hang on exit bug under Linux

[Peter Stuge]

On Tue, Dec 11, 2001 at 06:31:17PM -0800, Michael wrote:
>>>>> If you run openssh, like the following:
>>>>> 
>>>>> ssh remotehost "foreverSleep &"
>>>>> 
>>>>> Should and does hang (fsecure hangs as well).

If you do not want this to "hang", use

ssh remotehost foreverSleep &

instead.  Obvious solution maybe, but it's what this is all about.


>>>>> HOWEVER,
>>>>>
>>>>> ssh remotehost
>>>>> # foreverSleep &
>>>>> # exit
>>>>>
>>>>> DOES hang. (fsecure does not hang) This is where the bug is. If
>>>>> you run ssh with a tty and in interactive mode, if the client
>>>>> decides to disconnect, it disconnects cleanly (I'm not sure about
>>>>> what happens to the remaining processes, you will have to
>>>>> look at rsh code for that -- it may be SIGHUP or something, i
>>>>> dunno -- other posts may be clearer on this).

SSH Inc's sshd and rshd both behave this way, yes, and both can hence cause
data loss.  The same goes for xterm.  And my Linux console.  And the OpenBSD
console.  And this is the problem.  We're used to all these programs causing
possible data loss, but we don't quite see it this way.

At least I didn't, until now.

I was just discussing this with a nice guy in #openbsd on DALnet, and
neither of us could come up with one single program that would linger in the
above case..

<JohnA> but i can't think of any process that behaves that way these days,
        you'd just end up with piles of lingering processes on some machines


> I'd really like to be able to have and sshd daemon that would boot 
> the client off the machine and exit when it receives a close after 
> starting a faulty daemon. I'm not keen about having many waiting 
> sshd's in the process table because users don't clean up after 
> themselves. This really is the issue, not what is truly right or 
> wrong. I really don't think everyone will every agree. I'd be most 
> happy even with an option with which I could configure MY sshd's to 
> dump the user unconditionally if it receives a request to disconnect 
> and the process is backgrounded. Giving the sysop the option to set 
> things up that way would go a long way toward solving the problem 
> until the "world" comes to an agreement on the true solution.

The true solution is considered to be one of two things:

1. All daemons shall behave.  (ie. close std*)
2. The user knows what he/she wants.  (ie. to exit, loosing data)

I actually want both.  I want to be able to tell sloppy daemon programmers
that they should clean up their code.  But I also want my users to not have
to deal with sloppy daemon programmers, unless they choose to do so.
This is tough.

A thought that occured in my mind tonight while thinking about this is that
the ssh client could background itself and tell the user about it, instead
of closing down and causing possible data loss.  And it needs to leave std*
open, ie. not daemonize, but background.  This would propagate over multiple
connections all the way back to my actual terminal.  And if I choose to
close my terminal (xterm, console, whatever) the process that I started at
remotehost will be sent SIGHUP.  In the perl case it would kill it, a C
program that catches the signal doesn't care and keeps running.  Data will
be lost but that is out of SSH scope.

Comments on this, anyone?


//Peter

-- 
irc: CareBear\
irl: Peter Stuge