Bug 1641109 - SE Linux Troubleshooter will not start from an icon click or from the command line
Summary: SE Linux Troubleshooter will not start from an icon click or from the command...
Keywords:
Status: CLOSED DUPLICATE of bug 1641456
Alias: None
Product: Fedora
Classification: Fedora
Component: setroubleshoot
Version: 29
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-10-19 16:27 UTC by Pat Kelly
Modified: 2018-11-19 14:06 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-11-19 14:06:20 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
setroubleshoot.conf (5.51 KB, text/plain)
2018-11-13 13:39 UTC, Pat Kelly
no flags Details
journalctl -t setroubleshoot.txt (168 bytes, text/plain)
2018-11-13 13:40 UTC, Pat Kelly
no flags Details
SEAlertJournal (6.68 KB, text/plain)
2018-11-13 15:49 UTC, Pat Kelly
no flags Details
SEAlert (314 bytes, text/plain)
2018-11-13 15:57 UTC, Pat Kelly
no flags Details

Description Pat Kelly 2018-10-19 16:27:44 UTC
Description of problem:
SELinux Trouble shooter will not start and show its window.

Version-Release number of selected component (if applicable):
3.3.18-1.fc29


How reproducible:
Click the SELinux troubleshooter icon, or use "sealert -b" at the commend line.

Steps to Reproduce:
1. Install setroubleshoot
2. Attempt to run setroubleshoot from either the icon or from the command line.
3.

Actual results:
SELinux Troubleshooter never shows its window though the menu header does appear in the top bar briefly when the attempted start is from the icon click. When the attempt is made from the command line I get the following:

$ sealert -b
/usr/bin/sealert:32: DeprecationWarning: Importing dbus.glib to use the GLib main loop with dbus-python is deprecated.
Instead, use this sequence:

    from dbus.mainloop.glib import DBusGMainLoop

    DBusGMainLoop(set_as_default=True)

  import dbus.glib

There were no further messages and the trouble shooter did not start. The trouble shooter menu header did not appear in the top bar. (echo $?) produced 0

Expected results:
SELinux Troubleshooter should start and show its window.

Additional info:
This happened with F29 Workstation Live 10/17 drop. This was a clean install on bare metal (Lenovo M58p with E8400 processor) from a DVD. The ISO check-sum was good and the media test ran and passed. The installation ran without errors and the system restarted after the install without errors or problems of any kind.

SELinux Troubleshooter was the only additional software installed after the install from the DVD and it was installed with (sudo dnf install setroubleshoot) at the command line. The install ran without error.

I tried doing a reintall from the command line (sudo dnf reinstall setroubleshoot) and the bug persisted.

This bug was also present in the 10/13 drop, but I did not test this in drops prior to 10/13; so I don't know how far back it goes.

Comment 1 Pat Kelly 2018-10-24 15:04:07 UTC
Version-Release number of selected component (if applicable):
3.3.18-1.fc29

This bug persists in drop 10/22.

Comment 2 Pat Kelly 2018-10-26 14:01:24 UTC
Version-Release number of selected component (if applicable):
3.3.18-1.fc29

This bug persists in drop 10/25 (RC 1.2).

Comment 3 Pat Kelly 2018-11-12 12:58:35 UTC
Version-Release number of selected component (if applicable):
3.3.18-1.fc29

This bug persists in the fully updated released version of F29.

Comment 4 Vit Mojzis 2018-11-13 08:44:34 UTC
Thank you for reporting the issue.
I tried to reproduce it on the released version of F29 and sealert started as expected (albeit with a delay of several seconds).

Could you please try to reproduce the issue after switching "sealert_log" and "setroubleshootd_log" levels in /etc/setroubleshoot/setroubleshoot.conf to "DEBUG"? The output of "journalctl -t setroubleshoot" could give us some clues.

Also, does the issue persist after reboot?

Comment 5 Pat Kelly 2018-11-13 13:39:01 UTC
Created attachment 1505269 [details]
setroubleshoot.conf

Comment 6 Pat Kelly 2018-11-13 13:40:36 UTC
Created attachment 1505270 [details]
journalctl -t setroubleshoot.txt

Comment 7 Pat Kelly 2018-11-13 13:42:51 UTC
I set the /etc/setroubleshoot/setroubleshoot.conf as you asked. I have attached a copy of the file.

I did a restart and then tried to start SELinux troubleshooter. The result was SELinux Troubleshooter never shows its window though the menu header does appear in the top bar briefly. This is the same result I got when I wrote the bug report.

I have attached a copy of the journalctl results.

Yes, The bug happens even after a reboot. The bug occurs on all attempts to start the troubleshooter.

Comment 8 Vit Mojzis 2018-11-13 14:18:29 UTC
Please try running "sealert -b" while you have "sudo journalctl -f" running in a separate terminal. Does any new message appear?

Comment 9 Pat Kelly 2018-11-13 15:49:08 UTC
Created attachment 1505343 [details]
SEAlertJournal

Comment 10 Pat Kelly 2018-11-13 15:57:11 UTC
Created attachment 1505350 [details]
SEAlert

Comment 11 Pat Kelly 2018-11-13 15:58:01 UTC
I have attached two files. One is the journal that ran on one terminal. The other is trying to run the SEAlert in another terminal while the journal was running in the first terminal.

Comment 12 Vit Mojzis 2018-11-14 09:53:59 UTC
This is a dbus issue. Please see 
https://bugzilla.redhat.com/show_bug.cgi?id=1641456

It should be fixed by reinstalling dbus packages.

Comment 13 Pat Kelly 2018-11-14 13:16:01 UTC
I reinstalled the dbus-common and dbus-daemon and did a restart. After that the SELinux Alert Browser started as it should. Since this bug is present in the released F29 I think I will just add these reinstalls to the script I use to set up PCs.

Comment 14 Petr Lautrbach 2018-11-19 14:06:20 UTC

*** This bug has been marked as a duplicate of bug 1641456 ***


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