Gentoo Without systemd

Warning
This article has been flagged as dirty for not conforming to the wiki guidelines. It is now grouped in the list of articles to be cleaned.

One of Gentoo's distinctive characteristics is the ability to support systemd as an option, instead of it being the single available init system implementation. The distribution offers the choice of having a working Linux, non systemd-based operating system, and this article provides some tips on how to avoid unwanted installation of sys-apps/systemd on Gentoo.

Gentoo's init system and service manager setup

Several Gentoo profiles (eselect profile) that select the Linux kernel and the GNU C library (KERNEL USE_EXPAND flag set to linux and ELIBC USE_EXPAND flag set to glibc) have package virtual/service-manager in the system set (@system), i.e. it is guaranteed to be present in every Gentoo machine. This is a virtual package, that is, it installs no files but has an any-of dependency, || ( ... ), on other packages, and, for these profiles, it can be satisfied by sys-apps/openrc or sys-apps/systemd. The former pulls sys-apps/sysvinit as a runtime dependency (RDEPEND).

A Gentoo system installed from a sysvinit + OpenRC stage3 tarball (i.e. a stage3-*.tar.xz or stage3-*.tar.bz2 file that does not contain 'systemd' in the name) will have sys-apps/openrc already installed, so virtual/service-manager will be satisfied by that package, and systemd shouldn't get installed unless some other package pulls it as a dependency for some reason.

For information about stage3 tarballs and profiles, please review the Gentoo Handbook.

So, why is systemd pulled in?

Users of a non-systemd Gentoo system might be occasionally surprised by Portage trying to install systemd in response to an emerge command. Systemd is a large software package that implements an init system, but also provides a number other executables (systemd-udevd, systemd-logind, systemd-resolved, systemd-networkd, systemd-tmpfiles, systemd-localed, systemd-machined, systemd-nspawn, etc.), libraries (libsystemd, libudev), a PAM module (libpam_systemd.so) and an UEFI boot manager (systemd-boot), among other components. So any other package that needs any of these components, even if it is just one, would pull the whole systemd package as a dependency.

Most these packages, however, only have a 'soft dependency' on systemd, that is, optional fuctionality that uses a systemd component, and that can be turned on or off at build time. Gentoo, being a source-based distribution, is able to easily take advantage of such package features, and corresponding ebuilds usually expose a systemd USE flag that can be turned off to avoid installing systemd as a dependency. For most (all?) Gentoo profiles except the systemd or GNOME ones (i.e. those that contain 'systemd' and/or 'gnome' in their names), this USE flag is off by default.

A small number of packages have a 'hard dependency' on systemd, that is, their ebuild unconditionally lists sys-apps/systemd as a dependency, with no regard to the systemd USE flag. The most well known example of this is the GNOME desktop environment, which contains components (notably its display manager, GDM) that require systemd-logind. On systems that only use the official Gentoo repository (i.e. with no alternative ebuild repository of greater priority that has been added e.g. via eselect repository or Layman or /etc/portage/repos.conf), installing the GNOME desktop environment is one of the few cases that currently requires using systemd as the init system.

Taking explicit measures to avoid installation of systemd

Current profile settings are usually enough to avoid systemd on a Gentoo system installed from a sysvinit + OpenRC stage3 tarball, provided a non-systemd profile has been selected. However, the following explict measures can be easily taken by concerned administrators.

Gobally turning off the systemd USE flag

The systemd USE flag can be globally turned off in /etc/portage/make.conf:

FILE /etc/portage/make.conf

#Assuming USE contains more flag settings, represented by ellipsis:
USE="... -systemd ..."

This is an extra assurance that packages with a soft dependency on systemd will always install without enabling the features that require it.

Package masking systemd

The best assurance that systemd will not be installed is masking the package altogether:

FILE /etc/portage/package.mask/systemdpackage.mask directory example

sys-apps/systemd

Or alternatively:

FILE /etc/portage/package.maskpackage.mask file example

sys-apps/systemd

If an emerge command for any reason (including odd USE flag combinations) tries to pull sys-apps/systemd as a dependency, the package mask will cause a blocker that Portage cannot resolve (i.e. the output of emerge will show [blocks B ]), and make the emerge command fail. The administrator can then look at the blocker messages and figure out what to do, which in some cases might mean to just give up and not install certain packages.

The udev situation

