ReplacementInitscripts

Differences between revisions 1 and 2
Revision 1 as of 2006-11-23 12:22:51
Size: 2780
Editor: quest
Comment: dump spec
Revision 2 as of 2006-11-30 14:35:23
Size: 5391
Editor: syndicate
Comment: write in the form of aplan
Deletions are marked like this. Additions are marked like this.
Line 11: Line 11:
This specification outlines, in detail, the process for replacing the existing initscripts package with event-based upstart jobs. The primary source of tasks in the boot sequence comes from the `initscripts` package, which are implemented as serial shell scripts within the sysv-rc framework. This specification proposes their replacement with event-based upstart jobs.
Line 15: Line 15:
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. Our boot sequence is currently slow, full of race conditions and poor interactions, especially with competition between the series of tasks run by `sysv-rc`, `udev` and sometimes just with the kernel. We developed upstart so that we could have a truly event driven boot sequence that would be fast, reliable and flexible; we should take advantage of it.

== Use Cases ==

This specification is the logical next step of the ReplacementInit specification implemented for edgy, see that specification for use cases.

== Scope ==

The boot sequence is a complex series of moving parts, and any replacement should be done in stages with ample testing between. Therefore this specification does not specify the ultimate final result, and instead specifies the pattern of work and draft of the likely outcome.
Line 19: Line 27:
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. The new boot sequence will be driven by events received from the kernel, and generated by upstart as a result of running other tasks. Where possible, tasks that do not conflict will be run in parallel, and will only be run once their needs are met.

A draft chart based on the current boot sequence is given below. Note that there are already known bugs in this chart, as these bugs exist in our current boot sequence.
Line 23: Line 33:
== Rationale == === Rationale for Changes ===
Line 25: Line 35:
''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. A few changes were made in the above chart compared to the actual current boot sequence, the rationale for these is given below.
Line 27: Line 37:
''/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.  * ''/dev mounted by new task''.
Line 29: Line 39:
''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.  Currently the `/dev` filesystem is mounted by the `udev` init script, and filesystems underneath mounted by the `mountdevsubfs` init script. This has been rearranged so that `/dev` and the other filesystems are mounted first, and the events caused by that are used to start udev. This should make maintenance significantly easier.
Line 31: Line 41:
''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.  * ''udev and cold plugging separated''.
Line 33: Line 43:
''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.  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. Therefore they have been split into different jobs.
Line 35: Line 45:
''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.  * ''Network and block device events from udev''.
Line 37: Line 47:
''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.  We have race-free notification of addition and removal of network devices, interfaces and block devices from the kernel via the `udev` daemon. Rules will ensure that upstart can use these as a major source of events.
Line 39: Line 49:
''dbus services''. Several dbus services are started as a result of the dbus daemon itself starting.  * ''filesystem checking and mounting''.

 This is currently a couple of very complicated scripts; in the event-driven 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.

=== Known Bugs ===

 * The ''Set up keyboard'' task needs to happen after devices have been cold plugged, as it needs access to the `tty` devices. The current boot sequence runs this before, relying on the static devices or some to have come from the initramfs. This is not ideal.

== Implementation ==

The implementation process of this specification will be performed on a task-by-task basis. We can do this because existing init scripts will continue to be run by upstart once the jobs it manages have been run.

The order of work will be roughly:

 * Kernel filesystems, `udev` and cold plugging. In order to get the maximum benefit, we should ensure that at least the kernel filesystems and udev daemon are managed by upstart; and that `udev` emits events that the rest of the system can use.

 * Filesystem mounting and unmounting. The most critical job of the boot sequence, so it's important to get it right and spend the most time here.

 * Network device configuration. The next highest source of races, so our next target; this will also sort out the issue of network filesystems.

 * System setup and cleanups. Other jobs run within the current `rcS` such as setting up the keyboard and console, and cleaning out temporary directories.

