The road forward for systemd

Did you know...? LWN.net is a subscriber-supported publication; we rely on subscribers to keep the entire operation going. Please help out by buying a subscription and keeping LWN on the net.

At the end of April, Lennart Poettering announced the initial availability of systemd, a new system initialization and session management daemon. This announcement caused a bit of surprise and concern for those who didn't know it was coming. Lennart's work with PulseAudio remains a bit of a difficult memory for some users (though it seems to be working well for most people now), and some people had thought that the initialization problem was solved with the growing adoption of upstart. Systemd is a different approach, though, which may yet prove sufficiently compelling to motivate another big change.

There are many new features in systemd, but the core change is a concept stolen from the MacOS launchd daemon - and from others that came before launchd . There are (at least) two ways to ensure that a service is available when it is needed: (1) try to keep track of all other services which may need it and be sure to start things in the right order, or (2) just wait until somebody tries to connect to the service and start it on demand. Traditional Linux init systems - and upstart too - use the first approach. Systemd, instead, goes for the second. Rather than concern itself with dependencies, it simply creates the sockets that system daemons will use to communicate with their clients. When a connection request arrives on a specific socket, the associated daemon will be started.

This approach simplifies the system configuration process because there is no longer any need to worry about dependencies between services. It holds out the promise of a faster bootstrap process because nothing is started before it is actually needed (plus a fair amount of other work has been done to improve boot time). The systemd approach to managing daemons allows a fair amount of boilerplate code to be removed, at least under the difficult assumption that the daemon no longer needs to work with other initialization systems. Lennart clearly thinks that it is a better way to manage system processes, and a number of others seem to agree.

That said, there are some obstacles to the widespread adoption of systemd by distributors. To begin with, a number of them are just now beginning to use upstart in its native mode; the idea of jumping into another transition is not necessarily all that appealing. Daemons must be patched to work optimally with systemd; otherwise the socket-based activation scheme is not available. The patching is a relatively simple task, but it must be done with a number of daemons and the result accepted back upstream. There are also concerns about how well some types of services (CUPS was mentioned) will work under systemd, but Lennart seems to think there will not be troubles there.

Another area of concern, strangely enough, is the use of control groups (cgroups) by systemd. Cgroups are a Linux-specific feature initially created for use with containers; they allow the grouping of processes under the control of one or more modules which can restrict their behavior. Systemd uses cgroups to track daemon processes that it has created; they allow these processes to be monitored even if they use the familiar daemon tricks for detaching themselves from their parents. So if systemd is told to shut down Apache, it can do a thorough job of it - even to the point of cleaning up leftovers of rogue CGI scripts and such.

Cgroups would also make it easy for system administrators to set up specialized sandboxes for daemons to run in. The problem there is that there is no easy way for systemd to pick up a cgroup setup already created by somebody else; there is no transparent inheritance for cgroups now. So Lennart is asking for that type of inheritance to be added.

Beyond that, though, some people have concerns about the use of cgroups in the first place. Peter Zijlstra worries about adding yet another feature which must be built into the kernel for the system to even boot. The Debian community does not like the use of the "debug" group, which is not currently configured into its kernels. Systemd may eventually get a more appropriately-named cgroup subsystem for its use, but it is not going to work without the cgroup feature at all. So people wanting to boot systems with systemd will need to have cgroups built in. Lennart has this message for people who don't like that:

Next time something is added to the kernel please mark it as "Hey, please don't use it, this is only here so that you don't use it. Thanks!" Maybe then dumb-ass folks like me will notice and refrain from using it.

There are also claims that work on systemd is primarily motivated by antipathy toward Ubuntu and, especially, its copyright assignment policies. There can only be a bit of truth in some of that; hearing early talk about the work which became systemd is part of what inspired this article on assignment policies back in October. That said, Lennart insists that the motivations behind systemd are technical, and he asks that it be judged on its technical merits.

So where do things stand with regard to adoption of systemd?

There is an intent to package bug filed for Debian ; the packager plans to make it easy to switch between sysvinit and systemd at boot time.

; the packager plans to make it easy to switch between sysvinit and systemd at boot time. Lennart plans to have a systemd package ready for Fedora 14, saying " whether we can have it as default is to be seen ". Given that the Fedora 14 cycle has already begun, even thinking about adding a change that fundamental as the default seems ambitious. So it may be a hard sell, but Lennart would like to see it: " It would certainly be a shame though if other distros would ship systemd by default before we do. "

14, saying " ". Given that the Fedora 14 cycle has already begun, even thinking about adding a change that fundamental as the default seems ambitious. So it may be a hard sell, but Lennart would like to see it: " " Gentoo has an experimental systemd package available, but it has not found its way into the main distribution yet.

has an experimental systemd package available, but it has not found its way into the main distribution yet. openSUSE is apparently (according to Lennart's original announcement) discussing it internally, but, as is often the case with openSUSE, there is no public indication that it is being considered.

is apparently (according to Lennart's original announcement) discussing it internally, but, as is often the case with openSUSE, there is no public indication that it is being considered. Ubuntu seems unlikely to consider a change anytime soon.