public
anonymous / gist:1096804
Created

Inconsistent SIGINT behaviour - why?

  • Download Gist
gistfile1.txt
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57
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 fine. 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?
 
-----------------------------------------------------------
// First, the C code that cries 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);
}
-----------------------------------------------------------
#!/usr/bin/env python
#
# Then, the Python script that tests it by sending SIGINT:
 
import subprocess,signal,time
mysub=subprocess.Popen("./cryInAbort", shell=True)
time.sleep(2)
mysub.send_signal(signal.SIGINT)
mysub.wait()
-----------------------------------------------------------

Please sign in to comment on this gist.

Something went wrong with that request. Please try again.