Revision 1 as of 2006-11-23 12:22:51

Clear message

Please check the status of this specification in Launchpad before editing it. If it is Approved, contact the Assignee or another knowledgeable person before making changes.


This specification outlines, in detail, the process for replacing the existing initscripts package with event-based upstart jobs.


Our boot sequence is currently an ordered set of jobs, trying to complete alongside some udev callouts. This is inherently both slow and racey. We developed upstart so that we could have a truly event driven boot sequence, now we take advantage of it.


The easiest way of describing the changes is a graph showing the tasks, services and events that are proposed. The rest of this specification will contain the rationale for any unusual changes.



initial setup run in parallel. Once /proc is mounted, the other pieces of trivial setup such as the hostname and keyboard map are entirely isolated from each other. It's safe to run these side by side.

/dev mounted by new task. Currently the /dev filesystem is mounted by the udev init script, and filesystems underneath mounted by the mountdevsubfs init script. This is rearranged so that /dev and the other filesystems are mounted first, and that used to start udev.

udev and cold plugging separated. In the upstart world, udev is a service that we want to be respawned if it dies. The cold plugging and module loading is something that we want to do as a result of this. If LRM is installed, this need to be finished first.

network and block device events from udev. For the parallel win, we use udev events for network devices, interfaces and block devices as a major source of our events.

filesystem checking and mounting. This is currently a couple of very complicated scripts; in this model, we split them into many very small, easy to read scripts. The particular advantage here is that they're much easier to handle, and can be run outside of the boot sequence.

cleanup run in parallel. Once the filesystem is mounted, we can run all of the individual cleanups at once; when they're all done, we're ready to go multi-user.

daemons started at once. There's very little dependency between the daemons we start on boot, so we can pretty much start them all at once.

dbus services. Several dbus services are started as a result of the dbus daemon itself starting.