Bug 461688

Me too:

Traceback (most recent call last):
  File "/usr/sbin/system-config-services", line 900, in <module>
    GUI (use_dbus = use_dbus).run ()
  File "/usr/sbin/system-config-services", line 876, in __init__
    self.serviceherders.append (cls (bus = self._bus))
  File "/usr/lib/python2.5/site-packages/scservices/dbus/proxy/serviceherders.py", line 53, in __init__
    for service_name in self.list_services ():
  File "/usr/lib/python2.5/site-packages/slip/dbus/polkit.py", line 54, in enable_proxy_wrapper
    authobj = sessionbus.get_object ("org.freedesktop.PolicyKit.AuthenticationAgent", "/")
  File "/usr/lib/python2.5/site-packages/dbus/bus.py", line 244, in get_object
    follow_name_owner_changes=follow_name_owner_changes)
  File "/usr/lib/python2.5/site-packages/dbus/proxies.py", line 241, in __init__
    self._named_service = conn.activate_name_owner(bus_name)
  File "/usr/lib/python2.5/site-packages/dbus/bus.py", line 183, in activate_name_owner
    self.start_service_by_name(bus_name)
  File "/usr/lib/python2.5/site-packages/dbus/bus.py", line 281, in start_service_by_name
    'su', (bus_name, flags)))
  File "/usr/lib/python2.5/site-packages/dbus/connection.py", line 622, in call_blocking
    message, timeout)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.Spawn.ChildExited: Launch helper exited with unknown return code 1

Which version of PolicyKit have you installed?

PolicyKit-0.9-2.fc10.x86_64

I have the same one.

My system-config-services started working on the 16 Sept 2008 with a yum update system-config-services-0.99.23-1.fc10.noarch and kernel 2.6.27-0.329.rc6.git2.fc10

Not fixed by PolicyKit-0.9-3.fc10.x86_64 with system-config-services-0.99.23-1.fc10.noarch

Here are my rpms:

PolicyKit-gnome-libs-0.9-3.fc10.i386
PolicyKit-gnome-0.9-3.fc10.i386
PolicyKit-0.9-2.fc10.i386

system-config-services-0.99.23-1.fc10.noarch

dbus-1.2.3-1.fc10.i386
dbus-python-0.83.0-2.fc10.i386
dbus-glib-0.76-2.fc10.i386
dbus-glib-devel-0.76-2.fc10.i386
dbus-x11-1.2.3-1.fc10.i386
dbus-libs-1.2.3-1.fc10.i386
python-slip-dbus-0.1.13-1.fc10.noarch
dbus-devel-1.2.3-1.fc10.i386

When run as a superuser, now I get in the terminal window:

Traceback (most recent call last):
  File "/usr/sbin/system-config-services", line 900, in <module>
    GUI (use_dbus = use_dbus).run ()
  File "/usr/sbin/system-config-services", line 876, in __init__
    self.serviceherders.append (cls (bus = self._bus))
  File "/usr/lib/python2.5/site-packages/scservices/dbus/proxy/serviceherders.py", line 53, in __init__
    for service_name in self.list_services ():
  File "/usr/lib/python2.5/site-packages/slip/dbus/polkit.py", line 48, in enable_proxy_wrapper
    return func (*p, **k)
  File "/usr/lib/python2.5/site-packages/scservices/dbus/proxy/serviceherders.py", line 66, in list_services
    return self.dbus_object.list_services (dbus_interface = "org.fedoraproject.Config.Services.ServiceHerder")
  File "/usr/lib/python2.5/site-packages/dbus/proxies.py", line 68, in __call__
    return self._proxy_method(*args, **keywords)
  File "/usr/lib/python2.5/site-packages/dbus/proxies.py", line 140, in __call__
    **keywords)
  File "/usr/lib/python2.5/site-packages/dbus/connection.py", line 622, in call_blocking
    message, timeout)
dbus.exceptions.DBusException: org.fedoraproject.slip.dbus.service.PolKit.NotAuthorizedException.org.fedoraproject.config.services.info: 


When run system-config-services as a normal user, I get the service configuration dialog come up fully enabled and the following message in the terminal window:

enable DBusXinetdServiceHerderProxy

not sure this helps

Do you log in as the root user when attempting this or do you use su/sudo to change to the root user? In the latter case the root user doesn't have a ConsoleKit session and therefore can't acquire the proper PolicyKit authorizations.

Yup, I used su - and then tried system-config-services. It seems to be running now under normal user, it even doesn't ask for administrator's privileges.

I never use gdm to run a desktop as the root user.  Thats a no-no.  I hope system-config-services isn't expecting that?

