Is there a way to capture exit codes of applications that are executed via action script? I want to be able to have a task report as failed if it returns an error code other than 0. Also, it would be nice if I could somehow write the error code into a variable to do some flow control based on the code. Are either of these things possible? Thanks.
The short answer is that this is not easy (although you could write out the exit code to a file or reg key or something and then retrieve the info, but that isn’t really a very streamlined process)… but we have heard this request before and our current plans will be to add it to the next major BigFix version.
Thanks for the response Ben. I had thought about piping the exit code to a text file, but agree that it is somewhat messy. This will be a welcome feature and I look forward to being able to utilize it in a future version.
^ They have been exposed for a while, but I haven’t seen a way to use them yet. There is another thread in the “Feature Requests” forum where it is hinted at that it may be an included feature in BES8. I know it would make things easier for me and a lot of other folks.
But I can’t find any examples for how to use them searching “exit code” or “exit codes” on the BigFix site. Not sure if there is an 8.x reference guide that has not yet been indexed…
I too need to use the exit code if at all possible. I’m trying to use portqry.exe to determine if port 445 is available on a server before running a setup directly from a UNC path (available to domain computers). PortQry.exe (when run with the -q switch) provides an exit code of “0” for listening “1” for not listening, and “2” for listening or filtered" I’d like to either use these exit codes to CAUSE the action to fail, or be able to set a code with a script that could tell the action it has failed.
Currently I’m checking the output of portqry in a text file, but I still need to have a way to tell the action that it will not succeed.
Code if anyone is interested:
If
{exists files
"C:\windows\portqry.exe"
} delete
{pathname of parent folder of regapp
"BESClient.exe"
}\portqry.log waithidden cmd.exe /C portqry -n servernamehere -p tcp -e 445 >
"{pathname of parent folder of regapp "BESClient.exe
"}\portqry.log" If
{exists line whose (it contains
"TCP port 445" AND it contains
": LISTENING") of file
"portqry.log" of parent folder of regapp
"besclient.exe"
} run cmd /k echo
"Success code here!" Else run cmd /k echo
"Failure code here" EndIf EndIf
of 123 and the action will have a state of FAILED. The cmd run inside the Action script has a non-zero exit code.
wait cmd /c fake
if {exit code of action != 0}
exit 123
endif
This action will return with a
Action exit code
of 1 (it is passing up the exit code from the cmd command) but the action will have a state of COMPLETED. The cmd run inside the Action script has a non-zero exit code.
wait cmd /c fake
if {exit code of action = 0}
exit 123
endif
This action will return with a
Action exit code
of 0 and the action will have a state of COMPLETED. The cmd run inside the Action script has an exit code of zero.
wait cmd /c dir
if {exit code of action != 0}
exit 123
endif
Edit: fixed a mistake regarding the second example… I had originally wrote that the Action exit code was 0.
Does the Fixlet Debugger accurately mirror the way BES will initiate actions involving manipulated exit codes?
Any time I try to echo out (exit code of action) I continuously receive what looks like a random number, which would ALWAYS make {exit code of action = 0} false, and !=0} true
Manipulating the exit code with:
exit 123whatever
results in a client log that says:
Command succeeded (123) exit 123
Result —
Evaluation failed!
…but a runtime error on the “exit” line "an unknown error occurred. Which I would think means that anytime an exit code is manipulated in this way one would cause the entire action to fail.
Again, I don’t think I have a good handle on how to use error codes in BigFix yet, so I may be mis-interpreting.
Code I’m using to demonstrate error code output:
Failure:
wait cmd /c fake run cmd /k echo
"Failure code: "
{(exit code of action)
}
Success:
wait cmd /c dir run cmd /k echo
"Success code: "
{(exit code of action)
}
In your third example:
wait cmd /c dir
if {exit code of action != 0}
exit 123
endif
The first line exits with Code=0 as seen in the Client Log yet {exit code of action} is not zero which makes the if/then true and the line exit 123 creates a runtime error.