* Chet Ramey <chet.ra...@case.edu> 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.
Thanks,
Ingo
