Bug 174969 - Default logrotate config for yum produces wrong logwatch output
Default logrotate config for yum produces wrong logwatch output
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: yum (Show other bugs)
4
i386 Linux
medium Severity low
: ---
: ---
Assigned To: Jeremy Katz
:
: 178938 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-12-05 03:38 EST by Daniel Paul
Modified: 2014-01-21 17:53 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-04-19 16:49:26 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Daniel Paul 2005-12-05 03:38:58 EST
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):
yum-2.4.0-0.fc4

How reproducible:
Always

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) 

Additional info:
Comment 1 Seth Vidal 2005-12-05 16:15:43 EST
Not a yum bug.

a logwatch bug.
Comment 2 Daniel Paul 2005-12-06 04:05:09 EST
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?) 
 
Comment 3 Nerijus Baliūnas 2006-01-12 20:28:34 EST
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.
Comment 4 Seth Vidal 2006-01-13 01:26:29 EST
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.

Comment 5 Nerijus Baliūnas 2006-01-13 10:15:44 EST
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?
Comment 6 Seth Vidal 2006-01-13 10:19:17 EST
No. The yum.log time format is identical to syslogs. Changing it would be odd
and would break more things that it would fix.

Comment 7 Nerijus Baliūnas 2006-01-13 10:31:51 EST
Well, it has changed considerably in recent years:
Oct 29 03:09:58
Sau 11 01:32:45 (month in local language)
05/21/04 04:51:43
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).
Comment 8 Peter Bieringer 2006-03-31 08:39:16 EST
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

Workaround:
replace "size" by
    monthly
    rotate 48

More cleaner would be replacing "size" by
    yearly

But this works only with logrotate-3.7.2-2, see
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=134612

which is not distributed with FC4 and below.
Comment 9 Jeremy Katz 2006-04-19 16:37:18 EDT
*** Bug 178938 has been marked as a duplicate of this bug. ***
Comment 10 Jeremy Katz 2006-04-19 16:49:26 EDT
We're not going to diverge from upstream here.  There's some movement to move
towards just using the syslog stuff eventually.
Comment 11 Peter Bieringer 2006-09-28 09:39:30 EDT
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 @@
 /var/log/yum.log {
     missingok
     notifempty
-    size 30k
+    yearly
     create 0600 root root
 }

Comment 12 Jarkko 2008-04-15 10:24:34 EDT
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.
Comment 13 Peter Bieringer 2008-05-03 17:08:41 EDT
Still same issue on F8

@Reporter: please change release to "rawhide"
Comment 14 Seth Vidal 2008-05-04 09:24:46 EDT
it's not a problem in rawhide. The logrotate file had a 'yearly' added.


Comment 15 Mitchell Berger 2010-07-22 16:51:27 EDT
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:

======================
minsize size
   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.

Note You need to log in before you can comment on or make changes to this bug.