Logging in signal handlers may be unsafe about gunicorn HOT 2 OPEN

I've run into various issues issues with signals/logging/uvicorn. This issue contains the root cause for the problems we saw.

A summary that explains/connects various reported issues and might help others running into this:

• logging is ok for most of the signals, because signals are not handled directly, but added to a queue which moves handling to the main thread
• except for SIGCHLD, this signal is not queued by design
• SIGCHLD handling calls logging iff the exit code of the worker != 0, which might result in #2816
• the reason for a non-zero exit code can be the use of uvicorn workers: #3013
• the uvicorn socket error on exit is non-critical, however it can cause a cascade effect: uvicorn error -> non-zero exit code -> logging call -> Runtime Error
• if you use SIGHUP to reload workers, the almost simultaneous restart of workers cause a lot of these errors and in some situations can cause the the master process to get stuck

Mitigation

The issue can be mitigated by decoupling logging using QueueHandler and QueueListener, provided by a custom logconfig(_dict/_json)

from gunicorn.

Related: #2816

We do have suggested changes, notably #3148 attempting to address this.

from gunicorn.