Uploaded image for project: 'mod_python'
  1. mod_python
  2. MODPYTHON-109

Signal handler calling Py_Finalize() when child processes being killed.

    Details

    • Type: Bug
    • Status: Reopened
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: 3.2.7
    • Fix Version/s: None
    • Component/s: core
    • Labels:
      None

      Description

      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.

        Attachments

          Activity

            People

            • Assignee:
              grahamd Graham Dumpleton
              Reporter:
              grahamd Graham Dumpleton
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated: