Question

The following (a small C program and a python script that calls it)
behave differently across various Unixes.

In some of them (e.g. Debian stable), the C app gets the signal,
the message is printed fine from the signal handler and the script
finishes. In others (e.g. a two year-old Ubuntu and an OpenBSD)
the signal is lost, and therefore the message is not printed at all,
and the script waits forever…

The signal is ALWAYS delivered, if in the python script, I change this…

mysub=subprocess.Popen("./cryInAbort", shell=True)

into this…

mysub=subprocess.Popen("./cryInAbort", shell=False)

So it appears that in some Unixes the intermediate shell “eats” the SIGINT,
while in others it forwards it to the child process (the C program).

I took care to only call re-entrant functions in the signal handler
so this doesn’t seem to be related to my C code – it looks as if
signal handling behavior within “/bin/sh” (the default shell used
by Python to spawn things) is not “stable” across Unixes…

Am I doing something wrong?

EDIT: In case you are wondering why I used “shell=True”: it’s because in my real code, I am not just passing “./executable” – I am using shell code for loops and wildcards.

This is the C code that prints and dies when it gets SIGINT:

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

void my_handler()
{
    static const char msg[] = "Goodbye - test was OK.\n";
    write(1,msg,sizeof(msg));
    fsync(1);
    _exit (0);
}

int main()
{
    (void) signal (SIGINT, my_handler);
    while (1);
}

And this is the Python script that tests it by sending SIGINT:

#!/usr/bin/env python
import subprocess,signal,time
mysub=subprocess.Popen("./cryInAbort", shell=True)
time.sleep(2)
mysub.send_signal(signal.SIGINT)
mysub.wait()

Answer 1

Just because Python uses /bin/sh doesn’t mean it’s the same shell on all systems.

/bin/sh is almost always an alias in the form of a symbolic link: the real shell could be busybox, bash, ash, csh, ksh, dash, zsh, tcsh, or something crazy(er).

Confirm that you’re actually using the same shell on all the systems, then if the problem is a specific shell you know where to look for more information on it’s behavior.