Possible Defect with Scripts & Recurring Triggers?

[skoonin]

I've noticed that some scripts have a tendency to fail when run via a policy that uses a recurring trigger. If the policy is triggered manually, the script works though.

So
Script A in policy A with recurring trigger : fails
Script A in in policy A run with a manual trigger : runs as expected

Then create a second policy (policy B) with just Script A and a manual trigger
If you put the jamf policy -trigger X in the Files & Processes part of Policy A to call Policy B: Script A runs as expected
If you create a new script to call Policy B manually and put that script into Policy A: Script A fails

Anyone else run into this behavior? Seems like it is a defect in JSS. I am on 9.72.

Thanks, sk

ps: apologies for poor formatting

[alexjdale]

Fails how? I haven't seen this behavior.

[Look]

I have a couple of scripts runnning on the recurring trigger, haven't noticed any issues, as @alexjdale says what are the logs showing?

[skoonin]

@Look to be more clear, the script fails intermittently when run as a recurring trigger, but not when run manually (via jamf command) or locally in terminal/ssh.

This was also discussed HERE

This doesn't happen with ALL our scripts, just some for some reason I can't ascertain. The Logs tend to have different values depending on the syntax of the script. At this point, I've removed most of the ones that fail. The most problematic one I have is a script that force quits all apps. It runs fine locally and via manual trigger, but intermittently fails on recurring trigger. It error's out with a couple different things.

Script exit code: 1
Script result: 66:73: syntax error: Expected class name but found identifier. (-2741)
Script result: 52:132: execution error: An error of type -10810 has occurred. (-10810)

[mm2270]

@skoonin It sounds like the issue is that some of the scripts failing are trying to do some user interactive commands, like Applescript stuff maybe? The "error of type -10810" is often attributed to the OS blocking user interactive elements, like Applescript dialogs or commands that need to run as the user. When run from a recurring trigger policy, these commands in the script get run as "root" and the OS does not allow them to effect the logged in user. or run them "as" the user. However, when you run them manually (the scripts) in Terminal or when you manually call the policy, they get run as the logged in user, which is why they work that way. That's the main difference and would be the reason they intermittently fail when they get run naturally from the jamf LaunchDaemon.

Since you did not post examples of the scripts you're seeing this issue with, this is all speculation, but I'd be willing to bet that is the root of the problem.

[Look]

Without knowing what the script is trying to do it is also worth noting that if your trying to generate user interactions and there are no logged in users you might also generate errors.

[skoonin]

thanks for the feedback. that definitely makes sense that it is trying to do user specific commands, but what is strange is that it is running on computers with a logged in user (these are macmini's that autologin). The logged in user is not an admin however (and also has a blank pwd), would that have an impact? This would potentially explain other scripts too. I did upvote a feature request to allow policies to be run as logged in users!

note: this script was pulled from the Automator task that does this via ARD.

The script I am using is here:

#!/bin/bash

case "`uname -r`" in
7*) osascript -e 'tell application "System Events"
    set visible of every process to true
    set these_apps to name of every process whose visible is true and file type is not "FNDR"
    if these_apps is {} then return 
end tell
set aQuote to """
set the app_list to ""
set the item_count to the count of these_apps
repeat with i from 1 to the item_count
    set this_item to item i of these_apps
    if i is 1 then
        set the app_list to aQuote & this_item & aQuote
    else
        set the app_list to the app_list & space & aQuote & this_item & aQuote
    end if
end repeat
do shell script "killall " & app_list' ;;
*) osascript -e 'tell application "System Events"
    set these_apps to name of every process whose background only is false and file type is not "FNDR"
    if these_apps is {} then return 
end tell
set aQuote to """
set the app_list to ""
set the item_count to the count of these_apps
repeat with i from 1 to the item_count
    set this_item to item i of these_apps
    if i is 1 then
        set the app_list to aQuote & this_item & aQuote
    else
        set the app_list to the app_list & space & aQuote & this_item & aQuote
    end if
end repeat
do shell script "killall " & app_list' ;;
esac

[Look]

Maybe wrap the whole thing inside an if state whether there is a valid owner of /dev/console

if [ "$(ls -l /dev/console | awk '{ print $3 }')" ]; then
THE REST OF THE SCRIPT 
else
echo No user detected
fi

[mm2270]

Actually you'd need to check to see if the owner of console is not specifically "root" When a Mac is sitting at the login screen, root owns the console.
But that may help. It sounds like the ones its working on when it runs normally via the LaunchDaemon are the Macs that are already logged in, but even so, some of the stuff in the script isn't going to work correctly unless done in the user context. For example, I've had a lot of trouble getting back a valid list of running apps in the past by using stuff like set these_apps to name of every process whose visible is true in osascript commands. If run by root, it will return nothing. That has to run as the user who's logged in in my experience.

So even accounting for a logged in user just may not be enough in this case.

[sean]

Would this not be better served as a LaunchAgent with a 'start interval'?

launchd

[skoonin]

thanks for all the feedback guys! I agree that it is seems like it is somehow related to the script being run as root even though a user is logged in. However, in that regard, it doesn't seem to make sense that this script fails on only some machines and not others. They are all uniformly logged in to a non-admin user and are not asleep when the script is run. Why would it run on some and not others?

(for context, these are macmini's attached to smartboards).