quetz-mod_python-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Graham Dumpleton (JIRA)" <j...@apache.org>
Subject [jira] Commented: (MODPYTHON-109) Signal handler calling Py_Finalize() when child processes being killed.
Date Fri, 03 Mar 2006 01:09:12 GMT
    [ http://issues.apache.org/jira/browse/MODPYTHON-109?page=comments#action_12368628 ] 

Graham Dumpleton commented on MODPYTHON-109:

It will be random as to whether a registered cleanup handler in this situation would be able
to run, let alone work.

Ignoring the fact that you are doing complicated stuff in a signal handler, which is nearly
always bad, the simple fact is that if a normal request handler is in the middle of handling
a request and is thus holding the GIL when the parent Apache process decides to send the signal,
the cleanup handler will block waiting to acquire the GIL.

On UNIX systems at least where a signal handler causes main thread and any other threads to
stop for the period the signal handler is run (not sure about Win32 where a signal handler
is a distinct thread) , the request handler will never be able to release the GIL so the cleanup
handler can't even begin to run.

Thus if you are lucky, the cleanup handler will not block and will run, but even then the
code is being run from a signal handler which will cause problems in itself and may result
in the process crashing.

All very dodgy.

> Signal handler calling Py_Finalize() when child processes being killed.
> -----------------------------------------------------------------------
>          Key: MODPYTHON-109
>          URL: http://issues.apache.org/jira/browse/MODPYTHON-109
>      Project: mod_python
>         Type: Bug
>   Components: core
>     Versions: 3.2
>     Reporter: Graham Dumpleton
>     Assignee: Graham Dumpleton

> When Apache is killing off child processes as part of actions taken when the "apachectl
restart" or "apachectl graceful" command is run, it sends a SIGTERM signal to the child processes.
This causes a signal handler registered by Apache to be run. That signal handler destroys
the main child memory pool. That memory pool has though a cleanup handler associated with
it which was registered by mod_python. That cleanup handler ultimately calls Py_Finalize().
> The problem with this is that Py_Finalize() isn't safe to be called from a signal handler
and if a handler is still executing or there is a separate thread running in the context of
Python, a deadlock will likely ensue. This will prevent the child process exiting due to the
SIGTERM causing the Apache parent process to send it a SIGKILL to really kill it.
> For a more detailed assessment of the problem and what lead to this conclusion see:
>   http://www.modpython.org/pipermail/mod_python/2006-January/019865.html
>   http://www.modpython.org/pipermail/mod_python/2006-January/019866.html
>   http://www.modpython.org/pipermail/mod_python/2006-January/019870.html
> To avoid the problem, the only choice seems to be avoid calling Py_Finalize() from the
signal handler. The simplistic way of doing this seems to be to add:
>      if (child_init_pool)
>          return APR_SUCCESS;
> at the start of python_finalize(). This will mean that Py_Finalize() is never called
in child processes. The full consequences of this is unknown, but on face value it would seem
that it might be a reasonable thing to do. More research may be required.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message