so-called-hang-on-exit

[Michael Robinton]

>Fair enough on the flushing of the pty. But sshd should still not close
>the pty - it should wait for the background processes to exit and/or
>dissassociate from the pty.
>
>The client does know that there are background processes left still
>holding the pty open. How? Because the client requested and got a pty,
>the sshd has sent a session-exit message, and the channel is still open.
>
>Cheers,
>
>Nico --

This is an oversimplification of the problem and what I consider to be the
main reason why the problem has not been fixed. Consider the situation
where a sysadm needs to log into a host, kill and restart a daemon.
Naturally the daemon has not been properly written through no fault of the
sysadmin who is merely and innocent victim of the ssh server. Upon logout
the terminal window hangs.... duh!!!! Again I ask, why should we be held
hostage to poorly written daemons just so you purists can say that not a
single byte of data has been lost that might someday be attempted to be
sent to pty connection that is trying desperately to disconnect???

The argument will not go away until some one fixes this BUG. Your argument
that the "client knows" is simplistic. Sure, we know that people write
buggy software and buggy daemons that do not properly redirect their
STDOUT and STDERR. That does not meant that we should
accomodate their stupidity and hang our own systems up because of it. At
the very least, make it a server configuration option that connections
will be closed unconditionally if requested by the client to do so. This
way we can rid our systems of hung sshd processes that fill up the process
table.

Michael


> -----Original Message-----
> From: Jani Jaakkola [mailto:jjaakkol at cs.Helsinki.FI]
> Sent: Monday, August 05, 2002 4:20 PM
> To: Williams, Nicolas
> Cc: openssh-unix-dev at mindrot.org
> Subject: RE: so-called-hang-on-exit
>
>
> On Mon, 5 Aug 2002 Nicolas.Williams at ubsw.com wrote:
>
> >
> > I still think this sort of thing should be done by the client.
> >
> > The client knows everything that the server knows.
>
> Except this time is does not. If there is background
> processses on the
> tty, the client can either close the session and lose data or wait
> indefinetely for data from the background processes.
>
> > So the client
> > can choose to terminate the SSHv2 session when the PTY session
> > process leader exits - and it can implement any other termination
> > heuristic you wish too.
>
> It needs server modifications that data from the pty session process
> leaders is not lost. I think rlogin and all other pty using
> programs have
> allready implemented this properly; which is that the pty buffer is
> first emptied and the connection is closed _after_ that.
>
> - Jani
>
>