JAMFHelper from Check in hanging script.

[thoule]

I have a script that calls either/both Terminal-Notifier and jamfhelper. When running via SS or via command line (jamf policy -event workdammit) it works fine. But when called from 'check in' the Terminal-Notifier and jamfhelper lines hang. Looking at process viewer, I see they were called/running, but do not show on the workstation. It's like some security setting is keeping them from appearing. If I kill the jamfhelper process, then the script continues until next time it is called in my script. This only happens when called via Check-In. Anyone else run into this problem?

[jhalvorson]

Do you have different results when a user is logged in and when there are no logged in users? Or does your script include the logic to skip the notifier and jamfhelper if no users is logged in.

[thoule]

The script will not prompt if nobody is logged in. The script is here for reference. https://github.com/tmhoule/UpdateApps

[mm2270]

Hmm. The scripts I have that use terminal-notifier, I've had to call that using special launchctl bsexec functions since starting around 10.8+ the OSes more aggressive sandboxing. But I've never had the same issue with jamfHelper. Is the sequence you're doing them in jamfHelper first, then terminal-notifier, or the other way around?

[thoule]

I look for the existence of Terminal-Notifier (my recompiled version of it, actually). If it doesn't exist, it'll call jamfHelper. I'm doing another test now with a very simple script that is called by Check-In and only presents a jamfHelper box.

Here's the relevant hunk.

#### Routine to give feedback
notify(){
    loggedInUser=$( ls -l /dev/console | awk '{print $3}' )
    message="$1"

    if [[ "$loggedInUser" != "root" ]]; then    #display box only if someone logged in                                                                                                                

    #PEAS-Notifer is Todd's bastardized version of Terminal-Notifier app
    if [ -f "/Library/Application Support/JAMF/Partners/PEAS-Notifier.app/Contents/MacOS/PEAS-Notifier" ]; then
            /Library/Application Support/JAMF/Partners/PEAS-Notifier.app/Contents/MacOS/PEAS-Notifier -message "$message" -title "PEAS Updates"
        else
            /Library/Application Support/JAMF/bin/jamfHelper.app/Contents/MacOS/jamfHelper -windowType hud -windowPosition ll -title "PEAS Updates" -heading "PEAS Software Updates" -description "$message" -timeout 5
            sleep 1
            fi
    fi
}

[thoule]

Thanks, Mike. Looks like it's just terminal-notifier. It just surprised me that calling through Self Service it works fine, but not via Check In. JamfHelper does work as it should. I'll just pull terminal-notifier from my script until I get up the courage to use that bsexec function you mention.

[mm2270]

So, has this line:

/Library/Application Support/JAMF/Partners/PEAS-Notifier.app/Contents/MacOS/PEAS-Notifier -message "$message" -title "PEAS Updates"

always worked OK for you? Because my experience is that OS X will stop it from displaying a NC message unless the call to terminal-notifier is done as the logged in user. I'm wondering if that's why it works OK from SS. If I'm not mistaken Self Service runs some items as the logged in user, not root. But scripts run on check-in are always running in a root context.

[mm2270]

Ok, cool. Yeah, I had a feeling it was just getting stopped on the terminal-notifier call. As I said, I think SS runs things as the user, or at least some of it does, but not the case with the regular check-in trigger, which may account for the difference.

[thoule]

Yes, that line works great when called from Self Service, or via command line (jamf policy -event scriptWithNotifier) as root. Hence why I didn't notice it failing when called via Check In for a while. I suspect because they are both based as user initiated events, even when in a shell as root.