Package: libapache2-mod-fcgid
Version: 1:2.3.5-2
Severity: grave
Justification: renders package unusable
I am currently happily using mod_fcgid on a system running lenny
(version 2.2). When testing version 2.3.5 of the module I found that it
seems to spawn new FastCGI servers a lot, and ignores any limits that I
have configured.
First, the packages I'm testing with:
ii apache2-mpm-worker 2.2.9-10+lenny8 Apache HTTP Server - high speed
threaded model
ii libapache2-mod-fcgid 1:2.3.5-2 an alternative module compat with
mod_fastcgi
ii php5-cgi 5.2.6.dfsg.1-1+lenny server-side, HTML-embedded
scripting language (CGI binar
In my main Apache configuration, I have the following directive:
DefaultMaxClassProcessCount 5
In the .htaccess file for my test site, I have:
AddHandler fcgid-script .php
FCGIWrapper /srv/www/test.example/cgi-bin/php5 .php
The wrapper script is quite simple; it only exists to work around mod_suexec's
uid/gid match
checks:
#!/bin/sh
set -e
exec /usr/lib/cgi-bin/php5
So, having set this up, I run 'ab -c 15 -n 500
http://test.example.com/test.php'. This results in hundreds of PHP
processes being spawned...
$ pstree -u $(</var/run/apache2.pid)
apache2─┬─apache2(www-data)
├─apache2(www-data)───335*[php5(www-test)]
└─2*[apache2(www-data)───26*[{apache2}]]
... and these log messages:
[Thu Sep 02 16:47:47 2010] [error] (24)Too many open files: mod_fcgid: couldn't
set child process attributes: /var/lib/apache2/fcgid/sock/13843.335
[Thu Sep 02 16:47:47 2010] [warn] (24)Too many open files: mod_fcgid: spawn
process /srv/www/test.example/public_html/test.php error
With version 1:2.2-1 of the module, mod_fcgid correctly stops spawning
at 5 processes. Even if I remove the DefaultMaxProcessCount directive,
the same stress test only causes 11 php5 processes to be spawned.
I have tried to debug this but don't have the complete answer. mod_fcgid
calls the apply_free_procnode function to look for an existing spawned
process to handle a request. This search always seems to fail,
because the share_grp_id seems to change for every request. Hence,
apply_free_procnode returns NULL and a new process is spawned for each
request.
This also explains why the maximum process count is not obeyed:
the is_spawn_allowed function does a similar search, the mismatch for
which causes it to assume that there are no existing processes that will
handle the request, so it always returns 1.
Unfortunately I don't really know what the share_grp_id number is, or
why it changes for each request. :(
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
