This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ecatmur2
Recipients ecatmur2
Date 2020-11-16.19:48:22
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1605556102.98.0.0941471383568.issue42378@roundup.psfhosted.org>
In-reply-to
Content
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
History
Date User Action Args
2020-11-16 19:48:23ecatmur2setrecipients: + ecatmur2
2020-11-16 19:48:22ecatmur2setmessageid: <1605556102.98.0.0941471383568.issue42378@roundup.psfhosted.org>
2020-11-16 19:48:22ecatmur2linkissue42378 messages
2020-11-16 19:48:22ecatmur2create