(…) So, get yourself a copy of The Linux Programming Interface, ignore everything it says about POSIX compatibility and hack away your amazing Linux software. It’s quite relieving!
systemd is wrong on so many levels I hardly know where to start. Perhaps its single most important design fault is that it was conceived with a blatant disregard for servers. The author’s manifesto and the “systemd for admins” series provide good insight into his motives for designing systemd.
He goes on and on about how you can save 3 seconds here and 5 seconds there by parallel and delayed service startup – systemd actually has a feature to measure system boot time. The question is: who cares? Desktop users, yes. Embedded users, maybe. Server users? Nope. It doesn’t matter if a server comes up in 96.3 seconds instead of 33.1. What counts is if it stays up and is not too cumbersome to maintain.
So how are systemd’s goals achieved? Basically, by throwing well-proven Unix paradigms out the window and clearly admitting it. Yes, Unix was designed 42 years ago. And no, it’s not broken. I’m not a die-hard traditionalist nor am I even that reluctant to adopt new solutions, but Unix stays the single most successful server OS design in the world for a reason – still used today in various forms after those 42 years. It’s simple, elegant and it works. The mainstay of its design is simplicity and modularity. One program for one task; easy interconnection between programs. Yet we are expected to ditch all that for something new and shiny.
One of the design goals of systemd is to get rid of shell scripts in the boot process and… rewrite everything in C, as the author doesn’t seem to be very fond of grep being called 77 times and awk 92 times during his system boot. Now, why do we have shell scripts in the boot process? They’re simple. They’re easy to read. Every single competent un*x admin knows at least the basics of shell scripting. There is almost complete control over the entire boot process and anything can be changed in a few seconds. Of course, one can argue it’s almost as easy to change systemd’s C code, recompile and reinstall. I’ll let you on a little secret: when do you usually need to change something in the boot process? When something doesn’t work right. No matter if you’re comfortable at your desk with your triple 30″ screens or in the
trenches data center after an all-nighter gone horribly wrong – you need to fix the problem pronto. The last thing you want to worry about is instrumenting, debugging and rebuilding C code at the core of your OS.
The second design goal seems to be incredible and unwarranted intentional complexity. The single most important process in the userland is supposed to be clean, small and efficient. Let’s take a look what systemd is supposed to supervise:
restarting processes after they crash. sysvinit doesn’t do that and we don’t have restartd or a thousand other programs for it. Oh, wait…
collecting information on daemon crashes. Nowadays most daemons have their own crash report formats, logging to syslog, stderr, directly to text log files, to binary dumps, etc. Good luck making the authors conform to a single standard. And good luck with all the corner cases.
keeping control (via cgroups) over processes detached from their parents. But for that we already have, well… cgroups?
delayed/on-demand service startup. “on most machines where sshd might be listening somebody connects to it every other month or so.” says the author. On a workstation – maybe. How much RAM are you going to save by delaying the startup of a few daemons? If they’re unused, they’ll be swapped out anyway. To support on-demand startup of network services, yet another functionality already available elsewhere had to be implemented within systemd: inetd.
dependency based service management. To the author, dependency based management is redundant. The problem is, every boot process is dependency based. Think services, not processes. Your services depend on their filesystems having been mounted, the filesystems depend on the underlying devices having been initialized, and so forth. We’ve already had rudimentary dependency based service management in System V!
S31fancydand S31foobar depended on
S30whatsitfor setup. At teardown, only with
K10fancyddown could the system proceed with
K20whatsit. Servers are unlike desktops in that server boot time counts from the moment you press the big red button to the moment that server actually starts providing all its services. Or in other words: if you’re waiting, who cares if it’s in parallel or in series? It doesn’t matter if e.g. ftpd is allowed to start before
/home/ftpis mounted and files can be served. Besides, an administrator may choose to stop
S31fancyd– and he or she probably knows what they’re doing. It’s much harder to force service actions with systemd: you end up constantly fighting its decisions.
systemd creates autofs mount points and starts daemons before their filesystems are available (obviously, fs operations will block until then). Sounds horrible, right? This is going to be an administration nightmare. There is no way to do autofs right. If anything goes wrong with the underlying I/O or autofs itself, you’re left with an unusable system. Even on Solaris, which arguably has the most reliable automounter implementation available. Incorporating autofs into PID 1 and the boot process (and hanging services off it) guarantees problems.
listening to hardware changes introduces potential stability and security issues – and there already are [more or less] working facilities acting on hardware events.
communication via D-Bus. D-Bus is _very_ desktop-oriented. It’s not called Desktop Bus for nothing. It’s designed for portability – not speed, reliability or simplicity. There are dozens of simple, robust message passing and IPC protocols, but this is by far one of the most complicated, perhaps second only to CORBA/IIOP. Instead of letting this abomination die, or at least stay confined to the desktop, it’s actually going to be incorporated into the boot process. Daemon developers are encouraged to use it. Let’s put it in the kernel while we’re at it.
systemd is overcomplicated and bloated with unnecessary features, almost as if someone was trying to implement a second kernel in userland. It looks like it was designed by someone who never saw anything else than their own workstation. It’s a nice exercise in self-managing systems, with its kitchen sink approach it’s certainly worth a look by desktop/embedded vendors as an alternative to sysvinit or in-house inits, but that’s it.
Linux userland boot process should be reviewed and cleaned up in most major distributions, perhaps even standardized (not necessarily, though – we currently have about four major userland boot systems, all in major distros – some diversity here is actually welcome).
However, systemd is not the way to go. It would set us back a decade. Let’s hope it doesn’t catch on – just like upstart or the first implementation of devfs back in 2000. It’s hardly surprising how many people are drinking the kool-aid – systemd offers a lot of lofty promises. With Red Hat’s financial backing and all the propaganda (I can’t even call it PR), it’s going to be an arduous fight, but remember: after all upstart made it into Ubuntu; devfs even made it into the kernel. Not all hope is lost.