Several Gentoo profiles (eselect profile) have package virtual/dev-manager in the system set (@system), i.e. it is guaranteed to be present in every Gentoo machine. This is a virtual package, that is, it installs no files but has an any-of dependency, || ( ... ), on other packages, and can be satisfied by another virtual package, virtual/udev, for an udev daemon provider (although that's not the only alternative!). Currently, there are three packages in Gentoo's repository that satisfy virtual/udev: sys-fs/udev, sys-fs/eudev, and sys-apps/systemd. Their ebuilds build and install code from one of two possible upstream packages: systemd and eudev, currently a Gentoo project:

• sys-apps/systemd: The historical udev codebase was merged with systemd's in 2012, so installing any recent systemd version already provides an udev implementation. The corresponding daemon is named systemd-udevd.
• sys-fs/eudev: Eudev is a fork of systemd's udev implementation, intended to be a drop-in replacement.
• sys-fs/udev: Based on the fact that systemd-udevd can currently run without systemd being process 1, this is a Gentoo-specific package that only installs the udev parts (e.g the systemd-udevd daemon, the udevadm program, the libudev library, etc.) of systemd's source tarball, without the rest the package's components.

Historically, Gentoo had a single stage3 tarball 'flavor' that had sysvint, OpenRC, and sys-fs/udev already installed, which produced a Gentoo system that had sysvinit + OpenRC as the init system, and systemd's code as the udev implementation. This system offered the possibility to be converted later, by administrator intervention, to full systemd-based Gentoo, or to switch from sys-fs/udev to sys-fs/eudev, after installation of the distribution as per the Handbook.

Nowadays, Gentoo offers both a sysvinit + OpenRC stage3 tarball with sys-fs/eudev, and a systemd stage3 tarball. A Gentoo system installed from the former (i.e. a stage3-*.tar.xz or stage3-*.tar.bz2 file that does not contain 'systemd' in the name) will have virtual/dev-manager satisfied virtual/udev, which in turn will be satisfied by sys-fs/eudev, so systemd shouldn't get installed unless some other package pulls it as a dependency for some reason.

Gentoo's original sys-fs/udev package continues to be available in the official repository, and it is still possible to switch from sys-fs/eudev to it and vice-versa: Portage will automatically uninstall the current package and install the requested one (i.e. the output of emerge will show [uninstall ]). However, users that absolutely do not want code from the systemd project on their machines, even if it is just the udev parts, can mask sys-fs/udev along with sys-apps/systemd:

FILE /etc/portage/package.mask/systemdpackage.mask directory example

sys-apps/systemd
sys-fs/udev

Or alternatively:

FILE /etc/portage/package.maskpackage.mask file example

sys-apps/systemd
sys-fs/udev

For information about stage3 tarballs and profiles, please review the Gentoo Handbook.

Systemd unit files

Some upstream packages provide systemd unit files, to make them easier to install on systemd-based distributions and try make them work mostly out of the box, but don't otherwise have any heavier integration with systemd, or require any systemd-specific functionality. This sort of packages are not considered to have an actual dependency on systemd (neither 'soft' or 'hard'), and, according to the official ebuild policy for systemd, unit files follow the usual guidelines against small text files (bash completion, logrotate etc.) and ebuilds must not prevent their installation based on the systemd USE flag.

Unit files are harmless and do nothing if systemd is not installed, just like OpenRC service scripts do nothing if sys-apps/openrc is not installed. However, users that absolutely do not want systemd unit files on their machines, can add systemd's unit file paths to INSTALL_MASK in /etc/portage/make.conf:

FILE /etc/portage/make.conf

#Assuming INSTALL_MASK contains more items represented by ellipsis:
INSTALL_MASK="... /lib/systemd /usr/lib/systemd ..."

Or alternatively, write a Portage postsync hook in /etc/portage/postsync.d:

FILE /etc/portage/postsync.d/10systemd

rm -rf /lib/systemd /usr/lib/systemd

Note
Systemd has more search paths than those in /lib/systemd (if the split-usr USE flag is set) or /usr/lib/systemd (if the split-usr USE flag is unset), however the package manager should restrict itself to installing unit files in those directories, as per systemd's convention. The other locations are for unit files that are e.g. dynamically generated (/run/systemd/system, etc.), installed by the administrator (/etc/systemd/system, etc.), or from a package that has been installed without using the package manager (/usr/local/lib/systemd/system, etc.). Users that prefer to also add those paths to INSTALL_MASK or the postsync hook can find the complete list here

For information about INSTALL_MASK or postsync hooks, please consult man make.conf and man portage, respectively.

Troubleshooting

Packages that unconditionally require systemd

As long as systemd is package masked, it's impossible to install packages with a 'hard dependency' on it. Cases like this almost always happen by upstream's choice, so there is little Gentoo can do in a packager and distributor role to avoid that, short of developing a Gentoo-specific patchset and committing to its long-term mainteinance across upstrem's releases. So the most advisable course of action for a solution is to try contacting the upstream developer team directly: file a bug report, contribute a patch, etc. Interested people must be aware that upstream's openness to accept such kinds of patches or bug reports may vary widely from project to project.

Sometimes alternative packages with similar functionality and no hard dependency on systemd can be found.

Checking if systemd is installed or not

The equery program from Gentoolkit can be used to see if systemd is installed or not:

user $equery list sys-apps/systemd

 * Searching for systemd in sys-apps ...
!!! No installed packages matching 'sys-apps/systemd'

Nowadays, getting systemd accidentally installed if the selected profile is a non-systemd one is hard, because of blockers that Portage cannot resolve with sys-fs/udev or sys-fs/eudev (i.e. the output of emerge will show [blocks B ]), and with sys-apps/sysvinit because of the on-by-default state of the sysv-utils USE flag in recent versions of sys-apps/systemd. Turning a Gentoo system installed from a sysvinit + OpenRC stage3 tarball into a systemd-based one requires an emerge --newuse --deep @world step with a particular USE flag setup as per the installation instructions, which is facilitated by systemd profiles. And if the package is somehow installed, actually running systemd as the init system requires a machine reboot with a suitable setup to either execute the systemd program as process 1 (e.g. an init kernel parameter or special initramfs setup), or have /sbin/init be a symlink to systemd.

Nevertheless, if systemd is accidentally installed, it is advised to get in touch with Gentoo's support community for help with its removal, because it might be a nontrivial task depending on why package got installed in the first place, and whether it is actually running as the init system, or just installed but inactive.

See also

• A (possibly partial) list of packages with a hard dependency on systemd

External resources

• A thread in the Gentoo Forums about using INSTALL_MASK to prevent installation of systemd unit files.
• Funtoo Linux Optimization Proposal: No-systemd system
• without-systemd.org