“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.”
The road forward for systemd
By
Jonathan Corbet
Get the Free Newsletter!
Subscribe to Developer Insider for top news, trends, & analysis