Bug 974335 - rsyslog-7.4.0-1.fc19 appears to fill /var/log/messages continuously with old entries - making the machine sluggish
Summary: rsyslog-7.4.0-1.fc19 appears to fill /var/log/messages continuously with old ...
Keywords:
Status: CLOSED DUPLICATE of bug 974132
Alias: None
Product: Fedora
Classification: Fedora
Component: rsyslog
Version: 19
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Tomas Heinrich
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-06-14 02:46 UTC by Satish Balay
Modified: 2016-09-20 04:51 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-06-14 06:48:56 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Satish Balay 2013-06-14 02:46:33 UTC
Description of problem:

rsyslog-7.4.0-1.fc19 appears to fill /var/log/messages continuously with old [dated] entries - making the machine sluggish

Version-Release number of selected component (if applicable):
rsyslog-7.4.0-1.fc19.x86_64

How reproducible:

The behaviour continued even after reboot

Steps to Reproduce:
1. yum update
2. tail -f /var/log/messages
3.

Actual results:

the machine is sluggish
/var/log/messages have continuous new additions with 'april' dates.


Expected results:

not sluggish machine
a sane /var/log/messages.

Additional info:

reverting to rsyslog-7.2.6-1.fc19.x86_64 fixed the problem.

Sample of /var/log/messages [when it switched from using current date to sometime in april

>>>>>>
Jun 13 17:13:39 asterix dhclient[911]: DHCPREQUEST on wlan0 to 1.1.1.1 port 67 (xid=0x4397059b)
Jun 13 17:13:43 asterix setroubleshoot: SELinux is preventing /usr/libexec/accounts-daemon from read access on the directory /var/log. For complete SELinux messages. run seale
rt -l 8c4596c4-9aae-4d85-b2ab-2c26f8a623d4
Jun 13 17:13:59 asterix dhclient[911]: DHCPREQUEST on wlan0 to 1.1.1.1 port 67 (xid=0x4397059b)
Jun 13 17:13:59 asterix /etc/gdm/Xsession[954]: ** (nm-applet:1498): WARNING **: Could not find ShellVersion property on org.gnome.Shell after 5 tries
Jun 13 17:13:59 asterix rsyslogd: [origin software="rsyslogd" swVersion="7.2.6" x-pid="383" x-info="http://www.rsyslog.com"] exiting on signal 15.
Jun 13 17:14:02 asterix rsyslogd: [origin software="rsyslogd" swVersion="7.4.0" x-pid="22026" x-info="http://www.rsyslog.com"] start
Apr 22 19:54:19 asterix systemd-logind: Lid closed.
Apr 22 19:54:19 asterix systemd-logind: Suspending...
Apr 22 19:54:19 asterix NetworkManager[440]: <info> sleep requested (sleeping: no  enabled: yes)
Apr 22 19:54:19 asterix NetworkManager[440]: <info> sleeping or disabling...
Apr 22 19:54:19 asterix NetworkManager[440]: <info> (em1): device state change: unavailable -> unmanaged (reason 'sleeping') [20 10 37]
Apr 22 19:54:19 asterix NetworkManager[440]: <info> (em1): cleaning up...
Apr 22 19:54:19 asterix NetworkManager[440]: <info> (em1): taking down device.
Apr 22 19:54:19 asterix NetworkManager[440]: <info> (wlan0): device state change: activated -> unmanaged (reason 'sleeping') [100 10 37]
Apr 22 19:54:19 asterix NetworkManager[440]: <info> (wlan0): deactivating device (reason 'sleeping') [37]
Apr 22 19:54:19 asterix NetworkManager[440]: <info> (wlan0): canceled DHCP transaction, DHCP client pid 25895
Apr 22 19:54:19 asterix avahi-daemon[410]: Withdrawing address record for 192.168.0.2 on wlan0.
Apr 22 19:54:19 asterix avahi-daemon[410]: Leaving mDNS multicast group on interface wlan0.IPv4 with address 192.168.0.2.
Apr 22 19:54:19 asterix NetworkManager[440]: <info> (wlan0): cleaning up...
Apr 22 19:54:19 asterix dnsmasq[718]: no servers found in /etc/resolv.conf, will retry
Apr 22 19:54:19 asterix NetworkManager[440]: <info> (wlan0): taking down device.
Apr 22 19:54:19 asterix avahi-daemon[410]: Interface wlan0.IPv4 no longer relevant for mDNS.
<<<<<<<<

Comment 1 Jason Montleon 2013-06-14 04:25:03 UTC
Same issue for me. I had one host constantly replaying stuff from March 28th and another from June 5th. Interestingly I had a third host that did not seem affected. All were upgrades from Fedora 18 and downgrading got all working sanely again.

Noticed I had a 28G /var/log/messages on one host after wondering why the fan was working so hard and seeing 100+ percent CPU utilization caused by rsyslog.

Same package version causing the problem, same downgrade resolved it.

Comment 2 Jason Montleon 2013-06-14 04:38:02 UTC
to clarify 'downgrading' I meant from rsyslog-7.4.0-1.fc19.x86_64 to rsyslog-7.2.6-1.fc19.x86_64

Comment 3 Jason Montleon 2013-06-14 04:52:31 UTC
Cleaned up /var/log/journal/*/*journal~ and the problem went away. The unaffected host had no such files hanging around. It seems to be handling the existence of these files very poorly.

Comment 4 Adam Williamson 2013-06-14 06:48:02 UTC
*** Bug 974332 has been marked as a duplicate of this bug. ***

Comment 5 Tomas Heinrich 2013-06-14 06:48:56 UTC

*** This bug has been marked as a duplicate of bug 974132 ***

Comment 6 Adam Williamson 2013-06-14 06:50:00 UTC
Could folks affected please leave -1 karma on https://admin.fedoraproject.org/updates/FEDORA-2013-10782/librelp-1.0.3-1.fc19,rsyslog-7.4.0-1.fc19 to get the update un-pushed? Thanks.


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