Re: Apache2 PHP mod_fcgi HTTP 500 errors

Hi David,

The process you mean seams to work this way:
- each individual php child process has a counter
- if the counter is >= MAX REQUEST (something like 500) then the child 
terminates
- the php parent process detects that by the signal send from the child 
and forks a new child

This is all happening inside the compiled PHP_CGI though. You can 
obsever this
nicely with a trace on the php parent process.

I think the problem I have is not related to the communication inside 
the php_fcgi.

The documentation on mod_fcgi and fcgi indicate that there is some logic 
that automatically
starts-up and shuts-down php processes. Each php process is in turn 
responsible to fork the
MAX_CHILDREN  worker processes.

So I think the problem happens between the mod_fgci and the php parent 
process.

I am not sure what side to blame though. One could argue that PHP should 
wait
until all children are finished before exiting from the SIGTERM signal.
On the other hand one could think that mod_fcgi should not try to 
terminate a
php parent process before all jobs are finished.

Also, I don't want to rule out that there is something wrong with my setup.
I have to say that I am surprised to see the mod_fcgi to create more than
one php parent process. Frequently, I have more than 3 php parent processes
running each with 10 child processes all for the same virtual host. I 
expected
to see only one php parent process with 10 child process for each 
virtual host.

I am confused ;)

Thanks for your help ...
    Stefan Wendt

David Birnbaum wrote:

> Stefan,
>
> php seems to restart its children automatically from time to time, I 
> suspect as a way to get reclaim memory from leaks.  Is it possible the 
> problem is due to the php process not completing its work when it 
> receives the SIGTERM?
>
> David.
>
>>
>> I think the information below shows quite clearly that the fcgi-pm(?) 
>> terminates the
>> php process while 2 of it's child processes still work on a request.
>>
>> Thanks for having a look into this ...
>>   Stefan Wendt
>>

___________________________________
fastcgi-developers mailing list
http://fastcgi.com/fastcgi-developers/