Nginx Php-fpm not logging 500 error anywhere

Question

Nor do nginx or php-fpm reports a error 500 output, In fact the 500 response is on the access log and not on the nginx error log. The script is running ok in my dev environment.

nginx version: nginx/1.6.2  
PHP 5.5.19 (fpm-fcgi)

Tried this

catch_workers_output = 1

Restarted everything, still not working

nginx access log shows:

x.x.x.x - - [12/Dec/2014:19:25:08 -0200] "GET /merchant/customer/mobile/data?sEcho=1&iColumns=3&sColumns=%2C%2C&iDisplayStart=0&iDisplayLength=10&mDataProp_0=0&sSearch_0=&bRegex_0=false&bSearchable_0=true&mDataProp_1=1&sSearch_1=&bRegex_1=false&bSearchable_1=true&mDataProp_2=2&sSearch_2=&bRegex_2=false&bSearchable_2=true&sSearch=&bRegex=false&_=1418418256370 HTTP/1.1" 500 589 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.71 Safari/537.36"

Note the 500 error, which should be on error.log and with the php trace that's is happening on other errors.

Any clues?

Answer 1

When PHP display_errors are disabled, PHP errors can return Nginx 500 error.

Take a look into your php-fpm logs, i'm sure you'll find the error there. With CentOS 7 :

tail -f /var/log/php-fpm/www-error.log

You can finally show PHP errors. In /etc/php.ini, change :

display_errors = Off

to :

display_errors = On

Hope it helps.

Answer 2

Verify php-fpm service is running

sudo service php-fpm status

This will display the hostnames that can execute php.

Next edit php.ini to display errors. this will display errors on page..to make things easy to diagnose

sudo vim /etc/php.ini

then hit key [/] and type

display_errors

hit key [i] user arrow keys and backspace to set display_errors = on

then restart php-fpm service

On system type redhat /centos etc..

sudo service php-fpm restart

Answer 3

In case it helps someone else (Google brought me here), I had a similar problem (although in Apache, not nginx).

An older app I was installing was giving a 500 error with no output anywhere, in spite of every conceivable error logging setting turned to the most verbose level.

It turns out the problem was the controversial error-control operator, "@". As the red warning box in the docs states, no matter how verbose your logging is, if an @-prefixed command causes PHP to stop because of a typo, or because it is not available (say, because you have forgotten to install a critical module like php-mysql), PHP will exit with absolutely no indication as to why.

So, if you find yourself with a 500-error and no logs, check your codebase for "@" symbols.