From Bugzilla Helper:
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.4) KHTML/3.4.2 (like Gecko)
Description of problem:
The default logrotate config for yum shipped with fc4 (all current updates) is
located at /etc/logrotate.d/yum and contains the line size=30k.
On our server this caused the daily logwatch run on "yum package updates" to
display entries from 2004/12/04 (NOT 2005/12/04), because the log was not
rotated since one year (!).
This can be very confusing for the sysadmin at first look, because I didn't
run any package updates that night...
May be the "size" line should be removed from /etc/logrotate.d/yum?
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. install packages logwatch, logrotate, yum
2. keep standard config for /etc/logrotate.d/yum
3. wait one year ;-)
Actual Results: Possibly get old entries from daily logwatch run (and please, please be also
scared, like me this morning!)
Expected Results: logwatch should show right information about package updates (from one day
ago, not 366 days ago)
Not a yum bug.
a logwatch bug.
Not a logwatch bug, because logwatch is not able to determine the year a log
entry was made from the standard log format yum uses:
Dec 06 09:36:58 Updated: openoffice.org-core.i386 1:2.0.1-143.2.1
So the only way is to ensure, that the log is definitely rotated at least once
in a year or to change the log format:
- change /etc/logrotate.d/yum OR
- change yum log format (defined internally in yum, I think?)
Changing yum log format (adding year to it) would be good in a long run, but for
now /etc/logrotate.d/yum should probably be changed to rotate when size is 20k,
not 30k. Because now on FC3 system yum.log is 27k (after a year of updates), so
20k would be a good temporarily fix.
well I just checked in some code so you can essentially turn off the logfile and
yum will log to syslog for you instead.
so that might be an amenable solution for the future.
I actually like separate yum logfile, you can easily see what and when was
updated in case of problems. Did you consider adding year to log file?
No. The yum.log time format is identical to syslogs. Changing it would be odd
and would break more things that it would fix.
Well, it has changed considerably in recent years:
Oct 29 03:09:58
Sau 11 01:32:45 (month in local language)
So I'd suggest to change it the last time, but it's up to you.
It would still be nice to know a year in past logs (some people might even
"collect" them in order to have all the history).
Same happen to me on a small CentOS system without a huge amount of packages.
After a year, yum.log has around 18 k.
See also: http://bugs.centos.org/view.php?id=1283
replace "size" by
More cleaner would be replacing "size" by
But this works only with logrotate-3.7.2-2, see
which is not distributed with FC4 and below.
*** Bug 178938 has been marked as a duplicate of this bug. ***
We're not going to diverge from upstream here. There's some movement to move
towards just using the syslog stuff eventually.
Same happen on FC5.
Since current version of logrotate is 3.7.3-2.2.1, which support "yearly" I
would suggest to change /etc/logrotate.d/yum in following manner:
--- /etc/logrotate.d/yum.orig 2006-09-28 15:38:39.000000000 +0200
+++ /etc/logrotate.d/yum 2006-09-28 15:38:49.000000000 +0200
@@ -1,6 +1,6 @@
- size 30k
create 0600 root root
Don't remove the "size 30k" line. Just add "yearly". That will fix this bug:
1) yum.log will still be rotated when it grows bigger than 30k (no change here)
2) yum.log will also be rotated when there has been over a year from the last
rotation (because this assures it rotates at least once a year, this fixes this bug)
So we should reopen this one against rawhide, add the "yearly" line and close
this as fixed.
Still same issue on F8
@Reporter: please change release to "rawhide"
it's not a problem in rawhide. The logrotate file had a 'yearly' added.
Much as it pains me to request that a bug from half a decade ago
be reopened, please reopen this and mark it against any of F12,
F13, or Rawhide, all arches, because it still affects all of them.
(In reply to comment #12)
> Don't remove the "size 30k" line. Just add "yearly". That will fix this bug:
> 1) yum.log will still be rotated when it grows bigger than 30k (no change here)
> 2) yum.log will also be rotated when there has been over a year from the last
> rotation (because this assures it rotates at least once a year, this fixes this bug)
> So we should reopen this one against rawhide, add the "yearly" line and close
> this as fixed.
This comment led us down the wrong path. The change Peter suggested
in comment #11 was the correct one, though you have to read a nonobvious
section of the logrotate manpage to find out why:
Log files are rotated when they grow bigger then size bytes, but
not before the additionally specified time interval (daily, weekly,
monthly, or yearly). The related size option is similar except that
it is mutually exclusive with the time interval options, and it
causes log files to be rotated without regard for the last rotation
time. When minsize is used, both the size and timestamp of a log
file are considered.
As a result of this obscure bit of info only documented in the
description of a different logrotate directive, the change that was
made is actually a noop.
Please remove the "size 30k" line from yum's logrotate config.