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 Article description::provides some tips on how to avoid unwanted installation of.

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  and ELIBC USE_EXPAND variable set to  ) have package  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  or sys-apps/systemd. The former pulls as a runtime dependency ( RDEPEND ).

A Gentoo system installed from a sysvinit + OpenRC stage3 tarball (i.e. a or  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 command. Systemd is a large software package that implements an init system, but also provides a number of other executables (,, , , , , , , etc.), libraries , a PAM module and a UEFI boot manager , 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  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  USE flag. The most well known example of this is the GNOME desktop environment, which contains components that require (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 ), 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 unsetting the systemd USE flag
The  USE flag can be globally unset in :

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:

Or alternatively:

If an 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  will show  ), and make the  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 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, , 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.
 * : Eudev is a fork of systemd's udev implementation, intended to be a drop-in replacement.
 * : Based on the fact that can currently run without  being process 1, this is a Gentoo-specific package that only installs the udev parts (e.g the  daemon, the  program, the  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 or  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 will show  ). 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:

Or alternatively:

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  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 :

Or alternatively, write a Portage postsync hook in :

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 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: 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 program from Gentoolkit can be used to check if systemd is installed:

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 will show  ), and with sys-apps/sysvinit because of the on-by-default state of the   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 program as process 1 (e.g. an   kernel parameter or a suitable initramfs setup), or have  be a symlink to.

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.

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