Bug 416621 - setroubleshootd crashes when trying to view problems.
setroubleshootd crashes when trying to view problems.
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: setroubleshoot (Show other bugs)
8
All Linux
low Severity low
: ---
: ---
Assigned To: John Dennis
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-12-08 12:24 EST by Simon Goodall
Modified: 2008-01-14 08:56 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-01-14 08:56:31 EST
Type: ---
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 Simon Goodall 2007-12-08 12:24:32 EST
Description of problem:
setroubleshootd has started to crash when I try to view the latest denial
message that pops up on my desktop. See below for the output; 

> EXTRAOPTIONS=-f /etc/init.d/setroubleshoot start
Starting setroubleshootd: Traceback (most recent call last):
  File "/usr/lib/python2.5/site-packages/setroubleshoot/rpc.py", line 891, in
handle_client_io
    self.receiver.feed(data)
  File "/usr/lib/python2.5/site-packages/setroubleshoot/rpc.py", line 724, in feed
    self.process()
  File "/usr/lib/python2.5/site-packages/setroubleshoot/rpc.py", line 696, in
process
    match = header_end_re.search(self.feed_buf)
KeyboardInterrupt
                                                           [FAILED]

Trying to run "setroubleshoot -f" directly does nothing useful. Denial messages
keep popping up, but no usual problem window, nor is there any error.


Version-Release number of selected component (if applicable):
setroubleshoot-1.10.7-1.fc8


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 John Dennis 2008-01-09 17:41:10 EST
Are you sure it's setroubleshootd that's crashing? Setroubleshoot is composed of
two processes, the system daemon (setroubleshootd) and a GUI desktop component
called sealert. It's sealert that interacts with your desktop.

If setroubleshootd is crashing there should be errors in it's log file:
/var/log/setroubleshoot/setroubleshootd.log. Are there?

Are you running under KDE by any chance?

Try running sealert in the foreground so we can see what is going on. First kill
any running sealert processes, then run sealert -s -V You should get a lot of
debug output in the terminal window. Can you open the browser via the menu
"Applications-->System Tools-->SELinux Troubleshooter?

Does the browser open? Do you get errors or tracebacks messages? If you get too
much output reduce the verbosity with -v instead of -V.
Comment 2 Simon Goodall 2008-01-13 06:16:42 EST
It was certainly the daemon process. The browser would still be open, but unable
to connect to the daemon. Checking the status of the daemon service showed it
was no longer running. The stacktrace above was for the daemon program. Note
that the "keyboard exception" appeared to have been triggered by starting the
browser.

I am running gnome.

I am no longer seeing this crash. Either an update has fixed this. Another
possibility is that the number of different alerts I am getting is now much
lower (3 rather than several pages). Maybe there was a bad alert, or the number
of different alerts was the problem. 

Comment 3 John Dennis 2008-01-14 08:56:31 EST
Thank you for taking the time to report this and reply. Since it no longer seems
reproducible I'm going to close it.

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