Red Hat Bugzilla – Bug 135147
Excessive swap and cpu usage when system-logviewer loads
Last modified: 2007-11-30 17:10:51 EST
Description of problem:
When system-logviewer loads (and subsequently when using the program)
an excessive amount of swap activity occurs with high cpu usage
(maxed). Before the logviewer window is displayed over 400Mb of swap
space has been claimed by python. After using the viewer for a short
period another block of swapping activity locks up the system so X
does not even refresh. Occassionally the logviewer cpu usage will
cease and it will function normally for a short period before cpu
usage again maxes out.
Attaching to python from a vt and killing the process allowed X to
refresh again, system running fine.
Version-Release number of selected component (if applicable):
Consistent. Repeated but only 3 times so far.
System becomes unusable while attempting to view logs.
Logviewer should display all logfile entries without consuming large
amounts of swap space.
system-logviewer was started from a root (su -) logged in terminal in
a normal user X session.
backtrace of python during this issue is attached
It appears to be stuck in a library call from gtk2-devel.
/usr/lib/libgtk-x11-2.0.so.0 -> libgtk-x11-2.0.so.0.400.10
Created attachment 104967 [details]
backtrace of python running system-logviewer
This backtrace is not taken while the system is fully hung, I cannot
bring it to a complete hang state, but the backtrace does change at
different times while continuing under gdb. It has been deeper, into
xft calls but this so if this is not very helpful I'd appreciate hints
how to recover something that will help more. I am new to fairly new
What is your refresh time set too in Preferences?
Which log are you viewing when this occurs. What is the actuall log
ls -al /var/log/
Please could you show the memory usage via vmstat or top for
For more detailed X resource usage can you do (yum install xrestop):
xrestop -b | grep -A 14 system-logviewer
Whilst memory use is high.
I apologize for the delay in getting back to this one. I had the requested
output but cannot find it.. and cannot reproduce the behavior anymore. I will
make another attempt to push the program and see what happens, but (see below) I
think this may have been a problem "between chair and keyboard". It is a shame
Bugzilla doesn't have a resolution to fit that.
What I did find out was that I had one messages logfile (I think it was rotated
and gzip'd but not positive now) that was 90+ Mb of runaway selinux spam. The
refresh being used was default, which appears to be 30secs. That might create
an unreasonable load on parsing the logs.
Perhaps logs of 'larger' size should not refresh, although the initial load
would still take a long time. If this was simply a problem of my one large
logfile it made the system unusable while the process was still running, and
that should be avoided if possible.
system-logviewer has been removed from core.