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.
»