Support Upstart

Scott, could you explain what we should change in order to fully support Upstart? Do you think we could be Upstart-compatible with minimal changes for Karmic (e.g. just changing a few locations/commands)? Are there deeper changes that could be nice to do in the long term?

And, last but not least, are there any people from Canonical willing to work on this? I'm not sure we (upstream) will be able to do much before the next release.

From what /usr/share/doc/upstart/README.Debian.gz explains, we can easily provide as many features as before by working with scripts from /etc/init.d, isn't it? Upstart jobs in /etc/init are essential parts of the system, and there's little interest in disabling them.

So I'd say that at least for Karmic, we can limit the work required. What we need is mostly a shift from running the scripts by themselves to using 'start'/'stop' to do so. I can do that quickly since our code fits well in that design. I've also a pair of little fixes that can make disabling services more correct, renaming links to "KNNservice" instead of plainly removing the files. What's your feeling about that?

On Sun Sep 27 20:46:13 UTC 2009 Milan Bouchet-Valat wrote:
> >From what /usr/share/doc/upstart/README.Debian.gz explains, we can
> easily provide as many features as before by working with scripts from
> /etc/init.d, isn't it? Upstart jobs in /etc/init are essential parts of
> the system, and there's little interest in disabling them.

Yeah, not allowing some things to be disabled may be sensible anyway. I
haven't looked at the full list of conversions, bug I believe it includes
GDM? That may well be something someone wants to disable?

Still though, allowing to control the things that are still init scripts
would be good.

> So I'd say that at least for Karmic, we can limit the work required.
> What we need is mostly a shift from running the scripts by themselves to
> using 'start'/'stop' to do so. I can do that quickly since our code fits
> well in that design. I've also a pair of little fixes that can make
> disabling services more correct, renaming links to "KNNservice" instead
> of plainly removing the files. What's your feeling about that?

Those fixes will be great if we do ship it, thanks.

'start'/'stop' is cleaner, but if only init scripts can be changed I don't
think it makes any practical difference.

Thanks,

James

Converted scripts include GDM, D-Bus, Apport, Anacron, acpid, UFW, avahi-daemon, NetworkManager. The first two are not a problem since there are problems with people stopping them by mistake and breaking their graphical sessions. The others would be good to have, but... On my system, services-admin still manages exim4, klogd, sysklogd, brltty, apmd, alsa-utils, bluetooth, hotkey-setup, powernowd, smartmontools, winbind, ssh, rsync, apache2, samba, ntp and cups. Definitely good to have, I guess.

So I'm done with the basic Upstart "support" (more of a "compliance"). I have a patch here that uses 'service' to start/stop scripts, and that hides services duplicated in /etc/init.d and /etc/init. This is because for compatibility, many scripts in /etc/init.d are links to an Upstart executable that runs actual jobs. So we don't want to mess with that.

I've created a new "upstart" init system, that is used for Debian platforms now. Do you now if Debian is planning to move to Upstart? I could theoretically make my patch for Ubuntu only, but that would mean changing platforms in every module and force a rework of patch at bug 434565. Since the only real requirement of the "upstart" system for now is to have 'service' installed, if Debian wants to get Upstart I'll keep it that way.

About the fixes I've talked above (links and priorities), they are in the gst and in liboobs, so sadly they can't be released now. I could include them in 2.28.1, if that's worth it, or you could cherry-pick them for Ubuntu. But those changes are completely independent from Upstart, actually - they just make services-admin much cleaner.

About releasing the stb: when would Ubuntu need the release so that it can be included properly in Karmic? I can make it very soon, but we have to be sure there are no major bugs (changes are not so complex, though).

I've just realized /sbin/service is shipped by sysv-utils, so I guess I should use /sbin/initctl instead, which is shipped by upstart. Just a command to rename, anyway.

I've also checked packages in Debian, and they have upstart 0.6.3 in squeeze already, and the plan seems to be to switch to upstart, so I guess it's OK to push the patch. See
http://lists.debian.org/debian-devel-announce/2009/09/msg00003.html

Any reactions about my previous comment? If you approve it, I can release tomorrow, but I'd like to be sure it's OK before.

OK, eventually released in 2.8.2 which should be uploaded soon. FWIW, the code used service instead of initctl as the latter only deals with upstart jobs.

James: see bug 443312 about packaging 2.8.2. We're quite in a hurry, I must admit...

