13

I have Centos 7 fresh install and I see setroubleshootd with high CPU usage. How can I fix this? What is this process doing?

Improve this question
3
  • Are there SELinux issues logged in /var/log/audit/audit.log (AVC denials)? Commented Apr 5, 2019 at 15:47
  • well, yes, there is something connected with mongodb there... Commented Apr 5, 2019 at 15:51
  • I had the same issue and in the end it was caused by an error in configuration, specifically MongoDB. I believe SE is notifying you of an actual issue. Commented Jul 7, 2022 at 16:36

5 Answers 5

Reset to default
9

First of all, you should not disable SELinux. So what could cause the high CPU usage of setroubleshootd.

Try to find out in which mode SELinux is running on the machine by typing sestatus. It should show several lines. The interesting parts are SELinux status: and Current Mode which are usually enabled and enforcing. If the current mode is permissive, then SELinux does not block anything but only logs it (good for troubleshooting).

Assuming SELinux is enabled and in in enforcing mode, now take a look at the log /var/log/audit/audit.log. I would recommend to use tail -f /var/log/audit/audit.log to see live changes of the file.

Because you have high CPU load of setroubleshootd I assume you have permanent changes/entries in the file, meaning something permanently violates the SELinux policy and the output could give you a first clue why.

For more in depth troubleshooting you could install setroubleshoot-server with yum install setroubleshoot-server. This package is a set of tools that can help you to find the real cause of the SELinux violation. Most of the time it happens when you added files to the system without setting the correct SELinux permissions or a process tries to access a non typical file or folder.

I would recommend you read this document about SELinux first and this document to get an overview and then look at documents like this for your distribution.

There is a bit of a learning curve with SELinux and too much for a simple answer, but I would never ever disable it on a public facing server.

Improve this answer
2
  • 2
    that setroubleshoot-server actually is setroubleshootd ... Commented Apr 12, 2019 at 0:54
  • 1
    This doesn't really answer the question. There should be a way to limit the impact this process can have on performance. If there is some sort of an attack and settroubleshootd takes up too much CPU, it could cause an outage that would not otherwise happen. Commented Mar 17, 2021 at 14:32
2

setroubleshootd is analysing the audit messages produced by the kernel whenever a process performs an action that is denied by SELinux policy. It logs helpful suggestions for what you, as a system administrator, can do about them.

If you have a lot of audit messages being produced then setroubleshootd will keep waking up and producing messages to and have a lot of work to do.

As a system administrator you'd want to be investigating the root cause of the problem: a high volume of audit messages caused by processes trying to do things that the SELinux policy forbids.

You can use ausearch -m avc,user_avc -i -ts today to see all of the audit records logged since midnight, and you can look your syslog messages to see the output of setroubleshootd. Don't just follow its recommendations blindly however, that is likely to do more harm than good. You have to consider the output of such tools carefully.

If you want to keep it running but limit the amount of CPU/memory it's able to use, run systemctl edit setroubleshootd.service and then make use of the directives documented in systemd.resource-control(5) such as CPUQuota= and MemoryMax=.

You could also choose to disable the mechanism that is passing audit messages to setroubleshootd for analysis. This mechanism is an auditd plugin called sedispatch, and can be disabled in the file /etc/audit/plugins.d/sedispatch.conf on modern systems (on older systems there's a separate process, audispd that dispatches messages to plugins, which can be disalbed in the file /etc/audisp/plugins.d/sedispatch.conf).

You can also remove the setroubleshoot-server package entirely.

Improve this answer
1

a) Install setroubleshoot.x86_64 for a GUI; this might be easier than using tail.

# yum install setroubleshoot.x86_64 setroubleshoot-plugins.noarch

Adding SE Linux policies for mongodb (and possible others) might reduce the load.

Please note that the suggestions it makes can sometimes be useless/misleading.

b) Reinstalling setroubleshootd might be an option:

yum reinstall setroubleshoot-server
Improve this answer
0

Granted this is an old question, but neither of the solutions made a difference. I found this answer: completely uninstalling flatpak actually eliminated the excessive CPU usage.

Improve this answer
3
  • 1
    While this link may answer the question, it is better to include the essential parts of the answer here and provide the link for reference. Link-only answers can become invalid if the linked page changes. - From Review Commented Nov 23, 2022 at 10:59
  • As you'll note in my original answer that "completely uninstalling flatpak, actually eliminated the excessive CPU usage" which was the essential part of the linked answer. Commented Nov 24, 2022 at 15:33
  • Sorry, I misread “I found this answer … which eliminated the excessive CPU usage” as suggesting that there was something else in the answer which eliminated the CPU usage, not just removing Flatpak. Commented Nov 24, 2022 at 17:17
-3

That daemon setroubleshootd is part of SELinux (Security Enhanced Linux). SELinux was implented to provide a context type to files to add more security and comply with NSA requirements. SELinux can cause issues if not properly configured and employed. Setroubleshootd monitors and reports SELinux issues, and provides resolution recommendations.

Determine if you actually need SELinux to run. If not, disable it.

Click here for more info on Disabling SELinux.

Improve this answer
1
  • 1
    SE is notifying of a problem that will not be solved by disabling it, it could actually be worsened. SELinux should never be disabled, specially in production environments or any server open to access. Commented Jan 28, 2022 at 12:55

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.