502 Bad Gateway (php-fastcgi processes crashing)

Server NGINX
1

Our site is currently on a linux VPS with DreamHost and using nginx
0.8.53 as the web server and php-fcgi version 5.2.15. On occasion, our
php-fastcgi processes just suddenly crash, and our users are left with a
“502 Bad Gateway” error from nginx. The server is configured to use unix
sockets and not a TCP port.

Our php-fastcgi settings are the following:
PHP_FCGI_CHILDREN = 8 (should be plenty for our traffic)
PHP_FCGI_MAX_REQUESTS = 400 (used to be 1000, we tried lowering to see
if it would help, and nada.)

The http error logs show these sort of error messages:

9 connect() to unix:/home/**/.php.sock failed (111: Connection
refused) while connecting to upstream, client: *****, server: **,
request: "GET , upstream: "fastcgi://unix:/home//.php.sock:"
28898 connect() to unix:/home//.php.sock failed (11: Resource
temporarily unavailable) while connecting to upstream, client: **,
server: *, request: "GET ", upstream:
"fastcgi://unix:/home//.php.sock:"

We wrote a daemon that restarts the nginx web server when it detects the
processes crash, or these error codes pop up, but sometimes restarting
the web server fails to bring back the php5.cgi processes, and our users
are left without any access to our site material for a while. This
approach is also pretty sloppy and doesn’t work sometimes.

Why would php lock up and crash like this, and why isn’t nginx
automatically reload the php5.cgi processes? Is there another way to
serve php to our users that doesn’t use php-fastcgi? (I heard people
mention php-fpm, but I’m not too familar with using it or its
advantages). We think that it might be the php5.cgi processes timing out
waiting for MySQL queries to finish processing, since we can sometimes
crash php5.cgi simply by running long queries on the web site. Any
suggestions on settings we can tweak?

Thanks to anyone who can help.

Posted at Nginx Forum:

2

On Thu, Feb 10, 2011 at 5:51 PM, shadowlink64 [email protected]
wrote:

serve php to our users that doesn’t use php-fastcgi? (I heard people
mention php-fpm, but I’m not too familar with using it or its
advantages).

guess what, the advantage is it solves your problem.

3

On 2/10/11 5:51 AM, shadowlink64 wrote:

The http error logs show these sort of error messages:

9 connect() to unix:/home/**/.php.sock failed (111: Connection
refused) while connecting to upstream, client: *****, server: **,
request: "GET , upstream: "fastcgi://unix:/home//.php.sock:"
28898 connect() to unix:/home//.php.sock failed (11: Resource
temporarily unavailable) while connecting to upstream, client: **,
server: *, request: "GET ", upstream:
"fastcgi://unix:/home//.php.sock:"

This is a PHP problem and not related to nginx. I’ve never been happy
using php-fastcgi as a backend without a process manager of some sort.

Your choices include using PHP-FPM, using Supervisord, using another
process manager, or of course, using Apache as a backend to handle PHP
requests only with nginx serving static content and acting as a reverse
proxy the same way you use it now.

If your code will support it, and you want to use PHP-FPM, then
upgrading to PHP 5.3.x may be a good idea as no patching is required to
build from sources.

Additionally, I have seen anecdotal reports here and elsewhere that
having your processes listen on a TCP port rather than a Unix socket may
be beneficial.

We wrote a daemon that restarts the nginx web server when it detects the
processes crash, or these error codes pop up, but sometimes restarting
the web server fails to bring back the php5.cgi processes, and our users
are left without any access to our site material for a while. This
approach is also pretty sloppy and doesn’t work sometimes.

Why would php lock up and crash like this, and why isn’t nginx
automatically reload the php5.cgi processes?

nginx didn’t start the processes and does not control them.

Is there another way to
serve php to our users that doesn’t use php-fastcgi? (I heard people
mention php-fpm, but I’m not too familar with using it or its
advantages).

See above. It’s a process manager and will restart dead children
automatically.

nginx mailing list
[email protected]
nginx Info Page

–
Jim O.

4

On Thu, 10 Feb 2011 05:51:06 -0500, shadowlink64 wrote:

Our site is currently on a linux VPS with DreamHost and using nginx
0.8.53 as the web server and php-fcgi version 5.2.15. On occasion,
our
php-fastcgi processes just suddenly crash, and our users are left
with a
“502 Bad Gateway” error from nginx. The server is configured to use
unix
sockets and not a TCP port.

Everybody has that problem with PHP. The solution is to monitor PHP
with something (php-fpm, supervise, etc…)

I do it with supervise:
http://wiki.linuxwall.info/doku.php/en:ressources:dossiers:nginx:daemontools_spawnfcgi

Julien