What would cause this on sudo jamf policy? This policy trigger is already being run: ....

This just means that the JAMF policy trigger is already running. You can wait for it to finish and then you can manually run it again. You could force kill the process if you want to be able to run it manually immediately without waiting but I would strongly recommend not doing that.

Hmm, I've tried to trigger the process over the course of an hour.

How can I find out how far along it is? I think it's caching Yosemite, but from PA to Hong Kong, time ti spin up a another JSS or find another hub, like Amazon

You can check to see if the yosemite installer is getting cached into the /Library/Application Support/JAMF/Waiting Room folder. Once SSH'd into the system just do a Sudo -s enter your password then enter the following commands:

cd /Library/Application Support/JAMF/Waiting Room/
ls -la

If it is caching the installer as you suspected then you should see the file there and it's current size.

Awesome, that helps a bunch, I am now watching it to see if it grows with any sort of speed, before I just kill it, remote in with LogMeIn and run the installer from the App Store until we can get a better distribution point.

It could also be helpful to have a look at /var/log/jamf.log on the client machine. That should tell you exactly what's happening.

In review of the log, which was helpful but the way, I'm finding my check in constantly getting stuck... does anyone know what would be causing this type of behavior? What is the networkstatechange it's referencing? I'm not disconnecting/reconnecting from my network that often. Odd

Tue Nov 24 15:49:03 RFG_MbProR15 jamf[32151]: Checking for policies triggered by "recurring check-in"...
Tue Nov 24 15:49:05 RFG_MbProR15 jamf[32151]: Executing Policy Black and White Default...
Tue Nov 24 15:49:06 RFG_MbProR15 jamf[32151]:   Verifying package integrity...
Tue Nov 24 15:49:06 RFG_MbProR15 jamf[32151]:   Installing B&W_Printing_PPD_Files.dmg...
Tue Nov 24 16:09:17 RFG_MbProR15 jamf[56]: Network state changed, checking for policies...
Tue Nov 24 16:09:18 RFG_MbProR15 jamf[43290]: Checking for policies triggered by "networkStateChange"...
Tue Nov 24 17:04:27 RFG_MbProR15 jamf[56]: Network state changed, checking for policies...
Tue Nov 24 17:04:28 RFG_MbProR15 jamf[68392]: Checking for policies triggered by "networkStateChange"...
Tue Nov 24 19:15:56 RFG_MbProR15 jamf[56]: Network state changed, checking for policies...
Tue Nov 24 19:15:57 RFG_MbProR15 jamf[18914]: Checking for policies triggered by "networkStateChange"...
Tue Nov 24 19:37:45 RFG_MbProR15 jamf[56]: Network state changed, checking for policies...
Tue Nov 24 19:37:46 RFG_MbProR15 jamf[19381]: Checking for policies triggered by "networkStateChange"...
Tue Nov 24 19:37:47 RFG_MbProR15 jamf[19381]: Could not connect to the JSS. Looking for cached policies...
Tue Nov 24 19:37:52 RFG_MbProR15 jamf[56]: Network state changed, checking for policies...
Tue Nov 24 19:37:53 RFG_MbProR15 jamf[19530]: Checking for policies triggered by "networkStateChange"...
Wed Nov 25 00:53:27 RFG_MbProR15 jamf[56]: Network state changed, checking for policies...
Wed Nov 25 00:53:29 RFG_MbProR15 jamf[66255]: Checking for policies triggered by "networkStateChange"...
Wed Nov 25 00:53:30 RFG_MbProR15 jamf[66255]: Could not connect to the JSS. Looking for cached policies...
Wed Nov 25 00:53:30 RFG_MbProR15 jamf[56]: Network state changed, checking for policies...
Wed Nov 25 00:53:32 RFG_MbProR15 jamf[66328]: Checking for policies triggered by "networkStateChange"...
Wed Nov 25 08:31:15 RFG_MbProR15 jamf[56]: Network state changed, checking for policies...
Wed Nov 25 08:31:16 RFG_MbProR15 jamf[66328]: Could not connect to the JSS. Looking for cached policies...
Wed Nov 25 08:31:18 RFG_MbProR15 jamf[66520]: Checking for policies triggered by "networkStateChange"...
Wed Nov 25 08:31:19 RFG_MbProR15 jamf[66520]: Could not connect to the JSS. Looking for cached policies...
Wed Nov 25 08:31:25 RFG_MbProR15 jamf[56]: Network state changed, checking for policies...
Wed Nov 25 08:31:26 RFG_MbProR15 jamf[66674]: Checking for policies triggered by "networkStateChange"...
Wed Nov 25 08:31:49 RFG_MbProR15 jamf[56]: Network state changed, checking for policies...
Wed Nov 25 08:31:50 RFG_MbProR15 jamf[66949]: Checking for policies triggered by "networkStateChange"...

The policies aren't stuck. I don't think console shows when a policy has been completed/exited.

A network state is anytime:
You connect to bluetooth/disconnect
You connect to ethernet/disconnect
You connect to VPN/Disconnect (Basically anytime something in network preferences changes its a network state change)

@rgranholm By the time stamps in that log you posted it seems the jamf binary is doing exactly what it's supposed to do, run check-in on the "every 15" min mark. And it's "checking for policies triggered by networkStateChange". It looks like this client has connected and disconnected from the network several times as your log time stamps span from about 3PM to 8:30AM.

So it seems you're trying to initiate a policy that, as @FritzsCorner said, that is already being run, preparing to run or is at the end of it's run.

