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   systemd is free software; you can redistribute it and/or modify it
  13   under the terms of the GNU Lesser General Public License as published by
  14   the Free Software Foundation; either version 2.1 of the License, or
  15   (at your option) any later version.
  16
  17   systemd is distributed in the hope that it will be useful, but
  18   WITHOUT ANY WARRANTY; without even the implied warranty of
  19   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
  20   Lesser General Public License for more details.
  21
  22   You should have received a copy of the GNU Lesser General Public License
  23   along with systemd; If not, see <http://www.gnu.org/licenses/>.
  24 -->
  25
  26 <refentry id="systemd"
  27     xmlns:xi="http://www.w3.org/2001/XInclude">
  28
  29   <refentryinfo>
  30     <title>systemd</title>
  31     <productname>systemd</productname>
  32
  33     <authorgroup>
  34       <author>
  35         <contrib>Developer</contrib>
  36         <firstname>Lennart</firstname>
  37         <surname>Poettering</surname>
  38         <email>lennart@poettering.net</email>
  39       </author>
  40     </authorgroup>
  41   </refentryinfo>
  42
  43   <refmeta>
  44     <refentrytitle>systemd</refentrytitle>
  45     <manvolnum>1</manvolnum>
  46   </refmeta>
  47
  48   <refnamediv>
  49     <refname>systemd</refname>
  50     <refname>init</refname>
  51     <refpurpose>systemd system and service manager</refpurpose>
  52   </refnamediv>
  53
  54   <refsynopsisdiv>
  55     <cmdsynopsis>
  56       <command>/usr/lib/systemd/systemd</command>
  57       <arg choice="opt" rep="repeat">OPTIONS</arg>
  58     </cmdsynopsis>
  59     <cmdsynopsis>
  60       <command>init</command>
  61       <arg choice="opt" rep="repeat">OPTIONS</arg>
  62       <arg choice="req">COMMAND</arg>
  63     </cmdsynopsis>
  64   </refsynopsisdiv>
  65
  66   <refsect1>
  67     <title>Description</title>
  68
  69     <para>systemd is a system and service manager for Linux operating
  70     systems. When run as first process on boot (as PID 1), it acts as
  71     init system that brings up and maintains userspace
  72     services.</para>
  73
  74     <para>For compatibility with SysV, if systemd is called as
  75     <command>init</command> and a PID that is not 1, it will execute
  76     <command>telinit</command> and pass all command line arguments
  77     unmodified. That means <command>init</command> and
  78     <command>telinit</command> are mostly equivalent when invoked from
  79     normal login sessions. See
  80     <citerefentry><refentrytitle>telinit</refentrytitle><manvolnum>8</manvolnum></citerefentry>
  81     for more information.</para>
  82
  83     <para>When run as a system instance, systemd interprets the
  84     configuration file <filename>system.conf</filename> and the files
  85     in <filename>system.conf.d</filename> directories; when run as a
  86     user instance, systemd interprets the configuration file
  87     <filename>user.conf</filename> and the files in
  88     <filename>user.conf.d</filename> directories. See
  89     <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
  90     for more information.</para>
  91   </refsect1>
  92
  93   <refsect1>
  94     <title>Options</title>
  95
  96     <para>The following options are understood:</para>
  97
  98     <variablelist>
  99       <varlistentry>
 100         <term><option>--test</option></term>
 101
 102         <listitem><para>Determine startup sequence, dump it and exit.
 103         This is an option useful for debugging only.</para></listitem>
 104       </varlistentry>
 105       <varlistentry>
 106         <term><option>--dump-configuration-items</option></term>
 107
 108         <listitem><para>Dump understood unit configuration items. This
 109         outputs a terse but complete list of configuration items
 110         understood in unit definition files.</para></listitem>
 111       </varlistentry>
 112       <varlistentry>
 113         <term><option>--unit=</option></term>
 114
 115         <listitem><para>Set default unit to activate on startup. If
 116         not specified, defaults to
 117         <filename>default.target</filename>.</para></listitem>
 118       </varlistentry>
 119       <varlistentry>
 120         <term><option>--system</option></term>
 121         <term><option>--user</option></term>
 122
 123         <listitem><para>For <option>--system</option>, tell systemd to
 124         run a system instance, even if the process ID is not 1, i.e.
 125         systemd is not run as init process. <option>--user</option>
 126         does the opposite, running a user instance even if the process
 127         ID is 1. Normally, it should not be necessary to pass these
 128         options, as systemd automatically detects the mode it is
 129         started in. These options are hence of little use except for
 130         debugging. Note that it is not supported booting and
 131         maintaining a full system with systemd running in
 132         <option>--system</option> mode, but PID not 1. In practice,
 133         passing <option>--system</option> explicitly is only useful in
 134         conjunction with <option>--test</option>.</para></listitem>
 135       </varlistentry>
 136       <varlistentry>
 137         <term><option>--dump-core</option></term>
 138
 139         <listitem><para>Enable core dumping on crash. This switch has
 140         no effect when running as user instance. This setting may also
 141         be enabled during boot on the kernel command line via the
 142         <varname>systemd.dump_core=</varname> option, see
 143         below.</para></listitem>
 144       </varlistentry>
 145
 146       <varlistentry>
 147         <term><option>--crash-vt=</option><replaceable>VT</replaceable></term>
 148
 149         <listitem><para>Switch to a specific virtual console (VT) on
 150         crash. Takes a positive integer in the range 1–63, or a
 151         boolean argument. If an integer is passed, selects which VT to
 152         switch to. If <constant>yes</constant>, the VT kernel messages
 153         are written to is selected. If <constant>no</constant>, no VT
 154         switch is attempted. This switch has no effect when running as
 155         user instance. This setting may also be enabled during boot,
 156         on the kernel command line via the
 157         <varname>systemd.crash_vt=</varname> option, see
 158         <!-- FIXME: there is no crash_vt command line option? -->
 159         below.</para></listitem>
 160       </varlistentry>
 161
 162       <varlistentry>
 163         <term><option>--crash-shell</option></term>
 164
 165         <listitem><para>Run a shell on crash. This switch has no
 166         effect when running as user instance. This setting may also be
 167         enabled during boot, on the kernel command line via the
 168         <varname>systemd.crash_shell=</varname> option, see
 169         below.</para></listitem>
 170       </varlistentry>
 171
 172       <varlistentry>
 173         <term><option>--crash-reboot</option></term>
 174
 175         <listitem><para>Automatically reboot the system on crash. This
 176         switch has no effect when running as user instance. This
 177         setting may also be enabled during boot, on the kernel command
 178         line via the <varname>systemd.crash_reboot=</varname> option,
 179         see below.</para></listitem>
 180       </varlistentry>
 181
 182       <varlistentry>
 183         <term><option>--confirm-spawn</option></term>
 184
 185         <listitem><para>Ask for confirmation when spawning processes.
 186         This switch has no effect when run as user
 187         instance.</para></listitem>
 188       </varlistentry>
 189       <varlistentry>
 190         <term><option>--show-status=</option></term>
 191
 192         <listitem><para>Takes a boolean argument or the special value <constant>auto</constant>. If on, terse unit
 193         status information is shown on the console during boot-up and shutdown. If off, no such status information is
 194         shown. If set to <constant>auto</constant> behavior is similar to off, except that it is automatically switched
 195         to on, as soon as the first unit failure or significant boot delay is encountered. This switch has no effect
 196         when invoked as user instance. If specified, overrides both the kernel command line setting
 197         <varname>systemd.show_status=</varname> (see below) and the configuration file option
 198         <option>ShowStatus=</option>, see
 199         <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
 200       </varlistentry>
 201       <varlistentry>
 202         <term><option>--log-target=</option></term>
 203
 204         <listitem><para>Set log target. Argument must be one of
 205         <option>console</option>,
 206         <option>journal</option>,
 207         <option>kmsg</option>,
 208         <option>journal-or-kmsg</option>,
 209         <option>null</option>.</para></listitem>
 210       </varlistentry>
 211       <varlistentry>
 212         <term><option>--log-level=</option></term>
 213
 214         <listitem><para>Set log level. As
 215         argument this accepts a numerical log
 216         level or the well-known <citerefentry project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>
 217         symbolic names (lowercase):
 218         <option>emerg</option>,
 219         <option>alert</option>,
 220         <option>crit</option>,
 221         <option>err</option>,
 222         <option>warning</option>,
 223         <option>notice</option>,
 224         <option>info</option>,
 225         <option>debug</option>.</para></listitem>
 226       </varlistentry>
 227       <varlistentry>
 228         <term><option>--log-color=</option></term>
 229
 230         <listitem><para>Highlight important log messages. Argument is
 231         a boolean value. If the argument is omitted, it defaults to
 232         <option>true</option>.</para></listitem>
 233       </varlistentry>
 234       <varlistentry>
 235         <term><option>--log-location=</option></term>
 236
 237         <listitem><para>Include code location in log messages. This is
 238         mostly relevant for debugging purposes. Argument is a boolean
 239         value. If the argument is omitted it defaults to
 240         <option>true</option>.</para></listitem>
 241       </varlistentry>
 242       <varlistentry>
 243         <term><option>--default-standard-output=</option></term>
 244         <term><option>--default-standard-error=</option></term>
 245
 246         <listitem><para>Sets the default output or error output for
 247         all services and sockets, respectively. That is, controls the
 248         default for <option>StandardOutput=</option> and
 249         <option>StandardError=</option> (see
 250         <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
 251         for details). Takes one of
 252         <option>inherit</option>,
 253         <option>null</option>,
 254         <option>tty</option>,
 255         <option>journal</option>,
 256         <option>journal+console</option>,
 257         <option>syslog</option>,
 258         <option>syslog+console</option>,
 259         <option>kmsg</option>,
 260         <option>kmsg+console</option>.  If the
 261         argument is omitted
 262         <option>--default-standard-output=</option> defaults to
 263         <option>journal</option> and
 264         <option>--default-standard-error=</option> to
 265         <option>inherit</option>.</para></listitem>
 266       </varlistentry>
 267
 268       <varlistentry>
 269         <term><option>--machine-id=</option></term>
 270
 271         <listitem><para>Override the machine-id set on the hard drive,
 272         useful for network booting or for containers. May not be set
 273         to all zeros.</para></listitem>
 274       </varlistentry>
 275
 276       <xi:include href="standard-options.xml" xpointer="help" />
 277       <xi:include href="standard-options.xml" xpointer="version" />
 278     </variablelist>
 279   </refsect1>
 280
 281   <refsect1>
 282     <title>Concepts</title>
 283
 284     <para>systemd provides a dependency system between various
 285     entities called "units" of 11 different types. Units encapsulate
 286     various objects that are relevant for system boot-up and
 287     maintenance. The majority of units are configured in unit
 288     configuration files, whose syntax and basic set of options is
 289     described in
 290     <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
 291     however some are created automatically from other configuration,
 292     dynamically from system state or programmatically at runtime.
 293     Units may be "active" (meaning started, bound, plugged in, …,
 294     depending on the unit type, see below), or "inactive" (meaning
 295     stopped, unbound, unplugged, …), as well as in the process of
 296     being activated or deactivated, i.e. between the two states (these
 297     states are called "activating", "deactivating"). A special
 298     "failed" state is available as well, which is very similar to
 299     "inactive" and is entered when the service failed in some way
 300     (process returned error code on exit, or crashed, or an operation
 301     timed out). If this state is entered, the cause will be logged,
 302     for later reference. Note that the various unit types may have a
 303     number of additional substates, which are mapped to the five
 304     generalized unit states described 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/cgroups/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 ctl-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         <term><constant>SIGRTMIN+23</constant></term>
 749
 750         <listitem><para>Sets the log level to <literal>debug</literal>
 751         (or <literal>info</literal> on
 752         <constant>SIGRTMIN+23</constant>), as controlled via
 753         <varname>systemd.log_level=debug</varname> (or
 754         <varname>systemd.log_level=info</varname> on
 755         <constant>SIGRTMIN+23</constant>) on the kernel command
 756         line.</para></listitem>
 757       </varlistentry>
 758
 759       <varlistentry>
 760         <term><constant>SIGRTMIN+24</constant></term>
 761
 762         <listitem><para>Immediately exits the manager (only available
 763         for --user instances).</para></listitem>
 764       </varlistentry>
 765
 766       <varlistentry>
 767         <term><constant>SIGRTMIN+26</constant></term>
 768         <term><constant>SIGRTMIN+27</constant></term>
 769         <term><constant>SIGRTMIN+28</constant></term>
 770
 771         <listitem><para>Sets the log target to
 772         <literal>journal-or-kmsg</literal> (or
 773         <literal>console</literal> on
 774         <constant>SIGRTMIN+27</constant>, <literal>kmsg</literal> on
 775         <constant>SIGRTMIN+28</constant>), as controlled via
 776         <varname>systemd.log_target=journal-or-kmsg</varname> (or
 777         <varname>systemd.log_target=console</varname> on
 778         <constant>SIGRTMIN+27</constant> or
 779         <varname>systemd.log_target=kmsg</varname> on
 780         <constant>SIGRTMIN+28</constant>) on the kernel command
 781         line.</para></listitem>
 782       </varlistentry>
 783     </variablelist>
 784   </refsect1>
 785
 786   <refsect1>
 787     <title>Environment</title>
 788
 789     <variablelist class='environment-variables'>
 790       <varlistentry>
 791         <term><varname>$SYSTEMD_LOG_LEVEL</varname></term>
 792         <listitem><para>systemd reads the log level from this
 793         environment variable. This can be overridden with
 794         <option>--log-level=</option>.</para></listitem>
 795       </varlistentry>
 796
 797       <varlistentry>
 798         <term><varname>$SYSTEMD_LOG_TARGET</varname></term>
 799         <listitem><para>systemd reads the log target from this
 800         environment variable. This can be overridden with
 801         <option>--log-target=</option>.</para></listitem>
 802       </varlistentry>
 803
 804       <varlistentry>
 805         <term><varname>$SYSTEMD_LOG_COLOR</varname></term>
 806         <listitem><para>Controls whether systemd highlights important
 807         log messages. This can be overridden with
 808         <option>--log-color=</option>.</para></listitem>
 809       </varlistentry>
 810
 811       <varlistentry>
 812         <term><varname>$SYSTEMD_LOG_LOCATION</varname></term>
 813         <listitem><para>Controls whether systemd prints the code
 814         location along with log messages. This can be overridden with
 815         <option>--log-location=</option>.</para></listitem>
 816       </varlistentry>
 817
 818       <varlistentry>
 819         <term><varname>$XDG_CONFIG_HOME</varname></term>
 820         <term><varname>$XDG_CONFIG_DIRS</varname></term>
 821         <term><varname>$XDG_DATA_HOME</varname></term>
 822         <term><varname>$XDG_DATA_DIRS</varname></term>
 823
 824         <listitem><para>The systemd user manager uses these variables
 825         in accordance to the <ulink
 826         url="http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html">XDG
 827         Base Directory specification</ulink> to find its
 828         configuration.</para></listitem>
 829       </varlistentry>
 830
 831       <varlistentry>
 832         <term><varname>$SYSTEMD_UNIT_PATH</varname></term>
 833
 834         <listitem><para>Controls where systemd looks for unit
 835         files.</para></listitem>
 836       </varlistentry>
 837
 838       <varlistentry>
 839         <term><varname>$SYSTEMD_SYSVINIT_PATH</varname></term>
 840
 841         <listitem><para>Controls where systemd looks for SysV init
 842         scripts.</para></listitem>
 843       </varlistentry>
 844
 845       <varlistentry>
 846         <term><varname>$SYSTEMD_SYSVRCND_PATH</varname></term>
 847
 848         <listitem><para>Controls where systemd looks for SysV init
 849         script runlevel link farms.</para></listitem>
 850       </varlistentry>
 851
 852       <varlistentry>
 853         <term><varname>$SYSTEMD_COLORS</varname></term>
 854
 855         <listitem><para>The value must be a boolean. Controls whether colorized output should be
 856         generated. This can be specified to override the decision that <command>systemd</command>
 857         makes based on <varname>$TERM</varname> and what the console is connected to.</para>
 858         </listitem>
 859       </varlistentry>
 860
 861       <varlistentry>
 862         <term><varname>$LISTEN_PID</varname></term>
 863         <term><varname>$LISTEN_FDS</varname></term>
 864         <term><varname>$LISTEN_FDNAMES</varname></term>
 865
 866         <listitem><para>Set by systemd for supervised processes during
 867         socket-based activation. See
 868         <citerefentry><refentrytitle>sd_listen_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry>
 869         for more information.</para></listitem>
 870       </varlistentry>
 871
 872       <varlistentry>
 873         <term><varname>$NOTIFY_SOCKET</varname></term>
 874
 875         <listitem><para>Set by systemd for supervised processes for
 876         status and start-up completion notification. See
 877         <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>
 878         for more information.</para></listitem>
 879       </varlistentry>
 880     </variablelist>
 881   </refsect1>
 882
 883   <refsect1>
 884     <title>Kernel Command Line</title>
 885
 886     <para>When run as system instance systemd parses a number of
 887     kernel command line arguments<footnote><para>If run inside a Linux
 888     container these arguments may be passed as command line arguments
 889     to systemd itself, next to any of the command line options listed
 890     in the Options section above. If run outside of Linux containers,
 891     these arguments are parsed from <filename>/proc/cmdline</filename>
 892     instead.</para></footnote>:</para>
 893
 894     <variablelist class='kernel-commandline-options'>
 895       <varlistentry>
 896         <term><varname>systemd.unit=</varname></term>
 897         <term><varname>rd.systemd.unit=</varname></term>
 898
 899         <listitem><para>Overrides the unit to activate on boot.
 900         Defaults to <filename>default.target</filename>. This may be
 901         used to temporarily boot into a different boot unit, for
 902         example <filename>rescue.target</filename> or
 903         <filename>emergency.service</filename>. See
 904         <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>
 905         for details about these units. The option prefixed with
 906         <literal>rd.</literal> is honored only in the initial RAM disk
 907         (initrd), while the one that is not prefixed only in the main
 908         system.</para></listitem>
 909       </varlistentry>
 910
 911       <varlistentry>
 912         <term><varname>systemd.dump_core</varname></term>
 913
 914         <listitem><para>Takes a boolean argument or enables the option if specified
 915         without an argument. If enabled, the systemd manager (PID 1) dumps core when
 916         it crashes. Otherwise, no core dump is created. Defaults to enabled.</para>
 917         </listitem>
 918       </varlistentry>
 919
 920       <varlistentry>
 921         <term><varname>systemd.crash_chvt</varname></term>
 922
 923         <listitem><para>Takes a positive integer, or a boolean argument. Can be also
 924         specified without an argument, with the same effect as a positive boolean. If
 925         a positive integer (in the range 1–63) is specified, the system manager (PID
 926         1) will activate the specified virtual terminal (VT) when it
 927         crashes. Defaults to disabled, meaning that no such switch is attempted. If
 928         set to enabled, the VT the kernel messages are written to is selected.
 929         </para></listitem>
 930       </varlistentry>
 931
 932       <varlistentry>
 933         <term><varname>systemd.crash_shell</varname></term>
 934
 935         <listitem><para>Takes a boolean argument or enables the option if specified
 936         without an argument. If enabled, the system manager (PID 1) spawns a shell
 937         when it crashes, after a 10s delay. Otherwise, no shell is spawned. Defaults
 938         to disabled, for security reasons, as the shell is not protected by password
 939         authentication.</para></listitem>
 940       </varlistentry>
 941
 942       <varlistentry>
 943         <term><varname>systemd.crash_reboot</varname></term>
 944
 945         <listitem><para>Takes a boolean argument or enables the option if specified
 946         without an argument. If enabled, the system manager (PID 1) will reboot the
 947         machine automatically when it crashes, after a 10s delay.  Otherwise, the
 948         system will hang indefinitely. Defaults to disabled, in order to avoid a
 949         reboot loop. If combined with <varname>systemd.crash_shell</varname>, the
 950         system is rebooted after the shell exits.</para></listitem>
 951       </varlistentry>
 952
 953       <varlistentry>
 954         <term><varname>systemd.confirm_spawn</varname></term>
 955
 956         <listitem><para>Takes a boolean argument or a path to the virtual console
 957         where the confirmation messages should be emitted. Can be also specified
 958         without an argument, with the same effect as a positive boolean. If enabled,
 959         the system manager (PID 1) asks for confirmation when spawning processes
 960         using <option>/dev/console</option>. If a path or a console name (such as
 961         <literal>ttyS0</literal>) is provided, the virtual console pointed to by this
 962         path or described by the give name will be used instead. Defaults to disabled.
 963         </para></listitem>
 964       </varlistentry>
 965
 966       <varlistentry>
 967         <term><varname>systemd.show_status</varname></term>
 968
 969         <listitem><para>Takes a boolean argument or the constant
 970         <constant>auto</constant>. Can be also specified without an argument, with
 971         the same effect as a positive boolean.  If enabled, the systemd manager (PID
 972         1) shows terse service status updates on the console during bootup.
 973         <constant>auto</constant> behaves like <option>false</option> until a unit
 974         fails or there is a significant delay in boot. Defaults to enabled, unless
 975         <option>quiet</option> is passed as kernel command line option, in which case
 976         it defaults to <constant>auto</constant>. If specified overrides the system
 977         manager configuration file option <option>ShowStatus=</option>, see
 978         <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
 979         However, the process command line option <option>--show-status=</option>
 980         takes precedence over both this kernel command line option and the
 981         configuration file option.</para></listitem>
 982       </varlistentry>
 983
 984       <varlistentry>
 985         <term><varname>systemd.log_target=</varname></term>
 986         <term><varname>systemd.log_level=</varname></term>
 987         <term><varname>systemd.log_location=</varname></term>
 988         <term><varname>systemd.log_color</varname></term>
 989
 990         <listitem><para>Controls log output, with the same effect as the
 991         <varname>$SYSTEMD_LOG_TARGET</varname>,
 992         <varname>$SYSTEMD_LOG_LEVEL</varname>,
 993         <varname>$SYSTEMD_LOG_LOCATION</varname>,
 994         <varname>$SYSTEMD_LOG_COLOR</varname> environment variables described above.
 995         <varname>systemd.log_color</varname> can be specified without an argument,
 996         with the same effect as a positive boolean.</para></listitem>
 997       </varlistentry>
 998
 999       <varlistentry>
