Strange problem with trap and SIGINT

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.

With some tracing:

strace -o aaa ./scripta

we can observe that by default

read(255, "#!/bin/bash\n# this is scripta.sh"..., 153) = 153
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) = 0
lseek(255, -108, SEEK_CUR)              = 45
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f1ee9b7ca10) = 2483

so scripta has blocked INT and CHLD signals; scriptb inherits those settings through the fork (here called clone). And what is scriptb doing? If we run it from scripta via:

strace -o bbb ./scriptb &

And then look for signal related things, we find:

rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x7fb1b2e75250}, {SIG_IGN, [], 0}, 8) = 0
rt_sigaction(SIGINT, {SIG_IGN, [], SA_RESTORER, 0x7fb1b2e75250}, {SIG_DFL, [], SA_RESTORER, 0x7fb1b2e75250}, 8) = 0

Which indicates nothing is being blocked, and then that INT signals are first given the default handling, and then are ignored. scriptb run directly from the shell under strace by contrast shows:

rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x7f2c3f6d4250}, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x7f2c3f6d4250}, {SIG_DFL, [], SA_RESTORER, 0x7f2c3f6d4250}, 8) = 0
rt_sigprocmask(SIG_BLOCK, [INT], [], 8) = 0
rt_sigaction(SIGINT, {0x45fbf0, [], SA_RESTORER, 0x7f2c3f6d4250}, {SIG_DFL, [], SA_RESTORER, 0x7f2c3f6d4250}, 8) = 0
rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) = 0
rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1], [INT CHLD], 8) = 0
...

Or never ignored, before getting into the then repeated sleep call handling. Okay. Uh. Let's put a shim between scripta and scriptb that resets SIGINT to the default state...

#include <getopt.h>
#include <signal.h>
#include <stdlib.h>
#include <unistd.h>

int main(int argc, char *argv[])
{
    int ch;
    while ((ch = getopt(argc, argv, "h?")) != -1) {
        switch (ch) {
        case 'h':
        case '?':
        default:
            abort();
        }
    }
    argc -= optind;
    argv += optind;
    if (argc < 1) abort();

    signal(SIGINT, SIG_DFL);

    execvp(*argv, argv);
    abort();
    return 1;
}

Used as follows:

$ make defaultsig
cc     defaultsig.c   -o defaultsig
$ grep defaultsig scripta.sh
./defaultsig ./scriptb.sh &
$ ./scripta.sh 
12510 started
scriptb.sh 12510
scriptb.sh 12510
scriptb.sh 12510
scripta.sh 12509
Ouch
scriptb.sh 12510
scriptb.sh 12510
scriptb.sh 12510
scripta.sh 12509
Ouch
...

Yep works good now. However, I don't know why bash behaves this way, maybe file a bug with them? The code in sig.c looks mighty complicated, and there's more signal handling elsewhere...

Strange problem with trap and SIGINT

Thank you all for the answers and for the time you took studying the problem.

Please allow me to recapitulate and integrate (with apologies for what might be obvious in the following):

1) I forgot to add in my question I had tried SIGQUIT also and it behaved as SIGINT;

2) From that, I already suspected the problem was related to the default disposition of an interactive bash for those two signals;

3) Their default action not happening when interacting with bash is because it makes no sense quitting or interrupting anything when the only thing you have is the prompt. If you wish to leave the shell, just type exit;

4) I don’t see SIGQUIT and SIGINT playing a special role in job control (contrary to SIGTSTP, SIGTTOU, SIGTTIN);

5) It doesn’t make sense to me that the default disposition of an interactive bash for those two signals be inherited by a background (non-interactive) shell, (the one executing scriptb.sh in our case);

6) In fact, just as the foreground process group does not inherit (from the shell which started it) the dispositions for SIGQUIT and SIGINT, IMHO it should make sense for the same to happen with the background process groups.

7) Moreover, whatever the inherited disposition is, trap should change it.

8) All in all I incline to agree with thrig and to think what we are seeing here is a bug.