On a webserver, that usually works quite well with
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)