1000         <term><varname>systemd.default_standard_output=</varname></term>
1001         <term><varname>systemd.default_standard_error=</varname></term>
1002         <listitem><para>Controls default standard output and error
1003         output for services, with the same effect as the
1004         <option>--default-standard-output=</option> and
1005         <option>--default-standard-error=</option> command line
1006         arguments described above, respectively.</para></listitem>
1007       </varlistentry>
1008
1009       <varlistentry>
1010         <term><varname>systemd.setenv=</varname></term>
1011
1012         <listitem><para>Takes a string argument in the form
1013         VARIABLE=VALUE. May be used to set default environment
1014         variables to add to forked child processes. May be used more
1015         than once to set multiple variables.</para></listitem>
1016       </varlistentry>
1017
1018       <varlistentry>
1019         <term><varname>systemd.machine_id=</varname></term>
1020
1021         <listitem><para>Takes a 32 character hex value to be
1022         used for setting the machine-id. Intended mostly for
1023         network booting where the same machine-id is desired
1024         for every boot.</para></listitem>
1025       </varlistentry>
1026
1027       <varlistentry>
1028         <term><varname>systemd.unified_cgroup_hierarchy</varname></term>
1029
1030         <listitem><para>When specified without an argument or with a true argument,
1031         enables the usage of
1032         <ulink url="https://www.kernel.org/doc/Documentation/cgroup-v2.txt">unified cgroup hierarchy</ulink>
1033         (a.k.a. cgroups-v2). When specified with a false argument, fall back to
1034         hybrid or full legacy cgroup hierarchy.</para>
1035
1036         <para>If this option is not specified, the default behaviour is determined
1037         during compilation (the <option>--with-default-hierarchy=</option>
1038         option). If the kernel does not support unified cgroup hierarchy, the legacy
1039         hierarchy will be used even if this option is specified.</para>
1040         </listitem>
1041       </varlistentry>
1042
1043       <varlistentry>
1044         <term><varname>systemd.legacy_systemd_cgroup_controller</varname></term>
1045
1046         <listitem><para>Takes effect if the full unified cgroup hierarchy is not used
1047         (see previous option). When specified without an argument or with a true
1048         argument, disables the use of "hybrid" cgroup hierarchy (i.e. a cgroups-v2
1049         tree used for systemd, and
1050         <ulink url="https://www.kernel.org/doc/Documentation/cgroup-v1/">legacy
1051         cgroup hierarchy</ulink>, a.k.a. cgroups-v1, for other controllers), and
1052         forces a full "legacy" mode. When specified with a false argument, enables
1053         the use of "hybrid" hierarchy.</para>
1054
1055         <para>If this option is not specified, the default behaviour is determined
1056         during compilation (the <option>--with-default-hierarchy=</option>
1057         option). If the kernel does not support unified cgroup hierarchy, the legacy
1058         hierarchy will be used  even if this option is specified.</para>
1059         </listitem>
1060       </varlistentry>
1061
1062       <varlistentry>
1063         <term><varname>quiet</varname></term>
1064
1065         <listitem><para>Turn off status output at boot, much like
1066         <varname>systemd.show_status=false</varname> would. Note that
1067         this option is also read by the kernel itself and disables
1068         kernel log output. Passing this option hence turns off the
1069         usual output from both the system manager and the kernel.
1070         </para></listitem>
1071       </varlistentry>
1072
1073       <varlistentry>
1074         <term><varname>debug</varname></term>
1075
1076         <listitem><para>Turn on debugging output. This is equivalent
1077         to <varname>systemd.log_level=debug</varname>. Note that this
1078         option is also read by the kernel itself and enables kernel
1079         debug output. Passing this option hence turns on the debug
1080         output from both the system manager and the
1081         kernel.</para></listitem>
1082       </varlistentry>
1083
1084       <varlistentry>
1085         <term><varname>emergency</varname></term>
1086         <term><varname>rd.emergency</varname></term>
1087         <term><varname>-b</varname></term>
1088
1089         <listitem><para>Boot into emergency mode. This is equivalent
1090         to <varname>systemd.unit=emergency.target</varname> or
1091         <varname>rd.systemd.unit=emergency.target</varname>, respectively, and
1092         provided for compatibility reasons and to be easier to type.</para></listitem>
1093       </varlistentry>
1094
1095       <varlistentry>
1096         <term><varname>rescue</varname></term>
1097         <term><varname>rd.rescue</varname></term>
1098         <term><varname>single</varname></term>
1099         <term><varname>s</varname></term>
1100         <term><varname>S</varname></term>
1101         <term><varname>1</varname></term>
1102
1103         <listitem><para>Boot into rescue mode. This is equivalent to
1104         <varname>systemd.unit=rescue.target</varname> or
1105         <varname>rd.systemd.unit=rescue.target</varname>, respectively, and
1106         provided for compatibility reasons and to be easier to type.</para></listitem>
1107       </varlistentry>
1108
1109       <varlistentry>
1110         <term><varname>2</varname></term>
1111         <term><varname>3</varname></term>
1112         <term><varname>4</varname></term>
1113         <term><varname>5</varname></term>
1114
1115         <listitem><para>Boot into the specified legacy SysV runlevel.
1116         These are equivalent to
1117         <varname>systemd.unit=runlevel2.target</varname>,
1118         <varname>systemd.unit=runlevel3.target</varname>,
1119         <varname>systemd.unit=runlevel4.target</varname>, and
1120         <varname>systemd.unit=runlevel5.target</varname>,
1121         respectively, and provided for compatibility reasons and to be
1122         easier to type.</para></listitem>
1123       </varlistentry>
1124
1125       <varlistentry>
1126         <term><varname>locale.LANG=</varname></term>
1127         <term><varname>locale.LANGUAGE=</varname></term>
1128         <term><varname>locale.LC_CTYPE=</varname></term>
1129         <term><varname>locale.LC_NUMERIC=</varname></term>
1130         <term><varname>locale.LC_TIME=</varname></term>
1131         <term><varname>locale.LC_COLLATE=</varname></term>
1132         <term><varname>locale.LC_MONETARY=</varname></term>
1133         <term><varname>locale.LC_MESSAGES=</varname></term>
1134         <term><varname>locale.LC_PAPER=</varname></term>
1135         <term><varname>locale.LC_NAME=</varname></term>
1136         <term><varname>locale.LC_ADDRESS=</varname></term>
1137         <term><varname>locale.LC_TELEPHONE=</varname></term>
1138         <term><varname>locale.LC_MEASUREMENT=</varname></term>
1139         <term><varname>locale.LC_IDENTIFICATION=</varname></term>
1140
1141         <listitem><para>Set the system locale to use. This overrides
1142         the settings in <filename>/etc/locale.conf</filename>. For
1143         more information, see
1144         <citerefentry project='man-pages'><refentrytitle>locale.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
1145         and
1146         <citerefentry project='man-pages'><refentrytitle>locale</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
1147         </para></listitem>
1148       </varlistentry>
1149     </variablelist>
1150
1151     <para>For other kernel command line parameters understood by
1152     components of the core OS, please refer to
1153     <citerefentry><refentrytitle>kernel-command-line</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
1154   </refsect1>
1155
1156   <refsect1>
1157     <title>Sockets and FIFOs</title>
1158
1159     <variablelist>
1160       <varlistentry>
1161         <term><filename>/run/systemd/notify</filename></term>
1162
1163         <listitem><para>Daemon status notification socket. This is an
1164         <constant>AF_UNIX</constant> datagram socket and is used to
1165         implement the daemon notification logic as implemented by
1166         <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para></listitem>
1167
1168       </varlistentry>
1169
1170       <varlistentry>
1171         <term><filename>/run/systemd/private</filename></term>
1172
1173         <listitem><para>Used internally as communication channel
1174         between
1175         <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
1176         and the systemd process. This is an
1177         <constant>AF_UNIX</constant> stream socket. This interface is
1178         private to systemd and should not be used in external
1179         projects.</para></listitem>
1180       </varlistentry>
1181
1182       <varlistentry>
1183         <term><filename>/dev/initctl</filename></term>
1184
1185         <listitem><para>Limited compatibility support for the SysV
1186         client interface, as implemented by the
1187         <filename>systemd-initctl.service</filename> unit. This is a
1188         named pipe in the file system. This interface is obsolete and
1189         should not be used in new applications.</para></listitem>
1190       </varlistentry>
1191     </variablelist>
1192   </refsect1>
1193
1194   <refsect1>
1195     <title>See Also</title>
1196     <para>
1197       The <ulink url="https://www.freedesktop.org/wiki/Software/systemd/">systemd Homepage</ulink>,
1198       <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1199       <citerefentry project='man-pages'><refentrytitle>locale.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1200       <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
1201       <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
1202       <citerefentry><refentrytitle>systemd-notify</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
1203       <citerefentry><refentrytitle>daemon</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
1204       <citerefentry><refentrytitle>sd-daemon</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
1205       <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1206       <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1207       <citerefentry project='die-net'><refentrytitle>pkg-config</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
1208       <citerefentry><refentrytitle>kernel-command-line</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
1209       <citerefentry project='man-pages'><refentrytitle>bootup</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
1210       <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>
1211     </para>
1212   </refsect1>
1213
1214 </refentry>