From SysV init via Upstart to systemd
Scramble at the Start
SysV init was formerly the sole candidate for starting processes on Linux, but today, a tech-savvy generation of init systems is waiting in the starting blocks.
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).
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.
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
However, SysV Init was neither the first nor the only init system for Linux, which first used simpleinit , 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
At the end of 1992, after the release of
admutil-1.4, a discussion ensued on Usenet  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 . 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.
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  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  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, 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  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 , 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).
Buy this article as PDF
Azure CTO says Redmond has already considered the unthinkable.
Lead developer quells rumors that the Debian version is slated for center stage.
MSBuild is now just another GitHub project as Redmond continues its path to the light.
Malware could pass data and commands between disconnected computers without leaving a trace on the network.
New rules emphasize collegiality in coding.
Upstart lands in the dust bin as a new era begins for Linux.
HP's annual Cyber Risk report offers a bleak look at the state of IT.
But what do the big numbers really mean?
.NET Core execution engine is the basis for cross-platform .NET implementations.
The Xnote trojan hides itself on the target system and will launch a variety of attacks on command.