Systemd VS OpenRC – Which init System Is The Best For You? Comparison

Dry Facts

Alright, enough with all the history and theory lessons, it’s time to get practical.

Boot Speed

Benchmarking both init systems on my PC, enabling basically the same services (some services that has equivalent Systemd tool, e.g. cronie is interchangeable with timers, were not enabled on Systemd, as they are already built in), yielded the following results:

* Achieved by disabling irrelevant services

Pros & Cons

– Green represent pro quality

– Red represents con quality

Sytemd

• Systemd is geared towards performance
• Systemd provides more administration tools
• Systemd has more features e.g. unit files can be of different types, etc…
• Being relatively new, Systemd has less pre-made configurations for administering programs, e.g. you’ll have hard time finding service unit for ipset or other exotic software
• Systemd comes with extra tools by default which might be deemed unnecessary by some users
• Systemd’s binary log is more prone to corruption^[15]
• Systemd isn’t portable

openRC

• openRC is portable
• openRC is small
• openRC is modular
  
• openRC is simple
• openRC’s catering for other OSs may detract from its performance – as more code may be required to support different types of OSs and also, as it faces difficulty in leveraging platform specific advantages such as kernel features, etc…
• openRC provides less administration features e.g. openRC’s logger doesn’t track services initialization times (as can be viewed by Systemd, although it does inform about hangs)

Feature Comparison

Examining the Facts

The facts above might be a bit confusing on first glance, for instance, if we look at the pros and cons lists, it seems Systemd has more cons than pros and in openRC’s case it’s the opposite. However in reality, some of the items in the lists overshadows other items, which is why I took the liberty of emphasizing the qualities I deem the most prominent.

After all, at the end of the day most users probably won’t care that Systemd carries a few unnecessary features as long as it performs better (faster) than its competitors, right?

Another example is the boot speed table which shows clear advantage in favor of Systemd by default. However, it seems to show the opposite later on in the table. Moreover, by looking at one case scenario (which is my system case) we cannot deduce that this is the rule for everyone. Therefore we must examine it more closely.

So why is it that Systemd seems to be so fast by default? The proponents of Systemd attribute its superiority to its use of Unix domain sockets (UDS) technology^[18] which helps starting processes in parallel by caching request for processes that aren’t yet running – that probably had its most prominent impact on my first boot tests, those without any tweaking.

However on the second series of tests I changed the order of scripts to minimize any waiting times. openRC, which apparently uses pipeline technology (said to be faster than UDS^[19]), seemed to handle parallel start-ups then quite good too, so where did the difference stem from this time?

The difference appears to stem from 2 distinct reasons:

1. C is faster than Shell – for machines to execute binary code (zeros and ones) compiled from C language is much easier and quicker than interpreting a bash script and then executing it. As mentioned in the feature comparison table, Systemd doesn’t incorporate Shell scripts by default, thus when it starts up a service it saves a bit of time of interpreting and executing additional commands.
2. Systemd’s built-in extra tools means less services to start – saving the time of initializing cronie (interchangeable with timers), consolekit (interchangeable with logind), hwclock (interchangeable with timedated) and a few other services which have no equivalent on Systemd (for instance, ipset script is unnecessary on my Systemd set-up) surely is (at least) partly responsible for Systemd’s fast boot up.

On the third series of test, a dramatic change occur, suddenly it was the other way around and openRC was the one with the leading (fastest) boot time, so how did that happen?

Simply, I maximized my tweaking by disabling a couple more services (on both inits) which weren’t relevant for daily use and hwclock script on openRC (it turned out that the same functionality could be set in kernel), and thus the results changed.

Now, this leads to another interesting question: did I, by disabling a script only on openRC, have therefore given it an edge over Systemd? Well, my answer is I don’t think so and the reason is as follow:

First, the goal of my boot up comparison was to reach the same state of functionality with both inits and that state didn’t change by disabling hwclock (since the functionality was enabled through the kernel).

Secondly, script for script wise, I actually made things more even that way, since openRC also had to run my ipset service script while Systemd didn’t.

Hence, I would say that the last result is no less realistic than the two previous ones.

So we’ve addressed one part of the facts regarding performance, boot speed, and we’ve touched a little bit on the importance of other features the inits have. Now let’s address a couple more significant issues.

