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 Thu, 11 Feb 2010 18:54:07 GMT
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