Subject: RE: so called hang-on-exit bug

[Michael Robinton]

My apologies Nico, I overlooked the fact that your post was not to the
list since most I receive are cc'd to me. You have my sincere apology for
the public re-posting of your private comments.

>
> 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.
>

I have no illusion that anyone is obligated to me or anyone else in the
user community. I do open source development as well, just not for the ssh
project so I do have some insight into the other side of things. I have a
real interest in seeing opensource do well in all areas and I believe that
ssh is a significant contribution. I'd just like it to be a little more
user friendly. I don't want to beat a dead horse so I'll just shut up for
a while.

Michael

> 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
> >
>