5 reasons to love init

The init system of an operating system is the component that starts all the programs that run on your computer. Without init, you’d have to launch everything manually, including the interface you would use to do the launching! The init system is also the component that gracefully stops those processes when you send a shutdown signal to your computer.

In a previous article, I wrote about my favourite features of systemd. The truth is, I don’t run systemd on all my computers, most notably not the desktop Slackware PC that I use daily, and certainly not on my NetBSD Raspberry Pi. Slackware uses a “BSD style” init system, and there are other distributions (such as Gentoo, Arch, Crux, MxLinux) offering OpenRC, Runit, and SysV. Each distribution has its own set of reasons for not defaulting to systemd, but here are 5 reasons I love the traditional BSD init system.

1. No layers of abstraction

Sometimes it’s nice to have the exact details of a technology left abstract. It can be a real relief to not have to worry about how a process starts or stops, and what command options are required for it to run in the foreground or background. When writing a systemd service script, you get a lot of functionality “for free”. You don’t have to write the case statement that detects the arguments provided with a command, you don’t have to wrap a function in a script so it relaunches upon failure, and so on. You get a lot of functionality from the fact that systemd is designed to behave a specific way.

However, there are lots of good reasons you might prefer to write your own init scripts. Maybe you have your own conventions for starting and stopping and monitoring processes. Maybe you’re using custom software that, for whatever reason, would benefit from more interaction types than systemctl has to offer. Or maybe you just enjoy writing and maintaining your own system scripts. There’s no wrong reason, so if you want manual intervention past the level of defining that a service exists, then a traditional init system might be the way to go.

2. You already know how to script

A systemd definition is a configuration file. There are key and value pairs, special options specific to the way systemd works, and different definition types (service, socket, timer, and so on), and different locations for them on your system. It’s invisible to most users, even if you’re a user writing custom systemd configs, so you probably don’t think about it much.

With many other Linux and BSD init systems, startup files are consolidated, singular in purpose, and relatively easy to understand. Assuming you already know how to write a shell script, you can construct a custom startup script using your favourite shell syntax, and with identical logic to what you’d use for an interactive command. In fact, many init systems are just running startup scripts as shell scripts, and any time you want to start it manually you can just execute the script yourself. You have a very direct relationship with a traditional init system, with the actual init application doing little aside from running a bunch of scripts for you upon boot.

3. Native flexibility

Because an init script is just an executable script, you can actually write it in basically any language you like. A shell is safest because it’s available early in the boot process and it doesn’t usually have many dependencies. However, should you want to try init scripts written in Python or Perl or even Awk, you can. I’m not actually encouraging you to experiment with your init sequence, but the flexibility is significant. You may have a good reason to write an init script in something other than /bin/sh, and a traditional init system can (probably) handle whatever you use.

Even if you very rationally keep your init scripts constrained to basic shell syntax, there’s a lot of permissable flexibility within that script. You could use a case statement or an if statement to catch arguments. You could launch a subshell to gather important information from elsewhere on your system.

In short, you can use all the usual technologies available to you by your shell.

4. Just the init process

Critics of systemd often complain that systemd is “monolithic”. It’s objectively not monolithic, and you can look at the source code if you need proof, and yet somehow it does feel awfully monolithic. Because systemd has features for init, but also logging and scheduling and even user data management, it can seem like systemd is trying to do too much.

With a traditional init system, there’s no confusion about what init is there for. Your executable init scripts are started at boot time and stopped at shutdown, and that’s all. There are other applications entirely to handle scheduled jobs and logs and whatever else.

5. Easy to swap

Here’s what I get when I run sudo dnf remove systemd on my laptop:

Problem: The operation would result in removing the following protected packages: kernel-core

It’s hard to argue that removing an init system should ever result in the removal of the kernel, the single component that makes your computer functional. Even so, that’s how systemd is very frequently packaged. This isn’t actually a requirement of systemd, but a result of a package manager is instructed to track dependencies.

It’s rare, at least in my experience, to find a traditional init system with the kernel as a child package. That means it’s often easier with a traditional init system to change which init system you use. Some distributions make it very easy to do this, with existing packages for different init systems for you to choose from. Others don’t necessarily provide packages and scripts ready to use, but allow you to easily swap out the init command for something different, and to populate your init script directory with any converted scripts the different init system may require. I’ve run minit, ninit, runit, and openrc on Slackware, with each one requiring a different amount of adaptation.

Choose your init system

Many users are happy to run the default init system used in their Linux or BSD operating system. In practise, that’s what I do. I don’t think too much about init until, of course, I need to interact with it. It’s surprising how minor differences can impact your workflow, so having an init system you’re comfortable and familiar with is a real luxury, especially in a pinch. However, if you’ve got a long weekend ahead of you with nothing better to do, it can be a lot of fun to try a new init system on a test computer. It may never matter, but then again you may just find an init system that you enjoy more than what you’ve been using. Whether you’re switching from SysV to BSD, or BSD to systemd, or systemd to OpenRC, or whatever, exploring alternate ways of accomplishing effectively the same result is always educational.