Bash – Strange problem with trap and SIGINT

background-processbashshellsignalstrap:

Please explain this:

#!/bin/bash
# This is scripta.sh
./scriptb.sh &
pid=$!
echo $pid started
sleep 3
while true
do
    kill -SIGINT $pid
    echo scripta.sh $$
    sleep 3
done

–

#!/bin/bash
# This is scriptb.sh
trap "echo Ouch;" SIGINT

while true
do
 echo scriptb.sh $$
 sleep 1
done

When I run ./scripta.sh the trap doesn't print. If I switch from SIGINT to any other signal (I tried SIGTERM, SIGUSR1) the trap prints "Ouch" as expected. How can this happen?

Best Answer

If I switch from SIGINT to any other signal (I tried SIGTERM, SIGUSR1) the trap prints “Ouch” as expected.

Apparently you didn’t try SIGQUIT; you will probably find that it behaves the same as SIGINT.

The problem is job control.

In the early days of Unix, whenever the shell put a process or pipeline into the background, it set those processes to ignore SIGINT and SIGQUIT, so they would not be terminated if the user subsequently typed Ctrl+C (interrupt) or Ctrl+\ (quit) to a foreground task. When job control came along, it brought process groups along with it, and so now all the shell needs to do is put the background job into a new process group; as long as that is not the current terminal process group, the processes will not see signals coming from the keyboard (Ctrl+C, Ctrl+\ and Ctrl+Z (SIGTSTP)). The shell can leave background processes with the default signal disposition. In fact, it probably has to, for the processes to be killable by Ctrl+C when they are brought into the foreground.

But non-interactive shells don’t use job control. It makes sense that a non-interactive shell would fall back to the old behavior of ignoring SIGINT and SIGQUIT for background processes, for the historical reason — to allow the background processes to continue to run, even if keyboard-type signals are sent to them. And shell scripts run in non-interactive shells.

And, if you look at the last paragraph under the trap command in bash(1), you’ll see

Signals ignored upon entry to the shell cannot be trapped or reset.

So, if you run ./scriptb.sh & from your interactive shell’s command prompt, its signal dispositions are left alone (even though it’s being put into the background), and the trap command works as expected. But, if you run ./scripta.sh (with or without &), it runs the script in a non-interactive shell. And when that non-interactive shell runs ./scriptb.sh &, it sets the scriptb process to ignore interrupt and quit. And therefore the trap command in scriptb.sh silently fails.

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