Hard dependencies on systemd

While some people might intuitively think that software packages should not generally depend on a specific init system, systemd itself is a large package that not only implements an init system, but also provides a number of other executables (systemd-udevd, systemd-logind, systemd-homed, 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 sys-apps/systemd as a dependency.

This article contains a (possibly partial) list of packages in Gentoo's repository that unconditionally require systemd, i.e. that unconditionally list sys-apps/systemd in one or more of the corresponding ebuild's xDEPEND variables, thereby making systemd a 'hard dependency'.

Packages

Note
Packages designed to interact with systemd as their main purpose, like GNOME Logs (gnome-extra/gnome-logs, a viewer for systemd's journal), systemd-kcm (kde-misc/systemd-kcm, a systemd control module for KDE), or python-systemd (dev-python/python-systemd, a Python module for native access to the systemd facilities) are not considered.

• app-admin/abrt — This package includes three daemons, abrt_dump_journal_core, abrt_dump_journal_oops and abrt_dump_journal_xorg, that extract core dumps, oopses and Xorg crashes, respectively, logged in systemd's journal. These tools are useless on Gentoo without systemd; however, the package's build system builds them unconditionally, and because they access the journal using the sd-journal API of libsystemd, this results in a build failure if that library is not present. Assuming the rest of the package is still worth it without these daemons, to avoid the dependency the build system would have to be patched to conditionally build them based on a configure script option, and the ebuild would have to be modified to enable or disable the option based on the state of the systemd USE flag. The ebuild installs OpenRC service scripts for other daemons though, in addition to upstream's service unit files. Also, several other programs use libreport, so they gain an indirect dependency on libsystemd through that library (see below). In particular, those that produce log messages instruct libreport to log to the journal (LOGMODE_JOURNAL), expecting the administrator to configure systemd-journald to forward messages to syslog, instead of logging to syslog directly (LOGMODE_SYSLOG). A decision that would have to be reverted (or libreport would have to be patched to make LOGMODE_JOURNAL a synonym of LOGMODE_SYSLOG if journal support is disabled at compile time).
• app-emulation/snapd — This package provides a daemon, snapd, that requires systemd running as PID 1 to manage snap packages. Since snap packages are squashfsfiles, the daemon uses systemd's systemctl program to mount and unmount snap package archives. While the daemon makes calls to systemctl to perform these functions, it does not specify the path to its executable. A potential workaround would be to substitute systemctl with a custom program in its place to intercept the daemon's calls to the program.

• dev-libs/libreport — This package provides a library, libreport, with logging functionality among other things, including logging to systemd's journal. It does so by using the sd-journal API of libsystemd. To avoid the dependency, the library and the build system would have to be patched to make the feature, which is useless on Gentoo without systemd, a compile-time option, and the ebuild would have to be modified to enable or disable the option based on the state of the systemd USE flag.

• gnome-extra/gnome-user-share — This package provides a daemon, gnome-user-share-webdav, that expects to be launched and supervised by a systemd process running as a user instance (i.e. systemd --user). It does so by installing a service unit file, gnome-user-share-webdav.service, in /usr/lib/systemd/user. It has no other runtime dependency on systemd, and no compile-time dependency on it.

• gnome-extra/office-runner — This package provides a GTK+ 3 program, office-runner, that inhibits the low-level handling of the hardware lid switch by communicating over D-Bus with a process that implements the org.freedesktop.login1.Manager interface, and invoking the Inhibit() method of its /org/freedesktop/login1 object to take an inhibitor lock. This D-Bus interface is implemented by systemd-logind, but also by elogind, so it is not clear if this package couldn't also work with sys-auth/elogind. It does not have a compile-time dependency on systemd, it uses the GDBus API of GLib (dev-libs/glib).

• sys-apps/dbus-broker with the launcher USE flag set — This package provides a daemon, dbus-broker, that, in combination with a second process that meets certain specifications, called the controller, implements a D-Bus message bus daemon, just like the dbus-daemon program from the D-Bus reference implementation (sys-apps/dbus). It also provides another daemon, dbus-broker-launch, that can act as a controller for dbus-broker, and is built if the launcher USE flag is set. Because dbus-broker needs a controller to be usable, this is the ebuild's default setting (i.e. IUSE=+launcher). dbus-broker-launch and dbus-broker together aim to behave in a way that is fully compatible with dbus-daemon, except in several occasions where it deviates. While dbus-broker does not have any dependency on systemd, dbus-broker-launch has lots:
  • Its code is structured as an event loop, implemented with the sd-event API of libsystemd. Events that the loop handles are received signals, received D-Bus messages, dbus-broker process terminations, and changes in directories that contain configuration files (e.g. /usr/share/dbus-1/{system,session}.d/*.conf) and service files (e.g. /usr/share/dbus-1/system-services/*.service and ${XDG_DATA_HOME}/dbus-1/services/*.service), and are monitored via inotify watches.
  • It uses the sd-bus API of libsystemd to implement communications over the message bus, and communications with dbus-broker.
  • It uses the sd-daemon API of libsystemd to receive the message bus' file descriptor from systemd, and to verify that it corresponds to a listening, stream mode UNIX-domain socket.
  • It also uses the sd-daemon API to notify systemd when it is ready to provide the service, and when it is reloading.
  • It uses the the sd-id128 API of libsystemd to retrieve the system's machine ID.
  • At runtime, it tries to connect to systemd-journald's socket, /run/systemd/journal/socket, to log both its messages and dbus-broker's to systemd's journal.
  • At runtime, it doesn't execute activatable services' associated programs itself like dbus-daemon does. Instead, it expects a systemd process to be connected to the message bus, and asks it to execute the programs by creating transient service units for them, using systemd's org.freedesktop.systemd1.Manager D-Bus interface. This is one of the documented deviations.

• www-misc/profile-sync-daemon — This package provides a bash script, profile-sync-daemon, intended to be periodically executed with a resync argument, and a timer unit file and accompanying service unit files to implement that with systemd. The script is likely usable on Gentoo without systemd regardless, e.g. with explicit cron setup by the user, provided the XDG_RUNTIME_DIR environment variable is appropriately set as per the XDG Base Directory Specification. The psd preview command also uses systemctl is-active to show the status of its supplied units as part of its output ("Systemd service is currently active", "Systemd resync service is currently active"), which is meaningless without systemd. Running the unmodified script would be ugly because of the shell's "command not found" error messages instead of the intended output, but otherwise nonfatal. Cosmetic patches could be applied to suppress that part of the output, and to fix other error messages that suggest systemd commands to the user in order to fix the situation that caused the error.

Packages that formerly had a hard dependency on systemd

• gnome-base/gnome — For versions 3.28 and earlier, the GNOME desktop environment contained components that required systemd-logind (among them, notably, its display manager, GDM). However, as of version 3.30, 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. Some GNOME packages, though, still unconditonally pull sys-apps/systemd, and are explictly listed above.

• x11-wm/mutter with the wayland USE flag set (i.e. USE=wayland emerge mutter) — For versions 3.28.0 and earlier, Mutter's native (KMS) backend used to require systemd-logind. Building the native backend is optional, and enabled if the wayland USE flag is set. As of version 3.28.1, the native backend can alternatively be built with elogind, and Portage will do so if the elogind USE flag is also set.

See also

• Elogind — the systemd project's logind, extracted to a standalone package.