Bug Report
Version
- tracing = "0.1.44"
- tracing-subscriber = { version = "0.3.22", features = ["env-filter", "json"] }
- tracing-appender = "0.2.4"
- tracing-core = "0.1.36"
- tracing-test = "0.2.5"
Platform
Crates
- tracing-appender = "0.2.4"
Description
The short description of my problem:
When using a RollingFileAppender with max_log_files set, the Inner struct's prune_old_logs will delete down to max_log_files - 1 log files.
This is a problem because if the log file we start writing to has the same name as an existing log file, we are left with 'max_log_files - 1' log files, unexpectedly losing log files that should have been preserved still.
The longer explanation for how this happens:
- Lets assume that
max_log_files = 3
- The current date is March 20th, 2026
- The application has been running for a number of days and there are three log files being retained
application.log.2026-03-20application.log.2026-03-19application.log.2026-03-18
- The application is now restarted.
- On startup,
pruno_old_logs will delete application.log.2026-03-18 in order to reduce the log count to max_log_files - 1
- The
RollingFileAppender will then start writing to application.log.2026-03-20, leaving us with only 2 log files.
I think this behavior is in place under the assumption that a new log file will get created, so by deleting an extra log file the appender is leaving room for that new log file to be created. However, in the case of a quick restart (say, for an upgrade, or due to a crash) log data that is still relevant may be deleted.
I believe this line of code is where part of the issue occurs:
|
for (file, _) in files.iter().take(files.len() - (max_files - 1)) { |
My workaround for now is going to be to artificially increase the number of log files that an end user has configured. If they say to retain 3 log files, I will retain 4. While this will work, I then foresee people writing defects for my code complaining that I am retaining more log data than they have configured my application to retain.
Bug Report
Version
Platform
tokio-trace-macroscrate with a trace-ified version ofstd::dbg!#1 SMP Tue Nov 5 00:21:55 UTC 2024 x86_64 x86_64 x86_64 GNU/LinuxCrates
Description
The short description of my problem:
When using a RollingFileAppender with
max_log_filesset, theInnerstruct'sprune_old_logswill delete down tomax_log_files - 1log files.This is a problem because if the log file we start writing to has the same name as an existing log file, we are left with 'max_log_files - 1' log files, unexpectedly losing log files that should have been preserved still.
The longer explanation for how this happens:
max_log_files = 3application.log.2026-03-20application.log.2026-03-19application.log.2026-03-18pruno_old_logswill deleteapplication.log.2026-03-18in order to reduce the log count tomax_log_files - 1RollingFileAppenderwill then start writing toapplication.log.2026-03-20, leaving us with only 2 log files.I think this behavior is in place under the assumption that a new log file will get created, so by deleting an extra log file the appender is leaving room for that new log file to be created. However, in the case of a quick restart (say, for an upgrade, or due to a crash) log data that is still relevant may be deleted.
I believe this line of code is where part of the issue occurs:
tracing/tracing-appender/src/rolling.rs
Line 717 in 54ede4d
My workaround for now is going to be to artificially increase the number of log files that an end user has configured. If they say to retain 3 log files, I will retain 4. While this will work, I then foresee people writing defects for my code complaining that I am retaining more log data than they have configured my application to retain.