New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
On KeyboardInterrupt, the exit code should mirror the signal number #58437
Comments
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:
|
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 Processes that want default behavior upon signal reception (so that $ 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 |
Why would it be ugly? faulthandler does exactly that. |
Because calling exit() is the right way to end a process. For example,
This would not be performed if the signal is raised. |
Ah, ok, I agree with you, then. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: