Should we avoid systemd?

We have seen systemd become the standard init system in quite many distributions, even Debian after it’s board was infiltrated by RedHat connected people.

The arguments to why use systemd is said that it’s faster and can start services in parallel, much of the speed gain seems to come and haunt it later on in the process, when you really need to use the services, for example nfs won’t be started until someone tries to access a file over nfs, this makes nfs to become really slow when you really need it as it has to be started up, while in a traditional setup you can access the file at once. It seems that systemd didn’t solve a problem but created a new one and another big issues with systemd is that if you have a hard drive issues, systemd fails to boot when it can’t access the hard drive, traditionally the system would boot up as well as it can, if this failed hard drive is an old backup drive, then there is no point at all to fail the boot.

Something that seldom is lifted up when it comes to systemd, is the security vulnerabilities it has had, of course one of the contributing things is that systemd do eat up other projects and those gets more and more potential sources for vulnerabilities. This makes systemd to break with the Unix philosophy, do one thing and do it well. The more systemd does, the harder will it be to know if a change will have bad effects on other parts of systemd.
Lets go back to the vulnerabilities and take some help from NVD, here we can search for vulnerabilities based on application, so lets start with looking at our old buddy sysv, we find 12 matches and if we look closer at the vulnerabilities and we see that only two have anything to do with sysv, CVE-2019-2389 and CVE-1999-1329, and of those the first one is MongoDB start script badly written by the MongoDB developers, the later one is dues a modification RedHat made to RedHat 5.1 sysv init script, but let us count it as sysv vulnerability.
Then we have openrc and we find 2 vulnerabilities, CVE-2017-18188 and CVE-2017-16638, so we have one startup script that was quite critical, but this time we keep on counting it as it’s the same “team” as the authors of openrc.
Last lests look at systemd and we find 79, but of those we can ignore 11 as they are mainly microsoft windows related issues, so we still have 68 vulnerabilities of which mostly are high or critical.

So how can we compare the different init systems regarding to vulnerabilities, lets see when they were originally released, how many listed vulnerabilities in the NVD they have and how many are critical.

NameReleaseTotal # VulnerabilitiesCritical Vulnerabilities
sysv198110
openrc200721
systemd2010685

With a shorter lifespan than any other init system for Unix and Linux, it had managed to have the greatest amount of vulnerabilities. Sure systemd has the best service jailing, but that is more or less where it’s positive sides ends as openrc can also start services in parallel to speed up the boot sequence and may even be faster than systemd in some cases.

Just looking at this, makes you wonder why distributions has decided to leave the Unix philosophy to have a init system which do break if you don’t have the right combination of kernel, systemd, and udev. You will not know if you are out of sync until you try to reboot your computer, if it don’t boot, then you have to figure a way to boot from a rescue image and chroot into your systemd/Linux and upgrade the three components and then reboot and hope that the update went well or else… this did never happen with the older init systems.

My recommendation is, avoid systemd and you will have less problem, just pick a distribution from the nosystemd distribution list.

Leave a Reply