You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
KatolaZ 87c42e3fa5 added upstream-tags in gbp.conf 5 years ago
cb Prep v234: Update root build files to upstream. 6 years ago
debian added upstream-tags in gbp.conf 5 years ago
docs Prep v234.2: Remove obsolete files in coccinelle, docs/ and m4/ 6 years ago
factory/etc/pam.d Change systemd occurences in factory/etc/pam.d to elogind. 6 years ago
m4 Prep v234.2: Apply upstream fixes in m4 (1/6) 6 years ago
man Prep v233.7: Make all supportable API functions visible (v233 addition). 5 years ago
po Prep v234.2: Apply upstream fixes in po (2/6) 6 years ago
shell-completion bash-completion: list valid signal names 6 years ago
src Prep v234.4: ake all supportable API functions visible (v234 addition). 5 years ago
tools Prep v234.2: Apply upstream fixes in tools (6/6) 6 years ago
.dir-locals.el Prep v234: Update root build files to upstream. 6 years ago
.gitattributes git: indicate that tabs are never OK in the systemd tree 9 years ago
.gitignore Prep v232.6: Make all supportable API functions visible (v232 addition). 5 years ago
.mailmap Prep v234: Update root build files to upstream. 6 years ago
.vimrc Prep v230: Apply missing upstream fixes and updates (1/8) root build files. 6 years ago ycm: update flag blacklist 9 years ago
CODING_STYLE Prep v233: Update root build files to upstream version 6 years ago
LICENSE.GPL2 relicense to LGPLv2.1 (with exceptions) 11 years ago
LICENSE.LGPL2.1 licence: remove references to old FSF address 10 years ago
LICENSE.MIT relicense to LGPLv2.1 (with exceptions) 11 years ago Prep 229.9: Make all supportable API functions visible. 5 years ago Version 234.4 Release 5 years ago
NEWS Prep v234: Update root build files to upstream. 6 years ago
README Prep v231.3: Fix typo in README 6 years ago
TODO Prep v234: Update root build files to upstream. 6 years ago Prep v229: Update core build files to upstream 6 years ago Version 234.4 Release 5 years ago


Elogind User, Seat and Session Manager


Elogind is the systemd project's "logind", extracted out to be a
standalone daemon. It integrates with PAM to know the set of users
that are logged in to a system and whether they are logged in
graphically, on the console, or remotely. Elogind exposes this
information via the standard org.freedesktop.login1 D-Bus interface,
as well as through the file system using systemd's standard
/run/systemd layout. Elogind also provides "libelogind", which is a
subset of the facilities offered by "libsystemd". There is a
"libelogind.pc" pkg-config file as well.

All of the credit for elogind should go to the systemd developers.
For more on systemd, see All of the blame
should go to Andy Wingo, who extracted elogind from systemd.


Elogind was branched from systemd version 219, and preserves the git
history of the systemd project. The version of elogind is the
upstream systemd version, followed by the patchlevel of elogind. For
example version 219.12 is the twelfth elogind release, which aims to
provide a subset of the interfaces of systemd 219.

To contribute to elogind, fork the current source code from github:

Send a pull request for the changes you like.

To chat about elogind:

#guix on

Finally, bug reports:

Why bother?

Elogind has been developed for use in GuixSD, the OS distribution of
GNU Guix. See for more on Guix. GuixSD uses a
specific init manager (DMD), for reasons that are not relevant here,
but still aims to eventually be a full-featured distribution that can
run GNOME and other desktop environments. However, to run GNOME these
days means that you need to have support for the login1 D-Bus
interface, which is currently only provided by systemd. That is the
origin of this project: to take the excellent logind functionality
from systemd and provide it as a standalone package.

We like systemd. We realize that there are people out there that hate
it. You're welcome to use elogind for whatever purpose you like --
as-is, or as a jumping-off point for other things -- but please don't
use it as part of some anti-systemd vendetta. Systemd hackers are
smart folks that are trying to solve interesting problems on the free
desktop, and their large adoption is largely because they solve
problems that users and developers of user-focused applications care
about. We are appreciative of their logind effort and think that
everyone deserves to run it if they like, even if they use a different
PID 1.

Differences relative to systemd

The pkg-config file is called libelogind, not libsystemd or

The headers are in <elogind/...>, so like <elogind/sd-login.h> instead
of <systemd/sd-login.h>.

Libelogind just implements login-related functionality. It also
provides the sd-bus API.

Unlike systemd, whose logind arranges to manage resources for user
sessions via RPC calls to systemd, in elogind there is no systemd so
there is no global cgroup-based resource management. This has a few

* Elogind does not create "slices" for users. Elogind will not
record that users are associated with slices.

* The /run/systemd/slices directory will always be empty.

* Elogind does not have the concept of a "scope", internally, as
it's the same as a session. Any API that refers to scopes will
always return an error code.

On the other hand, elogind does use a similar strategy to systemd in
that it places processes in a private cgroup for organizational
purposes, without installing any controllers (see This
allows elogind to map arbitrary processes to sessions, even if the
process does the usual double-fork to be reparented to PID 1.

Elogind does not manage virtual terminals.

Elogind does monitor power button and the lid switch, like systemd,
but instead of doing RPC to systemd to suspend, poweroff, or restart
the machine, elogind just does this directly. For suspend, hibernate,
and hybrid-sleep, elogind uses the same code as systemd-sleep.
Instead of using a separate sleep.conf file to configure the sleep
behavior, this is included in the [Sleep] section of
/etc/elogind/login.conf. See the example login.conf for more. For
shutdown, reboot, and kexec, elogind shells out to "halt", "reboot",
and "kexec" binaries.

The loginctl command has the poweroff, reboot, sleep, hibernate, and
hybrid-sleep commands from systemd, as well as the --ignore-inhibitors

The PAM module is called, not

Elogind and the running cgroup controller
While 'configure' runs, it will detect which controller is in place.
If no controller is in place, configure will determine, that elogind
should be its own controller, which will be a very limited one.

This approach should generally work, but if you just have no cgroup
controller in place, yet, or if you are currently switching to
another one, this approach will fail.

In this case you can do one of the two following things:

1) Boot your system with the target init system and cgroup
controller, before configuring and building elogind, or
2) Use the --with-cgroup-controller=name option.

Example: If you plan to use openrc, but openrc has not yet booted
the machine, you can use
to let elogind know that openrc will be the controller
in charge.

However, if you set the controller at configure time to something
different than what is in place, elogind will not start until that
controller is actively used as the primary controller.


LGPLv2.1+ for all code

- except src/shared/MurmurHash2.c which is Public Domain
- except src/shared/siphash24.c which is CC0 Public Domain
- except src/journal/lookup3.c which is Public Domain


glibc >= 2.14
libmount >= 2.20 (from util-linux)
libseccomp >= 1.0.0 (optional)
libblkid >= 2.24 (from util-linux) (optional)
PAM >= 1.1.2 (optional)
libacl (optional)
libselinux (optional)
make, gcc, and similar tools

During runtime, you need the following additional dependencies:

dbus >= 1.4.0 (strictly speaking optional, but recommended)
PolicyKit (optional)

When building from git, you need the following additional

gtkdocize (optional)