Looks like a bug based on the man page for runscrit:
If the given command or script is successfully executed on all named
hosts then these programs will exit with a status of 0. If an error
occurs or if and given command or script exits with a non zero status,
then these programs will exit with a non-zero status.
A quick workaround would be to have the script being called (checkNetHSM) echo the error code and have the runscript interpret the return code.
What version of the client are you using? Is it 6.3.1?
Everything is 220.127.116.11
Can you suggest how we get the suggested workaround to work?
Note we are calling a type1 script from a type2 script.
This is because we need to run a single blcli command immediately after running a korn shell script on multiple agents. If we put them both in a type1 script, then the blcli command runs on each agent and takes the job from 10 seconds to around 6 minutes.
Here is a quick work-around.
In the script being called, (checkNetHSM.nsh) put in an echo statement right before any exit call.
Something like this in checkNetHSM.nsh:
#Error happens here
echo BladeLogicReturnCode 1
#normal exit code
echo BladeLogicReturnCode 0
And then the call can grep & cut the return code:
runscript -h $1 -p 50 -e /usr/nsh/storage/scripts/checkNetHSM.nsh | grep BladeLogicReturnCode | cut -f2 -d' '
I've added the following code to the type1 script, immediately after the nexec line.
echo BladeLogicReturnCode $RC
I've then added the suggested grep and cut commands to the runscript command in the type2 script that calls the type1 script, but this just blocks all the stdout from the nexec, and prints the return code from each target server on stdout instead.
I don't want to affect the stdout from the nexec command in the type1 script.
If you need to keep the output as well, you can redirect to a file, grep the return code and cat the file for the original output.
#run the script, send output to /tmp/file (could use tee here)
runscript -h $1 -p 50 -e /usr/nsh/storage/scripts/checkNetHSM.nsh > /tmp/file
#get the return code
VALUE=`grep BladeLogicReturnCode < /tmp/file | cut -f2 -d' '`
echo Return code is $VALUE
#Print the results as normal, remove grep -v if you want BladeLogicReturnCode
cat /tmp/file | grep -v BladeLogicReturnCode
This looks like it would work, but Richard has gone home now and I have no access to CM.
I will try it tomorrow and let you know.
In case this doesn't work; can anybody think of any alternatives to using runscript that don't involve having two jobs?
I'm not convinced.
Surely this is just going to display the return code for each target in the stdout at the job level in the 'show log' window.
It's not going to update the green tick/red cross that indicates a zero/non-zero return code.
Or am I missing something?
OK - we've found a solution.
I noticed that the type1 script always had a line in stdout saying 'Exit Code ??'
The type2 script using runscript didn't have this.
My theory was that the GUI uses this line to work out the individual return codes and displays the correct Green Tick or Red Cross against the target in the Show Log screen.
To put the theory to the test, I modified my korn shell script on each of the target servers to output a line to stdout as 'Exit Code $RC'.
I then ran the type2 script detailed below and it worked.
It still works as a type1, but you just get two lines saying 'Exit Code ??' instead of one. So it appears that the bug in runscript is that it doesn't append the 'Exit Code' text to the target server output.
runcmd -h $1 -p 50 -NH -e nexec -e /usr/local/bin/mylocalscript.ksh
blcli -r Operations NSHScriptJob clearJobTargetList "/Job Folder" "Run my local korn shell script" >/dev/null
Note that this requires the %h macro setting up in the Parameters tab of the NSH script and that mylocalscript.ksh outputs the exact words 'Exit Code 0' or whatever your exit code is.
The alternative to modifying the korn shell script is to use runscript to call a type1 NSH script that echos the same words, but I think this is a little neater.
You're absolutely right. The code looks for this particular "Exit Code" output. Take a look at this knowledge base article: