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>systemd only keeps a minimal set of units loaded into memory. Specifically, the only units that are kept
 396     loaded into memory are those for which at least one of the following conditions is true:</para>
 397
 398     <orderedlist>
 399       <listitem><para>It is in an active, activating, deactivating or failed state (i.e. in any unit state except for <literal>dead</literal>)</para></listitem>
 400       <listitem><para>It has a job queued for it</para></listitem>
 401       <listitem><para>It is a dependency of some sort of at least one other unit that is loaded into memory</para></listitem>
 402       <listitem><para>It has some form of resource still allocated (e.g. a service unit that is inactive but for which
 403       a process is still lingering that ignored the request to be terminated)</para></listitem>
 404       <listitem><para>It has been pinned into memory programmatically by a D-Bus call</para></listitem>
 405     </orderedlist>
 406
 407     <para>systemd will automatically and implicitly load units from disk — if they are not loaded yet — as soon as
 408     operations are requested for them. Thus, in many respects, the fact whether a unit is loaded or not is invisible to
 409     clients. Use <command>systemctl list-units --all</command> to comprehensively list all units currently loaded. Any
 410     unit for which none of the conditions above applies is promptly unloaded. Note that when a unit is unloaded from
 411     memory its accounting data is flushed out too. However, this data is generally not lost, as a journal log record
 412     is generated declaring the consumed resources whenever a unit shuts down.</para>
 413
 414     <para>Processes systemd spawns are placed in individual Linux
 415     control groups named after the unit which they belong to in the
 416     private systemd hierarchy. (see <ulink
 417     url="https://www.kernel.org/doc/Documentation/cgroup-v1/cgroups.txt">cgroups.txt</ulink>
 418     for more information about control groups, or short "cgroups").
 419     systemd uses this to effectively keep track of processes. Control
 420     group information is maintained in the kernel, and is accessible
 421     via the file system hierarchy (beneath
 422     <filename>/sys/fs/cgroup/systemd/</filename>), or in tools such as
 423     <citerefentry project='man-pages'><refentrytitle>systemd-cgls</refentrytitle><manvolnum>1</manvolnum></citerefentry>
 424     or
 425     <citerefentry project='man-pages'><refentrytitle>ps</refentrytitle><manvolnum>1</manvolnum></citerefentry>
 426     (<command>ps xawf -eo pid,user,cgroup,args</command> is
 427     particularly useful to list all processes and the systemd units
 428     they belong to.).</para>
 429
 430     <para>systemd is compatible with the SysV init system to a large
 431     degree: SysV init scripts are supported and simply read as an
 432     alternative (though limited) configuration file format. The SysV
 433     <filename>/dev/initctl</filename> interface is provided, and
 434     compatibility implementations of the various SysV client tools are
 435     available. In addition to that, various established Unix
 436     functionality such as <filename>/etc/fstab</filename> or the
 437     <filename>utmp</filename> database are supported.</para>
 438
 439     <para>systemd has a minimal transaction system: if a unit is
 440     requested to start up or shut down it will add it and all its
 441     dependencies to a temporary transaction. Then, it will verify if
 442     the transaction is consistent (i.e. whether the ordering of all
 443     units is cycle-free). If it is not, systemd will try to fix it up,
 444     and removes non-essential jobs from the transaction that might
 445     remove the loop. Also, systemd tries to suppress non-essential
 446     jobs in the transaction that would stop a running service. Finally
 447     it is checked whether the jobs of the transaction contradict jobs
 448     that have already been queued, and optionally the transaction is
 449     aborted then. If all worked out and the transaction is consistent
 450     and minimized in its impact it is merged with all already
 451     outstanding jobs and added to the run queue. Effectively this
 452     means that before executing a requested operation, systemd will
 453     verify that it makes sense, fixing it if possible, and only
 454     failing if it really cannot work.</para>
 455
 456     <para>systemd contains native implementations of various tasks
 457     that need to be executed as part of the boot process. For example,
 458     it sets the hostname or configures the loopback network device. It
 459     also sets up and mounts various API file systems, such as
 460     <filename>/sys</filename> or <filename>/proc</filename>.</para>
 461
 462     <para>For more information about the concepts and
 463     ideas behind systemd, please refer to the
 464     <ulink url="http://0pointer.de/blog/projects/systemd.html">Original Design Document</ulink>.</para>
 465
 466     <para>Note that some but not all interfaces provided
 467     by systemd are covered by the
 468     <ulink url="https://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise">Interface
 469     Stability Promise</ulink>.</para>
 470
 471     <para>Units may be generated dynamically at boot and system
 472     manager reload time, for example based on other configuration
 473     files or parameters passed on the kernel command line. For details, see
 474     <citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
 475
 476     <para>Systems which invoke systemd in a container or initrd
 477     environment should implement the
 478     <ulink url="https://www.freedesktop.org/wiki/Software/systemd/ContainerInterface">Container Interface</ulink> or
 479     <ulink url="https://www.freedesktop.org/wiki/Software/systemd/InitrdInterface">initrd Interface</ulink>
 480     specifications, respectively.</para>
 481   </refsect1>
 482
 483   <refsect1>
 484     <title>Directories</title>
 485
 486     <variablelist>
 487       <varlistentry>
 488         <term>System unit directories</term>
 489
 490         <listitem><para>The systemd system manager reads unit
 491         configuration from various directories. Packages that want to
 492         install unit files shall place them in the directory returned
 493         by <command>pkg-config systemd
 494         --variable=systemdsystemunitdir</command>. Other directories
 495         checked are <filename>/usr/local/lib/systemd/system</filename>
 496         and <filename>/usr/lib/systemd/system</filename>. User
 497         configuration always takes precedence. <command>pkg-config
 498         systemd --variable=systemdsystemconfdir</command> returns the
 499         path of the system configuration directory. Packages should
 500         alter the content of these directories only with the
 501         <command>enable</command> and <command>disable</command>
 502         commands of the
 503         <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
 504         tool. Full list of directories is provided in
 505         <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
 506         </para></listitem>
 507       </varlistentry>
 508     </variablelist>
 509
 510     <variablelist>
 511       <varlistentry>
 512         <term>User unit directories</term>
 513
 514         <listitem><para>Similar rules apply for the user unit
 515         directories. However, here the
 516         <ulink url="http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html">XDG
 517         Base Directory specification</ulink> is followed to find
 518         units. Applications should place their unit files in the
 519         directory returned by <command>pkg-config systemd
 520         --variable=systemduserunitdir</command>. Global configuration
 521         is done in the directory reported by <command>pkg-config
 522         systemd --variable=systemduserconfdir</command>. The
 523         <command>enable</command> and <command>disable</command>
 524         commands of the
 525         <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
 526         tool can handle both global (i.e. for all users) and private
 527         (for one user) enabling/disabling of units. Full list of
 528         directories is provided in
 529         <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
 530         </para></listitem>
 531       </varlistentry>
 532     </variablelist>
 533
 534     <variablelist>
 535       <varlistentry>
 536         <term>SysV init scripts directory</term>
 537
 538         <listitem><para>The location of the SysV init script directory
 539         varies between distributions. If systemd cannot find a native
 540         unit file for a requested service, it will look for a SysV
 541         init script of the same name (with the
 542         <filename>.service</filename> suffix
 543         removed).</para></listitem>
 544       </varlistentry>
 545     </variablelist>
 546
 547     <variablelist>
 548       <varlistentry>
 549         <term>SysV runlevel link farm directory</term>
 550
 551         <listitem><para>The location of the SysV runlevel link farm
 552         directory varies between distributions. systemd will take the
 553         link farm into account when figuring out whether a service
 554         shall be enabled. Note that a service unit with a native unit
 555         configuration file cannot be started by activating it in the
 556         SysV runlevel link farm.</para></listitem>
 557       </varlistentry>
 558     </variablelist>
 559   </refsect1>
 560
 561   <refsect1>
 562     <title>Signals</title>
 563
 564     <variablelist>
 565       <varlistentry>
 566         <term><constant>SIGTERM</constant></term>
 567
 568         <listitem><para>Upon receiving this signal the systemd system
 569         manager serializes its state, reexecutes itself and
 570         deserializes the saved state again. This is mostly equivalent
 571         to <command>systemctl daemon-reexec</command>.</para>
 572
 573         <para>systemd user managers will start the
 574         <filename>exit.target</filename> unit when this signal is
 575         received. This is mostly equivalent to <command>systemctl
 576         --user start exit.target
 577         --job-mode=replace-irreversible</command>.</para></listitem>
 578       </varlistentry>
 579
 580       <varlistentry>
 581         <term><constant>SIGINT</constant></term>
 582
 583         <listitem><para>Upon receiving this signal the systemd system manager will start the
 584         <filename>ctrl-alt-del.target</filename> unit. This is mostly equivalent to
 585         <command>systemctl start ctrl-alt-del.target --job-mode=replace-irreversible</command>. If
 586         this signal is received more than 7 times per 2s, an immediate reboot is triggered. Note
 587         that pressing
 588         <keycombo><keycap>Ctrl</keycap><keycap>Alt</keycap><keycap>Del</keycap></keycombo> on the
 589         console will trigger this signal. Hence, if a reboot is hanging, pressing
 590         <keycombo><keycap>Ctrl</keycap><keycap>Alt</keycap><keycap>Del</keycap></keycombo> more than
 591         7 times in 2 seconds is a relatively safe way to trigger an immediate reboot.</para>
 592
 593         <para>systemd user managers treat this signal the same way as
 594         <constant>SIGTERM</constant>.</para></listitem>
 595       </varlistentry>
 596
 597       <varlistentry>
 598         <term><constant>SIGWINCH</constant></term>
 599
 600         <listitem><para>When this signal is received the systemd
 601         system manager will start the
 602         <filename>kbrequest.target</filename> unit. This is mostly
 603         equivalent to <command>systemctl start
 604         kbrequest.target</command>.</para>
 605
 606         <para>This signal is ignored by systemd user
 607         managers.</para></listitem>
 608       </varlistentry>
 609
 610       <varlistentry>
 611         <term><constant>SIGPWR</constant></term>
 612
 613         <listitem><para>When this signal is received the systemd
 614         manager will start the <filename>sigpwr.target</filename>
 615         unit. This is mostly equivalent to <command>systemctl start
 616         sigpwr.target</command>.</para></listitem>
 617       </varlistentry>
 618
 619       <varlistentry>
 620         <term><constant>SIGUSR1</constant></term>
 621
 622         <listitem><para>When this signal is received the systemd
 623         manager will try to reconnect to the D-Bus
 624         bus.</para></listitem>
 625       </varlistentry>
 626
 627       <varlistentry>
 628         <term><constant>SIGUSR2</constant></term>
 629
 630         <listitem><para>When this signal is received the systemd
 631         manager will log its complete state in human-readable form.
 632         The data logged is the same as printed by
 633         <command>systemd-analyze dump</command>.</para></listitem>
 634       </varlistentry>
 635
 636       <varlistentry>
 637         <term><constant>SIGHUP</constant></term>
 638
 639         <listitem><para>Reloads the complete daemon configuration.
 640         This is mostly equivalent to <command>systemctl
 641         daemon-reload</command>.</para></listitem>
 642       </varlistentry>
 643
 644       <varlistentry>
 645         <term><constant>SIGRTMIN+0</constant></term>
 646
 647         <listitem><para>Enters default mode, starts the
 648         <filename>default.target</filename> unit. This is mostly
 649         equivalent to <command>systemctl isolate
 650         default.target</command>.</para></listitem>
 651       </varlistentry>
 652
 653       <varlistentry>
 654         <term><constant>SIGRTMIN+1</constant></term>
 655
 656         <listitem><para>Enters rescue mode, starts the
 657         <filename>rescue.target</filename> unit. This is mostly
 658         equivalent to <command>systemctl isolate
 659         rescue.target</command>.</para></listitem>
 660       </varlistentry>
 661
 662       <varlistentry>
 663         <term><constant>SIGRTMIN+2</constant></term>
 664
 665         <listitem><para>Enters emergency mode, starts the
 666         <filename>emergency.service</filename> unit. This is mostly
 667         equivalent to <command>systemctl isolate
 668         emergency.service</command>.</para></listitem>
 669       </varlistentry>
 670
 671       <varlistentry>
 672         <term><constant>SIGRTMIN+3</constant></term>
 673
 674         <listitem><para>Halts the machine, starts the
 675         <filename>halt.target</filename> unit. This is mostly
 676         equivalent to <command>systemctl start halt.target
 677         --job-mode=replace-irreversible</command>.</para>
 678         </listitem>
 679       </varlistentry>
 680
 681       <varlistentry>
 682         <term><constant>SIGRTMIN+4</constant></term>
 683
 684         <listitem><para>Powers off the machine, starts the
 685         <filename>poweroff.target</filename> unit. This is mostly
 686         equivalent to <command>systemctl start poweroff.target
 687         --job-mode=replace-irreversible</command>.</para>
 688         </listitem>
 689       </varlistentry>
 690
 691       <varlistentry>
 692         <term><constant>SIGRTMIN+5</constant></term>
 693
 694         <listitem><para>Reboots the machine, starts the
 695         <filename>reboot.target</filename> unit. This is mostly
 696         equivalent to <command>systemctl start reboot.target
 697         --job-mode=replace-irreversible</command>.</para>
 698         </listitem>
 699       </varlistentry>
 700
 701       <varlistentry>
 702         <term><constant>SIGRTMIN+6</constant></term>
 703
 704         <listitem><para>Reboots the machine via kexec, starts the
 705         <filename>kexec.target</filename> unit. This is mostly
 706         equivalent to <command>systemctl start kexec.target
 707         --job-mode=replace-irreversible</command>.</para>
 708         </listitem>
 709       </varlistentry>
 710
 711       <varlistentry>
 712         <term><constant>SIGRTMIN+13</constant></term>
 713
 714         <listitem><para>Immediately halts the machine.</para></listitem>
 715       </varlistentry>
 716
 717       <varlistentry>
 718         <term><constant>SIGRTMIN+14</constant></term>
 719
 720         <listitem><para>Immediately powers off the machine.</para></listitem>
 721       </varlistentry>
 722
 723       <varlistentry>
 724         <term><constant>SIGRTMIN+15</constant></term>
 725
 726         <listitem><para>Immediately reboots the machine.</para></listitem>
 727       </varlistentry>
 728
 729       <varlistentry>
 730         <term><constant>SIGRTMIN+16</constant></term>
 731
 732         <listitem><para>Immediately reboots the machine with kexec.</para></listitem>
 733       </varlistentry>
 734
 735       <varlistentry>
 736         <term><constant>SIGRTMIN+20</constant></term>
 737
 738         <listitem><para>Enables display of status messages on the
 739         console, as controlled via
 740         <varname>systemd.show_status=1</varname> on the kernel command
 741         line.</para></listitem>
 742       </varlistentry>
 743
 744       <varlistentry>
 745         <term><constant>SIGRTMIN+21</constant></term>
 746
 747         <listitem><para>Disables display of
 748         status messages on the console, as
 749         controlled via
 750         <varname>systemd.show_status=0</varname>
 751         on the kernel command
 752         line.</para></listitem>
 753       </varlistentry>
 754
 755       <varlistentry>
 756         <term><constant>SIGRTMIN+22</constant></term>
 757
 758         <listitem><para>Sets the service manager's log level to <literal>debug</literal>, in a fashion equivalent to
 759         <varname>systemd.log_level=debug</varname> on the kernel command line.</para></listitem>
 760       </varlistentry>
 761
 762       <varlistentry>
 763         <term><constant>SIGRTMIN+23</constant></term>
 764
 765         <listitem><para>Restores the log level to its configured value. The configured value is derived from – in order
 766         of priority – the value specified with <varname>systemd.log-level=</varname> on the kernel command line, or the
 767         value specified with <option>LogLevel=</option> in the configuration file, or the built-in default of
 768         <literal>info</literal>.</para></listitem>
 769       </varlistentry>
 770
 771       <varlistentry>
 772         <term><constant>SIGRTMIN+24</constant></term>
 773
 774         <listitem><para>Immediately exits the manager (only available
 775         for --user instances).</para></listitem>
 776       </varlistentry>
 777
 778       <varlistentry>
 779         <term><constant>SIGRTMIN+26</constant></term>
 780
 781         <listitem><para>Restores the log target to its configured value. The configured value is derived from – in
 782         order of priority – the value specified with <varname>systemd.log-target=</varname> on the kernel command line,
 783         or the value specified with <option>LogTarget=</option> in the configuration file, or the built-in
 784         default.</para></listitem>
 785       </varlistentry>
 786
 787       <varlistentry>
 788         <term><constant>SIGRTMIN+27</constant></term>
 789         <term><constant>SIGRTMIN+28</constant></term>
 790
 791         <listitem><para>Sets the log target to <literal>console</literal> on <constant>SIGRTMIN+27</constant> (or
 792         <literal>kmsg</literal> on <constant>SIGRTMIN+28</constant>), in a fashion equivalent to
 793         <varname>systemd.log_target=console</varname> (or <varname>systemd.log_target=kmsg</varname> on
 794         <constant>SIGRTMIN+28</constant>) on the kernel command line.</para></listitem>
 795       </varlistentry>
 796     </variablelist>
 797   </refsect1>
 798
 799   <refsect1>
 800     <title>Environment</title>
 801
 802     <variablelist class='environment-variables'>
 803       <varlistentry>
 804         <term><varname>$SYSTEMD_LOG_LEVEL</varname></term>
 805         <listitem><para>systemd reads the log level from this
 806         environment variable. This can be overridden with
 807         <option>--log-level=</option>.</para></listitem>
 808       </varlistentry>
 809
 810       <varlistentry>
 811         <term><varname>$SYSTEMD_LOG_TARGET</varname></term>
 812         <listitem><para>systemd reads the log target from this
 813         environment variable. This can be overridden with
 814         <option>--log-target=</option>.</para></listitem>
 815       </varlistentry>
 816
 817       <varlistentry>
 818         <term><varname>$SYSTEMD_LOG_COLOR</varname></term>
 819         <listitem><para>Controls whether systemd highlights important
 820         log messages. This can be overridden with
 821         <option>--log-color=</option>.</para></listitem>
 822       </varlistentry>
 823
 824       <varlistentry>
 825         <term><varname>$SYSTEMD_LOG_LOCATION</varname></term>
 826         <listitem><para>Controls whether systemd prints the code
 827         location along with log messages. This can be overridden with
 828         <option>--log-location=</option>.</para></listitem>
 829       </varlistentry>
 830
 831       <varlistentry>
 832         <term><varname>$XDG_CONFIG_HOME</varname></term>
 833         <term><varname>$XDG_CONFIG_DIRS</varname></term>
 834         <term><varname>$XDG_DATA_HOME</varname></term>
 835         <term><varname>$XDG_DATA_DIRS</varname></term>
 836
 837         <listitem><para>The systemd user manager uses these variables
 838         in accordance to the <ulink
 839         url="http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html">XDG
 840         Base Directory specification</ulink> to find its
 841         configuration.</para></listitem>
 842       </varlistentry>
 843
 844       <varlistentry>
 845         <term><varname>$SYSTEMD_UNIT_PATH</varname></term>
 846
 847         <listitem><para>Controls where systemd looks for unit
 848         files.</para></listitem>
 849       </varlistentry>
 850
 851       <varlistentry>
 852         <term><varname>$SYSTEMD_SYSVINIT_PATH</varname></term>
 853
 854         <listitem><para>Controls where systemd looks for SysV init
 855         scripts.</para></listitem>
 856       </varlistentry>
 857
 858       <varlistentry>
 859         <term><varname>$SYSTEMD_SYSVRCND_PATH</varname></term>
 860
 861         <listitem><para>Controls where systemd looks for SysV init
 862         script runlevel link farms.</para></listitem>
 863       </varlistentry>
 864
 865       <varlistentry>
 866         <term><varname>$SYSTEMD_COLORS</varname></term>
 867
 868         <listitem><para>The value must be a boolean. Controls whether colorized output should be
 869         generated. This can be specified to override the decision that <command>systemd</command>
 870         makes based on <varname>$TERM</varname> and what the console is connected to.</para>
 871         </listitem>
 872       </varlistentry>
 873
 874       <varlistentry>
 875         <term><varname>$SYSTEMD_URLIFY</varname></term>
 876
 877         <listitem><para>The value must be a boolean. Controls whether clickable links should be generated in the output
 878         for terminal emulators supporting this. This can be specified to override the decision that
 879         <command>systemd</command> makes based on <varname>$TERM</varname> and other conditions.</para>
 880         </listitem>
 881       </varlistentry>
 882
 883       <varlistentry>
 884         <term><varname>$LISTEN_PID</varname></term>
 885         <term><varname>$LISTEN_FDS</varname></term>
 886         <term><varname>$LISTEN_FDNAMES</varname></term>
 887
 888         <listitem><para>Set by systemd for supervised processes during
 889         socket-based activation. See
 890         <citerefentry><refentrytitle>sd_listen_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry>
 891         for more information.</para></listitem>
 892       </varlistentry>
 893
 894       <varlistentry>
 895         <term><varname>$NOTIFY_SOCKET</varname></term>
 896
 897         <listitem><para>Set by systemd for supervised processes for
 898         status and start-up completion notification. See
 899         <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>
 900         for more information.</para></listitem>
 901       </varlistentry>
 902     </variablelist>
 903
 904     <para>For further environment variables understood by systemd and its various components, see <ulink
 905     url="https://systemd.io/ENVIRONMENT">Known Environment Variables</ulink>.</para>
 906   </refsect1>
 907
 908   <refsect1>
 909     <title>Kernel Command Line</title>
 910
 911     <para>When run as system instance systemd parses a number of
 912     kernel command line arguments<footnote><para>If run inside a Linux
 913     container these arguments may be passed as command line arguments
 914     to systemd itself, next to any of the command line options listed
 915     in the Options section above. If run outside of Linux containers,
 916     these arguments are parsed from <filename>/proc/cmdline</filename>
 917     instead.</para></footnote>:</para>
 918
 919     <variablelist class='kernel-commandline-options'>
 920       <varlistentry>
 921         <term><varname>systemd.unit=</varname></term>
 922         <term><varname>rd.systemd.unit=</varname></term>
 923
 924         <listitem><para>Overrides the unit to activate on boot.
 925         Defaults to <filename>default.target</filename>. This may be
 926         used to temporarily boot into a different boot unit, for
 927         example <filename>rescue.target</filename> or
 928         <filename>emergency.service</filename>. See
 929         <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>
 930         for details about these units. The option prefixed with
 931         <literal>rd.</literal> is honored only in the initial RAM disk
 932         (initrd), while the one that is not prefixed only in the main
 933         system.</para></listitem>
 934       </varlistentry>
 935
 936       <varlistentry>
 937         <term><varname>systemd.dump_core</varname></term>
 938
 939         <listitem><para>Takes a boolean argument or enables the option if specified
 940         without an argument. If enabled, the systemd manager (PID 1) dumps core when
 941         it crashes. Otherwise, no core dump is created. Defaults to enabled.</para>
 942         </listitem>
 943       </varlistentry>
 944
 945       <varlistentry>
 946         <term><varname>systemd.crash_chvt</varname></term>
 947
 948         <listitem><para>Takes a positive integer, or a boolean argument. Can be also
 949         specified without an argument, with the same effect as a positive boolean. If
 950         a positive integer (in the range 1–63) is specified, the system manager (PID
 951         1) will activate the specified virtual terminal (VT) when it
 952         crashes. Defaults to disabled, meaning that no such switch is attempted. If
 953         set to enabled, the VT the kernel messages are written to is selected.
 954         </para></listitem>
 955       </varlistentry>
 956
 957       <varlistentry>
 958         <term><varname>systemd.crash_shell</varname></term>
 959
 960         <listitem><para>Takes a boolean argument or enables the option if specified
 961         without an argument. If enabled, the system manager (PID 1) spawns a shell
 962         when it crashes, after a 10s delay. Otherwise, no shell is spawned. Defaults
 963         to disabled, for security reasons, as the shell is not protected by password
 964         authentication.</para></listitem>
 965       </varlistentry>
 966
 967       <varlistentry>
 968         <term><varname>systemd.crash_reboot</varname></term>
 969
 970         <listitem><para>Takes a boolean argument or enables the option if specified
 971         without an argument. If enabled, the system manager (PID 1) will reboot the
 972         machine automatically when it crashes, after a 10s delay.  Otherwise, the
 973         system will hang indefinitely. Defaults to disabled, in order to avoid a
 974         reboot loop. If combined with <varname>systemd.crash_shell</varname>, the
 975         system is rebooted after the shell exits.</para></listitem>
 976       </varlistentry>
 977
 978       <varlistentry>
 979         <term><varname>systemd.confirm_spawn</varname></term>
 980
 981         <listitem><para>Takes a boolean argument or a path to the virtual console
 982         where the confirmation messages should be emitted. Can be also specified
 983         without an argument, with the same effect as a positive boolean. If enabled,
 984         the system manager (PID 1) asks for confirmation when spawning processes
 985         using <option>/dev/console</option>. If a path or a console name (such as
 986         <literal>ttyS0</literal>) is provided, the virtual console pointed to by this
 987         path or described by the give name will be used instead. Defaults to disabled.
 988         </para></listitem>
 989       </varlistentry>
 990
 991       <varlistentry>
 992         <term><varname>systemd.service_watchdogs=</varname></term>
 993
 994         <listitem><para>Takes a boolean argument. If disabled, all service runtime
 995         watchdogs (<option>WatchdogSec=</option>) and emergency actions (e.g.
 996         <option>OnFailure=</option> or <option>StartLimitAction=</option>) are
 997         ignored by the system manager (PID 1); see
 998         <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
 999         Defaults to enabled, i.e. watchdogs and failure actions are processed
