Gentoo without systemd - Gentoo wiki
Jump to:
content
Gentoo without systemd
From Gentoo Wiki
(Redirected from
Gentoo Without systemd
Jump to:navigation
Jump to:search
This page contains
changes
which are not marked for translation.
Other languages:
Some of the information in this article may have drifted out of sync with current practices. Please help out by
checking over the content
how to get started
).
This article contains references to the
obsolete
sys-fs/udev
package
. Could anyone who knows how to fix this and has the time please bring it up to date?
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
Contents
Gentoo's init system and service manager setup
1.1
So, why is systemd pulled in?
Taking explicit measures to avoid installation of systemd
2.1
Globally disabling and masking the systemd USE flag
2.2
Package masking systemd
systemd unit files
Troubleshooting
4.1
Packages that unconditionally require systemd
4.2
Checking if systemd is installed or not
See also
External resources
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
virtual/service-manager
and
virtual/dev-manager
packages in
the system set
, i.e. it is guaranteed to be present in every Gentoo machine. They are a
virtual packages
, 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
, and
virtual/dev-manager
can be satisfied by
sys-apps/systemd-utils
, and
sys-apps/systemd
itself.
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
and
sys-apps/systemd-utils
already installed, 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
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
[1]
. 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
systemd
Package masking systemd
The best assurance that systemd will not be installed is
masking the package
altogether:
FILE
/etc/portage/package.mask/systemd
package.mask directory 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
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
[2]
. 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
References
Gentoo website, News section,
"Gentoo GNOME 3.30 for all init systems"
, March 27th, 2019 .
News item
"systemd sysv-utils blocker resolution"
, January 1st, 2018. Retrieved on September 22nd, 2018.
Retrieved from "
Categories
Stale
Init systems