Bug 1465720

Summary: Weekly rotations should ignore the timestamp in logrotate.status
Product: Red Hat Enterprise Linux 7 Reporter: Xueying Nie <xnie>
Component: logrotateAssignee: Kamil Dudka <kdudka>
Status: CLOSED ERRATA QA Contact: Andrej Dzilský <adzilsky>
Severity: medium Docs Contact: Lenka Špačková <lkuprova>
Priority: unspecified    
Version: 7.0CC: adzilsky, covex, fsumsal, grdetil, kdudka, xnie
Target Milestone: rcKeywords: 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
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