Re: [BUG] Bash not reacting to Ctrl-C

[Ingo Molnar]

* Chet Ramey <chet.ramey@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