Re: Apache2 PHP mod_fcgi HTTP 500 errors

That's certainly been my experience; that's how the PHP developers chose to 
implement the FastCGI library.  However, if you can live with the 
dynamicMxClassProcs errors, it should work OK.  You might also want to set 
PHP_CHILDREN (or whatever the ENV is these days) to something closer to 2 or 4 
so you don't get 8 springing up each time a web site takes a hit.

David.

-----

On Fri, 28 Oct 2005, [email protected] wrote:

> 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/
>

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