Upstart Reloaded

In 2011, Upstart suffered a temporary setback when Remnant left the project. He joined Google to work on Chrome OS, which also relies on Upstart. Over time, his contributions to the mailing list dwindled significantly, and his place was taken by Canonical's James Hunt, a former IBM employee. Hunt still maintains and releases new versions of Upstart and took some time out to answer a few of my questions about the project.

According to Hunt, currently about 20 people work on Upstart, mainly Canonical employees. The software is not only part of all the Ubuntu installations worldwide but also runs under Chrome OS and on older versions of Fedora. Communication is handled via the mailing list and IRC channel, and the code and bug reports are managed on Ubuntu's Launchpad platform.

One of the changes initiated by Hunt involves setting up a repository that builds Upstart versions daily. Code changes are automatically posted on the mailing list. In addition to Scan-Build and Smatch, Coverity Scan handles static code analysis. The aim is to rely more on automated testing in future.

One of the greatest conflicts in recent project history, in Hunt's view, is the debate about Canonical's Contribution Agreement, out of which the Contributor License Agreement (CLA) arose. This still allows Canonical to license the code for Upstart and other projects commercially, but the developers reserve the right to sublicense and distribute freely.

Systemd

Another surprise event also happened during Remnant's tenure: systemd. Lennart Poettering, the brains behind PulseAudio and Avahi, and a Red Hat developer by trade, announced the alternative systemd init system in 2010 on his blog [9]. As he writes in the email interview, he was already working privately on an init system called Babykit before the appearance of Upstart, but he postponed it after the Upstart announcement.

At Linux Plumbers Conference 2009, he and colleague Kay Sievers decided that Upstart was taking the wrong approach, because it expected user input up front to determine the minimum number of required services. So, Poettering dusted off his plans, took a close look at Solaris's SMF and Apple's launchd, and started in November 2009 to develop code for systemd.

Future Plans

Technically, systemd wants to create massively parallelized services by enabling them in different ways: through sockets, buses, devices, paths, or timers. Traditionally, daemons wait under Linux for the sockets of other daemons to start receiving before they send requests to them. Systemd wants to change this by activating all sockets before it starts its daemons. The requests land in the socket buffer, where the kernel manages them.

Once the daemon is online, it processes the queue. If a client expects a response to its synchronous request, it has to wait until the daemon is running, but this step does not block other services. Because all sockets are active, dependencies between daemons are unimportant.

The plans go further, however; for example, the systemd developers, mainly Sievers, Zbigniew Jedrzejewski-Szmek, and Poettering, want systemd to handle disk management at system startup time, which involves tasks such as mounting, health checks, space management or swapping.

Additionally, the team wants to track processes via the cgroups feature in the kernel to keep an eye on services and restart them if they crash – or at least collect crash information. The intent is also for systemd to create logfiles for daemons; bind to Luks, SELinux, and PAM; manage locales; set up consoles and keyboards; and much more. His project, says Poettering, has "extended the focus of systemd somewhat." A complete list of the tasks planned for systemd is available online [10] (Figure 3).

Figure 3: In a very long table (this is only a short excerpt), Lennart Poettering lists on his blog numerous functions that systemd will assume in the future.

For many developers, the feature richness of systemd raises concern. Poettering defends his plans: He sees the project as an opportunity to abolish the various proprietary solutions and scripts used by distributions by allowing systemd to integrate new Linux features intelligently and unify the start system.

Many Linux users still adhere to the old Unix mantra of "Do one thing and do it well." Opponents accuse him of making life difficult for smaller distros that want to do without systemd by linking a range of services to his init system [11]. A number of Gentoo developers founded eudev [12], a fork of udev, after systemd integrated the udev code into its own codebase.

Poettering finds such accusations exaggerated and refutes them in his blog, but his offensive manner polarizes, and the nonchalance with which he drops what is purportedly obsolete does not necessarily suit everybody.

The project itself is harmonious, however, writes Poettering. Seventeen people have commit permission for systemd; the repository contains patches by 400 people, and 600 people are on the mailing list. All use the mailing list for communication, along with several hack festivals a year, and he regularly phones his co-developer Kay Sievers.

The systemd code is managed on Git; bugs are tracked by the Fedora bugtracker and Freedesktop.org. Currently, systemd is used by Fedora, openSUSE, Arch Linux, Mandriva, Mageia, Tizen, and Mer, a fork of MeeGo.

Although systemd packages exist for Debian, it still uses SysV init. Also, Linux Mint has not changed, maybe because Ubuntu is sticking to Upstart. Mark Shuttleworth gave his reasons for this in his blog, saying that Upstart was carefully designed and tested, along with a clear task assignment [13].