tty screwed up on ctrl-c

jw schultz jw at
Wed Dec 17 21:53:59 EST 2003

On Wed, Dec 17, 2003 at 10:53:22AM +0100, Paul Slootman wrote:
> 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) ?

Yes and no.  In the case of ^C the signal we received was
also received by the other children so if they aren't dying
they need to be killed.  SIGUSR1 is the correct signal for
killing the child rsync process but Unfortunately, kill_all()
kills all the children indiscriminately.  How this is done
should perhaps be reviewed.

Nevertheless the fact that ssh has altered TTY settings and
left some catchable signals that default to process termination
uncaught is a bug.

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

And the average linux user nowadays has his shell prompt
running in an terminal emulator window that can be closed
and a new one opened.  That is likely why he never learned
about stty.  That is if he is even running from a shell
prompt.  If he finds it that awkward to abort the local
shell he will either learn stty or type a bum password if he
wants to abort when asked for a password.

I may be wrong in this but i don't have that much sympathy
for the user who gets upset because his konsole window got
messed up when he hit ^C in the middle of a password
prompt.  Sometimes us codgers get a little curmudgeonly:)

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

I recall looking at the openssh code and it looked trivial
for them to catch all the catchable terminating signals
while the tty is in -echo state to restore prior state like
the already do for some signals.  If i were the paranoid
sort i could probably identify some security problem with
the current behaviour.

If they can come up with a good reason why the current
behaviour is correct i'll buy the workaround.  It might just
be me but i don't much care for coding kludgey workarounds
for trivial bugs in other products.  If we were talking
about a proprietary product from some faceless corp it would
be one thing but we are talking about responsible people
who, as far as i know, care about quality.

Anyway, i don't see that this issue is so urgent it has to
get slipped in at the last minute.  If we do want a
workaround maybe what should happen is for all_pids to have
a signal associated with each child at fork time for killing
that child.

	J.W. Schultz            Pegasystems Technologies
	email address:		jw at

		Remember Cernan and Schmitt

More information about the rsync mailing list