On Wed, Mar 17, 2010 at 3:44 PM, Roman Yakovenko <roman.yakove...@gmail.com> wrote:
>> >> transport.is_active() should report the condition of the ssh transport >> correctly. >> >> If the remote host simply stops responding and doesn't close the connection >> properly, there's is no way to detect it without testing the connection. > > This is exactly what I tried to achieve - to find light method to > verify that the connection is alive. transport.is_active() doesn't > help in such situation. I verified this, when the remote virtual > machine was shutdown. Transport.active was "True" > This is because the tcp connection is half-open, which is a condition that the socket doesn't know about. You can continue to send data with no errors. > Initially, I thought about executing some useless command like 'echo > 1', but didn't like that idea, mainly for the performance reasons ( > not verified, just a feeling ). > > So I started to look for a "light" way and found "send_ignore" message. > >> >>> The Transport class has "send_ignore" method, but it does nothing with >>> the "send" result: doesn't propagate exception, doesn't update the >>> instance state. >> >> send_ignore is to create line noise, or keep tcp sessions alive. It's >> purposely ignored. > > Do you mean that remote side completely ignores this message and > doesn't send any message back? > Yes. It's designed to keep the network connection alive, not the ssh session. > > I am trying to execute a different set of commands against a host. > During the remote command execution( on the server side ), the client > side executes some logic that could raise an exception. This could > leave the channel in some "unknown" state. I mean the read buffer > could be full and the server still executes the command. I didn't find > a way to "reset" the channel, but to create a new one. Now, in case > the remote host closed the connection, my program was stalled in the > Transport.open_session function. I tried to play with > blocking/nonblocking/timeout option without success. > The only way to clear out the channel is to read the data out of it. The pipe may backed up all the way to the kernel tcp buffers, and calling recv on the socket is the only way to free them up without closing the socket entirely. Think of the channel just like you would a tcp socket. If the remote host closes the connection, transport.is_alive() will be False, and paramiko will raise an exception. In the case of the remote host becoming unresponsive (crash, network down), you will have to implement a timeout of some sort. -jim _______________________________________________ paramiko mailing list paramiko@lag.net http://www.lag.net/cgi-bin/mailman/listinfo/paramiko
