Bug 837827 - in Rawhide, setroubleshootd constantly using large amount of CPU
in Rawhide, setroubleshootd constantly using large amount of CPU
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: setroubleshoot (Show other bugs)
rawhide
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Daniel Walsh
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-07-05 09:28 EDT by Andre Robatino
Modified: 2012-07-27 08:46 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-07-27 08:46:30 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Andre Robatino 2012-07-05 09:28:25 EDT
Description of problem:
In my Rawhide x86_64 VirtualBox guest, setroubleshootd is constantly running and using up large amounts of CPU (around 50-60%). If I kill it, it just restarts with a different PID.

Version-Release number of selected component (if applicable):
setroubleshoot-server-3.1.12-3.fc18.x86_64

How reproducible:
always

Additional info:
Noticed that "which setroubleshootd" returns "/sbin/setroubleshootd". In light of usrmove, should this be changed to /usr/sbin/setroubleshootd?
Comment 1 Andre Robatino 2012-07-05 09:29:17 EDT
Should have mentioned that this has been happening for weeks now, at least. Don't remember when it started.
Comment 2 Andre Robatino 2012-07-05 09:39:39 EDT
I mentioned the problem on the test mailing list on June 27 in https://lists.fedoraproject.org/pipermail/test/2012-June/108702.html . I said then that the high CPU usage had existed for a week or two.

Upon rebooting after today's (20120705) Rawhide updates, I see much lower CPU usage by setroubleshootd (around 5%). Could it be fixed?
Comment 3 Miroslav Grepl 2012-07-08 16:10:35 EDT
Are you getting a lot of AVC msgs?
Comment 4 Andre Robatino 2012-07-08 16:13:34 EDT
I'll check when Rawhide is working again. Right now I can only get in via rescue mode, and even then networking doesn't work after chroot, so I can't update.
Comment 5 Miroslav Grepl 2012-07-09 04:41:54 EDT
Ok.
Comment 6 Andre Robatino 2012-07-09 15:53:46 EDT
Now that I've recovered from the bad dracut, yes, in /var/log/audit I'm seeing a lot of AVC messages. In fact, there is a new audit.log file about once per minute. On my F17 box it's still on the first file.

End of latest audit.log file:

 comm="audispd" path="/dev/log" scontext=system_u:system_r:audisp_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=unix_dgram_socket
type=SYSCALL msg=audit(1341863504.459:41622): arch=c000003e syscall=42 success=no exit=-13 a0=4 a1=7f304a5b3880 a2=6e a3=7f304a9fcc98 items=0 ppid=437 pid=496 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="audispd" exe="/usr/sbin/audispd" subj=system_u:system_r:audisp_t:s0 key=(null)
type=AVC msg=audit(1341863504.478:41623): avc:  denied  { sendto } for  pid=496 comm="audispd" path="/dev/log" scontext=system_u:system_r:audisp_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=unix_dgram_socket
type=SYSCALL msg=audit(1341863504.478:41623): arch=c000003e syscall=42 success=no exit=-13 a0=4 a1=7f304a5b3880 a2=6e a3=7f304a9fcc98 items=0 ppid=437 pid=496 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="audispd" exe="/usr/sbin/audispd" subj=system_u:system_r:audisp_t:s0 key=(null)
type=AVC msg=audit(1341863504.503:41624): avc:  denied  { sendto } for  pid=496 comm="audispd" path="/dev/log" scontext=system_u:system_r:audisp_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=unix_dgram_socket
type=SYSCALL msg=audit(1341863504.503:41624): arch=c000003e syscall=42 success=no exit=-13 a0=4 a1=7f304a5b3880 a2=6e a3=7f304a9fcc98 items=0 ppid=437 pid=496 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="audispd" exe="/usr/sbin/audispd" subj=system_u:system_r:audisp_t:s0 key=(null)
Comment 7 Daniel Walsh 2012-07-10 21:21:31 EDT
We are working on this issue with systemd, what is happening right now is systemd-journald is starting as kernel_t in the initrd and then doing a fork/exec and transitioning to systemd-journald, but it is keeping the original socket opened to /dev/log which is owned by kernel_t, and this is causing the avc.  Since the audispd is triggering the AVC, and recieving info about the AVC, you end up in a loop.  I would allow this access for now until we figure out a good way to handle this in Rawhide.
Comment 8 Daniel Walsh 2012-07-27 08:46:30 EDT
This should be fixed in the latest policy.

Note You need to log in before you can comment on or make changes to this bug.