[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: ctrl-c does not send INT to all processes under foreground job
From: |
Ryan Ruan |
Subject: |
RE: ctrl-c does not send INT to all processes under foreground job |
Date: |
Thu, 20 Mar 2014 02:12:22 +0000 |
" bash doesn't do anything until the child exits" --- yes, that is exactly
what I have observed.
Thank you very much for your exclamation, Ramey.
/br
Ruan
-----Original Message-----
From: Chet Ramey [mailto:address@hidden
Sent: 2014年3月19日 21:51
To: Ryan Ruan; address@hidden
Cc: address@hidden
Subject: Re: ctrl-c does not send INT to all processes under foreground job
On 3/19/14 12:07 AM, Ryan Ruan wrote:
> Hello, guys:
>
> It is said that "ctrl-C sends INT to ALL processes under foreground job", but
> i found a weird phenomenon.
> I have not read source code yet, but it does not seem to ascribe to what
> specification says.
>
> Test code is like:
>
> 1 trap "echo hello world $1" 2
> 2 sleep 10000
> 3 /bin/bash $0 $(( $1 + 1 ))
> 4 echo "$1 go to sleep"
> 5 sleep 1000
> 6 echo "$1 exit "
>
>
> When I run ./test.sh on the console, the process (/bin/bash test.sh) is stuck
> at line 2.
> Then I input Ctrl-C, the result is that the code is interrupted at line 2 and
> goes to execute line 3, thus generate a new process (/bin/bash test.sh 1).
> At the same time, the first process (/bin/bash test.sh) is stuck at line 3
> waiting for process '/bin/bash test.sh 1' to finish.
> At this time, I input Ctrl-C again, and generate process '/bin/bash test.sh
> 2', and i think process '/bin/bash test.sh 1' SHOULD BE SENT signal INT now.
> So I kill process '/bin/bash test.sh 2' by doing 'kill -9 <pid>'.
> What amazes me is that process '/bin/bash test.sh 1' did not trap INT this
> time, because "hello world 1" is not printed out. So it seems the process did
> not receive INT before.
> How can this be? Is it a bug?
This is another instance of the question "what does bash do with a SIGINT it
receives while waiting for a foreground process?" The answer is that it allows
the child to decide what to do and responds accordingly: if the child exits due
to being killed by the SIGINT, bash acts as if it received the SIGINT; if the
child decides to trap it, do something else and not resend the SIGINT to
itself, bash will effectively discard it. In any case, bash doesn't do
anything until the child exits.
There is a fairly long explanation of the issue at
http://www.cons.org/cracauer/sigint.html.
This has come up in several past discussions on bug-bash, some quite heated
(especially the first link below, which involved Linus Torvalds and several
Linux kernel developers):
http://lists.gnu.org/archive/html/bug-bash/2011-02/msg00050.html
http://lists.gnu.org/archive/html/bug-bash/2013-02/msg00088.html
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU address@hidden http://cnswww.cns.cwru.edu/~chet/