Bug 416621
| Summary: | setroubleshootd crashes when trying to view problems. | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | simon |
| Component: | setroubleshoot | Assignee: | John Dennis <jdennis> |
| Status: | CLOSED WORKSFORME | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | 8 | ||
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2008-01-14 13:56:31 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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. 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. Thank you for taking the time to report this and reply. Since it no longer seems reproducible I'm going to close it. |
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: