troubleshootd utilizing high CPU and Memory
 

The setroubleshootd process on my system is utlizing access CPU and Memory.
DO we have any solution to this.

I have no idea what this daemon is for

[root@dgsmon01 ~]# ps -aux |grep trouble
root 2941 28.0 73.8 893724 764160 ? Ssl 21:53 4:20 /usr/bin/python -E /usr/sbin/setroubleshootd

Please help

seems to be a known issue with SELinux.

if you're NOT using SELinux, you can just disable it:

If you ARE using SELinux, update your OS to the latest version and hopefully a patch will fix it.

Yeah like siddhv said its the fancy tool that tells you what the SELinux finding is an potentially how to fix it in paragraph form.

If your using RHEL you have to disable SElinux this way:

in /etc/sysconfig/selinux to SELINUX=disabled and then reboot.

Normally you can go from Enforcing to Permissive without rebooting but you have to reboot to disable completely. I'd try what siddhv said first so maybe SELinux can atleast run/alarm you in permissive mode if your trying to learn the policies/mess with it.

You don't need to disable SELinux to fix this!
 

If you don't use setroubleshoot, just remove it, like this:

yum remove setroubleshoot*

SELinux will continue to work just fine without it, but you'll have to look at the logs and manually figure out what's going on if you have a problem with SELinux configuration.

/etc/sysconfig/selinux
is a link to /etc/selinux/config

I am no security expert, but I would look into the reason why setroubleshootd is using so much cpu and memory instead of just uninstalling it, I have been using a RHEL based distribution for years and never had a problem with it, therefore uninstalling it because it signals some trouble is not good advice in my opinion. I will write down my experience since it might be useful to someone else having this same trouble:

Well, I got here since my apache server got hacked I cleaned a backdoor left in a php file and cleaned a process that was using most of the CPU, called " 9912 apache 20 0 564m 17m 632 S 599.3 0.0 50:11.07 .syslogs " left in "/proc/6823/exe -> /var/tmp/.tmp/.syslogs" yet setroubleshootd was still using 100% of one CPU and using 5 gb of RAM.

I checked /var/log/audit/audit.log to see the reason of such activity and found high activity in the logs, endless attempts of some selinux security violations.

type=AVC msg=audit(1525869288.297:242958328): avc: denied { getattr } for pid=17678 comm="ps" path="/proc/146" dev=proc ino=882018300 scontext=unconfined_u:system_r:httpd_sys_script_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=dir
type=SYSCALL msg=audit(1525869288.297:242958328): arch=c000003e syscall=4 success=no exit=-13 a0=c993f0 a1=325dc11cc0 a2=325dc11cc0 a3=c993f6 items=0 ppid=17672 pid=17678 auid=0 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=94611 comm="ps" exe="/bin/ps" subj=unconfined_u:system_r:httpd_sys_script_t:s0 key=(null)
type=AVC msg=audit(1525869288.297:242958329): avc: denied { getattr } for pid=17678 comm="ps" path="/proc/147" dev=proc ino=882018301 scontext=unconfined_u:system_r:httpd_sys_script_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=dir

I checked the user and it was apache, and checked on the user's activity, since it could be an indicator of some wrong permissions in some files the server tried to access or something worse:

[root@server ~]# ps aux | grep apache
apache 1349 0.5 0.2 720628 177916 ? S May08 6:24 /usr/sbin/httpd
apache 8021 0.3 0.2 703572 159628 ? S 01:10 2:29 /usr/sbin/httpd
apache 8143 0.3 0.2 719396 175520 ? S 01:10 2:39 /usr/sbin/httpd
apache 8235 0.3 0.2 735252 190596 ? S 01:10 2:55 /usr/sbin/httpd
apache 8236 0.4 0.2 705324 161100 ? S 01:10 3:20 /usr/sbin/httpd
apache 8237 0.5 0.2 705404 162100 ? S 01:10 4:03 /usr/sbin/httpd
apache 8238 0.4 0.2 720020 176764 ? S 01:10 4:01 /usr/sbin/httpd
apache 11358 0.4 0.3 776164 232220 ? S May08 4:27 /usr/sbin/httpd
apache 11434 0.3 0.2 719948 175932 ? S May08 3:16 /usr/sbin/httpd
apache 11435 0.2 0.2 693372 150228 ? S May08 2:45 /usr/sbin/httpd
apache 11542 0.4 0.2 712460 168592 ? S May08 3:56 /usr/sbin/httpd
apache 16160 0.5 0.2 719604 176800 ? S May08 6:40 /usr/sbin/httpd
apache 16487 0.0 0.0 100924 572 ? S 14:41 0:00 sleep 1
apache 16492 0.0 0.0 108224 1368 ? S 14:41 0:00 sh
apache 16534 0.0 0.0 100924 576 ? S 14:41 0:00 sleep 1
root 16536 0.0 0.0 103332 876 pts/0 S+ 14:41 0:00 grep apache
apache 17868 0.3 0.2 704808 160868 ? S 01:06 2:35 /usr/sbin/httpd
apache 17917 0.3 0.3 777944 226112 ? S 01:06 2:59 /usr/sbin/httpd
apache 17918 0.4 0.2 703356 159468 ? S 01:06 3:51 /usr/sbin/httpd
apache 18014 0.3 0.3 741168 197320 ? S 01:06 2:58 /usr/sbin/httpd
apache 18077 0.3 0.2 712684 169232 ? S 01:06 2:45 /usr/sbin/httpd
apache 19801 0.4 0.2 720372 177760 ? S May08 6:07 /usr/sbin/httpd
apache 19805 0.5 0.2 720464 177680 ? S May08 7:00 /usr/sbin/httpd
apache 25112 0.0 0.0 4120 3296 ? Ss May06 1:57 /usr/libexec/kextd
apache 25119 0.0 0.0 4120 112 ? S May06 0:18 /usr/sbin/notifyd
apache 25432 0.4 0.2 720964 178272 ? S May08 5:20 /usr/sbin/httpd

I turned down httpd and the processes listed below remained:

apache 16487 0.0 0.0 100924 572 ? S 14:41 0:00 sleep 1
apache 16492 0.0 0.0 108224 1368 ? S 14:41 0:00 sh
apache 16534 0.0 0.0 100924 576 ? S 14:41 0:00 sleep 1
apache 25112 0.0 0.0 4120 3296 ? Ss May06 1:57 /usr/libexec/kextd
apache 25119 0.0 0.0 4120 112 ? S May06 0:18 /usr/sbin/notifyd

apache running kextd which I found is a kernel extension server and sh looked very suspicious to me and I killed the processes with "pkill -u apache" and everything went back to normal. I did update PHP and got some other security measures in hope that this issue doesn't repeat. Yet, I wold definitely look into why setroubleshootd is using so much CPU since setroubleshoot is used to diagnose SELinux denials and it might be signalling you some real trouble.