1000         normally. The hardware watchdog is not affected by this
1001         option.</para></listitem>
1002       </varlistentry>
1003
1004       <varlistentry>
1005         <term><varname>systemd.show_status</varname></term>
1006
1007         <listitem><para>Takes a boolean argument or the constant
1008         <constant>auto</constant>. Can be also specified without an argument, with
1009         the same effect as a positive boolean.  If enabled, the systemd manager (PID
1010         1) shows terse service status updates on the console during bootup.
1011         <constant>auto</constant> behaves like <option>false</option> until a unit
1012         fails or there is a significant delay in boot. Defaults to enabled, unless
1013         <option>quiet</option> is passed as kernel command line option, in which case
1014         it defaults to <constant>auto</constant>. If specified overrides the system
1015         manager configuration file option <option>ShowStatus=</option>, see
1016         <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
1017         However, the process command line option <option>--show-status=</option>
1018         takes precedence over both this kernel command line option and the
1019         configuration file option.</para></listitem>
1020       </varlistentry>
1021
1022       <varlistentry>
1023         <term><varname>systemd.log_target=</varname></term>
1024         <term><varname>systemd.log_level=</varname></term>
1025         <term><varname>systemd.log_location=</varname></term>
1026         <term><varname>systemd.log_color</varname></term>
1027
1028         <listitem><para>Controls log output, with the same effect as the
1029         <varname>$SYSTEMD_LOG_TARGET</varname>,
1030         <varname>$SYSTEMD_LOG_LEVEL</varname>,
1031         <varname>$SYSTEMD_LOG_LOCATION</varname>,
1032         <varname>$SYSTEMD_LOG_COLOR</varname> environment variables described above.
1033         <varname>systemd.log_color</varname> can be specified without an argument,
1034         with the same effect as a positive boolean.</para></listitem>
1035       </varlistentry>
1036
1037       <varlistentry>
1038         <term><varname>systemd.default_standard_output=</varname></term>
1039         <term><varname>systemd.default_standard_error=</varname></term>
1040         <listitem><para>Controls default standard output and error
1041         output for services, with the same effect as the
1042         <option>--default-standard-output=</option> and
1043         <option>--default-standard-error=</option> command line
1044         arguments described above, respectively.</para></listitem>
1045       </varlistentry>
1046
1047       <varlistentry>
1048         <term><varname>systemd.setenv=</varname></term>
1049
1050         <listitem><para>Takes a string argument in the form
1051         VARIABLE=VALUE. May be used to set default environment
1052         variables to add to forked child processes. May be used more
1053         than once to set multiple variables.</para></listitem>
1054       </varlistentry>
1055
1056       <varlistentry>
1057         <term><varname>systemd.machine_id=</varname></term>
1058
1059         <listitem><para>Takes a 32 character hex value to be
1060         used for setting the machine-id. Intended mostly for
1061         network booting where the same machine-id is desired
1062         for every boot.</para></listitem>
1063       </varlistentry>
1064
1065       <varlistentry>
1066         <term><varname>systemd.unified_cgroup_hierarchy</varname></term>
1067
1068         <listitem><para>When specified without an argument or with a true argument,
1069         enables the usage of
1070         <ulink url="https://www.kernel.org/doc/Documentation/cgroup-v2.txt">unified cgroup hierarchy</ulink>
1071         (a.k.a. cgroups-v2). When specified with a false argument, fall back to
1072         hybrid or full legacy cgroup hierarchy.</para>
1073
1074         <para>If this option is not specified, the default behaviour is determined
1075         during compilation (the <option>-Ddefault-hierarchy=</option> meson
1076         option). If the kernel does not support unified cgroup hierarchy, the legacy
1077         hierarchy will be used even if this option is specified.</para>
1078         </listitem>
1079       </varlistentry>
1080
1081       <varlistentry>
1082         <term><varname>systemd.legacy_systemd_cgroup_controller</varname></term>
1083
1084         <listitem><para>Takes effect if the full unified cgroup hierarchy is not used
1085         (see previous option). When specified without an argument or with a true
1086         argument, disables the use of "hybrid" cgroup hierarchy (i.e. a cgroups-v2
1087         tree used for systemd, and
1088         <ulink url="https://www.kernel.org/doc/Documentation/cgroup-v1/">legacy
1089         cgroup hierarchy</ulink>, a.k.a. cgroups-v1, for other controllers), and
1090         forces a full "legacy" mode. When specified with a false argument, enables
1091         the use of "hybrid" hierarchy.</para>
1092
1093         <para>If this option is not specified, the default behaviour is determined
1094         during compilation (the <option>-Ddefault-hierarchy=</option> meson
1095         option). If the kernel does not support unified cgroup hierarchy, the legacy
1096         hierarchy will be used  even if this option is specified.</para>
1097         </listitem>
1098       </varlistentry>
1099
1100       <varlistentry>
1101         <term><varname>quiet</varname></term>
1102
1103         <listitem><para>Turn off status output at boot, much like
1104         <varname>systemd.show_status=no</varname> would. Note that
1105         this option is also read by the kernel itself and disables
1106         kernel log output. Passing this option hence turns off the
1107         usual output from both the system manager and the kernel.
1108         </para></listitem>
1109       </varlistentry>
1110
1111       <varlistentry>
1112         <term><varname>debug</varname></term>
1113
1114         <listitem><para>Turn on debugging output. This is equivalent
1115         to <varname>systemd.log_level=debug</varname>. Note that this
1116         option is also read by the kernel itself and enables kernel
1117         debug output. Passing this option hence turns on the debug
1118         output from both the system manager and the
1119         kernel.</para></listitem>
1120       </varlistentry>
1121
1122       <varlistentry>
1123         <term><varname>emergency</varname></term>
1124         <term><varname>rd.emergency</varname></term>
1125         <term><varname>-b</varname></term>
1126
1127         <listitem><para>Boot into emergency mode. This is equivalent
1128         to <varname>systemd.unit=emergency.target</varname> or
1129         <varname>rd.systemd.unit=emergency.target</varname>, respectively, and
1130         provided for compatibility reasons and to be easier to type.</para></listitem>
1131       </varlistentry>
1132
1133       <varlistentry>
1134         <term><varname>rescue</varname></term>
1135         <term><varname>rd.rescue</varname></term>
1136         <term><varname>single</varname></term>
1137         <term><varname>s</varname></term>
1138         <term><varname>S</varname></term>
1139         <term><varname>1</varname></term>
1140
1141         <listitem><para>Boot into rescue mode. This is equivalent to
1142         <varname>systemd.unit=rescue.target</varname> or
1143         <varname>rd.systemd.unit=rescue.target</varname>, respectively, and
1144         provided for compatibility reasons and to be easier to type.</para></listitem>
1145       </varlistentry>
1146
1147       <varlistentry>
1148         <term><varname>2</varname></term>
1149         <term><varname>3</varname></term>
1150         <term><varname>4</varname></term>
1151         <term><varname>5</varname></term>
1152
1153         <listitem><para>Boot into the specified legacy SysV runlevel.
1154         These are equivalent to
1155         <varname>systemd.unit=runlevel2.target</varname>,
1156         <varname>systemd.unit=runlevel3.target</varname>,
1157         <varname>systemd.unit=runlevel4.target</varname>, and
1158         <varname>systemd.unit=runlevel5.target</varname>,
1159         respectively, and provided for compatibility reasons and to be
1160         easier to type.</para></listitem>
1161       </varlistentry>
1162
1163       <varlistentry>
1164         <term><varname>locale.LANG=</varname></term>
1165         <term><varname>locale.LANGUAGE=</varname></term>
1166         <term><varname>locale.LC_CTYPE=</varname></term>
1167         <term><varname>locale.LC_NUMERIC=</varname></term>
1168         <term><varname>locale.LC_TIME=</varname></term>
1169         <term><varname>locale.LC_COLLATE=</varname></term>
1170         <term><varname>locale.LC_MONETARY=</varname></term>
1171         <term><varname>locale.LC_MESSAGES=</varname></term>
1172         <term><varname>locale.LC_PAPER=</varname></term>
1173         <term><varname>locale.LC_NAME=</varname></term>
1174         <term><varname>locale.LC_ADDRESS=</varname></term>
1175         <term><varname>locale.LC_TELEPHONE=</varname></term>
1176         <term><varname>locale.LC_MEASUREMENT=</varname></term>
1177         <term><varname>locale.LC_IDENTIFICATION=</varname></term>
1178
1179         <listitem><para>Set the system locale to use. This overrides
1180         the settings in <filename>/etc/locale.conf</filename>. For
1181         more information, see
1182         <citerefentry project='man-pages'><refentrytitle>locale.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
1183         and
1184         <citerefentry project='man-pages'><refentrytitle>locale</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
1185         </para></listitem>
1186       </varlistentry>
1187     </variablelist>
1188
1189     <para>For other kernel command line parameters understood by
1190     components of the core OS, please refer to
1191     <citerefentry><refentrytitle>kernel-command-line</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
1192   </refsect1>
1193
1194   <refsect1>
1195     <title>Sockets and FIFOs</title>
1196
1197     <variablelist>
1198       <varlistentry>
1199         <term><filename>/run/systemd/notify</filename></term>
1200
1201         <listitem><para>Daemon status notification socket. This is an
1202         <constant>AF_UNIX</constant> datagram socket and is used to
1203         implement the daemon notification logic as implemented by
1204         <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para></listitem>
1205
1206       </varlistentry>
1207
1208       <varlistentry>
1209         <term><filename>/run/systemd/private</filename></term>
1210
1211         <listitem><para>Used internally as communication channel
1212         between
1213         <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
1214         and the systemd process. This is an
1215         <constant>AF_UNIX</constant> stream socket. This interface is
1216         private to systemd and should not be used in external
1217         projects.</para></listitem>
1218       </varlistentry>
1219
1220       <varlistentry>
1221         <term><filename>/dev/initctl</filename></term>
1222
1223         <listitem><para>Limited compatibility support for the SysV
1224         client interface, as implemented by the
1225         <filename>systemd-initctl.service</filename> unit. This is a
1226         named pipe in the file system. This interface is obsolete and
1227         should not be used in new applications.</para></listitem>
1228       </varlistentry>
1229     </variablelist>
1230   </refsect1>
1231
1232   <refsect1>
1233     <title>See Also</title>
1234     <para>
1235       The <ulink url="https://www.freedesktop.org/wiki/Software/systemd/">systemd Homepage</ulink>,
1236       <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1237       <citerefentry project='man-pages'><refentrytitle>locale.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1238       <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
1239       <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
1240       <citerefentry><refentrytitle>systemd-notify</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
1241       <citerefentry><refentrytitle>daemon</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
1242       <citerefentry><refentrytitle>sd-daemon</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
1243       <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1244       <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1245       <citerefentry project='die-net'><refentrytitle>pkg-config</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
1246       <citerefentry><refentrytitle>kernel-command-line</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
1247       <citerefentry project='man-pages'><refentrytitle>bootup</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
1248       <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>
1249     </para>
1250   </refsect1>
1251
1252 </refentry>