Jamf agent stuck on process when using 'prompt_user' #560

New Issue

michael · 2026-01-19T18:34:30Z

michael commented

2026-01-19 18:34:30 +00:00

Originally created by @m3ir on GitHub.

Hi!

recently I've noticed many machines on different jamfcloud fleets, stuck on jamf process.
the script have been used it 'prompt_user', seems that the user deffer the update, I am not sure how many times, This policy trigger is already being run on machine.
nothing will stop it, until the user will type : sudo killall jamf
after that the policies will keep coming while it's on scope.
I saw devices on pending for days, and just after killing jamf process, it ran on device.

Regards,

Originally created by @m3ir on GitHub. Hi! recently I've noticed many machines on different jamfcloud fleets, stuck on jamf process. the script have been used it 'prompt_user', seems that the user deffer the update, I am not sure how many times, This policy trigger is already being run on machine. nothing will stop it, until the user will type : sudo killall jamf after that the policies will keep coming while it's on scope. I saw devices on pending for days, and just after killing jamf process, it ran on device. Regards,

michael added the bug label 2026-01-19 18:34:30 +00:00

michael closed this issue

2026-01-19 18:34:30 +00:00

michael commented

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

@scriptingosx commented on GitHub:

can you re-check if this behavior appears with v8.0 there have been some improvements that should have fixed this

@scriptingosx commented on GitHub: can you re-check if this behavior appears with v8.0 there have been some improvements that should have fixed this

michael commented

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

@m3ir commented on GitHub:

I think they've clicked "Not now", but not sure.
anyway their were with Installomator v0.5, was it in default on "prompt-user" on that version?

@m3ir commented on GitHub: I think they've clicked "Not now", but not sure. anyway their were with Installomator v0.5, was it in default on "prompt-user" on that version?

michael commented

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

@TheDaveyBoy commented on GitHub:

Do you know if this is still the behavior? If the user doesn't interact with the prompt, will the prompt kill itself and move on after a certain amount of time?

@TheDaveyBoy commented on GitHub: Do you know if this is still the behavior? If the user doesn't interact with the prompt, will the prompt kill itself and move on after a certain amount of time?

michael commented

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

@Raptor399 commented on GitHub:

Also: does the user actually click "Not now", or do they leave the prompt open and just continue with their work?

Because the latter will never terminate the Installomator script, and therefore Jamf never gets the control back. Users ignoring the popup was the number one problem causing Jamf hangups for me, which is why I created PR #140 . It introduces a configurable timeout; if the user doesn't respond within the timeout, the script will assume "Not now" and exit.

@Raptor399 commented on GitHub: Also: does the user actually click "Not now", or do they leave the prompt open and just continue with their work? Because the latter will never terminate the Installomator script, and therefore Jamf never gets the control back. Users ignoring the popup was the number one problem causing Jamf hangups for me, which is why I created PR #140 . It introduces a configurable timeout; if the user doesn't respond within the timeout, the script will assume "Not now" and exit.

michael commented

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

@acodega commented on GitHub:

Can't say off the top of my head, you could look at some old commits to see what it was, but I think at this point this issue can be closed if it's not being seen on the latest release, Installomator v8.0. I'll leave this open for now and close it in a few days if we don't hear anything.

@acodega commented on GitHub: Can't say off the top of my head, you could look at some old commits to see what it was, but I think at this point this issue can be closed if it's not being seen on the latest release, Installomator v8.0. I'll leave this open for now and close it in a few days if we don't hear anything.

michael commented

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

@TheDaveyBoy commented on GitHub:

I figured it out.

Change

displaydialog() { # $1: message $2: title
    message=${1:-"Message"}
    title=${2:-"Installomator"}
    runAsUser osascript -e "button returned of (display dialog \"$message\" with  title \"$title\" buttons {\"Not Now\", \"Quit and Update\"} default button \"Quit and Update\" with icon POSIX file \"$LOGO\")"
}

to

displaydialog() { # $1: message $2: title
    message=${1:-"Message"}
    title=${2:-"Installomator"}
    runAsUser osascript -e "button returned of (display dialog \"$message\" with  title \"$title\" buttons {\"Not Now\", \"Quit and Update\"} default button \"Quit and Update\" with icon POSIX file \"$LOGO\" giving up after 120)"
}

This will close the prompt after 120 seconds. However, you do need to change

prompt_user|prompt_user_then_kill)
                      button=$(displaydialog "Quit “$x” to continue updating? (Leave this dialogue if you want to activate this update later)." "The application “$x” needs to be updated.")
                      if [[ $button = "Not Now" ]]; then
                        cleanupAndExit 10 "user aborted update" ERROR

to

prompt_user|prompt_user_then_kill)
                      button=$(displaydialog "Quit “$x” to continue updating? (Leave this dialogue if you want to activate this update later)." "The application “$x” needs to be updated.")
                      if [[ $button != "Quit and Update" ]]; then
                        cleanupAndExit 10 "user aborted update" ERROR

The osascript of giving up after (seconds) returns nothing, so just a quick and dirty fix of having the script check for quit and update only.

@TheDaveyBoy commented on GitHub: I figured it out. Change ``` displaydialog() { # $1: message $2: title message=${1:-"Message"} title=${2:-"Installomator"} runAsUser osascript -e "button returned of (display dialog \"$message\" with title \"$title\" buttons {\"Not Now\", \"Quit and Update\"} default button \"Quit and Update\" with icon POSIX file \"$LOGO\")" } ``` to ``` displaydialog() { # $1: message $2: title message=${1:-"Message"} title=${2:-"Installomator"} runAsUser osascript -e "button returned of (display dialog \"$message\" with title \"$title\" buttons {\"Not Now\", \"Quit and Update\"} default button \"Quit and Update\" with icon POSIX file \"$LOGO\" giving up after 120)" } ``` This will close the prompt after 120 seconds. However, you do need to change ``` prompt_user|prompt_user_then_kill) button=$(displaydialog "Quit “$x” to continue updating? (Leave this dialogue if you want to activate this update later)." "The application “$x” needs to be updated.") if [[ $button = "Not Now" ]]; then cleanupAndExit 10 "user aborted update" ERROR ``` to ``` prompt_user|prompt_user_then_kill) button=$(displaydialog "Quit “$x” to continue updating? (Leave this dialogue if you want to activate this update later)." "The application “$x” needs to be updated.") if [[ $button != "Quit and Update" ]]; then cleanupAndExit 10 "user aborted update" ERROR ``` The osascript of giving up after (seconds) returns nothing, so just a quick and dirty fix of having the script check for quit and update only.

michael commented

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

@Raptor399 commented on GitHub:

Have look at Pull Request #140, which tries to solve the problem in a similar fashion, but makes the timeout configurable instead of hardcoded.

@Raptor399 commented on GitHub: Have look at Pull Request #140, which tries to solve the problem in a similar fashion, but makes the timeout configurable instead of hardcoded.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Installomator/Installomator#560