Self Service Policies running twice?

[fsjjeff]

I'm working on migrating over to Casper 9 and doing my final stages of testing, but I'm seeing some strange behavior with Self Service. It seems like my policies run twice... I click on "Install" and it runs the policy, then immediately runs it again. Anyone else seeing this or have ideas?

My /var/jamf.log shows the two runs like so:
Fri Jun 06 15:48:53 csf-s1306-29091 jamf[9597]: Checking for policy ID 8...
Fri Jun 06 15:48:57 csf-s1306-29091 jamf[9597]: Executing Policy Audacity...
Fri Jun 06 15:49:00 csf-s1306-29091 jamf[9597]: Verifying package integrity...
Fri Jun 06 15:49:00 csf-s1306-29091 jamf[9597]: Installing Apps-Optional-Audacity-2.0.3.0.pkg...
Fri Jun 06 15:49:11 csf-s1306-29091 jamf[9597]: Successfully installed Apps-Optional-Audacity-2.0.3.0.pkg.
Fri Jun 06 15:49:25 csf-s1306-29091 jamf[9739]: Checking for policy ID 8...
Fri Jun 06 15:49:29 csf-s1306-29091 jamf[9739]: Executing Policy Audacity...
Fri Jun 06 15:49:32 csf-s1306-29091 jamf[9739]: Verifying package integrity...
Fri Jun 06 15:49:32 csf-s1306-29091 jamf[9739]: Installing Apps-Optional-Audacity-2.0.3.0.pkg...
Fri Jun 06 15:49:38 csf-s1306-29091 jamf[9739]: Successfully installed Apps-Optional-Audacity-2.0.3.0.pkg.

[Look]

I have some scripts in Self Service and they do this as well, run and then run again...

[mm2270]

Since starting with Casper Suite 9 you can assign multiple triggers to one policy, is it possible the policies doing this are using both Self Service and some other trigger, like recurring check-in? Or are you actually seeing it run twice within Self Service, as in progress bar goes from start to finish and then starts back at the beginning and runs through it again?

I recall back when we did some early testing on v9 that when we imported and upgraded our db, some policies were showing up with more than one trigger checked. If I recall, I think it only happened with any policies using the "any" trigger though.

[Look]

Not in my case, freshly minted script with no triggers, only being run from Self Service, I know it's running twice directly as it has dialog boxes for the user. It literally runs a second time one second after completing the first run. Looks like a bug to me.

[mm2270]

@Look, you mentioned it being a script. Sure the script wasn't added twice to the policy, as Before and After? If not, then I would say it probably is a bug, 'cause pretty sure that should not happen.

What JSS version are you using? I would be curious to hear from the OP as well on the version of 9 he's using.

[Look]

We are on 9.32, just putting 9.52 into Dev so will try that when it's up.
Already checked it's only in there once, but I will look again when I get to work.
EDIT: Definitely only in there once, must be a bug.

[Look]

I have changed the script to BEFORE (it was AFTER) and when I ran it today it no longer runs twice...
Not sure if this is a result of this change or due to replication or other overnight activity on the JSS.

Sorry for thread hijack to the original poster!

[Look]

Some further information on this, it appears to be a local client issue and may possibly be related to the login to Self Service timing out and reprompting for credentials, switching OSX accounts or some cache clearing function. Basically if my machine is left on for sometime and I go in and out of Self Service a bit and also switch between users eventually the problem appears, it got to the point where they were running 4 times!
Restart the machine, bang, problem solved...
Trying to isolate exactly what behaviour causes it.
JSS 9.32 OSX 9.4.5

[Look]

Narrowed it down to having more than one user logged into the machine when the policy is run, it appears the policy gets run once for each of them or something strange like that and once it is broken and running multiple times it stays broken and continues to run multiple times each run until the machine is restarted. Or at least that is how my script is behaving.

@fsjjeff
Do you use fast user switching at all on the affected machine(s)?

[fsjjeff]

Hey, it was a while back that I original posted this question, when I was still at the testing phase prior to deploying Casper 9. Since then Casper 9 is mostly deployed and I haven't seen a lot of the double policy issue, but every once in a while it would pop up for me. And the Fast User Switching sounds like a likely culprit as during my testing I quite often flipped between an admin and an MCX Managed account, so that would certainly explain both why I saw it so consistently in my early testing, then so rarely during and after deployment. Good catch!