On 2/8/11 7:11 PM, Ingo Molnar wrote:
>
> * Chet Ramey <[email protected]> wrote:
>
>> On 2/8/11 4:17 PM, Oleg Nesterov wrote:
>>
>>> Once again. If bash gets ^C and at the same time the current foreground
>>> child exits normally (either because this jctl signal races with exit()
>>> or because the child hooks SIGINT and exits after that) SIGINT is lost.
>>>
>>> set_job_status_and_cleanup() insists that WTERMSIG(child->status) should
>>> be SIGINT, iow the child should be killed by the same signal. Otherwise
>>> it is not going to kill itself, and the next wait_for() clears
>>> wait_sigint_received.
>>>
>>> This all looks intentional, but this means ^C can never work reliably.
>>
>> It depends on what you mean by `reliably'. Consider a script that runs
>> emacs, then does other processing when emacs completes. Emacs uses SIGINT
>> internally to interrupt editing commands, but handles it and does not exit
>> as a result. Since emacs is run from a script, and job control is not
>> enabled, the shell receives the SIGINT also, because it is in the
>> terminal's foreground process group. Should the shell abort the script
>> when emacs exits?
>
> Could you try the reproducer please?
>
> Once you run it, try to stop it via Ctrl-C, and try to do this a couple of
> times.
>
> Do you consider it normal that it often takes 2-3 Ctrl-C attempts to
> interrupt that
> script, that it is not possible to stop the script reliably with a single
> Ctrl-C?
>
> This issue occurs all the time on different hardware and on different
> distributions,
> during make jobs and other simpler scripts, etc. - i just simplified it down
> to a
> simple testcase.
>
> Oleg also found another simple testcase i think - and Thomas (Cc:-ed)
> reported
> similar Ctrl-C problems with Bash as well.
I tried to reproduce it and wasn't able to. I use Mac OS X.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU [email protected] http://cnswww.cns.cwru.edu/~chet/
