man/systemd.xml

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