Please consider the following Script, delivered as the sole payload of a Policy "_DEV LWW Test:"
#!/bin/bash
sh -c 'sleep 300; echo good > /tmp/ok' &
There are plenty of other Jamf Community posts (here's one and another one) which offer use-cases and success stories which involve forking a process to the background. Jamf Pro; Install & Upgrade methods for macOS Catalina is a particularly relevant thread for us. The Script above is a stripped-down, abstract version of a larger Script related to software updates.
I have configured the Policy to trigger upon "Recurring check-in" and with Execution Frequency = "Ongoing." As shown in the attached picture, I see different results based on how the Policy and its Script are invoked:
- Automatically on the 15-minute check-in timer: The script runs without error (according to jamf.log and the Logs in the Jamf Pro web interface) but there is no sh -c sleep 300 process left running in the background.
- Manually via jamf policy: The script runs without error and an sh process is left running in the background.
- By launching the Policy from Self Service: The script runs without error and an sh process is left running in the background.
Can someone help me to understand the difference between the first bullet and the latter two? Is this reproducible on other systems, or maybe it is localized to our own — in which case it may be a product of security software? I'd really appreciate a hint as to where to look next.
Attached picture, with colored bars to represent commands run around the same time: