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