man/elogind.xml

   1 <?xml version='1.0'?> <!--*- Mode: nxml; nxml-child-indent: 2; indent-tabs-mode: nil -*-->
   2 <!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
   3   "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
   4
   5 <!--
   6   This file is part of elogind.
   7   SPDX-License-Identifier: LGPL-2.1+
   8
   9
  10   Copyright 2010 Lennart Poettering
  11
  12   elogind is free software; you can redistribute it and/or modify it
  13   under the terms of the GNU Lesser General Public License as published by
  14   the Free Software Foundation; either version 2.1 of the License, or
  15   (at your option) any later version.
  16
  17   elogind is distributed in the hope that it will be useful, but
  18   WITHOUT ANY WARRANTY; without even the implied warranty of
  19   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
  20   Lesser General Public License for more details.
  21
  22   You should have received a copy of the GNU Lesser General Public License
  23   along with elogind; If not, see <http://www.gnu.org/licenses/>.
  24 -->
  25
  26 <refentry id="elogind"
  27     xmlns:xi="http://www.w3.org/2001/XInclude">
  28
  29   <refentryinfo>
  30     <title>elogind</title>
  31     <productname>elogind</productname>
  32
  33     <authorgroup>
  34       <author>
  35         <contrib>Developer</contrib>
  36         <firstname>Lennart</firstname>
  37         <surname>Poettering</surname>
  38         <email>lennart@poettering.net</email>
  39       </author>
  40     </authorgroup>
  41   </refentryinfo>
  42
  43   <refmeta>
  44     <refentrytitle>elogind</refentrytitle>
  45     <!-- 0 /// elogind is in section 8
  46     <manvolnum>1</manvolnum>
  47     --><!-- else -->
  48     <manvolnum>8</manvolnum>
  49     <!-- // 0 -->
  50   </refmeta>
  51
  52   <refnamediv>
  53     <!-- 0 /// Well, elogind isn't that much...
  54     <refname>systemd</refname>
  55     <refname>init</refname>
  56     <refpurpose>systemd system and service manager</refpurpose>
  57     --><!-- else -->
  58     <refname>elogind</refname>
  59     <refpurpose>Login manager</refpurpose>
  60     <!-- // 0 -->
  61   </refnamediv>
  62
  63   <refsynopsisdiv>
  64     <!-- 0 /// elogind has a different synopsis of course...
  65     <cmdsynopsis>
  66       <command>/usr/lib/systemd/systemd</command>
  67       <arg choice="opt" rep="repeat">OPTIONS</arg>
  68     </cmdsynopsis>
  69     <cmdsynopsis>
  70       <command>init</command>
  71       <arg choice="opt" rep="repeat">OPTIONS</arg>
  72       <arg choice="req">COMMAND</arg>
  73     </cmdsynopsis>
  74     --><!-- else -->
  75     <cmdsynopsis>
  76       <command>elogind</command>
  77       <arg choice="opt" rep="repeat">OPTIONS</arg>
  78       <arg choice="req">COMMAND</arg>
  79     </cmdsynopsis>
  80     <!-- // 0 -->
  81   </refsynopsisdiv>
  82
  83   <refsect1>
  84     <title>Description</title>
  85
  86     <!-- 0 /// elogind does not need that much explanation.
  87     <para>systemd is a system and service manager for Linux operating
  88     systems. When run as first process on boot (as PID 1), it acts as
  89     init system that brings up and maintains userspace
  90     services.</para>
  91
  92     <para>For compatibility with SysV, if systemd is called as
  93     <command>init</command> and a PID that is not 1, it will execute
  94     <command>telinit</command> and pass all command line arguments
  95     unmodified. That means <command>init</command> and
  96     <command>telinit</command> are mostly equivalent when invoked from
  97     normal login sessions. See
  98     <citerefentry><refentrytitle>telinit</refentrytitle><manvolnum>8</manvolnum></citerefentry>
  99     for more information.</para>
 100
 101     <para>When run as a system instance, systemd interprets the
 102     configuration file <filename>system.conf</filename> and the files
 103     in <filename>system.conf.d</filename> directories; when run as a
 104     user instance, systemd interprets the configuration file
 105     <filename>user.conf</filename> and the files in
 106     <filename>user.conf.d</filename> directories. See
 107     <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
 108     for more information.</para>
 109     --><!-- else -->
 110     <para><command>elogind</command> is a system service that
 111     manages user logins. It is responsible for:</para>
 112
 113     <itemizedlist>
 114       <listitem><para>Keeping track of users and sessions, their
 115       processes and their idle state</para></listitem>
 116
 117       <listitem><para>Providing PolicyKit-based access for users to
 118       operations such as system shutdown or sleep</para></listitem>
 119
 120       <listitem><para>Implementing a shutdown/sleep inhibition logic
 121       for applications</para></listitem>
 122
 123       <listitem><para>Handling of power/sleep hardware
 124       keys</para></listitem>
 125
 126       <listitem><para>Multi-seat management</para></listitem>
 127
 128       <listitem><para>Session switch management</para></listitem>
 129
 130       <listitem><para>Device access management for
 131       users</para></listitem>
 132
 133     </itemizedlist>
 134
 135     <para>User sessions are registered in elogind via the
 136     <citerefentry><refentrytitle>pam_elogind</refentrytitle><manvolnum>8</manvolnum></citerefentry>
 137     PAM module.</para>
 138
 139     <para>See
 140     <citerefentry><refentrytitle>logind.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
 141     for information about the configuration of this service.</para>
 142
 143     <para>See <ulink
 144     url="http://www.freedesktop.org/wiki/Software/systemd/multiseat">Multi-Seat
 145     on Linux</ulink> for an introduction into basic concepts of logind
 146     such as users, sessions and seats.</para>
 147
 148     <para>See the <ulink
 149     url="http://www.freedesktop.org/wiki/Software/systemd/logind">
 150     logind D-Bus API Documentation</ulink> for information about the
 151     APIs <filename>logind</filename> provides.</para>
 152
 153     <para>For more information on the inhibition logic see the <ulink
 154     url="http://www.freedesktop.org/wiki/Software/systemd/inhibit">Inhibitor
 155     Lock Developer Documentation</ulink>.</para>
 156   <!-- // 0 -->
 157   </refsect1>
 158
 159   <refsect1>
 160     <title>Options</title>
 161
 162     <para>The following options are understood:</para>
 163
 164     <variablelist>
 165     <!-- 0 /// This list is much shorter with elogind of course.
 166       <varlistentry>
 167         <term><option>&#x2D;&#x2D;test</option></term>
 168
 169         <listitem><para>Determine startup sequence, dump it and exit.
 170         This is an option useful for debugging only.</para></listitem>
 171       </varlistentry>
 172       <varlistentry>
 173         <term><option>&#x2D;&#x2D;dump-configuration-items</option></term>
 174
 175         <listitem><para>Dump understood unit configuration items. This
 176         outputs a terse but complete list of configuration items
 177         understood in unit definition files.</para></listitem>
 178       </varlistentry>
 179       <varlistentry>
 180         <term><option>&#x2D;&#x2D;unit=</option></term>
 181
 182         <listitem><para>Set default unit to activate on startup. If
 183         not specified, defaults to
 184         <filename>default.target</filename>.</para></listitem>
 185       </varlistentry>
 186       <varlistentry>
 187         <term><option>&#x2D;&#x2D;system</option></term>
 188         <term><option>&#x2D;&#x2D;user</option></term>
 189
 190         <listitem><para>For <option>&#x2D;&#x2D;system</option>, tell systemd to
 191         run a system instance, even if the process ID is not 1, i.e.
 192         systemd is not run as init process. <option>&#x2D;&#x2D;user</option>
 193         does the opposite, running a user instance even if the process
 194         ID is 1. Normally, it should not be necessary to pass these
 195         options, as systemd automatically detects the mode it is
 196         started in. These options are hence of little use except for
 197         debugging. Note that it is not supported booting and
 198         maintaining a full system with systemd running in
 199         <option>&#x2D;&#x2D;system</option> mode, but PID not 1. In practice,
 200         passing <option>&#x2D;&#x2D;system</option> explicitly is only useful in
 201         conjunction with <option>&#x2D;&#x2D;test</option>.</para></listitem>
 202       </varlistentry>
 203       <varlistentry>
 204         <term><option>&#x2D;&#x2D;dump-core</option></term>
 205
 206         <listitem><para>Enable core dumping on crash. This switch has
 207         no effect when running as user instance. This setting may also
 208         be enabled during boot on the kernel command line via the
 209         <varname>systemd.dump_core=</varname> option, see
 210         below.</para></listitem>
 211       </varlistentry>
 212
 213       <varlistentry>
 214         <term><option>&#x2D;&#x2D;crash-vt=</option><replaceable>VT</replaceable></term>
 215
 216         <listitem><para>Switch to a specific virtual console (VT) on
 217         crash. Takes a positive integer in the range 1–63, or a
 218         boolean argument. If an integer is passed, selects which VT to
 219         switch to. If <constant>yes</constant>, the VT kernel messages
 220         are written to is selected. If <constant>no</constant>, no VT
 221         switch is attempted. This switch has no effect when running as
 222         user instance. This setting may also be enabled during boot,
 223         on the kernel command line via the
 224         <varname>systemd.crash_vt=</varname> option, see
 225         // 0 -->
 226         <!-- FIXME: there is no crash_vt command line option? -->
 227         <!-- 0 /// elogind check_tree.pl can not mangle closed comments.
 228         below.</para></listitem>
 229       </varlistentry>
 230
 231       <varlistentry>
 232         <term><option>&#x2D;&#x2D;crash-shell</option></term>
 233
 234         <listitem><para>Run a shell on crash. This switch has no
 235         effect when running as user instance. This setting may also be
 236         enabled during boot, on the kernel command line via the
 237         <varname>systemd.crash_shell=</varname> option, see
 238         below.</para></listitem>
 239       </varlistentry>
 240
 241       <varlistentry>
 242         <term><option>&#x2D;&#x2D;crash-reboot</option></term>
 243
 244         <listitem><para>Automatically reboot the system on crash. This
 245         switch has no effect when running as user instance. This
 246         setting may also be enabled during boot, on the kernel command
 247         line via the <varname>systemd.crash_reboot=</varname> option,
 248         see below.</para></listitem>
 249       </varlistentry>
 250
 251       <varlistentry>
 252         <term><option>&#x2D;&#x2D;confirm-spawn</option></term>
 253
 254         <listitem><para>Ask for confirmation when spawning processes.
 255         This switch has no effect when run as user
 256         instance.</para></listitem>
 257       </varlistentry>
 258       <varlistentry>
 259         <term><option>&#x2D;&#x2D;show-status=</option></term>
 260
 261         <listitem><para>Takes a boolean argument or the special value <constant>auto</constant>. If on, terse unit
 262         status information is shown on the console during boot-up and shutdown. If off, no such status information is
 263         shown. If set to <constant>auto</constant> behavior is similar to off, except that it is automatically switched
 264         to on, as soon as the first unit failure or significant boot delay is encountered. This switch has no effect
 265         when invoked as user instance. If specified, overrides both the kernel command line setting
 266         <varname>systemd.show_status=</varname> (see below) and the configuration file option
 267         <option>ShowStatus=</option>, see
 268         <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
 269       </varlistentry>
 270       <varlistentry>
 271         <term><option>&#x2D;&#x2D;log-target=</option></term>
 272
 273         <listitem><para>Set log target. Argument must be one of
 274         <option>console</option>,
 275         <option>journal</option>,
 276         <option>kmsg</option>,
 277         <option>journal-or-kmsg</option>,
 278         <option>null</option>.</para></listitem>
 279       </varlistentry>
 280       <varlistentry>
 281         <term><option>&#x2D;&#x2D;log-level=</option></term>
 282
 283         <listitem><para>Set log level. As
 284         argument this accepts a numerical log
 285         level or the well-known <citerefentry project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>
 286         symbolic names (lowercase):
 287         <option>emerg</option>,
 288         <option>alert</option>,
 289         <option>crit</option>,
 290         <option>err</option>,
 291         <option>warning</option>,
 292         <option>notice</option>,
 293         <option>info</option>,
 294         <option>debug</option>.</para></listitem>
 295       </varlistentry>
 296       <varlistentry>
 297         <term><option>&#x2D;&#x2D;log-color=</option></term>
 298
 299         <listitem><para>Highlight important log messages. Argument is
 300         a boolean value. If the argument is omitted, it defaults to
 301         <option>true</option>.</para></listitem>
 302       </varlistentry>
 303       <varlistentry>
 304         <term><option>&#x2D;&#x2D;log-location=</option></term>
 305
 306         <listitem><para>Include code location in log messages. This is
 307         mostly relevant for debugging purposes. Argument is a boolean
 308         value. If the argument is omitted it defaults to
 309         <option>true</option>.</para></listitem>
 310       </varlistentry>
 311       <varlistentry>
 312         <term><option>&#x2D;&#x2D;default-standard-output=</option></term>
 313         <term><option>&#x2D;&#x2D;default-standard-error=</option></term>
 314
 315         <listitem><para>Sets the default output or error output for
 316         all services and sockets, respectively. That is, controls the
 317         default for <option>StandardOutput=</option> and
 318         <option>StandardError=</option> (see
 319         <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
 320         for details). Takes one of
 321         <option>inherit</option>,
 322         <option>null</option>,
 323         <option>tty</option>,
 324         <option>journal</option>,
 325         <option>journal+console</option>,
 326         <option>syslog</option>,
 327         <option>syslog+console</option>,
 328         <option>kmsg</option>,
 329         <option>kmsg+console</option>.  If the
 330         argument is omitted
 331         <option>&#x2D;&#x2D;default-standard-output=</option> defaults to
 332         <option>journal</option> and
 333         <option>&#x2D;&#x2D;default-standard-error=</option> to
 334         <option>inherit</option>.</para></listitem>
 335       </varlistentry>
 336
 337       <varlistentry>
 338         <term><option>&#x2D;&#x2D;machine-id=</option></term>
 339
 340         <listitem><para>Override the machine-id set on the hard drive,
 341         useful for network booting or for containers. May not be set
 342         to all zeros.</para></listitem>
 343       </varlistentry>
 344
 345       <xi:include href="standard-options.xml" xpointer="help" />
 346       <xi:include href="standard-options.xml" xpointer="version" />
 347       else -->
 348       <varlistentry>
 349         <term><option>-D</option></term>
 350         <term><option>--daemon</option></term>
 351
 352         <listitem><para>Daemonize elogind by double-forking
 353         into background.</para></listitem>
 354       </varlistentry>
 355
 356       <varlistentry>
 357         <term><option>-h</option></term>
 358         <term><option>--help</option></term>
 359
 360         <listitem><para>Show the helpt text and exit.</para></listitem>
 361       </varlistentry>
 362       <!-- // 0 -->
 363     </variablelist>
 364   </refsect1>
 365
 366   <!-- 0 /// The whole concpets section is unneeded in elogind
 367   <refsect1>
 368     <title>Concepts</title>
 369
 370     <para>systemd provides a dependency system between various
 371     entities called "units" of 11 different types. Units encapsulate
 372     various objects that are relevant for system boot-up and
 373     maintenance. The majority of units are configured in unit
 374     configuration files, whose syntax and basic set of options is
 375     described in
 376     <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
 377     however some are created automatically from other configuration,
 378     dynamically from system state or programmatically at runtime.
 379     Units may be "active" (meaning started, bound, plugged in, …,
 380     depending on the unit type, see below), or "inactive" (meaning
 381     stopped, unbound, unplugged, …), as well as in the process of
 382     being activated or deactivated, i.e. between the two states (these
 383     states are called "activating", "deactivating"). A special
 384     "failed" state is available as well, which is very similar to
 385     "inactive" and is entered when the service failed in some way
 386     (process returned error code on exit, or crashed, or an operation
 387     timed out). If this state is entered, the cause will be logged,
 388     for later reference. Note that the various unit types may have a
 389     number of additional substates, which are mapped to the five
 390     generalized unit states described here.</para>
 391
 392     <para>The following unit types are available:</para>
 393
 394     <orderedlist>
 395       <listitem><para>Service units, which start and control daemons
 396       and the processes they consist of. For details, see
 397       <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
 398
 399       <listitem><para>Socket units, which encapsulate local IPC or
 400       network sockets in the system, useful for socket-based
 401       activation. For details about socket units, see
 402       <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
 403       for details on socket-based activation and other forms of
 404       activation, see
 405       <citerefentry><refentrytitle>daemon</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para></listitem>
 406
 407       <listitem><para>Target units are useful to group units, or
 408       provide well-known synchronization points during boot-up, see
 409       <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
 410
 411       <listitem><para>Device units expose kernel devices in systemd
 412       and may be used to implement device-based activation. For
 413       details, see
 414       <citerefentry><refentrytitle>systemd.device</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
 415
 416       <listitem><para>Mount units control mount points in the file
 417       system, for details see
 418       <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
 419
 420       <listitem><para>Automount units provide automount capabilities,
 421       for on-demand mounting of file systems as well as parallelized
 422       boot-up. See
 423       <citerefentry><refentrytitle>systemd.automount</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
 424
 425       <listitem><para>Timer units are useful for triggering activation
 426       of other units based on timers. You may find details in
 427       <citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
 428
 429       <listitem><para>Swap units are very similar to mount units and
 430       encapsulate memory swap partitions or files of the operating
 431       system. They are described in
 432       <citerefentry><refentrytitle>systemd.swap</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
 433
 434       <listitem><para>Path units may be used to activate other
 435       services when file system objects change or are modified. See
 436       <citerefentry><refentrytitle>systemd.path</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
 437
 438       <listitem><para>Slice units may be used to group units which
 439       manage system processes (such as service and scope units) in a
 440       hierarchical tree for resource management purposes. See
 441       <citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
 442
 443       <listitem><para>Scope units are similar to service units, but
 444       manage foreign processes instead of starting them as well. See
 445       <citerefentry><refentrytitle>systemd.scope</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
 446
 447     </orderedlist>
 448
 449     <para>Units are named as their configuration files. Some units
 450     have special semantics. A detailed list is available in
 451     <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
 452
 453     <para>systemd knows various kinds of dependencies, including
 454     positive and negative requirement dependencies (i.e.
 455     <varname>Requires=</varname> and <varname>Conflicts=</varname>) as
 456     well as ordering dependencies (<varname>After=</varname> and
 457     <varname>Before=</varname>). NB: ordering and requirement
 458     dependencies are orthogonal. If only a requirement dependency
 459     exists between two units (e.g. <filename>foo.service</filename>
 460     requires <filename>bar.service</filename>), but no ordering
 461     dependency (e.g. <filename>foo.service</filename> after
 462     <filename>bar.service</filename>) and both are requested to start,
 463     they will be started in parallel. It is a common pattern that both
 464     requirement and ordering dependencies are placed between two
 465     units. Also note that the majority of dependencies are implicitly
 466     created and maintained by systemd. In most cases, it should be
 467     unnecessary to declare additional dependencies manually, however
 468     it is possible to do this.</para>
 469
 470     <para>Application programs and units (via dependencies) may
 471     request state changes of units. In systemd, these requests are
 472     encapsulated as 'jobs' and maintained in a job queue. Jobs may
 473     succeed or can fail, their execution is ordered based on the
 474     ordering dependencies of the units they have been scheduled
 475     for.</para>
 476
 477     <para>On boot systemd activates the target unit
 478     <filename>default.target</filename> whose job is to activate
 479     on-boot services and other on-boot units by pulling them in via
 480     dependencies. Usually, the unit name is just an alias (symlink) for
 481     either <filename>graphical.target</filename> (for fully-featured
 482     boots into the UI) or <filename>multi-user.target</filename> (for
 483     limited console-only boots for use in embedded or server
 484     environments, or similar; a subset of graphical.target). However,
 485     it is at the discretion of the administrator to configure it as an
 486     alias to any other target unit. See
 487     <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>
 488     for details about these target units.</para>
 489
 490     <para>Processes systemd spawns are placed in individual Linux
 491     control groups named after the unit which they belong to in the
 492     private systemd hierarchy. (see <ulink
 493     url="https://www.kernel.org/doc/Documentation/cgroups/cgroups.txt">cgroups.txt</ulink>
 494     for more information about control groups, or short "cgroups").
 495     systemd uses this to effectively keep track of processes. Control
 496     group information is maintained in the kernel, and is accessible
 497     via the file system hierarchy (beneath
 498     <filename>/sys/fs/cgroup/systemd/</filename>), or in tools such as
 499     <citerefentry project='man-pages'><refentrytitle>systemd-cgls</refentrytitle><manvolnum>1</manvolnum></citerefentry>
 500     or
 501     <citerefentry project='man-pages'><refentrytitle>ps</refentrytitle><manvolnum>1</manvolnum></citerefentry>
 502     (<command>ps xawf -eo pid,user,cgroup,args</command> is
 503     particularly useful to list all processes and the systemd units
 504     they belong to.).</para>
 505
 506     <para>systemd is compatible with the SysV init system to a large
 507     degree: SysV init scripts are supported and simply read as an
 508     alternative (though limited) configuration file format. The SysV
 509     <filename>/dev/initctl</filename> interface is provided, and
 510     compatibility implementations of the various SysV client tools are
 511     available. In addition to that, various established Unix
 512     functionality such as <filename>/etc/fstab</filename> or the
 513     <filename>utmp</filename> database are supported.</para>
 514
 515     <para>systemd has a minimal transaction system: if a unit is
 516     requested to start up or shut down it will add it and all its
 517     dependencies to a temporary transaction. Then, it will verify if
 518     the transaction is consistent (i.e. whether the ordering of all
 519     units is cycle-free). If it is not, systemd will try to fix it up,
 520     and removes non-essential jobs from the transaction that might
 521     remove the loop. Also, systemd tries to suppress non-essential
 522     jobs in the transaction that would stop a running service. Finally
 523     it is checked whether the jobs of the transaction contradict jobs
 524     that have already been queued, and optionally the transaction is
 525     aborted then. If all worked out and the transaction is consistent
 526     and minimized in its impact it is merged with all already
 527     outstanding jobs and added to the run queue. Effectively this
 528     means that before executing a requested operation, systemd will
 529     verify that it makes sense, fixing it if possible, and only
 530     failing if it really cannot work.</para>
 531
 532     <para>systemd contains native implementations of various tasks
 533     that need to be executed as part of the boot process. For example,
 534     it sets the hostname or configures the loopback network device. It
 535     also sets up and mounts various API file systems, such as
 536     <filename>/sys</filename> or <filename>/proc</filename>.</para>
 537
 538     <para>For more information about the concepts and
 539     ideas behind systemd, please refer to the
 540     <ulink url="http://0pointer.de/blog/projects/systemd.html">Original Design Document</ulink>.</para>
 541
 542     <para>Note that some but not all interfaces provided
 543     by systemd are covered by the
 544     <ulink url="https://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise">Interface
 545     Stability Promise</ulink>.</para>
 546
 547     <para>Units may be generated dynamically at boot and system
 548     manager reload time, for example based on other configuration
 549     files or parameters passed on the kernel command line. For details, see
 550     <citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
 551
 552     <para>Systems which invoke systemd in a container or initrd
 553     environment should implement the
 554     <ulink url="https://www.freedesktop.org/wiki/Software/systemd/ContainerInterface">Container Interface</ulink> or
 555     <ulink url="https://www.freedesktop.org/wiki/Software/systemd/InitrdInterface">initrd Interface</ulink>
 556     specifications, respectively.</para>
 557   </refsect1>
 558   // 0 -->
 559
 560   <!-- 0 /// The whole directories section is unneeded in elogind
 561   <refsect1>
 562     <title>Directories</title>
 563
 564     <variablelist>
 565       <varlistentry>
 566         <term>System unit directories</term>
 567
 568         <listitem><para>The systemd system manager reads unit
 569         configuration from various directories. Packages that want to
 570         install unit files shall place them in the directory returned
 571         by <command>pkg-config systemd
 572         &#x2D;&#x2D;variable=systemdsystemunitdir</command>. Other directories
 573         checked are <filename>/usr/local/lib/systemd/system</filename>
 574         and <filename>/usr/lib/systemd/system</filename>. User
 575         configuration always takes precedence. <command>pkg-config
 576         systemd &#x2D;&#x2D;variable=systemdsystemconfdir</command> returns the
 577         path of the system configuration directory. Packages should
 578         alter the content of these directories only with the
 579         <command>enable</command> and <command>disable</command>
 580         commands of the
 581         <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
 582         tool. Full list of directories is provided in
 583         <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
 584         </para></listitem>
 585       </varlistentry>
 586     </variablelist>
 587
 588     <variablelist>
 589       <varlistentry>
 590         <term>User unit directories</term>
 591
 592         <listitem><para>Similar rules apply for the user unit
 593         directories. However, here the
 594         <ulink url="http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html">XDG
 595         Base Directory specification</ulink> is followed to find
 596         units. Applications should place their unit files in the
 597         directory returned by <command>pkg-config systemd
 598         &#x2D;&#x2D;variable=systemduserunitdir</command>. Global configuration
 599         is done in the directory reported by <command>pkg-config
 600         systemd &#x2D;&#x2D;variable=systemduserconfdir</command>. The
 601         <command>enable</command> and <command>disable</command>
 602         commands of the
 603         <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
 604         tool can handle both global (i.e. for all users) and private
 605         (for one user) enabling/disabling of units. Full list of
 606         directories is provided in
 607         <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
 608         </para></listitem>
 609       </varlistentry>
 610     </variablelist>
 611
 612     <variablelist>
 613       <varlistentry>
 614         <term>SysV init scripts directory</term>
 615
 616         <listitem><para>The location of the SysV init script directory
 617         varies between distributions. If systemd cannot find a native
 618         unit file for a requested service, it will look for a SysV
 619         init script of the same name (with the
 620         <filename>.service</filename> suffix
 621         removed).</para></listitem>
 622       </varlistentry>
 623     </variablelist>
 624
 625     <variablelist>
 626       <varlistentry>
 627         <term>SysV runlevel link farm directory</term>
 628
 629         <listitem><para>The location of the SysV runlevel link farm
 630         directory varies between distributions. systemd will take the
 631         link farm into account when figuring out whether a service
 632         shall be enabled. Note that a service unit with a native unit
 633         configuration file cannot be started by activating it in the
 634         SysV runlevel link farm.</para></listitem>
 635       </varlistentry>
 636     </variablelist>
 637   </refsect1>
 638   // 0 -->
 639
 640   <!-- 0 /// The whole Signals section is unneeded in elogind
 641   <refsect1>
 642     <title>Signals</title>
 643
 644     <variablelist>
 645       <varlistentry>
 646         <term><constant>SIGTERM</constant></term>
 647
 648         <listitem><para>Upon receiving this signal the systemd system
 649         manager serializes its state, reexecutes itself and
 650         deserializes the saved state again. This is mostly equivalent
 651         to <command>systemctl daemon-reexec</command>.</para>
 652
 653         <para>systemd user managers will start the
 654         <filename>exit.target</filename> unit when this signal is
 655         received. This is mostly equivalent to <command>systemctl
 656         &#x2D;&#x2D;user start exit.target
 657         &#x2D;&#x2D;job-mode=replace-irreversible</command>.</para></listitem>
 658       </varlistentry>
 659
 660       <varlistentry>
 661         <term><constant>SIGINT</constant></term>
 662
 663         <listitem><para>Upon receiving this signal the systemd system
 664         manager will start the
 665         <filename>ctrl-alt-del.target</filename> unit. This is mostly
 666         equivalent to <command>systemctl start ctl-alt-del.target
 667         &#x2D;&#x2D;job-mode=replace-irreversible</command>. If this signal is
 668         received more than 7 times per 2s, an immediate reboot is
 669         triggered.  Note that pressing Ctrl-Alt-Del on the console
 670         will trigger this signal. Hence, if a reboot is hanging,
 671         pressing Ctrl-Alt-Del more than 7 times in 2s is a relatively
 672         safe way to trigger an immediate reboot.</para>
 673
 674         <para>systemd user managers treat this signal the same way as
 675         <constant>SIGTERM</constant>.</para></listitem>
 676       </varlistentry>
 677
 678       <varlistentry>
 679         <term><constant>SIGWINCH</constant></term>
 680
 681         <listitem><para>When this signal is received the systemd
 682         system manager will start the
 683         <filename>kbrequest.target</filename> unit. This is mostly
 684         equivalent to <command>systemctl start
 685         kbrequest.target</command>.</para>
 686
 687         <para>This signal is ignored by systemd user
 688         managers.</para></listitem>
 689       </varlistentry>
 690
 691       <varlistentry>
 692         <term><constant>SIGPWR</constant></term>
 693
 694         <listitem><para>When this signal is received the systemd
 695         manager will start the <filename>sigpwr.target</filename>
 696         unit. This is mostly equivalent to <command>systemctl start
 697         sigpwr.target</command>.</para></listitem>
 698       </varlistentry>
 699
 700       <varlistentry>
 701         <term><constant>SIGUSR1</constant></term>
 702
 703         <listitem><para>When this signal is received the systemd
 704         manager will try to reconnect to the D-Bus
 705         bus.</para></listitem>
 706       </varlistentry>
 707
 708       <varlistentry>
 709         <term><constant>SIGUSR2</constant></term>
 710
 711         <listitem><para>When this signal is received the systemd
 712         manager will log its complete state in human-readable form.
 713         The data logged is the same as printed by
 714         <command>systemd-analyze dump</command>.</para></listitem>
 715       </varlistentry>
 716
 717       <varlistentry>
 718         <term><constant>SIGHUP</constant></term>
 719
 720         <listitem><para>Reloads the complete daemon configuration.
 721         This is mostly equivalent to <command>systemctl
 722         daemon-reload</command>.</para></listitem>
 723       </varlistentry>
 724
 725       <varlistentry>
 726         <term><constant>SIGRTMIN+0</constant></term>
 727
 728         <listitem><para>Enters default mode, starts the
 729         <filename>default.target</filename> unit. This is mostly
 730         equivalent to <command>systemctl isolate
 731         default.target</command>.</para></listitem>
 732       </varlistentry>
 733
 734       <varlistentry>
 735         <term><constant>SIGRTMIN+1</constant></term>
 736
 737         <listitem><para>Enters rescue mode, starts the
 738         <filename>rescue.target</filename> unit. This is mostly
 739         equivalent to <command>systemctl isolate
 740         rescue.target</command>.</para></listitem>
 741       </varlistentry>
 742
 743       <varlistentry>
 744         <term><constant>SIGRTMIN+2</constant></term>
 745
 746         <listitem><para>Enters emergency mode, starts the
 747         <filename>emergency.service</filename> unit. This is mostly
 748         equivalent to <command>systemctl isolate
 749         emergency.service</command>.</para></listitem>
 750       </varlistentry>
 751
 752       <varlistentry>
 753         <term><constant>SIGRTMIN+3</constant></term>
 754
 755         <listitem><para>Halts the machine, starts the
 756         <filename>halt.target</filename> unit. This is mostly
 757         equivalent to <command>systemctl start halt.target
 758         &#x2D;&#x2D;job-mode=replace-irreversible</command>.</para>
 759         </listitem>
 760       </varlistentry>
 761
 762       <varlistentry>
 763         <term><constant>SIGRTMIN+4</constant></term>
 764
 765         <listitem><para>Powers off the machine, starts the
 766         <filename>poweroff.target</filename> unit. This is mostly
 767         equivalent to <command>systemctl start poweroff.target
 768         &#x2D;&#x2D;job-mode=replace-irreversible</command>.</para>
 769         </listitem>
 770       </varlistentry>
 771
 772       <varlistentry>
 773         <term><constant>SIGRTMIN+5</constant></term>
 774
 775         <listitem><para>Reboots the machine, starts the
 776         <filename>reboot.target</filename> unit. This is mostly
 777         equivalent to <command>systemctl start reboot.target
 778         &#x2D;&#x2D;job-mode=replace-irreversible</command>.</para>
 779         </listitem>
 780       </varlistentry>
 781
 782       <varlistentry>
 783         <term><constant>SIGRTMIN+6</constant></term>
 784
 785         <listitem><para>Reboots the machine via kexec, starts the
 786         <filename>kexec.target</filename> unit. This is mostly
 787         equivalent to <command>systemctl start kexec.target
 788         &#x2D;&#x2D;job-mode=replace-irreversible</command>.</para>
 789         </listitem>
 790       </varlistentry>
 791
 792       <varlistentry>
 793         <term><constant>SIGRTMIN+13</constant></term>
 794
 795         <listitem><para>Immediately halts the machine.</para></listitem>
 796       </varlistentry>
 797
 798       <varlistentry>
 799         <term><constant>SIGRTMIN+14</constant></term>
 800
 801         <listitem><para>Immediately powers off the machine.</para></listitem>
 802       </varlistentry>
 803
 804       <varlistentry>
 805         <term><constant>SIGRTMIN+15</constant></term>
 806
 807         <listitem><para>Immediately reboots the machine.</para></listitem>
 808       </varlistentry>
 809
 810       <varlistentry>
 811         <term><constant>SIGRTMIN+16</constant></term>
 812
 813         <listitem><para>Immediately reboots the machine with kexec.</para></listitem>
 814       </varlistentry>
 815
 816       <varlistentry>
 817         <term><constant>SIGRTMIN+20</constant></term>
 818
 819         <listitem><para>Enables display of status messages on the
 820         console, as controlled via
 821         <varname>systemd.show_status=1</varname> on the kernel command
 822         line.</para></listitem>
 823       </varlistentry>
 824
 825       <varlistentry>
 826         <term><constant>SIGRTMIN+21</constant></term>
 827
 828         <listitem><para>Disables display of
 829         status messages on the console, as
 830         controlled via
 831         <varname>systemd.show_status=0</varname>
 832         on the kernel command
 833         line.</para></listitem>
 834       </varlistentry>
 835
 836       <varlistentry>
 837         <term><constant>SIGRTMIN+22</constant></term>
 838         <term><constant>SIGRTMIN+23</constant></term>
 839
 840         <listitem><para>Sets the log level to <literal>debug</literal>
 841         (or <literal>info</literal> on
 842         <constant>SIGRTMIN+23</constant>), as controlled via
 843         <varname>systemd.log_level=debug</varname> (or
 844         <varname>systemd.log_level=info</varname> on
 845         <constant>SIGRTMIN+23</constant>) on the kernel command
 846         line.</para></listitem>
 847       </varlistentry>
 848
 849       <varlistentry>
 850         <term><constant>SIGRTMIN+24</constant></term>
 851
 852         <listitem><para>Immediately exits the manager (only available
 853         for &#x2D;&#x2D;user instances).</para></listitem>
 854       </varlistentry>
 855
 856       <varlistentry>
 857         <term><constant>SIGRTMIN+26</constant></term>
 858         <term><constant>SIGRTMIN+27</constant></term>
 859         <term><constant>SIGRTMIN+28</constant></term>
 860
 861         <listitem><para>Sets the log target to
 862         <literal>journal-or-kmsg</literal> (or
 863         <literal>console</literal> on
 864         <constant>SIGRTMIN+27</constant>, <literal>kmsg</literal> on
 865         <constant>SIGRTMIN+28</constant>), as controlled via
 866         <varname>systemd.log_target=journal-or-kmsg</varname> (or
 867         <varname>systemd.log_target=console</varname> on
 868         <constant>SIGRTMIN+27</constant> or
 869         <varname>systemd.log_target=kmsg</varname> on
 870         <constant>SIGRTMIN+28</constant>) on the kernel command
 871         line.</para></listitem>
 872       </varlistentry>
 873     </variablelist>
 874   </refsect1>
 875   // 0 -->
 876
 877   <!-- 0 /// The whole environment section is unneeded in elogind
 878   <refsect1>
 879     <title>Environment</title>
 880
 881     <variablelist class='environment-variables'>
 882       <varlistentry>
 883         <term><varname>$SYSTEMD_LOG_LEVEL</varname></term>
 884         <listitem><para>systemd reads the log level from this
 885         environment variable. This can be overridden with
 886         <option>&#x2D;&#x2D;log-level=</option>.</para></listitem>
 887       </varlistentry>
 888
 889       <varlistentry>
 890         <term><varname>$SYSTEMD_LOG_TARGET</varname></term>
 891         <listitem><para>systemd reads the log target from this
 892         environment variable. This can be overridden with
 893         <option>&#x2D;&#x2D;log-target=</option>.</para></listitem>
 894       </varlistentry>
 895
 896       <varlistentry>
 897         <term><varname>$SYSTEMD_LOG_COLOR</varname></term>
 898         <listitem><para>Controls whether systemd highlights important
 899         log messages. This can be overridden with
 900         <option>&#x2D;&#x2D;log-color=</option>.</para></listitem>
 901       </varlistentry>
 902
 903       <varlistentry>
 904         <term><varname>$SYSTEMD_LOG_LOCATION</varname></term>
 905         <listitem><para>Controls whether systemd prints the code
 906         location along with log messages. This can be overridden with
 907         <option>&#x2D;&#x2D;log-location=</option>.</para></listitem>
 908       </varlistentry>
 909
 910       <varlistentry>
 911         <term><varname>$XDG_CONFIG_HOME</varname></term>
 912         <term><varname>$XDG_CONFIG_DIRS</varname></term>
 913         <term><varname>$XDG_DATA_HOME</varname></term>
 914         <term><varname>$XDG_DATA_DIRS</varname></term>
 915
 916         <listitem><para>The systemd user manager uses these variables
 917         in accordance to the <ulink
 918         url="http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html">XDG
 919         Base Directory specification</ulink> to find its
 920         configuration.</para></listitem>
 921       </varlistentry>
 922
 923       <varlistentry>
 924         <term><varname>$SYSTEMD_UNIT_PATH</varname></term>
 925
 926         <listitem><para>Controls where systemd looks for unit
 927         files.</para></listitem>
 928       </varlistentry>
 929
 930       <varlistentry>
 931         <term><varname>$SYSTEMD_SYSVINIT_PATH</varname></term>
 932
 933         <listitem><para>Controls where systemd looks for SysV init
 934         scripts.</para></listitem>
 935       </varlistentry>
 936
 937       <varlistentry>
 938         <term><varname>$SYSTEMD_SYSVRCND_PATH</varname></term>
 939
 940         <listitem><para>Controls where systemd looks for SysV init
 941         script runlevel link farms.</para></listitem>
 942       </varlistentry>
 943
 944       <varlistentry>
 945         <term><varname>$SYSTEMD_COLORS</varname></term>
 946
 947         <listitem><para>The value must be a boolean. Controls whether colorized output should be
 948         generated. This can be specified to override the decision that <command>systemd</command>
 949         makes based on <varname>$TERM</varname> and what the console is connected to.</para>
 950         </listitem>
 951       </varlistentry>
 952
 953       <varlistentry>
 954         <term><varname>$LISTEN_PID</varname></term>
 955         <term><varname>$LISTEN_FDS</varname></term>
 956         <term><varname>$LISTEN_FDNAMES</varname></term>
 957
 958         <listitem><para>Set by systemd for supervised processes during
 959         socket-based activation. See
 960         <citerefentry><refentrytitle>sd_listen_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry>
 961         for more information.</para></listitem>
 962       </varlistentry>
 963
 964       <varlistentry>
 965         <term><varname>$NOTIFY_SOCKET</varname></term>
 966
 967         <listitem><para>Set by systemd for supervised processes for
 968         status and start-up completion notification. See
 969         <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>
 970         for more information.</para></listitem>
 971       </varlistentry>
 972     </variablelist>
 973   </refsect1>
 974   // 0 -->
 975
 976   <!-- 0 /// The whole kernel section is unneeded in elogind
 977   <refsect1>
 978     <title>Kernel Command Line</title>
 979
 980     <para>When run as system instance systemd parses a number of
 981     kernel command line arguments<footnote><para>If run inside a Linux
 982     container these arguments may be passed as command line arguments
 983     to systemd itself, next to any of the command line options listed
 984     in the Options section above. If run outside of Linux containers,
 985     these arguments are parsed from <filename>/proc/cmdline</filename>
 986     instead.</para></footnote>:</para>
 987
 988     <variablelist class='kernel-commandline-options'>
 989       <varlistentry>
 990         <term><varname>systemd.unit=</varname></term>
 991         <term><varname>rd.systemd.unit=</varname></term>
 992
 993         <listitem><para>Overrides the unit to activate on boot.
 994         Defaults to <filename>default.target</filename>. This may be
 995         used to temporarily boot into a different boot unit, for
 996         example <filename>rescue.target</filename> or
 997         <filename>emergency.service</filename>. See
 998         <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>
 999         for details about these units. The option prefixed with
1000         <literal>rd.</literal> is honored only in the initial RAM disk
1001         (initrd), while the one that is not prefixed only in the main
1002         system.</para></listitem>
1003       </varlistentry>
1004
1005       <varlistentry>
1006         <term><varname>systemd.dump_core</varname></term>
1007
1008         <listitem><para>Takes a boolean argument or enables the option if specified
1009         without an argument. If enabled, the systemd manager (PID 1) dumps core when
1010         it crashes. Otherwise, no core dump is created. Defaults to enabled.</para>
1011         </listitem>
1012       </varlistentry>
1013
1014       <varlistentry>
1015         <term><varname>systemd.crash_chvt</varname></term>
1016
1017         <listitem><para>Takes a positive integer, or a boolean argument. Can be also
1018         specified without an argument, with the same effect as a positive boolean. If
1019         a positive integer (in the range 1–63) is specified, the system manager (PID
1020         1) will activate the specified virtual terminal (VT) when it
1021         crashes. Defaults to disabled, meaning that no such switch is attempted. If
1022         set to enabled, the VT the kernel messages are written to is selected.
1023         </para></listitem>
1024       </varlistentry>
1025
1026       <varlistentry>
1027         <term><varname>systemd.crash_shell</varname></term>
1028
1029         <listitem><para>Takes a boolean argument or enables the option if specified
1030         without an argument. If enabled, the system manager (PID 1) spawns a shell
1031         when it crashes, after a 10s delay. Otherwise, no shell is spawned. Defaults
1032         to disabled, for security reasons, as the shell is not protected by password
1033         authentication.</para></listitem>
1034       </varlistentry>
1035
1036       <varlistentry>
1037         <term><varname>systemd.crash_reboot</varname></term>
1038
1039         <listitem><para>Takes a boolean argument or enables the option if specified
1040         without an argument. If enabled, the system manager (PID 1) will reboot the
1041         machine automatically when it crashes, after a 10s delay.  Otherwise, the
1042         system will hang indefinitely. Defaults to disabled, in order to avoid a
1043         reboot loop. If combined with <varname>systemd.crash_shell</varname>, the
1044         system is rebooted after the shell exits.</para></listitem>
1045       </varlistentry>
1046
1047       <varlistentry>
1048         <term><varname>systemd.confirm_spawn</varname></term>
1049
1050         <listitem><para>Takes a boolean argument or a path to the virtual console
1051         where the confirmation messages should be emitted. Can be also specified
1052         without an argument, with the same effect as a positive boolean. If enabled,
1053         the system manager (PID 1) asks for confirmation when spawning processes
1054         using <option>/dev/console</option>. If a path or a console name (such as
1055         <literal>ttyS0</literal>) is provided, the virtual console pointed to by this
1056         path or described by the give name will be used instead. Defaults to disabled.
1057         </para></listitem>
1058       </varlistentry>
1059
1060       <varlistentry>
1061         <term><varname>systemd.show_status</varname></term>
1062
1063         <listitem><para>Takes a boolean argument or the constant
1064         <constant>auto</constant>. Can be also specified without an argument, with
1065         the same effect as a positive boolean.  If enabled, the systemd manager (PID
1066         1) shows terse service status updates on the console during bootup.
1067         <constant>auto</constant> behaves like <option>false</option> until a unit
1068         fails or there is a significant delay in boot. Defaults to enabled, unless
1069         <option>quiet</option> is passed as kernel command line option, in which case
1070         it defaults to <constant>auto</constant>. If specified overrides the system
1071         manager configuration file option <option>ShowStatus=</option>, see
1072         <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
1073         However, the process command line option <option>&#x2D;&#x2D;show-status=</option>
1074         takes precedence over both this kernel command line option and the
1075         configuration file option.</para></listitem>
1076       </varlistentry>
1077
1078       <varlistentry>
1079         <term><varname>systemd.log_target=</varname></term>
1080         <term><varname>systemd.log_level=</varname></term>
1081         <term><varname>systemd.log_location=</varname></term>
1082         <term><varname>systemd.log_color</varname></term>
1083
1084         <listitem><para>Controls log output, with the same effect as the
1085         <varname>$SYSTEMD_LOG_TARGET</varname>,
1086         <varname>$SYSTEMD_LOG_LEVEL</varname>,
1087         <varname>$SYSTEMD_LOG_LOCATION</varname>,
1088         <varname>$SYSTEMD_LOG_COLOR</varname> environment variables described above.
1089         <varname>systemd.log_color</varname> can be specified without an argument,
1090         with the same effect as a positive boolean.</para></listitem>
1091       </varlistentry>
1092
1093       <varlistentry>
1094         <term><varname>systemd.default_standard_output=</varname></term>
1095         <term><varname>systemd.default_standard_error=</varname></term>
1096         <listitem><para>Controls default standard output and error
1097         output for services, with the same effect as the
1098         <option>&#x2D;&#x2D;default-standard-output=</option> and
1099         <option>&#x2D;&#x2D;default-standard-error=</option> command line
1100         arguments described above, respectively.</para></listitem>
1101       </varlistentry>
1102
1103       <varlistentry>
1104         <term><varname>systemd.setenv=</varname></term>
1105
1106         <listitem><para>Takes a string argument in the form
1107         VARIABLE=VALUE. May be used to set default environment
1108         variables to add to forked child processes. May be used more
1109         than once to set multiple variables.</para></listitem>
1110       </varlistentry>
1111
1112       <varlistentry>
1113         <term><varname>systemd.machine_id=</varname></term>
1114
1115         <listitem><para>Takes a 32 character hex value to be
1116         used for setting the machine-id. Intended mostly for
1117         network booting where the same machine-id is desired
1118         for every boot.</para></listitem>
1119       </varlistentry>
1120
1121       <varlistentry>
1122         <term><varname>systemd.unified_cgroup_hierarchy</varname></term>
1123
1124         <listitem><para>When specified without an argument or with a true argument,
1125         enables the usage of
1126         <ulink url="https://www.kernel.org/doc/Documentation/cgroup-v2.txt">unified cgroup hierarchy</ulink>
1127         (a.k.a. cgroups-v2). When specified with a false argument, fall back to
1128         hybrid or full legacy cgroup hierarchy.</para>
1129
1130         <para>If this option is not specified, the default behaviour is determined
1131         during compilation (the <option>&#x2D;&#x2D;with-default-hierarchy=</option>
1132         option). If the kernel does not support unified cgroup hierarchy, the legacy
1133         hierarchy will be used even if this option is specified.</para>
1134         </listitem>
1135       </varlistentry>
1136
1137       <varlistentry>
1138         <term><varname>systemd.legacy_systemd_cgroup_controller</varname></term>
1139
1140         <listitem><para>Takes effect if the full unified cgroup hierarchy is not used
1141         (see previous option). When specified without an argument or with a true
1142         argument, disables the use of "hybrid" cgroup hierarchy (i.e. a cgroups-v2
1143         tree used for systemd, and
1144         <ulink url="https://www.kernel.org/doc/Documentation/cgroup-v1/">legacy
1145         cgroup hierarchy</ulink>, a.k.a. cgroups-v1, for other controllers), and
1146         forces a full "legacy" mode. When specified with a false argument, enables
1147         the use of "hybrid" hierarchy.</para>
1148
1149         <para>If this option is not specified, the default behaviour is determined
1150         during compilation (the <option>&#x2D;&#x2D;with-default-hierarchy=</option>
1151         option). If the kernel does not support unified cgroup hierarchy, the legacy
1152         hierarchy will be used  even if this option is specified.</para>
1153         </listitem>
1154       </varlistentry>
1155
1156       <varlistentry>
1157         <term><varname>quiet</varname></term>
1158
1159         <listitem><para>Turn off status output at boot, much like
1160         <varname>systemd.show_status=false</varname> would. Note that
1161         this option is also read by the kernel itself and disables
1162         kernel log output. Passing this option hence turns off the
1163         usual output from both the system manager and the kernel.
1164         </para></listitem>
1165       </varlistentry>
1166
1167       <varlistentry>
1168         <term><varname>debug</varname></term>
1169
1170         <listitem><para>Turn on debugging output. This is equivalent
1171         to <varname>systemd.log_level=debug</varname>. Note that this
1172         option is also read by the kernel itself and enables kernel
1173         debug output. Passing this option hence turns on the debug
1174         output from both the system manager and the
1175         kernel.</para></listitem>
1176       </varlistentry>
1177
1178       <varlistentry>
1179         <term><varname>emergency</varname></term>
1180         <term><varname>rd.emergency</varname></term>
1181         <term><varname>-b</varname></term>
1182
1183         <listitem><para>Boot into emergency mode. This is equivalent
1184         to <varname>systemd.unit=emergency.target</varname> or
1185         <varname>rd.systemd.unit=emergency.target</varname>, respectively, and
1186         provided for compatibility reasons and to be easier to type.</para></listitem>
1187       </varlistentry>
1188
1189       <varlistentry>
1190         <term><varname>rescue</varname></term>
1191         <term><varname>rd.rescue</varname></term>
1192         <term><varname>single</varname></term>
1193         <term><varname>s</varname></term>
1194         <term><varname>S</varname></term>
1195         <term><varname>1</varname></term>
1196
1197         <listitem><para>Boot into rescue mode. This is equivalent to
1198         <varname>systemd.unit=rescue.target</varname> or
1199         <varname>rd.systemd.unit=rescue.target</varname>, respectively, and
1200         provided for compatibility reasons and to be easier to type.</para></listitem>
1201       </varlistentry>
1202
1203       <varlistentry>
1204         <term><varname>2</varname></term>
1205         <term><varname>3</varname></term>
1206         <term><varname>4</varname></term>
1207         <term><varname>5</varname></term>
1208
1209         <listitem><para>Boot into the specified legacy SysV runlevel.
1210         These are equivalent to
1211         <varname>systemd.unit=runlevel2.target</varname>,
1212         <varname>systemd.unit=runlevel3.target</varname>,
1213         <varname>systemd.unit=runlevel4.target</varname>, and
1214         <varname>systemd.unit=runlevel5.target</varname>,
1215         respectively, and provided for compatibility reasons and to be
1216         easier to type.</para></listitem>
1217       </varlistentry>
1218
1219       <varlistentry>
1220         <term><varname>locale.LANG=</varname></term>
1221         <term><varname>locale.LANGUAGE=</varname></term>
1222         <term><varname>locale.LC_CTYPE=</varname></term>
1223         <term><varname>locale.LC_NUMERIC=</varname></term>
1224         <term><varname>locale.LC_TIME=</varname></term>
1225         <term><varname>locale.LC_COLLATE=</varname></term>
1226         <term><varname>locale.LC_MONETARY=</varname></term>
1227         <term><varname>locale.LC_MESSAGES=</varname></term>
1228         <term><varname>locale.LC_PAPER=</varname></term>
1229         <term><varname>locale.LC_NAME=</varname></term>
1230         <term><varname>locale.LC_ADDRESS=</varname></term>
1231         <term><varname>locale.LC_TELEPHONE=</varname></term>
1232         <term><varname>locale.LC_MEASUREMENT=</varname></term>
1233         <term><varname>locale.LC_IDENTIFICATION=</varname></term>
1234
1235         <listitem><para>Set the system locale to use. This overrides
1236         the settings in <filename>/etc/locale.conf</filename>. For
1237         more information, see
1238         <citerefentry project='man-pages'><refentrytitle>locale.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
1239         and
1240         <citerefentry project='man-pages'><refentrytitle>locale</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
1241         </para></listitem>
1242       </varlistentry>
1243     </variablelist>
1244
1245     <para>For other kernel command line parameters understood by
1246     components of the core OS, please refer to
1247     <citerefentry><refentrytitle>kernel-command-line</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
1248   </refsect1>
1249   // 0 -->
1250
1251   <!-- 0 /// The whole sockets section is unneeded in elogind
1252   <refsect1>
1253     <title>Sockets and FIFOs</title>
1254
1255     <variablelist>
1256       <varlistentry>
1257         <term><filename>/run/systemd/notify</filename></term>
1258
1259         <listitem><para>Daemon status notification socket. This is an
1260         <constant>AF_UNIX</constant> datagram socket and is used to
1261         implement the daemon notification logic as implemented by
1262         <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para></listitem>
1263
1264       </varlistentry>
1265
1266       <varlistentry>
1267         <term><filename>/run/systemd/private</filename></term>
1268
1269         <listitem><para>Used internally as communication channel
1270         between
1271         <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
1272         and the systemd process. This is an
1273         <constant>AF_UNIX</constant> stream socket. This interface is
1274         private to systemd and should not be used in external
1275         projects.</para></listitem>
1276       </varlistentry>
1277
1278       <varlistentry>
1279         <term><filename>/dev/initctl</filename></term>
1280
1281         <listitem><para>Limited compatibility support for the SysV
1282         client interface, as implemented by the
1283         <filename>systemd-initctl.service</filename> unit. This is a
1284         named pipe in the file system. This interface is obsolete and
1285         should not be used in new applications.</para></listitem>
1286       </varlistentry>
1287     </variablelist>
1288   </refsect1>
1289   // 0 -->
1290
1291   <refsect1>
1292     <title>See Also</title>
1293     <para>
1294       <!-- 0 /// elogind does not have that much to see also...
1295       The <ulink url="https://www.freedesktop.org/wiki/Software/systemd/">systemd Homepage</ulink>,
1296       <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1297       <citerefentry project='man-pages'><refentrytitle>locale.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1298       <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
1299       <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
1300       <citerefentry><refentrytitle>systemd-notify</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
1301       <citerefentry><refentrytitle>daemon</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
1302       <citerefentry><refentrytitle>sd-daemon</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
1303       <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1304       <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1305       <citerefentry project='die-net'><refentrytitle>pkg-config</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
1306       <citerefentry><refentrytitle>kernel-command-line</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
1307       <citerefentry project='man-pages'><refentrytitle>bootup</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
1308       <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>
1309       else -->
1310       The <ulink url="https://github.com/elogind/elogind/">elogind Homepage</ulink>,
1311       <citerefentry><refentrytitle>loginctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
1312       <citerefentry><refentrytitle>logind.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1313       <citerefentry><refentrytitle>pam_elogind</refentrytitle><manvolnum>8</manvolnum></citerefentry>
1314       <!-- // 0 -->
1315     </para>
1316   </refsect1>
1317
1318 </refentry>