0011331: Logrotate not always rotating as expected

ClearFoundation Tracker - ClearOS

View Issue Details

Project

Category

View Status

Date Submitted

Last Update

0011331

ClearOS

logrotate

public

2016-12-04 12:20

2018-07-23 08:05

Reporter

NickH

Assigned To

user2

Priority

normal

Severity

minor

Reproducibility

have not tried

Status

closed

Resolution

fixed

Platform

OS Version

Product Version

7.2.0

Target Version

7.3.0

Fixed in Version

7.3.0

Summary

0011331: Logrotate not always rotating as expected

Description

Logrotate sometimes does weekly rotations after 8 days rather than 7. Similarly I'd guess that daily rotations also gets skipped occasionally.

The reason behind this is that in ClearOS7 the /var/lib/logrotate.status now also contains an h:m:s timestamp whereas ClearOS 6.x only had a date stamp. It appears that logrotate is waiting at least 7 * 24 * 60 * 60 seconds from the previous run as recorded in logrotate.status until it will do a weekly logrotate. Logrotate is run from cron.daily and when it actually runs depends on how long the preceding cron.daily jobs take to run. If in the previous week they took just a fraction longer than the current week then 7 * 24 * 60 * 60 seconds will not have elapsed between the to cron jobs which have run 7 days apart. This "jitter" in the timing of the logrotate script will always have a tendency to skip a day for both the daily and weekly rotations.

This is really an upstream issue and I've filed https://github.com/logrotate/logrotate/issues/93 [^] with the logrotate authors. However I can see a couple of workrounds. You can add either "sed -i 's/-3:[[:digit:]]\{1,2\}:/-3:0:/' /var/lib/logrotate.status" or "sed -i 's/:[[:digit:]]\{1,2\}:[[:digit:]]\{1,2\}$/:0:0/' /var/lib/logrotate.status" to the end of /etc/cron.daily/logrotate. The first one sets the minutes to anything run between 03h00m00 and 03h59m59 and works because cron.daily fires at 03:18 be default. This means you have 42min from cron.daily starting to so the log rotation. The second one leaves the hour intact and sets the minutes and seconds to 0. It has the advantage that it will also fix the problem if anyone changes when cron.daily runs. It will also make the script reliable if the user moves the logrotate function into cron.hourly to take advantage of hourly rotations (the introduction of which probaly gave rise to this bug).

Either of the two proposed solutions can be added by a post-install script.

I have not investigated any compile time options in the logrotate package to see if the timestamp functionality can be altered.

Steps To Reproduce

No particular steps needed, but check that there are a number of jobs in cron.daily which will run before logrotate to introduce some jitter into the runtimes or add a cron.daily job with a random wait which executes before logrotate. Eventually you will see a daily rotation missed or a weekly rotation with an 8 day gap.

I don't know if you also need to comment out "dateext" from logrotate.conf, but I doubt it.

Additional Information