Description of problem: On my F7 machine which is up for 44 days now setroublshootd is reported to consume 196M is resident memory. 00601000-1280e000 rw-p 00601000 00:00 0 [heap] Size: 297012 kB Rss: 195356 kB Shared_Clean: 0 kB Shared_Dirty: 0 kB Private_Clean: 208 kB Private_Dirty: 195148 kB Version-Release number of selected component (if applicable): setroubleshoot-1.9.4-2.fc7.noarch How reproducible: no idea Steps to Reproduce: 1.run F7 machine for some time 2. 3. Actual results: see above Expected results: I see no reason why the heap should ever be more than a few MBs. Additional info:
I wonder if you may be experiencing a known problem with i18n handling which will cause an exception which may fail to clean up memory. Could you please take a look at /var/log/setroubleshoot/setroubleshood.log and look for any python tracebacks (e.g. search for 'trace'). If you find tracebacks could you please add them to this bugzilla. If you don't find any tracebacks could you please tell me the size of this file: /var/lib/setroubleshoot/audit_listener_database.xml Question: I assume the memory usage output included in the original bug report was cut and pasted from the output of /proc/pid/smaps, for reasons I do not undertand on my systems I never see any entry labeled [heap], although there are a number of anonymous regions, can you shed some light on why /proc/pid/smaps would not have a [heap] region?
/var/log/setroubleshoot/setroubleshood.log is empty. # ll /var/lib/setroubleshoot/audit_listener_database.xml -rw-r--r-- 1 root root 617816 2007-05-13 21:03 /var/lib/setroubleshoot/audit_listener_database.xml The only reason there could be no [heap] (aside from kernel issues) is that sbrk() is never used. Instead malloc is used for allocations. This should not happen unless the allocations are too large. Anyway, this is the current state of the same process (now after 51 days) 00601000-13b33000 rw-p 00601000 00:00 0 [heap] Size: 316616 kB Rss: 247460 kB Shared_Clean: 0 kB Shared_Dirty: 0 kB Private_Clean: 14200 kB Private_Dirty: 233260 kB Still creeping up.
Created attachment 158547 [details] concatenated /var/log/setroubleshoot/* log files. I have to add big +1 here -- apparently leaking setroubleshootd in couple of days pushed my two-processor dual-core 1GB RAM computer to the crawl. Only when it blicked on me in top that setroubleshootd occupies around 540+MB [...] I killed it and now my comp is happy again. Attached are /var/log/setroubleshoot/setroubleshoot.* log files and /var/lib/setroubleshoot/audit_listener_database.xml has 13K. I cannot find it in any log but when switching to console (the only place, where my computer was at least slightly responsive) I saw there message something about /var/lib/setroubleshoot/audit_listener_database.xml containing non-XML unprintable characters and incorrect CDATA. However, just now xmllint doesn't complain, so I don't know what it was.
Me too! 345MB cat /proc/27721/status Name: setroubleshootd State: S (sleeping) Tgid: 27721 Pid: 27721 PPid: 1 TracerPid: 0 Uid: 0 0 0 0 Gid: 0 0 0 0 FDSize: 32 Groups: 0 1 2 3 4 6 10 VmPeak: 441896 kB VmSize: 343584 kB VmLck: 0 kB VmHWM: 378248 kB VmRSS: 312712 kB VmData: 327696 kB VmStk: 152 kB VmExe: 4 kB VmLib: 12956 kB VmPTE: 356 kB StaBrk: 0804a000 kB Brk: 1b723000 kB StaStk: bf9a5410 kB ExecLim: 08049000 Threads: 3 SigQ: 0/15343 SigPnd: 0000000000000000 ShdPnd: 0000000000000000 SigBlk: 0000000000000000 SigIgn: 0000000001001000 SigCgt: 0000000180004007 CapInh: 0000000000000000 CapPrm: 00000000fffffeff CapEff: 00000000fffffeff Cpus_allowed: 00000003 Mems_allowed: 1
would you please try installing the latest version, setroubleshoot-1.10.7-1.fc8 and see if this resolves your problem. I believe in each of the reported cases the native language was not english and known bugs have been fixed relating to i18n handling (which I believe was causing exceptions, which then failed to clean up after itself).
No improvement! with Package Arch Version Repository Size ============================================================================= Updating: setroubleshoot noarch 1.10.7-1.fc8 development 100 k Installing for dependencies: setroubleshoot-plugins noarch 1.10.3-1.fc8 development 474 k xdg-utils noarch 1.0.2-2.fc8 development 51 k Updating for dependencies: setroubleshoot-server noarch 1.10.7-1.fc8 development 776 k I get: cat /proc/24817/status Name: setroubleshootd State: S (sleeping) Tgid: 24817 Pid: 24817 PPid: 1 TracerPid: 0 Uid: 0 0 0 0 Gid: 0 0 0 0 FDSize: 32 Groups: 0 1 2 3 4 6 10 VmPeak: 346824 kB VmSize: 346824 kB VmLck: 0 kB VmHWM: 314436 kB VmRSS: 314436 kB VmData: 330212 kB VmStk: 164 kB VmExe: 4 kB VmLib: 13620 kB VmPTE: 364 kB StaBrk: 0804a000 kB Brk: 1b6d1000 kB StaStk: bf9243a0 kB ExecLim: 08049000 Threads: 3 SigQ: 0/15343 SigPnd: 0000000000000000 ShdPnd: 0000000000000000 SigBlk: 0000000000000000 SigIgn: 0000000001001000 SigCgt: 0000000180004007 CapInh: 0000000000000000 CapPrm: 00000000fffffeff CapEff: 00000000fffffeff Cpus_allowed: 00000003 Mems_allowed: 1 I see no problems in /var/log/setroubleshoot: cat setroubleshootd.log 2007-10-27 09:05:06,251 [email.WARNING] cannot open file /var/lib/setroubleshoot/email_alert_recipients, No such file or directory I think it is related to the size of the audit log file? ls -l ../audit/audit.log* -rw-r----- 1 root root 1917790 2007-10-27 09:05 ../audit/audit.log -r--r----- 1 root root 5243047 2007-10-24 20:35 ../audit/audit.log.1 -r--r----- 1 root root 5243068 2007-10-17 19:40 ../audit/audit.log.2 -r--r----- 1 root root 5243042 2007-10-09 18:37 ../audit/audit.log.3
I can see it as well (BTW, does it matter, that I have x86_64 here): [matej@hubmaier ~]$ pgrep -f -l setrouble 21179 /usr/bin/python -E /usr/sbin/setroubleshootd [matej@hubmaier ~]$ cat /proc/21179/status Name: setroubleshootd State: S (sleeping) Tgid: 21179 Pid: 21179 PPid: 1 TracerPid: 0 Uid: 0 0 0 0 Gid: 0 0 0 0 FDSize: 64 Groups: 0 1 2 3 4 6 10 VmPeak: 257120 kB VmSize: 253836 kB VmLck: 0 kB VmHWM: 19824 kB VmRSS: 9876 kB VmData: 32568 kB VmStk: 156 kB VmExe: 4 kB VmLib: 13188 kB VmPTE: 512 kB StaBrk: 00601000 kB Brk: 00c45000 kB StaStk: 7fff6f613fa0 kB Threads: 3 SigQ: 1/16372 SigPnd: 0000000000000000 ShdPnd: 0000000000000000 SigBlk: 0000000000000000 SigIgn: 0000000001001000 SigCgt: 0000000180004007 CapInh: 0000000000000000 CapPrm: 00000000fffffeff CapEff: 00000000fffffeff Cpus_allowed: 00000000,0000000f Mems_allowed: 00000000,00000001 voluntary_ctxt_switches: 1127822 nonvoluntary_ctxt_switches: 315 [matej@hubmaier ~]$ rpm -q setroubleshoot setroubleshoot-1.10.7-1.fc8.noarch [matej@hubmaier ~]$
Forgot to add: [matej@hubmaier ~]$ ls -lh /var/lib/setroubleshoot/ celkem 32K -rw------- 1 root root 25K 2007-10-29 10:34 audit_listener_database.xml [matej@hubmaier ~]$ ls -lh /var/log/setroubleshoot/setroubleshootd.log* -rw-r--r-- 1 root root 0 2007-10-28 04:53 /var/log/setroubleshoot/setroubleshootd.log -rw-r--r-- 1 root root 3,3K 2007-07-04 21:41 /var/log/setroubleshoot/setroubleshootd.log-concatenated -rw-r--r-- 1 root root 0 2007-09-16 04:57 /var/log/setroubleshoot/setroubleshootd.log.1 -rw-r--r-- 1 root root 0 2007-09-09 04:54 /var/log/setroubleshoot/setroubleshootd.log.2 -rw-r--r-- 1 root root 131 2007-10-16 12:22 /var/log/setroubleshoot/setroubleshootd.log-20071021 -rw-r--r-- 1 root root 0 2007-10-21 04:53 /var/log/setroubleshoot/setroubleshootd.log-20071028 [matej@hubmaier ~]$
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. 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 '7'. 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 7'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 7 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. 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. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists. Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs: http://docs.fedoraproject.org/release-notes/ The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I think this is pretty much under control in F8. 00601000-00efe000 rw-p 00601000 00:00 0 [heap] Size: 9204 kB Rss: 2156 kB Shared_Clean: 0 kB Shared_Dirty: 0 kB Private_Clean: 432 kB Private_Dirty: 1724 kB Referenced: 2156 kB That's after 100 days.