-
-
Notifications
You must be signed in to change notification settings - Fork 523
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
Immediately forwarding Ctrl+C to child processes considered harmful #1497
Comments
I have looked further into this and it appears that in response to Marius' freak accident with the zope-testrunner (#1172) the code was changed from process.wait() to basically process.murder(). That's quite radical IMO and prone to issues like the above. I guess the only reason it did not come up earlier is that few test runners actually have to perform any cleanups. I am happy to turn this into a PR à la #1493 but would appreciate some feedback first. |
I think the patch makes sense - just tried it again after having upvoted it before already. My use case is running pytest in tox, where it often looks like this then (and often much worse/longer):
|
Feel free to open a PR against master and fix it. My available efforts at the moment are aimed at fixing this as part of #1394, but that probably will take a while (ETA September). |
Fixes tox-dev#1497 Ctrl+C sends a SIGTERM to both Tox and the running process, causing the running process to receive the signal twice once tox passes it along. This can often cancel or interfer with the process's cleanup. Instead, add an option to allow a process to suicide before sending the SIGTERM. Co-Authored-By: Stefan H. Holek <stefan@epy.co.at>
Fixes tox-dev#1497 Ctrl+C sends a SIGTERM to both Tox and the running process, causing the running process to receive the signal twice once tox passes it along. This can often cancel or interfer with the process's cleanup. Instead, add an option to allow a process to suicide before sending the SIGTERM. Co-Authored-By: Stefan H. Holek <stefan@epy.co.at>
Fixes tox-dev#1497 Ctrl+C sends a SIGTERM to both Tox and the running process, causing the running process to receive the signal twice once tox passes it along. This can often cancel or interfer with the process's cleanup. Instead, add an option to allow a process to suicide before sending the SIGTERM. Co-Authored-By: Stefan H. Holek <stefan@epy.co.at>
Fixes tox-dev#1497 Ctrl+C sends a SIGTERM to both Tox and the running process, causing the running process to receive the signal twice once tox passes it along. This can often cancel or interfer with the process's cleanup. Instead, add an option to allow a process to suicide before sending the SIGTERM. Co-Authored-By: Stefan H. Holek <stefan@epy.co.at>
Fixes tox-dev#1497 Ctrl+C sends a SIGTERM to both Tox and the running process, causing the running process to receive the signal twice once tox passes it along. This can often cancel or interfer with the process's cleanup. Instead, add an option to allow a process to suicide before sending the SIGTERM. Co-Authored-By: Stefan H. Holek <stefan@epy.co.at>
Fixes tox-dev#1497 Ctrl+C sends a SIGTERM to both Tox and the running process, causing the running process to receive the signal twice once tox passes it along. This can often cancel or interfer with the process's cleanup. Instead, add an option to allow a process to suicide before sending the SIGTERM. Co-Authored-By: Stefan H. Holek <stefan@epy.co.at>
I have a test runner which install unittests's signal handlers. When hitting Ctrl+C in tox, the test runner sometimes receives a SIGINT while in the process of shutting down. This seemed wrong, and I traced it down to tox unconditionally forwarding any received SIGINT. The situation however is that all foreground processes receive the SIGINT, not just tox, and when tox forwards it the test runner receives the SIGINT twice. My solution is to make tox wait for processes to go away on their own before starting to send signals.
Anyway, here is my patch (which no longer applies after #1493, but you get the idea):
The text was updated successfully, but these errors were encountered: