See what policies are executing on a computer?

rseide
Contributor

I'm having an issue with a specific computer where, according to JSS, it hasn't checked in since 6/17. The policy I have run/ran is one where it removes a specific User profile.

In the JSS, this computer still shows this profile installed, however, if i SSH into it and change directories to the /Users folder, that profile is no longer there.

While I was SSH'd into the machine, i ran "sudo jamf manage" to see if I can try and manually have the computer update it's inventory/report to JSS, but I keep getting:

The management framework will be enforced as soon as all policies are done executing.

How can I see which policies are executing?

In addition, how/why did the policy run but the last report date says 6/17 and the JSS is still showing the profile there?

Thanks in advance.

6 REPLIES 6

JPDyson
Valued Contributor

You could tail the log file:

tail -20 /var/log/jamf.log

As for what you're seeing in inventory, it's showing you the status of the computer as of its last report (ie, before the policy ran). It's possible there are certificate issues on the computer, for example, and it doesn't trust the JSS.

mm2270
Legendary Contributor III

As a first step, I would take a look at the log file as JPDyson recommends. That will give you some idea of what's happening. There are timestamps for each entry in the log, so you should be able to see when the current policy began executing.

The jamf binary may have gotten stuck in a loop or otherwise is not exiting out of the last policy run. Its rare, but it can happen. We've seen it on occasion on some of our Macs. That would explain why it hasn't checked in or submitted inventory recently, since I don't think it can't do that until it completes the current running policies.
You could try killing all the running jamf processes on the Mac while ssh'd into it, but you may of course be killing something genuine, so be careful with that. If you do, they'll respawn once the binary gets called to do its next scheduled check-in.
Also, has the Mac been rebooted recently? Do uptime on it while ssh'd to see how long its been since last reboot.

rseide
Contributor

Thanks to both of you. I will check out the log as you instructed.

I forgot to mention that part of the policy is to Update Inventory after it's run. That being said, shouldn't the computer have updated the JSS? the policy ran last night.

Yes, the Mac was rebooted yesterday, before the policy was supposed to be executed.

mm2270
Legendary Contributor III

Since the inventory update happens at the very end of the policy run and then uploads all the data to the JSS, if it doesn't get to that stage, for example if it got stuck on gathering inventory or closing down the policy install, etc, you'll never get an updated inventory in your JSS. Another possibility is that the Mac had trouble uploading the log to the JSS. If that happens, the jamf binary will store the policy log locally and attempt to upload it again the next time it connects up.

Back in an older version of Casper there was a bug that JAMF fixed where certain special characters would cause the log to not get uploaded into the JSS. This resulted in the policy executing again and again and storing another log locally on the Mac. Each time the Mac would check in it attempted to upload the ever growing list of logs, to the point that it would cause the fans to blow like crazy as it worked real hard to upload those logs, but couldn't. The only recourse was to blow away or move the logs from the folder.
I'm not saying that's happening here (unless you happen to be running a very out of date version of Casper Suite on your JSS. You aren't are you?) I'm just illustrating how sometimes things don't go as planned and need a kick in the pants to get them going again.

If the Mac rebooted prior to the policy run that doesn't mean much. If the binary is stuck running a policy that won't shut down you may need to kill it or reboot the Mac again.

rseide
Contributor

Thanks for your thorough explanation.

We are running 8.63.

I'll try rebooting the machine again and see if that helps.

Thanks again for your input, both of you. :)

RobertHammen
Valued Contributor II

And another "test and get yourself to 8.71 ASAP" comment from me ;-)