If PHP-FPM is running and most pages on a site are working but one request in particular produces “502 Bad Gateway” errors, you’re dealing with the php runtime crashing. That’s probably not your fault, but debugging it can give you clues to working around it.
First, take a look in the site’s logs/error.log file for any PHP-reported errors for the script in the site, and then check the server’s global /emergence/services/logs/php-fpm/errors.log for any errors from PHP itself. If you don’t find anything in the site error log but do find a vague error like WARNING: [pool www] child 4858 exited on signal 11 (SIGSEGV - core dumped) after 616856.585160 seconds from start in the global log, keep reading – you’ve got a core dump to examine.
On Ubuntu systems by default, core dumps when a process crashes get written into the /var/crash directory. You should see a file for php-fpm in there, but before you do anything with it, delete it and trigger the “502 Bad Gateway” error again. apport, the service in Ubuntu that records this file, will avoid writing a core dump for a process if it already has one to prevent filling up the disk – so make sure you’re looking at a fresh one.
First, unpack the core dump into your home directory:
apport-unpack /var/crash/_usr_sbin_php5-fpm.33.crash ~/php5-fpm.crash
Then, install the GDB command and use it to inspect the core dump file:
sudo apt-get install gdb
gdb /usr/sbin/php5-fpm ~/php5-fpm.crash/CoreDump
Exactly what to do once you’ve got the PHP core dump loaded up in GDB is a bit beyond the scope of this post, but at least reading the traceback it prints as soon as it starts up should give you a clue what PHP feature the crash originated from