Policy fails when running a verbose script

Haven't tried -v but i have several scripts with -x so I can see the script results, and that works just fine.

If the word "error" or "failure" appears anywhere in the text returned by the command/script, Casper will flag the policy as failed, is that the case?

Not sure what words all trigger that, but it's not just exit codes that trigger the failure. If the script contains those words and you are echoing the whole script out, that would do it.

What alexjdale said. It has been fixed in one of the later versions tho...9.3?

I'm on 9.23 and it's not fixed, but I thought it was a feature. :-)

I just noticed that even when I had the word failure in a script comment the policy would return a failed status.

Try piping output to /dev/null:

command > /dev/null 2>&1

@andyinindy In my case I just changed the text of my commented line. Would piping the output to /dev/null also block reporting of legitimate failures?

@tomt][/url][/url: good question. You can gather the exit status of a command even if you redirect output to /dev/null using "$?":

command > /dev/null 2>&1

# store exit status command
# if successful, command will return 0 exit status
# if not successful, command will return a nonzero exit status
status=$?

You can then build conditionals to act upon the "$?":

if test $status -eq 0
then
echo "no error"
else
echo "error"
fi

Hope this is helpful.

--Andy

To add to what @andyinindy just pointed out, I use this method for logic checks from time to time. Mainly to test for something, and more specifically its exit status.

To use the JAMF binary has an example, if you type this in terminal:

jamf help ; echo $?

You will get a lot of output, because first you will get all the output of the help menu in the JAMF binary, and last you will get the exit status. Exit status of 0 means it was successful, anything else means there was an error. So, using the JAMF binary as yet another exmaple:

bash-3.2$ jamf help 2>&1 > /dev/null ; echo $?
0

A lot of times you can use awk/grep to test if something is present, and if the patter/string doesn't match the binary will spit out an exit status other than 0. A lot of times if logic test fail, it will show the script as failing. I have seen it where a script is trying to read a file that isn't there yet. Most of the time it is when an App dynamically creates files at first launch, and the script is looking for files that aren't there yet. Obviously the script fails to find the file, or modify/read the file and it spits up an error.

Can you post example code of the set -v output in your scripts?

Cheers,
Tom

Another option is to redirect verbose output to a file for analysis, rather then writing to the Policy Log (we have 40,000 clients, so policy log writes are perhaps more of a concern for us than others).

All of my policy scripts have the following code block (path names edited for confidentiality):

DebugOn=0
if [[ "$DebugOn" = 1 ]]; then
    set -x
    exec > >(tee '/Library/Logs/Organization/Debug.txt')
    exec 2>&1
fi

Then if I want to analyze the output, I just have to change a single line to toggle if I want to capture "verbose" output.

ProTip, instead of defining DebugOn in the script, you could go further and use one of the default field definitions in the JSS to handle this (we don't because we often use those variables for other things). An example of that code would look like:

if [[ "$4" = 1 ]]; then
    set -x
    exec > >(tee '/Library/Logs/Organization/Debug.txt')
    exec 2>&1
fi

Then you just have to change the $4 field definition on the JSS entry for the script to toggle on and off.