Sick and tired of failure of recon, policy and manage commands

khurram
Contributor III

e7f2326fc51f43c8b7d1c1feb4c73efb

The picture above shows how the recon, policy and manage commands are failing. What do we do if these commands are not taking affect immediately ? Can anyone please help ?

1 ACCEPTED SOLUTION

sdagley
Esteemed Contributor II

@khurram You need to do a sudo killall jamf to kill the Jamf processes

View solution in original post

9 REPLIES 9

khurram
Contributor III

notice how the 'recon' command was not responding and then Ctrl + c was used to abruptly end this command

sdagley
Esteemed Contributor II

@khurram You need to do a sudo killall jamf to kill the Jamf processes

garybidwell
Contributor III

Policy checks run as per your global checkin settings on the JSS - yours is reporting 300 seconds (so every 5 minutes)

All Settings, Computer Management Management Framework, Check In

if you need to run a policy check instantly, just running jamf policy command is all that is required to check for new and outstanding scheduled policies (the execution is then done a per each of your policy settings - once per computer, once per day, each check-in etc...)
*Not required for Config Profiles as that's APNs, which is near instant (or at least as how fast Apple's network sends out the APNs commands)

I'm not sure why you are running a Jamf manage command as this should really only be used on unmanaged devices or if you have issues with the client, as it forces all the jamf framework to be re-installed from scratch (its will then run through nearly all the commands as if its just been enrolled).

From the jamf man pages: manage = Enforces the entire management framework from the JSS

jamf recon - this does do a jamf policy command as part of its function, but also updates the inventory records at the same time (normally once a day is the default) - depending on your inventory this can take a minute to collate and upload to the JSS
if you clicked every inventory option and also collect user application usages stats the recon command could take upto 15 mins to get all of this.
You won't get any feedback on a recon command until its finished getting the info on inventory settings and what extension attributes are being used from the JSS - then is should start giving feedback on each step of the command

If it really is hanging then its struggling to talk to your JSS use the jamf checkJSSconnection command and may be try the -verbose and -displayJSSTraffic options on a recon to see how much data it being sent back to the JSS

donmontalvo
Esteemed Contributor III

The jamf binary is single threaded, so you can't tell it to check for policies while its doing something.

I believe this is why there is a 5 minute resumable download time limit, where an unlimited number of resumes are possible if none exceed 5 minutes...if a resume exceeds 5 minutes, the policy exits with a failure...this way jamf binary can go on to the next task.

--
https://donmontalvo.com

khurram
Contributor III

Thanks @sdagley I was actually missing the sudo, aarrrghhh, silly me. If you are working as 'root' you don't need to add sudo.

DWilliams-cmsd
New Contributor III

Glad I found this thread! Thought I would share my experience in case someone else has the same issue and runs across this thread too. I had the same problem with....
"The management framework will be enforced as soon as all policies are done executing"

The "sudo killall jamf" command did not work.

What did work was....

  1. sudo jamf removeframework
  2. Re-enrolling through <jss.address>/enroll

That has re-applied the management framework and set everything back to normal.

russell_garriso
New Contributor III

I can riff on this after losing another hour to it. I have had other issues with softwareupdate and jamf butting heads. So yesterday my machine stopped checking in after a policy I have kicked off softwareupdate to check for security updates and install them automatically. I decided to restart today and try to get unstuck in Jamf.

First the trouble:


Tue Mar 01 13:35:38 rg-mbp15 jamf[1744]: Checking for policies triggered by "recurring check-in" for user "russellgarrison"...
Tue Mar 01 13:35:44 rg-mbp15 jamf[1744]: Executing Policy Update Inventory
Tue Mar 01 13:35:47 rg-mbp15 jamf[1744]: Executing Policy Update Minor OS Updates 10.13.4 and Up Aggressive Test

Okay, restart:

