| Summary: | Weekly rotations should ignore the timestamp in logrotate.status | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Xueying Nie <xnie> |
| Component: | logrotate | Assignee: | Kamil Dudka <kdudka> |
| Status: | CLOSED ERRATA | QA Contact: | Andrej Dzilský <adzilsky> |
| Severity: | medium | Docs Contact: | Lenka Špačková <lkuprova> |
| Priority: | unspecified | ||
| Version: | 7.0 | CC: | adzilsky, covex, fsumsal, grdetil, kdudka, xnie |
| Target Milestone: | rc | Keywords: | Patch |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | logrotate-3.8.6-15.el7 | Doc Type: | Release Note |
| Doc Text: |
Weekly log rotations are now triggered more predictably
Weekly log rotations were previously performed by the *logrotate* utility when exactly 7 days (604800 seconds) elapsed since the last rotation. Consequently, if the "logrotate" command was triggered by a cron job slightly sooner, the rotation was delayed until the next run. With this update, weekly log rotations ignore the exact time. As a result, when the day counter advances by 7 or more days since the last rotation, a new rotation is triggered.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2018-04-10 13:49:08 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Bug Depends On: | |||
| Bug Blocks: | 1420851, 1465901, 1466365, 1472751 | ||
|
Description
Xueying Nie
2017-06-28 02:33:39 UTC
I believe this is safe to backport from upstream. The commit in question was included in the upstream release 3.12.1 and has been used in Fedora since April 2017 without any bug reports so far. Logrotate now rotates log files even when the time is not exact 7 days (math is mentioned above). *** Bug 1510046 has been marked as a duplicate of this bug. *** You may pay attention to this thread (Czech only): http://www.linux.cz/pipermail/linux/2018-April/276746.html where Pavel Kankovsky explains the issue and points out the patch that solves that in logrotate git. (In reply to Adam Pribyl from comment #18) The thread in question discusses two different issues: Issue #1 seems to be the same issue as this bugzilla entry, that is weekly rotations randomly slipping to Monday. My findings seem to be in line with the aforementioned upstream bug no. 93. Issue #2, on the other hand, seems to be a completely different bug related to a spurious monthly rotation that happened several days after a transition to DST. I can't find anything related in RH bugzilla (someone might want to create a new report...?). (In reply to Pavel Kankovsky from comment #19) > Issue #2, on the other hand, seems to be a completely different bug related > to a spurious monthly rotation that happened several days after a transition > to DST. I can't find anything related in RH bugzilla (someone might want to > create a new report...?). This is already tracked as bug #1556993, which is currently private. An upstream fix exists for that (assuming we are talking about the same issue): https://github.com/logrotate/logrotate/commit/r3-8-8~2#diff-c77f766704c11808480548296cdd6787 (In reply to Kamil Dudka from comment #20) > This is already tracked as bug #1556993, which is currently private. The above bug has just been disclosed for public. Please continue the related discussion there if needed. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2018:0797 |