This repository has been archived by the owner on Apr 26, 2024. It is now read-only.
-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
SIGHUP handler can throw exception due to reentrant call, which stops all future logging #8769
Comments
I suspect, without verification, that this is unrelated to any recent changes and is due to the unlikely event of the SIGHUP arriving during an active |
clokep
added
z-bug
(Deprecated Label)
A-Logging
Synapse's logs (structured or otherwise). Not metrics.
z-p2
(Deprecated Label)
labels
Nov 17, 2020
this happened again last night. |
^ Is last night's instance. Sequence of events (mm:ss):
|
This happened again overnight, this time on a pusher. If I'm reading the graphs correctly it didn't stop the pusher making requests. We have no logs for ~8hrs though |
Probably the easiest thing to do here is to not flush in the signal handler, but instead queue it up to be done next reactor tick. |
erikjohnston
added a commit
that referenced
this issue
Nov 25, 2020
We can get a SIGHUP at any point, including times where we are not in a sane state. By deferring calling the handlers until the next reactor tick we ensure that we don't get unexpected conflicts, e.g. trying to flush logs from the signal handler while the code was in the process of writing a log entry. Fixes #8769.
erikjohnston
added a commit
that referenced
this issue
Nov 26, 2020
We can get a SIGHUP at any point, including times where we are not in a sane state. By deferring calling the handlers until the next reactor tick we ensure that we don't get unexpected conflicts, e.g. trying to flush logs from the signal handler while the code was in the process of writing a log entry. Fixes #8769.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
When doing a SIGHUP to reload logging, this exception was thrown, the logs were not rotated, and no further logging was added to the log (the logging infrastructure seemed to remove the old loggers but never create the new ones?)
Seen on matrix.org
Argument were present but not listing in public issue: it did not inherently look like bad log data.
Not sure if related to recent SIGHUP change #8697
This was caused by an automatic midnight SIGHUP as part of log rotation. This failed and no further logs were written until a second manual SIGHUP restarted logging again.
The text was updated successfully, but these errors were encountered: