Why I am unhappy with Upstart right now

October 8, 2010

Upstart has a little problem: it erases the difference between something having a startup script and whether that script is activated or not. There is no equivalent in Upstart to the distinction between /etc/init.d and /etc/rc?.d; everyone puts startup configurations directly in /etc/init, where Upstart will process them. This matters quite a lot to me, because there are plenty of packages that we want installed without having their daemons be active.

Editing the /etc/init file is not a solution (even if it's done by a script), because the file is owned by the package, not the sysadmin. An Upstart .conf file contains a great deal more than whether or not a daemon is enabled (and under what circumstances); it also has how to start the daemon and what associated processing you need to do. This means that its contents are logically tied to the rest of the package and may need to be updated when the rest of the package is.

If you edit the file and the package is updated, either your changes are lost (and the daemon either starts running when you didn't want it to or stops running when you did) or you now get to merge your changes with the package's changes by hand. Neither is a good outcome when all you wanted to do was stop the MySQL daemon from running by default.

There's also a consequence for how people package daemons. It used to be that a lot of daemons were shipped in a default-disabled state, where after installation they were just available but you had to use chkconfig or the equivalent to turn them on. This was perfectly viable when we had a chkconfig (and GUI versions of it), but Upstart removes all that and makes it much more difficult and annoying to change the enabled/disabled state of a daemon. I suspect that the result will be a lot more daemons being installed default-enabled (if the packager has to pick an option, it's the more useful one), and in turn this means I'll be installing a lot less daemons.

Comments on this page:

From at 2010-10-08 12:55:39:

Looks like currently the only way to do this (at least in Ubuntu) is to move /etc/init/<service>.conf /etc/init/<service>.conf.off or basically to some other extension besides .conf. Kinda brain-dead if you ask me and doesn't help control which runlevels a service starts in.

-- Preston

By cks at 2010-10-08 13:43:04:

Also, once you rename the <service>.conf file you can't even start the service by hand with initctl.

From at 2010-10-08 20:11:10:

In general I think it's best practice to install only what is needed. I do all of my installs bare minimum and then install the specific packages I need. This keeps triage to a minimum in the event of a bus. Even with good documentation and a configuration management system if you get hit by a bus someone will need to triage the system.

I'll have to look at upstart sometime but that does sound a bit annoying.

From at 2010-10-09 03:27:48:

Upstart is symptomatic of a desktop/laptop bias. (So's NetworkManager.) On a server, I want complete control, and I want it to be predictable and as linear as possible. It's perfectly OK that I don't get complete dependency ordering in my startup scripts, because (a) I will be testing before deployment and (b) I don't expect to reboot a server very often.

On a laptop, it makes sense that the user wants the package they just installed to work immediately; that the kernel driver modules are loaded at the last moment; that the networking stack reconfigure itself without intervention. None of that is true in server-land.


From at 2010-10-09 22:48:26:

What nonsense is this?! chkconfig works perfectly with Upstart (on both Fedora 12 and 13).

By cks at 2010-10-10 00:12:58:

chkconfig only works on things that are still in /etc/init.d. These are not native Upstart service configurations and (at least officially) Upstart only supports them for backwards compatibility; programs are supposed to be migrating away from them to Upstart's /etc/init/<service>.conf setup.

From at 2013-01-28 12:17:42:

With recent Upstart version, automatic startup of a service can be disabled by doing:

echo manual > /etc/init/<service>.override
Written on 08 October 2010.
« In universities, you often buy hardware when you can
An illustration of how careful and clever spammers are today »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Fri Oct 8 01:01:27 2010
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.