chiark / gitweb /
Prep v239: sync manager_get_user_by_pid() with upstream updates
[elogind.git] / README
diff --git a/README b/README
index 928bd7d0c4447d6b3ed1a98cf2cf311069867d4d..ced8cc1641ad517e8680ab41a49d214770e917c0 100644 (file)
--- 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?
 -----------
@@ -54,16 +54,11 @@ 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 --
+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.
+use it as part of some anti-systemd vendetta. We are appreciative of
+the systemd developers logind effort and think that everyone deserves
+to run it if they like. Not matter what kind of PID1 they use.
 
 Differences relative to systemd
 -------------------------------
@@ -77,27 +72,32 @@ 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.
 
 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, hybernate,
+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
@@ -111,42 +111,84 @@ 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
 -------
 
 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
+  - except src/basic/siphash24.c which is CC0 Public Domain
 
 Dependencies
 ------------
 
-  glibc >= 2.14
+  glibc >= 2.16
   libcap
-  libmount >= 2.20 (from util-linux)
-  libseccomp >= 1.0.0 (optional)
+  libmount >= 2.27.1 (from util-linux)
+          (util-linux < 2.29 *must* be built with --enable-libmount-force-mountinfo,
+          and later versions without --enable-libmount-support-mtab.)
+  libseccomp >= 2.3.1 (optional)
   libblkid >= 2.24 (from util-linux) (optional)
   PAM >= 1.1.2 (optional)
   libacl (optional)
   libselinux (optional)
-  make, gcc, and similar tools
+  libpython (optional)
+  pkg-config
+  gperf >= 3.1
+  docbook-xsl (optional, required for documentation)
+  xsltproc    (optional, required for documentation)
+  python-lxml (optional, required to build the indices)
+  python, meson, ninja
+  gcc, awk, sed, grep, m4, and similar tools
 
 During runtime, you need the following additional dependencies:
 
+  util-linux >= v2.27.1 required
   dbus >= 1.4.0 (strictly speaking optional, but recommended)
+          NOTE: If using dbus < 1.9.18, you should override the default
+          policy directory (--with-dbuspolicydir=/etc/dbus-1/system.d).
   PolicyKit (optional)
 
-When building from git, you need the following additional
-dependencies:
+  To build in directory build/:
+    meson build/ && ninja -C build
 
-  pkg-config
-  docbook-xsl
-  xsltproc
-  automake
-  autoconf
-  libtool
-  intltool
-  gperf
-  gtkdocize (optional)
+  Any configuration options can be specified as -Darg=value... arguments
+  to meson. After the build directory is initially configured, the configuration
+  can be changed with:
+    meson configure -Darg=value... build/
+  'meson configure' without any arguments will print out available options and
+  their current values.
+
+  Useful commands:
+    ninja -v some/target
+    ninja test
+    sudo ninja install
+    DESTDIR=... ninja install
+
+  A tarball can be created with:
+    git archive --format=tar --prefix=elogind-238/ v238 | xz > elogind-238.tar.xz