tty screwed up on ctrl-c
John Van Essen
vanes002 at umn.edu
Thu Dec 18 09:26:53 EST 2003
On Wed, 17 Dec 2003 02:53:59 -0800, jw schultz <jw at pegasys.ws> 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 umn.edu>
More information about the rsync