Mac will not check-in automatically

[jriv]

Hello,

I have a Mac that refuses to check-in or update inventory by itself. It does if you sudo jamf policy or sudo jamf recon.

Things I've tried:
1. Ran a quick-add package
2. Removed MDM Profile (sudo jamf removeMDMprofile)
3. Reinstalled MDM Profile (sudo jamf manage)
4. Re-enrolled (sudo jamf enroll -prompt)

All of them ran without any issue and made the machine check-in/update inventory. However, the issue remains. I have more than 100 other Macs that are not having this issue. Has anyone encountered this before? Any advice?

Thanks!

[mm2270]

The check in process has nothing to do with MDM, so removing and adding the MDM profile isn't likely to help with this. The check-in is initiated from a local Jamf LaunchDaemon that has a startinterval to tell it to kick off every x minutes (plus add the random delay) That StartInterval amount depends on what you chose for your check in time in the JSS settings.

I would check to see if that LaunchDaemon is running, though I'd imagine it should be if you re-installed or re-enrolled the device.

sudo launchctl list | grep jamf

That should return something like this, but it may be slightly different for you.

com.jamfsoftware.task.Every 30 Minutes
com.jamfsoftware.jamf.daemon

It's that first one that does the check in as you can see by the label. If something similar to that doesn't show up, it's not loaded. Next step would be to see if it's present (the LaunchDaemon plist) but not loaded

ls -l /Library/LaunchDaemons/ | grep jamf

It actually shows up in Finder or Terminal as something like com.jamfsoftware.task.1.plist If you cat that plist, you'll see the label

$ cat /Library/LaunchDaemons/com.jamfsoftware.task.1.plist
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>com.jamfsoftware.task.Every 30 Minutes</string>
    <key>ProgramArguments</key>
    <array>
        <string>/usr/local/jamf/bin/jamf</string>
        <string>policy</string>
        <string>-randomDelaySeconds</string>
        <string>300</string>
    </array>
    <key>StartInterval</key>
    <integer>1800</integer>
    <key>UserName</key>
    <string>root</string>
</dict>
</plist>

Post back with what you find on the above.

[jriv]

Thanks, @mm2270. This is great.

sudo launchctl list | grep jamf returns nothing.

ls -l /Library/LaunchDaemons/ | grep jamf returns:

-rw-r--r--  1 root  wheel  868 Jun 21 10:43 com.jamfsoftware.jamf.daemon.plist
-rwxr--r--  1 root  wheel  474 Jun 21 10:43 com.jamfsoftware.startupItem.plist
-rw-r--r--  1 root  admin  537 Jun 21 10:43 com.jamfsoftware.task.1.plist

My guess is, I have to load the jamf and task daemons?

If that's right, will sudo launchctl load /Library/LaunchDaemons/com.jamfsoftware.jamf.daemon.plist and sudo launchctl load /Library/LaunchDaemons/com.jamfsoftware.task.1.plist do the trick?

[mm2270 · Accepted solution]

Yes, those commands should load them, but the big question is why they aren't loaded. Unless they were purposely unloaded at some point, they should auto load at each boot of the Mac and stay loaded. Before trying to load them, I would double check the ownership and permissions on them. launchd plist jobs need to have specific settings for them to load properly.

If you run

ls -l /Library/LaunchDaemons/com.jamfsoftware.task.1.plist

and similarly on the other plist, they should both show

-rw-r--r--  1 root  admin

as the first 4 columns of info, meaning root/wheel for owner/group and 644 for the POSIX permissions. If they aren't set that way you need to fix that first:

sudo chown root:wheel /path/to/plist
sudo chmod 644 /path/to/plist

Then load them with the commands you posted. As a test, I would do a reboot to make sure they are auto loading after a restart.

[jriv]

I was wondering the same thing. I will check and change the owner/group and permissions if necessary.

I wish JAMF Support knew about this when I opened up a ticket with them. It seems that since getting rid of the JAMF Buddy, our support experience has been very hit or miss.

Again, thanks for the help, @mm2270!

[mm2270]

That's odd that support didn't think to point you to that. I'd think that's pretty common knowledge that the daemon controls the check in process. I'm not sure why they wouldn't have recommended checking on that.

Anyway, glad that helped out.

Also, I just noticed that in my post above, the group on the task.1.plist is admin, not wheel, which is strange. That's from my own Mac. I'll need to check another system to see if that holds true or not. I thought it should be wheel not admin. Hmm...

Edit: OK, checked another machine and I see it's also root/admin on the task.1.plist but not the jamf.daemon plist. That one is root/wheel as I expected. Strange. I guess there's a reason for that, but I don't know what it is. I guess you should check on a working system to see what the owner/group says. Maybe the task plist needs to be admin for some reason that I'm not aware of.

[bradtchapman]

I discovered a repeatable problem with LaunchDaemon / LaunchAgent registration. @Grant.Klingbeil and Stacy @Behlmer worked tirelessly with me to diagnose this, and now PI-004098 has been opened for it. The enrollment process was not checking for unloaded agent/daemon and possibly not checking permissions either. Hopefully Jamf will fix this very soon.

[mm2270]

Ah, thanks for that PI @bradtchapman. I'll need to keep my eye on that. All the more reason Jamf needs to come up with some kind of self healing functionality for the framework. It's just too easy for Macs to stop checking in for no apparent reason.

[SimonLovett]

I don't know whether this is related, but I have taken to adding something like the following to my launchdaemons and agents...

https://developer.apple.com/library/content/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingLaunchdJobs.html

#
#. Do some stuff that you wanted done, then...
# 
#  https://developer.apple.com/library/content/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingLaunchdJobs.html
#
# Important: If your daemon shuts down too quickly after being launched, launchd may think it has crashed. 
# Daemons that continue this behavior 
#  may be suspended and not launched again when future requests arrive. 
# To avoid this behavior, do not shut down for at least 10 seconds after launch.
#
sleep 10
#

(Edited to add, I wonder if the LaunchDaemon for the binary sometimes finishes to quickly and could be getting quarantined. On things about it further, I suspect that much larger numbers of Jamf users would be seeing this 'though. I thought of it as it caused me no end of headaches with a script I wanted run every two minutes, which varied from machine to machine - sometimes it was fine, and sometimes it appeared to never run, or to run a few times only, before randomly conking out.

I found the ten seconds issue in the Apple documentation listed and it fixed it.

Seems to be a more recent thing that this is being enforced more than in the past as the issues were with Sierra 10.12.4 onwards)

[Cornoir]

Just as a thought you might also want to check permissions on those affected Macs that are not checking in.

[thoule]

For fun, this command will unload Jamf. The -w makes it permanent so even after a reboot, it won't load. And of course, 'load' to undo this change.

launchctl unload -w /Library/LaunchDaemons/com.jamfsoftware*

You can get a list of permanently disabled LaunchD's with this command

defaults read /var/db/com.apple.xpc.launchd/disabled.plist|grep "= 1"