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
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.
My work-around is to comment out the "size 30k" line and add a "yearly" line within the /etc/logrotate.d/yum file.
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.
I consider this to be an configuration error, therefore closing.
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.
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.