classification
Title: On KeyboardInterrupt, the exit code should mirror the signal number
Type: enhancement Stage: resolved
Components: Interpreter Core Versions: Python 3.3
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: Arfrever, eric.araujo, loewis, nadeem.vawda, neologix, pitrou, rosslagerwall
Priority: normal Keywords:

Created on 2012-03-08 20:21 by pitrou, last changed 2012-10-13 22:26 by nadeem.vawda. This issue is now closed.

Messages (10)
msg155174 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-03-08 20:21
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.
msg155209 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2012-03-09 07:14
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).
msg155244 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-03-09 16:38
Another problem with my suggestion is that C exit() ANDs the status with 255 before transmitting it to the parent.
msg155245 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-03-09 16:40
(faulthandler works around that problem by restoring the previous signal handler and calling raise(), apparently)
msg155353 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2012-03-10 21:39
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.
msg155354 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-03-10 21:44
> 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.
msg156446 - (view) Author: Charles-François Natali (neologix) * (Python committer) Date: 2012-03-20 18:56
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
msg156447 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-03-20 19:05
> 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.
msg156458 - (view) Author: Charles-François Natali (neologix) * (Python committer) Date: 2012-03-20 20:34
>> 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.
msg157304 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-04-01 15:39
> 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.
History
Date User Action Args
2012-10-13 22:26:13nadeem.vawdasetstatus: open -> closed
resolution: rejected
stage: resolved
2012-04-01 15:39:52pitrousetmessages: + msg157304
2012-03-20 20:34:53neologixsetmessages: + msg156458
2012-03-20 19:05:54pitrousetmessages: + msg156447
2012-03-20 18:56:38neologixsetmessages: + msg156446
2012-03-10 23:03:56Arfreversetnosy: + Arfrever
2012-03-10 21:44:44pitrousetmessages: + msg155354
2012-03-10 21:39:30eric.araujosetnosy: + eric.araujo
messages: + msg155353
2012-03-10 05:04:29rosslagerwallsetnosy: + rosslagerwall
2012-03-09 16:40:37pitrousetmessages: + msg155245
2012-03-09 16:38:57pitrousetmessages: + msg155244
2012-03-09 07:14:34loewissetmessages: + msg155209
2012-03-08 20:28:07nadeem.vawdasetnosy: + nadeem.vawda
2012-03-08 20:21:24pitroucreate