abrt detected crash.
How to reproduce
Clicked on Services (Gnome)
This bug report lacks essential information. Are there any error messages printed? Could this be related to bug #518239?
abrt - Testday
People: Seriously, if you want to vote for bugs, use the "vote" link near the top of the page instead of cluttering up the comments with plus-ones. Besides, the bug is already closed ;-). Thanks.
The +1 is done automatically by abrt.
Then that's a bug in abrt. Plus-ones in comments don't help fixing the bug, they only break the flow if people want to read the ticket.
Opened bug #526721 against abrt.
Created attachment 363547 [details]
system-config-services backtrace as generated by abrt
Heck, I wonder why abrt didn't send the crash report :-( And sorry about the +1, noticed it only after sending the bug report... Attaching backtrace generated by abrt, although it does not seem much usable at initial inspection to me...
Reopening as s-c-s-0.99.41-1 seems to be the latest version but is not working.
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.
More information and reason for this action is here:
Abrt warns me after logging on my computer from hibernation that system-config-services package has crashed.
(In reply to comment #11)
> Created an attachment (id=363547) [details]
> system-config-services backtrace as generated by abrt
> Heck, I wonder why abrt didn't send the crash report :-( And sorry about the
> +1, noticed it only after sending the bug report... Attaching backtrace
> generated by abrt, although it does not seem much usable at initial inspection
> to me...
Can you start /usr/share/system-config-services/system-config-services-mechanism.py as root and then run system-config-services? Does it matter if SELinux is enforcing or not? Please post error messages if there are any.
(In reply to comment #15)
> (In reply to comment #11)
> Can you start
> /usr/share/system-config-services/system-config-services-mechanism.py as root
> and then run system-config-services? Does it matter if SELinux is enforcing or
> not? Please post error messages if there are any.
Hrm, for some reason or another, I cannot reproduce the crash anymore. SELinux is enforcing. system-config-services-0.99.41-1.fc12.noarch. No error messages on terminal. But judging from from the amount of newly CC'ed people, the problem is apparently still here...
It seemed to me that after I rebooted I didn't get the error any more.
I'll try removing and re-installing the package to see if I can re-produce the error later tonight.
Her is the output from my first installation of system-config-services.
I uninstalled system-config-services and installed again from GUI.
When I started system-config-services from terminal as root everything function as it should.
It seems that is had to be started with root privileged first time.
Now I can start system-config-services as a normal user.
Here is the error message:
[tore@TH ~]$ system-config-services
Command not found. Install package 'system-config-services' to provide command 'system-config-services'? [N/y]
* Installing packages..
* Getting information..
* Resolving dependencies..
The following packages have to be installed:
gamin-python-0.1.10-5.fc12.i686 Python bindings for the gamin library
python-slip-gtk-0.2.7-1.fc12.noarch Code to make auto-wrapping gtk labels
Proceed with changes? [N/y]
* Waiting for authentication..
* Resolving dependencies..
* Downloading packages..
* Checking signatures..
* Testing changes..
* Installing packages..
* Scanning applications..
* Getting information.. [tore@TH ~]$ Traceback (most recent call last):
File "/usr/bin/system-config-services", line 1038, in <module>
File "/usr/bin/system-config-services", line 986, in __init__
File "/usr/lib/python2.6/site-packages/scservices/dbus/proxy/serviceherders.py", line 47, in __init__
File "/usr/lib/python2.6/site-packages/dbus/bus.py", line 244, in get_object
File "/usr/lib/python2.6/site-packages/dbus/proxies.py", line 241, in __init__
self._named_service = conn.activate_name_owner(bus_name)
File "/usr/lib/python2.6/site-packages/dbus/bus.py", line 183, in activate_name_owner
File "/usr/lib/python2.6/site-packages/dbus/bus.py", line 281, in start_service_by_name
'su', (bus_name, flags)))
File "/usr/lib/python2.6/site-packages/dbus/connection.py", line 630, in call_blocking
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.Spawn.ChildExited: Launch helper exited with unknown return code 1
(In reply to comment #18)
> Here is the error message:
> [tore@TH ~]$ system-config-services
> Command not found. Install package 'system-config-services' to provide command
> 'system-config-services'? [N/y]
> * Installing packages..
> * Getting information..
> * Resolving dependencies..
> File "/usr/lib/python2.6/site-packages/dbus/connection.py", line 630, in
> message, timeout)
> dbus.exceptions.DBusException: org.freedesktop.DBus.Error.Spawn.ChildExited:
> Launch helper exited with unknown return code 1
Ahh, it seems you use PackageKit-command-not-found, which gives me an idea why you run into SELinux problems for the first time only: If you type in "system-config-services" as a command and it is not found, the shell runs "/usr/libexec/pk-command-not-found system-config-services" which eventually installs the missing package and runs the program you asked for. I guess the helper runs it under a slightly different context than if you really were executing it by yourself.
I'll change the component to PackageKit for further investigation -- please chime up if you can reproduce this without involving PackageKit-command-not-found, i.e. by running it from the command line only when it is installed, or from the menu.
I don't have SELinux enabled, so maybe there are two different problems.
I am running this from the menu, right after installing it. I've noticed that this is fixed by a few things, rebooting, updating other packages, or just trying to open it a number of times, all seem to have "fixed" this, seems to be that something just isn't configured right away, and takes some other event to happen before it gets into a "working" state?
I don't think this is a PackageKit bug, sorry.
All who have seen this bug: please check if you see this error with system-config-services-0.99.43 (or later) and current SELinux policy.
Richard: I really think that at that time PackageKit-command-not-found didn't run programs installed by it in correct SELinux contexts (if SELinux was enabled). At the time I changed the component to PackageKit, I could reliable make this fail SELinux wise if, with PackageKit-command-not-found installed and s-c-services not installed, I ran "system-config-services" from the command line and let command-not-found run it after installation. If s-c-services was installed (i.e. I directly started the program, not by way of command-not-found), I didn't have this problem.
Seems to be "working for me":
How to reproduce
1. I did not notice how this bug occurred.
Anybody still seeing this with current selinux-policy and system-config-users (cf. comment #24)? If yes, I need to know the circumstances under which you see the problem, otherwise I'll have to close this.
Works fine on f13.
Seems ok here as well (I even tried uninstalling and running through pk command not found):
F-12 through Rawhide covered -- closing.
I am using Fedora 14 and ran into the same problem. the smb.conf file is the generic one that comes with the download, no changes made, yet.
I ran "/usr/libexec/pk-command-not-found system-config-services" in an xterm and still get the same error message.
(In reply to comment #30)
> I am using Fedora 14 and ran into the same problem. the smb.conf file is the
> generic one that comes with the download, no changes made, yet.
Not sure what smb.conf has got to do with it...
> I ran "/usr/libexec/pk-command-not-found system-config-services" in an xterm
> and still get the same error message.
I can't reproduce this right now, "/usr/libexec/pk-command-not-found system-config-services" just returns without attempting to install s-c-services, or executing it (Richard?). Besides that I guess you should open a new bug for your Fedora release, perhaps mention this bug in there.
F14 is eol. I don't think you will get a fix.
(In reply to comment #32)
> F14 is eol. I don't think you will get a fix.
Whoops. Don't know why I missed that.