[issue25666] Python unexpectedly ignores a signal after fork
New submission from jon orebro: Description: I found a slight problem with signal handling. It seems that if you have a signal handler setup for a signal, right after a fork the child ignores that signal for a short time. This is regardless of what the signal handler is setup to do. This can cause hangs if the parent immediately kills and then waits for the child. Since the timeframe is small, in practice this only happens sometimes (se example). There might be a reason for this behavour, but in that case I think it should me mentioned in the docs. What I expected: I expected the child to, at any point in time, either do the default action for the signal (terminate in this case), or to run the signal handler. What happens: It ignores the signal for a short while. Tested versions: Python 2.7.6 Python 3.4.0 ---------- assignee: docs@python components: Documentation, Interpreter Core files: example.py messages: 254890 nosy: docs@python, jon orebro priority: normal severity: normal status: open title: Python unexpectedly ignores a signal after fork type: behavior versions: Python 2.7, Python 3.4 Added file: http://bugs.python.org/file41074/example.py _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue25666> _______________________________________
R. David Murray added the comment: Are you sure this is a python issue and not an OS issue? That is, does an equivalent C program work correctly? Since the operation is a fork, I don't think there's anything that python does that would cause the signal to be ignored. The comment block in the example code here: https://www.win.tue.nl/~aeb/linux/lk/lk-5.html makes me think that the signal getting ignored is a possibility at the OS level, though it isn't explicitly clear. ---------- nosy: +r.david.murray _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue25666> _______________________________________
Martin Panter added the comment: Here is a modified version of the script that is not a slow fork bomb. In the original, if time.sleep(600) fails to be interrupted, the children end up continuing the loop and forking more children. I tried Python 3.5, 2.7 and 3.4. I am seeing the signal completely ignored (at the Python level), not just ignored “for a short while”. Here is a sample output: $ python3 example.py Python handler called Parent waiting for child Got exit status 0x0000 === Parent waiting for child Child: 0 Child: 1 Child: 2 Child: 3 Child: 4 Child: 5 Got exit status 0x0100 David may be right that it is an OS thing, though it does not seem likely IMO. It needs more investigation or expert knowledge. But I would like to point out that even if the bug of the signal being completely ignored is fixed, the code still has a race condition. The signal could arrive in the window between when Python checks for signals and when it calls sleep(). Then the signal will be ignored until sleep() has returned. If you need this code to be robust, I suggest looking at set_signal_fd() and select(). ---------- nosy: +martin.panter versions: +Python 3.5, Python 3.6 Added file: http://bugs.python.org/file41089/example.py _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue25666> _______________________________________
Martin Panter added the comment: I think I figured out the problem. The signal module has a “main_pid” variable which it checks inside the low-level handler: <https://hg.python.org/cpython/file/v3.5.1/Modules/signalmodule.c#l300>. It looks like main_pid gets updated inside PyOS_AfterFork(), but I guess there is a race with a signal being received before main_pid is updated. Maybe there should be some signal masking/blocking or something in the critical section between fork() and PyOS_AfterFork()? ---------- versions: -Python 3.4 _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue25666> _______________________________________
participants (3)
-
jon orebro -
Martin Panter
-
R. David Murray