Why is this code behaving differently across various distros/Unixes?

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()

score 6 · Accepted Answer · answered Jul 21 '11 at 08:58

6

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.

answered Jul 21 '11 at 08:58

agf

171,228
44
289
238

Verified - Ubuntu was using dash, OpenBSD was using ksh. Switching /bin/sh to being a symlink towards bash made OpenBSD work like Debian. Thank you. – ttsiodras Jul 21 '11 at 09:14
4

In case it helps other people: When invoking Popen, one can specify which shell to use, with: mysub=subprocess.Popen("./cryInAbort", shell=True, executable="/bin/bash") – ttsiodras Jul 21 '11 at 09:30

score 0 · Answer 2 · answered Jul 21 '11 at 19:43

0

A good thing to do is make sure your script is POSIX compliant. I had this problem porting a BASH script to DASH. I simply changed parts of the bash script that were BASH-specific and replaced them with the POSIX-compliant syntax.

answered Jul 21 '11 at 19:43

djhaskin987

9,741
4
50
86

Why is this code behaving differently across various distros/Unixes?

2 Answers2