Wed Mar 02 15:08:10 rg-mbp15 jamf[415]: The management framework will be enforced as soon as all policies are done executing.
Wed Mar 02 15:08:14 rg-mbp15 jamf[415]: Adding launchd task com.jamfsoftware.task.checkForTasks...
Wed Mar 02 15:08:45 rg-mbp15 jamf[625]: Checking for policies triggered by "startup" for user "russellgarrison"...
Wed Mar 02 15:11:04 rg-mbp15 jamf[625]: The management framework will be enforced as soon as all policies are done executing.
Wed Mar 02 15:11:10 rg-mbp15 jamf[625]: Executing Policy Set Redshift TCP Options
Wed Mar 02 15:12:27 rg-mbp15 jamf[625]: Removing existing launchd task /Library/LaunchDaemons/com.jamfsoftware.task.checkForTasks.plist...
Wed Mar 02 15:12:30 rg-mbp15 jamf[625]: Adding launchd task com.jamfsoftware.task.checkForTasks...
Wed Mar 02 15:13:11 rg-mbp15 jamf[1416]: The management framework will be enforced as soon as all policies are done executing.
Wed Mar 02 15:13:11 rg-mbp15 jamf[1341]: Checking for policies triggered by "login" for user "russellgarrison"...
Wed Mar 02 15:13:16 rg-mbp15 jamf[1341]: The management framework will be enforced as soon as all policies are done executing.
Wed Mar 02 15:13:17 rg-mbp15 jamf[1341]: Removing existing launchd task /Library/LaunchDaemons/com.jamfsoftware.task.checkForTasks.plist...
Wed Mar 02 15:13:17 rg-mbp15 jamf[1341]: Adding launchd task com.jamfsoftware.task.checkForTasks...
Wed Mar 02 15:13:18 rg-mbp15 jamf[1553]: The management framework will be enforced as soon as all policies are done executing.
Wed Mar 02 15:14:20 rg-mbp15 jamf[1617]: The management framework will be enforced as soon as all policies are done executing.
Wed Mar 02 15:15:22 rg-mbp15 jamf[1652]: The management framework will be enforced as soon as all policies are done executing.
Wed Mar 02 15:16:23 rg-mbp15 jamf[1688]: The management framework will be enforced as soon as all policies are done executing.
Wed Mar 02 15:17:25 rg-mbp15 jamf[1713]: The management framework will be enforced as soon as all policies are done executing.
Wed Mar 02 15:18:26 rg-mbp15 jamf[1740]: The management framework will be enforced as soon as all policies are done executing.
Wed Mar 02 15:19:28 rg-mbp15 jamf[1781]: The management framework will be enforced as soon as all policies are done executing.
Wed Mar 02 15:20:36 rg-mbp15 jamf[1821]: The management framework will be enforced as soon as all policies are done executing.


Even try starting up offline, and still the enforcement loop. You will see something like this in ps output:

 

767 ?? S 0:00.15 /usr/local/jamf/bin/jamf policy -event networkStateChange
999 ?? S 0:00.01 sh -c /bin/ps auxww | /usr/bin/grep -v 'sudo' | /usr/bin/grep 'jamf policy' | /usr/bin/grep -v 'sh -c' | /usr/bin/grep -v grep | /usr/bin/grep -v Contents/MacOS/jamfHelper | /usr/bin/grep -v 767 >& '/Library/Application Support/JAMF/tmp/767.pid'
1002 ?? S 0:00.00 /usr/bin/grep jamf policy
1006 ?? S 0:00.00 /usr/bin/grep -v Contents/MacOS/jamfHelper
2578 s000 S+ 0:00.01 grep jamf

 

 

My hacked solution was the following:

sudo kill 767

sudo kill 999

sudo kill 1002

sudo kill 1006

 

Go back online and cross your fingers. In my case networkStateChange ran successfully and then the Jamf /tmp dir was flushed and everything fell into place, for now. You may find that you need to clean out the /tmp and then restart for good measure before going back online. Really hope this doesn't happen too much out there. Also, the alternative of unenrolling and then re-enrolling does seem to work okay here. Just seems heavy handed to me, but maybe that is the experience of others with tons of machines. It could just be okay that you have to look out and unenroll re-enroll a part of your population all the time to keep things going. Thoughts?

jps3
Release Candidate Programs Tester

You can be more specific with pkill by using sudo pkill -f 'jamf policy' which will perform a (regexp) search for that string including the space, which should help cover any edge cases we don't want to trample on. And the sister command pgrep with slightly different options can be helpful when looking sudo pgrep -afl 'jamf policy'.

FWIW.

I've been coming across similar things in my labs where updates just are not happening and cannot be forced. There may be 1-2 systems per day that update overnight. They're all macOS Big Sur, and have a 1 day deferral set. Will need to review this thread more carefully.

Qwheel
Contributor II

Interesting to see that 'Jamf Manage' does so much.

I have it set to run once a month on all devices - I did this because I noticed that the 'Computer use reporting' stopped documenting Logins and Logouts... (just displaying Logins).
In those instances, nearly everytime I ran a JAMF manage it 'started doing something'.

I set that up a while ago now... but looking through the logs on the policy - "The management framework will be enforced as soon as all policies are done executing." is now a regular occurrence, AND logouts still aren't being documented.

Sigh