Re: Connection Failing for unknown reason

This may not exactly be related to your problem, but I've recently had some experience on working with Net::SSH::Expect. I wanted to execute programs (which can be interactive) on multiple hosts via SSH and capture the output for each of them and used Net::SSH::Expect for this.

During the course noticed that there are some serious issues with how Net::SSH::Expect::read_all() determines termination of any command. It follows a logic of timeout duration of inactivity on the input stream - the command's STDOUT - to decide it's termination. Which can be highly misleading. I had to tweak some of Net::SSH::Expect's code to work around this.

Comment on Re: Connection Failing for unknown reason

Replies are listed 'Best First'.
Re^2: Connection Failing for unknown reason by sierpinski (Chaplain) on Aug 06, 2009 at 20:16 UTC
What did you end up tweaking? You don't have to go into great details, just a general idea I mean.... was it basically moving from a length of time to some other notation of inactivity? Thanks for the response!	[reply]
Re^3: Connection Failing for unknown reason by laminee (Novice) on Aug 06, 2009 at 20:36 UTC
It may not be a very wise solution but this is what I did: in case there is <timeout> duration of inactivity, establish a duplicate connection and check in the process table whether the concerned process is still executing. If yes, do not return from read_all() because my thinking was you have not really read all. And I am passing an extra optional max-timeout parameter to the Net::SSH::Expect::exec() which acts as a check in the loop in read_all() in case the command hangs or something. Update: The optional max-timeout parameter serves another purpose of circumventing a flaw in the inactivity logic of read_all(). What if a command keeps on printing stuff to its STDOUT indefinitely? The default read_all() will never return in such a case.	[reply]