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, an abhorrent and violent 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.
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, and other things. Keep it simple, stupid.
- 2. systemd's journal files (handled by journald)
are stored in a complicated binary format2, 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? Ignore it.
Oh, and there's embedded HTTP server integration (libmicrohttpd).
QR codes are served, as well, through libqrencode.
- 3. systemd's team is noticeably chauvinistic and anti-Unix, due to their open disregard for non-Linux software and subsequent systemd
incompatibility with all non-Linux systems. Since systemd is very tightly welded with the Linux kernel API, this also makes different
systemd versions incompatible with different kernel versions. This is an isolationist policy that essentially binds the Linux ecosystem
into its own cage, and serves as an obstacle to software portability.
- 4. udev and dbus are forced dependencies. In fact,
udev merged with systemd a long time ago3. The integration of the
device node manager that was once 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.
- 5. By default, systemd saves core dumps to the
journal, instead of the file system. Core dumps must be explicitly
queried using coredumpctl4. Besides going against all
reason, it also creates complications in multi-user environments
(good luck running gdb on your program's core dump if it's dumped
to the journal and you don't have root access), since systemd
requires root to control. It assumes that users and admins are
dumb5, but more critically, the fundamentally corruptible nature
of journal logs makes this a severe impediment.
- 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 20106. 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
- 7. systemd is viral by its very nature. 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 has adopted systemd as a hard dependency
since 3.8 for various utilities, including gdm, gnome-shell and gnome-extra-apps7. This means GNOME versions >=3.8 are incompatible with non-Linux
systems, and due to GNOME's popularity, it will help tilt a lot of maintainers to add systemd. 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 weston, 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 coercion8.
- 8. systemd clusters itself into PID 1. Due to it controlling lots of different components, this means that there are tons of scenarios in which it can crash and bring down the whole system.
But in addition, this means that plenty of non-kernel system upgrades will now require a reboot. Enjoy your new
Windows 9 Linux system!
In fairness, systemd does provide a mechanism to reserialize and reexecute systemctl in real time. If this fails, of course, the system
goes down. There are several ways that this can occur9. This happens to be another example of SPOF.
- 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 execing scripts.
- 11. Ultimately, systemd's parasitism 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 vehemently postmodern, monolithic, heavily desktop-oriented, choice-limiting, isolationist,
reinvents the flat tire, and 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
- 12. systemd doesn't even know what the fuck 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
 https://web.nvd.nist.gov/view/vuln/search-results?adv_search=true... [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).