08 Making UEX Features Work With Jamf Check in

The Problem

When launchd wants to terminate a job it sends a SIGTERM signal which will be propagated to all child processes of the job as well. https://www.launchd.info

What this means

• When you run commands in scripts that have an & after it to make it's own process ( a child process )
• If that script runs during check in as a part of com.jamfsoftware.task.1.plist (the default check-in daemon and parent process
• Once the script and all other policies at check-in are completed
• The child process is terminated

How this affects UEX

The restart, logout, and inventory update agents depend on running after the check-in finishes. When any policy requires any of these agents they are started as a child process and therefore can be killed after a check-in is done.

This might also affect other scripts that depend on being set as their own child process. Such as https://github.com/kc9wwh/macOSUpgrade which uses & to make the macOS installer run as a child process and allows the policy to finish. Although the macosupgrade project was designed to run in Self Service, when combined with UEX, it can be a powerful mix to push the updates to users that rarely visit Self Service.

The Solution

AbandonProcessGroup Setting the value of this key to true will stop this propagation, allowing the child processes to survive their parents.

By modifying com.jamfsoftware.task.1.plist with this key and value it will allow child process to stay running.

<key>AbandonProcessGroup</key>
<true/>

00-UEX-Fix-Check-in-Daemon-jss.sh was written to monitor the check-in daemon and set this value then reload the daemon so that future check-in will work with UEX. When deployed to clients it makes own Daemon to watch for changes.

General Work-flow

• If the script is not from the daemon make a copy of itself and make a new daemon so that it can run locally
  • Then exit to avoid disrupting the check-in
• Wait for all policies at check-in to finish
  • Achieved by watching for the jamf policy -randomDelaySeconds in running processes
• Wait for management framework to finish updating
  • Achieved by watching for the jamf manage in running processes
• Read com.jamfsoftware.task.1.plist
• If AbandonProcessGroup is not set true
  • get the contents of the daemon to retain the check in time
  • add the right setting to the end <key>AbandonProcessGroup</key><true/>
  • unload and reload com.jamfsoftware.task.1.plist

Deployment of Solution

This script can be deployed automatically to all clients with the API Config Tool or you can deploy it to clients selectively on your own. And as always...

TEST TEST TEST!!! (not in production) 😉😜