Ideally the `/etc/rcS.d` directory of a fresh install, or one with only packages from ''main'' should be empty. We'll continue to run anything here, of course.

If there is time, jobs from `rc2` will be tackled. Priorities are:

 * `dbus` and services. This will gain a particular benefit as upstart can manage making sure services are restarted when dbus is, and stopped first, etc.

 * X display manager and dependencies. The X display manager is the daemon we want started as early as possible, so we should try and get this managed within upstart. Any dependencies should be managed as well to ensure that we're race free.

 * Hardware services such as CUPS, ACPId, etc.

 * Network services.

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.

Summary

The primary source of tasks in the boot sequence comes from the initscripts package, which are implemented as serial shell scripts within the sysv-rc framework. This specification proposes their replacement with event-based upstart jobs.

Rationale

Our boot sequence is currently slow, full of race conditions and poor interactions, especially with competition between the series of tasks run by sysv-rc, udev and sometimes just with the kernel. We developed upstart so that we could have a truly event driven boot sequence that would be fast, reliable and flexible; we should take advantage of it.

Use Cases

This specification is the logical next step of the ReplacementInit specification implemented for edgy, see that specification for use cases.

Scope

The boot sequence is a complex series of moving parts, and any replacement should be done in stages with ample testing between. Therefore this specification does not specify the ultimate final result, and instead specifies the pattern of work and draft of the likely outcome.

Design

The new boot sequence will be driven by events received from the kernel, and generated by upstart as a result of running other tasks. Where possible, tasks that do not conflict will be run in parallel, and will only be run once their needs are met.

A draft chart based on the current boot sequence is given below. Note that there are already known bugs in this chart, as these bugs exist in our current boot sequence.

attachment:Graph.png

Rationale for Changes

A few changes were made in the above chart compared to the actual current boot sequence, the rationale for these is given below.

  • /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 has been rearranged so that /dev and the other filesystems are mounted first, and the events caused by that are used to start udev. This should make maintenance significantly easier.

  • 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. Therefore they have been split into different jobs.

  • Network and block device events from udev.

    We have race-free notification of addition and removal of network devices, interfaces and block devices from the kernel via the udev daemon. Rules will ensure that upstart can use these as a major source of events.

  • filesystem checking and mounting. This is currently a couple of very complicated scripts; in the event-driven 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.

Known Bugs

  • The Set up keyboard task needs to happen after devices have been cold plugged, as it needs access to the tty devices. The current boot sequence runs this before, relying on the static devices or some to have come from the initramfs. This is not ideal.

Implementation

The implementation process of this specification will be performed on a task-by-task basis. We can do this because existing init scripts will continue to be run by upstart once the jobs it manages have been run.

The order of work will be roughly:

  • Kernel filesystems, udev and cold plugging. In order to get the maximum benefit, we should ensure that at least the kernel filesystems and udev daemon are managed by upstart; and that udev emits events that the rest of the system can use.

  • Filesystem mounting and unmounting. The most critical job of the boot sequence, so it's important to get it right and spend the most time here.
  • Network device configuration. The next highest source of races, so our next target; this will also sort out the issue of network filesystems.
  • System setup and cleanups. Other jobs run within the current rcS such as setting up the keyboard and console, and cleaning out temporary directories.

Ideally the /etc/rcS.d directory of a fresh install, or one with only packages from main should be empty. We'll continue to run anything here, of course.

If there is time, jobs from rc2 will be tackled. Priorities are:

  • dbus and services. This will gain a particular benefit as upstart can manage making sure services are restarted when dbus is, and stopped first, etc.

  • X display manager and dependencies. The X display manager is the daemon we want started as early as possible, so we should try and get this managed within upstart. Any dependencies should be managed as well to ensure that we're race free.
  • Hardware services such as CUPS, ACPId, etc.
  • Network services.


CategorySpec

ReplacementInitscripts (last edited 2011-01-19 05:32:02 by 109-170-137-116)