1. I did confirm it is a Broken Pipe condition. When started with the ./test.nsh &, I get the following response
+ Broken pipe /tmp/test.nsh
2. Also, I saw some references to adding 'cd //@;disconnect' to the script to assist with broken pipe conditions, that did not help.
According to the man pages for NSH, it may be related to the default time-outs for the RSCD Agents:
The following is from the 'remote_cmds' option, but I assume the implications are the same.
"... The max_time field represents the maximum time
in seconds that the remote command should need to execute. The default
value is 300 seconds (5 minutes). Adjust this value if you anticipate that
the remote command might take longer than 300 seconds to execute. If the
remote command does not finish after the maximum allocated time, the shell
assumes an error has occured [sic] and the command is aborted."
Is this 'max_time' a configurable item (either command-line or agent-level)?
what is the value of the 'appserviceurl' setting on your appservers?
this setting should not affect blcli connections. blcli connects to the appserver, not agents.
Thanks for the response Bill.
My appserviceurl is a load-balanced VIP (service:appsvc.bladelogic:blsess://bladelogic.xxxx.com:9841).
I did wonder if that might be an issue, so I tried making my Authentication Profile directly to the server itself. My assumption was that the TCP flow would be the same as my authentication, but as I am typing this - I realize that may be a flawed assumption.
Bill... I think that's my problem.
After reading your post, I changed the local /etc/host file entry on my appserver (where I was running blcli and my BSA Application server to change the appserviceurl host from the VIP to the local machine, and it is working.
That's good news. Now, I will work with support to ensure that I dont have something misconfigured or if I need to focus on an environment issue with our load-balancer/VIP.
Thanks Bill... really appreciate the pointer.... I at least have a work around that can get me past my "go live" date. We are only using the VIP for HA - not for load demand.
i'm pretty sure the issue is on the vip - there's probably a session timeout setting or something that is closing out the connection. or possibly there is some issue w/ a server behind a vip connecting to the same vip. the /etc/hosts fix is what a few of our customers have done that have a similar setup.