Repository navigation
logging: keep only log-max-files backup files when rotating - #712
Conversation
| * With log_max_files == 1 the loop does not run and the old .1 backup is | ||
| * atomically replaced by the rename() in perform_file_rotation(). */ |
There was a problem hiding this comment.
looks like a AI artifact to explain the change itself, instead we need to explain what the code below does
There was a problem hiding this comment.
Done — removed those two lines. The pre-existing first line already describes what the loop does; the change rationale stays in the commit message.
|
please use your real name for the commit author and DCO line |
a3ba37c to
c57a91c
Compare
Done — amended the author and DCO line to "Aucoto Zhang": Zhang is my real surname; Aucoto is the contributor name I sign my contributions under across projects (e.g. docker/compose#14390), and I'd rather not publish my legal given name. Happy to adjust if this doesn't work for you. |
|
lint fix here: #713 |
With --log-rotate and --log-max-files 1, shift_backup_files() started its renaming loop at 2, moving .1 to .2 on every rotation. Together with the current log becoming .1, two backup files were left behind although only one was configured, so the log space used exceeded --log-max-files. Start the loop at opt_log_max_files directly: with log-max-files == 1 the loop does not run and the old .1 backup is atomically replaced by the rename() in perform_file_rotation(), keeping exactly one backup. Behavior for log-max-files >= 2 is unchanged. A regression test runs a container that produces enough output to rotate the log several times and asserts that only the .1 backup file is left behind. Fixes: 61c8da9 ("Add log rotation functionality as alternative to log truncation") Signed-off-by: Aucoto Zhang <tdnorthgarden@gmail.com> Co-Authored-By: AtomCode (glm-5.3) <noreply@atomgit.com>
c57a91c to
156323e
Compare
Problem
With
--log-rotate --log-max-files 1(--log-max-filesdefaults to 1), every rotationfrom the second one on leaves two backup files (
.1and.2) behind instead of thesingle one configured, so the disk space used by logs exceeds the
--log-max-fileslimit.shift_backup_files()computes the loop start as(opt_log_max_files > 1) ? opt_log_max_files : 2, so with--log-max-files 1the shiftingloop runs once and moves
.1to.2on every rotation;perform_file_rotation()thenrenames the current log to
.1. The result islog.1+log.2.This is a bug, not a design choice:
--log-max-filesis documented as "Number of backuplog files to keep", and rotation exists to bound log disk usage. The
: 2special caselooks like an attempt to move
.1out of the way before the new.1is placed, withoutnoticing that
rename()already replaces the destination atomically — a property the samefunction relies on elsewhere ("Direct atomic rename - overwrites destination if it
exists"). Introduced by 61c8da9 ("Add log rotation functionality as alternative to log
truncation").
Reproducer (container writes ~2 KB+ of output, log-size-max 1024):
Fix
opt_log_max_filesdirectly and drop the: 2specialcase. With
--log-max-files 1the loop no longer runs; the old.1backup isatomically replaced by the
rename()inperform_file_rotation(), keeping exactly onebackup.
--log-max-files >= 2is unchanged: the loop start equalsopt_log_max_filesin both versions.Testing
New regression test
log management: should keep only log-max-files backup filesintest/06-log-management.bats: runs a real container producing ~300 log lines (≈20 KB)against
--log-size-max 1024(many rotations) and asserts$LOG_PATH.1exists while$LOG_PATH.2does not.Full suite result after the fix:
06-log-management.bats14/14,03-k8s-log-rotation.bats3/3, clean build with the project's
-Werrorflag set.