man/systemd.xml

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