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