services-admin should be disabled

Yeah, services-admin is in a poor shape... I wanted to ask Scott James Remnant about what should be done in the system-tools-backends so that we work with upstart. Would you have any idea if somebody from Canonical would work on this? :-p

Anyway, splitting it for now is a wise choice IMHO.

This bug was fixed in the package gnome-system-tools - 2.28.0-0ubuntu1

---------------
gnome-system-tools (2.28.0-0ubuntu1) karmic; urgency=low

  [ Chris Coulson ]
  * New upstream release 2.27.92 (LP: #433700):
    - Network: Remove empty space around buttons on the right (Milan)
    - Time:
      + Fix crash due to empty time zone list (Milan)
      + Fix missing time zones map (idem) (Milan)
      + Correctly detect NTP support when we've just installed it (Milan)
    - Users:
      + Prevent changing root's UID, and that of currently logged in users.
        Show a notice about that. (Milan - Bug 395056)
      + Always check that committing changes is successful before showing
        them (Milan)
      + Don't try to create the user if we could not create its main group.
        This avoids showing three identical error dialogs when failing. (Milan)
      + Allow new users to explicitly choose in the list an existing group
        for main group (Milan)
      + Set UID and GID range to [0;MAX_UINT32], since those values are
        allowed (for manual selection only) (Milan)
  * debian/control:
    - Bump libgtk2.0-dev build-dep to 2.16.
  * Disable services-admin - it is not very useful in the Upstart world
    (LP: #433701).
  * Dropped obsolete debian/patches/18_disable_uid.patch.
  * Added debian/patches/84_hide_uid_notice.patch:
    - Disable a new string introduced upstream, as we are past UI Freeze.
      The string is not fully translated yet and incorrectly uses a
      gender-specific pronoun, which would need to change.
  * Refreshed patches:
    - 82_gst-packages-time-admin.patch
    - 98_automake.patch

  [ Martin Pitt ]
  * Update to 2.28.0 (LP: #433700):
    - Translation updates.
  * debian/control.in: Fix policykit-gnome dependency to be policykit-1-gnome.

 -- Martin Pitt <email address hidden> Tue, 22 Sep 2009 09:53:06 +0200

Hi,

As I understand it using "service" should be the preferred way of
manipulating services now. It supports sysvinit and upstart, and
will gracefully handle the transitions.

It doesn't include a "disable" interface, which I think gst provides?

Thanks,

James

Thanks for the hint. Though, I guess the migration should be more complex than a mere s/update-rc.d/service/g. We'll have to see how services are disabled currently, but you may well be right that we have some custom code (I remember bugs about its implementation not being right). Service name and description will have to be loaded from the LSB header, instead of hardcoding it, too. And I'm sure some smart new features of upstart should be supported better/differently, too.

What will replace services-admin to start/stop services from the GUI then ?

If this was/is the only GUI tool for that, it would go a bit against Ubuntu's motto to remove it altogether before providing an alternative.

We removed it altogether because it doesn't work with Upstart jobs. We haven't provided an alternative because one doesn't exist yet. Would you rather we carried on shipping an application on the CD that doesn't work properly?

Chris I just wonder where is the logic in removing a tool that needs to be fixed instead of, well, fixing it.

The current situation means we're now back in command line, an important regression IMO.

On Wed, 2009-09-23 at 16:28 +0000, Fabián Rodríguez wrote:
> Chris I just wonder where is the logic in removing a tool that needs to
> be fixed instead of, well, fixing it.

You seem to assume that we can just wave a magic wand and the tool will
be magically fixed with no effort. If that was possible then we would do
that, but the reality is that fixing it requires a finite amount of
effort, and there just isn't anybody available right now who has time
(or is interested enough) to actually do the work. There are currently
more important issues for us to work on at the moment rather than
spending time fixing a tool which isn't all that useful anyway.

Regards
Chris

Fabián: actually I'm currently planning to spend my "fixed amount of time" on users-admin, which is IMO a more essential part of our system. I won't be able to fix services-admin in time for Karmic. But if you want to give it a try, basic support may not be too complex (replacing calls to "update-rc.d" with "service" will be a good start), mostly requiring some testing and distro-specific cases to keep supporting. I could give you as many hints as you want, and promise you to make a release as soon as it is ready.

See bug 435935 about Upstart support in the system-tools-backends.

@Chris I am not asking for an *immediate* fix, tone down.

@Milan, thanks for the explanation and bug link, knowing this won't work for another cycle lets me plan and document accordingly.

Hopefully future similar transitions can be planned more sensibly.

Has anyone seen the services GUI used by Fedora? It's pretty nice, much better than services-admin. I don't know if it works with upstart, but if so, maybe we could just use that. (It is open source, after all.)

What always bothered me about services-admin is that it wasn't comprehensive. It was hard-coded for some particular services, rather than providing a general interface for manipulating any services the user may have installed. I hope its replacement is more general.

Correct me if I'm wrong (it's hard to get details on system-config-services on the Web), but I don't believe the Fedora tool brings us much more than we have (or could easily have). It seems to work only with traditional init scripts, and does not seems to have very different features from services-admin.

The problem about hard-coded services list is really silly, I guess I can fix that for the next release. Basically, the problem is that you can't get translated names and descriptions from random services, because scripts don't provide it. But we can easily translate known services, and show others in plain English.

And if the matter is making the GUI nicer and make it present more informations, that should be quite easy to do, the framework is already present.

@Milan: Yes, we should provide descriptions for those services we
know, and allow operations on all services, even those we don't know.

However, I think the list of "known" services should not be
hard-coded; rather, there should be a way for services to register
themselves with service manager and thereby provide a description. So,
for example, the service manager, upon encountering an unknown service
in /etc/init.d/myserviced would look at
/usr/share/registered-services/myserviced.desktop (for example) and
find out that the friendly name is "My Service" and the description is
"This service provides some services." This way any arbitrary package
can be extended to provide a "nice" description by including the
appropriate .desktop file.

What do you think of this idea?

Follow-up: maybe the services.desktop file could contain firewall
exception information as well, for integration with a possible
eventual firewall manager GUI?

Yeah, we can imagine several ways of translating descriptions of services, and .desktop files would be a convenient solution. But that's really beyond the scope of services-admin... You may want to discuss that on the Upstart mailing list, for a start. However, we have to comply with the Linux Standard Base in all cases, so that solution can only be an option for packages, and we must keep supporting the old way. Definitely not a trivial work - I think we're going to need the static list for a long time.

I have just upgraded from 9.04 to 9.10.
There is still "Services" option in Administration menu. When I click it, it failes because services-admin can not be found.

If you remove services-admin, you also ought to remove this menu item.

The menu item is removed. If it stays in your user profile, then it's because you made customizations to it at some point (perhaps hidden it using the Menu editor?)

If you create a new user account, you will find that there is no menu icon

I accept that the services old app doesn't work any more and requires fixing or replacing.
I understand that no-one has the time. However for a supposedly user-friendly O/S like Ubuntu to remove the GUI option and leave users no option except to use the command line is absolutely not a good idea. There seem to be an awful lot of problems with this release. :-(

Since I wanted to play a bit with glade+gtkpython and I was missing a mean to manage services through the GUI, I spent a couple of days to make an upstart graphical front-end "ServiceManager" which is in attachment.

The program is really simple and lets you only list, stop start and restart the services because at the present time there's no mean in upstart to control if a service should be enabled or not. Even if the usefulness is quite low, I hope that it's still better than nothing.

The deb can be installed on all architecture and places an icon under the administration menu. The program itself is made of two files which can be found under /opt/servicemanager: "mainwindow.glade" is a glade3 project and "servicemanager.py" is the program itself.

If I'll see some interest I can try to extend functionality (as far as the underlying tools like service, initctl etc. allow).

BIG DISCLAIMER: It's my first work on python, it's something made just to suite my needs, it's simple and stupid, but if it fills an hole I'm happy to share.

Servicemanager has grown up a bit, now it's in version 0.2, it fetches services descriptions and let enable/disable system V services at boot.

Further updates here: http://ubuntuforums.org/showthread.php?p=8376891

I just wanted to compliment you for the lack of information on how to enable/disable services via the console. I guess I am not the only one who has disabled a service via the GUI of services-admin and is clueless how to re-enable it now.

Don't get me wrong, ubuntu has an unprecedented level of user friendliness compared to other distributions I can account for over the past 11 years and is attractive because it does not require the occasional sacrifice of a goat to get something to work. However, if you're forced to sack functionalities at least be decent and provide information how to do things from now on instead of wasting the time of others.

I am a bit in a culture shock to see this bug trail. I said back in 2006 and I'm repeating myself now. We need an Ubuntu local system tools package. That would suite and co-operate nicely with all the new quirks Ubuntu now uses (upstart being an example).

Also, why not offer some funding to Carlos to do that work? He'd be happy to and there were always talks about funding him to put some more polish into gnome-system-tools. This could benefit the entire community which is using GST.

There's no need for funding, most of the work is here, Upstart support isn't that required to get services-admin back and useful. It's just a matter of packaging. Though, if you want to pay me, just go on, I'll add Upstart support sooner... :-p

see Bug #437905 for tracking getting services-admin re-released.