Description of problem: For some reason, setroubleshootd decided to fill available memory on my system. Version-Release number of selected component (if applicable): 2.0.8-2.fc9 How reproducible: Not very. This is the first time I've caught it in the act after running Fedora 9 since its release. That's not to say it hasn't happened before; filling system memory tends to make a Linux system unusable (or nearly so). If not caught early enough, this kind of problem could exhibit as apparently arbitrary unresponsiveness.
Created attachment 312500 [details] Screen shot showing the memory footprint of setroubleshootd
Are you running SELinux in permissive mode? Do you have a huge number of AVC's? If you restart setroubleshootd does it attempt to grow to this size again? What is the output of ' ls -l /var/lib/setroubleshoot/'
It's in enforcing mode. $ ls -l /var/lib/setroubleshoot/ total 40 -rw------- 1 root root 30959 2008-07-23 12:42 audit_listener_database.xml -rw------- 1 root root 0 2008-02-28 22:07 email_alert_recipients I didn't notice a large number of AVC messages before; but maybe I just missed them. Because upon restarting the service, I'm seeing huge numbers of these: SELinux is preventing gam_server (unlabeled_t) "getattr" to inotify (inotifyfs_t). SELinux is preventing gam_server (unlabeled_t) "read" to inotify (inotifyfs_t).
killall gam_server There is a bug in the latest policy, that causes a running gam_server to go nuts. If you just kill the app everything should be fine. This was fixed in selinux-policy-3.3.1-79.fc9.noarch
So this looks like setroubleshoot is leaking memory when it gets one AVC repeatedly.
There are a few possibilities. First of all we should check there aren't a large number of alerts, but given the size of the database that does not seem likely (setroubleshoot should have collapse the thousands of AVC from gaim into 1 or 2 alerts with high "incident counts"). Leaked memory might be the result of Python exceptions where we take a unusual exit and never clean up a resource. Exception tracebacks are recorded in /var/log/setroubleshoot/setroubleshootd.log and syslog (/var/log/messages). Do either of these show Python stack traces. Otherwise it's likely something we link with, libxml2 and rpm are two likely culprits.
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '9'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 9's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 9 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
setroubleshoot now exits after receiving avc messages so this is really no longer a problem, if the problem still exists.