hang on exit bug under Linux

[Michael]

> > so try this, guaranteed to hang the exit of the session for 
> > openssh, but ssh-1.2.27 likes it fine.
> > file tst.pl
> > #!/usr/bin/perl
> > while (1) {
> >   sleep 1;
> > }
> > # end
> > at the keyboard, just type
> > > perl tst.pl &
> > > exit
> > This means that a daemon can never be stopped and restarted from the 
> > keyboard without a hang or screwing around with special exit 
> > procedures. Looks, sounds, smells like a bug to me.
> 
> That is not a proper daemon program and therefore not a good example
> of a problem.  Proper daemons should always close any tty file
> descriptor, detach from any controlling terminals, call setsid() to
> form a new process group, etc.  This is more representative of a
> program that could loose data.
> 
> Perhaps one of the reasons this issue has been hard to get agreement
> on is that everyone is testing with different daemons and some of
> those are ill behaved?
> 

Sure, I know it's not a proper daemon. The point is, it is 
representative of what people do everyday when writing 
script programs. Other clients that attach to unix boxes manage 
somehow to get around this and do so, in my opinion, because the 
developers realize that the the people that use these tools are not 
"perfect programers" that always do every thing exactly the right 
way. It is not unreasonable to assume that some people that write 
script code are all senior developers. It's also not unreasonable to 
expect or require that when a client is told to disconnect that the 
server end honor the request and clean up any mess that might remain. 
It's really not any different than the loss of the connection due to 
a network outage. I haven't checked, but I assume (excuse me) that 
sshd is capable of cleaning up after a network loss and not polluting 
the system with unused daemons that will never close.

If openssh is to remain a useful and viable tool for secure 
communication between hosts, it must operate in a manner where even 
the idiots can use it. When you sit at the keyboard and type 
>exit
one assumes that what's on the other end will go away. RTFM'ing to 
find ~. or ~? is not the solution. Likewise, ps-ax'ing the remote 
host to find out how many sshd's remain because of broken client 
connections is not realistic either. In many cases, the client 
operator or script does not even know what version of sshd is on the 
other end and will have no idea that there is a problem. The sysop of 
the target system is also in the dark since he has no idea what his 
users are doing at any given moment. Certainly the victim sysop does 
not want useless copies of sshd lying around in the job table simply 
because it is incapable of complying with a disconnect 
request from its client. Basically, the request for disconnect is 
analogus to a kill -15 followed by a kill -9 if there is not an 
immediate response. The daemon can not in the presence of a 
disconnect request or loss of connection to the client, fail to clean 
up what ever remains of its process and die unconditionally.

And, ..... yes I have followed and read the entire thread about this. 
What I fail to understand is why all the dithering. Data might be 
lost, but the client has said "GO AWAY" and obviously does not want 
any more data.

Michael
Michael at Insulin-Pumpers.org