tty screwed up on ctrl-c

John Van Essen vanes002 at
Thu Dec 18 09:26:53 EST 2003

On Wed, 17 Dec 2003 02:53:59 -0800, jw schultz <jw at> wrote:
> 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.

But ssh has to have *some* opportunity to restore the settings,
doesn't it?  So a small delay seems appropriate in any case.

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

For that matter, why does it have to be SIGUSR1?  If you are trying
to terminate children, why not use SIGTERM and trap that instead?

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

That reasoning works for me!

I have a suggestion about your patch, though.

Move the msleep (and a rationale comment) to the sig_int routine.
Then it takes effect only in the situations where it's really needed.
I tried that, and it works just fine.

I used a much larger msleep to begin with so I could do a ps to verify
that the ssh process goes away.  It does.  So it just needs that little
bit of extra time to do its thang.
        John Van Essen  Univ of MN Alumnus  <vanes002 at>

More information about the rsync mailing list