On a webserver, that usually works quite well with nginx
and php-fpm
(currently version 7.0.22, but this is mostly independet from the version), there are times when a 502 Bad Gateway occurs. This sually means: One of the php-fpm
processes has crashed, and nginx
does not receive an answer from the chosen process.
My current workaround is to monitor not only the php-fpm
process, but also the output of a PHP page. And if this does not work for 4 minutes (two failed retries with a surveillance interval of 2 minutes), then monit
will kill all php-fpm
processes and restart the php-fpm
service. Works, but still causes a 5 minute downtime (at least for some users that connect to the broken process) or more, because monit
may as well see the answer from a sane process a few times, before it observes the 502 Bad Gateway.
(1) The ideal solution was to bugfix whatever break the php-fpm
process. Yet, the error occurs rarely, so I was unable to track it down to some specific reason. Possibly a memory leak in a PHP script ... I don't know.
(2) The second best option, I have in mind, would involve some cooperation from nginx
. If the webserver process could react to a PHP failure, it could (a) kill the specifically broken process and (b) try another process instead of throwing the 502 Bad Gatway.
So far, I did not find an option to make nginx
react to the failure. Who has an ideas how this could be achieved? Or is there an easier solution, I missed?
connect() to unix:/run/php/php7.0-fpm.sock failed (11: Resource temporarily unavailable)