The system-config-services on F11 is completely broken. Below is the error log when an attempt is made to stop/start/disable any services. In effect it does not work at all. # system-config-services Traceback (most recent call last): File "/usr/bin/system-config-services", line 807, in on_serviceDisable_activate service.disable () File "/usr/lib/python2.6/site-packages/slip/dbus/polkit.py", line 53, in enable_proxy_wrapper sessionbus = dbus.SessionBus () File "/usr/lib/python2.6/site-packages/dbus/_dbus.py", line 219, in __new__ mainloop=mainloop) File "/usr/lib/python2.6/site-packages/dbus/_dbus.py", line 108, in __new__ bus = BusConnection.__new__(subclass, bus_type, mainloop=mainloop) File "/usr/lib/python2.6/site-packages/dbus/bus.py", line 125, in __new__ bus = cls._new_for_bus(address_or_type, mainloop=mainloop) dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
This works for me ;-). Do you start s-c-services as the logged in user from an active session? What does ck-list-sessions give?
*** Bug 505579 has been marked as a duplicate of this bug. ***
I think for F10, I had to start this as root. With F11, when I start it as the logged-in user and then try disabling the service, it asks for root passwd and succeeds. So this happens only if I do this: $ su # system-config-serivces <backtrace>
s-c-services is started from root, but circumstances don't change even if it's started from a user.
(In reply to comment #3) > I think for F10, I had to start this as root. With F11, when I start it as the > logged-in user and then try disabling the service, it asks for root passwd and > succeeds. > > So this happens only if I do this: > > $ su > # system-config-serivces > <backtrace> You should use "su -" instead of plain "su" to set up the environment for the root user correctly, this way it would bypass dbus, PolicyKit, etc. If you only use "su", it is run as the root user (not in a ConsoleKit session), but with the normal user environment and gets confused. (In reply to comment #4) > s-c-services is started from root, but circumstances don't change even if it's > started from a user. Please provide more details on that: are you logged into GNOME/KDE/.., as the root or a different user, how do you start the tool?
system-config-services works up to a certain point. As you add applications, it breaks. Sometimes it recovers and breaks again. Finally it breaks irretrievably. Same result with GNOME or KDE. Changed SElinux to disabled. No luck. Bug is intractable for regular users. Updates to SElinux are applied. It recoverd faintly. Greyed out window appeared. Then it failed completely.Login as "su" in a Terminal. Then run system-config-services. Error messages appear. Go to Administration->Services. Timeout occurs. Nothing comes up.
Multiple ways of not working: 1. Administration-> Services Result is timeout. As a regular user and not root, because logged as regular user. 2. From a Terminal: As suggested, changed to "su -" and password. Then ran system-config-services. Window comes up. Greyed out with no services listed. Question: Anything to do with bypassing dbus? 3. Remove pure-ftpd and then as 2 above: Same result.
Tested with different authorizations: In GNOME, System->Preferences->System->Authorizations->fedora project->config->services->Manage System Services: Implicit Authorizations: Anyone Yes Console Yes Active Console Yes Explicit Authorizations: None In GNOME, System->Preferences->System->Authorizations->fedora project->config->services->Get Information About System Services: Implicit Authorizations: Anyone No Console No Active Console No Explicit Authorizations: None 1. Administration-> Services Result is Service Configuration Window comes up; however, greyed out. As a regular user and not root, because logged as regular user. 2. From a Terminal: As suggested, changed to "su -" and password. Then ran system-config-services. Result is Service Configuration Window comes up. Greyed out.
system-config-services window comes up ; however, greyed out. Any suggestions?
You can increase the python stack size by inserting some lines right after the first comment block in /usr/bin/system-config-services and /usr/share/system-config-services/system-config-services-mechanism.py -- like that: --- 8< --- import sys sys.setrecursionlimit (2000) --- >8 ---
Does the workaround suggested in comment 10 improve the situation?
(In reply to comment #11) > Does the workaround suggested in comment 10 improve the situation? It certainly made my s-c-s gui functional again when root, and it was not prior. The initial large load and greyed window are still present when started from cli or menu, but this is very brief and seems like a non-issue. Thank you.
*** Bug 504448 has been marked as a duplicate of this bug. ***
I added import sys sys.setrecursionlimit (2000) lines as advised by comment 10, then ran system-config-services and pressed "Stop" button on restorecond service. Traceback appears, and service does not stop: # system-config-services Traceback (most recent call last): File "/usr/sbin/system-config-services", line 825, in on_serviceStop_activate service.stop () File "/usr/lib/python2.6/site-packages/slip/dbus/polkit.py", line 48, in enable_proxy_wrapper return func (*p, **k) File "/usr/lib/python2.6/site-packages/scservices/dbus/proxy/services.py", line 85, in stop self.dbus_object.stop (dbus_interface = "org.fedoraproject.Config.Services.SysVService") File "/usr/lib/python2.6/site-packages/dbus/proxies.py", line 140, in __call__ **keywords) File "/usr/lib/python2.6/site-packages/dbus/connection.py", line 630, in call_blocking message, timeout) dbus.exceptions.DBusException: org.fedoraproject.slip.dbus.service.PolKit.NotAuthorizedException.org.fedoraproject.config.services.manage:
(In reply to comment #14) > I added > > import sys > sys.setrecursionlimit (2000) > > lines as advised by comment 10, then ran system-config-services and pressed > "Stop" button on restorecond service. Traceback appears, and service does not > stop: [...] > dbus.exceptions.DBusException: > org.fedoraproject.slip.dbus.service.PolKit.NotAuthorizedException.org.fedoraproject.config.services.manage: Looks like you either ran this as a normal user and you don't have the authorization or you ran it as root and didn't clean your environment. Either use "su -", or start the program with "--no-dbus" if you use it as root.
I run it as root. --no-dbus fares worse, it errors out before I do anything: # system-config-services --no-dbus Traceback (most recent call last): File "/usr/lib/python2.6/site-packages/scservices/core/asynccmd.py", line 96, in on_fd self._finish () File "/usr/lib/python2.6/site-packages/scservices/core/asynccmd.py", line 103, in _finish self.pipe.wait () RuntimeError: maximum recursion depth exceeded
(In reply to comment #16) > I run it as root. --no-dbus fares worse, it errors out before I do anything: > > # system-config-services --no-dbus > Traceback (most recent call last): > File "/usr/lib/python2.6/site-packages/scservices/core/asynccmd.py", line 96, > in on_fd > self._finish () > File "/usr/lib/python2.6/site-packages/scservices/core/asynccmd.py", line > 103, in _finish > self.pipe.wait () > RuntimeError: maximum recursion depth exceeded And that is a good thing -- you see the actual backend error instead of a follow-up one in the frontend (because frontend and backend run in the same process). I'm still trying to get a handle on why it would bring that error as I don't do recursion by myself. The traceback above is from a callback that was installed via gobject.io_add_watch() and I found that this uses GSource objects in the background which can be set to recurse or not -- I don't know enough about the implementation to say that this does or doesn't contribute to the problem. Matthew, can you shed some light on this? Some background: s-c-services basically open a huge number of pipes ("service <something> status", "chkconfig --list <something>", for every services) concurrently after it starts and I get the recursion RuntimeError above in the processing callback for these pipes. As the gobject/glib modules don't expose the whole API, I can't experiment with a non-recursing GSource here (from python). The only thing I can say for certain right now is that I don't do recursions in my python code ;-). Thanks in advance.
*** Bug 511356 has been marked as a duplicate of this bug. ***
system-config-services-0.99.34-1.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/system-config-services-0.99.34-1.fc11
system-config-services-0.99.34-1.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/system-config-services-0.99.34-1.fc10
(In reply to comment #17) > The only thing I can say for certain > right now is that I don't do recursions in my python code ;-). And I was in error to say that: In order that the GUI wouldn't hang during discovery, I let the GTK main loop service pending events in the callback that processes discovered services, which in turn would service that callback, ... and so forth. I've made a lock around this which avoids deep recursion, built 0.99.35 meanwhile and requested that it be pushed to testing.
system-config-services-0.99.35-1.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
system-config-services-0.99.35-1.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.
Problems still persist with System-config-services. GUI window remains greyed out after running from console with "su -" and/or "--no-debus". Will not start at all, from Administration -> Services neither in Gnome nor in KDE. Various suggested changes do not work. Works in a medium installation in applications and services. Adding applications and services eventually breaks. Suspect one bad apple service or application. Deeper knowledge is needed.