Bug 1465720 - Weekly rotations should ignore the timestamp in logrotate.status
Summary: Weekly rotations should ignore the timestamp in logrotate.status
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: logrotate
Version: 7.0
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: rc
: ---
Assignee: Kamil Dudka
QA Contact: Andrej Dzilský
Lenka Špačková
URL:
Whiteboard:
: 1510046 (view as bug list)
Depends On:
Blocks: 1420851 1465901 1466365 1472751
TreeView+ depends on / blocked
 
Reported: 2017-06-28 02:33 UTC by Xueying Nie
Modified: 2019-06-07 03:21 UTC (History)
6 users (show)

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.
Clone Of:
Environment:
Last Closed: 2018-04-10 13:49:08 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2018:0797 None None None 2018-04-10 13:49:32 UTC

Description Xueying Nie 2017-06-28 02:33:39 UTC
Description of problem:

Weekly rotations won't be executed unless it has passed more than 7*24*3600 s
since last rotation. 

Version-Release number of selected component (if applicable):

logrotate-3.8.6

How reproducible:

Change system time and run logrotate command manually.

Steps to Reproduce:

1. # ll /var/log/messages*
-rw-r--r--. 1 root root 3146 Jul  2 04:09 /var/log/messages
-rw-r--r--. 1 root root  782 Jul  2 04:02 /var/log/messages-20170702

2.# date -s "20170709 04:01";logrotate /etc/logrotate.conf 
Sun Jul  9 04:01:00 CST 2017

3.# ll /var/log/messages*
-rw-r--r--. 1 root root 5016 Jul  9 04:01 /var/log/messages
-rw-r--r--. 1 root root  782 Jul  2 04:02 /var/log/messages-20170702
 
4.# date -s "20170710 04:01";logrotate /etc/logrotate.conf 
Mon Jul 10 04:01:00 CST 2017

5.# ll /var/log/messages*
-rw-r--r--. 1 root root 1330 Jul 10 04:01 /var/log/messages
-rw-r--r--. 1 root root  782 Jul  2 04:02 /var/log/messages-20170702
-rw-r--r--. 1 root root 5927 Jul 10 04:01 /var/log/messages-20170710

6.# date -s "20170716 04:01";logrotate /etc/logrotate.conf 
Sun Jul 16 04:01:00 CST 2017

Actual results:

# ll /var/log/messages*
-rw-r--r--. 1 root root  4872 Jul 16 04:01 /var/log/messages
-rw-r--r--. 1 root root   782 Jul  2 04:02 /var/log/messages-20170702
-rw-r--r--. 1 root root  5927 Jul 10 04:01 /var/log/messages-20170710
-rw-r--r--. 1 root root 27361 Jul 16 04:01 /var/log/messages-20170716

Expected results:

/var/log/messages could be rotated on 7/9 even the rotate time is 04:01,
which is less than 7*24*3600s since last rotation.

Additional info:
1.It has no effect setting logrotate job in /etc/crontab, since the least unit  we can set is minute instead second.

2.upstream information:
https://github.com/logrotate/logrotate/issues/93

Comment 2 Kamil Dudka 2017-06-28 05:43:46 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.

Comment 9 Andrej Dzilský 2017-09-29 13:30:19 UTC
Logrotate now rotates log files even when the time is not exact 7 days (math is mentioned above).

Comment 13 Kamil Dudka 2017-11-07 13:21:01 UTC
*** Bug 1510046 has been marked as a duplicate of this bug. ***

Comment 18 Adam Pribyl 2018-04-06 13:05:47 UTC
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.

Comment 19 Pavel Kankovsky 2018-04-09 16:25:09 UTC
(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...?).

Comment 20 Kamil Dudka 2018-04-09 17:23:50 UTC
(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

Comment 21 Kamil Dudka 2018-04-09 18:08:08 UTC
(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.

Comment 23 errata-xmlrpc 2018-04-10 13:49:08 UTC
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


Note You need to log in before you can comment on or make changes to this bug.