tty screwed up on ctrl-c

[Paul Slootman]

On Tue 16 Dec 2003, jw schultz wrote:
> 
> I remember this as well and the root of the problem was not
> that rsync didn't wait long enough but that ssh was not
> resetting the tty for all catchable signals including
> SIGUSR1 which is what we send to kill_all children.

Does it make sense to kill children with a different signal than the one
we received ourselves, especially in the case of "adopted" children such
as ssh (compared to child instances of rsync itself) ?

> The change is simple enough and safe enough though i don't
> much like the idea of a half second delay that still won't
> always be long enough.  I still consider it a non-issue, and
> yes i have hit it but i've had similar things happen in the
> past with other utilities and a simple "tty sane" typed
> blind does the trick.

The problem is that without the fix, I get the screwed up setting
everytime (i.e. it _will_ be a problem; even though there's a slight
chance that it'll be OK, in practice it'll be screwed up every time).
You and I know enough to blindly type "tty sane", but the average linux
user nowadays has never heard of stty...
If ssh doesn't react to the SIGINT within the half second, then you're
on a pretty slow system... and then waking up from the delay will
probably take longer as well, giving ssh more time :-)

> Paul, have you pinged the openssh developers on this?

No; it didn't really cross my mind. My fear is that the reaction will be
that we shouldn't be sending SIGUSR1 in cases where we don't really know
what that will do... It's far more usual to trap SIGINT than SIGUSR1.


Paul Slootman