chiark / gitweb /
Merge patches from Hleb Valoshka
[elogind.git] / README
diff --git a/README b/README
index 21a6c18..0cd868a 100644 (file)
--- a/README
+++ b/README
-udev - userspace device management
-
-For more information see the files in the docs/ directory.
-
-Important Note:
-  Integrating udev in the system is a whole lot of work, has complex dependencies
-  and differs a lot from distro to distro. All reasonable distros depend on udev
-  these days and the system will not work without it.
-
-  The upstream udev project does not support or recomend to replace a distro's udev
-  installation with the upstream version. The installation of a unmodified upstream
-  version may render your system unusable! There is no "default" setup or a set
-  of "default" rules provided by the upstream udev version.
-
-Requirements:
-  - 2.6.x version of the Linux kernel. See the RELEASE-NOTES file in the
-    udev tree and the Documentation/Changes in the kernel source tree for
-    the actual dependency.
-
-  - The kernel must have sysfs and unix domain socket enabled.
-    (unix domain sockets (CONFIG_UNIX) as a loadable kernel module may work,
-     but it is completely silly, don't complain if anything goes wrong.)
-
-  - The proc filesystem must be mounted on /proc.
-
-  - The sysfs filesystem must be mounted at /sys. No other location
-    will be supported by udev.
-
-
-Operation:
-  Udev creates and removes device nodes in /dev, based on events the kernel
-  sends out on device discovery or removal.
-
-  - Early in the boot process, /dev should get a tmpfs filesystem
-    mounted, which is populated from scratch by udev. Created nodes or
-    changed permissions will not survive a reboot, which is intentional.
-
-  - The content of /lib/udev/devices directory which contains the nodes,
-    symlinks and directories, which are always expected to be in /dev, should
-    be copied over to the tmpfs mounted /dev, to provide the required nodes
-    to initialize udev and continue booting.
-
-  - The udevd daemon must be started by an init script to receive netlink
-    uevents from the kernel driver core.
-
-  - From kernel version 2.6.15 on, the hotplug helper /sbin/hotplug should
-    be disabled with an init script before actions like loading kernel
-    modules are taken, which may cause a lot of events.
-
-  - All kernel events are matched against a set of specified rules in
-    /etc/udev/rules.d/ which make it possible to hook into the event
-    processing to load required kernel modules and setup devices. For all
-    devices the kernel requests a device node, udev will create one with
-    the default name or the one specified by a matching udev rules.
-
-
-Compile Options:
-  DESTDIR
-       Prefix of install target, used for package building.
-  USE_LOG
-       If set to 'true', udev is able to pass errors or debug information
-       to syslog. This is very useful to see what udev is doing or not doing.
-       It is enabled by default, don't expect any useful answer, if you
-       need to hunt a bug, but you can't enable syslog.
-  DEBUG
-       If set to 'true', very verbose debugging messages will be compiled
-       into the udev binaries. The actual level of debugging is specified
-       in the udev config file.
-  STRIPCMD
-       If udev is compiled for packaging an empty string can be passed
-       to disable the stripping of the binaries.
-  USE_SELINUX
-       If set to 'true', udev will be built with SELinux support
-       enabled.  This is disabled by default.
-  USE_KLIBC
-       If set to 'true', udev is built and linked against klibc.
-       Default value is 'false'. KLCC specifies the klibc compiler
-       wrapper, usually located at /usr/bin/klcc.
-  EXTRAS
-       If set, will build the "extra" helper programs as specified
-       as listed (see below for an example).
-
-If you want to build the udev helper programs:
-  make EXTRAS="extras/cdrom_id extras/scsi_id extras/volume_id"
-
-
-Installation:
-  - The install target intalls the udev binaries in the default locations,
-    All at boot time reqired binaries will be installed in /sbin.
-
-  - The default location for scripts and binaries that are called from
-    rules is /lib/udev. Other packages who install udev rules, should use
-    that directory too.
-
-  - It is recommended to use the /lib/udev/devices directory to place
-    device nodes and symlinks in, which are copied to /dev at every boot.
-    That way, nodes for broken subsystems or devices which can't be
-    detected automatically by the kernel, will always be available.
-
-  - Copies of the rules files for all major distros are in the etc/udev
-    directory (you may look there how others distros are doing it).
-
-  - The persistent disk links in /dev/disk are the de facto standard
-    on Linux and should be installed with every default udev installation.
-    The devfs naming scheme rules are not recommended and not supported.
-
-Please direct any comment/question/concern to the linux-hotplug-devel mailing list at:
-  linux-hotplug-devel@lists.sourceforge.net
+Elogind User, Seat and Session Manager
 
 
+Introduction
+------------
+
+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
+http://www.freedesktop.org/wiki/Software/systemd.  All of the blame
+should go to Andy Wingo, who extracted elogind from systemd.
+
+Contributing
+------------
+
+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:
+
+  https://github.com/elogind/elogind
+
+Send a pull request for the changes you like.
+
+To chat about elogind:
+
+  #guix on irc.freenode.org
+
+Finally, bug reports:
+
+  https://github.com/elogind/elogind/issues
+
+Why bother?
+-----------
+
+Elogind has been developed for use in GuixSD, the OS distribution of
+GNU Guix.  See http://gnu.org/s/guix 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
+libsystemd-logind.
+
+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
+implications:
+
+  * 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
+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, 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
+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
+
+Dependencies
+------------
+
+  glibc >= 2.14
+  libcap
+  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
+dependencies:
+
+  pkg-config
+  docbook-xsl
+  xsltproc
+  automake
+  autoconf
+  libtool
+  intltool
+  gperf
+  gtkdocize (optional)