lkml.org 
[lkml]   [2011]   [Jan]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Bash not reacting to Ctrl-C

* Oleg Nesterov <oleg@redhat.com> wrote:

> On 01/28, Ingo Molnar wrote:
> >
> > The bug is that occasionally Ctrl-C does not get processed, and that the Ctrl-C is
> > 'lost'. It can be reproduced here by running ./test-signal several times, and
> > Ctrl-C-ing it:
> >
> > $ ./test-signal
> > ^C
> > $ ./test-signal
> > ^C^C
> > $ ./test-signal
> > ^C
> >
> > See that '^C^C' line? That is where i had to do Ctrl-C twice.
>
> Reproduced.
>
> At first glance, /bin/sh should be blamed... Hmm, probably yes,
> I even reproduced this under strace, and this is what I see
>
> wait4(-1, 0x7fff388431c4, 0, NULL) = ? ERESTARTSYS (To be restarted)
> --- SIGINT (Interrupt) @ 0 (0) ---
> rt_sigreturn(0) = -1 EINTR (Interrupted system call)
> wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 9706
>
> So, ^C is not lost, but ./test-signal doesn't want to exit.

Might be some Bash assumption or race that works under other OSs but somehow Linux
does differently. IIRC Bash is being developed on MacOS-X.

But it's happening all the time (with yum for example - but also with makejobs, as
Thomas has reported it) - this is simply the first time i managed to reproduce it
with something really simple.

Thanks,

Ingo


\
 
 \ /
  Last update: 2011-01-28 19:33    [W:0.139 / U:44.676 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site