Hmm, I'm hearing it's doing what it should, but every time I run jamf policy, the policy trigger is already being run, making me think something it's working, the last "check in" time in the JSS also is hours ago.

You can always run a ps -ef | grep jamf to see what processes are running currently with that binary.

Thanks so much, hmm, I did mess with an iBeacon like months ago, but I still can't tell from this what's the hold up. I didn't see a policy for the iBeacon on my computer, but I am listed in an iBeacon range.

RFG-MbProR15:~ rgranholm$ ps -ef | grep jamf
    0    56     1   0 Tue10AM ??         0:17.39 /usr/local/jamf/bin/jamf launchDaemon -monitorUsage -monitorBeacons -enforceRestrictions -monitorNetworkStateChanges
    0   987     1   0 Tue10AM ??         1:54.31 /usr/local/jamf/bin/jamfAgent
    0 32149     1   0 Tue03PM ??         0:00.02 sudo jamf policy
    0 32151 32149   0 Tue03PM ??         0:13.44 jamf policy
  502 79176 79050   0  5:14PM ttys000    0:00.00 grep jamf

Days later, trying to check in on this. I don't think it's beacon related at all.

I still get this on grep ... can anyone help me figured out why it's always hanging? If it means anything, I can't open Self Service either, it just hangs and hangs.

This policy trigger is already being run: root             1067   0.0  0.2  2572228  32012   ??  S    11:22AM   0:06.92 jamf policy
RFG-MbProR15:~ rgranholm$ ps -ef | grep jamf
    0    56     1   0 11:20AM ??         0:06.56 /usr/local/jamf/bin/jamf launchDaemon -monitorUsage -monitorBeacons -enforceRestrictions -monitorNetworkStateChanges
    0  1051     1   0 11:22AM ??         0:00.02 sudo jamf policy
    0  1067  1051   0 11:22AM ??         0:06.93 jamf policy
    0  1175     1   0 11:22AM ??         0:05.31 /usr/local/jamf/bin/jamfAgent
  502 45259 45094   0  6:31PM ttys000    0:00.00 grep jamf
RFG-MbProR15:~ rgranholm$ ps -ef | grep jamf
    0    56     1   0 11:20AM ??         0:07.14 /usr/local/jamf/bin/jamf launchDaemon -monitorUsage -monitorBeacons -enforceRestrictions -monitorNetworkStateChanges
    0  1051     1   0 11:22AM ??         0:00.02 sudo jamf policy
    0  1067  1051   0 11:22AM ??         0:07.39 jamf policy
    0  1175     1   0 11:22AM ??         0:05.72 /usr/local/jamf/bin/jamfAgent
  502 57641 45094   0  7:02PM ttys000    0:00.00 grep jamf

Sounds a bit like a network issue between the client machine and the JSS.

If I get the message saying the binary is already being run or some such, I tend to try a

killall jamf

then you might want to try

jamf manage

Might be an issue with the binary.

Tried restarting? Re-running enrollment or removing the binary and enrolling again?
Happening on other machines or just the one?

Thanks again! Those two commands at least got me functional.

I'm wired into my network, no issues otherwise, server is almost right next to me, wonder what could be causing hiccups...I will keep an eye out. At least I know how to force a check in now, which also cleared up Self Service not launching.

Mine constantly gets stuck. This one has been running since 6/16. (today is 6/27). I had to SSH into his machine and kill the process. Anyone know why the trigger keeps getting stuck?

This policy trigger is already being run: root 3533 0.0 0.0 2505432 2456 ?? Ss 16Jun17 0:01.84 /usr/local/jamf/bin/jamf policy -randomDelaySeconds 300

I have a similar situation going on. Funny thing is, could it just be coincidence that the time on my logs match the time on rgranholm, which is at 12:22AM?

@ronb Hey did you ever solve this issue ? I am having similar problem..

Never did dross. Just moved on. I still seem to see it more often than not on other systems I am working on, but it's hit or miss.

Yea , I am thinking its erase install time. tried all the fixes mentioned.

I have see this issue too, however it was only on machines that saw this issue...so I kinda thought it was a messed up enroll

https://www.jamf.com/jamf-nation/discussions/38791/intel-macbook-pros-not-creating-new-user-accounts#responseChild216817

I have just seen this again ... with a machine that wasn't checking in .. .Has anyone open a ticket with Jamf?

C

So I have been fixing this with sudo killall jamf .. however today I just saw a machine where it said the process isn't running but when I ran sudo jamf policy still got This policy trigger is already being run: root XXXXXXX....

Any ideas?

C

Having the same issue and cannot not determine what is actually stuck. When running sudo jamf policy, getting this (at today's date):

This policy trigger is already being run: root 632 0.0 0.0 434 8292 2796 ?? S 28Jun21 0:08.43

What are 434 8292 2796, are these policy IDs? As I was not able to find anything under these IDs on our JSS

Overall it would be nice exactly what does this response means in details!

Was only able to push the needed policy manually as otherwise it is uncertain for how long you should wait and if it is still stuck or not... sudo jamf policy -id XXXX

I came across this issue yesterday and it occured after the user upgraded his intel  AD bound macbook from monterey to ventura. With the verbose setting on I saw this error jamf policy error code 51
All the tips and steps in this thread did not work. 
Not even a sudo jamf policy logged in as local admin.
What did work was to enable the root account and then run the sudo jamf policy command.

Ofcourse I disabled the root account after the issue was fixed.