Upstart is the ‘new’ event-based sysvinit replacement by Canonical, that has been widely adopted in the linux world ever since it first appeared in late 2006. The idea is centred around causality, that is, defining relationships that are not loosely defined by some measure of time, but by the presence (at runtime that is) of processes that a service depends upon. For example, if you need service X to run after service Y, you shouldn’t have to ‘wait’ for Y to start before starting X, but, instead, you should be able to specify that X depends on Y in some canonical form and the system would try to start X as soon as Y was up and running. In other words as a user/administrator of a machine you shouldn’t have to go through all that S?? and K?? silliness from SysV.
Upstart is by no means the first such service management system; Apple has incorporated its own version of such a system, called launchd, since the mid 2000s and so has Sun Microsystems with SMF. In fact, launchd was considered as a sysvinit replacement for Ubuntu 6.10, before Upstart was anything but a crude replacement for the /sbin/init daemon, but the idea was scrapped due to licensing issues (launchd was at the time licensed under the somewhat controversial Apple Public License; it has since been relicensed under the Apache License).
In the upcoming Ubuntu 9.10 release Upstart has reached another milestone, ‘just’ three years since it first made its appearance as a project; a number of core scripts have been rewritten as Upstart jobs (yay). Despite the fact that Upstart has been adopted by a number of systems (including Fedora, Maemo and — soon — Debian, among others) there are numerous issues (and practically no documentation for most of the system) as well as extreme volatility in both the format and structure of Upstart jobs and — alas — the aimed featureset. The only thing that’s been ‘stable’ in Upstart is the actual daemon, while the configuration/job format has been changing (and being moved around) every few months.
The problem here is that it’s dumbfounding how most major ‘vendors’ of GNU/Linux distributions equally depend on such a system and how no-one is putting any effort in getting this done. To the end-user (and given the lack of documentation to practically everyone not bothering looking at the source code) Upstart has been nothing but a sysvinit-like daemon for more than three years.
I’m pretty sure that Upstart is most certainly going to offer a lot of the linux community in the future. On the other hand, as with so many other promising open source projects, its development pace is slower than molasses, unstructured and undisciplined and makes me (at least) wonder what exactly the commercial linux ‘vendors’ are thinking when they clearly fail to support, finance and expedite the development of solid foundations upon which most of the ‘fancier’, ‘prettier’ and more humane features could be built.
Fortunately, in this particular case, a solution might be possible: Ditching Upstart and adopting launchd might make more sense, given the practical non-existence of Upstart as a complete, functioning, open source and usable system, but especially given the maturity and stability of launchd (even at the cost of a marginally inferior feature set), leaving aside the fact that people can actually use it *today* without resorting to reading ever-changing source code or waiting in perpetuity for a way to write and manage their system services.
I’m saddened that it’s late 2009 and I bet that in one year’s time Upstart will be so marginally improved that this post might need minimal changes to be current. I’m very much looking forward to losing that bet.
