sshd fails to close open file descriptors when forking

[Nicolas Williams]

This is the SIGCHLD race condition that's been hashed to death already.

Nico


On Mon, Oct 22, 2001 at 01:04:52PM -0400, Ed Phillips wrote:
> On Mon, 22 Oct 2001, Lutz Jaenicke wrote:
> 
> > Date: Mon, 22 Oct 2001 17:22:46 +0200
> > From: Lutz Jaenicke <Lutz.Jaenicke at aet.TU-Cottbus.DE>
> > To: openssh-unix-dev at mindrot.org
> > Subject: Re: sshd fails to close open file descriptors when forking
> >
> > On Mon, Oct 22, 2001 at 11:03:26AM -0400, Ed Phillips wrote:
> > > But the child processes don't have the _same_ file descriptors open, do
> > > they?  I thought they had a pipe(s) back to the sshd for protocol
> > > encoding/decoding.  Regardless, all the children need to exit _before_
> > > sshd exits, and when they do, all of the file descriptors will be closed.
> > > When sshd exits, there should be no open file descriptors, right?  (And if
> > > sshd exits when there is a process that has a file descriptor open that is
> > > a "connection" back to the ssh client, then that's a bug, right?) Am I
> > > missing some key point here?  It seems simple... ;-)
> >
> > We are talking different issues here.
> > * sshd daemonizes on startup. In this case it forks and the child process
> >   (to become the actual server) closes its fds for stdin, stdout, stderr.
> > * When a new connection comes in, a sshd child process is created, that
> >   itself will fork()/exec() the user process, normally a shell.
> >   There are file descriptors for the network connection (channel) and for the
> >   user process. Typically the 3 default file descriptors for stdin, stdout,
> >   stderr are open between sshd and user process, but there may be more
> >   open files when X11 connections or port forwarding is used.
> > * When the user process dies, it closes all of its file descriptors.
> >   sshd notes this closure and also closes all file descriptors. On the
> >   network side the connection is however not simply closed, but a
> >   handshake specified in the SSH protocol is performed to have the
> >   encrypted _channel_ closed down before the underlying network
> >   connection is closed. Then sshd can exit().
> 
> Okay... that makes sense.
> 
> >   The often experienced "hang on exit()" problem is caused by processes
> >   started from the main user process. If at shell level a process is
> >   started with, say "sleep 20000 &", the sleep process may not close
> >   its file descriptors (stdin, stdout, stderr), which are identical to
> >   the shell's descriptors. Even when the shell now exits, sleep keeps the
> >   file descriptors open and therefore the handling sshd process thinks,
> >   that data may still be exchanged and does not shut down.
> >   (Of course, sleep won't exchange data, but there may be other more important
> >   processes be backgrounded.)
> 
> The problem I see is that there _are_ no background processes and no file
> descriptors left open (there aren't even any processes running on the sshd
> side)... but still, ssh hangs on the client side - even though there are
> no sockets left on the server side.  Maybe this is a problem with the
> protocol implementation in v2.9p2, or maybe it's a problem where ssh
> doesn't "know" that the file descriptors are gone (TCP sockets without
> keep-alive, client doesn't realize that the count of valid file
> descriptors is < 1, etc.).
> 
> Hopefully, I'll be able to tell if this is fixed in v2.9.9p2... sometime
> today...
> 
> Thanks,
> 
> 	Ed
> 
> Ed Phillips <ed at udel.edu> University of Delaware (302) 831-6082
> Systems Programmer III, Network and Systems Services
> finger -l ed at polycut.nss.udel.edu for PGP public key
--

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.