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