Return-Path: 
 <dev-return-67713-apmail-httpd-dev-archive=httpd.apache.org@httpd.apache.org>
Delivered-To: apmail-httpd-dev-archive@www.apache.org
Received: (qmail 10872 invoked from network); 12 Feb 2010 13:32:38 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3)
  by minotaur.apache.org with SMTP; 12 Feb 2010 13:32:38 -0000
Received: (qmail 27423 invoked by uid 500); 12 Feb 2010 13:32:37 -0000
Delivered-To: apmail-httpd-dev-archive@httpd.apache.org
Received: (qmail 27343 invoked by uid 500); 12 Feb 2010 13:32:36 -0000
Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
list-help: <mailto:dev-help@httpd.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@httpd.apache.org>
List-Post: <mailto:dev@httpd.apache.org>
List-Id: <dev.httpd.apache.org>
Delivered-To: mailing list dev@httpd.apache.org
Received: (qmail 27334 invoked by uid 99); 12 Feb 2010 13:32:36 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 12 Feb 2010 13:32:36 +0000
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
	tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: local policy)
Received: from [193.17.218.81] (HELO mail.binero.se) (193.17.218.81)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 12 Feb 2010 13:32:28 +0000
Received: from [192.168.1.137] ([10.8.0.18])
        by mail.binero.se (IceWarp 9.4.2) with ASMTP (SSL) id UPS45307;
        Fri, 12 Feb 2010 14:32:07 +0100
Message-ID: <4B755857.2070209@binero.se>
Date: Fri, 12 Feb 2010 14:32:07 +0100
From: Jonathan Petersson <jonathan.petersson@binero.se>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US;
 rv:1.9.1.7) Gecko/20100111 Lightning/1.0b2pre Thunderbird/3.0.1
MIME-Version: 1.0
To: dev@httpd.apache.org
CC: Jeff Trawick <trawick@gmail.com>
Subject: Re: mod_fcgi segementation fault and loss of MaxProcessCount
References: <4B742DF9.20002@binero.se>
 <cc67648e1002110936g459d589bkc3794c473b147d5e@mail.gmail.com>
 <4B74524F.6020704@binero.se>
In-Reply-To: <4B74524F.6020704@binero.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked by ClamAV on apache.org

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.