Re: mod_fcgi segementation fault and loss of MaxProcessCount

[Jonathan Petersson]

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.peters...@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.