status of the hang-on-exit-bug

[Lutz Jaenicke]

On Tue, Oct 23, 2001 at 10:48:28AM -0500, mouring at etoh.eviladmin.org wrote:
> [..]
> > > unlike sshd both telnetd and rlogind exit on SIGCHLD. however, this
> > > is because they don't care about lost data. but ssh needs to care.
> > > rlogin does not. this is why ssh hangs and rlogin does not.
> >
> > what's the rationale for not using the rlogin behavior for interactive
> > sessions and rsh behavior for non-interactive sessions? (tty/notty)
> >
> 
> This has been talked about recently amoung the developers.  And we are
> still confused why OpenBSD does not result this this bug, but a large
> amount of the UNIXes do show it.  It would be nice if we could learn the
> 'why' and fix the underlying issue we could could.  However, no one seems
> to be able to provide such an answer.

While this may become a time consuming process, it should be manageable
since at least two OpenSource platforms with the behaviour in question
are available:
* OpenBSD not exhibiting the problem
* Linux having the "hang on exit" effect.
Therefore it is even possible to examine kernel source, if necessary.

As far as I understood the problem, sshd is waiting for the I/O fds
to be closed before actually closing the channel and exiting.
The effect occurs with background processes having the file descriptors
still open.
Questions:
- Is the problem consistent between shells? (Actually: are we looking for
  an operating system dependant problem? The discussion by now says, that
  it is an OS dependant problem.)
- What happens to the open files on exit of the shell?
  As on OpenBSD there is no "hang-on-exit" problem, it seems that the file
  descriptors are being closed immediatly (from the sshd's side of view).
  It should be the kernel performing the close.
  From the backgrounded process side of view: are the files also closed
  on exit of the shell? This would mean, that the backgrounded process
  would also experience an end-of-file condition (and a SIGPIPE on
  write). Should not be too hard to find out..
- Even more: on OpenBSD the connection is closed immediatly. Doesn't this
  mean, that output generated by the backgrounded processes after the
  close would be lost, thus violating the idea of keeping the channel
  open to prevent this data loss...

Just thinking on how to tackle the problem...

Best regards,
	Lutz
-- 
Lutz Jaenicke                             Lutz.Jaenicke at aet.TU-Cottbus.DE
BTU Cottbus               http://www.aet.TU-Cottbus.DE/personen/jaenicke/
Lehrstuhl Allgemeine Elektrotechnik                  Tel. +49 355 69-4129
Universitaetsplatz 3-4, D-03044 Cottbus              Fax. +49 355 69-4153