(In reply to comment #10)
> I never use gdm to run a desktop as the root user.  Thats a no-no.  I hope
> system-config-services isn't expecting that?

No, system-config-users expects you to just run it as your (logged in) normal user which uses a PolicyKit-enabled DBus backend for the privileged stuff. If you use sudo/su to switch another user, that user doesn't have an active session and therefore can't get the necessary authorizations needed for managing system services. If you really insist on using it as the root user(*), at the moment you need to run it with the "--no-dbus" option. I've plans to make the tool default to not using DBus if the necessary prerequisites aren't met, but this code isn't there yet.

(*): Doing so is IMO less secure than a separate unprivileged GUI frontend and privileged backend, where online help uses the normal user's web browser instead of starting one as root.

(In reply to comment #9)
> Yup, I used su - and then tried system-config-services. It seems to be running
> now under normal user, it even doesn't ask for administrator's privileges.

Per default, it asks you once (per action: "get information" and "manage") and stores that authorization.

It opens a window, without any authentication, which says "No services found"

Then after about a minute it finds some services !

Perhaps impatience is why we both try sudo ?

Why is it taking so long????

It does ask for authentication if I try to enable/disable a service.

(In reply to comment #13)
> It opens a window, without any authentication, which says "No services found"

I agree that "No service selected" is a bit poorly chosen, it should rather say "Discovering services" or similar with a throbber/spinner thing to indicate that it's busy.

> Then after about a minute it finds some services !
>
> Perhaps impatience is why we both try sudo ?
> 
> Why is it taking so long????

I just timed that and it took 7 seconds from starting the program to the list being sensitive, i.e. all services discovered. I have an average machine, what type of machine do you have?

> It does ask for authentication if I try to enable/disable a service.

Right, no authentication is required for just getting information (if you're in an active session).

I have a dual-core x86_64 X2 4800+ with striped 10Krpm disks.   The machine is no slouch.

It takes 35 seconds to get to the same point.

Its probably relevant that I have ~400 services installed, mostly disabled.

Perhaps you need to use a dynamic list which becomes sensitive as soon as the first list-pane is full?

And, yes, some better indication that its doing something useful.

(In reply to comment #15)
> I have a dual-core x86_64 X2 4800+ with striped 10Krpm disks.   The machine is
> no slouch.
> 
> It takes 35 seconds to get to the same point.
> 
> Its probably relevant that I have ~400 services installed, mostly disabled.

Having less services would probably help, yes.

> Perhaps you need to use a dynamic list which becomes sensitive as soon as the
> first list-pane is full?

Um, my impression (and intent) is that it does that. As soon as the backend has discovered all SysV and xinetd services, it sends a signal to the frontend which opens up the list.

> And, yes, some better indication that its doing something useful.

How about "Detecting ..." or "Discovering installed services"?

> > Its probably relevant that I have ~400 services installed, mostly disabled.
>
> Having less services would probably help, yes.

Help?  No, thats not the right way to solve this problem.  I might be filling my system with useless junk (value judgement) but its not technically invalid.

> > Perhaps you need to use a dynamic list which becomes sensitive as soon as
> > the first list-pane is full?
> 
> Um, my impression (and intent) is that it does that. As soon as the backend
> has discovered all SysV and xinetd services, it sends a signal to the 
> frontend which opens up the list.

Hmm, well, it isn't working.  Although there is a greyed-out list that apears after about 6 seconds.

BTW.  /usr/sbin/ntsysv opens in under 3 seconds.

> How about "Detecting ..." or "Discovering installed services"?

Better, perhaps with a progress bar to show that its actually alive...

But better still would be to not take so long till the first fully active pane
that the user even needs to think about it.

This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Me too, same problem in single user or root user on fedora 10

# /usr/bin/system-config-services 
ERROR:dbus.proxies:Introspect error on :1.87:/org/fedoraproject/Config/Services/ServiceHerders/SysVServiceHerder: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.AccessDenied: A security policy in place prevents this sender from sending this message to this recipient, see message bus configuration file (rejected message had interface "org.freedesktop.DBus.Introspectable" member "Introspect" error name "(unset)" destination ":1.87")
Traceback (most recent call last):
  File "/usr/bin/system-config-services", line 945, in <module>
    GUI (use_dbus = use_dbus).run ()
  File "/usr/bin/system-config-services", line 900, in __init__
    self.serviceherders.append (cls (bus = self._bus))
  File "/usr/lib/python2.5/site-packages/scservices/dbus/proxy/serviceherders.py", line 53, in __init__
    for service_name in self.list_services ():
  File "/usr/lib/python2.5/site-packages/slip/dbus/polkit.py", line 48, in enable_proxy_wrapper
    return func (*p, **k)
  File "/usr/lib/python2.5/site-packages/scservices/dbus/proxy/serviceherders.py", line 66, in list_services
    return self.dbus_object.list_services (dbus_interface = "org.fedoraproject.Config.Services.ServiceHerder")
  File "/usr/lib/python2.5/site-packages/dbus/proxies.py", line 68, in __call__
    return self._proxy_method(*args, **keywords)
  File "/usr/lib/python2.5/site-packages/dbus/proxies.py", line 140, in __call__
    **keywords)
  File "/usr/lib/python2.5/site-packages/dbus/connection.py", line 630, in call_blocking
    message, timeout)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.AccessDenied: A security policy in place prevents this sender from sending this message to this recipient, see message bus configuration file (rejected message had interface "org.fedoraproject.Config.Services.ServiceHerder" member "list_services" error name "(unset)" destination ":1.87")

(In reply to comment #19)
> Me too, same problem in single user or root user on fedora 10
[...]
> dbus.exceptions.DBusException: org.freedesktop.DBus.Error.AccessDenied: A
> security policy in place prevents this sender from sending this message to this
> recipient, see message bus configuration file (rejected message had interface
> "org.fedoraproject.Config.Services.ServiceHerder" member "list_services" error
> name "(unset)" destination ":1.87")

This is not the original problem, but another one which is revealed by a recent dbus upgrade which contains tighter default policy. Try whether updating to the following versions from updates-testing solves your problem:

system-config-services-0.99.28-3.fc10
PolicyKit-0.9-4.fc10

Me too, same problem in single user or root user on fedora 10

system-config-services not responding , even if  i update my system with yum update 

system-config-services-0.99.28-1.fc10.noarch

PolicyKit-0.9-3.fc10.i386

Me too, same problem in single user or root user on fedora 10

system-config-services not responding , even if  i update my system with yum update 

system-config-services-0.99.28-1.fc10.noarch

PolicyKit-0.9-3.fc10.i386

Me too. 
[mehmed@hp-laptop log]$ system-config-services
ERROR:dbus.proxies:Introspect error on :1.67:/org/fedoraproject/Config/Services/ServiceHerders/SysVServiceHerder: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.AccessDenied: A security policy in place prevents this sender from sending this message to this recipient, see message bus configuration file (rejected message had interface "org.freedesktop.DBus.Introspectable" member "Introspect" error name "(unset)" destination ":1.67")
Traceback (most recent call last):
  File "/usr/bin/system-config-services", line 945, in <module>
    GUI (use_dbus = use_dbus).run ()
  File "/usr/bin/system-config-services", line 900, in __init__
    self.serviceherders.append (cls (bus = self._bus))
  File "/usr/lib/python2.5/site-packages/scservices/dbus/proxy/serviceherders.py", line 53, in __init__
    for service_name in self.list_services ():
  File "/usr/lib/python2.5/site-packages/slip/dbus/polkit.py", line 48, in enable_proxy_wrapper
    return func (*p, **k)
  File "/usr/lib/python2.5/site-packages/scservices/dbus/proxy/serviceherders.py", line 66, in list_services
    return self.dbus_object.list_services (dbus_interface = "org.fedoraproject.Config.Services.ServiceHerder")
  File "/usr/lib/python2.5/site-packages/dbus/proxies.py", line 68, in __call__
    return self._proxy_method(*args, **keywords)
  File "/usr/lib/python2.5/site-packages/dbus/proxies.py", line 140, in __call__
    **keywords)
  File "/usr/lib/python2.5/site-packages/dbus/connection.py", line 630, in call_blocking
    message, timeout)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.AccessDenied: A security policy in place prevents this sender from sending this message to this recipient, see message bus configuration file (rejected message had interface "org.fedoraproject.Config.Services.ServiceHerder" member "list_services" error name "(unset)" destination ":1.67")


I have the following packages installed :-

dbus-1.2.8-1.fc10.i386.rpm
dbus-devel-1.2.8-1.fc10.i386.rpm
dbus-doc-1.2.8-1.fc10.i386.rpm
dbus-libs-1.2.8-1.fc10.i386.rpm
dbus-x11-1.2.8-1.fc10.i386.rpm
gnome-packagekit-0.3.12-1.fc10.i386.rpm
gnome-packagekit-extra-0.3.12-1.fc10.i386.rpm
PackageKit-0.3.12-1.fc10.i386.rpm
PackageKit-browser-plugin-0.3.12-1.fc10.i386.rpm
PackageKit-docs-0.3.12-1.fc10.i386.rpm
PackageKit-glib-0.3.12-1.fc10.i386.rpm
PackageKit-gstreamer-plugin-0.3.12-1.fc10.i386.rpm
PackageKit-qt-0.3.12-1.fc10.i386.rpm
PackageKit-udev-helper-0.3.12-1.fc10.i386.rpm
PackageKit-yum-0.3.12-1.fc10.i386.rpm
PackageKit-yum-plugin-0.3.12-1.fc10.i386.rpm

Again, please don't confuse this issue with bug #475203 which is likely fixed with these package versions:

system-config-services-0.99.28-3.fc10
PolicyKit-0.9-4.fc10

Installed system-config-services-0.99.28-3.fc10 and PolicyKit-0.9-4.fc10 from testing and everything works well. Thank you.

Works for me too with PolicyKit-0.9-4.fc10 from testing. Thanks.

Regarding the latest comments, I'll close this now.