While I can not consider myself a veteran among the linux community (quite the contrary actually), I hope to help lay the groundwork for getting support for the various other inits that have just as much potential in production as sysvinit. To do this, I have decided to separate this broad topic into different sections. Throughout these sections I will use “Debian” as well as “Devuan”, as this could help fix Debian as well and lead to greater collaboration between the two distributions.

Inits Overview

Systemd

Currently, from how I understand it, the two main inits supported on Debian are systemd and sysvinit. Sysvinit is treated as a second class citizen compared to systemd, although the support is still far better than inits such as openrc and runit (more on those two later). According to anti-systemd critics, systemd is not that hard to uninstall and replace with sysvinit. This claim is correct, but also very much not correct. The steps to remove systemd and install sysvinit are thankfully provided here. Even a normal user could follow these directions given enough time, but it comes with big caveats. Many packages are specifically built against systemd, and will not install without it. Even if they don’t strictly depend on it, they still make use of the libsystemd0 library, which Devuan has been unsuccessful in removing. There’s also the issue of systemd trying to force its way back in even after fufilling all the directions, leading to a big mess. In layman terms, systemd is easy to uninstall, but hard to keep from reinstalling. This is not entirely systemd’s fault, but also on developers that build their software this way.

Sysvinit

Now, let’s say you decide to uninstall systemd and replace it with sysvinit, as you don’t think systemd reinstalling itself will be an issue. As a second and easier option, you decide instead to install Devuan and have sysvinit installed by default, with any of the possible caveats listed in the directions taken away. If you prefer good old-fashioned bash scripts, and /etc/initab for modifying the runlevels, what processes to start and monitor, etc., that’s great for you! Supporting that as an option is necessary for backwards compatibility, and for many people, “it just works”. However, writing sysvinit scripts can be a hassle, as they are shell scripts through and through. It is hard or at least non-obvious to support daemons starting on demand. Sysvinit scripts are not really user edit-able configuration, as discussed here. For me, the biggest turnoff is no real process supervision, e.g. daemons are not automatically restarted when they crash. As such, should sysvinit really be the only viable alternative to systemd on Debian? But wait, what about…

Openrc

Openrc is provided as an alternative service manager from the Devuan installer, which is already a step up from Debian. However, this is far from a replacement to sysvinit. In fact, it simply runs atop it. Sysvinit scripts are still used during initialization, and no openrc run scripts are provided as replacements for the various sysvinit scripts used in starting services. In recent versions of Openrc, it comes with its own init. This skips inittab and boots openrc directly, but since it still uses sysvinit scripts, it’s noticeably slower. Also, without providing getty scripts, the user won’t even reach the login prompt. Gentoo provides all the run scripts we could ever need, and so bringing them over is not an impossibility. Why bother using openrc run scripts and using openrc as an init and a service manager? The scripts are much easier to read, and process supervision would be handled much more cleanly. There’s also faster boot times and better overall performance, but your mileage may vary on those claims.

Runit

Runit, compared to openrc and sysvinit, is incredibly simplistic. Perhaps too simplistic for some users, but it makes creating services a breeze. Compared to the runlevels in sysvinit or openrc, there are 3 stages:

1: One time initialization tasks.

2: Run runsvdir (/etc/runit/runsvdir/default, single, etc. runlevels).

3. Halt or reboot the system.

Void Linux provides all the initialization tasks and services we need, but Debian throws all of that out the window in favor of using sysvinit scripts for initialization (more on this later). Even if this is not an issue for some users, there is still the problem of no runit scripts being provided.

Init Compatibility

The biggest problems facing init compatibility are as follows:

File Conflicts

First, where it all begins: /sbin/init. There are three packages that provide the inits: sysvinit-core, openrc, and runit-init. sysvinit-core installs init to /sbin/init. Openrc installs init to /sbin/openrc-init. Runit installs init to /sbin/init. sysvinit-core conflicts with runit-init, so there are no problems there. Openrc does not bother with at least symlinking /sbin/openrc-init to /sbin/init. This is where it gets tricky. if I wanted the openrc package to handle changing the init, it would have to conflict with sysvinit-core. Users who want to run openrc atop sysvinit would be out of luck if we did it this way. With this in mind, I propose a change to the openrc package: split /sbin/openrc-init into its own package, and have it install to /sbin/init instead. Now sysvinit-core, openrc-init, and runit-init will conflict with each other, and openrc can still be installed separately. To make them conflict, have them provide the init package. Next, we move on to power commands: halt, poweroff, shutdown, and reboot (I probably missed a few). As each init system provides their own power commands, these commands will conflict if they are installed together. Moving the commands into the init packages, if they’re not already there, would fix the issue. sysvinit-core already does this, in which case, perhaps renaming openrc-init and runit-init to openrc-core and runit-core would be a more consistent naming scheme. I’m not sure how this would affect running openrc atop sysvinit, runit atop openrc, and vice versa. Openrc has support for using runit for supervision. Next, the biggest source of conflicts: /etc/init.d. Specifically, the services installed there by sysvinit and openrc. For user choice, you could have openrc-core or runit-core installed along with the initscripts package, and use those scripts for initialization. However, what if you wanted to use openrc or runit initscripts instead? A lot of openrc initscripts have the same file names as sysvinit initscripts. Modifying openrc to include the initscripts, and then making openrc provide the initscripts package is one solution. This could be an issue for users who suddenly can no longer use sysvinit initscripts with openrc installed. Another solution is splitting openrc initscripts into its own package, initscripts-openrc. Runit would use initscripts-runit. Now initscripts, initscripts-openrc, and initscripts-runit would conflict. While this solves the file conflict issue among scripts during initial installation, it does not solve the issue of file conflicts that arise from packages that provide their own sysvinit scripts. This is a touchy problem, and deserves its own section as a result.

Service Conflicts

In init fairness, openrc and runit services should be provided. One solution is having each service be its own package. For instance, nginx-openrc, php-fpm-openrc, nginx-runit, and php-fpm-runit. The problem is that nginx and php-fpm already provide their own services in /etc/init.d. The same rule applies for countless other packages in Debian’s repositories. Why not just separate the sysvinit services into their own packages as well? As I discussed with other developers, the amount of effort that would take would be insurmountable. Also, when switching to another init, all service packages for that init would need to be replaced with equivalents for the new init. Automating these tasks somehow would ease development.

Helpers

init-system-helpers provides tools that are necessary for switching between the various init systems in Debian, but I’m not very knowledgeable with it. I think the tools in particular to pay attention to are invoke-rc.d and update-rc.d, as invoke-rc.d is executed on package service installation, and update-rc.d is executed on package service upgrade.