UNIX init systems are not a topic people discusses a lot about, usually. There is some buzz when a new one is out, some more buzz when it is adopted in other shops than those where it was born, then most OS keep on with their old solution (usually the System V init system, or sysvinit) and everything falls back to radio silence. Other times, I assume, things cut short from some buzz and directly into the radio silence phase. I’ve been into the Upstart buzz, before that I’ve been into the Solaris SMF buzz and even played with it until our friend OpenSolaris was mercilessly killed by their new father. But, honestly, the heated arguments about systemd took my by surprise.

I really don’t know how I had not heard about systemd before. Maybe I was just looking in another direction, or maybe the fact that it was so controversial suggested systemd’s detractors not to talk about it in the hope that it would be yet another of those attempts that cut short from their offspring to radio silence. I don’t know. Anyway, it didn’t go that way. To me, it’s like systemd flew steadily under the radar and kept growing until the Debian project decided to adopt it as their init system. My brain just filtered the news as yet another thing I could safely ignore for the moment and I’ll have to learn about when it comes. And then the sky fell down.

What happened after that announcement was kind of the burst of a religious war, with people debating harshly, insulting each other, death threats spewed here and there, people resigning from their role in important organizations. Then came the Devuan fork of Debian. For now.

A bit too much for “just another init system”, right?

What follows is the outcome of my Christmastime readings about systemd and my own considerations about what I’ve read. I hope it will help you make up your own opinion on whether or not systemd is a good thing or a bad thing. As an extra, you can read my own opinion (for what is worth).

The origin

I don’t know for how long sysvinit has been around, if it existed before System V itself (by another name) or not. But if it was introduced by System V itself, then it’s more than 30 years old, it’s gone through the long battle System V vs BSD style and, according to Wikipedia, the battle was slowly set by cross-breeding between the two systems and with the advent of POSIX and Linux.

When someone puts their hands to change something that is so widely used and consolidated that has been around for 30 years, there must be a good reason. To me, it happens because the old thing is becoming a hindrance to the evolution of the surrounding ecosystem, or because a revolution is required to make a bigger evolutionary step, breaking the linearity of the “normal” evolution process (because, like it or not, evolution is not linear if you look at it as a whole).

According to Lennart’s post “Rethinking PID 1” dating back to April 30th, 2010, it was time for such a revolution to happen in Linux. So he started writing a new init system that was faster and more efficient than System V’s.

To do so he follows two lines of optimization. The first line is to reduce the number of short-lived processes that are forked over and over by sysvinit scripts. As you know, sysvinit starts/stops services by using shell scripts that live in /etc/init.d (usually) and are sym-linked in a number of /etc/rc*.d directories (usually), one per each runlevel offered by the system. Script often get the information they need by means of sourcing external files, running system commands and parsing the output with sed, awk and the like, where each command that is run will spawn a new, short lived process. His solution is to replace the shell scripts with small, self-contained programs written in C.

The second line of optimization is parallelization: he would parallelize the start-up of processes and services wherever possible and as much as possible. In order to do so efficiently, he makes init make the system believe it has started all services, but it would actually start them only on demand. You can read his post for more detail, but even now you are probably understanding that in order to “stage” a state of the system that is not actually true it has to have more control on many more things than the simple sysvinit has. To pretend that a process is servicing a socket, it has to create the socket, monitor it, and start up the real process as soon as another one tries to get information from that socket. To pretend that a filesystem is mounted, it has to watch for requests for items in that filesystem and mount it as soon as it is requested. To shut down a service in full, including all processes that were spawned by that service and forked away of the parent’s control, it has to keep track of all processes spawned for the service. It’s not just starting or stopping services in a given order. There is much more.

How does one achieve that? The solution implemented in systemd makes use of unique Linux features, like cgroups, and gets out of POSIX constraints.

systemd today

Fast forward to 2015. The current state of systemd is summarized in Wikipedia. If you compare the blog post and the article you’ll notice how systemd has grown a lot, adding more components to allow for more functionality and more control over the system. Besides the initialization/shutdown of the system, it manages event logging (journald, not mandatory as of today, syslog-ng or rsyslog can be used instead), logins (logind, replaces ConsoleKit that is not maintained any more), parts of the network configuration (networkd), system time and time-related settings (timedated), and has swallowed udev (udevd, libudev). It has been adopted as the default init system by the Arch, CoreOS, Fedora, Mageia, OpenSUSE, Red Hat Enterprise, SUSE Enterprise Server Linux distributions; will be the default init system in Debian Jessie and is planned to be the init system in Ubuntu, too.

My opinion

Before reading my take on the systemd argument I’d recommend you do two things:

• first: please do read Lennart’s blog post and the Wikipedia page for systemd and make your own opinion at least from those two pages (that’s what I did and that’s why I wrote this post); do it before or after reading this but do it;
• second: please be aware of this principle of mine: “it doesn’t happen often that there is only one right solution to a problem“

That said…

What I like in systemd is the basic idea of making a new init system that is more efficient than our old pal sysvinit. I acknowledge the need to do that in a revolutionary way rather than evolutionary. I understand that it’s not easy to reach the goals of the project without “disrupting” sysvinit and making something very different.

On the other hand, I don’t like the idea of replacing shell scripts with C programs, trading simplicity for efficiency to the extreme: I am fine with the optimization offered by parallelizing start-up more, not with making the boot process more difficult to debug and tinker with. And I don’t like that all the optimizations in systemd are done so Linux-centrically and in total disregard of POSIX, compatibility and portability. That makes Linux an island of its own by making it more complicated to port programs from Linux to other platforms and vice versa, as it adds a big, “low-level” subsystem that can’t just be ignored. And, finally, I don’t like it’s being so big and comprehensive to resemble an OS in the OS by “stealing” functions out of it.

Where I will go from here

Well, for good or bad it may be, I have to learn systemd, there is no choice.

Secondly, I guess that I should take action and not just say something. The problem is that I stand for neither systemd nor sysvinit. Nor I support efforts done against something, I’d rather like to support a project made to genuinely create a better, viable init system that aims to be standard across all UNIX flavours, for the benefit of everyone. Any existing project I should watch? Suggestions welcome.

Religious wars image from http://blog.codinghorror.com/are-you-there-god-its-me-microsoft/