Repository navigation
asyncio: ugly error related to signal handlers at exit if the loop is not closed explicitly #70321
Description
Activity
AlexBrandt commented
on Jan 16, 2016 AlexBrandtmannequinMannequinAuthorWhen 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
has been called. You must not rely on destructors but call explicitly close
methods. Please run your app in asyncio debug mode and enable logs. See
asyncio doc.Victor, if the signal module has been cleared, how could it emit that error
message? signal.signal itself would no longer exist.(I do agree with the solution you suggest -- though note that it may be
tricky to close the loop from inside the signal callback for SIGTERM, which
is presumably what is going on here.)- changed the title
[-]TypeError: signal handler must be signal.SIG_IGN, signal.SIG_DFL, or a callable object in <bound method BaseEventLoop.__del__ of <_UnixSelectorEventLoop running=False closed=True debug=False>>[/-][+]asyncio: ugly error related signal handler at exit if the loop is not closed explicitly[/+]on Jan 19, 2016 - changed the title
[-]asyncio: ugly error related signal handler at exit if the loop is not closed explicitly[/-][+]asyncio: ugly error related to signal handlers at exit if the loop is not closed explicitly[/+]on Jan 19, 2016 hlellelid commented
on Feb 4, 2016 hlellelidmannequinMannequinFWIW, I am experiencing the issue described here with Python 3.5.1.
remove_signal_handler()should do nothing ifsys.is_finalizing()is true.remove_signal_handler()should do nothing ifsys.is_finalizing()is true.Probably a good idea.
See also python/asyncio#456.
remove_signal_handler()should do nothing ifsys.is_finalizing()is true.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__().
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: