Page MenuHomePhabricator

PHP warnings should be logged via Monolog (with a stack trace), not HHVM
Closed, DuplicatePublic

Event Timeline

Tgr created this task.Feb 16 2017, 1:38 AM

Seems like we already have this. MWExceptionHandler already installs an error handler which logs to the "error" channel.

Maybe we're just missing routing? I don't see it in $wmgMonologChannels

Tgr added a comment.Feb 20 2017, 6:13 AM

Yes, in theory this should be already happening but doesn't. (Or maybe doesn't some of the time, not sure.)

If it was only a routing issue, I'd expect the error to not show up anywhere. If ends up in HHVM, then it's probably not caught.

Tgr added a subscriber: bd808.Feb 20 2017, 7:03 AM

Strike that, the handler actually passes the error on:

// This handler is for logging only. Return false will instruct PHP
// to continue regular handling.
return false;

@bd808 do you know why we do that? Is that to make fatalmonitor work?

Strike that, the handler actually passes the error on:

// This handler is for logging only. Return false will instruct PHP
// to continue regular handling.
return false;

@bd808 do you know why we do that? Is that to make fatalmonitor work?

We do that because it's the correct way for a default set_error_handler() to function. If we swallowed the errors there without returning false then $php_errormsg would not be populated and all errors would be handled as though the @ suppression operator was applied to every line in the codebase.

Maybe we're just missing routing? I don't see it in $wmgMonologChannels

See T45086#787151. The channel is too noisy to log on WMF's production servers.

This whole ticket is really a duplicate of T45086: Capture PHP warnings with stacktraces in MediaWiki and save to logstash.

Tgr added a comment.Feb 20 2017, 6:29 PM

@bd808 sorry, I seem to have a really short memory when it comes to logging :) Now I remember having talked about this in T154112.

mmodell changed the subtype of this task from "Task" to "Production Error".Aug 28 2019, 11:10 PM