Message381146
If a logging.FileHandler is configured with mode='w', or if logging.basicConfig is called with filemode='w' (as suggested by the Basic Logging Tutorial https://docs.python.org/3/howto/logging.html#logging-basic-tutorial)
and if some code logs during shutdown, after logging has closed its handlers (asyncio is prone to do this, e.g.),
then logging.FileHandler._open will reopen the log file with the same mode as it was originally opened with, potentially truncating it and losing valuable information:
import atexit
atexit.register(lambda: logging.info("so long"))
import logging
logging.basicConfig(filename='test.log', filemode='w', level=logging.INFO)
logging.info("super important stuff")
$ python truncate.py
$ cat test.log
INFO:root:so long
I have a hunch that the fix to issue 26789 will potentially make things worse, as previously at least there was a chance that logging had been fully unloaded so that the call to open would fail.
https://stackoverflow.com/questions/39838616/why-is-python-logging-framework-losing-messages |
|
Date |
User |
Action |
Args |
2020-11-16 19:48:23 | ecatmur2 | set | recipients:
+ ecatmur2 |
2020-11-16 19:48:22 | ecatmur2 | set | messageid: <1605556102.98.0.0941471383568.issue42378@roundup.psfhosted.org> |
2020-11-16 19:48:22 | ecatmur2 | link | issue42378 messages |
2020-11-16 19:48:22 | ecatmur2 | create | |
|