Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (athena.apache.org: domain of
 andriy.gapon@hybridcluster.com designates 37.59.20.28 as permitted sender)
Message-ID: <5230538E.1060409@hybridcluster.com>
Date: Wed, 11 Sep 2013 14:27:10 +0300
From: Andriy Gapon <andriy.gapon@hybridcluster.com>
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64;
 rv:17.0) Gecko/20130810 Thunderbird/17.0.8
MIME-Version: 1.0
To: dev@httpd.apache.org, =?UTF-8?B?UHFmIOa9mOW6huWzsA==?=
 <pqf@mailtech.cn>
Subject: Re: unreaped zombie children of mod_fcgid
References: <522EF30F.6040802@hybridcluster.com>
 <6f74d2f4.13.1410aa00467.Coremail.pqf@mailtech.cn>
 <523009A6.7080400@hybridcluster.com>
In-Reply-To: <523009A6.7080400@hybridcluster.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

on 11/09/2013 09:11 Andriy Gapon said the following:
> I've been thinking about this problem and the only theory that I have got so far
> is that perhaps an owner httpd process could terminate ungracefully (e.g.
> crash).  In that case the pool cleanup would never be run.  That's OK for
> process local resources like memory or file descriptors, which would be freed by
> OS because the process dies anyway.  But that's not OK for external resources
> like other processes.
> In other words, if an httpd process marks an fcgid process as busy and then
> suddenly dies, then there is nobody to move the fcgid process back to the idle list.

Just an idea: perhaps scan_busylist should move a process to a different list
(the error list?) after treating it with proc_kill_force?
Currently the processes on the busy list are never checked for being a zombie.
With the proposed change they should be correctly reaped after all the waiting
and killing.

-- 
Andriy Gapon