Debian 8 "Jessie" OpenRC Conversion

Last updated: 2021-06-01

Debian packages an excellent dependency-based init system ¹ named OpenRC. This page covers how to easily convert Debian 8 "Jessie"² to use OpenRC³ + SysVInit's PID1 /sbin/init instead of the default systemd init, init scripts, service supervisor, etc., etc. The question arose on a mailing list:

Date: Thu, 6 Aug 2015 12:40:56 -0700
From: Rick Moen <rick@linuxmafia.com>
To: luv-main@luv.asn.au
Subject: Re: laptop sleep on closing lid

Quoting Mark Trickett:

> The fact [systemd] does binary logs is a very major defect in my opinion
> and experience.

For completeness, I'll note that it's pretty easy to disable handoff of logging information to systemd-journald and substitute a handoff to rsyslog or syslog-ng, instead. For example, Debian's systemd package defaults to rsyslog as system logger, not systemd-journald.

> I noted that it is possible to put OpenRC on Debian 8. I shall need to
> do a bit of research. Some notes from you and/or Rick Moen would be
> very appreciated.

OpenRC Installation / Systemd Removal Recipe:

apt-get install openrc

(Note: At this point, you should also do "apt-get install sysvinit-core" to make double-sure you have a suitable PID1 init binary. This package was auto-installed when I test-installed Debian 8 "Jessie", but I hear reports it's no longer auto-installed as of Debian 9 "Stretch", the subsequent Debian-stable branch. Footnote 1 has more background on this matter.)

Reboot.

apt-get remove --purge --auto-remove systemd

Measures to prevent package systemd from being installed in the future via dependencies:

echo -e 'Package: systemd\nPin: origin ""\nPin-Priority: -1' > /etc/apt/preferences.d/systemd
echo -e '\n\nPackage: *systemd*\nPin: origin ""\nPin-Priority: -1' >> /etc/apt/preferences.d/systemd

If your system uses multiarch (32- and 64-bit packages), do this too, to pin the 64-bit version of systemd:

echo -e '\nPackage: systemd:amd64\nPin: origin ""\nPin-Priority: -1' >> /etc/apt/preferences.d/systemd

In other multiarch cases where amd64 is the default architecture, you may have to pin the i386 package:

echo -e '\nPackage: systemd:i386\nPin: origin ""\nPin-Priority: -1' >> /etc/apt/preferences.d/systemd

You are done.

Above recipe is adapted from a without-systemd.org wiki article, and gratefully acknowledged. See that page for some other ideas.

A quickstart guide to OpenRC administration would be nice, and if time permits I might write one. So far, Steve Litt's notes and notfoss's OpenRC blog post look most useful (ignoring some details specific to Arch Linux), and the Arch Linux wiki OpenRC page is also some help. The Gentoo wiki's OpenRC page is authoritative, but verbose, (IMO) murky, and (IMO) too interwoven with Gentoo-specific bits inapplicable to Debian. OpenRC's maintainers have some docs in GitHub

Above is from my contemporaneous notes of changeover conducted in a VirtualBox VM (x86_64 arch), so I'm reasonably confident they're complete and correct. Getting rid of the systemd-entangled udev/libudev1 code, and getting any replacement (eudev, mdev (1, 2) vdev) to work with the latest xserver-xorg packages, is a further experiment I've not yet undertaken. (The Devuan fork of Debian is doing great work with vdev, to make that practical. It should also be noted that the Linux kernel can do just fine managing automated device nodes, and automatic loading of firmware, by itself, using its own devtmpfs code. The function of udev is basically to create additional symlinks such as /dev/disk/by-{path,id,label,partlabel,partuuid,uuid} ones for devices, further manage device permissions, run ancillary scripts, and send notification messages to desktop environment code. If you don't need those things or can bloody well do them yourself, thanks, then you don't need udev or anything like it. Also useful in this regard: ifrename.)

I strongly encourage using VM (virtual machine) software as a vehicle for system software experiments. Among other advantages, the VM framework lets you checkpoint the entire guest OS just before any such experiment, so you can revert with ease if your experiment fails, i.e., you needn't either risk a real system nor risk even having to reinstall a guest OS. Without the VirtualBox trick, I'm not sure I'd have chanced this test conversion, as the conditioned fear of destroying systems kicks in. Point is, VM software allows you to set aside this otherwise commendable caution without risk.

A few things such as bsdutils and util-linux have started to depend on libsystemd0, but that seems entirely harmless. I respect the developers behind Devuan, and know they have done & are doing a great deal more than just omitting systemd, but it seems to me that there was a lot of hyperventilating over mere presence of a lib that's doing zero harm just sitting there. If worried about it, run a nightly cronjob that ensures /lib/[$ARCH]-linux-gnu/libsystemd.so.* is set to 000 permissions.

In my experience and for my use-case (eschewing big DEs and NetworkManager — detailed below), my instructions completely suffice to create fully functional Debian 8 "Jessie" with my choice of init — without any need to fork the distribution.

Which Debian 8 "Jessie" Packages Depend on Package Systemd:

I spent time studying the dependency graph of Debian 8 "Jessie" packages and metapackages — to find which require (directly or indirectly) the systemd package (referred to in the paragraph below as being "adversely affected").

Summary: All of these Desktop Environments as a whole (as kitchen-sink metapackages) are adversely affected: GNOME, MATE, Cinnamon, KDE, and Razor-qt. You will certainly be able to install almost all applications from those DEs, but not the DEs as a whole. The hplip printing software for HP printers is adversely affected (but see workaround in the next section), because that package is (seemingly pointlessly) packaged to require policykit-1 (that requires libpam-systemd, that requires systemd). network-manager (from GNOME) and a number of its variant forms are adversely affected. And a couple of dozen individual applications are adversely affected. Attempting to install those packages/metapackages will result in apt-get erroring with a "Some packages cannot be installed" diagnostic citing a broken dependency — because of the above recipe's package-pinning via /etc/apt/preferences.d/systemd that bars installation of systemd.

Unaffected DEs include Xfce, LXDE, LXQt (officially part of Debian-stable as of 9 "Stretch", but not 8 "Jessie") Enlightenment E17, fvwm-crystal, and Window Maker.

Here are all Debian 8 "Jessie" packages/metapackages with dependencies traceable to the systemd package⁴:

Depends directly on systemd: libpam-systemd, systemd-dbg, systemd-sysv, systemd-ui
Pre-Depends directly on systemd: gummiboot, systemd-sysv
Depends on systemd-sysv: systemd-cron, libpam-systemd
Depends on libpam-systemd: policykit-1, gnome-bluetooth, udisks2, gdm3, gnome-settings-daemon, network-manager
Depends on systemd-ui: systemd-gui
Depends on policykit-1: aptdaemon, colord, ettercap-graphical, firewall-applet, firewalld, fprintd, gdm3, gnome-color-manager, gnome-system-log, gufw, hplip, libmatepolkit-dev, libpolkit-gtk-mate-1-0, libvirt-daemon-system, mate-polkit, mate-power-manager, nautilus-dropbox, network-manager, packagekit, policykit-1-gnome, polkit-kde-1, python3-plainbox, razorqt-policykit-agent
Depends on libpolkit-gtk-mate-1-0: libpolit-gtk-mate-1-0-dbg, libmatepolkit-dev, mate-system-tools
Depends on udisks2: python3-checkbox-support, daisy-player, gnome-disk-utility, gvfs-daemons, k3b, kde-plasma-desktop, kde-plasma-netbook
Depends on gdm3: gnome-core, xfswitch-plugin
Depends on gnome-core: gnome, task-gnome-desktop
Depends on network-manager: modem-manager-gui, network-manager-dbg, network-manager-gnome, network-manager-openconnect, network-manager-strongswan, plasma-nm, python-networkmanager, sucrose-0.96, sucrose-0.98
Depends on packagekit: apper, browser-plugin-packagekit, gnome-packagekit-session, gstreamer1.0-packagekit, listaller, packagekit-command-not-found, packagekit-dbg, packagekit-tools
Depends on network-manager-gnome: cinnamon, design-desktop, gnome, parl-desktop
Depends on network-manager-openconnect: network-manager-openconnect-gnome
Depends on policykit-1-gnome: apper, cinnamon, gconf-editor, gnome-session-flashback, gnome-system-tools, gnome-core, network-manager-gnome
Depends on gnome-settings-daemon: gdm3, cinnamon, gnome-control-center, gnome-core gnome-music, gnome-packagekit-session, gnome-power-manager, gnome-session, gnome-session-flashback, gnome-shell, indicator-session
Depends on gnome-bluetooth: gnome-core, gnome-user-share
Depends on gnome-disk-utility: gnome-core
Depends on colord: gnome-color-manager, gnome-control-center
Depends on gnome-color-manager: gnome
Depends on gnome-system-log: gnome-core
Depends on apper: apper-dbg
Depends on daisy-player: daisy-player-dbg
Depends on mate-polkit: gnome-system-tools, libmatepolkit-dev, mate-desktop-environment-core, mate-panel, mate-session-manager, mate-system-tools
Depends on mate-system-tools: mate-system-tools-dbg
Depends on kde-plasma-desktop: kde-full, kde-standard
Depends on kde-plasma-netbook: kde-full, kde-standard
Depends on polkit-kde-1: apper, kde-standard
Depends on k3b: k3b-i18n
Depends on razorqt-policykit-agent: razorqt
Depends on ettercap-graphical: ettercap-dbg
Depends on firewalld: firewall-applet, freedombox-setup
Depends on gvfs-daemons: gvfs-backends
Depends on hplip: hplip-data, hplip-gui, printer-driver-postscript-hp
Depends on python3-plainbox: python3-checkbox-ng
Depends on python3-checkbox-support: pythong3-checkbox-ng, plainbox-provider-resource-generic

Overcoming Dependency Obstacles

Let's say you want package hplip (printing software for HP printers), a common use-case. On a systemd-free Debian 8 "Jessie" system, package installation unfortunately is blocked by dependency chain hplip -> policykit-1 -> libpam-systemd -> systemd. What to do?

In that one case, the answer is that you only think you need the hplip package, which is an omnibus desktop-oriented packaging of the HPIJS and HPLIP drivers, and therefore includes GNOME-dependency hooks. The parts you want are in more-focussed subcomponent packages printer-driver-hpcups and printer-driver-hpijs, working with CUPS or your preferred print engine.

To pick another case, suppose you wish to use the daisy-player package to play talking books for the visually impaired. That package is built, seemingly gratuitously, to require udisks2, so installation is blocked by dependency chain daisy-player -> udisks2 -> libpam-systemd -> systemd. My best advice is to rebuild the package locally, omitting the gratuitous dependency on Freedesktop.org's intrusive udisks2 software.

In other cases, your best bet might be to construct a deb package using the upstream source tarball, using the superb debhelper utility to guide you through the process.

In still other cases, you may find a suitable unofficial deb package in a third-party apt repository. (Be wary of security implications of using third-party software sources.)

You could fall back on the old-school option of compiling a non-packaged installation, placed into /usr/local/*, starting from the upstream maintainer's source code. (Again, there are security concerns to beware of.) However, I would suggest always using debhelper to create a true local deb package, so that your system's package management knows what exists, can manage its dependencies, and can remove it cleanly upon request.

The equivs package can sometimes finesse a dependency if you judge it to be bogus: equivs provides a mechanism for convincing Debian a package is installed even though it is not.

Last, if you wish to supplement Debian's official repositories with those of the Devuan fork, there are instructions for doing so. That change is reported to restore ability to use software needing Freedesktop.org's udisks2 and policykit system software. Presumably, Devuan's versions of the latter lack a dependency on systemd.

¹ Init system, but lacking an init. (2017-11 update: Starting with OpenRC 0.25, init binary openrc-init has been added.) OpenRC provides all functions needed to control startup processes, except for the /sbin/init process (the actual init process) forked from your booting kernel as master process with PID1. (Again, one has now been added with the 0.25 release.) This Web page uses SysVInit's /sbin/init as the Debian system's PID1 init process, because Debian 8 "Jessie" happens to install it. However, any other init will also do, e.g, FreeBSD's init and many others.

OpenRC includes cgroup (control group) management on the Linux kernel (cgroups being Linux-specific). Also, starting with v. 0.22, OpenRC can do service supervision in conjunction with runit's runsvdir service script. Also, starting with v. 0.21 (May 24, 2016), OpenRC has included its own native service supervisor, supervise-daemon.

Until 2018 I recommended Andy Mender's excellent page about optimal implementation of runit as service supervisor, init, or both on Devuan (and presumably also Debian.) For more about service supervisors and inits, see also Frew Schmidt's supervisors impressions. supervise-daemon appears to make this no longer necessary.

A history of modern init systems mentions that OpenRC is known to be runnable from Busybox init + mdev, which sounds intriguing, especially for servers, possibly with the minirc script. (See tutorial, background, instructions.)

I owe thanks to Steve Litt for pointing out that OpenRC requires a separate PID1 /sbin/init that spawns it and then permits OpenRC to run/control all subsequent services. Through dumb luck, my test conversion of Debian 8 "Jessie" to OpenRC in a VM benefited from Debian's installer default-installing the sysvinit-core package, thereby providing SysVinit's traditional /sbin/init binary. SysVInit's /sbin/init has the advantage of being a well-audited and reasonably scoped init binary, to which nobody really objects, whereas SysVInit's init scripts are widely deemed antiquated and no longer able to cope well with the needs of increasingly dynamic Linux system environments, exactly the area where OpenRC or your choice of other modern but modestly-scoped init systems (e.g., runit, s6, Epoch, tt) wins without systemd's drawbacks of scope creep, dependency nightmares, intrusiveness, and hostile upstream maintainers. Other, even smaller init binaries can be used in its place. At this writing, the Debian 8 "Jessie" OpenRC package lacks dependency metadata to guarantee a PID1 init package being also present, so that detail is worth double-checking manually.

During recent controversies over systemd, there's been much confusion between inits (the PID1 system process binaries), init script packages, service managers, and init systems (composite of two or more of the first three categories). I highly recommend reading the Arch Linux wiki's init page to help untangle these concepts. Notice that what I call an init system (a composite of two or more categories), Arch Linux calls "init (integrated)".

2017-07 addendum: Readers familiar with the canonical OpenRC implementation in Gentoo / Funtoo / Manjaro / Alpine Linux / arch-openrc / TrueOS (a FreeBSD derivative) say that Debian's package is relatively unsatisfactory/incomplete a/o the time I wrote this page (2016). The issue is that OpenRC's signature /etc/conf.d/ tree (that holds default values for the corresponding /etc/init.d/ scripts, eliminating the need for stability-risking edits to the latter) is missing, and OpenRC's init scripts aren't used, but rather those from SysVInit, making the package a half-hearted effort so far.

(Adam Borowski says the OpenRC package in Debian 9 "Stretch" and in Debian sid/unstable is a lot better albeit not ideal.)

Alternatives include installing Debian using the TRIOS Mia installation image instead of Official Debian. Also, Adam Borowski says that the full-featured OpenRC package in Devuan "Ascii" (the Devuan release parallel to Debian 9 "Stretch") is now (2017-07-10) fully usable with the rebuilt util-linux support package from his third-party repo:

I don't have an Ascii VM to check right now, but I'm 99% sure my stretch packages should work fine.

You can either grab them via apt:
wget -qO- https://angband.pl/deb/archive.html | apt-key add -

deb http://angband.pl/debian nosystemd-stretch main
deb-src http://angband.pl/debian nosystemd-stretch main

Or rebuild yourself:
https://angband.pl/debian/pool/main/u/util-linux/util-linux_2.29.2-1.0nosystemd1.dsc

It might be wise at this date to apt-get the tweaked util-linux source code from his repo and build it.

The Devuan distribution's leadership said in 2016 that Devuan's official OpenRC package would "follow the design proposed by upstream" (Gentoo), i.e., include the full OpenRC feature set, directories, and scripts. It has been developed by package maintainer "Parazyd".

² And, one hopes, Debian 9 "Stretch", Debian 10 "Buster", and later.

³ Or to any of the other init systems' packages in Debian 8 "Jessie": sysvinit, upstart, or runit, in addition to the openrc package. (dumb-init can be fetched from Debian-unstable and is a simple init and process supervisor intended for software-container setups.) The nosh init system (init, init scripts, and service manager) is also available directly from its author as binary packages for Debian. Conversion to OpenRC is the only one I've so far tested, but there's no reason my simple technique shouldn't work to change over to any of those others.

Also worth investigating albeit not yet Debian-packaged, and filling one or more of the roles init system, init (PID1), or service supervisor: ninit, "subsentient's" sinit (suckless init) (1, 2), minit, finit, Epoch (1, 2), uinit, busybox-init, anopa, eINIT, myinit, daemontools-encore, freedt, procer, watchman, s6-rc, tt, GNU Shepherd. Packaged by Debian: runit, supervisord, daemontools, monit, restartd. Third-party packaged for Debian: s6 (packaged), perp (packaged), nosh (packaged).

To avert possible confusion: References you may see to "66" refer not to an init system, but rather to a suite of system management tools coded for s6 and s6-rc, by coders at Obarun, an Arch Linux-based distribution that eschews systemd.

⁴ Gleaned mostly via commands like this: "apt-cache --no-pre-depends --no-recommends --no-suggests --no-conflicts --no-breaks --no-replaces --no-enhances rdepends libpam-systemd"

Verbatim copying, distribution, and display of this entire article (page) are permitted in any medium, provided this notice is preserved. Alternatively, you may create derivative works of any sort for any purpose, provided your versions contain no attribution to me, and that you assert your own authorship (and not mine) in every practical medium.