so called hang-on-exit bug

[Michael Robinton]

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