X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=elogind.git;a=blobdiff_plain;f=README;h=0cd868ade28b70e40163bbb3ddfca44f0e536b8c;hp=06f1fc80cdc749902e629f71f72ea8a73f397800;hb=734744fddd783fec7b19215b24c12e95c00c1e67;hpb=2055a4de39bdf062645a7a58b50aae029df80857

diff --git a/README b/README
index 06f1fc80c..0cd868ade 100644
--- a/README
+++ b/README
@@ -29,7 +29,7 @@ provide a subset of the interfaces of systemd 219.
 
 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.
 
@@ -39,7 +39,7 @@ To chat about elogind:
 
 Finally, bug reports:
 
-  https://github.com/andywingo/elogind/issues
+  https://github.com/elogind/elogind/issues
 
 Why bother?
 -----------
@@ -77,21 +77,26 @@ of <systemd/sd-login.h>.
 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.
 
@@ -111,6 +116,32 @@ flag.
 
 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
 -------