1 of 1 people found this helpful
I would open a ticket w/ support for this – the cd command in theory should function like the other commands so this could be a defect. also share the ticket #..
The idle timeout is on some network device between your appserver and target.
There’s a client_keepalive_time but for now there’s an issue w/ that setting on windows (unix should be fine)
Thanks Bill. You are the person I was hoping you would reply. Will raise support ticket as suggested.
I've appended "client_keepalive_time" to secure file on my Windows PC. You mentioned their is some issue with it but if it works great!
There’s an issue where file descriptors will be left open and not closed. It may not cause an issue on your pc, but on a windows appserver that’s communicating w/ many targets they will add up and affect the system.
Heads up for others with this issue...
I was hoping setting "client_keepalive_time=" in secure file on my Windows PC would prevent occurrence of (Error on socket: 'Connection reset by peer') event for 'cd' command after a period of NSH inactivity. Unfortunately this has not helped (even when set to 60 seconds) thus hopes now rest in BMC producing a fix for this behaviour.
try a lower time than 60 ? also, are you connecting directly to a target or through a nsh proxy ?
We do use Network Proxies to connect to target servers. Separate to that we have all BSA application servers sitting together on their own subnet and VLAN. When I 'NSH Here' to these BSA Configuration Application Servers and to Job/NSH Proxy servers I still get SSL_write (Error on socket: 'Connection reset by peer'). It would make sense to me that communication between these BSA application servers is direct thus the use (or not) of NSH_Proxy/Socks_Proxy isn't related to root cause.
P.S. I have set client_keepalive_time= from 60 to 5 seconds in C:\Windows\rsc\secure file but it has not helped.
UPDATE: Reading “C:\Program Files\BMC Software\BladeLogic\NSH\man\txt1\nsh.txt” I note max_time field is set to default value of 300 seconds (5 minutes). That matches the timeout I am seeing. I tried setting "cd - 1000000000" in "C:\Program Files\BMC Software\BladeLogic\NSH\share\remote_cmds" but unfortunately the problem continues.
Presumably somewhere in "C:\Program Files\BMC Software\BladeLogic\NSH\..." is an option to set the timeout for "NSH Here" from 300 seconds (5 minutes) to something much longer. Does anyone know how to set that?
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)
If the remote command does not finish after the maximum
allocated time, the shell assumes an error has occured and the command
I’m not sure if that’s what you want. the client_keepalive_time should keep any nsh connection alive. It’s possible there is some issue w/ just the cd command.
I agree that "max_time" field in "C:\Program Files\BMC Software\BladeLogic\NSH\share\remote_cmds" is probably not the right area to focus on. However it did clue me in that 'NSH Here' has a default idle timeout of 300 seconds and the solution is likely at the 'BMC Automation Console end' on my PC. It makes sense that "client_keepalive_time" should keep my nsh connection alive but given it fails to do so...I wonder what the command actually does.
This fault should be easy to replicate for any BMC employee with access to a BSA lab.
Step 1. Make an 'NSH Here' connection to a remote target. Check "cd" command works (which it will).
Step 2. Let the NSH connection idle for 300+ seconds. Run "cd" command again and watch it fail.
Step 3. Add "client_keepalive_time" setting to secure file with a value <300 seconds. Retest and watch it make no difference.
Step 4. BMC advise how to extend default idle timeout on NSH shell to a value >300 seconds.
Step 5. BMC fix 'cd' command so that it recovers after a (Error on socket: 'Connection reset by peer') event.
Fingers crossed on a solution to above
yes, that's what support should be working on right now.
Support have just raised this as Defect QM001888997 which is targeted for BSA 8.8.
is there any news for this issue? Error? or we must wate of the 8.8 version?
There is a defect for this - QM001888997 and it is fixed in 8.8.
OK, Thank you Bill!
it was a batchJob with some BlPackageJobs and NSHJobs...
Work around => I started manualy the Jobs separately and the result was fine.