+Elogind User, Seat and Session Manager
-udev - a userspace implementation of devfs
+Introduction
+------------
-For more information on the design, and structure of this project, see the
-files in the docs/ directory.
-
-To use:
-
-- You must be running a 2.6 version of the Linux kernel.
-
-- Your 2.6 kernel must have had CONFIG_HOTPLUG enabled when it was built.
-
-- Make sure sysfs is mounted. udev will figure out where sysfs is mounted, but
- the traditional place for it is at /sys. You can mount it by hand by running:
- mount -t sysfs none /sys
-
-- Make sure you have the latest version of the linux-hotplug scripts. They are
- available at linux-hotplug.sf.net or from your local kernel.org mirror at:
- kernel.org/pub/linux/utils/kernel/hotplug/
- They are required in order for udev to work properly.
-
- If for some reason you do not install the hotplug scripts, you must tell the
- kernel to point the hotplug binary at wherever you install udev at. This can
- be done by:
- echo "/sbin/udev" > /proc/sys/kernel/hotplug
-
-- Build the project:
- make
-
- Note:
- There are a number of different flags that you can use when building
- udev. They are as follows:
- prefix - set this to the default root that you want udev to be
- installed into. This works just like the 'configure --prefix'
- script does. Default value is ''. Only override this if you
- really know what you are doing.
- USE_KLIBC - if set to 'true', udev is built and linked against the included
- version of klibc. Default value is 'false'.
- DEBUG - if set to 'true', debugging messages will be sent to the syslog
- as udev is run. Default value is 'false'.
- USE_DBUS - if set to 'true', DBUS messages will be sent everytime udev
- creates or removes a device node. This requires that DBUS
- development headers and libraries be present on your system to
- build properly. Default value is 'false'.
-
- So, if you want to build udev using klibc with debugging messages, you
- would do:
- make USE_KLIBC=true DEBUG=true
-
- Note: If you want to use klibc, you will have to set up the "linux"
- symlink properly. See the file klibc/klibc/README and pay
- attention to step "a)" there.
-
-- Install the project:
- make install
-
- This will put the udev binary in /sbin, create the /udev and /etc/udev
- directories, and place the udev configuration files in /etc/udev. You
- will probably want to edit the namedev.* files to create custom naming
- rules. More info on how the config files are set up are contained in
- comments in the files, and is located in the documentation.
-
-- Add and remove devices from the system and marvel as nodes are created
- and removed in /udev/ based on the device types.
-
-- If you later get sick of it, uninstall it:
- make uninstall
-
-
-Things are still quite rough, but it should work properly. If nothing
-seems to happen, make sure your build worked properly by running the
-udev-test.pl script as root in the test/ subdirectory of the udev source
-tree.
-
-Development and documentation help is very much appreciated, see the TODO
-file for a list of things left to be done.
-
-
-Any comment/questions/concerns please let me and the other udev developers
-know by sending a message to the linux-hotplug-devel mailing list at:
- linux-hotplug-devel@lists.sourceforge.net
-
-greg k-h
-greg@kroah.com
+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)
~ianmdlvl / elogind.git / blobdiff