When it comes to Linux and systemd, the one thing on which everyone can agree is that it’s complicated — some say overly complicated.
Devuan, the Debian fork without systemd, has a page called Init Freedom on its site. At first the title seems ridiculously over-dramatic, because freedom in free software generally refers to licensing and not to software itself, and feels out of place in a discussion of init systems. Here, however, the title seems to refer to the conviction that systemd was foisted upon unsuspecting users by a distro elite, especially in Debian.
Although the topic of systemd is often met with profound indifference in some circles, I confess to deep-seated ambiguity whenever the topic is raised. Moreover, the more I research, the deeper my ambiguity grows, although in the end I finally reached a position.
I generally ignore the claims that systemd is part of Red Hat’s long-range conspiracy to dominate the Linux desktop. Although Red Hat occasionally makes a gesture towards the desktop, it mostly appears to be indifferent to it. Anyway, how would you prove such a conspiracy exists? The closest I can find to evidence is the way that GNOME Boxes lists Fedora releases out of order and at the top of the list of distros to run in a virtual machine — which is a pretty feeble piece of evidence.
Likewise, I ignore the rejection of systemd that amounts to a hate campaign against Lennart Poettering, its chief original developer, even though like countless other Linux users I have had many occasions to curse Poettering’s other best known project, PulseAudio. In addition, as Linus Torvalds complained, Poettering has sometimes been slapdash about fixing bugs and usually sounds high-handed. However, much of the hatred against Poettering is homophobic, which means that it automatically disqualifies itself from serious discussion.
Once I turn to design considerations and technological benefits, however, I quickly bog down. The Unix philosophy of one utility to do one thing very well sounds admirable in theory, and perhaps on the administrative level it works well. Yet, I have heard few if any complaints that large apps like SE Linux or AppArmor violate the Unix philosophy, and on the desktop, apps like LibreOffice or Krita are clear violators. Could it be that some projects require a different approach to be effective?
As a user, my initial tendency is to applaude Init Freedom’s rejection of “this one-size-fits-all vision” that led to the general acceptance of systemd in the major distributions. Yet as I think further, I wonder how practical supporting multiple init systems might be.
In the recent Debian general resolution on systemd, both sides maintained that expecting maintainers to support multiple init systems would seriously add to the task of keeping packages current. The Devuan project itself appears to illustrate the difficulty, since it still uses Debian 9 as its basis and so far has been unable to add multiple init support itself. When finding maintainers is a constant problem for many distros, perhaps a limit on the number of supported init systems is sheer practicality.
My uncertainty continues when I start learning more about the technical aspects of systemd. My fellow Progeny alumni and Debian maintainer, John Goerzen, says “I don’t agree with every design choice they’ve made” in systemd. For instance, he states that “the learning curve is somewhat higher, what with files being spread out across /lib and /etc and the interactions between them sometimes complicated.”
Yet, he has no trouble mentioning some of systemd’s benefits:
- Systemd timers, for instance, can help avoid the thundering herd problem that one might otherwise see with their RandomizedDelayStart. They also have several other features that make them more useful than cron jobs in some situations.
- For daemons, the service monitoring and restart is quite helpful. The dependency ordering is more expressive and reliable than what we had in sysvinit, particularly in situations involving complex ordering of filesystem mounts (certain NFS scenarios were a thorn in people’s side for ages with sysvinit).
- Journalctl shows useful information, especially for daemons that crash or exit without logging to syslog. It also simplifies development of simple new daemons, which can just log to stdout if they don’t have copious output to produce.
He concludes that, “while systemd doesn’t strictly provide things that were impossible before, it streamlines a lot of things. [For instance] we no longer need to have separate watchers for most daemons [and] don’t have to write random delays into cron jobs.” His assessment sounds much like that of someone who has no particular stake in systemd, yet who has learned to live with it.
Still, what strikes me is Goerzen’s reservations. Systemd is a layer overlaid on an already working operating system. From what I have been told, it requires numerous small patches to integrate with the existing system — and in my experience, increased complexity means more space for things to go wrong. Asked for an opinion, developer Christopher Smith gave the opinion that systemd “became overly ambitious/complex. On the security front in particular, it seems to be the source of problems at least as much as the solution.” A search shows that memory leaks in particular have been a problem.
More importantly, I find that lists like Goerzen’s tend to focus on benefits for programmers, not for average users. Less knowledgeable users like me, who maintain only a few machines at home, generally use systemd only to start and stop services, to check their statuses, or read an occasional log — and for such purposes, systemd is serious overkill. I can get what I need from a more dedicated init system like runit, which is quicker to learn and has little beyond those basic options that I might actually use.
To my way of thinking, that’s the strongest argument against systemd. For average users, it has far more overhead than it needs. In that respect, it resembles SE Linux on Fedora, offering sophistication that is not needed and creating problems that should not be there. It does not seem like something that should be installed by default on every system.
Systemd seems to be here to stay for those who run major distributions. Still, it first appeared almost a decade ago, so its time may be drawing to an end in a few years. Just as projects like PipeWire stand ready to replace PulseAudio, many of the alternatives listed on Init Freedom already offer alternatives to systemd. If systemd irks you sufficiently, you can easily try several of these alternatives on a live DVD. Otherwise, the solution may be to wait patiently until a more efficient consensus emerges.