Restart window doesn't pop in or execute.

[spmindel]

Hopefully this isn't too weird as when I first tried this script, it worked perfectly. Further testing of it (different computers, trying defer, etc) has resulted in it never presenting the user the reboot message and never rebooting. Manually initiating a restart will install the update though.

Attached is a copy of the log. It seems something errors at line 192 with Jamfhelper. This should be with the default script and no modifications.

default 15:58:08.422901 -0400 logger /Library/Scripts/install_or_defer.sh: line 192: 1366 Terminated: 15 "$JAMFHELPER" -windowType "hud" -windowPosition "ur" -icon "$LOGO" -title "$MSG_UPDATING_HEADING" -description "$MSG_UPDATING" -lockHUD

InstallofDeferlog.txt

[mpanighetti]

According to the logs, the only update available was Safari, which doesn't require a restart. The script was updated awhile back to only restart if required to do so by one or more updates.

If you're seeing this behavior with updates that do require restarts (like 10.14.6 Supplemental 2), let us know and we can dig in further.

[spmindel]

Thank you for the response. Of course I provided a terrible example. Please see the log with the exact same behavior from the 10.14.1-10.14.6 update. It identifies from software update as requiring an update. After processing by the script, the restart never takes place. I'm unclear as to why. I've included a screenshot of softwareupdate -l to show that this patch does indicate a restart is required.

Logger.txt

[mpanighetti]

For what it's worth, that Terminated line is expected, as that's how the script kills the alert showing an update in progress (once the update has finished running). I'd recommend seeing if this issue persists in the latest build of Install or Defer (2.3.3); if it does, try running the script via bash -x so you can capture the logs of what exactly it's trying to do during the "Running all system updates..." step, and send those our way. I also haven't seen this in my production environment, so I'm curious where it's tripping up.

[Gregzy1987]

Hey, I also had this issue with the latest release, and with the 2 versions before. I found that 2.3.0 worked fine and decided to add the following changes only and it worked.

if [[ "$UPDATE_CHECK" == *"[restart]"* ]]; then changed to if [[ "$UPDATE_CHECK" =~ (Action: restart|\[restart\]) ]]; then

elif [[ "$UPDATE_CHECK" == *"[recommended]"* ]]; then changed to elif [[ "$UPDATE_CHECK" =~ (Recommended: YES|\[recommended\]) ]]; then

And also the Version check to 15 rather than 14. Hopefully this can help someone else with the same issues :)

[ahousseini]

I do have the exact same issue as @spmindel:

2019-12-09 15:54:23.272419+0100  localhost logger[13515]: Killing any active jamfHelper notifications...
2019-12-09 15:54:23.273106+0100  localhost logger[13515]: Cleaning up stored plist values...
2019-12-09 15:54:23.463291+0100  localhost logger[13534]: Starting install_or_defer.sh script. Performing validation and error checking...
2019-12-09 15:54:23.859685+0100  localhost logger[13534]: Validation and error checking passed. Starting main process...
2019-12-09 15:54:23.859809+0100  localhost logger[13534]: No logo provided, or no logo exists at specified path. Using Software Update icon.
2019-12-09 15:54:24.414895+0100  localhost logger[13534]: Max deferral time undefined, or not set to a positive integer. Using default value.
2019-12-09 15:54:24.416344+0100  localhost logger[13534]: Maximum deferral time: 72h:00m:00s
2019-12-09 15:54:24.476389+0100  localhost logger[13534]: Deferral deadline: 2019-12-12 15:54:24
2019-12-09 15:54:24.478132+0100  localhost logger[13534]: Time remaining: 72h:00m:00s
2019-12-09 15:54:24.498561+0100  localhost logger[13534]: Checking for pending system updates...
2019-12-09 15:54:35.273951+0100  localhost logger[13534]: Caching all system updates...
2019-12-09 15:54:46.669132+0100  localhost logger[13534]: Software Update Tool
2019-12-09 15:54:46.669253+0100  localhost logger[13534]: 
2019-12-09 15:54:46.669321+0100  localhost logger[13534]: Finding available software
2019-12-09 15:54:46.669372+0100  localhost logger[13534]: 
2019-12-09 15:54:46.669418+0100  localhost logger[13534]: Downloaded macOS 10.14.6-Update
2019-12-09 15:54:46.669464+0100  localhost logger[13534]: Done.
2019-12-09 15:54:46.682300+0100  localhost logger[13534]: Prompting to install updates now or defer...
2019-12-09 15:54:49.348667+0100  localhost logger[13534]: User clicked Run Updates after 00h:00m:03s.
2019-12-09 15:54:49.383618+0100  localhost logger[13534]: Running all system updates...
2019-12-09 15:55:21.594109+0100  localhost logger[13534]: Finished running updates.
2019-12-09 15:55:21.642962+0100  localhost logger[13534]: /Library/Scripts/install_or_defer.sh: line 254: 13625 Terminated: 15          "$JAMFHELPER" -windowType "hud" -icon "$LOGO" -title "$MSG_UPDATING_HEADING" -description "$MSG_UPDATING" -lockHUD
2019-12-09 15:55:21.643441+0100  localhost logger[13534]: Cleaning up stored plist values...
2019-12-09 15:55:21.705063+0100  localhost logger[13534]: Cleaning up main script and LaunchDaemons...

@Gregzy1987 I changed also those two lines but the issues still persist. Any hints?

[ahousseini]

I tried to run the script directly with bash -x and then it worked. It seems when running in the PKG the restart gets not invoked.

[ahousseini]

Any news on this?

[mpanighetti]

Is this possibly a TCC issue? The script's osascript actions may require user approval, and if it was denied (or the alert timed out) the first time said approval was requested, you'd no longer see a prompt and the system would instead silently skip those commands. The restart/shutdown steps are the only instances of osascript in the whole script, so it wouldn't cause issues earlier in the sequence.

Recommend resetting your TCC approvals/denials on your test systems by running:

tccutil reset All

After that's done, restart the Mac, try enforcing an update, and see if you get an approval prompt during the final steps of the script.

[mpanighetti]

I think I've sorted out this issue. The clean_up function was too aggressive and was unloading the main LaunchDaemon, which killed the script and prevented it from getting to the restart phase. Just put in PR #37 to fix this; I'll merge once I've confirmed it's working on my test VM.

[mpanighetti]

Fix worked! I've merged the change and released as version 2.3.4. @spmindel @Gregzy1987 @ahousseini please give the latest build a try and let me know if it's working any better for you.

[mpanighetti]

I've received independent confirmation that the restart behavior is restored with this fix, closing out this issue as resolved.