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.


4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
  1. Elogind User, Seat and Session Manager
  2. Introduction
  3. ------------
  4. Elogind is the systemd project's "logind", extracted out to be a
  5. standalone daemon. It integrates with PAM to know the set of users
  6. that are logged in to a system and whether they are logged in
  7. graphically, on the console, or remotely. Elogind exposes this
  8. information via the standard org.freedesktop.login1 D-Bus interface,
  9. as well as through the file system using systemd's standard
  10. /run/systemd layout. Elogind also provides "libelogind", which is a
  11. subset of the facilities offered by "libsystemd". There is a
  12. "libelogind.pc" pkg-config file as well.
  13. All of the credit for elogind should go to the systemd developers.
  14. For more on systemd, see
  15. All of the blame
  16. should go to Andy Wingo, who extracted elogind from systemd.
  17. Contributing
  18. ------------
  19. Elogind was branched from systemd version 219, and preserves the git
  20. history of the systemd project. The version of elogind is the
  21. upstream systemd version, followed by the patchlevel of elogind. For
  22. example version 219.12 is the twelfth elogind release, which aims to
  23. provide a subset of the interfaces of systemd 219.
  24. To contribute to elogind, fork the current source code from github:
  26. Send a pull request for the changes you like.
  27. To chat about elogind:
  28. #guix on
  29. Finally, bug reports:
  31. Why bother?
  32. -----------
  33. Elogind has been developed for use in GuixSD, the OS distribution of
  34. GNU Guix. See for more on Guix. GuixSD uses a
  35. specific init manager (DMD), for reasons that are not relevant here,
  36. but still aims to eventually be a full-featured distribution that can
  37. run GNOME and other desktop environments. However, to run GNOME these
  38. days means that you need to have support for the login1 D-Bus
  39. interface, which is currently only provided by systemd. That is the
  40. origin of this project: to take the excellent logind functionality
  41. from systemd and provide it as a standalone package.
  42. You're welcome to use elogind for whatever purpose you like --
  43. as-is, or as a jumping-off point for other things -- but please don't
  44. use it as part of some anti-systemd vendetta. We are appreciative of
  45. the systemd developers logind effort and think that everyone deserves
  46. to run it if they like. Not matter what kind of PID1 they use.
  47. Differences relative to systemd
  48. -------------------------------
  49. The pkg-config file is called libelogind, not libsystemd or
  50. libsystemd-logind.
  51. The headers are in <elogind/...>, so like <elogind/sd-login.h> instead
  52. of <systemd/sd-login.h>.
  53. Libelogind just implements login-related functionality. It also
  54. provides the sd-bus API.
  55. Unlike systemd, whose logind arranges to manage resources for user
  56. sessions via RPC calls to systemd, in elogind there is no systemd so
  57. there is no global cgroup-based resource management. This has a few
  58. implications:
  59. * Elogind does not create "slices" for users. Elogind will not
  60. record that users are associated with slices.
  61. * The /run/systemd/slices directory will always be empty.
  62. * Elogind does not have the concept of a "scope", internally, as
  63. it's the same as a session. Any API that refers to scopes will
  64. always return an error code.
  65. On the other hand, elogind does use a similar strategy to systemd in
  66. that it places processes in a private cgroup for organizational
  67. purposes, without installing any controllers (see
  68. This
  69. allows elogind to map arbitrary processes to sessions, even if the
  70. process does the usual double-fork to be reparented to PID 1.
  71. Elogind does not manage virtual terminals.
  72. Elogind does monitor power button and the lid switch, like systemd,
  73. but instead of doing RPC to systemd to suspend, poweroff, or restart
  74. the machine, elogind just does this directly. For suspend, hibernate,
  75. and hybrid-sleep, elogind uses the same code as systemd-sleep.
  76. Instead of using a separate sleep.conf file to configure the sleep
  77. behavior, this is included in the [Sleep] section of
  78. /etc/elogind/login.conf. See the example login.conf for more. For
  79. shutdown, reboot, and kexec, elogind shells out to "halt", "reboot",
  80. and "kexec" binaries.
  81. The loginctl command has the poweroff, reboot, sleep, hibernate, and
  82. hybrid-sleep commands from systemd, as well as the --ignore-inhibitors
  83. flag.
  84. The PAM module is called, not
  85. Elogind and the running cgroup controller
  86. -----------------------------------------
  87. While 'configure' runs, it will detect which controller is in place.
  88. If no controller is in place, configure will determine, that elogind
  89. should be its own controller, which will be a very limited one.
  90. This approach should generally work, but if you just have no cgroup
  91. controller in place, yet, or if you are currently switching to
  92. another one, this approach will fail.
  93. In this case you can do one of the two following things:
  94. 1) Boot your system with the target init system and cgroup
  95. controller, before configuring and building elogind, or
  96. 2) Use the --with-cgroup-controller=name option.
  97. Example: If you plan to use openrc, but openrc has not yet booted
  98. the machine, you can use
  99. --with-cgroup-controller=openrc
  100. to let elogind know that openrc will be the controller
  101. in charge.
  102. However, if you set the controller at configure time to something
  103. different than what is in place, elogind will not start until that
  104. controller is actively used as the primary controller.
  105. License
  106. -------
  107. LGPLv2.1+ for all code
  108. - except src/basic/siphash24.c which is CC0 Public Domain
  109. Dependencies
  110. ------------
  111. glibc >= 2.16
  112. libcap
  113. libmount >= 2.27.1 (from util-linux)
  114. (util-linux < 2.29 *must* be built with --enable-libmount-force-mountinfo,
  115. and later versions without --enable-libmount-support-mtab.)
  116. libseccomp >= 2.3.1 (optional)
  117. libblkid >= 2.24 (from util-linux) (optional)
  118. PAM >= 1.1.2 (optional)
  119. libacl (optional)
  120. libselinux (optional)
  121. libpython (optional)
  122. pkg-config
  123. gperf >= 3.1
  124. docbook-xsl (optional, required for documentation)
  125. xsltproc (optional, required for documentation)
  126. python-lxml (optional, required to build the indices)
  127. python, meson, ninja
  128. gcc, awk, sed, grep, m4, and similar tools
  129. During runtime, you need the following additional dependencies:
  130. util-linux >= v2.27.1 required
  131. dbus >= 1.4.0 (strictly speaking optional, but recommended)
  132. NOTE: If using dbus < 1.9.18, you should override the default
  133. policy directory (--with-dbuspolicydir=/etc/dbus-1/system.d).
  134. PolicyKit (optional)
  135. To build in directory build/:
  136. meson build/ && ninja -C build
  137. Any configuration options can be specified as -Darg=value... arguments
  138. to meson. After the build directory is initially configured, the configuration
  139. can be changed with:
  140. meson configure -Darg=value... build/
  141. 'meson configure' without any arguments will print out available options and
  142. their current values.
  143. Useful commands:
  144. ninja -v some/target
  145. ninja test
  146. sudo ninja install
  147. DESTDIR=... ninja install
  148. A tarball can be created with:
  149. git archive --format=tar --prefix=elogind-238/ v238 | xz > elogind-238.tar.xz