I am running Debian Squeeze. I compiled nginx 1.0.5 since the one in Debian's repository was out of date, and I setup the fastcgi scripts in /usr/bin/php-fastcgi and /etc/init.d/php-fastcgi as per the Linode Library's article for php-fastcgi. This setup worked fine for about a month, but the nginx started giving my browser the "502 Bad Gateway" message. It does not appear in top, and I double checked the output of "ps -A | grep php ; ps -A | grep fastcgi ; ps -A grep spawn", and saw no output. The .pid file does exist in the /var/php-fastcgi when I start php-fastcgi, and disappears when I stop it; the process does not show up after starting it.

Output of starting, stopping and checking the status of php-fastcgi:

root@li283-45:~# /etc/init.d/php-fastcgi start
spawn-fcgi: child signaled: 11
root@li283-45:~# /etc/init.d/php-fastcgi status
php-fastcgi running with PID
root@li283-45:~# /etc/init.d/php-fastcgi stop
kill: usage: kill [-s sigspec | -n signum | -sigspec] pid | jobspec ... or kill -l [sigspec]
root@li283-45:~# /etc/init.d/php-fastcgi status
Could not find PID file /var/run/php-fastcgi/php-fastcgi.pid, php-fastcgi does not appear to be running

Steps I took to troubleshoot:
- I ssh'ed to my Linode to restart php-fastcgi, but it does not appear to be running after I start it.
-I reinstalled spawn-fcgi via apt-get (apt-get purge spawn-fcgi && apt-get install spawn-fcgi) to no avail.
-I also removed the scripts that I added from Linode Library and re-added them with a direct copy-and-paste as before, and adjusted the user and group to the ones I'm using for my nginx server (I'm using www, not www-data, and I triple-checked these were correct in the scripts, everything else is exactly the same).

Here are my scripts:

/etc/init.d/php-fastcgi:

#!/bin/bash

PHP_SCRIPT=/usr/bin/php-fastcgi
FASTCGI_USER=www
FASTCGI_GROUP=www
PID_DIR=/var/run/php-fastcgi
PID_FILE=/var/run/php-fastcgi/php-fastcgi.pid
RET_VAL=0

case "$1" in
    start)
      if [[ ! -d $PID_DIR ]]
      then
        mkdir $PID_DIR
        chown $FASTCGI_USER:$FASTCGI_GROUP $PID_DIR
        chmod 0770 $PID_DIR
      fi
      if [[ -r $PID_FILE ]]
      then
        echo "php-fastcgi already running with PID `cat $PID_FILE`"
        RET_VAL=1
      else
        $PHP_SCRIPT
        RET_VAL=$?
      fi
  ;;
    stop)
      if [[ -r $PID_FILE ]]
      then
        kill `cat $PID_FILE`
        rm $PID_FILE
        RET_VAL=$?
      else
        echo "Could not find PID file $PID_FILE"
        RET_VAL=1
      fi
  ;;
    restart)
      if [[ -r $PID_FILE ]]
      then
        kill `cat $PID_FILE`
        rm $PID_FILE
        RET_VAL=$?
      else
        echo "Could not find PID file $PID_FILE"
      fi
      $PHP_SCRIPT
      RET_VAL=$?
  ;;
    status)
      if [[ -r $PID_FILE ]]
      then
        echo "php-fastcgi running with PID `cat $PID_FILE`"
        RET_VAL=$?
      else
        echo "Could not find PID file $PID_FILE, php-fastcgi does not appear to be running"
      fi
  ;;
    *)
      echo "Usage: php-fastcgi {start|stop|restart|status}"
      RET_VAL=1
  ;;
esac
exit $RET_VAL

/usr/bin/php-fastcgi

#!/bin/bash

FASTCGI_USER=www
FASTCGI_GROUP=www
ADDRESS=127.0.0.1
PORT=9000
PIDFILE=/var/run/php-fastcgi/php-fastcgi.pid
CHILDREN=6
PHP5=/usr/bin/php5-cgi

/usr/bin/spawn-fcgi -a $ADDRESS -p $PORT -P $PIDFILE -C $CHILDREN -u $FASTCGI_USER -g $FASTCGI_GROUP -f $PHP5

Does the www user have write access to the PID file?

What do you get when you manually run the spawn-fcgi program as in the last line of /usr/bin/php-fastcgi?

It also seems that you're using an overly complicated setup. Init script calling another bash script? What for? If you're using spawn-fcgi on Debian Squeeze, you only need one init script. Here is the init script that I used to use. (I have since moved on to FPM.)

Yes, www has read/write to the PID file.

Regardless of if I run the init script, the bash script in /usr/bin, or the command, I get:

spawn-fcgi: child signaled: 11

I've no idea what this is, but the PID file generated is empty. I also get the same output from your script, and it produces an empty file called /var/run/spawn-fcgi.pid. When I tell both scripts to stop, they delete their respective PID files and complain that they don't have a process to kill.

I was following the tutorial in the Linode Library, which has me create both scripts: http://library.linode.com/web-servers/nginx/php-fastcgi/debian-6-squeeze.

I don't think this matters, but just in case, I added Debian's backports server to /etc/apt/sources.list and installed nginx 1.1.0 from there, in addition to a dist-upgrade. This doesn't seem to have changed the error, though, and nginx 1.1.0 seems to be running with no problem whatsoever. It's just php-fastcgi that won't work.

Signal 11 is segmentation fault. PHP is crashing. This is usually due to some extension or another. Try removing APC if you have it, or any other PECL extension you might have installed. I've even seen a combination of curl and pgsql cause random segfaults.

Didn't realize I had pgsql installed... I uninstalled that, along with php-apc and curl. I don't seem to have any other PECL installed, at least none that are reported by apt-get, and none are listed in /etc/php5/cli/php.ini or /etc/php5/cgi/php.ini.

At this point, I'd be trying php-fpm, except it's not in Debian's repos and I don't feel like compiling something else

Ok, so I overcame my laziness, somewhat.

I ran "dpkg -l | grep php" and removed anything that showed up. I then added the dotdeb.org repositories (which I found after several minutes of searching) and reinstalled php from there, and included php5-fpm. I reconfigured nginx to use that, and the site works fine now. I'm still baffled as to what happened to make fastcgi stop working -- the only packages I had installed were php5-cli, php5-common, php5-cgi, php5-mcrypt, and spawn-fcgi. It's probably too late to do investigating, I tend to purge packages rather than just removing them.

Good move there. Dotdeb is the preferred way to get FPM on Debian Squeeze. No compiling necessary, and updates are very quick, too.

I bet one of your extensions got corrupted in a recent update. It can happen, especially if you mix distro binaries with self-compiled binaries. You could have tried reinstalling all of them, but it's a moot point now that you've moved on to Dotdeb.