Sys­temd has been the con­tro­ver­sial hot-but­ton topic for the Linux com­mu­nity for the past few years. Sys­temd replaces the tra­di­tional Sys­tem V init sys­tem and basi­cally just redoes the whole core of the oper­at­ing sys­tem. It takes over the init sys­tem, the log­ging sys­tem, and all of the auto­matic launch­ers for X, and just crams them into this sin­gle mono­lithic sys­tem. Sys­temd changes everything and for what? Aside from faster boot times, What does sys­temd give us that we did­n’t have before and why are all the dis­tros adopt­ing it? I’ll tell you why.¹

Sys­temd is not the first attempt at rethink­ing the Sys­tem V init model in Unix-­like oper­at­ing sys­tems. Long ago, Mac OS X wrote their own init sys­tem called launchd that pro­vides a lot of the same fea­tures to Mac that sys­temd does to Lin­ux. Around the same time Solaris replaced its init sys­tem with the Sys­tem Man­age­ment Facil­i­ty, which did the same thing. The thing that these two sys­tems have in com­mon is that they replace the tra­di­tional init script writ­ten in shell with a declar­a­tive model for spec­i­fy­ing what a dae­mon or other pro­gram is sup­posed to do. Most of the details that would orig­i­nally have been writ­ten explic­itly in shell for each dae­mon is now imple­mented inter­nally by the init sys­tem. Sys­temd does this as well and that’s its killer fea­ture.

Once upon a time my job entailed writ­ing a lot of cus­tom soft­ware for a Solaris based dat­a­cen­ter. I wrote a num­ber of dae­mons and I got used to writ­ing SMF man­i­fest files for them. SMF man­i­fests are writ­ten in a hor­ri­ble XML based lan­guage, but on a whole they are much sim­pler to write than tra­di­tional init scripts.² I’ve also writ­ten numer­ous init scripts in shell, and they’re tricky to get right if you want to do them cor­rect­ly. You have to tell them where to send the logs, if you want it to restart itself you need to imple­ment a PID file, etc. Declar­a­tive dae­mon descrip­tion is in gen­eral much, much eas­ier.

Now one might object, that that does­n’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 flex­i­bil­ity that hav­ing a full pro­gram­ming lan­guage at my dis­posal when I do so. There might be some fea­ture I need that sys­temd does not han­dle and I’d rather imple­ment it in shell directly in my init script rather than have to imple­ment some kind of mod­ule so that sys­temd can have the nec­es­sary func­tion­al­i­ty.” 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 pack­age main­tain­ers for var­i­ous linux dis­tri­b­u­tions do. Who decides what init sys­tem to include with a given dis­tro? Those same peo­ple.

Dis­tri­b­u­tions tend to have a lot of pack­ages. Arch Lin­ux, for exam­ple, has upwards of 11000 pack­ages. A lot of those pack­ages are dae­mons that have their own init scripts. Very often, a dis­tro main­tainer can­not sim­ply reuse the script that comes with the pack­age because the default pack­age script assumes some­thing about the sys­tem that, while it was true on the orig­i­nal devel­op­er’s sys­tem or dis­tri­b­u­tion is not still true on the dis­tri­b­u­tion for which it is being pack­aged. Writ­ing and main­tain­ing hun­dreds of init scripts, each of which is its own mini pro­gram writ­ten in a lan­guage that is noto­ri­ously hard to get right is a very dif­fi­cult task, to put it light­ly. So it should­n’t come as a sur­prise that dis­tri­b­u­tions are mov­ing towards a sys­tem that light­ens this work­load. The upshot is that, even if you find sys­temd to be the most obtuse piece of soft­ware with which you’ve ever work, the main­tain­ers of your favorite Linux dis­tri­b­u­tion will likely have more time to fix bugs not related to the init sys­tem which is a ben­e­fit to us all.

1. Or my version of why anyway. I haven’t read all of the discussions. ↩
2. They are also optional; you can configure your service through a number of CLI commands and never have a concrete file or script to handle your service, but that’s just sugar on a doughnut. ↩