man/systemd.xml

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