Description of problem: setroubleshootd uses too much RAM, which causes slowness and excessive thrashing when running other processes. Version-Release number of selected component (if applicable): Fedora-Live-XFCE-i686-19-Alpha-RC4 setroubleshoot-server-3.2.4-1.fc19.i686 How reproducible: always Steps to Reproduce: 1. boot XFCE i686 Live spin on machine with 1GB RAMf (or append " mem=1024m " to the kernel boot command line) and log in. 2. ps axl | sed 1q; ps axl | grep setroubleshootd 3. grep heap /proc/<<PID>>/maps 4. sed -n '/heap/,+12p' </proc/<<PID>>/smaps Actual results: F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND 4 0 836 1 20 0 93576 69340 poll_s Sl ? 0:11 /usr/bin/python -Es /usr/sbin/setroubleshootd -f 09bd5000-0d16e000 rw-p 00000000 00:00 0 [heap] 09bd5000-0d16e000 rw-p 00000000 00:00 0 [heap] Size: 54884 kB Rss: 54868 kB Pss: 54868 kB Shared_Clean: 0 kB Shared_Dirty: 0 kB Private_Clean: 0 kB Private_Dirty: 54868 kB Referenced: 0 kB Anonymous: 54868 kB AnonHugePages: 0 kB Swap: 0 kB KernelPageSize: 4 kB which shows 69MB of resident pages (RSS), and 56MB (0x3599000 = (09bd5000-0d16e000)) of address space for the heap, and 54.8MB of dirty pages for the heap. So that really is 55MB of physical RAM in a Live system. Expected results: 10MB or less physical RAM when not doing anything. Additional info:
We are just shipping it as it is... moving to setroubleshoot for comment. Note that some of this might be due to the debugging kernel. If you boot with 'slub_debug=-' and disable that part of debugging does it reduce memory needs?
No, 'slub_debug=-' does not change the memory needs; it just liberates some cycles. setroubleshootd has 10 seconds of CPU time and 55MB of RAM, and nothing is happening. Perhaps setroubleshootd should dismiss itself if all is quiet for several minutes?
It is supposed to die after 10 seconds. Fixed in setroubleshoot-3.2.6-1.fc19 Also realize that python is not using as much memory as you think. http://illiterat.livejournal.com/4615.html
Thank you for the change which makes the process disappear soon. As for how much RAM is actually used, that linked page does not explain this case. The /proc/PID/smaps (step 4 of "Steps to reproduce") shows 54.8MB of Private_Dirty and Anonymous pages, not Shared with any other process, and not in Swap. That 54.8MB is actual physical RAM that no other process can use. (It might possibly be shared in the future if setroubleshootd created a child process, but there aren't any children at the moment.) Thus having the process exit() will return 54.8MB to the pool of Free pages; and that is 5% of 1GB RAM.
setroubleshoot-3.2.6-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/setroubleshoot-3.2.6-1.fc19
Sadly same bug in F18.
Package setroubleshoot-3.2.7-1.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing setroubleshoot-3.2.7-1.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-6063/setroubleshoot-3.2.7-1.fc19 then log in and leave karma (feedback).
Package setroubleshoot-3.2.8-1.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing setroubleshoot-3.2.8-1.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-6063/setroubleshoot-3.2.8-1.fc19 then log in and leave karma (feedback).
setroubleshoot-3.2.8-1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.