Systemd as central control for the Linux system

Neverending Story

Distributions such as Fedora and openSUSE, but also Debian derivatives such as Siduction, Semplice, and soon Tanglu, have already switched over to systemd (Figure 5).

Figure 5: Front ends already exist to exhibit systemd activities.

The dependencies to parts of systemd were the catalyst for hard decisions about the future init system in Debian. The discussion began in October 2003 with news on the Debian developer mailing list [14]: A complaint was filed about the dependency of the Gnome settings daemon on systemd – introduced by the hope that it wouldn't "turn into some kind of flame war."

But, that's just what happened. The discussion became heated and with no result, until it became clear after a week that no solution was possible. Another developer requested that the Debian Technical Committee (CTTE) [15] should take on the problem [16] and come up with a decision [17].

The CTTE familiarized itself with the technical issues and tried to find a solution supported by all its members. The board comprised eight members – of which four soon supported systemd, with the other four supporting Upstart. Of the latter, two were currently working at Canonical, and a third was a former Ubuntu employee.

The Debian project has its particular problems because of its many supported architectures. Thus, it was clear from the beginning that the Hurd and KFreeBSD platforms weren't working with systemd. This proved to be a problem technically and politically for the largest distribution that decides things without any corporate backing.

Of the three candidates that could replace SysVinit, only one could come to the rescue: OpenRC, developed in Gentoo. Although it currently has little chance of establishing itself as the default init system, with some effort, it could run both architectures.

In the case of Upstart, a fork of the software would apply, because Canonical only allows collaboration when the aforementioned CLA is signed (see the "Canonical's Gag" box). Mark Shuttleworth would probably rub his hands if Debian took over the further development of Upstart.

Early February saw a second set of ballot initiatives [21] that committee member Ian Jackson (a Canonical colleague) proposed, without resolution, only to be followed by a third. The third vote was like the first, a simple proposal – with one difference: It included a clause that allowed Debian developers to adopt the ultimate decision-making tool at Debian, the General Resolution (GR) and thereby repeal the decision of the CTTE with a simple majority [22].

Normally, such a decision needs a two-thirds majority at Debian. The GR needs six official Debian developers to agree. In mid-February, the third ballot led to almost four months of discussion. Finally, Bdale Garbee, chair of the committee, broke the stalemate by invoking for the first time a special voting procedure for such situations and declared systemd a winner [23].

Whether the developers tilt the vote again with another GR has yet to be seen. Systemd would probably win again but would have a broader base. Thus, the argument of an arbitrary decision would be removed from the hands of any critics, with Upstart having hardly a chance in the process. The procedure, however, showed that the CTTE statutes might require some reform. Attempts by one or the other members to drag out the process and torpedo it are hard to overlook.

In his blog, Canonical founder Mark Shuttleworth conceded a few days after the decision to be the "graceful loser" and announced that even Ubuntu would make the switch to systemd in the long run, provided developers declared it to be as stable as the previous solution, Upstart.

Thus, with Debian and Ubuntu, the last major distributions are on course with systemd. Together they form a critical mass to influence its development in keeping with Debian. There may also be less contention among the distribution warehouses. Gentoo and Slackware are the sole outsiders; Gentoo continues to rely on OpenRC, while Slackware will probably keep the faith with SysVinit.

Optimizing the Boot Process with Systemd

Systemd provides a few tools to analyze the boot process and optimize it. These tools all work under a user account, which means no root privileges – the corresponding command is systemd-analyze .

In our test, on a workstation with KDE and a good many services and SSD for the whole system, the result was not convincing (Listing 1, line 1). A freshly installed current notebook with KDE started faster (Listing 1, line 2). On a lighter desktop environment, the values were in the three-second range.

01 02 Startup finished in 10.432s (kernel) + 6.287s (userspace) = 16.720s
03 Startup finished in 1.327s (kernel) + 3.116s (userspace) = 4.443s

If the startup takes too long, you can use systemd-analyze blame to test which processes and services are to blame. On an older notebook, the blame option revealed that the NTP service was stuck in a loop for more than 30 seconds. As it turned out, it was trying to contact a server that no longer existed, so a configuration correction fixed the problem.

If necessary, you can create a graph with systemd-bootchart that shows the behavior at boot time (Figure 6). The command is as follows:

Figure 6: Using a boot chart, you can tell at first glance which services are coming up on startup.

$ systemd-analyze plot > test.svg; inkscape test.svg

In this case, the Inkscape application helped in viewing the graph. Alternatives include image viewers such as Gthumb or the Firefox web browser.