Systemd has been the controversial hot-button topic for the Linux community for the past few years. Systemd replaces the traditional System V init system and basically just redoes the whole core of the operating system. It takes over the init system, the logging system, and all of the automatic launchers for X, and just crams them into this single monolithic system. Systemd changes everything and for what? Aside from faster boot times, What does systemd give us that we didn’t have before and why are all the distros adopting it? I’ll tell you why.1
Systemd is not the first attempt at rethinking the System V init model in Unix-like operating systems. Long ago, Mac OS X wrote their own init system called launchd that provides a lot of the same features to Mac that systemd does to Linux. Around the same time Solaris replaced its init system with the System Management Facility, which did the same thing. The thing that these two systems have in common is that they replace the traditional init script written in shell with a declarative model for specifying what a daemon or other program is supposed to do. Most of the details that would originally have been written explicitly in shell for each daemon is now implemented internally by the init system. Systemd does this as well and that’s its killer feature.
Once upon a time my job entailed writing a lot of custom software for a Solaris based datacenter. I wrote a number of daemons and I got used to writing SMF manifest files for them. SMF manifests are written in a horrible XML based language, but on a whole they are much simpler to write than traditional init scripts.2 I’ve also written numerous init scripts in shell, and they’re tricky to get right if you want to do them correctly. You have to tell them where to send the logs, if you want it to restart itself you need to implement a PID file, etc. Declarative daemon description is in general much, much easier.
Now one might object, that that doesn’t seem like so much. One might say: “I’ve only needed to write a few init scripts in my life and I like the flexibility that having a full programming language at my disposal when I do so. There might be some feature I need that systemd does not handle and I’d rather implement it in shell directly in my init script rather than have to implement some kind of module so that systemd can have the necessary functionality.” I’d respond that all that might be true, but as you’re an end-user and end-users, as you say, you don’t write many init scripts. Who does write a lot of init scripts? The package maintainers for various linux distributions do. Who decides what init system to include with a given distro? Those same people.
Distributions tend to have a lot of packages. Arch Linux, for example, has upwards of 11000 packages. A lot of those packages are daemons that have their own init scripts. Very often, a distro maintainer cannot simply reuse the script that comes with the package because the default package script assumes something about the system that, while it was true on the original developer’s system or distribution is not still true on the distribution for which it is being packaged. Writing and maintaining hundreds of init scripts, each of which is its own mini program written in a language that is notoriously hard to get right is a very difficult task, to put it lightly. So it shouldn’t come as a surprise that distributions are moving towards a system that lightens this workload. The upshot is that, even if you find systemd to be the most obtuse piece of software with which you’ve ever work, the maintainers of your favorite Linux distribution will likely have more time to fix bugs not related to the init system which is a benefit to us all.