Skip to main content

Hey guys,



just wondering if anyone else seen an issue here before creating a support ticket.
We use a script with jamfhelper to create a message box when a user logs out. For example, $3 could be "Adobe Reader" and $4 "will be updated" Here's a snippet: 



APPTITLE=$4

MESSAGE=$5

/Library/Application Support/JAMF/bin/jamfHelper.app/Contents/MacOS/jamfHelper 

    -windowType hud 

    -iconSize 96 

    -heading "Please do not turn off your Mac! " 

    -icon /System/Library/CoreServices/Software Update.app/Contents/Resources/SoftwareUpdate.icns 

    -startlaunchd 

    -lockHUD 

    -description "${APPTITLE} ${MESSAGE}. The installation may take several minutes to complete.



Do not turn off your Mac until this message disappears." &



# Get the PID of the message box and write it in the informations.plist

defaults write /Library/Management/informations.plist LastUpdatePID -int $!

exit 0


The "&" after the jamfHelper message puts the process in the background so that the script would finish and the package install begins.
The script is set to "Before". After installing a package I'm executing the following command:



kill $(sudo defaults read /Library/Management/informations.plist LastUpdatePID)


and the message box will disappear.
This worked like a charm prior to 9.62 (I haven't tested this in 9.61 and 9.6). Has anyone a similar script in his environment and seeing an issue here with 9.62 too?
Manually executing the script works as expected, only see this issue when executing via the JSS.



Thanks,
Michael



Edit: perhaps these two issues are a little bit similar...
https://jamfnation.jamfsoftware.com/discussion.html?id=12766

We're encountering this issue as well. I'll report here if I discover a fix.

I did a lot of digging into this. I put the jamfhelper message in a subshell (and a sub-subshell too...), no change on that.
I tried nohup and bg. But whatever changed in the script, nothing changed in the fault behaviour.
Interesting is, that the scripts JAMF uses for creating the "Checking for Policies..." at logout are using the same "&" at the end.
There was even a call with JAMF, but no sulution yet.

We are also seeing this, but haven't had time to troubleshoot. Casper 9.62 and JSS running on OS X 10.9.

YES. I was going nuts wondering what happened over Christmas break. I've only been able to mitigate by omitting -lockHUD so the window can be closed and the policy will continue...

We worked with JAMF to develop a LaunchDaemon that spawns the jamfHelper process, thus preventing the policy from getting "stuck." It's not a true solution, but it's a good enough workaround for us right now.

Elliot - can you post what you came up with? I'd love for my 200+ macs to be able to run updates... AND for my weekend to begin already! :D



EDIT: Although since YOUR weekend might have begun already I'll put in a ticket with support.

Here are the relevant bits:



1) A policy installs this com.jamfnation.jamfhelper-helper.plist file into /Library/LaunchDaemons:



<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

<plist version="1.0">

    <dict>

        <key>Label</key>

        <string>com.jamfnation.jamfhelper-helper</string>

        <key>Program</key>

        <string>/tmp/jamfhelper-helper.sh</string>

        <key>KeepAlive</key>

        <true/>

    </dict>

</plist>


2) The same policy also installs this jamfhelper-helper.sh file into /tmp:



/Library/Application Support/JAMF/bin/jamfHelper.app/Contents/MacOS/jamfHelper 

-windowType "hud" -lockHUD -windowPosition "ur" -icon "/path/to/your/logo.png" 

-heading "Restart required" -description "In order to enable encryption, your computer needs to restart. Please save your work, quit open apps, and choose Restart from the Apple menu."


3) The same policy also runs (not installs) the following "kickoff" script:



launchctl load /Library/LaunchDaemons/com.jamfnation.jamfhelper-helper.plist


The effect of all this is the same as it used to be when you'd call jamfHelper [...] -startlaunchd &



Our policy is intended to politely prompt people to restart without actually forcing it. Thus, we place our script into /tmp so that it's automatically deleted upon restart and can't be called upon again. A separate policy goes through and cleans up the remaining LaunchDaemon upon restart.

@elliotjordan Hey thanks, I'll have to modify this a bit -- I call jamfHelper in policies as a BEFORE script with the message in parameter $4. It gives users feedback for policies running at logout so they don't hard power off their machines thinking they are frozen. I'll have to have the script pass the parameter in some way to the helper script... and then see if unloading the plist is necessary for each successive use of the helper script ... oy! Come on 9.64 :]



Thanks again!

Another workaround for that. Not as nice as the jamfhelper one, but it works.



Edit:
never mind, doesn't work either...

Hi everyone,



I believe this is being looked under D-008244, highlight it to your rep as important as for us it's preventing us from upgrading from 9.6 as we also display a message at logout for patching before updates get applied which is now paused until the message is closed down. I hope they address this in 9.64.

Doesn't look like 9.64 has fixed this....

omg... waiting for the next release begins.... :/

Apparently on the list for fixing in 9.66 I am told...

From the Casper 9.7 release notes:



‚ D-008244 Fixed an issue that prevented a policy from running the JAMF Helper as a background process using a script with a command followed by an ampersand (&).

It took 9.7.2 for our multiple issues to clear up - including this one. At this point, 9.7.2 has been the best release for us since implementing Casper 3 years ago.

Terms & ConditionsCookie settings