Hi,

setroubleshootd appears to be using 50% of the memory available on my server - I have pretty much nailed all of the setroubleshoot messages, so I am only getting one or two a day, but it still appears to be using loads of memory.

any one any ideas as to how to reduce this? (without turning selinux off please!)

Thanks,

Paul

Did you change anything in the setroubleshoot.cfg?
Does setroubleshootd.log show anything?
And if you change the warning level to info or even debug in setroubleshoot.cfg?
Or else by attaching 'strace' to the PID?
Anything else related in syslog or audit.log that may help?

No

Empty file

Warning level is set to info

Lots of this:
poll([{fd=6, events=POLLIN}, {fd=3, events=POLLIN}], 2, 100) = 0
futex(0xa013d28, FUTEX_WAKE, 1) = 0
futex(0xa013d28, FUTEX_WAKE, 1) = 0
futex(0xa013d28, FUTEX_WAKE, 1) = 0
futex(0xa013d28, FUTEX_WAKE, 1) = 0
futex(0xa013d28, FUTEX_WAKE, 1) = 0
futex(0xa013d28, FUTEX_WAKE, 1) = 0
futex(0xa149a20, FUTEX_WAKE, 1) = 0

But then I don't know what I'm looking for!

Not that I can see.

I ran ps aux | grep setroubleshootd and got this:

MEM: 48.8% COMMAND: /usr/bin/python -E /usr/sbin/setroubleshootd

Not sure if this means it is a related python issue?

Thanks for your help

Paul

Could be. IIGC Python allocates all the meory it needs for a process, I'm seeing a virtual size of fifty megs and resident is aprox fifteen megs but fifty percent of total memory is ridiculous. Looking aroud I see some metnioning of the same situation but same as here w/o OS/package version specs nor fixes. I'd suggest you check CentOS' bug tracking for similar issues and open a ticket if there's none.

Just to answer this problem:

It turns out that versions of setroubleshootd prior to 2.x branch could lead to this problem. Redhat has released an upgrade of EL5.1 to EL5.2, which upgrades setroubleshootd to 2.x branch. This has now been reflected by CentOS with 5.2 now available.

The selinux mailing list is useful for figuring out/answering these problems:

http://www.redhat.com/mailman/listin...a-selinux-list

Cheers,

Paul

Had the same issue here.

I dont know if it is related, but my "hald-addon-stor" was taking a lot of cpu time due to a CD being mounted for a couple of week.

I unmounted the CD, stopped the setroubleshootd process, waited a couple of minute and VOILA, 200 MB of ram freed and load average back to normal.

By the way, if anyone wonders how to restart the process :

Is there a better fix for this yet, sorry for the old thread I didn't want to open another for the same problem. Seems like needing to restart it is just a temp fix.