Red Hat Bugzilla – Bug 268221
setroubleshoot opens but displays a blank window
Last modified: 2007-11-30 17:12:14 EST
Description of problem:
This machine is a modern P4 with 2.8 GHz P4 and 1 GB ram. Was running FC6 and
was upgraded some time ago to F7. Since it was an upgrade, setroubleshoot was
not installed. Installed it from the Fedora repo and re-booted. Services says
it's running. Upon opening it, I just get a blank screen. Tried changing the
view to audit messages; tried loading two different log files (messages and
messages.1)- the message at the bottom says it's opening log file, but nothing
Version-Release number of selected component (if applicable):
happens every time I open it
Steps to Reproduce:
1. Start setroubleshoot
Setroubleshoot opens, all menus seem to function, but the windows are blank
expect to see a list of selinux security messages in one window, and proposed
resolutions in the other
By any chance is your language set to something other than english? There is a
known bug with i18n string handling in the initial F7 version of setroubleshoot.
Also, please take a look in /var/log/setroubleshoot/setroubleshootd.log and see
if there are error or traceback messages, if so please attach them.
(In reply to comment #1)
> By any chance is your language set to something other than english? There is a
> known bug with i18n string handling in the initial F7 version of setroubleshoot.
> Also, please take a look in /var/log/setroubleshoot/setroubleshootd.log and see
> if there are error or traceback messages, if so please attach them.
My language is set to English.
The log is pretty empty so here it is:
2007-08-30 13:14:50,777 [email.WARNING] cannot open file
/var/lib/setroubleshoot/email_alert_recipients, No such file or directory
I haven't configured any email recipients, so this is probably harmless.
O.K. those are all fine.
You must also have the service setroubleshoot running, is it?
% service setroubleshoot status
if its not running then start it with
% service setroubleshoot start
You also may want to chkconfig the service to be on so it restarts at boot time.
Once the service is running you still won't see anything until an AVC occurs.
(In reply to comment #3)
> You must also have the service setroubleshoot running, is it?
> As root:
> % service setroubleshoot status
> if its not running then start it with
> % service setroubleshoot start
> You also may want to chkconfig the service to be on so it restarts at boot time.
That was one of the first things I checked. The Fedora rpm obviously sets it to
run as default because it was set that way in services.
> Once the service is running you still won't see anything until an AVC occurs.
I didn't realize there'd be nothing to see in the window till AVC alerts were
generated - maybe that's all there is to it.
I suspect you're last comment is correct. You won't see anything until there is
something to see :-) The tool does not go backwards in time by searching for
AVC's in old log files, it works by listening to the audit system waiting for an
AVC to occur. Once it does you should get a notification on the desktop.
However, if you do have a log file with AVC's in it you should be able to open
the log file in the browser, but unless the log file has AVC's the browser will
still be blank.
(In reply to comment #5)
> However, if you do have a log file with AVC's in it you should be able to open
> the log file in the browser, but unless the log file has AVC's the browser will
> still be blank.
Checked my various logs and found this in my messages logfile by filtering on
"AVC" in my logviewer:
Aug 27 13:06:07 localhost dbus: Can't send to audit system: USER_AVC avc:
received policyload notice (seqno=2) : exe="/bin/dbus-daemon" (sauid=500,
hostname=?, addr=?, terminal=?)
Is this SELinux?
No, it's not SELinux, at least not directly. What is happening is that DBus is
trying to inject a message into the audit system but is failing because DBus
does not have permission to write audit messages. This has been a long standing
bug that to the best of my knowledge is innocuous. I do not know what DBus is
trying to report, but John Palmieri (firstname.lastname@example.org) probably could tell you.
If you no longer believe setroubleshoot is failing would you please close this