If you are running PHP on a limited-resource box, like a VPS then you may have seen your PHP pages randomly hang. I was able to trace this issue down because the PHP pages were hung up and the normal html pages were still being served. The problem was ‘solved’ when I restarted the web server. Some research later, and talking to Thilo (bangert), I found out about PHP_FCGI_MAX_REQUESTS. This is an environment variable that PHP respects, it basically tells how many requests to serve before respawning fcgi. In my case, 500 seemed like a good number after testing. Your mileage may vary, but it is worth a try if you have those symptoms.
%% cat /etc/lighttpd/mod_fastcgi.conf
server.modules += ("mod_fastcgi")
fastcgi.server = ( ".php" =>
( "localhost" =>
(
"socket" => "/var/run/lighttpd/lighttpd-fastcgi-php-" + PID + ".socket",
"bin-path" => "/usr/bin/php-cgi",
"max-procs" => "2", # default 4
"bin-environment" => (
"PHP_FCGI_CHILDREN" => "2", # default 1
"PHP_FCGI_MAX_REQUESTS" => "500" #default 1000
)
)
)
)
I could be mistaken here, and correct me if I’m wrong, but I think you may be confusing PHP_FCGI_CHILDREN with the -F parameter of spawn-fcgi. By default, spawn-fcgi spawns a single parent process with $PHP_FCGI_CHILDREN children. The wildcard here is the “max-procs” fastcgi configuration parameter in lighttpd itself. When I was using lighttpd, I didn’t use it at all; I merely used PHP_FCGI_CHILDREN to indicate how many children the single parent process should spawn to handle requests, and I usually kept it, depending on the size of the server, between 8 and 32. Actually, I still do, using spawn-fcgi with nginx.
Actually, the more reading I do, the more I’m convinced that lighttpd’s fastcgi.server is trying to act as a process manager for php-cgi, but php-cgi is too. To keep fastcgi.server from doing process management, I would guess “max-procs” and “min-procs” should be “1″, and PHP_FCGI_CHILDREN and PHP_FCGI_MAX_REQUESTS must be set to allow php-cgi to act as its own process manager.