rest server: log rotation: fix off-by-one for max_days

The entries in a file go from oldest end-time in the first time to
newest end-time in the last line. So, just because the first line is
older than the cut-off time, the remaining one doesn't necessarily
have to be old enough too. What we can know for sure that older than
the current checked rotations of the task archive are definitively up
for deletion.

Another possibility would be to check the last line, but as scanning
backwards is more expensive/complex to do while only being an actual
improvement in a very specific edge case (it's more likely to have a
mixed time-cutoff vs. task-log-file boundary than that those are
aligned)

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
This commit is contained in:
Thomas Lamprecht 2022-04-07 12:57:03 +02:00
parent 416194d799
commit 40853461d1
1 changed files with 6 additions and 2 deletions

View File

@ -238,6 +238,11 @@ pub fn rotate_task_log_archive(
let mut delete = false;
let file_names = logrotate.file_names();
let mut files = logrotate.files();
// task archives have task-logs sorted by endtime, with the oldest at the start of the
// file. So, peak into every archive and see if the first listed tasks' endtime would be
// cut off. If that's the case we know that the next (older) task archive rotation surely
// falls behind the cut-off line. We cannot say the same for the current archive without
// checking its last (newest) line, but that's more complex, expensive and rather unlikely.
for file_name in file_names {
if !delete {
// we only have to check if we did not start deleting already
@ -262,8 +267,7 @@ pub fn rotate_task_log_archive(
}
}
}
}
if delete {
} else {
if let Err(err) = std::fs::remove_file(&file_name) {
log::error!("could not remove {:?}: {}", file_name, err);
}