Feature Request - Pause JAMF Framework #119

New Issue

michael · 2026-01-19T18:31:35Z

michael commented

2026-01-19 18:31:35 +00:00

Originally created by @Uggbert on GitHub.

During long deployments (such as lab devices) where lots of software deployments and configuration is taking place I have a script that pauses the jamf framework - killing jamf binary and unloads the schedule task

jamftasks=($( find /Library/LaunchDaemons -iname "*task*" -type f -maxdepth 1 ))
jamfpid=$( ps -ax | grep "jamf policy -randomDelaySeconds" | grep -v "grep" | awk '{ print $1 }' )
for ((i=0;i<${#jamftasks[@]};i++)); do
	launchctl unload -w "${jamftasks[$i]}"
done

if [ "$jamfpid" != "" ]; then
	kill -9 "$jamfpid"
fi

exit 0

This ensures all manual triggers are executed in order without interruption, then at the end of deployment this then reloads as normal to allow normal recon and any other 'check-in' policies to run.

Is it possible to add something like this as a bool value to the config? if not, no worries I can keep this bookending my deployments.

Originally created by @Uggbert on GitHub. During long deployments (such as lab devices) where lots of software deployments and configuration is taking place I have a script that pauses the jamf framework - killing jamf binary and unloads the schedule task ``` jamftasks=($( find /Library/LaunchDaemons -iname "*task*" -type f -maxdepth 1 )) jamfpid=$( ps -ax | grep "jamf policy -randomDelaySeconds" | grep -v "grep" | awk '{ print $1 }' ) for ((i=0;i<${#jamftasks[@]};i++)); do launchctl unload -w "${jamftasks[$i]}" done if [ "$jamfpid" != "" ]; then kill -9 "$jamfpid" fi exit 0 ``` This ensures all manual triggers are executed in order without interruption, then at the end of deployment this then reloads as normal to allow normal recon and any other 'check-in' policies to run. Is it possible to add something like this as a bool value to the config? if not, no worries I can keep this bookending my deployments.

michael closed this issue

2026-01-19 18:31:35 +00:00

michael commented

2026-01-19 18:31:36 +00:00

@scriptingosx commented on GitHub:

Setup Manager already waits for the jamf processes to be finished and then unloads the background daemon while it is running its workflow (this is one of the steps in the "Getting Ready" phase). Then it reloads the background daemon when it is done.

If you are still seeing problems:

please test with Setup Manager 1.1beta
if the problems persist with 1.1beta, please share /Library/Logs/Setup Manager.log and /var/log/jamf.log

@scriptingosx commented on GitHub: Setup Manager already waits for the jamf processes to be finished and then unloads the background daemon while it is running its workflow (this is one of the steps in the "Getting Ready" phase). Then it reloads the background daemon when it is done. If you are still seeing problems: 1) please test with Setup Manager 1.1beta 2) if the problems persist with 1.1beta, please share `/Library/Logs/Setup Manager.log` and `/var/log/jamf.log`

michael commented

2026-01-19 18:31:36 +00:00

@Uggbert commented on GitHub:

Ok then this was not working for me with the 1.1 beta. It's what prompted
me to write this, I'll take a look at the logs!
Kind Regards,

Graeme Urquhart

On Tue, 1 Oct 2024, 17:55 Armin Briegel, @.***> wrote:

Setup Manager already waits for the jamf processes to be finished and then
unloads the background daemon while it is running its workflow (this is one
of the steps in the "Getting Ready" phase). Then it reloads the background
daemon when it is done.

If you are still seeing problems:

please test with Setup Manager 1.1beta

if the problems persist with 1.1beta, please share /Library/Logs/Setup
Manager.log and /var/log/jamf.log

—
Reply to this email directly, view it on GitHub
https://github.com/Jamf-Concepts/Setup-Manager/issues/37#issuecomment-2386514983,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AMF7CIGLCO5UQ2EOJSA3WEDZZLHYPAVCNFSM6AAAAABPFYFHC2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOBWGUYTIOJYGM
.
You are receiving this because you authored the thread.Message ID:
@.***>

@Uggbert commented on GitHub: Ok then this was not working for me with the 1.1 beta. It's what prompted me to write this, I'll take a look at the logs! Kind Regards, Graeme Urquhart On Tue, 1 Oct 2024, 17:55 Armin Briegel, ***@***.***> wrote: > Setup Manager already waits for the jamf processes to be finished and then > unloads the background daemon while it is running its workflow (this is one > of the steps in the "Getting Ready" phase). Then it reloads the background > daemon when it is done. > > If you are still seeing problems: > > 1. please test with Setup Manager 1.1beta > 2. if the problems persist with 1.1beta, please share /Library/Logs/Setup > Manager.log and /var/log/jamf.log > > — > Reply to this email directly, view it on GitHub > <https://github.com/Jamf-Concepts/Setup-Manager/issues/37#issuecomment-2386514983>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AMF7CIGLCO5UQ2EOJSA3WEDZZLHYPAVCNFSM6AAAAABPFYFHC2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOBWGUYTIOJYGM> > . > You are receiving this because you authored the thread.Message ID: > ***@***.***> >

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: jamf/Setup-Manager#119