2

There is so much static around this it's hard to find an answer that actually applies, so my apologies if there is an answer for this, I just haven't been able to find it.

My situation is that I want to display errors from our application on the page when they happen... in our DEVELOPMENT environment.... I don't need to be told to only send them to the logs, it's a giant waste of time during dev and not near as formatted to have to read them out of the logs. We of course turn this off in production.

My errors ARE being logged, this is not the problem, the issue is, they are not being DISPLAYED before Apache redirects them with a 503 response code, most likely because of PHP/FPM dying with a fatal error that we didn't catch properly.

Prior to moving to PHP-FPM, any kind of error was displayed no problem, we have the standard settings in place in /etc/php.ini...

error_reporting = E_ALL
error_display_errors = On
display_startup_errors = On
log_errors = On

And my exception/error handler was working great, I could access my stack trace details, extra meta, etc., however now that I've got PHP-FPM enabled, Apache seems to be capturing the returning http 503 status, and is redirecting to the generic apache error message. I've tried using...

errordocument 503 /error.php?...

... but this loses state so I don't get all the details I would normally have gotten in the shutdown handler I normally use. I've added the following to the FPM pool definition...

php_admin_flag[display_errors] = On
php_admin_flag[log_errors] = On

... but they had no effect. php_info() is showing both master and local values are working as expected, so it's not a misconfiguration, or errant include file somewhere.

What am I doing wrong, how can I stop apache from forwarding to it's own error handler and just display the output of PHP-FPM, and by extension my own error handler?

Apache:  2.4.37-21
PHP/FPM: 7.3.5-5
oucil
  • 445
  • 3
  • 16
  • 503 is semantically the wrong response for this anyway; you should be responding with 500 in this scenario. See RFC 7231 section 6.6. – Michael Hampton Jun 29 '20 at 16:14
  • @MichaelHampton true enough, depends a bit on where the error was coming from and how the exception/error was captured because I don't think we're returning the 503 specifically (I'll update my question accordingly), but I do agree, we still have some work to do to make up for past mistakes ;) I have a feeling, it might be defaulting to a 503 in Apache because PHP/FPM is dying with a fatal error, which is part of the issue, it's just a blanket override basically. – oucil Jun 29 '20 at 16:21
  • And you're right about all the junk on the Internet when you try to search for something like this. But I read a bunch of stuff and got the vague impression that Apache handles 503 specially. I haven't done a whole lot with Apache since switching most everything to nginx in 2008, so I probably can't be much more help (unless you want to switch to nginx)... – Michael Hampton Jun 29 '20 at 16:40
  • @MichaelHampton Some days I get that urge :D Thanks for your insights, I'll see what I can dig up on the 503 handling specifically, hopefully it'll lead to something. – oucil Jun 29 '20 at 16:50
  • 2
    I don't regret it for a moment. I'm quite glad to have mostly left Apache behind. – Michael Hampton Jun 29 '20 at 16:51

0 Answers0