elogind is the systemd project's logind, extracted to a standalone package. It's designed for users who prefer a non-systemd init system, but still want to use popular software such as KDE/Wayland or GNOME that otherwise hard-depends on systemd.
The following kernel options are recommended:
General setup ---> [*] Control Group support ---> File systems ---> [*] Inotify support for userspace
In the unlikely (and not recommended) event that standard kernel features are enabled for manual configuration, elogind also requires
timerfd() support. Most users can ignore this.
USE flags for sys-auth/elogind The systemd project's logind, extracted to a standalone package
||Add support for Access Control Lists|
||Enable support for Linux audit subsystem using sys-process/audit|
||Use hybrid cgroup hierarchy (OpenRC's default) instead of unified.|
||Enable extra debug codepaths, like asserts and extra output. If you want to get meaningful backtraces see https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Backtraces|
||Add extra documentation (API, Javadoc, etc). It is recommended to enable per package instead of globally|
||Add support for PAM (Pluggable Authentication Modules)DANGEROUS to arbitrarily flip|
||Enable PolicyKit (polkit) authentication support|
||!!internal use only!! Security Enhanced Linux support, this must be set by the selinux profile or breakage will occur|
||Enable dependencies and/or preparations necessary to run tests (usually controlled by FEATURES=test but can be toggled independently)|
There is a global
elogind USE flag for enabling elogind support in other packages.
It's also recommended to disable support for other session trackers (systemd) to avoid conflicts:
Using elogind and systemd at the same time is untested and not advised!
After updating the USE flags update the system so the changes take effect:
emerge --ask --changed-use --deep @world
elogind should be configured to start at boot time:
rc-update add elogind boot
When D-Bus is installed with the
USE="elogind" flag, starting elogind on boot triggers the dbus system daemon to load automatically.
Alternatively, elogind can be launched on-demand by the first program that requests it (like a compatible display manager), through the system dbus service.
If there are problems getting poweroff/reboot/suspend etc. working from desktop environment, putting elogind into boot runlevel will make sure the elogind-daemon is started properly before any user is logged in, and so should fix the problem.
Additionally, if built with
USE="pam", elogind will be activated when the first user logs into the system.
In order to trigger elogind to activate a session on first on a VT console terminal, sys-apps/shadow has to be built with the PAM USE flag also, since it provides /bin/login. This concept also applies to any other graphical login managers or alternative terminal login programs used. In that case, they should be built with PAM too.
startx D-Bus integration
To have an elogind session created when using startx to start the X server (instead of a display manager), add the following to the user's ~/.xinitrc file:
exec dbus-launch --exit-with-session <WINDOW_MANAGER>
WINDOW_MANAGER in the above example needs to be replaced by a window manager or a single application.
This exec command launches dbus-daemon --system, which launches your WM. No further commands will be executed if placed after this "exec" line
Suspend/Hibernate Resume/Thaw hook scripts
With elogind the situation is much handier. Any suspend/resume and hibernate/thaw hook scripts need to be in the directory /lib64/elogind/system-sleep/ and use the variables $1 (
post) and $2 (
hybrid-sleep). For example, in the case of elogind a hook script could have the following format:
#!/bin/bash case $1/$2 in pre/*) # Put here any commands expected to be run when suspending or hibernating. ;; post/*) # Put here any commands expected to be run when resuming from suspension or thawing from hibernation. ;; esac
Do not forget to make the hook scripts executable. (chmod +x)
The command loginctl may be used to control and introspect the login manager. For example, to shut down or reboot the system:
For example, to suspend, hibernate or hybrid-suspend the system:
Confirmation of full functionality
Running loginctl itself will indicate ALL sessions/seats/users/tty's for which elogind has been fully activated. For example:
SESSION UID USER SEAT TTY 1 0 root seat0 tty1 2 1000 larry seat0 tty2 2 sessions listed.
Checking for the presence of XDG environment variables should produce similar results, even before a GUI is loaded. For example:
env | grep "XDG"
XDG_CONFIG_DIRS=/etc/xdg:/etc/xdg XDG_SEAT=seat0 XDG_SESSION_TYPE=tty XDG_SESSION_CLASS=user XDG_VTNR=2 XDG_SESSION_ID=2 XDG_RUNTIME_DIR=/run/user/1000 XDG_DATA_DIRS=/usr/local/share:/usr/share:/usr/share
Conflict when using hidepid in proc
When procfs is mounted with
gid=wheel, there will be conflicts with elogind. In order to change this, the gid needs to be changed to
See also this forum post https://forums.gentoo.org/viewtopic-t-1099870.html
If using USE=pam, make sure there are no conflicting pending changes waiting to be written to /etc (run etc-update or dispatch-conf to merge any /etc/pam.d conflicts.)
Confirm these changes took place in these two /etc/pam.d files:
grep -r "elogind" /etc/pam.d/
/etc/pam.d/elogind-user: session optional pam_elogind.so /etc/pam.d/system-login: -session optional pam_elogind.so
- bug #599470 - sys-auth/elogind integration into Gentoo tracker bug.
- News item - Desktop profile switching USE default to elogind