so-called-hang-on-exit

[Nicolas.Williams at ubsw.com]

A test program *could* be written. The test should try several
conditions to determine what the kernel/pty driver behaviour is:

 - does the pty close immediately when the session leader exits?
 - does the pty close immediately when the session leader is gone *and*
   the pty's foreground process group is orphaned (or empty?)?
 - does the pty driver send SIGHUP to all processes associated with the
   PTY when the session leader exits?

Having the answers to these questions for each of the major platforms we
can then think about how to emulate *BSD behaviour on Linux and Solaris
(assuming that it's even desired). But then, we all pretty much suspect
what the behaviour is (see previous posts in this thread).

The notion of "flushing the pty" may not be so simple because the
boundary between data last written by the session leader and data
written by background processes may be indistiguishable (would that
even be a problem?) - how does one "flush the pty" from the master
side anyways? (by reading until read() returns EWOULDBLOCK? or is there
some special ioctl() for emptying buffered data on the slave write side
to the master read side?)

And one more avenue that must be considered: why not just document the
platform differences and leave it at that? Some will be inconvenienced,
but the OpenSSH folks could just say "hey, take it to your OS vendor", say.

Cheers,

Nico
-- 

> -----Original Message-----
> From: Ben Lindstrom [mailto:mouring at etoh.eviladmin.org]
> Sent: Tuesday, August 06, 2002 10:35 PM
> To: Carl Brewer
> Cc: Michael Robinton; openssh-unix-dev at mindrot.org
> Subject: Re: so-called-hang-on-exit
> 
> 
> 
> On Tue, 6 Aug 2002, Carl Brewer wrote:
> 
> [..]
> > > since ~ will unconditionally close a terminal window, 
> what's wrong with a
> > > config option to do this automagically if the sysadmin 
> wishes to configure
> > > sshd in this fashion. Give me a good reason (other than 
> academic) why when
> > > the user or script says "bye now" that sshd should not take them
> > > seriously.
> >
> > Not to mention the complexity of multiple chained ssh 
> connections, how
> > many "~'s do I need to press?  I'm chained in through how 
> many sessions
> > again?
> >
> > Unfortunatly, Michael, you're wasting your time.  None of the
> > developers will see it from a 'real user' perspective.  Purity
> > vs practicality, and purity wins.
> >
> 
> Your going to have to excuse me. I just got back into town after a
> wirlwind trip, but I don't think you are qualify to say that.
> 
> The question that has yet to be answered is.
> 
> *WHY* does it happen on some platforms and not others?  You 
> run OpenSSH on
> OpenBSD?  No hang.
> 
> No one has yet to even explain to us why.  If one person 
> could explain why
> without handwaving it would solve the problem because it more 
> than likely
> is a mistake on TTY handling.
> 
> - Ben
> 
> _______________________________________________
> openssh-unix-dev at mindrot.org mailing list
> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
> 

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.