Bug 214218

Summary: no sealert applet on AVC deny
Product: [Fedora] Fedora Reporter: Thorsten Scherf <tscherf>
Component: setroubleshootAssignee: John Dennis <jdennis>
Status: CLOSED RAWHIDE QA Contact: Ben Levenson <benl>
Severity: medium Docs Contact:
Priority: medium    
Version: 6CC: alcapcom, gauret, mishu
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-11-28 06:15:37 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Thorsten Scherf 2006-11-06 17:34:36 UTC
Description of problem:
sealert doesn't start up. 

Version-Release number of selected component (if applicable):

How reproducible:
create an AVC deny 

Steps to Reproduce:
1.see above
Actual results:
there is only a log entry, but not sealert message pops up on the desktop

Expected results:
popup on the desktop

Additional info:
Nov  6 18:13:40 tiffy setroubleshoot:      SELinux is preventing the
/usr/sbin/httpd from using potentially mislabeled files (/var/www/html/test).  
   See audit.log for complete SELinux messages. id =
Nov  6 18:14:38 tiffy setroubleshoot: 2006-11-06 18:14:38,013 [alert.ERROR]
could not start dbus: Unable to determine the address of the message bus (try
'man dbus-launch' and 'man dbus-daemon' for help)
Nov  6 18:14:43 tiffy setroubleshoot: 2006-11-06 18:14:43,698 [alert.ERROR]
could not start dbus: Unable to determine the address of the message bus (try
'man dbus-launch' and 'man dbus-daemon' for help)
Nov  6 18:14:56 tiffy setroubleshoot: 2006-11-06 18:14:56,146 [alert.ERROR]
could not start dbus: Unable to determine the address of the message bus (try
'man dbus-launch' and 'man dbus-daemon' for help)

installes with latest fc6 rpms.

Comment 1 John Dennis 2006-11-06 18:10:52 UTC
This is usually a symptom of the session bus either not running, or not bound to
your session. It's not a setroubleshoot issue.

For starters, is DBUS_SESSION_BUS_ADDRESS defined in your environment? (e.g. set

When happens when you run dbus-monitor? Do you get the same you list above?

Did you ssh in thus bypassing the dbus-launch gdm performs for you?

Provided you have a DBUS_SESSION_BUS_ADDRESS defined then what does 'ps ax |
grep dbus' show? Do you have a daemon listed after the dbus-launch? Is it
running? What happens if you close your session and log back in? Does the
problem go away?

Anyway, this isn't a setroubleshoot issue per se, it's more to do with dbus or
how you're trying to run things.

Comment 2 Thorsten Scherf 2006-11-06 22:37:15 UTC
as discussed on irc, when calling sealert it just dies:

[tscherf@tiffy ~]$ sealert -s

(Setroubleshoot-Browser:5423): libglade-CRITICAL **: glade_xml_build_interface:
assertion `wid != NULL' failed
Traceback (most recent call last):
  File "/usr/bin/sealert", line 426, in ?
  File "/usr/bin/sealert", line 376, in start_service
  File "/usr/bin/sealert", line 350, in main
    self.browser = BrowserApplet()
  File "/usr/lib/python2.4/site-packages/setroubleshoot/browser.py", line 79, in
  File "/usr/lib/python2.4/site-packages/setroubleshoot/browser.py", line 104,
in init_widgets
    self.window.connect_after("realize", self.on_realize)
AttributeError: 'NoneType' object has no attribute 'connect_after'

rpm -V setroubleshoot|grep glade shows no problem with the glade files.

Comment 3 Thorsten Scherf 2006-11-06 22:44:24 UTC
problem remains with setroubleshoot rawhide version 1.3-1

Comment 4 John Dennis 2006-11-07 18:29:16 UTC
Thorsten, I would like to do one more diagnostic test for me please. This
morning I discovered many of the system-config-* applets will not run, they seem
to fail because they can't open the X display. The tracebase in comment #2 is
saying there is no window, the inability to open the display is a very likely
candidate for why there is no window. 

For the failing console helper apps if I monitor /var/log/Xorg.0.log (tail -f)
I'll see message like this:

AUDIT: Tue Nov  7 13:11:18 2006: 2241 Xorg: client 31 rejected from local host

and what the client sees is a failure to open the X windows display and the
inability to open any windows.

Could you please see if you're getting these messages in your
/var/log/Xorg.0.log file? Try running system-config-soundcard, that's one which
I know fails for me. Try it with sealert -s on the command line and invoked from
the System->Administration->setroubleshoot menu item. Are the client rejection
messages generated in the X log when you do these things?

Comment 5 Thorsten Scherf 2006-11-08 09:51:09 UTC
there is no log entry as you described. sorry. I really guess it has something
to do with dbus. we could try to isolate the problem later on, will be available
around 2pm EST, if you would like access one of the machines where this bug

Comment 6 Alphonse Van Assche 2006-11-09 23:35:21 UTC
Apparently, i have the same bug, some strings which should not be i18l, should
be, i have found one in browser.py.

-        self.window_name = _('browser')
+        self.window_name = "browser"

There are other files to patch, because the notification is show but the icon is
When I start gnome in English all work perfectly.

ps: the same log output as Thorsten about dbus.

Comment 7 John Dennis 2006-11-10 03:21:20 UTC
Good catch Alphonse! That would certainly explain things, thank you for your
help in diagnosing the problem. I never occurred to me to consider i18n as a
root cause.

However, I think this line:

self.window_name = _('browser')

is correct, that the name displayed to the user and it should be i18n, but the
mistake was then using this name to look up the widget in the glade file, here:

        self.window = self.wTree.get_widget(self.window_name)

that name should be hard coded to match the name in the glade file.

Thorsten, does running in english or modifying either of the two lines
referenced in /usr/lib/python2.4/site-packages/browser.py to be 'browser' fix
the problem for you? The i18n component probably explains why the problem you
were reporting wasn't surfacing more often and why we were not seeing it.

Comment 8 John Dennis 2006-11-10 03:24:09 UTC
Oh, by the way, along with fixing the i18n issue, we'll also fix the error
checking/reporting, the dbus failure was a red herring caused by a chain of
earlier events.

Comment 9 Thorsten Scherf 2006-11-10 07:53:20 UTC
Very good catch.

When changing  self.window_name = _("browser") to  self.window_name =
("browser") it works without problems.

Comment 10 Alphonse Van Assche 2006-11-11 12:01:46 UTC
cf: There are other files to patch, because the notification is show but the
icon is not.

Oups, self.window_name = "browser" fix entirely the problem for me too (after a

Comment 11 John Dennis 2006-11-11 13:29:37 UTC
*** Bug 215135 has been marked as a duplicate of this bug. ***