Messages in this thread |  | | | Date | Thu, 26 Mar 2009 13:44:53 +0100 | | From | Ingo Molnar <> | | Subject | Re: ext3 IO latency measurements (was: Linux 2.6.29) |
| |
* Theodore Tso <tytso@mit.edu> wrote:
> > while :; do > > date > > make mrproper 2>/dev/null >/dev/null > > make defconfig 2>/dev/null >/dev/null > > make -j32 bzImage 2>/dev/null >/dev/null > > done & > ^^ > > So there would have been nothing to ^C; I assume you were running > this with a variant that didn't have the ampersand, which would > have run the whole shell pipeline in a detached background > process?
That was just the example - the real script did not go into the background so it was Ctrl-C-able. I've attached it.
> In any case, the workaround for this is to ^Z the script, and then > "kill %" it. > > I'm pretty sure this is actually a bash problem. When you send a > Ctrl-C, it sends a SIGINT to all of the members of the tty's > foreground process group. Under some circumstances, bash sets the > signal handler for SIGINT to be SIGIGN. I haven't looked at this > super closely (it would require diving into the bash sources), but > you can see it if you attach an strace to the bash shell driving a > script such as > > #!/bin/bash > > while /bin/true; do > date > sleep 60 > done & > > If you do a "ps axo pid,ppid,pgrp,args", you'll see that the bash > and the sleep 60 have the same process group. If you emulate > hitting ^C by sending a SIGINT to pid of the shell, you'll see > that it ignores it. Sleep also seems to be ignoring the SIGINT > when run in the background; but it does honor SIGINT in the > foreground --- I didn't have time to dig into that. > > In any case, bash appears to SIGIGN the INT signal if there is a > child process running, and only takes the ^C if bash itself is > actually "running" the shell script. For example, if you run the > command "date;sleep 10;date;sleep 10;date", the ^C only interrupts > the sleep command. It doesn't stop the series of commands which > bash is running.
It happens all the time - and it does look like a Bash bug. I reported it to the Bash maintainer one or two years ago. He said he does not see it as he's using MacOS X. Can dig into archives if needed.
Ingo
# # Cool down caches as much as possible: # sync echo 3 > /proc/sys/vm/drop_caches # # Kernel developer builds his kernel workload: # while :; do date make mrproper 2>/dev/null >/dev/null make defconfig 2>/dev/null >/dev/null make -j32 bzImage 2>/dev/null >/dev/null done
|  |