To contribute to elogind, fork the current source code from github:
- https://github.com/andywingo/elogind
+ https://github.com/elogind/elogind
Send a pull request for the changes you like.
Finally, bug reports:
- https://github.com/andywingo/elogind/issues
+ https://github.com/elogind/elogind/issues
Why bother?
-----------
Libelogind just implements login-related functionality. It also
provides the sd-bus API.
-Unlike systemd, whose logind arranges to run user sessions in cgroups
-via RPC calls to systemd, in elogind there is no systemd so there are
-no cgroups. This has a few implications:
+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
+implications:
* Elogind does not create "slices" for users. Elogind will not
record that users are associated with slices.
- * Systemd's logind waits for all user jobs to stop before recording
- that a user's session has gone away. Since we have no cgroups,
- elogind just removes the session directly when pam_elogind.so
- indicates the user has logged out.
-
* The /run/systemd/slices directory will always be empty.
- * Support for lingering is not so great.
+ * 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
+http://0pointer.de/blog/projects/cgroups-vs-cgroups.html). 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.
The PAM module is called pam_elogind.so, not pam_systemd.so.
+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
+ --with-cgroup-controller=openrc
+ 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.
+
License
-------