so called hang-on-exit bug

[Nicolas.Williams at ubsw.com]

I expect private e-mail to stay private. Particularly if I'm
helping someone who I'm not required to help. It seems that you
think that I'm obligated to you.

You fail to understand that the behaviour you want is at odds
with the behaviour others may want and it may be hard to faithfully
emulate the *BSD behaviour on Linux/Solaris. I suggest that you
file a bug report with Sun, RedHat and the other Linux vendors, or
with the LKML directly - perhaps they'll respond sooner to your
needs than this list.

Cheers,

Nico
-- 

> -----Original Message-----
> From: Michael Robinton [mailto:michael at bizsystems.com]
> Sent: Wednesday, August 07, 2002 11:31 AM
> To: openssh-unix-dev at mindrot.org
> Subject: Re: so called hang-on-exit bug
> 
> 
> >
> > Yes, you can "police" these things as a sysadmin. How? Use
> > /usr/proc/bin/ptree, ps, lsof and what not to find all sshd
> > processes and their associated ptys - the sshds that have no
> > children processes but whose master pty's slave pty still has
> > processes associated with said pty, those are the sshds that must be
> > killed in order to clean up (or you could kill -HUP the background
> > processes).
> 
> sure, that's real practical. I just log on to each system 
> every hour or
> so and take a look :-) That's a real time saver NOT! The whole idea of
> using OS's that don't crash and are able to run unattended 
> for more than a
> day is to avoid this kind of problem. If I wanted to do 
> contstant needless
> maintenance I could run Windoze servers instead of *nix. Are you
> advocating writing software ala "the gates way" ??? i.e. damn the user
> community, let's write it our way???
> 
> 
> >
> > As for the underlying issue, folk are clearly discussing ways to
> > address it - you should be a little more patient and a little more
> > grateful. After all, we could all just ignore you (I am not part of
> > the OpenSSH team - I'm participating out of enlightened
> > self-interest).
> >
> 
> I've been very patient. If you check the archives, this issue has
> been brought up over and over again as a bug -- and -- discussed at
> length and ignored again with the same justification for a year
> or more. I am simply pointing out once again the flaw in the reasoning
> that "not a single byte of data must be lost" even when 
> termination has
> been explicitly requested. It is not productive to simply ignore
> "reported bugs" in a program. The issue is not really whether or not
> it is a bug for the terminal window to hang. I laud the "intent" of
> the developers in trying to preserve data integretity, the reasoning
> is sound. However, the practical aspect of that is a consumption
> of resources on the server that is untenable from an administrative
> standpoint. At some point, real world needs must overide 
> academic purity.
> I have no objection whatsoever to someone else running a 
> system that (I
> won't use the word "hang") --- preserves data that might be 
> lost during a
> disconnect of a session. Our systems need to have the process 
> tables free
> of zombie sshd's and our users need their terminal windows and client
> scripts to terminate without having to examine and test EVERY piece of
> software they use on a remote system whether they wrote it or 
> not. To not
> do this is impractical. To be a user friendly piece of 
> software in my view
> it is necessary for the ssh suite to provide, at a minimum, a 
> configurable
> option for sshd to terminate on request without regard to data loss.
> 
> Every time someone posts a justification as to why hanging a process
> when a termination has been requested, they must consider the needs of
> real world users once again. I'm afraid in the absence of 
> other voices, I
> will post that reminder.
> 
> Michael
> 
> 
> > Cheers,
> >
> > Nico
> > --
> >
> > > -----Original Message-----
> > > From: Michael Robinton [mailto:michael at bizsystems.com]
> > > Sent: Tuesday, August 06, 2002 7:53 PM
> > > To: openssh-unix-dev at mindrot.org
> > > Subject: (no subject)
> > >
> > >
> > > > On Tuesday, August 06, Michael Robinton wrote:
> > > > > Make it an option that can be set in both sshd-config and
> > > > > ssh-config so
> > > > > that both client and server operators have the choice to
> > > > > never lose data
> > > > > or to always disconnect, damn the data, full speed ahead :-)
> > > >
> > > > You can't make it a client-side option if it's 
> implemented on the
> > > > server side without extending the SSHv2 protocol [by 
> adding a new
> > > > channel request type].
> > > >
> > > > So now you're saying you'd be happy with a client-side 
> option (which
> > > > you'd default a particular way, and I another, in ssh_config).
> > > >
> > > > So you've come around to my position :)
> > > >
> > > > Q.E.D.,
> > > >
> > > > Nico
> > > > --
> > >
> > > not really sigh..... What I would like is to NOT find hung
> > > sshd processes
> > > on our servers that have been started by users that can't
> > > figure out how
> > > to properly close the session, or by scripts trying to 
> run brain dead
> > > daemons. From a sysadmin's viewpoint, it is impossible to
> > > police all of
> > > this. The only practical solution is to be able to set sshd
> > > to disconnect
> > > unconditionally when asked. The "client" side option 
> should enable the
> > > "no data loss" for users that really know what they are 
> doing and are
> > > capable of figuring out that their process hung for some 
> reason AND
> > > take corrective action to clear the process.
> > >
> > > Michael
> > >
> > > _______________________________________________
> > > openssh-unix-dev at mindrot.org mailing list
> > > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
> > >
> >
> 
> _______________________________________________
> 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.