A robust drop-in replacement for Python's `RotatingFileHandler` and `TimedRotatingFileHandler` that supports safe concurrent writes from multiple processes and threads. It also includes features like gzip compression and better Windows compatibility. The library is actively maintained, with frequent minor releases addressing bugs and adding features, typically every few months.
pip install concurrent-log-handlerVerified import paths — ran on the pinned version, not inferred.
This example demonstrates how to set up a basic logger using `ConcurrentRotatingFileHandler` to ensure log file rotation works safely across multiple processes, preventing data loss or corruption due to concurrent writes. It configures a log file to rotate after reaching 10MB, keeping 5 backup copies.
Upgrade your Python environment to 3.6 or newer if you are using an older Python 2.x interpreter.
As of 0.9.29, inherited handlers automatically reopen lock files for isolation. However, it is still strongly recommended to re-initialize your logging configuration *after* calling `os.fork()` in child processes to ensure full isolation and robust behavior.
Remove calls to `setup_logging_queues()`. The standard synchronous logging calls with this handler are generally sufficient and recommended.
Upgrade to version 0.9.28 or later. The handler now performs catch-up rollovers on initialization if scheduled times were missed.
No direct fix needed, but be aware of this internal behavior. If you experience unexpected issues with file handles, you can revert to the old behavior by explicitly setting `keep_file_open=False` in the handler constructor, though this may impact performance.
Install the package using pip: `pip install concurrent-log-handler`. Ensure the import statement is `from concurrent_log_handler import ConcurrentRotatingFileHandler` (or `ConcurrentTimedRotatingFileHandler`).
Install the `pywin32` package: `pip install pywin32`.
Ensure that each child process creates its own `ConcurrentRotatingFileHandler` or `ConcurrentTimedRotatingFileHandler` instance after forking, rather than inheriting one from the parent process. Re-initializing logging post-fork is recommended.
Update to the latest version of `concurrent-log-handler` to benefit from bug fixes. If the issue persists, simplify log message formatting or ensure critical log calls are not intertwined with complex formatting that could cause rollovers mid-operation.
No dependency data recorded yet.