homepage

Compare:
$ ./python -c "import subprocess, signal, time; p = subprocess.Popen(['cat']); time.sleep(1); p.send_signal(signal.SIGINT); print(p.wait())"
-2
with:
$ ./python -c "import subprocess, signal, time; p = subprocess.Popen(['python', '-c', 'input()']); time.sleep(1); p.send_signal(signal.SIGINT); print(p.wait())"
Traceback (most recent call last):
 File "<string>", line 1, in <module>
KeyboardInterrupt
1
Python's behaviour apparently breaks a common assumption towards Unix processes (see bug reported at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=652926). A solution would be to add a signal number attribute to KeyboardInterrupt, and use that value when computing the process exit code.

I'm not so sure that Python is in violation of the convention here. The exit code should report *unhandled* signals, indicating that the process didn't provide an exit code at all (as it didn't call exit(2)). You are supposed to use WIFEXITED/WIFSIGNALED/WIFSTOPPED on the status code, and interpret it as an exit code only if WIFEXITED.
Since Python *does* handle the signal, and exits "regularly", we shouldn't (and probably even can't) claim that we didn't exit (unless we raise the signal again instead of exiting).

Another problem with my suggestion is that C exit() ANDs the status with 255 before transmitting it to the parent.

(faulthandler works around that problem by restoring the previous signal handler and calling raise(), apparently)

The Debian bug has some more convincing examples:
> any Python program which is expected to implement the interface of (say) "diff" is buggy, because
> it may exit status 1 ("comparison successful; differences found") when it should have died with
> SIGINT ("comparison not completed due to interrupt signal"); this could in principle cause data loss
> in some applications.

> Since Python *does* handle the signal, and exits "regularly", we
> shouldn't
You are arguing from a legal point of view, but from a pratical point of view Python doesn't really "handle" the signal: it just defers the exit until after all internal structures are cleaned up.

I agree with Martin: we really do handle the signal, and as such, the
only way to convey the relevant information to the parent as to which
signal caused the exit would be to re-raise it, which is really ugly
and probably not a good idea.
Processes that want default behavior upon signal reception (so that
they can use WEXITSTATUS(), WCOREDUMP() and friends) can always use
SIG_DFL:
$ python -c "import subprocess, signal, time; p =
subprocess.Popen(['python', '-c', 'import signal;
signal.signal(signal.SIGINT, signal.SIG_DFL); input()']);
time.sleep(1); p.send_signal(signal.SIGINT); print(p.wait())"
-2

> I agree with Martin: we really do handle the signal, and as such, the
> only way to convey the relevant information to the parent as to which
> signal caused the exit would be to re-raise it, which is really ugly
> and probably not a good idea.
Why would it be ugly? faulthandler does exactly that.

>> I agree with Martin: we really do handle the signal, and as such, the
>> only way to convey the relevant information to the parent as to which
>> signal caused the exit would be to re-raise it, which is really ugly
>> and probably not a good idea.
>
> Why would it be ugly? faulthandler does exactly that.
Because calling exit() is the right way to end a process. For example,
it does the following:
- atexit()-registered finalizers are run
- stdio streams are flushed and closed (although it could probably
done by the interpreter)
- files created with tmpfile() are removed (on POSIX systems, they're
removed after creation, but you can imagine an implementation where
they would need to be explicitely removed upon close)
This would not be performed if the signal is raised.
Since the user has the possibility of restoring default signal
handlers with SIG_DFL, I think we could stcik with the current
behavior.

> Because calling exit() is the right way to end a process. For example,
> it does the following:
> - atexit()-registered finalizers are run
> - stdio streams are flushed and closed (although it could probably
> done by the interpreter)
> - files created with tmpfile() are removed (on POSIX systems, they're
> removed after creation, but you can imagine an implementation where
> they would need to be explicitely removed upon close)
> 
> This would not be performed if the signal is raised.
> Since the user has the possibility of restoring default signal
> handlers with SIG_DFL, I think we could stcik with the current
> behavior.
Ah, ok, I agree with you, then.