X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=elogind.git;a=blobdiff_plain;f=README;h=0cd868ade28b70e40163bbb3ddfca44f0e536b8c;hp=f37c12a8e06b65008481afb5b2bc66220237e6a8;hb=cac2e345596b2743053c0285280b81794b3aaf10;hpb=98520be72f9a0167df1da3c7b1a4ca2e88c3c831 diff --git a/README b/README index f37c12a8e..0cd868ade 100644 --- a/README +++ b/README @@ -1,94 +1,183 @@ -udev - userspace device management - -For more information see the files in the docs/ directory. - -Important Note: - Integrating udev in the system has complex dependencies and differs from distro - to distro. All major distros depend on udev these days and the system may not - work without a properly installed version. The upstream udev project does not - recommend to replace a distro's udev installation with the upstream version. - -Requirements: - - Version 2.6.15 of the Linux kernel for reliable operation of this release of - udev. The kernel may have a requirement on udev too, see Documentation/Changes - in the kernel source tree for the actual dependency. - - - The kernel must have sysfs, unix domain sockets and networking 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 is supported by udev. - - -Operation: - Udev creates and removes device nodes in /dev, based on events the kernel - sends out on device discovery or removal. - - - Very early in the boot process, the /dev directory 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 old hotplug helper /sbin/hotplug should be disabled on bootup, before - actions like loading kernel modules are taken, which may cause a lot of - events. - - - The udevd daemon must be started on bootup to receive netlink uevents - from the kernel driver core. - - - 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 exports a major/minor number, udev will create a - device node with the default kernel name or the one specified by a - matching udev rule. - - -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. - USE_SELINUX - If set to 'true', udev will be built with SELinux support - enabled. This is disabled by default. - EXTRAS - list of helper programs in extras/ to build. - 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 /lib/udev or /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 the major distros are provided as examples - in the etc/udev directory. - - - The persistent device naming links in /dev/disk/ are required by other - software that depends on the data udev has collected from the devices - and should be installed by default with every udev installation. - -Please direct any comment/question/concern to the linux-hotplug-devel mailing list at: - linux-hotplug@vger.kernel.org +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 , so like instead +of . + +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)