Created attachment 482154 [details] Screenshot s-c-s Description of problem: All services in system-config-services are shown as with read dot and disabled. Version-Release number of selected component (if applicable): system-config-services-0.99.47-2.fc15.noarch How reproducible: Always Steps to Reproduce: 1. start system-config-services from terminal 2. 3. Actual results: All services in system-config-services are shown as with read dot and disabled. And with "This service is disabled." Expected results: To see services which are enabled with green dot and with and And with "This service is enabled." Additional info: loki@f15arc2 ~]$ service cups status cups.service - LSB: The CUPS scheduler Loaded: loaded (/etc/rc.d/init.d/cups) Active: active (running) since Thu, 03 Mar 2011 19:55:58 +0000; 19min ago Process: 959 ExecStart=/etc/rc.d/init.d/cups start (code=exited, status=0/SUCCESS) Main PID: 998 (cupsd) CGroup: name=systemd:/system/cups.service └ 998 cupsd -C /etc/cups/cupsd.conf [floki@f15arc2 ~]$ See comment in Bug 679185 - doesn't handle stderr well
This is because s-c-services makes certain assumptions about how services behave which are true with SysVinit (and upstart in SysV-compat mode), but are done differently with systemd. This needs more extensive changes which I hope will be ready for the beta.
Nominating this as F15Blocker, because it makes system-config-services unusable (and maybe even dangerous to use, haven't tried). At a minimum system-config-services should show a dialog box that it does not yet support systemd and then immediately exit, rather then showing wrong information.
Agreed, this should be a blocker -- but I'm working on it ;-).
Discussed at 2011-04-15 blocker review meeting. Agreed this is a blocker per criterion "# All applications listed under the Applications menu or category must withstand a basic functionality test and not crash after a few minutes of normal use. They must also have working Help and Help -> About menu items ". -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
I can reproduce this same issue with my recent upgrade from f13 via preupgrade.
Discussed at 2011-04-21 blocker review meeting. Nils is aware of the issue, will monitor for updates before next meeting.
*** Bug 679185 has been marked as a duplicate of this bug. ***
Discussed at 2011-04-29 blocker review meeting. No updates on this issue, other than a status change. Time is running out for F15. The Final test compose is scheduled for Monday, 2011-05-02. The Final candidate is scheduled for Tuesday, 2011-05-10. http://rbergero.fedorapeople.org/schedules/f-15/f-15-releng-tasks.html
Note that as far as the release criteria are concerned, simply not shipping s-c-s is an acceptable workaround for this issue: we don't require s-c-s to be present and working, we only require it to be working if it's present. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
system-config-services-0.101.0-1.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/system-config-services-0.101.0-1.fc15
I realize the above update is largely untested (except the testing I did), but it's still much better than the previous version with didn't work at all, so if s-c-services gets shipped on GA, it should be this version.
system-config-services-0.101.0-1.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.
Created attachment 500714 [details] s-c-s screen with inactive enable/disable buttons i've updated my system from *testing repos and installed system-config-services-0.101.2-1.fc15.noarch package from koji, but still has this issue: Even if I run system-config-services from root console, buttons enable/disable are not active. I am not sure if i should file a separate bug or could you reopen this one?
(In reply to comment #13) > Even if I run system-config-services from root console, buttons enable/disable > are not active. Currently, system-config-services can only enable/disable xinetd services -- systemd doesn't yet offer a way to enable/disable units via its dbus interface, see bug #701326 for details.