Bug 974335 - rsyslog-7.4.0-1.fc19 appears to fill /var/log/messages continuously with old entries - making the machine sluggish
rsyslog-7.4.0-1.fc19 appears to fill /var/log/messages continuously with old ...
Status: CLOSED DUPLICATE of bug 974132
Product: Fedora
Classification: Fedora
Component: rsyslog (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Tomas Heinrich
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-13 22:46 EDT by Satish Balay
Modified: 2016-09-20 00:51 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-06-14 02:48:56 EDT
Type: Bug
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 Satish Balay 2013-06-13 22:46:33 EDT
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 00:25:03 EDT
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 00:38:02 EDT
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 00:52:31 EDT
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 02:48:02 EDT
*** Bug 974332 has been marked as a duplicate of this bug. ***
Comment 5 Tomas Heinrich 2013-06-14 02:48:56 EDT

*** This bug has been marked as a duplicate of bug 974132 ***
Comment 6 Adam Williamson 2013-06-14 02:50:00 EDT
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.