For many years, the Linux kernel started the init process as its first official act and assigned it a process ID of 1. From that point, the init process spawned all other processes running on the system, acting as a kind of "daemon-starting daemon" that initiated the processes necessary for getting the system working at the required runlevel. SysV init reads a list of configured processes in the /etc/inittab file and then shuffles through the runlevels (Figure 1).

Figure 1: Init goes through various runlevels in the SysV system, all of which are set by inittab, and executes some init scripts in each.

At each runlevel, init – supported by init scripts – launches various services and does not stop until it reaches the originally envisaged target runlevel for the system. In the case of a Debian system with a runlevel target of 1, for instance, the user has no network connection or graphical interface but can still use local applications. When you shut down the computer, init terminates any running processes to leave the system in a safe shutdown state.

The time-tested init has been around for years, but it has been showing some signs of age. Some promising alternatives have appeared recently to challenge the uniformity of the all-init Linux universe.

From simpleinit to SysV init

As the name suggests, SysV init did not come from a vacuum; it was instead based on the runlevel system in System V, AT&T's commercial Unix system from 1983. Miquel van Smoorenburg ported SysV init to Minix in 1992; Peter Ørbæk developed a version for Linux, which debuted in April 1992 in version 1.0 of admutil [1].

However, SysV Init was neither the first nor the only init system for Linux, which first used simpleinit [2], an init-based system that Ørbæk had developed with the help of Werner Almesberger. It was a little simpler than SysV init, because it did not use runlevels, among other things, and it resided in the poeigl archive.

At the end of 1992, after the release of admutil-1.4, a discussion ensued on Usenet [3] about the appropriate init system. The starting point was Ørbæk's plan to use the Getty tool to write the logout records. A user pointed out that you should probably leave this job to init in the best Unix fashion and mentioned his good experience with SysV init. Ørbæk agreed to make SysV init the default in the next version of his toolkit; simpleinit had already grown "too big" he said. Then, plans changed because SysV init author Miquel van Smoorenburg in December 1992 took over the development of the tool on Linux and released version 2.0 [4]. He had purchased a 386, installed Linux, and completely rebuilt the SysV init code.

The original Minix support was lost, but to make up for this, SysV init was added to the kernel and, soon after, became the boot system for Softlanding Linux, the first Linux distribution ever. Smoorenburg supervised SysV init for 12 years, until he stopped the project in 2004.

Rearguard Action

Smoorenburg left, and an abandoned project that was still being used remained at version number 2.86. Debian developer Petter Reinholdtsen unofficially handled bug reports for SysV init, added patches, and released patched versions, which was also used by Ubuntu.

For five years, this frustrating status continued until Reinholdtsen, in July 2009, took over the project along with some helpers [5] and summarily declared the newly released version 2.87dsf of SysV init to be the new upstream.

The change of maintainer was also accompanied by a change in the repository: Ever since, Savannah [6] has hosted the code. Reinholdtsen certainly saw the irony in this takeover, because some distributions were thinking by this time about switching to Ubuntu's new init system.

Upstart

Upstart, a brainchild of Ubuntu developer Scott James Remnant, was designed to iron out the disadvantages of SysV init, which at that point was getting on in years and had been developed with a completely different model of computer in mind: Desktop computers that were powered up and then ran for quite a while without major changes to the hardware. In 2006, when Remnant began to develop Upstart, USB sticks, mobile hard drives, and external USB devices were already in common use.

Upstart supports flexible, event-based starting and stopping of services and thus speeds up the boot process. SysV init, on the other hand, delays the boot process occasionally because dependent services are not available, so it does not execute the other scripts until after a timeout.

Upstart does not define boot targets for starting services; instead they react to certain events. By defining a job, the admin ensures that Apache starts when a network is available. If needed, an event can trigger multiple jobs that run in parallel. The syntax is quite simple compared with SysV init.

Fedora, which integrated Upstart version 10 [7] in late 2008, wanted especially to get rid of the numerous Bash scripts associated with SysV init.

Debian saw Upstart as the answer to an increasingly event-based kernel and wanted to solve the problems that a sequential boot process occasionally brought with it. Reinholdtsen proposed that Debian switch to Upstart [8], but it was not until the end of 2012 that a package landed in Debian unstable.

In Ubuntu, Upstart has been around since October 2006, but this had little effect initially, because the developers emulated the behavior of SysV init. It was not until the 9x versions that the Ubuntu project replaced numerous init scripts with Upstart jobs (Figure 2).

Figure 2: Excerpt from a boot chart generated under Ubuntu 9.04.