Ping to all: do you consider it's too late to do anything about that, even cherry-picking the simple patch that adds compatibility with Upstart? services-admin is something important for many users, see the duplicates and http://ubuntuforums.org/showthread.php?t=1272747

Basic support is now in Karmic with the system-tools-backends 2.8.2 (see bug 443312). services-admin can be brought back if we want.

Milan, could you tell me what's the status on this? I still don't see services-admin available in Lucid. It's rather important to have in a LTS release :)

Ask Chris Coulson about that. Upstart support is not really plan for now, because most useful services are actually still using SysV scripts. So what I'd like to see in Lucid is services-admin managing those scripts, and hide Upstart jobs, which are started when needed, and often essential system services. This is already working fine, and we kind of agreed that bringing back services-admin, at least as a separate package, would be nice. But I think Chris needs some free time to do it, and we have to decide in what form.

OK, here's a debdiff that re-enables services-admin in Lucid (pretty basic).

Chris, do you think you could apply this one before everything gets frozen?

Oh, and BTW, people that want to test this package may install it from my PPA:
https://launchpad.net/~nalimilan/+archive/ppa/+packages?field.name_filter=gnome-system-tools&field.status_filter=published&field.series_filter=lucid

Hello Milan and thank you for working on this as it is very much needed. From what I understand (after reading this bug and testing the packages in your PPA) is that your services-admin completely ignores upstart jobs and allows a user to only enable/disable SysV scripts. Only my testing shows different results. I am not able to disable SysV scripts (such as the one which starts the ssh service), whereas rcconf does the job correctly.

I am also not able to disable GDM (to start the computer in command line) and UFW (to start the computer without a firewall). Both which have been converted to upstart (I believe; I mean they do have an upstart /etc/init/<serv>.conf file) and it is reasonable to expect that a user may need to turn them off (I know this goes against your theory of "Upstart jobs are hidden since they are the less interesting to disable").

After my tests I don't believe this is what was intended by the "Upstart compatible services-admin[1]" blueprint. First, we need a way to have a non-destructive means to disable an upstart job (as explained in Bug #94065 [2]). Currently, the way I use to disable an upstart job is to rename a config file for the service needed:

$ mv /etc/init/<serv>.conf /etc/init/<serv>.away

Once the non-destructive method of disabling a job has been introduced, services-admin will need to be changed to use that method. A that point, I would say that we are one step closer to making a services-admin that can handle the init -> upstart transition. Until then, headaches distinguishing jobs from scripts, renaming upstart .conf files, and using update-rc.d/rcconf for SysV scripts.

Meanwhile, do you have any idea why ssh doesn't show up in your services-admin? Did you create a filter list for the items that show up (or stay hidden) in services-admin?

[1] https://blueprints.launchpad.net/ubuntu/+spec/desktop-lucid-services-settings-window
[2] Bug #94065 (upstart) - init: add non-destructive means to disable a job

Please stay specific to the very issue I'm trying to tackle for Lucid: we won't get true Upstart support included before the final release. So let's discuss and test my PPA package on the basis of SysV scripts *only*.

From all of your description, I can't see any issue that wasn't expected beforehand: we ignore Upstart jobs. SSH doesn't appear because it installs /etc/init/ssh.conf. Granted, it would be nice to be able to manage this too, and that won't be too hard, but that's not possible for Lucid.

So do you have a precise objection to this package considered as a stable-enough quick solution for Lucid?

looks like Lucid shipped without services-admin :( see Bug #437905 for tracking getting services-admin re-released.

this is annoying - the System -> Administration -> Services menu is missing, and for example cups doesn't start automatically on the system, how would I make it start automatically?

removing a feature, but not providing a replacement is not progress :(

(BTW, cups's troubleshooting guide specifically tells you to go to System -> Administration -> Services, which is now nonexistent)

how do I add a service to the default runlevel then?

See http://www.unixtutorial.org/2009/01/disable-service-startup-in-ubuntu/, or install bum.

I would be gracefull if the ppa would be updated Lucid is on 2.30 at the moment while the ppa is on 2.29.91.

This is a colossal mess. The bottom line seems to be that one has to recheck all service configs after an update, whether sysv or upstart. One also has to "know" which services have been "upstarted" in order to derive their expected behaviour.

Confidence in services' configs at reboot has just been reduced to near zero.

The current workaround, to retain confidence, seems to be to aptitude remove services to ensure they don't load. And that is bonkers!

Anyone working on restoring the "services" menu?

This bug's status isn't set to "In progress" nor assigned to someone, so no one is working on this.