Bash – Why does Bash ignore SIGINT if its currently running child handles it

bashsignals

The following Bash loop stops if I interrupt it with ^C:

(while true; do sleep 5; done)

The following, however, does not:

(while true; do aplay test.wav; done)

The difference, from what I can tell, is that aplay catches and handles SIGINT, whereas sleep does not.

Why is this? Does POSIX specify this behavior somewhere (I notice that Dash does the same thing), and if so, why? I cannot quite understand why this behavior is desirable. In fact, how can Bash even tell the difference? I must admit I'm not aware of any mechanism (other than ptrace or /proc/ hacking, at least) by which one process can tell how another one handles signals.

Also, is there a way to counteract it? I notice that not even a trap 'exit 0' SIGINT before the loop helps.

(EDIT: Running the loops in a subshell is important, because otherwise the parent shell does not receive the SIGINT.)

Best Answer

The problem is well explained here, as WCE wait and cooperative exit and I encourage you to read it. Basically, your signal is received by all foreground processes, ie the shell and the program, sleep or aplay. The program exits with return code 130 if it does not handle the signal. The shell does a wait for the child to end, and sees this, and the fact that it got the signal too, so exits.

When the program captures the signal, it often just exits with code 1 (as with aplay). When the shell waits for the child, it sees that it did not end due to the signal and so has to assume the signal was a normal aspect of the program's working, so the shell carries on as normal.

For your example, the best way to handle aplay is to check its return code for non-zero and stop:

(while aplay test.wav; do :; done)

The above-mentioned article goes on to explain that a well-behaved program that wants to trap sigint to do some cleanup, should then disable its handler, and re-kill itself in order to get the correct exit flags set.

Related Solutions

Shell Script – Prevent SIGINT from Interrupting Function Calls and Child Processes

There are several ways you can cut off the effect of Ctrl+C:

Change the terminal setting so that it doesn't generate a signal.
Block the signal so that it is saved for later delivery, when the signal becomes unblocked.
Ignore the signal, or set a handler for it.
Run subprocesses in a background process group.

Since you want to detect that Ctrl+C has been pressed, ignoring the signal is out. You could change the terminal settings, but then you would need to write custom key processing code. Shells don't provide access to signal blocking.

You can however isolate subprocesses from receiving the signal automatically by running them in a separate process group. Interactive shells run background commands in a separate process group by default, but non-interactive shells run them in the same process group, and all processes in the foreground process group receive a signal from terminal events. To tell the shell to run background jobs in a separate process group, run set -m. Running setsid ping … is another way of forcing ping to run in a separate process group.

set -m
interrupted=
trap 'echo Interrupted, but ping may still be running' INT
set -m
ping … &
while wait; [ $? -ge 128 ]; do echo "Waiting for background jobs"; done
echo ping has finished

If you want Ctrl+Z to suspend a background process group, you'll need to propagate the signal from the shell.

Controlling signals finely is a bit of a stretch for a shell script, and shells other than ATT ksh tend to be a little buggy when you reach the corner cases, so consider a language that gives you more control such as Perl, Python or Ruby.

Bash does not exit on abnormal exit of child process due to signal

First, exit 130 is not an abnormal exit. It is a normal exit, with exit status 130. As can be seen from man 3 wait (POSIX):

   If  the  information  pointed  to  by  stat_loc was stored by a call to
   waitpid()  that  specified  the  WUNTRACED     and  WCONTINUED   flags,
   exactly one of the macros WIFEXITED(*stat_loc), WIFSIGNALED(*stat_loc),
   WIFSTOPPED(*stat_loc),  and WIFCONTINUED(*stat_loc)  shall evaluate  to
   a non-zero value.

WIFEXITED checks normal exit, and WIFSIGNALLED is termination due to an uncaught signal. Since these are mutually exclusive, an exit 130 is normal.

That the exit status is 130 when a process dies by SIGINT is because bash sets it to be 130 outside of the process because it detected an exit due to SIGINT: Why does bash set $? (exit status) to non-zero on Ctrl-C or Ctrl-Z?

Second, a process that handles SIGINT and then dies should kill itself with SIGINT. Greg's wiki (an excellent resource for shell stuff) has a note on this:

If you choose to set up a handler for SIGINT (rather than using the EXIT trap), you should be aware that a process that exits in response to SIGINT should kill itself with SIGINT rather than simply exiting, to avoid causing problems for its caller. Thus:
trap 'rm -f "$tempfile"; trap - INT; kill -INT $$' INT

Now, if you changed the exit 130 to:

trap - INT
kill -INT $$

You'd see the expected behaviour.

Best Answer

Related Solutions

Shell Script – Prevent SIGINT from Interrupting Function Calls and Child Processes

Bash does not exit on abnormal exit of child process due to signal

Related Question