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