Skip to main content

Hi - I'm experiencing a somewhat strange issue lately. We have a very Self Service-heavy environment where I work, and I've recently noticed a strange glitch with any self-service policy...



Let's say I manually cancel a running policy ('X' button) for some reason (e.g., I'm binding to a directory service and it is failing for some reason and I want to stop it from running before it times-out on its own). I know, not the best practice, but again...let's just say "what if."



Then, if I try to run that same policy again (even after restarting, recon-ing, enforcing mgmt. framework, resetting MDM, etc.) it says "Gathering Information" then the progress bar just zooms and completes and nothing has happened. The JSS has no record of the policy running and the jamf.log just says "running policy xxx..."



I am able to easily reproduce the issue on my own system with just about any policy, script-based only or ones with package payloads.



Is there some cache or something that I can clear out that will let me attempt to run one of these policies again? Has anyone else experienced this issue? I've tried checking the 'Waiting Room' and 'Tmp' directories, clearing them and unfortunately the issue persists.



jamf 9.97.1482356336. Planned deployment of 9.98 next week...



Thanks!

I had a similar experience when I manually ran a policy with an -event flag and then cancelled it with a ctrl -c.



What I did to get the policy to run again was to hit the edit button on the policy, make no changes, and then save. I would give that try.

Maybe re-enrolling the device will kick it back into gear as well.

Thanks guys. I didn't get a chance to try the fake edit policy trick - but will the next time this comes up. Yesterday I did end up re-enrolling the problematic Mac I was working with and that did the trick. In terms of my recreating the issue earlier today, it turns out that just time was all that was required. After a couple of hours the policy works again normally. So who knows! But glad it appears to be self-healing.

Ok glad I'm not the only one experiencing this. Will be forwarding this to support under the ticket I'm logging.

Official word from JAMF:



I did some research and found out that in fact we have Product Issue for that.

If an admin creates a policy that an end user tries to run (but cancels) from Mac/ OS X Self Service, then the policy will not be available again for one hour. Despite this, the output returned by self service appears to indicate the the policy runs correctly.

For now workaround is to wait for one hour before attempting to run the policy again.


Oh well.

Problem: If you interrupt (ctrl-c) a policy on the command running 'jamf policy' or 'jamf policy -event ..." then that computer effectively falls out of scope for the policy in question.



Workaround: You can edit the policy and update the execution frequency field to clear what ever flag is not getting cleared.



We demonstrated this in person to our Jamf Buddy at the 2017 JNUC. No fix yet.



I do see the need for this mutex behaviour, as it would prevent an executing policy from running on top of itself and save the tomcat/database from going into potential meltdown. However, the jamf binary should be able to trap the user interrupt and call the deconstrutor prior to exit and clear the flag.

This is a horrible experience for both users and admins and almost impossible to diagnose because it doesn't even log the policy in the computer/policy history....

@prbsparx - It doesn't log because the ^C isn't trapped and it stops the jamf CLI command in its tracks.

Terms & ConditionsCookie settings