Gentoo without systemd

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.

Gentoo's init system and service manager setup

Several Gentoo profiles that select the Linux kernel and the GNU C library (KERNEL USE_EXPAND variable set to linux and ELIBC USE_EXPAND variable set to glibc) have package virtual/service-manager in the system set, 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. For these profiles, virtual/service-manager 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-managerwill be satisfied by that package, and systemd shouldn't get installed unless some other package pulls it as a dependency for some reason.

For a refresher on 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 of 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 (pam_systemd.so) and a 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 functionality 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 unset to avoid installing systemd as a dependency. For most (all?) Gentoo profiles except the systemd ones (i.e. those that contain 'systemd' in their names), this USE flag is unset 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 used to be the GNOME desktop environment, which, for versions 3.28 and earlier, contained components that required systemd-logind (among them, notably, its display manager, GDM). As of version 3.30, though, Gentoo's packaging of GNOME allows it to work once again with sysvinit + OpenRC as the init system. This is achieved through elogind; non-systemd GNOME profiles (i.e. those with 'gnome', but not 'systemd', in their name) set the elogind USE flag so that packages pull sys-auth/elogind as a dependency instead of sys-apps/systemd.

It might also be necessary to remove lines that set the systemd USE flag from files in /etc/portage/package.use that could have been added automatically.

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.

Globally disabling and masking the systemd USE flag

The systemd USE flag can be globally unset 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.

In addition, the USE flag can be masked in /etc/portage/profile/use.mask so that Portage's autounmask feature will be unable to suggest enabling it:

FILE /etc/portage/profile/use.mask

systemd

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 have package virtual/dev-manager in the system set, 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. Currently, there are only two packages in Gentoo's repository that satisfy virtual/udev: sys-apps/systemd-utils, and sys-apps/systemd itself.

• sys-apps/systemd: The historical udev code base 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-apps/systemd-utils: A collection of systemd-specific split off for use with alternative init systems. It includes the udev program.

Historically, Gentoo had a single stage3 tarball 'flavor' that had sysvinit, OpenRC, and udev already installed. A system installed from this tarball had sysvinit + OpenRC as the init system, and systemd's code as the udev implementation. It offered the possibility to be converted later, by administrator intervention, to full systemd-based Gentoo, or to switch from udev to eudev (deprecated), after installation of the distribution as per the Handbook.

Nowadays, Gentoo offers both a sysvinit + OpenRC stage3 tarball and a systemd stage3 tarball. A 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-apps/systemd-utils, so systemd shouldn't get installed unless some other package pulls it as a dependency for some reason.

For a refresher on stage3 tarballs and profiles, please review the Gentoo Handbook.

systemd unit files

Warning
Some packages like sys-fs/udev install files to directories with 'systemd' in the path and therefore a wide INSTALL_MASK for e.g. /lib/systemd/* is dangerous and may lead to breaking an installation.

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 the INSTALL_MASK variable in /etc/portage/make.conf:

FILE /etc/portage/make.conf

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

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

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

rm -rf /lib/systemd/*/*.service /usr/lib/systemd/*/*.service

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 patch set and committing to its long-term maintenance across upstream's releases. So the most advisable course of action for a solution is to try contacting the upstream developer team directly: filing a bug report, contributing 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 check if systemd is installed:

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 (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 a suitable 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

• Hard dependencies on systemd — a (possibly partial) list of packages in Gentoo's repository that unconditionally require systemd

External resources

• without-systemd overlay, containing replacements for sys-apps/systemd-utils
• A thread in the Gentoo Forums about using the INSTALL_MASK variable to prevent installation of systemd unit files.
• Funtoo Linux Optimization Proposal: No-systemd system
• without-systemd.org