|Summary:||no sealert applet on AVC deny|
|Product:||[Fedora] Fedora||Reporter:||Thorsten Scherf <tscherf>|
|Component:||setroubleshoot||Assignee:||John Dennis <jdennis>|
|Status:||CLOSED RAWHIDE||QA Contact:||Ben Levenson <benl>|
|Version:||6||CC:||alcapcom, gauret, mishu|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2006-11-28 06:15:37 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
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): setroubleshoot-1.0-1 How reproducible: create an AVC deny Steps to Reproduce: 1.see above 2. 3. 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: /var/log/messages: 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 = 671f8958-3e13-4d74-ad63-752534e0d955 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 | grep DBUS_SESSION). 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 ? start_service() File "/usr/bin/sealert", line 376, in start_service app.main() File "/usr/bin/sealert", line 350, in main self.browser = BrowserApplet() File "/usr/lib/python2.4/site-packages/setroubleshoot/browser.py", line 79, in __init__ self.init_widgets() 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 happened...
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 not. 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 reboot)