Debian 8 "Jessie" OpenRC Conversion
Debian packages an excellent dependency-based, event-driven init system 1 named OpenRC. This page covers how to easily convert Debian 8 "Jessie"2 to use OpenRC3 + SysVInit's PID#1 /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
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, notfoss's OpenRC blog post looks 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.
Above is from my contemporaneous notes of changeover conducted in a VirtualBox VM, 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, 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.)
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.
Summary: All of these Desktop Environments as a whole are 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 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 affected. And a couple of dozen individual applications are affected. Attempting to install those packages 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 (not yet in Debian-stable), Enlightenment E17, fvwm-crystal, and Window Maker.
Here are all Debian 8 "Jessie" packages with dependencies traceable to
the systemd package4:
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: maste-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 thirty-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.
1 Init system, but lacking an init. 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 PID #1. This Web page uses SysVInit's /sbin/init as the Debian system's PID#1 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.
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.)
I owe thanks to Steve Litt for pointing out that OpenRC requires a separate PID#1 /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 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's event-driven loop 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 OpenRC package lacks dependency metadata to guarantee a PID#1 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 PID#1 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)".
2 And, one hopes, Debian 9 "Stretch", Debian 10 "Buster", and later.
3 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.
4 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"
Copyright (C) 2016 Rick Moen, <rick@linuxmafia.com> — though I have borrowed publicly-posted material from other, helpers elsewhere on the Internet and acknowledge those I can re-find.
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.