For using declarative unit files, Systemd discourages free scripting (by you or your distribution) and encourages sticking to a certain set of rules by default. (although, scripts can be referenced via its service files, e.g. ExecStart=PATH/TO/SCRIPT)

This approach certainly has its merits in the form of:

• Performance gains – the less options a software need to take into account the faster it can respond.
• Generally tighter security –  as stricter set of rules may lead to less human errors.

openRC on the other hand, defaults to using Shell (POSIX) compliant scripts which may lead to a little more creativity and by extent functionality.

Lastly, another important fact worth a closer examination is Systemd’s built-in extra tools, which possibly are giving it a performance edge, as long as the user actually needs and wishes to use them all.

Having other tools built into it leaves no much choice for the user but to install the tools that comes with Systemd. However, those aren’t always matching the user needs. For instance, Systemd’s timers (replacement for cron) can’t send emails^[20]. Now this might be of little to no importance to you on a home machine but on servers it might actually be a deal breaker.

Although you could theoretically always add another tool that would either replace timers altogether or would supplement it, still the fact remains you can’t install Systemd without the extras, thus having unnecessary software on your machine, incurring all the drawbacks that may entail.

At the bottom line, the extra tools shipped with Systemd have, and probably always will have, the same drawback that exist in many other products that offers multiple solutions packed into one – think about shampoo combined with conditioner, laundry detergent combined with softener, etc… While these tools can certainly save some time and money (as you buy both in one) they’ll probably never be as optimized as one tool for one job.

Conclusions

It is obvious from the above that neither Systemd nor openRC are all-round perfect, also, neither of which could fit the title of “one init fits all”.

That said, it does seem that Systemd would be the preferable solution for the majority of users, at least as long as current state of things is going to remain (note that there are indications it won’t last^[13]).

Systemd’s performance by default, as evident in the “Dry Facts” section, definitely plays a major part in its viability. Its extra tools and feature set might appeal to those who seek a ready made solution. Being at the forefront of init’s evolution (- “Natural Evolution”) means users are going to be covered, in terms of capabilities, for the near future.

On the other hand openRC certainly lives up to its position as an alternative to the mainstream Systemd, and perhaps even a premium alternative I would add.

As evident in “Examining the Facts” section, openRC can indeed outperform Systemd, however to utilize its performance to the maximum level, a user would have to be somewhat an expert in administering the system and perhaps even Linux in general (that kernel setting, for instance, wouldn’t be apparent to anyone). Those who are willing to walk the extra mile of learning, configuring and tweaking their systems would find openRC capable of delivering astonishing feats.

Furthermore, openRC proved itself to be both backwards compliant as well as future-proof by offering the latest init abilities (- “Natural Evolution”), all that without breaking any backwards compatibility, which is impressing. Its smaller development scale however may mean users will need to be a bit more patient when it comes to new features, but probably “it’s better slow and steady than fast and shaky”.

In light of the above, it is therefore not surprising, when you think about it, how distros in reality have actually aligned themselves in relations to the Systemd/openRC question – distros such as Fedora, Debian, Ubuntu and many others, which are aiming at general user-audience, have all chose using Systemd by default, whereas distros that are considered more niche such as Gentoo, Alpine, ArchBang, TrueOS and more have all chosen openRC by default.

Recommendations

If you’re looking for a straight up solution that needs not much configuring and works quite well out of the box, then you should probably go with Systemd as your init system.

If indeed you choose to go with Systemd, I’d recommend you make yourself acquainted with:

• systemd-analyze (tool)
• systemctl (tool)
• Note that journald is storing its logs in binary format by default thus to read it you’ll probably want to use: journalctl -b (last session since boot)

And obviously make yourself familiar with the various unit types Systemd supports: services, timers, targets, slices, etc…

If you’re looking for a more optimized solution that you could play with, tweak and bend to your will openRC should be the init for you.

In this case I’d recommend you familiarize yourself with:

• rc-service (tool)
• rc-update (tool)
• /etc/rc.conf file and the options it contains
• Configuration files can be set in /etc/conf.d directory
• Applications init scripts are located at /etc/init.d directory
• runlevels are located at /etc/runlevels directory

Have fun :)