At the end of April, Lennart Poettering
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
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
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
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.
- 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
- Gentoo 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
- Ubuntu seems unlikely to consider a change anytime soon.
So it is not clear that any distribution will make the jump to systemd.
But, then, even the above is a fair amount of attention for a project which
has been public for less than one month. This program has reopened the
discussion on how our systems should initialize themselves, and things may
go on from there: there is talk of using systemd to take over the tasks of
processes like cron and gnome-session. Regardless of who
ends up running systemd, the ideas it expresses are likely to influence
development for some time.
to post comments)