httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Petersson <jonathan.peters...@binero.se>
Subject Re: mod_fcgi segementation fault and loss of MaxProcessCount
Date Fri, 12 Feb 2010 13:32:07 GMT
So I just upgraded to SVN HEAD and are trying to replicate the issue but 
something seams funky.

Just to trigger issues I've set the following:
MaxProcessCount 1
DefaultMaxClassProcessCount 1

Using 2.3.4 I get:
[Fri Feb 12 14:20:17 2010] [notice] mod_fcgid: too many 
/var/www/html/test.php processes (current:1, max:1), skip the spawn request

But using SVN HEAD there's no output at all.

Is there some new flags which mod_fcgi has to be configured with to get 
this output?

Thanks

-Jonathan

On 2010-02-11 19:54, Jonathan Petersson wrote:
> Thanks for your feedback, I'll check out the latest code and see if it 
> works any better.
>
> /Jonathan
>
> On 02/11/2010 06:36 PM, Jeff Trawick wrote:
>> On Thu, Feb 11, 2010 at 11:19 AM, Jonathan Petersson
>> <jonathan.petersson@binero.se>  wrote:
>>> Hi all,
>>>
>>> I've a few selected servers on which I've started getting issues with
>>> mod_fcgi on. All of these servers are generally overloaded which 
>>> partially
>>> is the source of this issue.
>>>
>>> Anyhow to break down the problem there's multiple portions we have the
>>> following:
>>> - "Normal"/"Simple" PHP-scripts (we're talking Hello World) are 
>>> sticking
>>> around and utilizes the full IdleTimeout even though they've finished
>>> processing before exiting
>> Isn't that Working as Designed?  Idle apps aren't subject to
>> termination until after IdleTimeout?  (perhaps I misunderstood you)
>>
>>> - On numerous occasions mod_fcgi segfaults returns: [notice] child 
>>> pid<pid>
>>> exit signal Segmentation fault (11), I take it that this happens when a
>>> mod_fcgi wrapper terminates, however something tells me it shouldn't
>>> segfault on exit
>> A fix for an httpd child process crash in mod_fcgid was recently
>> committed; the crash occurred when the FastCGI app didn't write any
>> response headers or body before closing the connection.  I don't know
>> if any of your apps could do that.
>>
>> Can you get a coredump and backtrace from the crash?
>>
>>> - mod_fcgi drops MaxProcessCount to 0 [notice] mod_fcgid: too many
>>>   processes (current:0, max:0), skip the spawn request, prior to 
>>> this the
>>> server generally says [notice] mod_fcgid:<path>/<script>.php total

>>> process
>>> count 120>= 120, skip the spawn request (again due to overload)
>> Those messages have different meanings.  The one with "total process
>> count" is based on FcgidMaxProcesses (MaxProcessCount).  The one that
>> shows bad data is based on FcgidMaxProcessesPerClass
>> (DefaultMaxClassProcessCount).
>>
>> I don't see what is corrupting FcgidMaxProcessPerClass.  Just maybe
>> the segfaults occurred while initializing the data structure where
>> that was picked up, but I don't think that is likely.
>>
>>> 1 and 2 is survivable but once MaxProcessCount drops we have to restart
>>> apache to get things rollin again which isn't all that great.
>>>
>>> Here's the config I'm using, we have the exact same on multiple 
>>> servers on
>>> which we don't have any issues with.
>>>
>>> <IfModule mod_fcgid.c>
>>> AddHandler fcgid-script .fcgi
>>> SharememPath /var/lib/fcgid/shm
>>> SocketPath /tmp/fcgid_sock
>>> IdleTimeout 60
>>> ProcessLifeTime 7200
>>> MaxProcessCount 120
>>> IPCCommTimeout  300
>>> IPCConnectTimeout 8
>>> DefaultMaxClassProcessCount 5
>>> DefaultMinClassProcessCount 0
>>> </IfModule>
>> That looks reasonable to me, though perhaps it would perform better
>> with a higher DefaultMaxClassProcessCount?  Are apps getting
>> terminated frequently and replaced shortly thereafter?
>>
>> --/--
>>
>> I think the best plan is to try to solve the segfault then proceed 
>> from there.


Mime
View raw message