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.
- 1 Gentoo's init system and service manager setup
- 2 Taking explicit measures to avoid installation of systemd
- 3 The udev situation
- 4 Systemd unit files
- 5 Troubleshooting
- 6 See also
- 7 External resources
- 8 References
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, 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 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 or GNOME ones (i.e. those that contain 'systemd' and/or 'gnome' 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 is the GNOME desktop environment, which contains components that require systemd-logind (among them, notably, its display manager, GDM). 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, Layman or directly in /etc/portage/repos.conf), installing the GNOME desktop environment is one of the few cases that currently requires using systemd as the init system.
It is necessary to remove lines containing systemd from /etc/portage/package.use/ipuitls which would 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
systemd USE flag can be globally unset in /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.
To do this, create this file:
Package masking systemd
The best assurance that systemd will not be installed is masking the package altogether:
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 (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 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-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:
For a refresher on 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:
#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:
rm -rf /lib/systemd /usr/lib/systemd
Systemd has more search paths than those in /lib/systemd (if the
split-usrUSE flag is set) or /usr/lib/systemd (if the
split-usrUSE 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.
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:
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 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.
- A (possibly partial) list of packages with a hard dependency on systemd
- A thread in the Gentoo Forums about using INSTALL_MASK to prevent installation of systemd unit files.
- Funtoo Linux Optimization Proposal: No-systemd system
- News item "systemd sysv-utils blocker resolution", January 1st, 2018. Retrieved on September 22nd, 2018.