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   SPDX-License-Identifier: LGPL-2.1+
   7
   8   This file is part of elogind.
   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       <varlistentry>
 346         <term><option>&#x2D;&#x2D;service-watchdogs=</option></term>
 347
 348         <listitem><para>Globally enable/disable all service watchdog timeouts and emergency
 349         actions. This setting may also be specified during boot, on the kernel
 350         command line via the <varname>systemd.service_watchdogs=</varname>
 351         option, see below. Defaults to enabled.</para></listitem>
 352       </varlistentry>
 353
 354       <xi:include href="standard-options.xml" xpointer="help" />
 355       <xi:include href="standard-options.xml" xpointer="version" />
 356       else -->
 357       <varlistentry>
 358         <term><option>-D</option></term>
 359         <term><option>--daemon</option></term>
 360
 361         <listitem><para>Daemonize elogind by double-forking
 362         into background.</para></listitem>
 363       </varlistentry>
 364
 365       <varlistentry>
 366         <term><option>-h</option></term>
 367         <term><option>--help</option></term>
 368
 369         <listitem><para>Show the helpt text and exit.</para></listitem>
 370       </varlistentry>
 371       <!-- // 0 -->
 372     </variablelist>
 373   </refsect1>
 374
 375   <!-- 0 /// The whole concpets section is unneeded in elogind
 376   <refsect1>
 377     <title>Concepts</title>
 378
 379     <para>systemd provides a dependency system between various
 380     entities called "units" of 11 different types. Units encapsulate
 381     various objects that are relevant for system boot-up and
 382     maintenance. The majority of units are configured in unit
 383     configuration files, whose syntax and basic set of options is
 384     described in
 385     <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
 386     however some are created automatically from other configuration,
 387     dynamically from system state or programmatically at runtime.
 388     Units may be "active" (meaning started, bound, plugged in, …,
 389     depending on the unit type, see below), or "inactive" (meaning
 390     stopped, unbound, unplugged, …), as well as in the process of
 391     being activated or deactivated, i.e. between the two states (these
 392     states are called "activating", "deactivating"). A special
 393     "failed" state is available as well, which is very similar to
 394     "inactive" and is entered when the service failed in some way
 395     (process returned error code on exit, or crashed, an operation
 396     timed out, or after too many restarts). If this state is entered,
 397     the cause will be logged, for later reference. Note that the
 398     various unit types may have a number of additional substates,
 399     which are mapped to the five generalized unit states described
 400     here.</para>
 401
 402     <para>The following unit types are available:</para>
 403
 404     <orderedlist>
 405       <listitem><para>Service units, which start and control daemons
 406       and the processes they consist of. For details, see
 407       <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
 408
 409       <listitem><para>Socket units, which encapsulate local IPC or
 410       network sockets in the system, useful for socket-based
 411       activation. For details about socket units, see
 412       <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
 413       for details on socket-based activation and other forms of
 414       activation, see
 415       <citerefentry><refentrytitle>daemon</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para></listitem>
 416
 417       <listitem><para>Target units are useful to group units, or
 418       provide well-known synchronization points during boot-up, see
 419       <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
 420
 421       <listitem><para>Device units expose kernel devices in systemd
 422       and may be used to implement device-based activation. For
 423       details, see
 424       <citerefentry><refentrytitle>systemd.device</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
 425
 426       <listitem><para>Mount units control mount points in the file
 427       system, for details see
 428       <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
 429
 430       <listitem><para>Automount units provide automount capabilities,
 431       for on-demand mounting of file systems as well as parallelized
 432       boot-up. See
 433       <citerefentry><refentrytitle>systemd.automount</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
 434
 435       <listitem><para>Timer units are useful for triggering activation
 436       of other units based on timers. You may find details in
 437       <citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
 438
 439       <listitem><para>Swap units are very similar to mount units and
 440       encapsulate memory swap partitions or files of the operating
 441       system. They are described in
 442       <citerefentry><refentrytitle>systemd.swap</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
 443
 444       <listitem><para>Path units may be used to activate other
 445       services when file system objects change or are modified. See
 446       <citerefentry><refentrytitle>systemd.path</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
 447
 448       <listitem><para>Slice units may be used to group units which
 449       manage system processes (such as service and scope units) in a
 450       hierarchical tree for resource management purposes. See
 451       <citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
 452
 453       <listitem><para>Scope units are similar to service units, but
 454       manage foreign processes instead of starting them as well. See
 455       <citerefentry><refentrytitle>systemd.scope</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
 456
 457     </orderedlist>
 458
 459     <para>Units are named as their configuration files. Some units
 460     have special semantics. A detailed list is available in
 461     <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
 462
 463     <para>systemd knows various kinds of dependencies, including
 464     positive and negative requirement dependencies (i.e.
 465     <varname>Requires=</varname> and <varname>Conflicts=</varname>) as
 466     well as ordering dependencies (<varname>After=</varname> and
 467     <varname>Before=</varname>). NB: ordering and requirement
 468     dependencies are orthogonal. If only a requirement dependency
 469     exists between two units (e.g. <filename>foo.service</filename>
 470     requires <filename>bar.service</filename>), but no ordering
 471     dependency (e.g. <filename>foo.service</filename> after
 472     <filename>bar.service</filename>) and both are requested to start,
 473     they will be started in parallel. It is a common pattern that both
 474     requirement and ordering dependencies are placed between two
 475     units. Also note that the majority of dependencies are implicitly
 476     created and maintained by systemd. In most cases, it should be
 477     unnecessary to declare additional dependencies manually, however
 478     it is possible to do this.</para>
 479
 480     <para>Application programs and units (via dependencies) may
 481     request state changes of units. In systemd, these requests are
 482     encapsulated as 'jobs' and maintained in a job queue. Jobs may
 483     succeed or can fail, their execution is ordered based on the
 484     ordering dependencies of the units they have been scheduled
 485     for.</para>
 486
 487     <para>On boot systemd activates the target unit
 488     <filename>default.target</filename> whose job is to activate
 489     on-boot services and other on-boot units by pulling them in via
 490     dependencies. Usually, the unit name is just an alias (symlink) for
 491     either <filename>graphical.target</filename> (for fully-featured
 492     boots into the UI) or <filename>multi-user.target</filename> (for
 493     limited console-only boots for use in embedded or server
 494     environments, or similar; a subset of graphical.target). However,
 495     it is at the discretion of the administrator to configure it as an
 496     alias to any other target unit. See
 497     <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>
 498     for details about these target units.</para>
 499
 500     <para>Processes systemd spawns are placed in individual Linux
 501     control groups named after the unit which they belong to in the
 502     private systemd hierarchy. (see <ulink
 503     url="https://www.kernel.org/doc/Documentation/cgroup-v1/cgroups.txt">cgroups.txt</ulink>
 504     for more information about control groups, or short "cgroups").
 505     systemd uses this to effectively keep track of processes. Control
 506     group information is maintained in the kernel, and is accessible
 507     via the file system hierarchy (beneath
 508     <filename>/sys/fs/cgroup/systemd/</filename>), or in tools such as
 509     <citerefentry project='man-pages'><refentrytitle>systemd-cgls</refentrytitle><manvolnum>1</manvolnum></citerefentry>
 510     or
 511     <citerefentry project='man-pages'><refentrytitle>ps</refentrytitle><manvolnum>1</manvolnum></citerefentry>
 512     (<command>ps xawf -eo pid,user,cgroup,args</command> is
 513     particularly useful to list all processes and the systemd units
 514     they belong to.).</para>
 515
 516     <para>systemd is compatible with the SysV init system to a large
 517     degree: SysV init scripts are supported and simply read as an
 518     alternative (though limited) configuration file format. The SysV
 519     <filename>/dev/initctl</filename> interface is provided, and
 520     compatibility implementations of the various SysV client tools are
 521     available. In addition to that, various established Unix
 522     functionality such as <filename>/etc/fstab</filename> or the
 523     <filename>utmp</filename> database are supported.</para>
 524
 525     <para>systemd has a minimal transaction system: if a unit is
 526     requested to start up or shut down it will add it and all its
 527     dependencies to a temporary transaction. Then, it will verify if
 528     the transaction is consistent (i.e. whether the ordering of all
 529     units is cycle-free). If it is not, systemd will try to fix it up,
 530     and removes non-essential jobs from the transaction that might
 531     remove the loop. Also, systemd tries to suppress non-essential
 532     jobs in the transaction that would stop a running service. Finally
 533     it is checked whether the jobs of the transaction contradict jobs
 534     that have already been queued, and optionally the transaction is
 535     aborted then. If all worked out and the transaction is consistent
 536     and minimized in its impact it is merged with all already
 537     outstanding jobs and added to the run queue. Effectively this
 538     means that before executing a requested operation, systemd will
 539     verify that it makes sense, fixing it if possible, and only
 540     failing if it really cannot work.</para>
 541
 542     <para>systemd contains native implementations of various tasks
 543     that need to be executed as part of the boot process. For example,
 544     it sets the hostname or configures the loopback network device. It
 545     also sets up and mounts various API file systems, such as
 546     <filename>/sys</filename> or <filename>/proc</filename>.</para>
 547
 548     <para>For more information about the concepts and
 549     ideas behind systemd, please refer to the
 550     <ulink url="http://0pointer.de/blog/projects/systemd.html">Original Design Document</ulink>.</para>
 551
 552     <para>Note that some but not all interfaces provided
 553     by systemd are covered by the
 554     <ulink url="https://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise">Interface
 555     Stability Promise</ulink>.</para>
 556
 557     <para>Units may be generated dynamically at boot and system
 558     manager reload time, for example based on other configuration
 559     files or parameters passed on the kernel command line. For details, see
 560     <citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
 561
 562     <para>Systems which invoke systemd in a container or initrd
 563     environment should implement the
 564     <ulink url="https://www.freedesktop.org/wiki/Software/systemd/ContainerInterface">Container Interface</ulink> or
 565     <ulink url="https://www.freedesktop.org/wiki/Software/systemd/InitrdInterface">initrd Interface</ulink>
 566     specifications, respectively.</para>
 567   </refsect1>
 568   // 0 -->
 569
 570   <!-- 0 /// The whole directories section is unneeded in elogind
 571   <refsect1>
 572     <title>Directories</title>
 573
 574     <variablelist>
 575       <varlistentry>
 576         <term>System unit directories</term>
 577
 578         <listitem><para>The systemd system manager reads unit
 579         configuration from various directories. Packages that want to
 580         install unit files shall place them in the directory returned
 581         by <command>pkg-config systemd
 582         &#x2D;&#x2D;variable=systemdsystemunitdir</command>. Other directories
 583         checked are <filename>/usr/local/lib/systemd/system</filename>
 584         and <filename>/usr/lib/systemd/system</filename>. User
 585         configuration always takes precedence. <command>pkg-config
 586         systemd &#x2D;&#x2D;variable=systemdsystemconfdir</command> returns the
 587         path of the system configuration directory. Packages should
 588         alter the content of these directories only with the
 589         <command>enable</command> and <command>disable</command>
 590         commands of the
 591         <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
 592         tool. Full list of directories is provided in
 593         <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
 594         </para></listitem>
 595       </varlistentry>
 596     </variablelist>
 597
 598     <variablelist>
 599       <varlistentry>
 600         <term>User unit directories</term>
 601
 602         <listitem><para>Similar rules apply for the user unit
 603         directories. However, here the
 604         <ulink url="http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html">XDG
 605         Base Directory specification</ulink> is followed to find
 606         units. Applications should place their unit files in the
 607         directory returned by <command>pkg-config systemd
 608         &#x2D;&#x2D;variable=systemduserunitdir</command>. Global configuration
 609         is done in the directory reported by <command>pkg-config
 610         systemd &#x2D;&#x2D;variable=systemduserconfdir</command>. The
 611         <command>enable</command> and <command>disable</command>
 612         commands of the
 613         <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
 614         tool can handle both global (i.e. for all users) and private
 615         (for one user) enabling/disabling of units. Full list of
 616         directories is provided in
 617         <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
 618         </para></listitem>
 619       </varlistentry>
 620     </variablelist>
 621
 622     <variablelist>
 623       <varlistentry>
 624         <term>SysV init scripts directory</term>
 625
 626         <listitem><para>The location of the SysV init script directory
 627         varies between distributions. If systemd cannot find a native
 628         unit file for a requested service, it will look for a SysV
 629         init script of the same name (with the
 630         <filename>.service</filename> suffix
 631         removed).</para></listitem>
 632       </varlistentry>
 633     </variablelist>
 634
 635     <variablelist>
 636       <varlistentry>
 637         <term>SysV runlevel link farm directory</term>
 638
 639         <listitem><para>The location of the SysV runlevel link farm
 640         directory varies between distributions. systemd will take the
 641         link farm into account when figuring out whether a service
 642         shall be enabled. Note that a service unit with a native unit
 643         configuration file cannot be started by activating it in the
 644         SysV runlevel link farm.</para></listitem>
 645       </varlistentry>
 646     </variablelist>
 647   </refsect1>
 648   // 0 -->
 649
 650   <!-- 0 /// The whole Signals section is unneeded in elogind
 651   <refsect1>
 652     <title>Signals</title>
 653
 654     <variablelist>
 655       <varlistentry>
 656         <term><constant>SIGTERM</constant></term>
 657
 658         <listitem><para>Upon receiving this signal the systemd system
 659         manager serializes its state, reexecutes itself and
 660         deserializes the saved state again. This is mostly equivalent
 661         to <command>systemctl daemon-reexec</command>.</para>
 662
 663         <para>systemd user managers will start the
 664         <filename>exit.target</filename> unit when this signal is
 665         received. This is mostly equivalent to <command>systemctl
 666         &#x2D;&#x2D;user start exit.target
 667         &#x2D;&#x2D;job-mode=replace-irreversible</command>.</para></listitem>
 668       </varlistentry>
 669
 670       <varlistentry>
 671         <term><constant>SIGINT</constant></term>
 672
 673         <listitem><para>Upon receiving this signal the systemd system
 674         manager will start the
 675         <filename>ctrl-alt-del.target</filename> unit. This is mostly
 676         equivalent to <command>systemctl start ctrl-alt-del.target
 677         &#x2D;&#x2D;job-mode=replace-irreversible</command>. If this signal is
 678         received more than 7 times per 2s, an immediate reboot is
 679         triggered.  Note that pressing Ctrl-Alt-Del on the console
 680         will trigger this signal. Hence, if a reboot is hanging,
 681         pressing Ctrl-Alt-Del more than 7 times in 2s is a relatively
 682         safe way to trigger an immediate reboot.</para>
 683
 684         <para>systemd user managers treat this signal the same way as
 685         <constant>SIGTERM</constant>.</para></listitem>
 686       </varlistentry>
 687
 688       <varlistentry>
 689         <term><constant>SIGWINCH</constant></term>
 690
 691         <listitem><para>When this signal is received the systemd
 692         system manager will start the
 693         <filename>kbrequest.target</filename> unit. This is mostly
 694         equivalent to <command>systemctl start
 695         kbrequest.target</command>.</para>
 696
 697         <para>This signal is ignored by systemd user
 698         managers.</para></listitem>
 699       </varlistentry>
 700
 701       <varlistentry>
 702         <term><constant>SIGPWR</constant></term>
 703
 704         <listitem><para>When this signal is received the systemd
 705         manager will start the <filename>sigpwr.target</filename>
 706         unit. This is mostly equivalent to <command>systemctl start
 707         sigpwr.target</command>.</para></listitem>
 708       </varlistentry>
 709
 710       <varlistentry>
 711         <term><constant>SIGUSR1</constant></term>
 712
 713         <listitem><para>When this signal is received the systemd
 714         manager will try to reconnect to the D-Bus
 715         bus.</para></listitem>
 716       </varlistentry>
 717
 718       <varlistentry>
 719         <term><constant>SIGUSR2</constant></term>
 720
 721         <listitem><para>When this signal is received the systemd
 722         manager will log its complete state in human-readable form.
 723         The data logged is the same as printed by
 724         <command>systemd-analyze dump</command>.</para></listitem>
 725       </varlistentry>
 726
 727       <varlistentry>
 728         <term><constant>SIGHUP</constant></term>
 729
 730         <listitem><para>Reloads the complete daemon configuration.
 731         This is mostly equivalent to <command>systemctl
 732         daemon-reload</command>.</para></listitem>
 733       </varlistentry>
 734
 735       <varlistentry>
 736         <term><constant>SIGRTMIN+0</constant></term>
 737
 738         <listitem><para>Enters default mode, starts the
 739         <filename>default.target</filename> unit. This is mostly
 740         equivalent to <command>systemctl isolate
 741         default.target</command>.</para></listitem>
 742       </varlistentry>
 743
 744       <varlistentry>
 745         <term><constant>SIGRTMIN+1</constant></term>
 746
 747         <listitem><para>Enters rescue mode, starts the
 748         <filename>rescue.target</filename> unit. This is mostly
 749         equivalent to <command>systemctl isolate
 750         rescue.target</command>.</para></listitem>
 751       </varlistentry>
 752
 753       <varlistentry>
 754         <term><constant>SIGRTMIN+2</constant></term>
 755
 756         <listitem><para>Enters emergency mode, starts the
 757         <filename>emergency.service</filename> unit. This is mostly
 758         equivalent to <command>systemctl isolate
 759         emergency.service</command>.</para></listitem>
 760       </varlistentry>
 761
 762       <varlistentry>
 763         <term><constant>SIGRTMIN+3</constant></term>
 764
 765         <listitem><para>Halts the machine, starts the
 766         <filename>halt.target</filename> unit. This is mostly
 767         equivalent to <command>systemctl start halt.target
 768         &#x2D;&#x2D;job-mode=replace-irreversible</command>.</para>
 769         </listitem>
 770       </varlistentry>
 771
 772       <varlistentry>
 773         <term><constant>SIGRTMIN+4</constant></term>
 774
 775         <listitem><para>Powers off the machine, starts the
 776         <filename>poweroff.target</filename> unit. This is mostly
 777         equivalent to <command>systemctl start poweroff.target
 778         &#x2D;&#x2D;job-mode=replace-irreversible</command>.</para>
 779         </listitem>
 780       </varlistentry>
 781
 782       <varlistentry>
 783         <term><constant>SIGRTMIN+5</constant></term>
 784
 785         <listitem><para>Reboots the machine, starts the
 786         <filename>reboot.target</filename> unit. This is mostly
 787         equivalent to <command>systemctl start reboot.target
 788         &#x2D;&#x2D;job-mode=replace-irreversible</command>.</para>
 789         </listitem>
 790       </varlistentry>
 791
 792       <varlistentry>
 793         <term><constant>SIGRTMIN+6</constant></term>
 794
 795         <listitem><para>Reboots the machine via kexec, starts the
 796         <filename>kexec.target</filename> unit. This is mostly
 797         equivalent to <command>systemctl start kexec.target
 798         &#x2D;&#x2D;job-mode=replace-irreversible</command>.</para>
 799         </listitem>
 800       </varlistentry>
 801
 802       <varlistentry>
 803         <term><constant>SIGRTMIN+13</constant></term>
 804
 805         <listitem><para>Immediately halts the machine.</para></listitem>
 806       </varlistentry>
 807
 808       <varlistentry>
 809         <term><constant>SIGRTMIN+14</constant></term>
 810
 811         <listitem><para>Immediately powers off the machine.</para></listitem>
 812       </varlistentry>
 813
 814       <varlistentry>
 815         <term><constant>SIGRTMIN+15</constant></term>
 816
 817         <listitem><para>Immediately reboots the machine.</para></listitem>
 818       </varlistentry>
 819
 820       <varlistentry>
 821         <term><constant>SIGRTMIN+16</constant></term>
 822
 823         <listitem><para>Immediately reboots the machine with kexec.</para></listitem>
 824       </varlistentry>
 825
 826       <varlistentry>
 827         <term><constant>SIGRTMIN+20</constant></term>
 828
 829         <listitem><para>Enables display of status messages on the
 830         console, as controlled via
 831         <varname>systemd.show_status=1</varname> on the kernel command
 832         line.</para></listitem>
 833       </varlistentry>
 834
 835       <varlistentry>
 836         <term><constant>SIGRTMIN+21</constant></term>
 837
 838         <listitem><para>Disables display of
 839         status messages on the console, as
 840         controlled via
 841         <varname>systemd.show_status=0</varname>
 842         on the kernel command
 843         line.</para></listitem>
 844       </varlistentry>
 845
 846       <varlistentry>
 847         <term><constant>SIGRTMIN+22</constant></term>
 848         <term><constant>SIGRTMIN+23</constant></term>
 849
 850         <listitem><para>Sets the log level to <literal>debug</literal>
 851         (or <literal>info</literal> on
 852         <constant>SIGRTMIN+23</constant>), as controlled via
 853         <varname>systemd.log_level=debug</varname> (or
 854         <varname>systemd.log_level=info</varname> on
 855         <constant>SIGRTMIN+23</constant>) on the kernel command
 856         line.</para></listitem>
 857       </varlistentry>
 858
 859       <varlistentry>
 860         <term><constant>SIGRTMIN+24</constant></term>
 861
 862         <listitem><para>Immediately exits the manager (only available
 863         for &#x2D;&#x2D;user instances).</para></listitem>
 864       </varlistentry>
 865
 866       <varlistentry>
 867         <term><constant>SIGRTMIN+26</constant></term>
 868         <term><constant>SIGRTMIN+27</constant></term>
 869         <term><constant>SIGRTMIN+28</constant></term>
 870
 871         <listitem><para>Sets the log target to
 872         <literal>journal-or-kmsg</literal> (or
 873         <literal>console</literal> on
 874         <constant>SIGRTMIN+27</constant>, <literal>kmsg</literal> on
 875         <constant>SIGRTMIN+28</constant>), as controlled via
 876         <varname>systemd.log_target=journal-or-kmsg</varname> (or
 877         <varname>systemd.log_target=console</varname> on
 878         <constant>SIGRTMIN+27</constant> or
 879         <varname>systemd.log_target=kmsg</varname> on
 880         <constant>SIGRTMIN+28</constant>) on the kernel command
 881         line.</para></listitem>
 882       </varlistentry>
 883     </variablelist>
 884   </refsect1>
 885   // 0 -->
 886
 887   <!-- 0 /// The whole environment section is unneeded in elogind
 888   <refsect1>
 889     <title>Environment</title>
 890
 891     <variablelist class='environment-variables'>
 892       <varlistentry>
 893         <term><varname>$SYSTEMD_LOG_LEVEL</varname></term>
 894         <listitem><para>systemd reads the log level from this
 895         environment variable. This can be overridden with
 896         <option>&#x2D;&#x2D;log-level=</option>.</para></listitem>
 897       </varlistentry>
 898
 899       <varlistentry>
 900         <term><varname>$SYSTEMD_LOG_TARGET</varname></term>
 901         <listitem><para>systemd reads the log target from this
 902         environment variable. This can be overridden with
 903         <option>&#x2D;&#x2D;log-target=</option>.</para></listitem>
 904       </varlistentry>
 905
 906       <varlistentry>
 907         <term><varname>$SYSTEMD_LOG_COLOR</varname></term>
 908         <listitem><para>Controls whether systemd highlights important
 909         log messages. This can be overridden with
 910         <option>&#x2D;&#x2D;log-color=</option>.</para></listitem>
 911       </varlistentry>
 912
 913       <varlistentry>
 914         <term><varname>$SYSTEMD_LOG_LOCATION</varname></term>
 915         <listitem><para>Controls whether systemd prints the code
 916         location along with log messages. This can be overridden with
 917         <option>&#x2D;&#x2D;log-location=</option>.</para></listitem>
 918       </varlistentry>
 919
 920       <varlistentry>
 921         <term><varname>$XDG_CONFIG_HOME</varname></term>
 922         <term><varname>$XDG_CONFIG_DIRS</varname></term>
 923         <term><varname>$XDG_DATA_HOME</varname></term>
 924         <term><varname>$XDG_DATA_DIRS</varname></term>
 925
 926         <listitem><para>The systemd user manager uses these variables
 927         in accordance to the <ulink
 928         url="http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html">XDG
 929         Base Directory specification</ulink> to find its
 930         configuration.</para></listitem>
 931       </varlistentry>
 932
 933       <varlistentry>
 934         <term><varname>$SYSTEMD_UNIT_PATH</varname></term>
 935
 936         <listitem><para>Controls where systemd looks for unit
 937         files.</para></listitem>
 938       </varlistentry>
 939
 940       <varlistentry>
 941         <term><varname>$SYSTEMD_SYSVINIT_PATH</varname></term>
 942
 943         <listitem><para>Controls where systemd looks for SysV init
 944         scripts.</para></listitem>
 945       </varlistentry>
 946
 947       <varlistentry>
 948         <term><varname>$SYSTEMD_SYSVRCND_PATH</varname></term>
 949
 950         <listitem><para>Controls where systemd looks for SysV init
 951         script runlevel link farms.</para></listitem>
 952       </varlistentry>
 953
 954       <varlistentry>
 955         <term><varname>$SYSTEMD_COLORS</varname></term>
 956
 957         <listitem><para>The value must be a boolean. Controls whether colorized output should be
 958         generated. This can be specified to override the decision that <command>systemd</command>
 959         makes based on <varname>$TERM</varname> and what the console is connected to.</para>
 960         </listitem>
 961       </varlistentry>
 962
 963       <varlistentry>
 964         <term><varname>$LISTEN_PID</varname></term>
 965         <term><varname>$LISTEN_FDS</varname></term>
 966         <term><varname>$LISTEN_FDNAMES</varname></term>
 967
 968         <listitem><para>Set by systemd for supervised processes during
 969         socket-based activation. See
 970         <citerefentry><refentrytitle>sd_listen_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry>
 971         for more information.</para></listitem>
 972       </varlistentry>
 973
 974       <varlistentry>
 975         <term><varname>$NOTIFY_SOCKET</varname></term>
 976
 977         <listitem><para>Set by systemd for supervised processes for
 978         status and start-up completion notification. See
 979         <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>
 980         for more information.</para></listitem>
 981       </varlistentry>
 982     </variablelist>
 983   </refsect1>
 984   // 0 -->
 985
 986   <!-- 0 /// The whole kernel section is unneeded in elogind
 987   <refsect1>
 988     <title>Kernel Command Line</title>
 989
 990     <para>When run as system instance systemd parses a number of
 991     kernel command line arguments<footnote><para>If run inside a Linux
 992     container these arguments may be passed as command line arguments
 993     to systemd itself, next to any of the command line options listed
 994     in the Options section above. If run outside of Linux containers,
 995     these arguments are parsed from <filename>/proc/cmdline</filename>
 996     instead.</para></footnote>:</para>
 997
 998     <variablelist class='kernel-commandline-options'>
 999       <varlistentry>
1000         <term><varname>systemd.unit=</varname></term>
1001         <term><varname>rd.systemd.unit=</varname></term>
1002
1003         <listitem><para>Overrides the unit to activate on boot.
1004         Defaults to <filename>default.target</filename>. This may be
1005         used to temporarily boot into a different boot unit, for
1006         example <filename>rescue.target</filename> or
1007         <filename>emergency.service</filename>. See
1008         <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>
1009         for details about these units. The option prefixed with
1010         <literal>rd.</literal> is honored only in the initial RAM disk
1011         (initrd), while the one that is not prefixed only in the main
1012         system.</para></listitem>
1013       </varlistentry>
1014
1015       <varlistentry>
1016         <term><varname>systemd.dump_core</varname></term>
1017
1018         <listitem><para>Takes a boolean argument or enables the option if specified
1019         without an argument. If enabled, the systemd manager (PID 1) dumps core when
1020         it crashes. Otherwise, no core dump is created. Defaults to enabled.</para>
1021         </listitem>
1022       </varlistentry>
1023
1024       <varlistentry>
1025         <term><varname>systemd.crash_chvt</varname></term>
1026
1027         <listitem><para>Takes a positive integer, or a boolean argument. Can be also
1028         specified without an argument, with the same effect as a positive boolean. If
1029         a positive integer (in the range 1–63) is specified, the system manager (PID
1030         1) will activate the specified virtual terminal (VT) when it
1031         crashes. Defaults to disabled, meaning that no such switch is attempted. If
1032         set to enabled, the VT the kernel messages are written to is selected.
1033         </para></listitem>
1034       </varlistentry>
1035
1036       <varlistentry>
1037         <term><varname>systemd.crash_shell</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) spawns a shell
1041         when it crashes, after a 10s delay. Otherwise, no shell is spawned. Defaults
1042         to disabled, for security reasons, as the shell is not protected by password
1043         authentication.</para></listitem>
1044       </varlistentry>
1045
1046       <varlistentry>
1047         <term><varname>systemd.crash_reboot</varname></term>
1048
1049         <listitem><para>Takes a boolean argument or enables the option if specified
1050         without an argument. If enabled, the system manager (PID 1) will reboot the
1051         machine automatically when it crashes, after a 10s delay.  Otherwise, the
1052         system will hang indefinitely. Defaults to disabled, in order to avoid a
1053         reboot loop. If combined with <varname>systemd.crash_shell</varname>, the
1054         system is rebooted after the shell exits.</para></listitem>
1055       </varlistentry>
1056
1057       <varlistentry>
1058         <term><varname>systemd.confirm_spawn</varname></term>
1059
1060         <listitem><para>Takes a boolean argument or a path to the virtual console
1061         where the confirmation messages should be emitted. Can be also specified
1062         without an argument, with the same effect as a positive boolean. If enabled,
1063         the system manager (PID 1) asks for confirmation when spawning processes
1064         using <option>/dev/console</option>. If a path or a console name (such as
1065         <literal>ttyS0</literal>) is provided, the virtual console pointed to by this
1066         path or described by the give name will be used instead. Defaults to disabled.
1067         </para></listitem>
1068       </varlistentry>
1069
1070       <varlistentry>
1071         <term><varname>systemd.service_watchdogs=</varname></term>
1072
1073         <listitem><para>Takes a boolean argument. If disabled, all service runtime
1074         watchdogs (<option>WatchdogSec=</option>) and emergency actions (e.g.
1075         <option>OnFailure=</option> or <option>StartLimitAction=</option>) are
1076         ignored by the system manager (PID 1); see
1077         <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
1078         Defaults to enabled, i.e. watchdogs and failure actions are processed
1079         normally. The hardware watchdog is not affected by this
1080         option.</para></listitem>
1081       </varlistentry>
1082
1083       <varlistentry>
1084         <term><varname>systemd.show_status</varname></term>
1085
1086         <listitem><para>Takes a boolean argument or the constant
1087         <constant>auto</constant>. Can be also specified without an argument, with
1088         the same effect as a positive boolean.  If enabled, the systemd manager (PID
1089         1) shows terse service status updates on the console during bootup.
1090         <constant>auto</constant> behaves like <option>false</option> until a unit
1091         fails or there is a significant delay in boot. Defaults to enabled, unless
1092         <option>quiet</option> is passed as kernel command line option, in which case
1093         it defaults to <constant>auto</constant>. If specified overrides the system
1094         manager configuration file option <option>ShowStatus=</option>, see
1095         <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
1096         However, the process command line option <option>&#x2D;&#x2D;show-status=</option>
1097         takes precedence over both this kernel command line option and the
1098         configuration file option.</para></listitem>
1099       </varlistentry>
1100
1101       <varlistentry>
1102         <term><varname>systemd.log_target=</varname></term>
1103         <term><varname>systemd.log_level=</varname></term>
1104         <term><varname>systemd.log_location=</varname></term>
1105         <term><varname>systemd.log_color</varname></term>
1106
1107         <listitem><para>Controls log output, with the same effect as the
1108         <varname>$SYSTEMD_LOG_TARGET</varname>,
1109         <varname>$SYSTEMD_LOG_LEVEL</varname>,
1110         <varname>$SYSTEMD_LOG_LOCATION</varname>,
1111         <varname>$SYSTEMD_LOG_COLOR</varname> environment variables described above.
1112         <varname>systemd.log_color</varname> can be specified without an argument,
1113         with the same effect as a positive boolean.</para></listitem>
1114       </varlistentry>
1115
1116       <varlistentry>
1117         <term><varname>systemd.default_standard_output=</varname></term>
1118         <term><varname>systemd.default_standard_error=</varname></term>
1119         <listitem><para>Controls default standard output and error
1120         output for services, with the same effect as the
1121         <option>&#x2D;&#x2D;default-standard-output=</option> and
1122         <option>&#x2D;&#x2D;default-standard-error=</option> command line
1123         arguments described above, respectively.</para></listitem>
1124       </varlistentry>
1125
1126       <varlistentry>
1127         <term><varname>systemd.setenv=</varname></term>
1128
1129         <listitem><para>Takes a string argument in the form
1130         VARIABLE=VALUE. May be used to set default environment
1131         variables to add to forked child processes. May be used more
1132         than once to set multiple variables.</para></listitem>
1133       </varlistentry>
1134
1135       <varlistentry>
1136         <term><varname>systemd.machine_id=</varname></term>
1137
1138         <listitem><para>Takes a 32 character hex value to be
1139         used for setting the machine-id. Intended mostly for
1140         network booting where the same machine-id is desired
1141         for every boot.</para></listitem>
1142       </varlistentry>
1143
1144       <varlistentry>
1145         <term><varname>systemd.unified_cgroup_hierarchy</varname></term>
1146
1147         <listitem><para>When specified without an argument or with a true argument,
1148         enables the usage of
1149         <ulink url="https://www.kernel.org/doc/Documentation/cgroup-v2.txt">unified cgroup hierarchy</ulink>
1150         (a.k.a. cgroups-v2). When specified with a false argument, fall back to
1151         hybrid or full legacy cgroup hierarchy.</para>
1152
1153         <para>If this option is not specified, the default behaviour is determined
1154         during compilation (the <option>&#x2D;&#x2D;with-default-hierarchy=</option>
1155         option). If the kernel does not support unified cgroup hierarchy, the legacy
1156         hierarchy will be used even if this option is specified.</para>
1157         </listitem>
1158       </varlistentry>
1159
1160       <varlistentry>
1161         <term><varname>systemd.legacy_systemd_cgroup_controller</varname></term>
1162
1163         <listitem><para>Takes effect if the full unified cgroup hierarchy is not used
1164         (see previous option). When specified without an argument or with a true
1165         argument, disables the use of "hybrid" cgroup hierarchy (i.e. a cgroups-v2
1166         tree used for systemd, and
1167         <ulink url="https://www.kernel.org/doc/Documentation/cgroup-v1/">legacy
1168         cgroup hierarchy</ulink>, a.k.a. cgroups-v1, for other controllers), and
1169         forces a full "legacy" mode. When specified with a false argument, enables
1170         the use of "hybrid" hierarchy.</para>
1171
1172         <para>If this option is not specified, the default behaviour is determined
1173         during compilation (the <option>&#x2D;&#x2D;with-default-hierarchy=</option>
1174         option). If the kernel does not support unified cgroup hierarchy, the legacy
1175         hierarchy will be used  even if this option is specified.</para>
1176         </listitem>
1177       </varlistentry>
1178
1179       <varlistentry>
1180         <term><varname>quiet</varname></term>
1181
1182         <listitem><para>Turn off status output at boot, much like
1183         <varname>systemd.show_status=false</varname> would. Note that
1184         this option is also read by the kernel itself and disables
1185         kernel log output. Passing this option hence turns off the
1186         usual output from both the system manager and the kernel.
1187         </para></listitem>
1188       </varlistentry>
1189
1190       <varlistentry>
1191         <term><varname>debug</varname></term>
1192
1193         <listitem><para>Turn on debugging output. This is equivalent
1194         to <varname>systemd.log_level=debug</varname>. Note that this
1195         option is also read by the kernel itself and enables kernel
1196         debug output. Passing this option hence turns on the debug
1197         output from both the system manager and the
1198         kernel.</para></listitem>
1199       </varlistentry>
1200
1201       <varlistentry>
1202         <term><varname>emergency</varname></term>
1203         <term><varname>rd.emergency</varname></term>
1204         <term><varname>-b</varname></term>
1205
1206         <listitem><para>Boot into emergency mode. This is equivalent
1207         to <varname>systemd.unit=emergency.target</varname> or
1208         <varname>rd.systemd.unit=emergency.target</varname>, respectively, and
1209         provided for compatibility reasons and to be easier to type.</para></listitem>
1210       </varlistentry>
1211
1212       <varlistentry>
1213         <term><varname>rescue</varname></term>
1214         <term><varname>rd.rescue</varname></term>
1215         <term><varname>single</varname></term>
1216         <term><varname>s</varname></term>
1217         <term><varname>S</varname></term>
1218         <term><varname>1</varname></term>
1219
1220         <listitem><para>Boot into rescue mode. This is equivalent to
1221         <varname>systemd.unit=rescue.target</varname> or
1222         <varname>rd.systemd.unit=rescue.target</varname>, respectively, and
1223         provided for compatibility reasons and to be easier to type.</para></listitem>
1224       </varlistentry>
1225
1226       <varlistentry>
1227         <term><varname>2</varname></term>
1228         <term><varname>3</varname></term>
1229         <term><varname>4</varname></term>
1230         <term><varname>5</varname></term>
1231
1232         <listitem><para>Boot into the specified legacy SysV runlevel.
1233         These are equivalent to
1234         <varname>systemd.unit=runlevel2.target</varname>,
1235         <varname>systemd.unit=runlevel3.target</varname>,
1236         <varname>systemd.unit=runlevel4.target</varname>, and
1237         <varname>systemd.unit=runlevel5.target</varname>,
1238         respectively, and provided for compatibility reasons and to be
1239         easier to type.</para></listitem>
1240       </varlistentry>
1241
1242       <varlistentry>
1243         <term><varname>locale.LANG=</varname></term>
1244         <term><varname>locale.LANGUAGE=</varname></term>
1245         <term><varname>locale.LC_CTYPE=</varname></term>
1246         <term><varname>locale.LC_NUMERIC=</varname></term>
1247         <term><varname>locale.LC_TIME=</varname></term>
1248         <term><varname>locale.LC_COLLATE=</varname></term>
1249         <term><varname>locale.LC_MONETARY=</varname></term>
1250         <term><varname>locale.LC_MESSAGES=</varname></term>
1251         <term><varname>locale.LC_PAPER=</varname></term>
1252         <term><varname>locale.LC_NAME=</varname></term>
1253         <term><varname>locale.LC_ADDRESS=</varname></term>
1254         <term><varname>locale.LC_TELEPHONE=</varname></term>
1255         <term><varname>locale.LC_MEASUREMENT=</varname></term>
1256         <term><varname>locale.LC_IDENTIFICATION=</varname></term>
1257
1258         <listitem><para>Set the system locale to use. This overrides
1259         the settings in <filename>/etc/locale.conf</filename>. For
1260         more information, see
1261         <citerefentry project='man-pages'><refentrytitle>locale.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
1262         and
1263         <citerefentry project='man-pages'><refentrytitle>locale</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
1264         </para></listitem>
1265       </varlistentry>
1266     </variablelist>
1267
1268     <para>For other kernel command line parameters understood by
1269     components of the core OS, please refer to
1270     <citerefentry><refentrytitle>kernel-command-line</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
1271   </refsect1>
1272   // 0 -->
1273
1274   <!-- 0 /// The whole sockets section is unneeded in elogind
1275   <refsect1>
1276     <title>Sockets and FIFOs</title>
1277
1278     <variablelist>
1279       <varlistentry>
1280         <term><filename>/run/systemd/notify</filename></term>
1281
1282         <listitem><para>Daemon status notification socket. This is an
1283         <constant>AF_UNIX</constant> datagram socket and is used to
1284         implement the daemon notification logic as implemented by
1285         <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para></listitem>
1286
1287       </varlistentry>
1288
1289       <varlistentry>
1290         <term><filename>/run/systemd/private</filename></term>
1291
1292         <listitem><para>Used internally as communication channel
1293         between
1294         <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
1295         and the systemd process. This is an
1296         <constant>AF_UNIX</constant> stream socket. This interface is
1297         private to systemd and should not be used in external
1298         projects.</para></listitem>
1299       </varlistentry>
1300
1301       <varlistentry>
1302         <term><filename>/dev/initctl</filename></term>
1303
1304         <listitem><para>Limited compatibility support for the SysV
1305         client interface, as implemented by the
1306         <filename>systemd-initctl.service</filename> unit. This is a
1307         named pipe in the file system. This interface is obsolete and
1308         should not be used in new applications.</para></listitem>
1309       </varlistentry>
1310     </variablelist>
1311   </refsect1>
1312   // 0 -->
1313
1314   <refsect1>
1315     <title>See Also</title>
1316     <para>
1317       <!-- 0 /// elogind does not have that much to see also...
1318       The <ulink url="https://www.freedesktop.org/wiki/Software/systemd/">systemd Homepage</ulink>,
1319       <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1320       <citerefentry project='man-pages'><refentrytitle>locale.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1321       <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
1322       <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
1323       <citerefentry><refentrytitle>systemd-notify</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
1324       <citerefentry><refentrytitle>daemon</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
1325       <citerefentry><refentrytitle>sd-daemon</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
1326       <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1327       <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1328       <citerefentry project='die-net'><refentrytitle>pkg-config</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
1329       <citerefentry><refentrytitle>kernel-command-line</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
1330       <citerefentry project='man-pages'><refentrytitle>bootup</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
1331       <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>
1332       else -->
1333       The <ulink url="https://github.com/elogind/elogind/">elogind Homepage</ulink>,
1334       <citerefentry><refentrytitle>loginctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
1335       <citerefentry><refentrytitle>logind.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1336       <citerefentry><refentrytitle>pam_elogind</refentrytitle><manvolnum>8</manvolnum></citerefentry>
1337       <!-- // 0 -->
1338     </para>
1339   </refsect1>
1340
1341 </refentry>