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

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 
problems
with the signal handler trying to do complicated stuff like call into 
Python
and cause a deadlock.

Even with this, it isn't going to avoid all problems as you can't 
totally
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 
yet
worked out why the python_finalize() function isn't being run, 
suggesting
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.

Graham