How to handle a (possibly) misbehaving logger?

Hi Delgan,

In one of my multithreaded service daemons I’m seeing that the logger will occasionally stop altogether. By that I mean the application continues to run as if there are no errors but nothing is written to the logs and the files themselves aren’t rotated. The file descriptors for the log files themselves are still open too. I suspect that I’m either blocking on a single logging call or that the there could have been an exception in the logger itself. Unfortunately I don’t have a record of strerr to check this.

In the interest of debugging my problem I have a couple of questions:

1. Do you have an example of handling errors in the Loguru logger (setting catch to False when adding a sink) to the documentation? Would this basically mean that every logging call needs to be put into a try/except block?
2. If there is an exception in the logger, can it be restarted to make it sane again? If so, how can I accomplish that?
3. If on the other hand I’m being blocked by a single logging call (not sure why this would be), do you think that setting enqueue to True when adding a sink might solve my problem? Do logging calls eventually timeout?

I use Loguru extensively in my work. Thanks for your effort!

[kace]

I assumed this was the case, but failed to find anything from the Python stdlib documentation listing this requirement (not sure if re-entrant signal handlers are the norm across all programming languages).

Your explanation makes sense. Don’t worry about coming up with a fix. I’ve already removed the logging calls from my signal handlers, but a note in the documentation might save clueless people like me some time!

Thanks again Delgan and great work on Loguru!

[jacksmith15]

Actually, I’ve managed to reproduce and I think what I’ve found constitutes a separate issue. I will raise and link it here. EDIT: https://github.com/Delgan/loguru/issues/712