-
-
Notifications
You must be signed in to change notification settings - Fork 31.7k
asyncio: ugly error related to signal handlers at exit if the loop is not closed explicitly #70321
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
Comments
When using the suggested practice of setting a stop loop signal handler with: loop.add_signal_handler(signal.SIGTERM, loop.stop) The following stack trace is given when the signal runs: ligament_1 | Exception ignored in: <bound method BaseEventLoop.__del__ of <_UnixSelectorEventLoop running=False closed=True debug=False>>
ligament_1 | Traceback (most recent call last):
ligament_1 | File "/usr/lib/python3.5/asyncio/base_events.py", line 387, in __del__
ligament_1 | File "/usr/lib/python3.5/asyncio/unix_events.py", line 58, in close
ligament_1 | File "/usr/lib/python3.5/asyncio/unix_events.py", line 139, in remove_signal_handler
ligament_1 | File "/usr/lib/python3.5/signal.py", line 47, in signal
ligament_1 | TypeError: signal handler must be signal.SIG_IGN, signal.SIG_DFL, or a callable object Since this happens during shutdown of the application I wouldn't consider this a high priority bug but it is quite annoying. I've also not investigated if this interrupts the loop stopping procedure yet. |
Heh, this is weird. If the signal being removed is SIGTERM, the logic looks like it is definitely going to call signal.signal(signal.SIGTERM, signal.SIG_DFL). And it doesn't look like the signal module's globals have been eradicated yet (or you'd have gotten something like "TypeError: 'NoneType' object is not callable" instead). You seem to be using Python 3.5.0. Can you repro this with 3.5.1 or with the asyncio from github? Do you have a small self-contained program that repos it? |
The problem is that the signal module has been cleared when the destruction |
Victor, if the signal module has been cleared, how could it emit that error (I do agree with the solution you suggest -- though note that it may be |
FWIW, I am experiencing the issue described here with Python 3.5.1. |
|
Probably a good idea. See also python/asyncio#456. |
I dislike this option. If you want to use sys.is_finalizing(), I would prefer to modify _UnixSelectorEventLoop.close() to not try to remove signal handler if close() has been called too late during Python finalization. But I also expect a warning in this case, not hide bugs silently. If you reach this case, close() has probably been called by BaseEventLoop.__del__(). |
Implemented PR 4956 following Victor's suggestion. |
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: