You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@httpd.apache.org by Johannes Truschnigg <jo...@gmx.at> on 2007/08/07 00:37:43 UTC

[users@httpd] apache 2.2 + suexec + mod_fcgid 2.1 + php-cgi: nproc ulimit ineffective, rabid process spawning occurs

Hello everyone,

I'm running a webserver (Server version: Apache/2.2.4 (Unix)) on Gentoo 
GNU/Linux, Kernel 2.6.22 (x86, Gentoo patchset) for quite some time now, and 
cannot seem to fix my problems regarding a per-user 
number-of-processes-restriction I need to implement.

I'll post the sections of all the configs I consider relevant to the problem; 
I think that'll make it easiest for everyone interested to follow...

+-----
mod_fcgid.conf (this one's global to apache, it's mostly adopted verbatim from 
my distribution's defaults):
<IfDefine FCGID>
        SharememPath /var/run/fcgid_shm
        SocketPath /var/run/fcgid.sock
        IPCCommTimeout 45
        MaxProcessCount 12
        MaxRequestsPerProcess 500
        DefaultMaxClassProcessCount 4
        IdleTimeout 3600
        ProcessLifeTime 36000
        <IfModule !mod_fcgid.c>
                LoadModule fcgid_module modules/mod_fcgid.so
        </IfModule>
        <IfModule mod_fcgid.c>
                AddHandler fcgid-script .fcg
        </IfModule>
        <Location /fcgid>
                SetHandler fcgid-script
                Options ExecCGI
                allow from all
        </Location>
        <IfDefine PHP>
                AddHandler fcgid-script .php
        </IfDefine>
</IfDefine>
+-----


+-----
vhost.conf (irrelevant parts left out):
<VirtualHost *:80>
	#[...]
        ServerRoot "/home/www_michaelk/www/nicoleundmichael.at"
        DocumentRoot "/home/www_michaelk/www/nicoleundmichael.at/htdocs"
        <IfDefine SUEXEC>
                SuexecUserGroup "www_michaelk" "www_michaelk"
                <IfDefine FCGID>
                        <IfDefine PHP>
                                AddHandler fcgid-script .php
                        </IfDefine>
                        <IfDefine !PHP>
                                <FilesMatch "\.(php)$">
                                        Deny from all
                                </FilesMatch>
                        </IfDefine>
                </IfDefine>
        </IfDefine>
        <Directory "/home/www_michaelk/www/nicoleundmichael.at">
                AllowOverride None
                Order Deny,Allow
                Deny from all
        </Directory>
        <Directory "/home/www_michaelk/www/nicoleundmichael.at/htdocs">
                FCGIWrapper "/var/www/fcgi-wrap/www_michaelk/php.fcgi" .php
                AllowOverride AuthConfig FileInfo Options
                Options +ExecCGI
                Order deny,allow
                Allow from all
        </Directory>
</VirtualHost>
+-----

+-----
php.fcgi (this one's the wrapper invoking php):
#!/bin/bash
export PHPRC="/home/www_michaelk/conf/nicoleundmichael.at/"
export PHP_FCGI_CHILDREN=3
export PHP_FCGI_MAX_REQUESTS=15000
exec /usr/bin/php-cgi
+-----


+-----
/etc/security/limits.conf (relevant part only):
www_michaelk        hard        nproc           25
+-----

If I throw a real lot of requests (100K+) on one site hosted in this manner 
now, at some point, mod_fcgid begins spawning new processes seemingly without 
killing/discarding any old ones. I'd expect mod_fcgid to restrict the max. 
number of processes it dispatches requests to to the value 
of "MaxProcessCount", but this turns out not to be the case.
I always end up with one process above my actual ulimit (I suppose that's 
because of how Linux handles changing a process' effective user id, right?), 
leaving my users unable to login, because it's impossible for them to start a 
new shell.

I already tried fiddling with all the values I suspected of having an impact 
on the situation ("PHP_FCGI_CHILDREN" in the wrapper, "MaxProcessCount" and 
cousins in the mod_fcgid configuration), but nothing actually yielded 
success.

I'm running out of ideas on what to try next, so I figured I'd cry for help by 
posting here. I highly appreciate any sort of input that might lead me into 
the right direction to fix this - thanks in advance for your efforts!

If you feel there's need for additional info I did not provide yet, please 
don't hesitate to let me know.

-- 
with best regards:
- Johannes Truschnigg ( johannes.truschnigg@gmx.at )

www: http://johannes.truschnigg.info/
phone: +43 650 2 133337
jabber: johannes.truschnigg@gmail.com

Please do not bother me with HTML-eMail or attachments. Thank you.