Endless reboot

[bmichael]

After doing a user initiated enrollment on a non-DEP Mac that is running Sierra it would act like it was starting up by showing the apple logo and the progress bar would get about 3/4 of the way then it would start the entire process over. I was able to get into safe mode and bring up the log at the attached picture is what looks like was causing it. Any suggestions on how to fix?

[mm2270]

Do you have a policy scoped to it that would issue a restart, triggered by login? It almost looks like the login for "root" is causing it to run a policy, and then it restarts.
Another question - is it wired into a network? If so, what happens if you disconnect from the network and it reboots? Does it stop rebooting? If so, that would be a good indication it's getting its instructions for restart from a network resource, like the Jamf Pro server.

[bmichael]

I attached a picture of the global policy that runs when the device is enrolled. We do want the device to restart once this policy completes but it does look like something here may be causing it?

[hkabik]

how is that policy scoped and what is the frequency set to? Does this machine show up in that policies logs over and over?

[mm2270]

Sounds like the policy isn't being registered as complete for the machine back in the server, perhaps because of the reboot? If it doesn't show it completed, the next time the machine checks in, it's going to run that policy again, and again. Rinse, repeat. Maybe that's what's happening here.

[bmichael]

Policy is scoped to a smart group called "01 Global Not Complete".

[hkabik]

What are the requirements of that smart group and is the effected machine a member of the smart group?

Sounds like whatever requirement to be removed from that smart group is not being set so it just keeps running through.

[ricardtolosa]

Check if in /Library/Preferences there’s a launch daemon called com.jamfsoftware.task.reboot.plist, if so delete it and see if the problem persists.

[GabeShack]

We had this same issue with policies that happen during enrollment complete set to ongoing and had to switch them to once per computer.
Machine kept looping the Enrollment Complete commands and never registered that they actually completed.

I'll have to look more into what else we did, but that was the crux of it.

Gabe Shackney
Princeton Public Schools

[AMonts]

We have seen a few instances of this behavior (same log pattern but not enrollment related) preceded by:
A pair of attempts to remove “com.jamfsoftware.task.reboot.plist” from "/Library/LaunchDaemons/" (both of which were unsuccessful) and then “Exception: Error Domain=com.jamfsoftware.task.errors Code=124 “(null)””.

So a Launch Daemon (employed by a policy option) that should not be present is initiating reboots shortly after each attempt to boot. I then removed “com.jamfsoftware.task.reboot.plist” and rebooted, which lifted the condition (just as ricardtolosa suggests above). This addresses the immediate problem but does nothing to prevent it.

We are running JSS 10.9 and OS 10.12.6 on the effected devices. I am fairly confident we have never encountered this under a previous JSS version. Policies contributing to this result have been in use for some time and have not been modified.

[Sonic84]

We found that having softwareupdate -iaR and /usr/local/bin/jamf reboot -minutes 5 -background & in the same script was causing this issue. Specific criteria for occurrence is a Mojave client with a pending macOS update and a script delivered to via policy with the two code parts mentioned above. Whether or not a reboot options payload is included with the jamf policy made no difference (at least in my case). The fix in my environment was to harden our updater script to not issue a jamf reboot if the client is on Mojave. It also didn't happen all the time in repeat testing, which suggests a race condition is involved somewhere.

Observation from troubleshooting: It seems "create a launch daemon, delete the daemon, create a process in stead" is a common flow for jamf binary tasks. If this process is interrupted, the LD is left behind. if that daemon happens to be a reboot task, it really sucks for the end user.

hope this helps!