paramiko

Client doesn't die after server session hang up

Bug #70081 reported by coldas57
6
Affects Status Importance Assigned to Milestone
paramiko
Invalid
Undecided
coldas57

Bug Description

If you have a shell client session opened, in idle state, and the server closes this session (IdleTimeout), when you try to launch a new command through the shell, the client does not return anymore.

You can test it opening a ssh shell session against an ssh server and afterwards kill that session and then try to send a command. The client hangs and does not return.

If you have a look into channel.py, you will see that Channel class in send method calls _wait_for_send_window(...) method, where it seems to be the problem.

I have solved, but I am not sure if it is the best solution, the problem modifying send method as stated below:

    def send(self, s):
        """
        Send data to the channel. Returns the number of bytes sent, or 0 if
        the channel stream is closed. Applications are responsible for
        checking that all data has been sent: if only some of the data was
        transmitted, the application needs to attempt delivery of the remaining
        data.

        @param s: data to send.
        @type s: str
        @return: number of bytes actually sent.
        @rtype: int

        @raise socket.timeout: if no data could be sent before the timeout set
            by L{settimeout}.
        """
        size = len(s)
        self.lock.acquire()
        try:
            if False == self.transport.is_active():
                raise SSHException('Transport session has been unexpectedly closed')
            size = self._wait_for_send_window(size)
            if size == 0:
                # eof or similar
                return 0
            m = Message()
            m.add_byte(chr(MSG_CHANNEL_DATA))
            m.add_int(self.remote_chanid)
            m.add_string(s[:size])
            self.transport._send_user_message(m)
        finally:
            self.lock.release()
        return size

I now check the transport session state before doing any channel operation. Could you have a look into this problem and propose a new workaround or fix, please?..or validate this one as the correct fix.

More data:

Client platform: WinXP, Python 2.3.5, paramiko 1.6.3 "xatu"
Server platform: Suse 9, OpenSSH_3.7.1p2, SSH protocols 1.5/2.0, OpenSSL 0.9.7b 10 Apr 2003
I kill the ssh server session before sending a new client command.

Thank you in advance for your assistance

See original description
coldas57 (coldas57)
description: updated
coldas57 (coldas57)
description: updated
Revision history for this message
Robey Pointer (robey) wrote : Re: [Bug 70081] Re: Client doesn't die after server session hang up

On 3 Nov 2006, at 8:11, coldas57 wrote:

> ** Description changed:
>
> If you have a shell client session opened, in idle state, and the
> server
> closes this session (IdleTimeout), when you try to launch a new
> command
> through the shell, the client does not return anymore.
>
> You can test it opening a ssh shell session against an ssh server
> and
> afterwards kill that session and then try to send a command. The
> client
> hangs and does not return.
>
> If you have a look into channel.py, you will see that Channel
> class in
> send method calls _wait_for_send_window(...) method, where it
> seems to
> be the problem.

I can't reproduce this on OSX by either closing the SSHClient or kill
-9'ing the sshd process. Could you give me a more specific way to
reproduce it?

Also, what does paramiko log when the server disconnects?

robey

Robey Pointer (robey)
Changed in paramiko:
assignee: nobody → coldas57
Revision history for this message
coldas57 (coldas57) wrote :

I am trying to open a shell session against a Suse 9 server. I can show you a sample.py that I have used to test it:

#! /usr/bin/python
import paramiko
import time

client = paramiko.SSHClient()
p = paramiko.MissingHostKeyPolicy()
client.set_missing_host_key_policy(p)
client.connect('myserver',22,'myuser','mypsswd')
chan = client.invoke_shell()

time.sleep(60)

In this period of time I obtain which ssh session is opened in the server by means of executing "ps -aux | grep shh |grep myuser", then I kill the client ssh session : kill pid obtained as you can see hereafter:

 root 29120 0.4 0.0 5032 1804 ? S 10:11 0:00 sshd: coldas@pts/3

When the period of time expires the script executes a command

chan.send('ls -la\n')

This command hangs and does not return. The paramiko's log disappears...I mean, its content disappears..it seems like a restart. I am executing the script from a winXp machine with python 2.3.5 installed.

Please, let me know if you need more data, please

Revision history for this message
Robey Pointer (robey) wrote :

i tried running your script on my laptop, using a linux box as the remote server, and i couldn't reproduce it. paramiko got "EOF in transport thread." and the script stopped.

the logfile disappearing makes it sound like some windows funkiness. can you repro this on a posix machine? (paramiko doesn't erase its logfile on shutdown, so you've got something else going there.)

attached is the script i used to test, in case that helps.

Robey Pointer (robey)
Changed in paramiko:
status: Unconfirmed → Needs Info
Revision history for this message
Andreas Moog (ampelbein) wrote : Closing this Bug

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

We are closing this bug report because it lacks the information we need
to investigate the problem, as described in the previous comments.
Please reopen it if you can give us the missing information, and don't
hesitate to submit bug reports in the future. To reopen the bug report
you can click on the current status, under the Status column, and change
the Status back to "New". Thanks again!

 status invalid
 subscribe

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAki1d2QACgkQ06FgkPZwicT/wgCeKG32hXCDUqLrGWoG8y0ZvEGw
/WYAnRzdVT9s2p2oR3uYW7L/V5UlH/O6
=XT5P
-----END PGP SIGNATURE-----

Changed in paramiko:
status: Incomplete → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.