Bug 1887334

Summary:	setroubleshootd loop eating 100% cpu after startup
Product:	[Fedora] Fedora	Reporter:	Karel Volný <kvolny>
Component:	selinux-policy	Assignee:	Zdenek Pytela <zpytela>
Status:	CLOSED DUPLICATE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	33	CC:	dwalsh, fengalin, fschwarz, grepl.miroslav, lvrabec, mmalik, omosnace, plautrba, ppywlkiqletw, redhat, thofman, tony.cook.666, vmojzis, zpytela
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-11-25 16:11:44 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Karel Volný 2020-10-12 07:21:15 UTC

Description of problem:
After logging in, seapplet keeps reappearing despite there is no new problem and setroubleshotd hogs one cpu. The problem goes away after about 10 minutes.

Version-Release number of selected component (if applicable):
setroubleshoot-server-3.3.23-5.fc33.x86_64

How reproducible:
always

Steps to Reproduce:
1. have something to generate denial during startup (e.g. bug 1880948)
2. log in

Actual results:
seapplet keeps reappearing, your cpu fan gets noisy for ~10 minutes

Expected results:
old problems are not reported again, cpu is idle

Additional info:
I'm using KDE, if that matters for the frontend ...

Comment 1 Milos Malik 2020-10-12 09:32:55 UTC

Is the SetroubleshootP process consuming the majority of CPU when some SELinux denials happen?

Comment 2 Karel Volný 2020-10-15 12:53:59 UTC

(In reply to Milos Malik from comment #1)
> Is the SetroubleshootP process consuming the majority of CPU when some
> SELinux denials happen?

well, yes, SetroubleshootP seems to appear also, although not on the first place

currently, I'm observing the problem - with 3 days uptime, so it doesn't happen only on startup - and top reads:

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
 689620 setroub+  20   0  594548 135880  19824 S  66,1   0,4   1:33.79 setroubleshootd                                                                                                       
 649183 kvolny    20   0 6267292 498896  89468 S  49,8   1,5 106:09.98 QtWebEngineProc                                                                                                       
 689632 root      20   0  452928  77872  14108 S  31,9   0,2   0:35.58 SetroubleshootP
...

Comment 3 Tomas Hofman 2020-11-08 11:45:32 UTC

Also run into this after upgrading to Fedora 33 on Thinkpad T470s.


    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
   3731 setroub+  20   0  597432 138432  18956 S  62.5   0.9   5:38.45 setroubleshootd
   3742 root      20   0  455192  80364  14044 R  35.5   0.5   2:01.26 SetroubleshootP



Running `ausearch -m AVC,USER_AVC -ts recent` returns lots of following messages (like 29298 of them):

----
time->Sun Nov  8 12:33:43 2020
type=AVC msg=audit(1604835223.008:19391): avc:  denied  { read } for  pid=4263 comm="rpm" name="rpmdb.sqlite" dev="dm-1" ino=2622413 scontext=system_u:system_r:setroubleshootd_t:s0 tcontext=system_u:object_r:var_lib_t:s0 tclass=file permissive=0
----

Comment 4 François Laignel 2020-11-16 11:50:29 UTC

This seems to happen once after an update (e.g. using gnome-software).

Comment 5 Tony Cook 2020-11-23 09:46:20 UTC

Sure is writing a lot of AVC reports about something

Event Summary Report
======================
total  type
======================
155541  AVC
895  NETFILTER_CFG
88  SERVICE_STOP
82  SERVICE_START
9  USER_ACCT

[  296.656374] audit: audit_backlog=65 > audit_backlog_limit=64
[  296.656376] audit: audit_lost=836 audit_rate_limit=0 audit_backlog_limit=64
[  296.656377] audit: backlog limit exceeded
[  296.656394] audit: audit_backlog=65 > audit_backlog_limit=64
[  296.656395] audit: audit_lost=837 audit_rate_limit=0 audit_backlog_limit=64
[  296.656396] audit: backlog limit exceeded
[  296.656436] audit: audit_backlog=65 > audit_backlog_limit=64
[  296.656437] audit: audit_lost=838 audit_rate_limit=0 audit_backlog_limit=64
[  296.656438] audit: backlog limit exceeded
[  296.656452] audit: audit_backlog=65 > audit_backlog_limit=64
[  489.400305] audit_log_start: 32 callbacks suppressed
[  489.400306] audit: audit_backlog=65 > audit_backlog_limit=64
[  489.400308] audit: audit_lost=850 audit_rate_limit=0 audit_backlog_limit=64
[  489.400309] audit: backlog limit exceeded
[  531.628966] audit: audit_backlog=65 > audit_backlog_limit=64
[  531.628968] audit: audit_lost=851 audit_rate_limit=0 audit_backlog_limit=64
[  531.628969] audit: backlog limit exceeded
[  531.628983] audit: audit_backlog=65 > audit_backlog_limit=64
[  531.628984] audit: audit_lost=852 audit_rate_limit=0 audit_backlog_limit=64
[  531.628985] audit: backlog limit exceeded
[  531.629018] audit: audit_backlog=65 > audit_backlog_limit=64
[  531.629019] audit: audit_lost=853 audit_rate_limit=0 audit_backlog_limit=64
[  531.629020] audit: backlog limit exceeded
[  531.629032] audit: audit_backlog=65 > audit_backlog_limit=64

Comment 6 Tony Cook 2020-11-23 10:06:57 UTC

All the same as this one, obviously some sort of SELINUX configuration issue with the rpm database after upgrade.

06099566.464:47592): avc:  denied  { read } for  pid=4677 comm="rpm" name="rpmdb.sqlite" dev="sda6" ino=1192312 scontext=system_u:system_r:setroubleshootd_t:s0 tcontext=system_u:object_r:var_lib_t:s0 tclass=file permissive=0

Comment 7 Tomas Hofman 2020-11-25 10:18:12 UTC

To me the condition happens after each reboot.

Comment 8 Zdenek Pytela 2020-11-25 16:11:44 UTC

The problem listed in c#6 has been fixed, please update to the latest selinux-policy package.

*** This bug has been marked as a duplicate of bug 1461313 ***

Comment 9 Villy Kruse 2020-11-25 19:02:28 UTC

Do

   restorecon -R /var/lib/rpm