2014-03-19 04:07:06 +0000, Ryan Ruan:
[...]
> 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?
[...]
I can't reproduce with any of bashs 3.2.48, 4.0, 4.1, 4.2, 4.3
on Linux 3.12 amd64 which exhibits the same behavior as any
other shell I tried. What system are you on? Have you tried
other shells?
Do you possible have a SHELLOPTS, BASHOPTS or BASH_ENV in your
environment?
What should happen is that on the first ^C
zsh
└─bash ./a
└─sleep 10000
zsh being my interactive shell has set the process group running
the script in foreground, so all processes in that group should
receive the SIGINT.
bash blocks the SIGINT to be able to handle it *after* sleep
returns.
sleep dies because of the SIGINT, then bash receives and handles
the SIGINT so we see "hello world", and it goes on to run the
next command:
zsh
└─bash ./a
└─bash ./a 1
└─sleep 10000
Now, three processes in that process group. ^C is sent to all
of them but the bash processes block it.
Upon termination of the sleep, "hello world 1" is printed but
the first bash doesn't print its "hello world" because the
second bash has not returned. And we now have:
zsh
└─bash ./a
└─bash ./a 1
└─bash ./a 2
└─sleep 10000
If you kill the "./bash ./a 2", "bash ./a 1", runs its
echo "go to sleep 1" and after finishing, we should see the
first bash handling its second SIGINT at last and display
"hello world" again before going to sleep.
--
Stephane.
