Logind

Logind is a system service that manages user logins. It is responsible for keeping track of users and sessions, generating and managing session IDs, providing polkit-based access to users for operations such as system shutdown or sleep, handling of power/sleep hardware keys, etc. Generally it's very useful for desktop systems but less useful for servers.

In BLFS, a logind implementation is provided by either systemd package (with PAM as a dependency), or elogind package.

How to declare logind dependencies in BLFS

BLFS packages can use systemd/elogind in various ways.

The package uses a logind API provided by libsystemd.so or libelogind.so

This package has a runtime dependency on BLFS systemd, and a normal dependency on elogind.

The LFS libsystemd.so already provides the logind APIs, but any call to them will fail before BLFS systemd is installed and logind starts to run. So it depends on BLFS systemd, but only at runtime. For elogind it's different: libelogind.so is not provided by LFS, so to use an API from it, the package needs to link to this library (unless dlopen() it but AFAIK no packages do so). Then elogind must be installed when the package is built.

A typical example is colord.

The package uses a non-logind API provided by libsystemd.so or libelogind.so

This package has no dependency on BLFS systemd or elogind.

The LFS libsystemd.so already provides the non-logind APIs and they are functioning fine w/o a logind, so you don't need to install BLFS systemd to use them. The non-logind APIs are provided by libelogind.so, but completely useless (elogind is not a service manager). In this case we don't declare an dependency despite the package links to libelogind.so.

A typical example is pulseaudio.

The package relies on the logind to give device access

This package has a runtime dependency on BLFS systemd or elogind.

The package actually only needs to access the device. When the logind is installed, we configure login (from shadow) to use pam_{systemd,elogind}. This PAM module will contact with the logind, telling it to give device access (via ACL in devtmpfs).

So the package by itself does not interact with logind, at all. You just need to run it in a login session started with pam_{systemd,logind}. This is of course a runtime dependency.

A typical example is Xorg server. Note that it also falls in "using non-logind API" (sd_notify and sd_listen_fds). So don't declare a build time dependency to elogind just because it links to libelogind.so, but the runtime dependency is real!

The PAM configuration of this package uses pam_systemd or pam_elogind

This package has a recommended runtime dependency to BLFS systemd or elogind. This should be obvious.

A typical example is GDM.

The package runs as a systemd user service

This package has no dependency on elogind, of course (elogind is not a service manager).

We normally don't declare an dependency on BLFS systemd, either. This kind of package often functions as a DE component, then the DM should use pam_systemd in the PAM configuration to spawn the systemd per-user service and we've already declared the runtime dependency to BLFS systemd (see the previous section). And a package in this kind can often run in a form other than per-user service and provide the same functionality.

D-Bus session services are registered as systemd user services if the systemd per-user manager is running (then we can use systemctl --user to control them), but they can also function w/o systemd per-user manager as a pure D-Bus service. So we should declare an optional runtime dependency on systemd for D-Bus, but not for every package providing D-Bus services.

A typical example is gnome-settings-daemon (and many other GNOME components).

If a package can only function as a systemd per-user service and it's not a DE component, maybe we should declare an optional/recommended runtime dependency on systemd. (obexd.service from bluez, if someone will really use a bluetooth device w/o a DE running?)