The error is from LBFactory::__destruct calling LoadBalancer::closeAll which does some debug logging, and at that point UdpSocket::$socket is null because the object's own destructor has already been called.

Change 323360 had a related patch set uploaded (by Gergő Tisza):
Wrap SyslogHandler in WhatFailureGroupHandler in elk role

https://gerrit.wikimedia.org/r/323360

Change 323360 merged by jenkins-bot:
Wrap SyslogHandler in WhatFailureGroupHandler in elk role

https://gerrit.wikimedia.org/r/323360

Per IRC discussion this was fixed in vagrant by wrapping in WhatFailureGroupHandler like WMF production does. Third parties are on their own I guess.

@bd808 is there a way to tell if the exception is being thrown in production? Maybe the perf team is interested in tracking it down - even if it's caught, throwing exceptions is not that cheap.

In T151428#2826303, @Tgr wrote:

@bd808 is there a way to tell if the exception is being thrown in production? Maybe the perf team is interested in tracking it down - even if it's caught, throwing exceptions is not that cheap.

The only way to tell would be either disabling our use of WhatFailureGroupHandler or subclassing it to add some kind of counter that could be monitored. Based on your local experience I'd be pretty comfortable saying that it is throwing exceptions. Logging during the destructor phase of the PHP lifecycle is a difficult thing to get right.

Adding Performance-Team per previous comment. Feel free the close as resolved if you are not interested, the original problem is already fixed.

There is a similar issue on monolog #860 about catching the exception thrown by the handler and/or re-routing the original message to another handler.

T159613 seems to be the same issue for LegacyLogger.