[mod_python] Re: child process XXXX still did not exit, sending a SIGTERM

Graham Dumpleton grahamd at dscpl.com.au
Wed Jan 4 06:10:10 EST 2006

On 04/01/2006, at 9:29 PM, Graham Dumpleton wrote:
> My immediate question is why does Py_Finalize() even need to be called
> within the context of the child process if it is simply being killed 
> off
> anyway. I know that for the Apache main process if doing a restart that
> Py_Finalize() needs to be called as the same process is kept around,
> but for a child process I don't see the point except maybe to flush
> out stderr/stdout which aren't typically used in mod_python anyway.
> Time now to work out why python_finalize() needs to be called. Maybe
> it can't simply not do anything when called in the context of the child
> process.

That should have been "can simply" not "can't simply".

Anyway, one could put:

     if (child_init_pool)
         return APR_SUCCESS;

at the start of python_finalize() and that would at least avoid any 
with the signal handler trying to do complicated stuff like call into 
and cause a deadlock.

Even with this, it isn't going to avoid all problems as you can't 
eliminate the possible need for the Apache to forcibly kill the child
process. There simply could be reasons that the signal handler couldn't
run due to signals being blocked for example. For some reason I seem to
be seeing just this case in my test example on Mac OS X and I haven't 
worked out why the python_finalize() function isn't being run, 
that the signal handler isn't even being called.

Can you at least try the above little addition to python_finalize() and
see if it makes any difference in your specific case.


More information about the Mod_python mailing list