So I read Lennart’s blog post entitled Why systemd?. In it, he makes a number of comparisons between systemd and the two other Linux init systems that are still in widespread use (this being the third init system some distributions have adopted within the last few years). Overall, he makes a good argument that systemd has many nice and exciting features, and I’m sure they are of interest to various people who want their init system to be SYSV on steroids. Here are some of them:
- Interfacing via D-BUS
- Shell-free bootup
- Modular C coded early boot services included
- Socket-based Activation
- Socket-based Activation: inetd compatibility
- Mount handling
- fsck handling
- Quota handling
- Automount handling
- Swap handling
- Encrypted hard disk handling (LUKS)
- Infrastructure for creating, removing, cleaning up of temporary and volatile files
- Save/restore random seed
- Static loading of kernel modules
These are all things I don’t want built into my init system. To me, there are many good reasons that they have been traditionally handled using simple, easy to edit and modify scripts, and that’s where I personally feel they should belong. In my mind, some don’t even make sense to build directly into the init system itself, such as automounting and the like (that belongs in autofs and friends). There’s more, but the main point I want to make here is that when you come up with a list of comparisons, that list should not really be an inverted list of features of the replacement (which obviously may not be in what is being replaced). A better comparison would be user experience. If I’m an admin, all of the new features are nice, but do I need to change my workflow for the new tool? And at the end of the day, what am I winning overall in terms of experience?
I’m not one of those who actually wanted YAIS (Yet Another Init System). No offence particularly to systemd, but I preferred good old fashioned sysvinit. It worked for longer time than many people have been using Linux (or UNIX), it was well understood, and well documented. It was far from perfect, but it got system services started. I can’t remember ever yelling at SYSV init and saying “wow, if only you weren’t so crappy, if only you started every service when I connected to it”. In fact, it was a mature tool that did everything I needed it to. It took a little longer to boot my system than it might, but then like most real users, I use suspend and other features that mean I boot from scratch infrequently, or I run servers where I really don’t care at all. I wouldn’t have cared if it took 10 minutes to boot my laptop, or an hour to boot my server…well, I exaggerate, but you get the point. And inetd? Or xinetd? Automount? Good enough for my uses as separate tools.
Jon.
I think you should read the rest of lennart’s blog posts. He raises valid points about what’s wrong within sysvinit (for instance it doesn’t kill services the right way) and he has written I believe 5 blog posts relevant for sysadmins.
Oh man.
I am sure you are happy to learn that 8 of the items you list are not done in PID 1, but just in small services shipped along with systemd.
I like your wise comments on systemd, without actually having had a close look. That’s uninformed FUDing.
“simple, easy to edit” scripts? Really? You must be running a different Fedora or RHEL than I am running.
Well, while sysv work fine since a long time, so would we say about Windows. On a engineering point of view, replacing initscript by something simpler to administer ( systemd unit are cleaner and easier to read/write ) is a big advantage. I remember yelling at the initscripts system because it was so much composed of cut and paste everywhere, because people had varying degree of understanding of the shell scripting, etc. I also often found that having to kill process by hand was rather unsatisfying and fragile.
Maybe systemd do too much. But I think there is a logical reason to unify the boot process like systemd does.
Oh yes, we can’t blame sysv very much because it doesn’t do much at all, all we can blame is a badly written script. But the best part in systemd is that it makes it possible to standardize all distros which in many cases modify their scripts etc.
As is the case with hal, systemd uses all best stuff linux has, there is no point in being generic and crappy but work everywhere. Systemd might ease a lot of administration leaving more for proper coding
Everyone want to forget the init process itself is a block of C code even with system V. It is in charge of shutting the system down. That init command you run to change run levels under system V sends a message to process 1 on the system. dbus is just a different way and more friendly way todo IPC messages. Interfacing by dbus nothing different really.
“Modular C coded early boot services included.” Did you not read this.
Systemd main source codes include the features todo Mount handling down. But big but these are independent modules. So can be replaced or removed.
Merging in of inetd kinda came a requirement due to how systemd operates.
xinetd/inetd was the first Socket-based Activation system. systemd is the next generation with many improvements so every service can take advantage of xinetd/inetd activation on demand idea even if they are not designed to be xinetd/inetd compatible with systemd. This is why xinetd/inetd cannot mix with systemd. They both will want to be monitoring the same things.
mount handling also falls into mount based Activation. Service has started up it goes to use a partition that is not mounted yet. So systemd suspends it until that is mounted.
The deeper you dig systemd is an Activation based system. Something completely different in a lot of ways to sys v init system. It is basically impossible todo a full activation based system inside the system v model. Also none of the YAIS (Yet Another Init System) ever has been a fully activation based system. Systemd closest living relation is launchd from OS X. Launchd is only partly in the direction of Activation based system.
Activation based system is not an Init system really either. Activation based systems keep on working away after the system has started up.
Encrypted hard disk handling (LUKS) is a good example of this in systemd it handles encrypted harddrives on startup also if you plug them in while the system is running. If harddrive requires password drive may wait until have the machine is booted and dbus sends a message asking for password.
Also due to it being an activation based system not a init based system. It does house keeping on temp directories and the like.
Biggest change is cgroup wrapping of every service so you know what started what. Doing this also would have required a complete rewrite of the shell scripts.
Of course I am not going to say for one moment there are not areas in systemd that cannot be refined. Like possibly making units for mount handling and so on run as independent processes so more tolerant to failures.
Systemd is the first of its kind of system on Linux other than xinetd and inetd. This is important to remember every other init system that has ever been on linux is a rework of the sys v design one way or another. So perfectly fair to call the others YAIS. If systemd is yet another something. Its Yet Another Inetd. Just inetd on serious booster drugs so it can boot the complete system just compatible services. Yes systemd behavior is more like a inetd than a system v init.
A revamp of this size is a chance to fix a lot of historic mistakes and make a few new ones.
sysvinit is unreliable in the case of services depending on each other. You have to manually reorder stuff, or automatically reorder stuff based on dependencies encoded in LSB headers. Automatically reordering stuff is hard, especially on custom setups. With systemd that goes away and the kernel does it automatically. Much nicer than sysvinit.
Server boot time matters too.
With sysvinit you lose packets when restarting services, not so with systemd.
Changing the workflow isn’t necessary a bad thing. Sure, it can be an annoyance. But often specific workflow is a result of working around limtations and bad design decisions in tools. Learning new workflow can let you utilize the power of new tool. Only after you acknowledge that some canonical things can be done different and better you appreciate the new design.