Init System Comparison
Hello all and welcome to my first blog-post style devlog (just a new thing I am trying). Today, we will be comparing various init systems.
This devlog also happened in my usual realtime way in Matrix. This is the same thing, but in a more of a research paper style vibe. Anyway.
What Is An Init System
An init system is a program typically located at /sbin/init. It is the first program to be started and is started automatically by the kernel once it loads the rest of the operating system. It is responsible for starting all key services.
Therefore, service management is an essential part of an init system.
Today, we will be comparing OpenRC, runit and sysvinit to systemd, when it comes to service management.
I made a few VMs for testing each of these. Let’s start with the control group.
systemd
We’re testing this one on an Arch:
Systemd’s service management utility is systemctl. Without arguments, it lists all the services present on this system. Most important arguments include:
-
start: Starts the service. -
stop: Stops the service (by sending SIGTERM); kills it (SIGKILL) if it isn’t responding. -
enable: Enables autostart on system startup. -
disable: Disables autostart on system startup. -
status: Displays basic information about the service, if it’s running, the log of its current lifetime…
This is the output of status:
Let’s now look at a service file itself:
Now systemd does something unusual here: the service is a config, not a script. I like this approach, because it ensures that each config has a similar, easily readable structure. Dependencies? in the Wants and After field. Which program is the service really? ExecStart, you’re welcome. Straightforward.
Any errors result in an invalid service, and not a half invalid service, as we will find out later. Furthermore, it ensures that actions that have a service management nature stay with systemd, the thing that actually does the service management?
Now let’s talk logs. Systemd uses the highly controversial journal. It’s a log, but binary and compressed. I can actually understand the hate here. Afterall, you can’t just grep this thing. But there is journalctl, with many powerful switches (e.g. -u, for filtering output based on service), so I suppose you can just pipe this into grep and go from there.
Since systemd is our control group, I will rate it 5/10:
Perfectly average, because we said it is the average. By this logic:
-
10/10: I can’t believe it hasn’t replaced systemd yet.
-
5/10: Better than systemd in some situations, worse in others.
-
0/10: I can’t believe some people believe it can even even dream of replacing systemd.
OpenRC
Unlike the other init systems we have here, OpenRC is not an init system (until recently, at least). Instead it is a service manager that sits on top of another init system (usually sysvinit). We’re counting it as an init system here, because all the actual init system does on a system with OpenRC is start OpenRC, which then starts all the other services.
We have an Artix OpenRC for this one:
I know nothing about OpenRC, so it’s wiki time.
So instead of systemctl, we have rc-service. It has the same start, stop, status. enable and disable is handled by a more traditional concept called runlevels, which are kind of like systemd targets. Now the output of status is a little lacking:
A little disappointing. Sure, the thing is running, but that’s all I am getting from here. Now let’s take a closer look at this service:
So it is true. Services really used to be scripts, huh. With the service management actions defined inside the service. Why. At least OpenRC has its special service scripting language, making it relatively easy to read, e.g. dependencies are simpy within depend().
Logs are just plain old text logs. You can grep it. Not much to say there.
3/10:
While pretty straightforward, the status command for services is lacking, and speaking of service commands, they are actually just functions in a script, which means that it’s possible to create a service that can only be started but cannot be stopped. I would never want to deal with this this.
runit
We have another Artix, the runit one this time:
Once again, wiki time.
This one has sv instead of systemctl. Same system, with runlevels and all, as with OpenRC, including the lacking status.
Autopsy time:
Wait is that it? That’s right, the entire service is less than 10 lines. Now I know that these services are also just scripts, but this init system actually understands that. As of result, the scripts are only responsible for actually starting the service. Everything else, including the command parsing, is where it should be, with runit.
Now how does it handle dependencies?
Really?? That’s what you’re going with? I don’t like it.
Logs are once again just logs. You should consider entering the lumber industry.
5/10:
Just as with OpenRC, status is lacking. the services themselves are just startup scripts though, which I find wonderfully simple, though I do not agree with how dependencies are handled. While it is in no way better than systemd on a server, I can see myself using it on hardware where systemd is too much.
sysvinit
So there isn’t an Artix variant that uses plain sysvinit without OpenRC. Infact, there is barely any distro that uses sysvinit without OpenRC. Let’s just say, my hopes are not high for this one. In the end, I had to touch the absolute lunacy that is Devuan:
This time I don’t even have the Artix wiki. Well, manpages it is.
For systemctl we have service, with exactly the same syntax as OpenRC, runleveles, lacking status, all the charade. What else can I say.
Autopsy time:
Oh dear no please nononononono… It’s a fucking BASH SCRIPT
Right. Where do we begin. How does it handle dependencies? Idk, up in the header perhaps? It uses hashtags though, which is for comments in bash, so maybe it’s just documentation? Don’t ask me. Of course, the start and stop commands are handled by the service in the worst possible way, just see for yourself:
You can make a service without the basic stuff like status, or even stop, and it would still be a perfectly valid service.
Logs are just logs, very pretty and definitely not a distraction from the terrible services.
1/10:
status is lacking (just like the others), and the service files themselves are bash scripts, with all the command parsing with the individual services themselves, instead where it should be, with the init system. I do not want to even see this thing, ever.
Conclusion
Of all the init systems we explored today, only runit got even close to being a worthy systemd alternative. All it needs now is a more verbose status, and maybe switching from service scripts to service configs, so they don’t have to handle dependencies with their weird pipe to /dev/null exit thing.
As they stand today, neither of these init systems is capable of replacing systemd. Maybe runit could, but only in embedded (or BSDs, which don’t have systemd), but generally, even it is lacking.
That concludes today’s devlog.