Skip to main content
Question

Policy fails when running a verbose script


Forum|alt.badge.img+3

I have a policy that is running a shell script using "#!/bin/sh -v", which prints the contents of the script to the log for debug/testing purposes. Regardless of whether or not the -v option is there, the logs show that the script returns an exit code of 0, but the policy fails after running the script when -v option is present. Is anyone aware of a bug that could be related to this?

10 replies

Forum|alt.badge.img+5

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


Forum|alt.badge.img+17
  • Contributor
  • 881 replies
  • July 24, 2014

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.


Forum|alt.badge.img+10
  • Valued Contributor
  • 159 replies
  • July 24, 2014

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


Forum|alt.badge.img+17
  • Contributor
  • 881 replies
  • July 24, 2014

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


Forum|alt.badge.img+12
  • Valued Contributor
  • 350 replies
  • September 2, 2014

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


Forum|alt.badge.img+18
  • Valued Contributor
  • 238 replies
  • September 2, 2014

Try piping output to /dev/null:

command > /dev/null 2>&1

Forum|alt.badge.img+12
  • Valued Contributor
  • 350 replies
  • September 2, 2014

@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?


Forum|alt.badge.img+18
  • Valued Contributor
  • 238 replies
  • September 3, 2014

@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


Forum|alt.badge.img+31
  • Honored Contributor
  • 2721 replies
  • September 5, 2014

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


Forum|alt.badge.img+8
  • Contributor
  • 41 replies
  • September 5, 2014

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.


Reply


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings