Skip to main content
Solved

Need bug confirmation. Please assist.

  • July 9, 2014
  • 4 replies
  • 36 views
M
Forum|alt.badge.img+9
  • MrP
  • Valued Contributor

If someone has a moment can you please run the following script via policy and confirm casper see's it as a failure. I've tried for days to explain to support that this is a bug in their log parsing but they will not listen and are now suggesting I have their team write me a script for a fee. I'm about ready to start pulling my hair out. Since I can't seem to get them to help I'd at least like someone here to back me up on what I am seeing.

The following simulates the output of my script and in my testing, provides the same 'failure' result in the target system's JSS logs.

echo "Script result: ---> Computing dependencies for watch ---> Cleaning watch ---> Scanning binaries for linking errors ---> No broken files found."
exit 0

Best answer by mm2270

Casper Suite sees the word "error" or "errors" etc in any output as an indication that something failed and sets it as a failure. Whether you consider that a "bug" kind of depends on your viewpoint. JAMF designed it to work that way, but it has been pointed out to JAMF many times that this behavior is poor design. This is a case in point. Your script above has the word "errors" in it as it checks for errors, which is why its flagging it as "failed"

I believe that JAMF is changing this behavior in a future version of Casper Suite. At least it has been mentioned in the release notes now for many versions of 9.x that this behavior will go away in favor of actually checking the exit result instead. But right now to my knowledge it still does it. You may want to ask support if they know of any way to disable this functionally. Or. rewrite your script so it doesn't explicitly use the term "error" anywhere.

I once wrote a script that also had to check for errors and I ultimately had to work around this by using a word like e_r_r_o_r instead to stop the jamf binary from thinking it failed. :-/

    4 replies

    mm2270
    Forum|alt.badge.img+24
    • mm2270
    • Legendary Contributor
    • Answer
    • July 9, 2014

    Casper Suite sees the word "error" or "errors" etc in any output as an indication that something failed and sets it as a failure. Whether you consider that a "bug" kind of depends on your viewpoint. JAMF designed it to work that way, but it has been pointed out to JAMF many times that this behavior is poor design. This is a case in point. Your script above has the word "errors" in it as it checks for errors, which is why its flagging it as "failed"

    I believe that JAMF is changing this behavior in a future version of Casper Suite. At least it has been mentioned in the release notes now for many versions of 9.x that this behavior will go away in favor of actually checking the exit result instead. But right now to my knowledge it still does it. You may want to ask support if they know of any way to disable this functionally. Or. rewrite your script so it doesn't explicitly use the term "error" anywhere.

    I once wrote a script that also had to check for errors and I ultimately had to work around this by using a word like e_r_r_o_r instead to stop the jamf binary from thinking it failed. :-/

    M
    Forum|alt.badge.img+9
    • MrP
    • Author
    • Valued Contributor
    • July 9, 2014
    Casper Suite sees the word "error" or "errors" etc in any output as an indication that something failed and sets it as a failure. Whether you consider that a "bug" kind of depends on your viewpoint.

    That was my assumption and asserted that with support and received no acknowledgement of such. I have adjusted the real script to write the results to null but store the exit code of the command into a variable, then to "exit 1" if the variable indicated a value. It works to show a proper success/fail status, however I also cannot see what happened if it did fail. I know some things output the word "error" and the JSS doesn't get triggered by them so my assumption is that there is a list of exceptions, likely regex based. Anyway, once again I suggested this to support and got nothing back but "send us more logs". I suggested they run the echo command in a script to reproduce. then check their own logs only to be told my script needs to be written by their professional team..........

    Any who, thanks for confirming my diagnosis.

    M
    Forum|alt.badge.img+9
    • MrP
    • Author
    • Valued Contributor
    • July 9, 2014
    I once wrote a script that also had to check for errors and I ultimately had to work around this by using a word like e_r_r_o_r instead to stop the jamf binary from thinking it failed. :-/

    Good thinking. Unfortunately the text reported is from the Macports 'port' command. I have no control over what it says; short of adjusting the code and compiling from scratch, or perhaps editing it with a hex editor. I'd like to avoid either ;)

    A
    Forum|alt.badge.img+17
    • admin13
    • Contributor
    • July 9, 2014

    @Dickson

    @mm2270 summed it up more quickly than I was able to get to it.

    We did have an old defect opened for the behavior in the 8 series, and I'm going to look into getting a new one open for the 9 series until we get that behavior change implemented, as it does tend to make people want to tear their hair out when it reports as failed but we can go and see that the script actually completed successfully.

    Just for reference, this is what @mm2270 is referring to in the answer above:

    From the release notes of 9.32:

    The following functionality has been deprecated: ? Policy status determined by checking script output for “error” and “fail”—Historically, one of the ways the JSS has determined the status of a policy is by checking script output for the words “error” and “fail”. As of v9.0, the JSS also uses exit codes to determine the status of a policy. This method is more reliable and accurate. Although the JSS v9.32 still checks script output for the words “error” or “fail”, this will be removed in a future version. If you have written scripts that utilize this feature, consider implementing an alternative solution using exit codes as soon as possible.

    Thanks!

    Amanda Wulff
    JAMF Software Support

    Terms & ConditionsCookie settingsAccessibility statement