Check out the uselessd project for a saner systemd base.
systemd0 is a replacement for
the sysvinit daemon used in GNU/Linux and Unix systems, originally
authored by Lennart Poettering of Red Hat. It represents a monumental
increase in complexity, a slap in the face to the Unix philosophy, and
its inherent domineering and viral nature turns it into something akin
to a "second kernel" that is spreading all across the Linux ecosystem. This
site aims to serve as a rundown and a wake-up call to take a stand
against the widespread proliferation
of systemd, to detail why it is harmful, and to persuade users to
reject its use, and especially its
Disclaimer: We are not sysvinit purists by any means. We do recognize the need for a new init system in the 21st century, but
systemd is not it.
- 1. systemd flies in the face of the Unix
philosophy: "do one thing and do it well," representing a complex
collection of dozens of tightly coupled binaries1. Its
responsibilities grossly exceed that of an init system, as it goes
on to handle power management, device management, mount points,
cron, disk encryption, socket API/inetd, syslog, network
configuration, login/session management, readahead, GPT partition
discovery, container registration, hostname/locale/time
management, mDNS/DNS-SD, the Linux console and other things all
wrapped into one. The agenda for systemd to be an ever-growing and
invasive middleware for GNU/Linux was elucidated in a 2014 GNOME
Asia talk2. Keep it simple, stupid.
2. systemd's journal files (handled by journald) are stored in a
complicated binary format3, and must be
queried using journalctl. This makes journal logs potentially
corruptible, as they do not have ACID-
compliant transactions. You typically don't want that to happen to
your syslogs. The advice of the systemd developers?
The only way to generate traditional logs is to run a standard syslogd
like rsyslog alongside the journal4.
There's also embedded HTTP server integration (libmicrohttpd). QR codes are served, as well, through libqrencode.
- 3. Since systemd is very tightly welded with the
Linux kernel API, different systemd versions are incompatible with
different kernel versions and portability is unnecessarily
hampered in many components. This is an isolationist policy that
essentially binds the Linux ecosystem into its own cage, serving
as an obstacle to developing software portable with both Linux
variations and other Unix-like systems. It also raises some issues
backporting patches and maintaining long-term stable systems.
4. udev and dbus are forced dependencies. In fact, udev merged
with systemd a long time ago5. The integration of the device node
manager, which was once a part of the Linux kernel, is not a
decision that is to be taken lightly. The political implications
of it are high, and it makes a lot of packages dependent on udev,
in turn dependent on systemd, despite the existence of forks, such
as eudev. Starting with systemd-209, the developers now have their
own, non-standard and sparsely documented sd-bus API that replaces
much of libdbus's job, and further decreases transparency.
Further, they intend to migrate udev to this new transport,
replacing Netlink and thus making udev a systemd-only
effects of this move are profound.
5. systemd features a helper which captures coredumps and directs
them either to /var/lib/systemd/coredump... or the journal, where
they must be queried using coredumpctl7. The latter behavior was a
default and is likely to return8. It assumes that users and admins
are dumb9, but more critically, the fundamentally corruptible
nature of journal logs makes this a severe impediment, and an
irresponsible design choice. It can also create complications in
multi-user environments related to privileges.
- 6. systemd's size makes it a single point of
failure. As of this writing, systemd has had 9 CVE reports, since
its inception in March 201010. So far, this may not seem like that
much, but its essential and overbearing nature will make it a
juicy target for crackers, as it is far smaller in breadth than
the Linux kernel itself, yet seemingly just as critical.
7. systemd is viral by its very nature, due to its auxiliaries
exposing APIs, while being bound to systemd's init. Its scope in
functionality and creeping in as a dependency to lots of packages
means that distro maintainers will have to necessitate a
conversion, or suffer a drift. As an example, the GNOME
environment often makes use of systemd components, such as logind,
and support for non-systemd systems is becoming increasingly
difficult. Under Wayland, GNOME relies on logind, which in turn
requires and is a part of systemd11. More and more maintainers are
going to require systemd for this reason, and similar instances
like it. The rapid rise in adoption by distros such as Debian,
Arch Linux, Ubuntu, Fedora, openSUSE and others shows that many
are jumping onto the bandwagon, with or without justification.
Other dependent packages include the Weston compositor, Polkit,
upower, udisks2, PackageKit, etc. It's also worth noting that
systemd will refuse to start as a user instance, unless the system
boots with it as well - blatant coercion12.
8. systemd clusters itself into PID 1, rather than acting as a
standalone process supervisor. Due to it controlling lots of
different components, there are tons of scenarios in which it
can crash and bring down the whole system. We should also
mention that in order to reduce the need for rebooting, systemd
provides a mechanism to reserialize and reexecute systemctl in
real time, however, if this fails, of course, the system goes
down. There are several ways that this can occur13, including an
inability to reload a previous, potentially incompatible state.
This happens to be another example of SPOF and an unnecessary
burden on an already critical component (init).
- 9. systemd is designed with glibc in mind, and
doesn't take kindly to supporting other libcs all that
general, the systemd developers' idea of a standard libc is one
that has bug-for-bug compatibility with glibc.
10. systemd's complicated nature makes it harder to extend and
step outside its boundaries. While you can more or less trivially
start shell scripts from unit files, it's more difficult to write
behavior that goes outside the box, what with all the feature
bloat. Many users will likely need to write more complicated
programs that directly interact with the systemd API, or even
patch systemd directly. One also needs to worry about a much
higher multitude of code paths and behaviors in a system-critical
program, including the possibility of systemd not synchronizing
with the message bus queue on boot, and thus freezing. This is as
opposed to a conventional init, which is deterministic and
predictable in nature, mostly just serially execing scripts.
11. Ultimately, systemd's spread is symbolic of something more
than systemd itself. It shows a radical shift in thinking by the
Linux community. Not necessarily a positive one, either. One that
is heavily desktop-oriented, choice-limiting, isolationist,
reinvents the flat tire, and is just a huge anti-pattern in
general. If your goal is to pander to the lowest common
denominator, so be it. We will look for alternatives, however.
12. systemd doesn't even know what it wants to be. It is
variously referred to as a "system daemon" or a "basic userspace
building block to make an OS from", both of which are highly
ambiguous. It engulfs functionality that variously belonged to
util-linux, wireless tools, syslog and other projects. It has no
clear direction, other than the whims of the developers
themselves. Ironically, despite aiming to standardize Linux
distributions, it itself has no clear standard, and is perpetually
External Resources and References
[truncated; not all entries apply]
Articles critical of systemd
(The author took this article down because of us. Read the details here.)
What You Can Do
Boycott distros that use systemd.
Spread word of this web page.
Contribute to and use distros like Slackware, CRUX, Funtoo, and Gentoo that follow traditional Unix paradigms.
systemd alternatives include runit, OpenRC, s6, monit, perp, supervisord, Upstart, nosh and GNU dmd.
Note that not all of these are meant as replacements for initd, specifically, even if they can theoretically be hacked in to be. Some are specifically designed for the task of process supervision and monitoring.
Consider migrating to *BSD, Plan 9 or something similar, if things get really out of hand.
Make an xBill mod that replaces Bill Gates' sprite with that of our great overlord Lennart Poettering. Maybe.
Research, work on and promote reimplementations of common systemd interfaces (hostnamed, localed, timedated, etc.) and their D-Bus APIs, which will facilitate running applications that depend on them, without the host system having to use systemd as its PID1. An OpenBSD GSoC developer is currently working on OS-agnostic, BSD-licensed replacements, which will likely prove the most viable. In the meantime, take a look at Gentoo's OpenRC-settingsd, as well as Canonical's systemd-shim and ubuntu-system-service. For udev alternatives, see Gentoo's eudev and Busybox's mdev (source).