Bash Signals – Control Which Process Gets Cancelled by Ctrl+C

bashsignals

I have a live CD that boots into Linux and runs a small Bash script. The script searches for and runs a second program (which is usually a compiled C++ binary).

You're supposed to be able to abort the second program by pressing Ctrl+C. What should happen is that the second program halts, and the Bash script continues running cleanup. What actually happens is that both the main application and the Bash script terminate. Which is a problem.

So I used the trap builtin to tell Bash to ignore SIGINT. And now Ctrl+C terminates the C++ application, but Bash continues its run. Great.

Oh yeah… Sometimes the "second application" is another Bash script. And in that case, Ctrl+C now does nothing whatsoever.

Clearly my understanding of how this stuff works is wrong… How do I control which process gets SIGINT when the user presses Ctrl+C? I want to direct this signal to just one specific process.

Best Answer

After many, many hours of searching the face of the Internet, I have found the answer.

Linux has the notion of a process group.
The TTY driver has a notion of Foreground Process Group.
When you press Ctrl+C, the TTY sends SIGINT to every process in the Foreground Process Group. (See also this blog entry.)

This is why both the compiled binary and the script that launches it both get clobbered. In fact I only want the main application to receive this signal, not the startup scripts.

The solution is now obvious: We need to put the application in a new process group, and make it the Foreground Process Group for this TTY. Apparently the command to do that is

setsid -c <applcation>

And that is all. Now when the user presses Ctrl+C, SIGINT will be sent to the application (and any children it may have) and nobody else. Which is what I wanted.

setsid by itself puts the application in a new process group (indeed, an entire new "session", which is apparently a group of process groups).
Adding the -c flag makes this new process group become the "foreground" process group for the current TTY. (I.e., it gets SIGINT when you press Ctrl+C)

I've seen a lot of conflicting information about when Bash does or does not run processes in a new process group. (In particular, it appears to be different for "interactive" and "non-interactive" shells.) I've seen suggestions that you can maybe get this to work with clever pipe trickery... I don't know. But the approach above seems to work for me.

Related Solutions

Why would Ctrl-C behave differently than kill -2

One possibility is that the program catches the Ctrl+C sequence. Check the output of stty -a; the intr setting indicates which key combination (if any) sends a SIGINT signal, and the isig indicates whether the signal keys are enabled (-isig means they are disabled).

If the program consists of several processes, pressing Ctrl+C sends SIGINT to all the processes in the process group. You can obtain the same effect by sending the signal to the process group instead of sending it to one of the processes. To send a signal to a process group, first determine its leader: that's the first process that starts all the others; if you run the process group in the background, that's the PID shown by jobs -l. The PID of the process group leader is the PGID (process group id); send the signal to its negative. E.g. if the PGID is 1234, run kill -INT -1234.

If the program consists of a wrapper script and a main application, there are two cases to consider. If there is no cleanup to do, so that the wrapper script terminates as soon as the main aplication terminates, make the wrapper script call exec:

#!/bin/sh
export SOMEVAR=somevalue
…
exec /path/to/application "$@"

This way the application replaces the script, inheriting its PID. Some shells optimize a script that ends by executing another program, but not all. This approach doesn't work when the script needs to perform some cleanup such as removing temporary files.

Consider making the script detect a signal and transmitting the signal to the application. Here's a sketch of how this goes:

/path/to/application "$@" &
app_pid=$!
trap -INT 'kill -INT $app_pid'
wait $!
rm /temp/file

Bash – Prevent SIGINT from reaching child processes

trap '' INT is meant to ignore SIGINTs for the shell and all its children.

But looking at strace outputs on scp, it looks like scp installs its own SIGINT handler which cancels the SIG_IGN above.

The only way to prevent it from getting the SIGINT would be to run it in a different process group like with:

perl -MPOSIX -e 'setpgid 0,0; exec @ARGV' scp...

(set -m; scp ... & wait)

or tell the tty driver to stop sending SIGINT upon Ctrl-C (like with stty -isig, or stty intr '' for ^C alone), though you'd want to restore the settings afterwards:

saved=$(stty -g)
stty intr ''
scp ...
stty "$saved"

Best Answer

Related Solutions

Why would Ctrl-C behave differently than kill -2

Bash – Prevent SIGINT from reaching child processes

Related Question