ClearOS Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0011331ClearOSlogrotatepublic2016-12-04 12:202018-07-23 08:05
Assigned Touser2 
PrioritynormalSeverityminorReproducibilityhave not tried
PlatformOSOS Version
Product Version7.2.0 
Target Version7.3.0Fixed in Version7.3.0 
Summary0011331: Logrotate not always rotating as expected
DescriptionLogrotate 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 [^] 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 ReproduceNo 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.
TagsNo tags attached.
Attached Files

- Relationships
related to 0020871closeduser2 Logrotate fixed upstream 

-  Notes
NickH (developer)
2016-12-05 04:22

From, [^] it makes no difference whether or not you use "dateext"
2016-12-05 09:55

Nice one Nick!
NickH (developer)
2016-12-05 11:34

Following comments from Tony, my fix may not be good enough. The delay + random_delay in anacrontab can stack up and make logrotate trip to after 04:00:00. At this point the only solution by injecting a line into /etc/cron.daily/logrotate is really to force all timestamps to 3:0:0 with something like :

sed -i 's/-[[:digit:]]\{1,2\}:[[:digit:]]\{1,2\}:[[:digit:]]\{1,2\}$/-3:0:0/' /var/lib/logrotate.status

This forces all timestamps to 3:0:0, but probably 0:0:0 or 0:0:1 could be a better choice as it will work if a user changes the timing of cron.daily. The downside of this approach is that it destroys compatibility with hourly rotations. This should not be a huge issue as there is no cron.hourly logrotate job or hourly rotations in ClearOS.

Ultimately it would be best if upstream could do something like force daily, weekly and monthly rotations to ignore the timestamp in logrotate.status, just using the datestamp, and hourly rotations to ignore the minutes and seconds in the timestamp.
NickH (developer)
2017-01-31 08:11

It looks like upstream have now closed the bug: [^]

The first patch which we used created a bit of fallout which I think was unwarranted for the issue I was trying to get fixed, and a further patch has been added which allows you to select which day you want the weekly rotations to happen by specifying a number after the WEEKLY directive, defaulting to Sunday.

I'd be happy for Peter Baldwin's patched rpm to be rolled out formally and the bug closed. Otherwise we are going to have to wait for the master branch to be released and adopted upstream.
2017-02-01 10:22


- Install: yum --enablerepo=clearos-updates-testing upgrade logrotate
- Git Repo: [^]
- Patch applied: [^]

That's the patch that was used in the previous build, so the new logrotate RPM is essentially the same package but built via the ClearOS build system. Note: the upstream patch is a little more extensive: [^]

- Issue History
Date Modified Username Field Change
2016-12-04 12:20 NickH New Issue
2016-12-05 04:22 NickH Note Added: 0004171
2016-12-05 09:55 user2 Note Added: 0004181
2016-12-05 09:55 user2 Assigned To => user2
2016-12-05 09:55 user2 Status new => confirmed
2016-12-05 09:55 user2 Target Version => 7.3.1 Updates
2016-12-05 11:34 NickH Note Added: 0004201
2017-01-31 08:11 NickH Note Added: 0004701
2017-02-01 10:22 user2 Note Added: 0004721
2017-02-01 10:23 user2 Status confirmed => resolved
2017-02-01 10:23 user2 Fixed in Version => 7.3.1 Updates
2017-02-01 10:23 user2 Resolution open => fixed
2017-02-01 10:24 user2 Category => logrotate
2017-02-10 11:43 user2 Fixed in Version 7.3.1 Updates => 7.3.0
2017-02-10 11:43 user2 Target Version 7.3.1 Updates => 7.3.0
2017-02-10 11:43 user2 Status resolved => closed
2018-07-23 08:05 user2 Issue cloned: 0020871
2018-07-23 08:05 user2 Relationship added related to 0020871