If you have PHP setup via the default 'mod_fastcgi.conf' that is installed via the ebuild, you should be able to observe the problem as follows: # /etc/init.d/lighttpd start * Starting lighttpd ... [ ok ] # ps ax | grep php 1481 ? Ss 0:00 /usr/bin/php-cgi 1482 ? S 0:00 /usr/bin/php-cgi 1485 ? Ss 0:00 /usr/bin/php-cgi 1486 ? S 0:00 /usr/bin/php-cgi 1487 ? Ss 0:00 /usr/bin/php-cgi 1488 ? S 0:00 /usr/bin/php-cgi 1489 ? Ss 0:00 /usr/bin/php-cgi 1490 ? S 0:00 /usr/bin/php-cgi 1747 pts/13 S+ 0:00 grep --colour=auto php # /etc/init.d/lighttpd graceful * Gracefully stopping lighttpd ... [ ok ] * Starting lighttpd ... [ ok ] # ps ax | grep php 1795 pts/13 S+ 0:00 grep --colour=auto php As you can see, the php process don't come back after a restart. This affects lighttpd with and without the init script changes from bug 168865. The reason is outlined in the lightppd trac bug I have referenced above. The solution (with any lighttpd 1.4.5 or later) is very simple -- Replace the "host" / "port" section of the mod_fastcgi.conf with a "socket" that contains the current lighttpd PID somewhere in it. For example, the following snipped from my mod_fastcgi.conf works great for me: fastcgi.server = ( ".php" => ( "localhost" => ( "socket" => "/tmp/lighttpd-fastcgi-php-" + PID + ".socket", "bin-path" => "/usr/bin/php-cgi" ) ) ) Note the addition of the 'PID' variable (as opposed to 'pid' as is suggested in the original trac bug). I may create a patch against the ebuild, time permitting, and paste it here when I have it done.
Created attachment 113307 [details] files/conf/mod_fastcgi.conf This is a replacement for the existing mod_fastcgi.conf in the ebuild. Works for me :)
fixed in cvs. notice that I used a safer directory setup instead of /tmp.
