Bug 437693
| Summary: | logwatch returns packages installed/updated from past years | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | John T. Rose <inode0> |
| Component: | yum | Assignee: | James Antill <james.antill> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | 5.1 | CC: | nguyenthihongvan.tnmt |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2009-03-25 05:38:45 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: | |||
If this is a bug then it should belong to yum since it owns /etc/logrotate.d/yum. Bug 174969 seems to be about the same issue. The solution I think is to add "yearly" line to: /etc/logrotate.d/yum Thanks for the pointer to that old bug report. What in the world is the reason this isn't being fixed? On the surface it seems utterly trivial. This change went out in the 5.3 (3.2.19-18) release. |
Description of problem: In the output of logwatch today I noticed on one system --------------------- yum Begin ------------------------ Packages Installed: kernel-xen.i686 2.6.18-8.1.1.el5 Packages Updated: libgcj.i386 4.1.1-52.el5.2 nss.i386 3.11.5-3.el5 php.i386 5.1.6-7.el5 samba-client.i386 3.0.23c-2.el5.2 gnupg.i386 1.4.5-13 bind-utils.i386 30:9.3.3-8.el5 evolution-data-server-devel.i386 1.8.0-15.0.2.el5 libstdc++.i386 4.1.1-52.el5.2 php-ldap.i386 5.1.6-7.el5 libgfortran.i386 4.1.1-52.el5.2 yelp.i386 2.16.0-14.0.1.el5 module-init-tools.i386 3.3-0.pre3.1.16.0.1.el5 bind-libs.i386 30:9.3.3-8.el5 gcc-gfortran.i386 4.1.1-52.el5.2 gcc.i386 4.1.1-52.el5.2 cpp.i386 4.1.1-52.el5.2 xen-libs.i386 3.0.3-25.0.3.el5 tzdata.noarch 2007c-1.el5 devhelp.i386 0.12-10.0.1.el5 postgresql-libs.i386 8.1.8-1.el5 virt-manager.i386 0.2.6-7.0.2.el5 dhclient.i386 12:3.0.5-5.el5 php-common.i386 5.1.6-7.el5 libstdc++-devel.i386 4.1.1-52.el5.2 xen.i386 3.0.3-25.0.3.el5 evolution-data-server.i386 1.8.0-15.0.2.el5 kernel-headers.i386 2.6.18-8.1.1.el5 firefox.i386 1.5.0.10-2.el5 gcc-c++.i386 4.1.1-52.el5.2 nss-tools.i386 3.11.5-3.el5 Deployment_Guide-en-US.noarch 5.0.0-21 libgomp.i386 4.1.1-52.el5.2 libgcc.i386 4.1.1-52.el5.2 autofs.i386 1:5.0.1-0.rc2.43.0.2 samba-common.i386 3.0.23c-2.el5.2 emacs-leim.i386 21.4-18.1.el5 php-cli.i386 5.1.6-7.el5 ---------------------- yum End ------------------------- All of this stuff is from Mar 15 2007 rather than Mar 15 2008. Version-Release number of selected component (if applicable): logrotate-3.7.4-8 logwatch-7.3-5 How reproducible: Run logwatch against a /var/log/yum.log file that contains logs that exceed one year in age. Steps to Reproduce: 1. Use a default configuration of logwatch and logrotate 2. Let /var/log/yum.log age more than one year without being rotated 3. Check output of logwatch Actual results: logwatch returns packages listed for the Month/Day for all years present in /var/log/yum.log Expected results: logwatch returns packages only for the Month/Day of the current year Additional info: Since yum.log doesn't log the year I think the best solution to this issue is to have the default configuration of logrotate for rotation of this log be at least yearly rather than just being based on log size, which in some cases won't get the rotation done in time. Perhaps yum could log the year and logwatch could be expected to account for that in which case logrotate isn't involved. Please let me know if you think I should file this against different components.