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-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org