| Anonymous | Login | 2024-12-21 23:56 MST |
| Main | My View | View Issues | Change Log | Roadmap | Repositories |
| View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
| ID | 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 | 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. | ||||||||
| Tags | No tags attached. | ||||||||
| Attached Files | |||||||||
 Relationships |
||||||
|
||||||
 Relationships |
|
Notes |
|
|
(0004171) NickH (developer) 2016-12-05 04:22 |
From https://www.clearos.com/clearfoundation/social/community/clearos-7-logrotate-not-always-rotating-as-expected#reply-155891, [^] it makes no difference whether or not you use "dateext" |
|
(0004181) user2 2016-12-05 09:55 |
Nice one Nick! |
|
(0004201) 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. |
|
(0004701) NickH (developer) 2017-01-31 08:11 |
It looks like upstream have now closed the bug: https://github.com/logrotate/logrotate/issues/93 [^] 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. |
|
(0004721) user2 2017-02-01 10:22 |
Done! - Install: yum --enablerepo=clearos-updates-testing upgrade logrotate - Git Repo: https://github.com/clearos/logrotate [^] - Patch applied: https://github.com/clearos/logrotate/blob/clear7/SOURCES/logrotate-3.8.6-weekly.patch [^] 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: https://github.com/logrotate/logrotate/commit/bd2638856dbbb6c0a47beb85fe8a8a628160772e [^] |
|
Notes |
|
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 |
|
Issue History |