Re: Apache2 PHP mod_fcgi HTTP 500 errors

Hi all,

I still got a question on this.
So what you are saying is, that PHP is just not going to run smoothly with
a FastCgiConfig (dynamic) setup?

Defining a static config is not an option I'm affraid becasue it does not
allow me to specify VirtualHost specific configurations, so using suexec
for security is not possible then.
Also, with a static config all PHP processes will keep running, which is
fine ifyour talking about 1 site, not when you try to server thousands of
websites...

We have the same problem with our FastCgi setup. I get a lot of:
Oct 28 10:05:01 www3 fcgi-[6285]: [warn] FastCGI: scheduled the start of
the last (dynamic) server "/path/to/php.sh" process: reached
dynamicMaxClassProcs (1)
errors.

Is there really no way to get this working properly? Is it an option to
let FastCgi manage the processes and define zero children for PHP?

Thanks for your time,
Regards,

Ruben van der Zwan



> Ah - you are using dynamic.  That don't mix with PHP, sadly.
>
> I recommend that you use static, and not dynamic, since PHP has its own
> process
> manager.  Or, if you use dynamic, you tune it carefully to ensure it
> doesn't
> ever stop running.  FastCGI can't tell what's going on properly, because
> the
> number of servers it *thinks* are running does not equal the number that
> actually are.  I think if you set the maxprocesses to 1, dynamic might
> work
> right, but I've never tried it.
>
> We've run PHP in static mode with no problems.
>
> David.
>
> -----
>
> On Mon, 24 Oct 2005, Stefan Wendt wrote:
>
>> 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/
>>
>
>



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