httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <>
Subject Re: mod_fcgi segementation fault and loss of MaxProcessCount
Date Thu, 11 Feb 2010 17:36:15 GMT
On Thu, Feb 11, 2010 at 11:19 AM, Jonathan Petersson
<> 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

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.

View raw message