➜
This issue trackerhas been migrated toGitHub, and is currentlyread-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.
Created on2017-04-27 10:51 bypitrou, last changed2022-04-11 14:58 byadmin. This issue is nowclosed.
| Files | ||||
|---|---|---|---|---|
| File name | Uploaded | Description | Edit | |
| forkserversignal.py | pitrou,2017-04-27 10:53 | |||
| Pull Requests | |||
|---|---|---|---|
| URL | Status | Linked | Edit |
| PR 1319 | merged | pitrou,2017-04-27 12:21 | |
| PR 1454 | merged | pitrou,2017-05-04 14:57 | |
| PR 1455 | merged | pitrou,2017-05-04 15:01 | |
| Messages (11) | |||
|---|---|---|---|
| msg292420 -(view) | Author: Antoine Pitrou (pitrou)* | Date: 2017-04-27 10:51 | |
The forkserver intermediate process is an implementation detail. However, if you Ctrl-C the main process, the forkserver process will exit with a KeyboardInterrupt traceback, even if the main process catches KeyboardInterrupt to exit silently. This produces stderr such as:$ ./python forkserversignal.py ^CTraceback (most recent call last): File "<string>", line 1, in <module> File "/home/antoine/cpython/default/Lib/multiprocessing/forkserver.py", line 164, in main rfds = [key.fileobj for (key, events) in selector.select()] File "/home/antoine/cpython/default/Lib/selectors.py", line 445, in select fd_event_list = self._epoll.poll(timeout, max_ev)KeyboardInterruptFor the sake of usability, forkserver should probably silence those tracebacks by default, for example by changing the default signal handler in the forkserver process (but children forked by the forkserver process should probably get the default Python signal handlers...).Not sure this can be considered a bugfix or an enhancement. | |||
| msg292421 -(view) | Author: Antoine Pitrou (pitrou)* | Date: 2017-04-27 10:53 | |
Uploading small reproducer script. | |||
| msg292422 -(view) | Author: Antoine Pitrou (pitrou)* | Date: 2017-04-27 10:55 | |
A simpler solution would actually be to catch KeyboardInterrupt inside the forkserver loop and exit cleanly... | |||
| msg292425 -(view) | Author: STINNER Victor (vstinner)* | Date: 2017-04-27 11:32 | |
> A simpler solution would actually be to catch KeyboardInterrupt inside the forkserver loop and exit cleanly...I'm not sure that we always want to exit on CTRL-c. But I agree that the forkserver has to handle CTRL-c. Maybe ignore it, but be killed when its master gets a CTRL-c? | |||
| msg292426 -(view) | Author: Antoine Pitrou (pitrou)* | Date: 2017-04-27 11:39 | |
> I'm not sure that we always want to exit on CTRL-c.That's what the forkserver does right now, it's just that it does it with a traceback that's useless to the user.> Maybe ignore it, but be killed when its master gets a CTRL-c?That's a possibility (the forkserver should already exit automatically when its parent dies), the problem is what to do for the forkserver's children? Should they restore the default signal handler?Simply silencing the KeyboardInterrupt traceback at least is a straightforward solution with little risk of side effects. | |||
| msg292983 -(view) | Author: Antoine Pitrou (pitrou)* | Date: 2017-05-04 14:44 | |
New changeset6dd4d734ed207ba16b017e38f8909de7ef187e29 by Antoine Pitrou in branch 'master':bpo-30185: avoid KeyboardInterrupt tracebacks in forkserver (#1319)https://github.com/python/cpython/commit/6dd4d734ed207ba16b017e38f8909de7ef187e29 | |||
| msg292986 -(view) | Author: Antoine Pitrou (pitrou)* | Date: 2017-05-04 15:12 | |
New changeseta7e48b544becc01dbf9059ed01f38997c6d0156c by Antoine Pitrou in branch '3.6':[3.6]bpo-30185: avoid KeyboardInterrupt tracebacks in forkserver (GH-1319) (#1454)https://github.com/python/cpython/commit/a7e48b544becc01dbf9059ed01f38997c6d0156c | |||
| msg292989 -(view) | Author: Antoine Pitrou (pitrou)* | Date: 2017-05-04 15:16 | |
New changeset7299088ccf5f72b8494063814b58a180b4250aa7 by Antoine Pitrou in branch '3.5':[3.5]bpo-30185: avoid KeyboardInterrupt tracebacks in forkserver (GH-1319) (#1455)https://github.com/python/cpython/commit/7299088ccf5f72b8494063814b58a180b4250aa7 | |||
| msg292996 -(view) | Author: STINNER Victor (vstinner)* | Date: 2017-05-04 16:09 | |
Python 2.7 isn't affected by this bug? | |||
| msg292997 -(view) | Author: Antoine Pitrou (pitrou)* | Date: 2017-05-04 16:12 | |
There is no forkserver in 2.7. | |||
| msg292998 -(view) | Author: STINNER Victor (vstinner)* | Date: 2017-05-04 16:19 | |
> There is no forkserver in 2.7.Oh right, it's specific to forkserver, ok ;-) Thank you for the fix. | |||
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2022-04-11 14:58:45 | admin | set | github: 74371 |
| 2017-05-04 16:19:48 | vstinner | set | messages: +msg292998 |
| 2017-05-04 16:12:16 | pitrou | set | messages: +msg292997 |
| 2017-05-04 16:09:18 | vstinner | set | messages: +msg292996 |
| 2017-05-04 15:17:42 | pitrou | set | status: open -> closed resolution: fixed stage: needs patch -> resolved |
| 2017-05-04 15:16:51 | pitrou | set | messages: +msg292989 |
| 2017-05-04 15:12:39 | pitrou | set | messages: +msg292986 |
| 2017-05-04 15:01:22 | pitrou | set | pull_requests: +pull_request1553 |
| 2017-05-04 14:57:09 | pitrou | set | pull_requests: +pull_request1552 |
| 2017-05-04 14:44:55 | pitrou | set | messages: +msg292983 |
| 2017-04-27 12:21:11 | pitrou | set | pull_requests: +pull_request1426 |
| 2017-04-27 11:39:37 | pitrou | set | messages: +msg292426 |
| 2017-04-27 11:32:30 | vstinner | set | nosy: +vstinner messages: +msg292425 |
| 2017-04-27 10:55:36 | pitrou | set | messages: +msg292422 |
| 2017-04-27 10:53:01 | pitrou | set | files: +forkserversignal.py messages: +msg292421 |
| 2017-04-27 10:51:47 | pitrou | create | |