Re^2: Connection Failing for unknown reason

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!

Comment on Re^2: Connection Failing for unknown reason

Replies are listed 'Best First'.
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]

Replies are listed 'Best First'.

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]