Bug 447021

Summary:	Logs should be rotated at least once a year to avoid problems with Logwatch and similar tools
Product:	Red Hat Enterprise Linux 5	Reporter:	Filipe Brandenburger <filbranden>
Component:	logrotate	Assignee:	Daniel Novotny <dnovotny>
Status:	CLOSED NOTABUG	QA Contact:
Severity:	low	Docs Contact:
Priority:	low
Version:	5.1	CC:	ajb, blocke, jon, phil, ralph+rh-bugzilla
Target Milestone:	rc
Target Release:	---
Hardware:	All
OS:	Linux
URL:	http://lists.centos.org/pipermail/centos/2008-May/098839.html
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2008-08-28 11:11:46 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Filipe Brandenburger 2008-05-17 00:30:01 UTC

Description of problem:

Syslog does not log the year on the logs. Other programs (such as "logwatch") do
reports by grepping the logs on the date (in "Mon DD" format) and sending such
reports by e-mail. But as syslog does not log the year, if you have a log that
is more than one year old, you will be getting e-mails saying that what happened
one year old happened yesterday.

This problem bit me once, and I just saw it bit two different people in CentOS
list. See the threads at:

http://lists.centos.org/pipermail/centos/2008-May/098839.html
http://lists.centos.org/pipermail/centos/2008-May/099200.html

I would suggest including in logrotate a default policy that would force a
yearly logrotate (or two per year actually) to avoid this issue happening in the
future.



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

Any.



How reproducible:

Every time.



Steps to Reproduce:
1. Set up a box which runs syslog, logrotate and logwatch
2. Update some packages using yum (to generate logs in yum.log). NOTE: This
could actually be any other log that does not grow enough to be rotated in an year.
3. Wait for 1 year and 1 day.
4. Check your logwatch e-mail.

  
Actual results:

It will say that you installed/upgraded some packages yesterday (when in fact
they were updated last year).



Expected results:

It won't say that you installed/upgraded those packages yesterday.



Additional info:

N/A

Comment 1 Ralph Angenendt 2008-05-17 10:19:12 UTC

It's probably enough to lower the "size 30k" in the yum snippet in
/etc/logrotate.d/ - if people do not install that much software on their
machines except updates this size seems to be too big. Or insert a "monthly"
there, so that the yum.log is rotated once per month.

Comment 2 Alan Bartlett 2008-05-17 12:02:01 UTC

My work-around is to comment out the "size 30k" line and add a "yearly" line
within the /etc/logrotate.d/yum file.

Comment 3 Tomas Smetana 2008-05-26 07:21:17 UTC

I understand the problem but I would also expect the administrators to set their
machines up according to their needs.  There is no default configuration that
would suite everyone.

Comment 4 Tomas Smetana 2008-08-28 11:11:46 UTC

I consider this to be an configuration error, therefore closing.

Comment 5 Bruce A. Locke 2008-12-13 18:35:58 UTC

I just spent 15 minutes on a Saturady panicked that one of my servers had been compromised before I found this.

This is clearly and oversight and a bug in the DEFAULT configuration of the system and would be trivial for the packager to fix.

If the DEFAULT configuration has incorrect behavior then it should be fixed.  It should not be expected that every customer will need to discover this and find this bug report to understand what went wrong.  This just ends up as cruft that annoys people for no sane reason.

Comment 7 Jon Jensen 2016-10-03 21:43:27 UTC

Tomas Smetana, this is indeed a configuration error, in the default setup. It is a bug.

This problem just bit me on a bunch of RHEL 7 systems.

It's been bothering people for at least 10 years, as evidenced by this mailing list thread:

https://www.redhat.com/archives/fedora-legacy-list/2006-September/msg00004.html

The correct fix seems to me to have yum log with proper complete timestamps.

But an even easier change for this specific problem would be to get rid of the logrotate "size 30k" limit, or change it from yearly to monthly rotation. Can we please do that? That would be a trivial change that I don't see harming anyone -- I don't know of any sysadmins who expect logs to remain unrotated for a year.

This was fixed in just this way on Fedora -- in a Fedora 24 installation dnf still has the lame incomplete timestamps (and I don't even see a documented way to have dnf send its logs to syslog) -- but /etc/logrotate.d/dnf has weekly rotation of its logfiles, with no size limit. Exactly that simple solution I believe should be backported to RHEL 5, 6, and 7.