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