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