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