YMMV, but I had a *lot* of trouble using spawn-fcgi + php. Processes would stop responding to requests after a while for no reason. Turns out PHP has a hard limit on the number of requests it can take before re-spawning a child and spawn-fcgi didn't honor that limit, passing requests to quitting children.

I posted this information to the list and forums but was ignored, which expidited the move to nginx. I'm now running php-cgi with the -b switch on a number of production servers without issue (php-fpm wouldn't compile for me at the time).

Cliff Wells wrote:

For those people who, for various reasons, can't or don't want to compile PHP with php-fpm (or for anyone who needs to spawn FCGI processes in general), spawn-fcgi has been split out of Lighttpd into its own project (message below).

Regards, Cliff

-------- Forwarded Message -------- From: Stefan Bühler <ligh...@stbuehler.de> To: ligh...@lists.lighttpd.net Subject: [lighttpd-announce] spawn-fcgi-1.6.0rc1-r16 prerelease Date: Thu, 19 Feb 2009 00:42:13 +0100

Prerelease of spawn-fcgi 1.6.0 (rc1-r16)

*spawn-fcgi extracted into own project*

There are several versions of spawn-fcgi (one in lighttpd 1.4.x, one in 1.5.x and one in cherokee), which makes packaging very hard (e.g.: debian packages spawn-fcgi from lighty as "spawn-fcgi.lighttpd" - which makes using it more complicated as your scripts are probably using "spawn-fcgi"...). Additionally, keeping the sources and bug fixes synchronized is just too much work (ok, the one in cherokee isn't our problem :) ). Therefore we decided to split spawn-fcgi into a new project which will start with version 1.6.0 (and will be independent of lighttpd releases).

We plan to remove spawn-fcgi from lighttpd-1.4.x after the release of lighttpd-1.4.22.

You can find the new project at http://redmine.lighttpd.net/projects/spawn-fcgi/wiki

In case you would like to test a spawn-fcgi version with more features (options for chown the socket), see here: http://cgit.stbuehler.de/gitosis/spawn-fcgi/about/ (needs glib)

*Important changes*

- Removed limits for @-C phpchildren@ option, which now justs sets @PHP_FCGI_CHILDREN@ if @phpchildren >= 0@ (default: ommited); php's default is @PHP_FCGI_CHILDREN = 0@, which means that the master process is the worker process. (not the same as @PHP_FCGI_CHILDREN = 1@, which results in one master watching its child). Instead of using the @-C@ option you can now just set the environment var before invoking spawn-fcgi. - Modified the log messages format

*Downloads*

- http://www.lighttpd.net/download/spawn-fcgi-1.6.0rc1-r16.tar.gz MD5: ff19abc92b74fd8c7099291aff0caa95 SHA1: 883ccaeb9be21e0eda2f03b37e43795abf403845 - http://www.lighttpd.net/download/spawn-fcgi-1.6.0rc1-r16.tar.bz2 MD5: 19099d04b133222329f1f6eed12b6398 SHA1: f6fb10a5c71a3d7b23889be614c5ecb232ce4563 - SHA1 checksums: http://www.lighttpd.net/download/spawn-fcgi-1.6.0rc1-r16.sha1sum - MD5 checksums: http://www.lighttpd.net/download/spawn-fcgi-1.6.0rc1-r16.md5sum

*Changes*

- Separated spawn-fcgi from lighttpd - Remove limits für php children; per default the PHP_FCGI_CHILDREN var is not changed (php defaults to no children, one worker) - Modified the log messages format (more details on errors, no source line) - Only try to connect to unix socket (not tcp) before spawning (fixes again #1575) - Only disconnect from terminal in fork mode (keep stderr/stdout open in nofork mode) - Allow numerical user and group ids for -u/-g (fixes #1141) - Ignore pid-file option in no-fork mode (instead of producing empty file) - Fix error handling for unix-socket-connect test

--

Phillip B Oldham The Activity People phi...@theactivitypeople.co.uk

________________________________

Policies

This e-mail and its attachments are intended for the above named recipient(s) only and may be confidential. If they have come to you in error, please reply to this e-mail and highlight the error. No action should be taken regarding content, nor must you copy or show them to anyone.

This e-mail has been created in the knowledge that Internet e-mail is not a 100% secure communications medium, and we have taken steps to ensure that this e-mail and attachments are free from any virus. We must advise that in keeping with good computing practice the recipient should ensure they are completely virus free, and that you understand and observe the lack of security when e-mailing us.