weekly log rotation is often a day late

Bug #1649168 reported by Doug Smythies
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
logrotate (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

Over the last few Ubuntu releases, the status file the logrotate generates and uses has added more detail to the time stamp information.

In 12.04 it seems to only keep information to the day.
In 14.04 it seems to keep information to the second.
In 16.04 it seems to keep information to the second.

However, the weekly section of the logrotate program calculates the time since the last rotation to the second with absolutely no jitter margin, and therefore as often as every other week, weekly logs that should rotate on Sunday do not rotate until Monday. I have 43 weeks of weekly rotation data, where on 17 of those weeks the rotation was on Monday and not Sunday. Note that the week after Monday rotation it will always rotate on Sunday due to "the current weekday is before the weekday of the last rotation" condition.

Code segment:

        case ROT_WEEKLY:
            /* rotate if:
               1) the current weekday is before the weekday of the
               last rotation
               2) more then a week has passed since the last
               rotation */
            state->doRotate = ((now.tm_wday < state->lastRotated.tm_wday)
                               ||
                               ((mktime(&now) -
                                 mktime(&state->lastRotated)) >
                                (7 * 24 * 3600)));

There is an upstream bug report at:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825776
which I will attempt to link in. It suggests introducing a 60 jitter allowance. I would make it more myself.

I first noticed this issue during 16.04 development in 2016.02 (Feb). However, that computer had previously been a 12.04 server, so I do not have good data about 14.04.
See also: https://ubuntuforums.org/showthread.php?t=2320149

Do not ask me to run apport collect for this bug report, because it is not needed, and it never works for me anyhow.

summary: - weekly log roation is often a day late
+ weekly log rotation is often a day late
Revision history for this message
Doug Smythies (dsmythies) wrote :

There is also issue 93 at GitHub:

https://github.com/logrotate/logrotate/issues/93

I seem to be unable to create a GitHub account so that I can add to the issue discussion, and point to here.

description: updated
Revision history for this message
Doug Smythies (dsmythies) wrote :

In addition to the proper fix for this issue, they are wanting to make a fundamental change to how weekly log rotation works by eliminating the migration to Sunday portion. This part of the change should NOT be done, in my opinion. Before it is too late, Please chime in on the upstream thread.

https://github.com/logrotate/logrotate/issues/93

Revision history for this message
Doug Smythies (dsmythies) wrote :

The now upstream committed solution to this issue ( https://github.com/logrotate/logrotate/issues/93 ) does not change the default way logrotate worked in the past. So now it just has to make its way downstream.

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in logrotate (Ubuntu):
status: New → Confirmed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.