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.5/docbookx.dtd">
   4 <!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
   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 systems. When run as first process on
  41     boot (as PID 1), it acts as init system that brings up and maintains userspace services. Separate
  42     instances are started for logged-in users to start their services.</para>
  43
  44     <para><command>systemd</command> is usually not invoked directly by the user, but is installed as the
  45     <filename>/sbin/init</filename> symlink and started during early boot. The user manager instances are
  46     started automatically through the
  47     <citerefentry><refentrytitle>user@.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>
  48     service.</para>
  49
  50     <para>For compatibility with SysV, if the binary is called as <command>init</command> and is not the
  51     first process on the machine (PID is not 1), it will execute <command>telinit</command> and pass all
  52     command line arguments unmodified. That means <command>init</command> and <command>telinit</command> are
  53     mostly equivalent when invoked from normal login sessions. See
  54     <citerefentry><refentrytitle>telinit</refentrytitle><manvolnum>8</manvolnum></citerefentry> for more
  55     information.</para>
  56
  57     <para>When run as a system instance, systemd interprets the
  58     configuration file <filename>system.conf</filename> and the files
  59     in <filename>system.conf.d</filename> directories; when run as a
  60     user instance, systemd interprets the configuration file
  61     <filename>user.conf</filename> and the files in
  62     <filename>user.conf.d</filename> directories. See
  63     <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
  64     for more information.</para>
  65   </refsect1>
  66
  67   <refsect1>
  68     <title>Concepts</title>
  69
  70     <para>systemd provides a dependency system between various
  71     entities called "units" of 11 different types. Units encapsulate
  72     various objects that are relevant for system boot-up and
  73     maintenance. The majority of units are configured in unit
  74     configuration files, whose syntax and basic set of options is
  75     described in
  76     <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
  77     however some are created automatically from other configuration
  78     files, dynamically from system state or programmatically at runtime.
  79     Units may be "active" (meaning started, bound, plugged in, …,
  80     depending on the unit type, see below), or "inactive" (meaning
  81     stopped, unbound, unplugged, …), as well as in the process of
  82     being activated or deactivated, i.e. between the two states (these
  83     states are called "activating", "deactivating"). A special
  84     "failed" state is available as well, which is very similar to
  85     "inactive" and is entered when the service failed in some way
  86     (process returned error code on exit, or crashed, an operation
  87     timed out, or after too many restarts). If this state is entered,
  88     the cause will be logged, for later reference. Note that the
  89     various unit types may have a number of additional substates,
  90     which are mapped to the five generalized unit states described
  91     here.</para>
  92
  93     <para>The following unit types are available:</para>
  94
  95     <orderedlist>
  96       <listitem><para>Service units, which start and control daemons
  97       and the processes they consist of. For details, see
  98       <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
  99
 100       <listitem><para>Socket units, which encapsulate local IPC or
 101       network sockets in the system, useful for socket-based
 102       activation. For details about socket units, see
 103       <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
 104       for details on socket-based activation and other forms of
 105       activation, see
 106       <citerefentry><refentrytitle>daemon</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para></listitem>
 107
 108       <listitem><para>Target units are useful to group units, or
 109       provide well-known synchronization points during boot-up, see
 110       <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
 111
 112       <listitem><para>Device units expose kernel devices in systemd
 113       and may be used to implement device-based activation. For
 114       details, see
 115       <citerefentry><refentrytitle>systemd.device</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
 116
 117       <listitem><para>Mount units control mount points in the file
 118       system, for details see
 119       <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
 120
 121       <listitem><para>Automount units provide automount capabilities,
 122       for on-demand mounting of file systems as well as parallelized
 123       boot-up. See
 124       <citerefentry><refentrytitle>systemd.automount</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
 125
 126       <listitem><para>Timer units are useful for triggering activation
 127       of other units based on timers. You may find details in
 128       <citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
 129
 130       <listitem><para>Swap units are very similar to mount units and
 131       encapsulate memory swap partitions or files of the operating
 132       system. They are described in
 133       <citerefentry><refentrytitle>systemd.swap</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
 134
 135       <listitem><para>Path units may be used to activate other
 136       services when file system objects change or are modified. See
 137       <citerefentry><refentrytitle>systemd.path</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
 138
 139       <listitem><para>Slice units may be used to group units which
 140       manage system processes (such as service and scope units) in a
 141       hierarchical tree for resource management purposes. See
 142       <citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
 143
 144       <listitem><para>Scope units are similar to service units, but
 145       manage foreign processes instead of starting them as well. See
 146       <citerefentry><refentrytitle>systemd.scope</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
 147
 148     </orderedlist>
 149
 150     <para>Units are named as their configuration files. Some units
 151     have special semantics. A detailed list is available in
 152     <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
 153
 154     <para>systemd knows various kinds of dependencies, including
 155     positive and negative requirement dependencies (i.e.
 156     <varname>Requires=</varname> and <varname>Conflicts=</varname>) as
 157     well as ordering dependencies (<varname>After=</varname> and
 158     <varname>Before=</varname>). NB: ordering and requirement
 159     dependencies are orthogonal. If only a requirement dependency
 160     exists between two units (e.g. <filename>foo.service</filename>
 161     requires <filename>bar.service</filename>), but no ordering
 162     dependency (e.g. <filename>foo.service</filename> after
 163     <filename>bar.service</filename>) and both are requested to start,
 164     they will be started in parallel. It is a common pattern that both
 165     requirement and ordering dependencies are placed between two
 166     units. Also note that the majority of dependencies are implicitly
 167     created and maintained by systemd. In most cases, it should be
 168     unnecessary to declare additional dependencies manually, however
 169     it is possible to do this.</para>
 170
 171     <para>Application programs and units (via dependencies) may
 172     request state changes of units. In systemd, these requests are
 173     encapsulated as 'jobs' and maintained in a job queue. Jobs may
 174     succeed or can fail, their execution is ordered based on the
 175     ordering dependencies of the units they have been scheduled
 176     for.</para>
 177
 178     <para>On boot systemd activates the target unit
 179     <filename>default.target</filename> whose job is to activate
 180     on-boot services and other on-boot units by pulling them in via
 181     dependencies. Usually, the unit name is just an alias (symlink) for
 182     either <filename>graphical.target</filename> (for fully-featured
 183     boots into the UI) or <filename>multi-user.target</filename> (for
 184     limited console-only boots for use in embedded or server
 185     environments, or similar; a subset of graphical.target). However,
 186     it is at the discretion of the administrator to configure it as an
 187     alias to any other target unit. See
 188     <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>
 189     for details about these target units.</para>
 190
 191     <para>On first boot, <command>systemd</command> will enable or disable units according to preset policy.
 192     See <citerefentry><refentrytitle>systemd.preset</refentrytitle><manvolnum>5</manvolnum></citerefentry>
 193     and "First Boot Semantics" in
 194     <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
 195
 196     <para>systemd only keeps a minimal set of units loaded into memory. Specifically, the only units that are
 197     kept loaded into memory are those for which at least one of the following conditions is true:</para>
 198
 199     <orderedlist>
 200       <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>
 201       <listitem><para>It has a job queued for it</para></listitem>
 202       <listitem><para>It is a dependency of at least one other unit that is loaded into memory</para></listitem>
 203       <listitem><para>It has some form of resource still allocated (e.g. a service unit that is inactive but for which
 204       a process is still lingering that ignored the request to be terminated)</para></listitem>
 205       <listitem><para>It has been pinned into memory programmatically by a D-Bus call</para></listitem>
 206     </orderedlist>
 207
 208     <para>systemd will automatically and implicitly load units from disk — if they are not loaded yet — as soon as
 209     operations are requested for them. Thus, in many respects, the fact whether a unit is loaded or not is invisible to
 210     clients. Use <command>systemctl list-units --all</command> to comprehensively list all units currently loaded. Any
 211     unit for which none of the conditions above applies is promptly unloaded. Note that when a unit is unloaded from
 212     memory its accounting data is flushed out too. However, this data is generally not lost, as a journal log record
 213     is generated declaring the consumed resources whenever a unit shuts down.</para>
 214
 215     <para>Processes systemd spawns are placed in individual Linux control groups named after the unit which
 216     they belong to in the private systemd hierarchy. (see <ulink
 217     url="https://docs.kernel.org/admin-guide/cgroup-v2.html">Control Groups v2</ulink> for more information
 218     about control groups, or short "cgroups").  systemd uses this to effectively keep track of
 219     processes. Control group information is maintained in the kernel, and is accessible via the file system
 220     hierarchy (beneath <filename>/sys/fs/cgroup/</filename>), or in tools such as <citerefentry
 221     project='man-pages'><refentrytitle>systemd-cgls</refentrytitle><manvolnum>1</manvolnum></citerefentry> or
 222     <citerefentry
 223     project='man-pages'><refentrytitle>ps</refentrytitle><manvolnum>1</manvolnum></citerefentry> (<command>ps
 224     xawf -eo pid,user,cgroup,args</command> is particularly useful to list all processes and the systemd
 225     units they belong to.).</para>
 226
 227     <para>systemd is compatible with the SysV init system to a large
 228     degree: SysV init scripts are supported and simply read as an
 229     alternative (though limited) configuration file format. The SysV
 230     <filename>/dev/initctl</filename> interface is provided, and
 231     compatibility implementations of the various SysV client tools are
 232     available. In addition to that, various established Unix
 233     functionality such as <filename>/etc/fstab</filename> or the
 234     <filename>utmp</filename> database are supported.</para>
 235
 236     <para>systemd has a minimal transaction system: if a unit is
 237     requested to start up or shut down it will add it and all its
 238     dependencies to a temporary transaction. Then, it will verify if
 239     the transaction is consistent (i.e. whether the ordering of all
 240     units is cycle-free). If it is not, systemd will try to fix it up,
 241     and removes non-essential jobs from the transaction that might
 242     remove the loop. Also, systemd tries to suppress non-essential
 243     jobs in the transaction that would stop a running service. Finally
 244     it is checked whether the jobs of the transaction contradict jobs
 245     that have already been queued, and optionally the transaction is
 246     aborted then. If all worked out and the transaction is consistent
 247     and minimized in its impact it is merged with all already
 248     outstanding jobs and added to the run queue. Effectively this
 249     means that before executing a requested operation, systemd will
 250     verify that it makes sense, fixing it if possible, and only
 251     failing if it really cannot work.</para>
 252
 253     <para>Note that transactions are generated independently of a unit's
 254     state at runtime, hence, for example, if a start job is requested on an
 255     already started unit, it will still generate a transaction and wake up any
 256     inactive dependencies (and cause propagation of other jobs as per the
 257     defined relationships). This is because the enqueued job is at the time of
 258     execution compared to the target unit's state and is marked successful and
 259     complete when both satisfy. However, this job also pulls in other
 260     dependencies due to the defined relationships and thus leads to, in our
 261     example, start jobs for any of those inactive units getting queued as
 262     well.</para>
 263
 264     <para>systemd contains native implementations of various tasks
 265     that need to be executed as part of the boot process. For example,
 266     it sets the hostname or configures the loopback network device. It
 267     also sets up and mounts various API file systems, such as
 268     <filename>/sys/</filename> or <filename>/proc/</filename>.</para>
 269
 270     <para>For more information about the concepts and
 271     ideas behind systemd, please refer to the
 272     <ulink url="https://0pointer.de/blog/projects/systemd.html">Original Design Document</ulink>.</para>
 273
 274     <para>Note that some but not all interfaces provided by systemd are covered by the
 275     <ulink url="https://systemd.io/PORTABILITY_AND_STABILITY/">Interface Portability and Stability Promise</ulink>.</para>
 276
 277     <para>Units may be generated dynamically at boot and system
 278     manager reload time, for example based on other configuration
 279     files or parameters passed on the kernel command line. For details, see
 280     <citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
 281
 282     <para>The D-Bus API of <command>systemd</command> is described in
 283     <citerefentry><refentrytitle>org.freedesktop.systemd1</refentrytitle><manvolnum>5</manvolnum></citerefentry>
 284     and
 285     <citerefentry><refentrytitle>org.freedesktop.LogControl1</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
 286     </para>
 287
 288     <para>Systems which invoke systemd in a container or initrd environment should implement the <ulink
 289     url="https://systemd.io/CONTAINER_INTERFACE">Container Interface</ulink> or
 290     <ulink url="https://systemd.io/INITRD_INTERFACE/">initrd Interface</ulink>
 291     specifications, respectively.</para>
 292   </refsect1>
 293
 294   <refsect1>
 295     <title>Directories</title>
 296
 297     <variablelist>
 298       <varlistentry>
 299         <term>System unit directories</term>
 300
 301         <listitem><para>The systemd system manager reads unit
 302         configuration from various directories. Packages that want to
 303         install unit files shall place them in the directory returned
 304         by <command>pkg-config systemd
 305         --variable=systemdsystemunitdir</command>. Other directories
 306         checked are <filename>/usr/local/lib/systemd/system</filename>
 307         and <filename>/usr/lib/systemd/system</filename>. User
 308         configuration always takes precedence. <command>pkg-config
 309         systemd --variable=systemdsystemconfdir</command> returns the
 310         path of the system configuration directory. Packages should
 311         alter the content of these directories only with the
 312         <command>enable</command> and <command>disable</command>
 313         commands of the
 314         <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
 315         tool. Full list of directories is provided in
 316         <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
 317         </para></listitem>
 318       </varlistentry>
 319     </variablelist>
 320
 321     <variablelist>
 322       <varlistentry>
 323         <term>User unit directories</term>
 324
 325         <listitem><para>Similar rules apply for the user unit
 326         directories. However, here the
 327         <ulink url="https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html">XDG
 328         Base Directory specification</ulink> is followed to find
 329         units. Applications should place their unit files in the
 330         directory returned by <command>pkg-config systemd
 331         --variable=systemduserunitdir</command>. Global configuration
 332         is done in the directory reported by <command>pkg-config
 333         systemd --variable=systemduserconfdir</command>. The
 334         <command>enable</command> and <command>disable</command>
 335         commands of the
 336         <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
 337         tool can handle both global (i.e. for all users) and private
 338         (for one user) enabling/disabling of units. Full list of
 339         directories is provided in
 340         <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
 341         </para></listitem>
 342       </varlistentry>
 343     </variablelist>
 344
 345     <variablelist>
 346       <varlistentry>
 347         <term>SysV init scripts directory</term>
 348
 349         <listitem><para>The location of the SysV init script directory
 350         varies between distributions. If systemd cannot find a native
 351         unit file for a requested service, it will look for a SysV
 352         init script of the same name (with the
 353         <filename>.service</filename> suffix
 354         removed).</para></listitem>
 355       </varlistentry>
 356     </variablelist>
 357
 358     <variablelist>
 359       <varlistentry>
 360         <term>SysV runlevel link farm directory</term>
 361
 362         <listitem><para>The location of the SysV runlevel link farm
 363         directory varies between distributions. systemd will take the
 364         link farm into account when figuring out whether a service
 365         shall be enabled. Note that a service unit with a native unit
 366         configuration file cannot be started by activating it in the
 367         SysV runlevel link farm.</para></listitem>
 368       </varlistentry>
 369     </variablelist>
 370   </refsect1>
 371
 372   <refsect1>
 373     <title>Signals</title>
 374
 375     <para>The service listens to various UNIX process signals that can be used to request various actions
 376     asynchronously. The signal handling is enabled very early during boot, before any further processes are
 377     invoked. However, a supervising container manager or similar that intends to request these operations via
 378     this mechanism must take into consideration that this functionality is not available during the earliest
 379     initialization phase. An <function>sd_notify()</function> notification message carrying the
 380     <varname>X_SYSTEMD_SIGNALS_LEVEL=2</varname> field is emitted once the signal handlers are enabled, see
 381     below. This may be used to schedule submission of these signals correctly.</para>
 382
 383     <variablelist>
 384       <varlistentry>
 385         <term><constant>SIGTERM</constant></term>
 386
 387         <listitem><para>Upon receiving this signal the systemd system
 388         manager serializes its state, reexecutes itself and
 389         deserializes the saved state again. This is mostly equivalent
 390         to <command>systemctl daemon-reexec</command>.</para>
 391
 392         <para>systemd user managers will start the
 393         <filename>exit.target</filename> unit when this signal is
 394         received. This is mostly equivalent to <command>systemctl
 395         --user start exit.target
 396         --job-mode=replace-irreversibly</command>.</para></listitem>
 397       </varlistentry>
 398
 399       <varlistentry>
 400         <term><constant>SIGINT</constant></term>
 401
 402         <listitem><para>Upon receiving this signal the systemd system manager will start the
 403         <filename>ctrl-alt-del.target</filename> unit. This is mostly equivalent to
 404         <command>systemctl start ctrl-alt-del.target --job-mode=replace-irreversibly</command>. If
 405         this signal is received more than 7 times per 2s, an immediate reboot is triggered. Note
 406         that pressing
 407         <keycombo><keycap>Ctrl</keycap><keycap>Alt</keycap><keycap>Del</keycap></keycombo> on the
 408         console will trigger this signal. Hence, if a reboot is hanging, pressing
 409         <keycombo><keycap>Ctrl</keycap><keycap>Alt</keycap><keycap>Del</keycap></keycombo> more than
 410         7 times in 2 seconds is a relatively safe way to trigger an immediate reboot.</para>
 411
 412         <para>systemd user managers treat this signal the same way as
 413         <constant>SIGTERM</constant>.</para></listitem>
 414       </varlistentry>
 415
 416       <varlistentry>
 417         <term><constant>SIGWINCH</constant></term>
 418
 419         <listitem><para>When this signal is received the systemd
 420         system manager will start the
 421         <filename>kbrequest.target</filename> unit. This is mostly
 422         equivalent to <command>systemctl start
 423         kbrequest.target</command>.</para>
 424
 425         <para>This signal is ignored by systemd user
 426         managers.</para></listitem>
 427       </varlistentry>
 428
 429       <varlistentry>
 430         <term><constant>SIGPWR</constant></term>
 431
 432         <listitem><para>When this signal is received the systemd
 433         manager will start the <filename>sigpwr.target</filename>
 434         unit. This is mostly equivalent to <command>systemctl start
 435         sigpwr.target</command>.</para></listitem>
 436       </varlistentry>
 437
 438       <varlistentry>
 439         <term><constant>SIGUSR1</constant></term>
 440
 441         <listitem><para>When this signal is received the systemd
 442         manager will try to reconnect to the D-Bus
 443         bus.</para></listitem>
 444       </varlistentry>
 445
 446       <varlistentry>
 447         <term><constant>SIGUSR2</constant></term>
 448
 449         <listitem><para>When this signal is received the systemd
 450         manager will log its complete state in human-readable form.
 451         The data logged is the same as printed by
 452         <command>systemd-analyze dump</command>.</para></listitem>
 453       </varlistentry>
 454
 455       <varlistentry>
 456         <term><constant>SIGHUP</constant></term>
 457
 458         <listitem><para>Reloads the complete daemon configuration.
 459         This is mostly equivalent to <command>systemctl
 460         daemon-reload</command>.</para></listitem>
 461       </varlistentry>
 462
 463       <varlistentry>
 464         <term><constant>SIGRTMIN+0</constant></term>
 465
 466         <listitem><para>Enters default mode, starts the
 467         <filename>default.target</filename> unit. This is mostly
 468         equivalent to <command>systemctl isolate
 469         default.target</command>.</para></listitem>
 470       </varlistentry>
 471
 472       <varlistentry>
 473         <term><constant>SIGRTMIN+1</constant></term>
 474
 475         <listitem><para>Enters rescue mode, starts the
 476         <filename>rescue.target</filename> unit. This is mostly
 477         equivalent to <command>systemctl isolate
 478         rescue.target</command>.</para></listitem>
 479       </varlistentry>
 480
 481       <varlistentry>
 482         <term><constant>SIGRTMIN+2</constant></term>
 483
 484         <listitem><para>Enters emergency mode, starts the
 485         <filename>emergency.service</filename> unit. This is mostly
 486         equivalent to <command>systemctl isolate
 487         emergency.service</command>.</para></listitem>
 488       </varlistentry>
 489
 490       <varlistentry>
 491         <term><constant>SIGRTMIN+3</constant></term>
 492
 493         <listitem><para>Halts the machine, starts the
 494         <filename>halt.target</filename> unit. This is mostly
 495         equivalent to <command>systemctl start halt.target
 496         --job-mode=replace-irreversibly</command>.</para>
 497         </listitem>
 498       </varlistentry>
 499
 500       <varlistentry>
 501         <term><constant>SIGRTMIN+4</constant></term>
 502
 503         <listitem><para>Powers off the machine, starts the
 504         <filename>poweroff.target</filename> unit. This is mostly
 505         equivalent to <command>systemctl start poweroff.target
 506         --job-mode=replace-irreversibly</command>.</para>
 507         </listitem>
 508       </varlistentry>
 509
 510       <varlistentry>
 511         <term><constant>SIGRTMIN+5</constant></term>
 512
 513         <listitem><para>Reboots the machine, starts the
 514         <filename>reboot.target</filename> unit. This is mostly
 515         equivalent to <command>systemctl start reboot.target
 516         --job-mode=replace-irreversibly</command>.</para>
 517         </listitem>
 518       </varlistentry>
 519
 520       <varlistentry>
 521         <term><constant>SIGRTMIN+6</constant></term>
 522
 523         <listitem><para>Reboots the machine via kexec, starts the
 524         <filename>kexec.target</filename> unit. This is mostly
 525         equivalent to <command>systemctl start kexec.target
 526         --job-mode=replace-irreversibly</command>.</para>
 527         </listitem>
 528       </varlistentry>
 529
 530       <varlistentry>
 531         <term><constant>SIGRTMIN+7</constant></term>
 532
 533         <listitem><para>Reboots userspace, starts the <filename>soft-reboot.target</filename> unit. This is
 534         mostly equivalent to <command>systemctl start soft-reboot.target
 535         --job-mode=replace-irreversibly</command>.</para>
 536
 537         <xi:include href="version-info.xml" xpointer="v254"/>
 538         </listitem>
 539       </varlistentry>
 540
 541       <varlistentry>
 542         <term><constant>SIGRTMIN+13</constant></term>
 543
 544         <listitem><para>Immediately halts the machine.</para></listitem>
 545       </varlistentry>
 546
 547       <varlistentry>
 548         <term><constant>SIGRTMIN+14</constant></term>
 549
 550         <listitem><para>Immediately powers off the machine.</para></listitem>
 551       </varlistentry>
 552
 553       <varlistentry>
 554         <term><constant>SIGRTMIN+15</constant></term>
 555
 556         <listitem><para>Immediately reboots the machine.</para></listitem>
 557       </varlistentry>
 558
 559       <varlistentry>
 560         <term><constant>SIGRTMIN+16</constant></term>
 561
 562         <listitem><para>Immediately reboots the machine with kexec.</para></listitem>
 563       </varlistentry>
 564
 565       <varlistentry>
 566         <term><constant>SIGRTMIN+17</constant></term>
 567
 568         <listitem><para>Immediately reboots the userspace.</para>
 569
 570         <xi:include href="version-info.xml" xpointer="v254"/></listitem>
 571       </varlistentry>
 572
 573       <varlistentry>
 574         <term><constant>SIGRTMIN+20</constant></term>
 575
 576         <listitem><para>Enables display of status messages on the
 577         console, as controlled via
 578         <varname>systemd.show_status=1</varname> on the kernel command
 579         line.</para></listitem>
 580       </varlistentry>
 581
 582       <varlistentry>
 583         <term><constant>SIGRTMIN+21</constant></term>
 584
 585         <listitem><para>Disables display of
 586         status messages on the console, as
 587         controlled via
 588         <varname>systemd.show_status=0</varname>
 589         on the kernel command
 590         line.</para></listitem>
 591       </varlistentry>
 592
 593       <varlistentry>
 594         <term><constant>SIGRTMIN+22</constant></term>
 595
 596         <listitem><para>Sets the service manager's log level to <literal>debug</literal>, in a fashion equivalent to
 597         <varname>systemd.log_level=debug</varname> on the kernel command line.</para></listitem>
 598       </varlistentry>
 599
 600       <varlistentry>
 601         <term><constant>SIGRTMIN+23</constant></term>
 602
 603         <listitem><para>Restores the log level to its configured value. The configured value is derived from – in order
 604         of priority – the value specified with <varname>systemd.log-level=</varname> on the kernel command line, or the
 605         value specified with <option>LogLevel=</option> in the configuration file, or the built-in default of
 606         <literal>info</literal>.</para>
 607
 608         <xi:include href="version-info.xml" xpointer="v239"/></listitem>
 609       </varlistentry>
 610
 611       <varlistentry>
 612         <term><constant>SIGRTMIN+24</constant></term>
 613
 614         <listitem><para>Immediately exits the manager (only available
 615         for --user instances).</para>
 616
 617         <xi:include href="version-info.xml" xpointer="v195"/></listitem>
 618       </varlistentry>
 619
 620       <varlistentry>
 621         <term><constant>SIGRTMIN+25</constant></term>
 622
 623         <listitem><para>Upon receiving this signal the systemd manager will reexecute itself. This
 624         is mostly equivalent to <command>systemctl daemon-reexec</command> except that it will be
 625         done asynchronously.</para>
 626
 627         <para>The systemd system manager treats this signal the same way as
 628         <constant>SIGTERM</constant>.</para>
 629
 630         <xi:include href="version-info.xml" xpointer="v250"/></listitem>
 631       </varlistentry>
 632
 633       <varlistentry>
 634         <term><constant>SIGRTMIN+26</constant></term>
 635
 636         <listitem><para>Restores the log target to its configured value. The configured value is derived from – in
 637         order of priority – the value specified with <varname>systemd.log-target=</varname> on the kernel command line,
 638         or the value specified with <option>LogTarget=</option> in the configuration file, or the built-in
 639         default.</para>
 640
 641         <xi:include href="version-info.xml" xpointer="v239"/></listitem>
 642       </varlistentry>
 643
 644       <varlistentry>
 645         <term><constant>SIGRTMIN+27</constant></term>
 646         <term><constant>SIGRTMIN+28</constant></term>
 647
 648         <listitem><para>Sets the log target to <literal>console</literal> on <constant>SIGRTMIN+27</constant> (or
 649         <literal>kmsg</literal> on <constant>SIGRTMIN+28</constant>), in a fashion equivalent to
 650         <varname>systemd.log_target=console</varname> (or <varname>systemd.log_target=kmsg</varname> on
 651         <constant>SIGRTMIN+28</constant>) on the kernel command line.</para>
 652
 653         <xi:include href="version-info.xml" xpointer="v239"/></listitem>
 654       </varlistentry>
 655     </variablelist>
 656   </refsect1>
 657
 658   <refsect1>
 659     <title>Environment</title>
 660
 661     <para>The environment block for the system manager is initially set by the kernel. (In particular,
 662     <literal>key=value</literal> assignments on the kernel command line are turned into environment
 663     variables for PID 1). For the user manager, the system manager sets the environment as described in the
 664     "Environment Variables in Spawned Processes" section of
 665     <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>. The
 666     <varname>DefaultEnvironment=</varname> setting in the system manager applies to all services including
 667     <filename>user@.service</filename>. Additional entries may be configured (as for any other service)
 668     through the <varname>Environment=</varname> and <varname>EnvironmentFile=</varname> settings for
 669     <filename>user@.service</filename> (see
 670     <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>). Also,
 671     additional environment variables may be set through the <varname>ManagerEnvironment=</varname> setting in
 672     <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
 673     and
 674     <citerefentry><refentrytitle>systemd-user.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
 675     </para>
 676
 677     <para>Some of the variables understood by <command>systemd</command>:</para>
 678
 679     <variablelist class='environment-variables'>
 680       <varlistentry>
 681         <term><varname>$SYSTEMD_LOG_LEVEL</varname></term>
 682         <listitem><xi:include href="common-variables.xml" xpointer="log-level-body" />
 683
 684         <para>This can be overridden with <option>--log-level=</option>.</para></listitem>
 685       </varlistentry>
 686
 687       <varlistentry>
 688         <term><varname>$SYSTEMD_LOG_COLOR</varname></term>
 689         <listitem><xi:include href="common-variables.xml" xpointer="log-color-body" />
 690
 691         <para>This can be overridden with <option>--log-color=</option>.</para></listitem>
 692       </varlistentry>
 693
 694       <varlistentry>
 695         <term><varname>$SYSTEMD_LOG_TIME</varname></term>
 696         <listitem><xi:include href="common-variables.xml" xpointer="log-time-body" />
 697
 698         <para>This can be overridden with <option>--log-time=</option>.</para>
 699
 700         <xi:include href="version-info.xml" xpointer="v246"/></listitem>
 701       </varlistentry>
 702
 703       <varlistentry>
 704         <term><varname>$SYSTEMD_LOG_LOCATION</varname></term>
 705         <listitem><xi:include href="common-variables.xml" xpointer="log-location-body" />
 706
 707         <para>This can be overridden with <option>--log-location=</option>.</para></listitem>
 708       </varlistentry>
 709
 710       <varlistentry>
 711         <term><varname>$SYSTEMD_LOG_TID</varname></term>
 712         <listitem><xi:include href="common-variables.xml" xpointer="log-tid-body" />
 713
 714         <xi:include href="version-info.xml" xpointer="v247"/></listitem>
 715       </varlistentry>
 716
 717       <varlistentry>
 718         <term><varname>$SYSTEMD_LOG_TARGET</varname></term>
 719         <listitem><xi:include href="common-variables.xml" xpointer="log-target-body" />
 720
 721         <para>This can be overridden with <option>--log-target=</option>.</para></listitem>
 722       </varlistentry>
 723
 724       <varlistentry>
 725         <term><varname>$SYSTEMD_LOG_RATELIMIT_KMSG</varname></term>
 726         <listitem><xi:include href="common-variables.xml" xpointer="log-ratelimit-kmsg-body" />
 727
 728         <xi:include href="version-info.xml" xpointer="v254"/></listitem>
 729       </varlistentry>
 730
 731       <varlistentry>
 732         <term><varname>$XDG_CONFIG_HOME</varname></term>
 733         <term><varname>$XDG_CONFIG_DIRS</varname></term>
 734         <term><varname>$XDG_DATA_HOME</varname></term>
 735         <term><varname>$XDG_DATA_DIRS</varname></term>
 736
 737         <listitem><para>The systemd user manager uses these variables
 738         in accordance to the <ulink
 739         url="https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html">XDG
 740         Base Directory specification</ulink> to find its
 741         configuration.</para></listitem>
 742       </varlistentry>
 743
 744       <varlistentry>
 745         <term><varname>$SYSTEMD_UNIT_PATH</varname></term>
 746         <term><varname>$SYSTEMD_GENERATOR_PATH</varname></term>
 747         <term><varname>$SYSTEMD_ENVIRONMENT_GENERATOR_PATH</varname></term>
 748
 749         <listitem><para>Controls where systemd looks for unit files and
 750         generators.</para>
 751         <para>These variables may contain a list of paths, separated by colons
 752         (<literal>:</literal>). When set, if the list ends with an empty
 753         component (<literal>...:</literal>), this list is prepended to the
 754         usual set of paths. Otherwise, the specified list replaces the usual
 755         set of paths.
 756         </para></listitem>
 757       </varlistentry>
 758
 759       <xi:include href="common-variables.xml" xpointer="pager"/>
 760       <xi:include href="common-variables.xml" xpointer="less"/>
 761       <xi:include href="common-variables.xml" xpointer="lesscharset"/>
 762       <xi:include href="common-variables.xml" xpointer="lesssecure"/>
 763       <xi:include href="common-variables.xml" xpointer="colors"/>
 764       <xi:include href="common-variables.xml" xpointer="urlify"/>
 765
 766       <varlistentry>
 767         <term><varname>$LISTEN_PID</varname></term>
 768         <term><varname>$LISTEN_FDS</varname></term>
 769         <term><varname>$LISTEN_FDNAMES</varname></term>
 770
 771         <listitem><para>Set by systemd for supervised processes during
 772         socket-based activation. See
 773         <citerefentry><refentrytitle>sd_listen_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry>
 774         for more information.</para></listitem>
 775       </varlistentry>
 776
 777       <varlistentry>
 778         <term><varname>$NOTIFY_SOCKET</varname></term>
 779
 780         <listitem><para>Set by service manager for its services for status and readiness notifications. Also
 781         consumed by service manager for notifying supervising container managers or service managers up the
 782         stack about its own progress. See
 783         <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry> and the
 784         relevant section below for more information.</para></listitem>
 785       </varlistentry>
 786     </variablelist>
 787
 788     <para>For further environment variables understood by systemd and its various components, see <ulink
 789     url="https://systemd.io/ENVIRONMENT">Known Environment Variables</ulink>.</para>
 790   </refsect1>
 791
 792   <refsect1>
 793     <title>Kernel Command Line</title>
 794
 795     <para>When run as the system instance, systemd parses a number of options listed below. They can be
 796     specified as kernel command line arguments which are parsed from a number of sources depending on the
 797     environment in which systemd is executed. If run inside a Linux container, these options are parsed from
 798     the command line arguments passed to systemd itself, next to any of the command line options listed in
 799     the Options section above. If run outside of Linux containers, these arguments are parsed from
 800     <filename>/proc/cmdline</filename> and from the <literal>SystemdOptions</literal> EFI variable
 801     (on EFI systems) instead. Options from <filename>/proc/cmdline</filename> have higher priority.</para>
 802
 803     <para>Note: use of <literal>SystemdOptions</literal> is deprecated.</para>
 804
 805     <para>The following variables are understood:</para>
 806
 807     <variablelist class='kernel-commandline-options'>
 808       <varlistentry>
 809         <term><varname>systemd.unit=</varname></term>
 810         <term><varname>rd.systemd.unit=</varname></term>
 811
 812         <listitem><para>Overrides the unit to activate on boot.  Defaults to
 813         <filename>default.target</filename>. This may be used to temporarily boot into a different boot unit,
 814         for example <filename>rescue.target</filename> or <filename>emergency.service</filename>. See
 815         <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>
 816         for details about these units. The option prefixed with <literal>rd.</literal> is honored only in the
 817         initrd, while the one that is not prefixed only in the main system.</para></listitem>
 818       </varlistentry>
 819
 820       <varlistentry>
 821         <term><varname>systemd.dump_core</varname></term>
 822
 823         <listitem><para>Takes a boolean argument or enables the option if specified
 824         without an argument. If enabled, the systemd manager (PID 1) dumps core when
 825         it crashes. Otherwise, no core dump is created. Defaults to enabled.</para>
 826
 827         <xi:include href="version-info.xml" xpointer="v233"/>
 828         </listitem>
 829       </varlistentry>
 830
 831       <varlistentry>
 832         <term><varname>systemd.crash_chvt</varname></term>
 833
 834         <listitem><para>Takes a positive integer, or a boolean argument. Can be also specified without an
 835         argument, with the same effect as a positive boolean. If a positive integer (in the range 1–63) is
 836         specified, the system manager (PID 1) will activate the specified virtual terminal when it crashes.
 837         Defaults to disabled, meaning that no such switch is attempted. If set to enabled, the virtual
 838         terminal the kernel messages are written to is used instead.</para>
 839
 840         <xi:include href="version-info.xml" xpointer="v233"/></listitem>
 841       </varlistentry>
 842
 843       <varlistentry>
 844         <term><varname>systemd.crash_shell</varname></term>
 845
 846         <listitem><para>Takes a boolean argument or enables the option if specified
 847         without an argument. If enabled, the system manager (PID 1) spawns a shell
 848         when it crashes, after a 10s delay. Otherwise, no shell is spawned. Defaults
 849         to disabled, for security reasons, as the shell is not protected by password
 850         authentication.</para>
 851
 852         <xi:include href="version-info.xml" xpointer="v233"/></listitem>
 853       </varlistentry>
 854
 855       <varlistentry>
 856         <term><varname>systemd.crash_reboot</varname></term>
 857
 858         <listitem><para>Takes a boolean argument or enables the option if specified
 859         without an argument. If enabled, the system manager (PID 1) will reboot the
 860         machine automatically when it crashes, after a 10s delay.  Otherwise, the
 861         system will hang indefinitely. Defaults to disabled, in order to avoid a
 862         reboot loop. If combined with <varname>systemd.crash_shell</varname>, the
 863         system is rebooted after the shell exits.</para>
 864
 865         <xi:include href="version-info.xml" xpointer="v227"/></listitem>
 866       </varlistentry>
 867
 868       <varlistentry>
 869         <term><varname>systemd.confirm_spawn</varname></term>
 870
 871         <listitem><para>Takes a boolean argument or a path to the virtual console
 872         where the confirmation messages should be emitted. Can be also specified
 873         without an argument, with the same effect as a positive boolean. If enabled,
 874         the system manager (PID 1) asks for confirmation when spawning processes
 875         using <option>/dev/console</option>. If a path or a console name (such as
 876         <literal>ttyS0</literal>) is provided, the virtual console pointed to by this
 877         path or described by the give name will be used instead. Defaults to disabled.
 878         </para>
 879
 880         <xi:include href="version-info.xml" xpointer="v233"/></listitem>
 881       </varlistentry>
 882
 883       <varlistentry>
 884         <term><varname>systemd.service_watchdogs=</varname></term>
 885
 886         <listitem><para>Takes a boolean argument. If disabled, all service runtime
 887         watchdogs (<option>WatchdogSec=</option>) and emergency actions (e.g.
 888         <option>OnFailure=</option> or <option>StartLimitAction=</option>) are
 889         ignored by the system manager (PID 1); see
 890         <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
 891         Defaults to enabled, i.e. watchdogs and failure actions are processed
 892         normally. The hardware watchdog is not affected by this
 893         option.</para>
 894
 895         <xi:include href="version-info.xml" xpointer="v237"/></listitem>
 896       </varlistentry>
 897
 898       <varlistentry>
 899         <term><varname>systemd.show_status</varname></term>
 900
 901         <listitem><para>Takes a boolean argument or the constants <constant>error</constant> and
 902         <constant>auto</constant>. Can be also specified without an argument, with the same effect as a
 903         positive boolean. If enabled, the systemd manager (PID 1) shows terse service status updates on the
 904         console during bootup. With <constant>error</constant>, only messages about failures are shown, but
 905         boot is otherwise quiet. <constant>auto</constant> behaves like <option>false</option> until there is
 906         a significant delay in boot. Defaults to enabled, unless <option>quiet</option> is passed as kernel
 907         command line option, in which case it defaults to <constant>error</constant>. If specified overrides
 908         the system manager configuration file option <option>ShowStatus=</option>, see
 909         <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
 910         </para>
 911
 912         <xi:include href="version-info.xml" xpointer="v233"/></listitem>
 913       </varlistentry>
 914
 915       <varlistentry>
 916         <term><varname>systemd.status_unit_format=</varname></term>
 917
 918         <listitem><para>Takes <option>name</option>, <option>description</option> or
 919         <option>combined</option> as the value. If <option>name</option>, the system manager will use unit
 920         names in status messages. If <option>combined</option>, the system manager will use unit names and
 921         description in status messages. When specified, overrides the system manager configuration file
 922         option <option>StatusUnitFormat=</option>, see
 923         <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
 924         </para>
 925
 926         <xi:include href="version-info.xml" xpointer="v243"/></listitem>
 927       </varlistentry>
 928
 929       <varlistentry>
 930         <term><varname>systemd.log_color</varname></term>
 931         <term><varname>systemd.log_level=</varname></term>
 932         <term><varname>systemd.log_location</varname></term>
 933         <term><varname>systemd.log_target=</varname></term>
 934         <term><varname>systemd.log_time</varname></term>
 935         <term><varname>systemd.log_tid</varname></term>
 936         <term><varname>systemd.log_ratelimit_kmsg</varname></term>
 937
 938         <listitem><para>Controls log output, with the same effect as the
 939         <varname>$SYSTEMD_LOG_COLOR</varname>, <varname>$SYSTEMD_LOG_LEVEL</varname>,
 940         <varname>$SYSTEMD_LOG_LOCATION</varname>, <varname>$SYSTEMD_LOG_TARGET</varname>,
 941         <varname>$SYSTEMD_LOG_TIME</varname>, <varname>$SYSTEMD_LOG_TID</varname> and
 942         <varname>$SYSTEMD_LOG_RATELIMIT_KMSG</varname> environment variables described above.
 943         <varname>systemd.log_color</varname>, <varname>systemd.log_location</varname>,
 944         <varname>systemd.log_time</varname>, <varname>systemd.log_tid</varname> and
 945         <varname>systemd.log_ratelimit_kmsg</varname> can be specified without
 946         an argument, with the same effect as a positive boolean.</para></listitem>
 947       </varlistentry>
 948
 949       <varlistentry>
 950         <term><varname>systemd.default_standard_output=</varname></term>
 951         <term><varname>systemd.default_standard_error=</varname></term>
 952
 953         <listitem><para>Controls default standard output and error output for services and sockets. That is,
 954         controls the default for <option>StandardOutput=</option> and <option>StandardError=</option> (see
 955         <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
 956         details). Takes one of <option>inherit</option>, <option>null</option>, <option>tty</option>,
 957         <option>journal</option>, <option>journal+console</option>, <option>kmsg</option>,
 958         <option>kmsg+console</option>. If the argument is omitted
 959         <varname>systemd.default-standard-output=</varname> defaults to <option>journal</option> and
 960         <varname>systemd.default-standard-error=</varname> to <option>inherit</option>.</para></listitem>
 961       </varlistentry>
 962
 963       <varlistentry>
 964         <term><varname>systemd.setenv=</varname></term>
 965
 966         <listitem><para>Takes a string argument in the form
 967         VARIABLE=VALUE. May be used to set default environment
 968         variables to add to forked child processes. May be used more
 969         than once to set multiple variables.</para></listitem>
 970       </varlistentry>
 971
 972       <varlistentry>
 973         <term><varname>systemd.machine_id=</varname></term>
 974
 975         <listitem><para>Takes a 32 character hex value to be
 976         used for setting the machine-id. Intended mostly for
 977         network booting where the same machine-id is desired
 978         for every boot.</para>
 979
 980         <xi:include href="version-info.xml" xpointer="v229"/></listitem>
 981       </varlistentry>
 982
 983       <varlistentry>
 984         <term><varname>systemd.set_credential=</varname></term>
 985         <term><varname>systemd.set_credential_binary=</varname></term>
 986
 987         <listitem><para>Sets a system credential, which can then be propagated to system services using the
 988         <varname>ImportCredential=</varname> or <varname>LoadCredential=</varname> setting, see
 989         <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
 990         details. Takes a pair of credential name and value, separated by a colon. The
 991         <varname>systemd.set_credential=</varname> parameter expects the credential value in literal text
 992         form, the <varname>systemd.set_credential_binary=</varname> parameter takes binary data encoded in
 993         Base64. Note that the kernel command line is typically accessible by unprivileged programs in
 994         <filename>/proc/cmdline</filename>. Thus, this mechanism is not suitable for transferring sensitive
 995         data. Use it only for data that is not sensitive (e.g. public keys/certificates, rather than private
 996         keys), or in testing/debugging environments.</para>
 997
 998         <para>For further information see <ulink url="https://systemd.io/CREDENTIALS">System and Service
 999         Credentials</ulink> documentation.</para>
1000
1001         <xi:include href="version-info.xml" xpointer="v251"/></listitem>
1002       </varlistentry>
1003
1004       <varlistentry>
1005         <term><varname>systemd.import_credentials=</varname></term>
1006
1007         <listitem><para>Takes a boolean argument. If false disables importing credentials from the kernel
1008         command line, the DMI/SMBIOS OEM string table, the qemu_fw_cfg subsystem or the EFI kernel
1009         stub.</para>
1010
1011         <xi:include href="version-info.xml" xpointer="v251"/></listitem>
1012       </varlistentry>
1013
1014       <varlistentry>
1015         <term><varname>quiet</varname></term>
1016
1017         <listitem><para>Turn off status output at boot, much like
1018         <varname>systemd.show_status=no</varname> would. Note that
1019         this option is also read by the kernel itself and disables
1020         kernel log output. Passing this option hence turns off the
1021         usual output from both the system manager and the kernel.
1022         </para>
1023
1024         <xi:include href="version-info.xml" xpointer="v186"/></listitem>
1025       </varlistentry>
1026
1027       <varlistentry>
1028         <term><varname>debug</varname></term>
1029
1030         <listitem><para>Turn on debugging output. This is equivalent
1031         to <varname>systemd.log_level=debug</varname>. Note that this
1032         option is also read by the kernel itself and enables kernel
1033         debug output. Passing this option hence turns on the debug
1034         output from both the system manager and the
1035         kernel.</para>
1036
1037         <xi:include href="version-info.xml" xpointer="v205"/></listitem>
1038       </varlistentry>
1039
1040       <varlistentry>
1041         <term><varname>emergency</varname></term>
1042         <term><varname>rd.emergency</varname></term>
1043         <term><varname>-b</varname></term>
1044
1045         <listitem><para>Boot into emergency mode. This is equivalent
1046         to <varname>systemd.unit=emergency.target</varname> or
1047         <varname>rd.systemd.unit=emergency.target</varname>, respectively, and
1048         provided for compatibility reasons and to be easier to type.</para>
1049
1050         <xi:include href="version-info.xml" xpointer="v186"/></listitem>
1051       </varlistentry>
1052
1053       <varlistentry>
1054         <term><varname>rescue</varname></term>
1055         <term><varname>rd.rescue</varname></term>
1056         <term><varname>single</varname></term>
1057         <term><varname>s</varname></term>
1058         <term><varname>S</varname></term>
1059         <term><varname>1</varname></term>
1060
1061         <listitem><para>Boot into rescue mode. This is equivalent to
1062         <varname>systemd.unit=rescue.target</varname> or
1063         <varname>rd.systemd.unit=rescue.target</varname>, respectively, and
1064         provided for compatibility reasons and to be easier to type.</para>
1065
1066         <xi:include href="version-info.xml" xpointer="v186"/></listitem>
1067       </varlistentry>
1068
1069       <varlistentry>
1070         <term><varname>2</varname></term>
1071         <term><varname>3</varname></term>
1072         <term><varname>4</varname></term>
1073         <term><varname>5</varname></term>
1074
1075         <listitem><para>Boot into the specified legacy SysV runlevel.
1076         These are equivalent to
1077         <varname>systemd.unit=runlevel2.target</varname>,
1078         <varname>systemd.unit=runlevel3.target</varname>,
1079         <varname>systemd.unit=runlevel4.target</varname>, and
1080         <varname>systemd.unit=runlevel5.target</varname>,
1081         respectively, and provided for compatibility reasons and to be
1082         easier to type.</para>
1083
1084         <xi:include href="version-info.xml" xpointer="v186"/></listitem>
1085       </varlistentry>
1086
1087       <varlistentry>
1088         <term><varname>locale.LANG=</varname></term>
1089         <term><varname>locale.LANGUAGE=</varname></term>
1090         <term><varname>locale.LC_CTYPE=</varname></term>
1091         <term><varname>locale.LC_NUMERIC=</varname></term>
1092         <term><varname>locale.LC_TIME=</varname></term>
1093         <term><varname>locale.LC_COLLATE=</varname></term>
1094         <term><varname>locale.LC_MONETARY=</varname></term>
1095         <term><varname>locale.LC_MESSAGES=</varname></term>
1096         <term><varname>locale.LC_PAPER=</varname></term>
1097         <term><varname>locale.LC_NAME=</varname></term>
1098         <term><varname>locale.LC_ADDRESS=</varname></term>
1099         <term><varname>locale.LC_TELEPHONE=</varname></term>
1100         <term><varname>locale.LC_MEASUREMENT=</varname></term>
1101         <term><varname>locale.LC_IDENTIFICATION=</varname></term>
1102
1103         <listitem><para>Set the system locale to use. This overrides
1104         the settings in <filename>/etc/locale.conf</filename>. For
1105         more information, see
1106         <citerefentry project='man-pages'><refentrytitle>locale.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
1107         and
1108         <citerefentry project='man-pages'><refentrytitle>locale</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
1109         </para>
1110
1111         <xi:include href="version-info.xml" xpointer="v186"/></listitem>
1112       </varlistentry>
1113     </variablelist>
1114
1115     <para>For other kernel command line parameters understood by
1116     components of the core OS, please refer to
1117     <citerefentry><refentrytitle>kernel-command-line</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
1118   </refsect1>
1119
1120   <refsect1>
1121     <title>System Credentials</title>
1122
1123     <para>During initialization the service manager will import credentials from various sources into the
1124     system's set of credentials, which can then be propagated into services and consumed by
1125     generators:</para>
1126
1127     <itemizedlist>
1128       <listitem><para>When the service manager first initializes it will read system credentials from SMBIOS
1129       Type 11 vendor strings
1130       <varname>io.systemd.credential:<replaceable>name</replaceable>=<replaceable>value</replaceable></varname>,
1131       and
1132       <varname>io.systemd.credential.binary:<replaceable>name</replaceable>=<replaceable>value</replaceable></varname>.</para></listitem>
1133
1134       <listitem><para>At the same time it will import credentials from QEMU <literal>fw_cfg</literal>. (Note
1135       that the SMBIOS mechanism is generally preferred, because it is faster and generic.)</para></listitem>
1136
1137       <listitem><para>Credentials may be passed via the kernel command line, using the
1138       <varname>systemd.set-credential=</varname> parameter, see above.</para></listitem>
1139
1140       <listitem><para>Credentials may be passed from the UEFI environment via
1141       <citerefentry><refentrytitle>systemd-stub</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para></listitem>
1142
1143       <listitem><para>When the service manager is invoked during the initrd → host transition it will import
1144       all files in <filename>/run/credentials/@initrd/</filename> as system credentials.</para></listitem>
1145     </itemizedlist>
1146
1147     <para>Invoke
1148     <citerefentry><refentrytitle>systemd-creds</refentrytitle><manvolnum>1</manvolnum></citerefentry> as
1149     follows to see the list of credentials passed into the system:</para>
1150
1151     <programlisting># systemd-creds --system list</programlisting>
1152
1153     <para>For further information see <ulink url="https://systemd.io/CREDENTIALS">System and Service
1154     Credentials</ulink> documentation.</para>
1155
1156     <para>The service manager when run as PID 1 consumes the following system credentials:</para>
1157
1158     <variablelist class='system-credentials'>
1159       <varlistentry>
1160         <term><varname>vmm.notify_socket</varname></term>
1161         <listitem>
1162           <para>Contains a <constant>AF_VSOCK</constant> or <constant>AF_UNIX</constant> address where to
1163           send a <constant>READY=1</constant> notification message when the service manager has completed
1164           booting. See
1165           <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry> and
1166           the next section for more information. Note that in case the hypervisor does not support
1167           <constant>SOCK_DGRAM</constant> over <constant>AF_VSOCK</constant>,
1168           <constant>SOCK_SEQPACKET</constant> will be tried instead. The credential payload for
1169           <constant>AF_VSOCK</constant> should be a string in the form
1170           <literal>vsock:CID:PORT</literal>. <literal>vsock-stream</literal>, <literal>vsock-dgram</literal>
1171           and <literal>vsock-seqpacket</literal> can be used instead of <literal>vsock</literal> to force
1172           usage of the corresponding socket type.</para>
1173
1174           <para>This feature is useful for machine managers or other processes on the host to receive a
1175           notification via VSOCK when a virtual machine has finished booting.</para>
1176
1177           <xi:include href="version-info.xml" xpointer="v254"/>
1178         </listitem>
1179       </varlistentry>
1180
1181       <varlistentry>
1182         <term><varname>system.machine_id</varname></term>
1183         <listitem>
1184           <para>Takes a 128bit hexadecimal ID to initialize <filename>/etc/machine-id</filename> from, if the
1185           file is not set up yet. See
1186           <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
1187           details.</para>
1188
1189         <xi:include href="version-info.xml" xpointer="v254"/>
1190         </listitem>
1191       </varlistentry>
1192     </variablelist>
1193
1194     <para>For a list of system credentials various other components of systemd consume, see
1195     <citerefentry><refentrytitle>systemd.system-credentials</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
1196   </refsect1>
1197
1198   <refsect1>
1199     <title>Readiness Protocol</title>
1200
1201     <para>The service manager implements a readiness notification protocol both between the manager and its
1202     services (i.e. down the stack), and between the manager and a potential supervisor further up the stack
1203     (the latter could be a machine or container manager, or in case of a per-user service manager the system
1204     service manager instance). The basic protocol (and the suggested API for it) is described in
1205     <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para>
1206
1207     <para>The notification socket the service manager (including PID 1) uses for reporting readiness to its
1208     own supervisor is set via the usual <varname>$NOTIFY_SOCKET</varname> environment variable (see
1209     above). Since this is directly settable only for container managers and for the per-user instance of the
1210     service manager, an additional mechanism to configure this is available, in particular intended for use
1211     in VM environments: the <varname>vmm.notify_socket</varname> system credential (see above) may be set to
1212     a suitable socket (typically an <constant>AF_VSOCK</constant> one) via SMBIOS Type 11 vendor strings. For
1213     details see above.</para>
1214
1215     <para>The notification protocol from the service manager up the stack towards a supervisor supports a
1216     number of extension fields that allow a supervisor to learn about specific properties of the system and
1217     track its boot progress. Specifically the following fields are sent:</para>
1218
1219     <itemizedlist>
1220       <listitem><para>An <varname>X_SYSTEMD_HOSTNAME=…</varname> message will be sent out once the initial
1221       hostname for the system has been determined. Note that during later runtime the hostname might be
1222       changed again programmatically, and (currently) no further notifications are sent out in that case.</para>
1223
1224       <xi:include href="version-info.xml" xpointer="v256"/></listitem>
1225
1226       <listitem><para>An <varname>X_SYSTEMD_MACHINE_ID=…</varname> message will be sent out once the machine
1227       ID of the system has been determined. See
1228       <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
1229       details.</para>
1230
1231       <xi:include href="version-info.xml" xpointer="v256"/></listitem>
1232
1233       <listitem><para>An <varname>X_SYSTEMD_SIGNALS_LEVEL=…</varname> message will be sent out once the
1234       service manager installed the various UNIX process signal handlers described above. The field's value
1235       is an unsigned integer formatted as decimal string, and indicates the supported UNIX process signal
1236       feature level of the service manager. Currently, only a single feature level is defined:</para>
1237
1238       <itemizedlist>
1239         <listitem><para><varname>X_SYSTEMD_SIGNALS_LEVEL=2</varname> covers the various UNIX process signals
1240         documented above – which are a superset of those supported by the historical SysV init
1241         system.</para></listitem>
1242       </itemizedlist>
1243
1244       <para>Signals sent to PID 1 before this message is sent might not be handled correctly yet. A consumer
1245       of these messages should parse the value as an unsigned integer indication the level of support. For
1246       now only the mentioned level 2 is defined, but later on additional levels might be defined with higher
1247       integers, that will implement a superset of the currently defined behaviour.</para>
1248
1249       <xi:include href="version-info.xml" xpointer="v256"/></listitem>
1250
1251       <listitem><para><varname>X_SYSTEMD_UNIT_ACTIVE=…</varname> and
1252       <varname>X_SYSTEMD_UNIT_INACTIVE=…</varname> messages will be sent out for each target unit as it
1253       becomes active or stops being active. This is useful to track boot progress and functionality. For
1254       example, once the <filename>ssh-access.target</filename> unit is reported started SSH access is
1255       typically available, see
1256       <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
1257       details.</para>
1258
1259       <xi:include href="version-info.xml" xpointer="v256"/></listitem>
1260     </itemizedlist>
1261
1262     <para>Note that these extension fields are sent in addition to the regular <literal>READY=1</literal> and
1263     <literal>RELOADING=1</literal> notifications.</para>
1264   </refsect1>
1265
1266   <refsect1>
1267     <title>Options</title>
1268
1269     <para><command>systemd</command> is only very rarely invoked directly, since it is started early and is
1270     already running by the time users may interact with it. Normally, tools like
1271     <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> are used to
1272     give commands to the manager. Since <command>systemd</command> is usually not invoked directly, the
1273     options listed below are mostly useful for debugging and special purposes.</para>
1274
1275     <refsect2>
1276       <title>Introspection and debugging options</title>
1277
1278       <para>Those options are used for testing and introspection, and <command>systemd</command> may
1279       be invoked with them at any time:</para>
1280
1281       <variablelist>
1282         <varlistentry>
1283           <term><option>--dump-configuration-items</option></term>
1284
1285           <listitem><para>Dump understood unit configuration items. This outputs a terse but complete list of
1286           configuration items understood in unit definition files.</para></listitem>
1287         </varlistentry>
1288
1289         <varlistentry>
1290           <term><option>--dump-bus-properties</option></term>
1291
1292           <listitem><para>Dump exposed bus properties. This outputs a terse but complete list of properties
1293           exposed on D-Bus.</para>
1294
1295           <xi:include href="version-info.xml" xpointer="v239"/></listitem>
1296         </varlistentry>
1297
1298         <varlistentry>
1299           <term><option>--test</option></term>
1300
1301           <listitem><para>Determine the initial start-up transaction (i.e. the list of jobs enqueued at
1302           start-up), dump it and exit — without actually executing any of the determined jobs. This option is
1303           useful for debugging only. Note that during regular service manager start-up additional units not
1304           shown by this operation may be started, because hardware, socket, bus or other kinds of activation
1305           might add additional jobs as the transaction is executed. Use <option>--system</option> to request
1306           the initial transaction of the system service manager (this is also the implied default), combine
1307           with <option>--user</option> to request the initial transaction of the per-user service manager
1308           instead.</para></listitem>
1309         </varlistentry>
1310
1311         <varlistentry>
1312           <term><option>--system</option></term>
1313           <term><option>--user</option></term>
1314
1315           <listitem><para>When used in conjunction with <option>--test</option>, selects whether to calculate
1316           the initial transaction for the system instance or for a per-user instance. These options have no
1317           effect when invoked without <option>--test</option>, as during regular
1318           (i.e. non-<option>--test</option>) invocations the service manager will automatically detect
1319           whether it shall operate in system or per-user mode, by checking whether the PID it is run as is 1
1320           or not. Note that it is not supported booting and maintaining a system with the service manager
1321           running in <option>--system</option> mode but with a PID other than 1.</para></listitem>
1322         </varlistentry>
1323
1324         <xi:include href="standard-options.xml" xpointer="help" />
1325         <xi:include href="standard-options.xml" xpointer="version" />
1326       </variablelist>
1327     </refsect2>
1328
1329     <refsect2>
1330       <title>Options that duplicate kernel command line settings</title>
1331
1332       <para>Those options correspond directly to options listed above in "Kernel Command Line". Both forms
1333       may be used equivalently for the system manager, but it is recommended to use the forms listed above in
1334       this context, because they are properly namespaced. When an option is specified both on the kernel
1335       command line and as a normal command line argument, the latter has higher precedence.</para>
1336
1337       <para>When <command>systemd</command> is used as a user manager, the kernel command line is ignored and
1338       only the options described below are understood. Nevertheless, <command>systemd</command> is usually
1339       started in this mode through the
1340       <citerefentry><refentrytitle>user@.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>
1341       service, which is shared between all users. It may be more convenient to use configuration files to
1342       modify settings (see
1343       <citerefentry><refentrytitle>systemd-user.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>),
1344       or environment variables. See the "Environment" section above for a discussion of how the environment
1345       block is set.</para>
1346
1347       <variablelist>
1348         <varlistentry>
1349           <term><option>--unit=</option></term>
1350
1351           <listitem><para>Set default unit to activate on startup. If not specified, defaults to
1352           <filename>default.target</filename>. See <varname>systemd.unit=</varname> above.</para></listitem>
1353         </varlistentry>
1354
1355         <varlistentry>
1356           <term><option>--dump-core</option></term>
1357
1358           <listitem><para>Enable core dumping on crash. This switch has no effect when running as user
1359           instance. Same as <varname>systemd.dump_core=</varname> above.</para></listitem>
1360         </varlistentry>
1361
1362         <varlistentry>
1363           <term><option>--crash-vt=<replaceable>VT</replaceable></option></term>
1364
1365           <listitem><para>Switch to a specific virtual console (VT) on crash. This switch has no effect when
1366           running as user instance. Same as <varname>systemd.crash_chvt=</varname> above (but not the
1367           different spelling!).</para>
1368
1369           <xi:include href="version-info.xml" xpointer="v227"/></listitem>
1370         </varlistentry>
1371
1372         <varlistentry>
1373           <term><option>--crash-shell</option></term>
1374
1375           <listitem><para>Run a shell on crash. This switch has no effect when running as user instance. See
1376           <varname>systemd.crash_shell=</varname> above.</para></listitem>
1377         </varlistentry>
1378
1379         <varlistentry>
1380           <term><option>--crash-reboot</option></term>
1381
1382           <listitem><para>Automatically reboot the system on crash. This switch has no effect when running as
1383           user instance. See <varname>systemd.crash_reboot</varname> above.</para>
1384
1385           <xi:include href="version-info.xml" xpointer="v227"/></listitem>
1386         </varlistentry>
1387
1388         <varlistentry>
1389           <term><option>--confirm-spawn</option></term>
1390
1391           <listitem><para>Ask for confirmation when spawning processes. This switch has no effect when run as
1392           user instance. See <varname>systemd.confirm_spawn</varname> above.</para></listitem>
1393         </varlistentry>
1394
1395         <varlistentry>
1396           <term><option>--show-status</option></term>
1397
1398           <listitem><para>Show terse unit status information on the console during boot-up and shutdown. See
1399           <varname>systemd.show_status</varname> above.</para>
1400
1401           <xi:include href="version-info.xml" xpointer="v244"/></listitem>
1402         </varlistentry>
1403
1404         <varlistentry>
1405           <term><option>--log-color</option></term>
1406
1407           <listitem><para>Highlight important log messages. See <varname>systemd.log_color</varname> above.
1408           </para>
1409
1410           <xi:include href="version-info.xml" xpointer="v244"/></listitem>
1411         </varlistentry>
1412
1413         <varlistentry>
1414           <term><option>--log-level=</option></term>
1415
1416           <listitem><para>Set log level. See <varname>systemd.log_level</varname> above.</para></listitem>
1417         </varlistentry>
1418
1419         <varlistentry>
1420           <term><option>--log-location</option></term>
1421
1422           <listitem><para>Include code location in log messages. See <varname>systemd.log_location</varname>
1423           above.</para>
1424
1425           <xi:include href="version-info.xml" xpointer="v244"/></listitem>
1426         </varlistentry>
1427
1428         <varlistentry>
1429           <term><option>--log-target=</option></term>
1430
1431           <listitem><para>Set log target. See <varname>systemd.log_target</varname> above.</para></listitem>
1432         </varlistentry>
1433
1434         <varlistentry>
1435           <term><option>--log-time=</option></term>
1436
1437           <listitem><para>Prefix console messages with timestamp. See <varname>systemd.log_time</varname> above.
1438           </para>
1439
1440           <xi:include href="version-info.xml" xpointer="v246"/></listitem>
1441         </varlistentry>
1442
1443         <varlistentry>
1444           <term><option>--machine-id=</option></term>
1445
1446           <listitem><para>Override the machine-id set on the hard drive. See
1447           <varname>systemd.machine_id=</varname> above.</para>
1448
1449           <xi:include href="version-info.xml" xpointer="v229"/></listitem>
1450         </varlistentry>
1451
1452         <varlistentry>
1453           <term><option>--service-watchdogs</option></term>
1454
1455           <listitem><para>Globally enable/disable all service watchdog timeouts and emergency actions. See
1456           <varname>systemd.service_watchdogs</varname> above.</para>
1457
1458           <xi:include href="version-info.xml" xpointer="v237"/></listitem>
1459         </varlistentry>
1460
1461         <varlistentry>
1462           <term><option>--default-standard-output=</option></term>
1463           <term><option>--default-standard-error=</option></term>
1464
1465           <listitem><para>Sets the default output or error output for all services and sockets,
1466           respectively. See <varname>systemd.default_standard_output=</varname> and
1467           <varname>systemd.default_standard_error=</varname> above.</para></listitem>
1468         </varlistentry>
1469       </variablelist>
1470     </refsect2>
1471   </refsect1>
1472
1473   <refsect1>
1474     <title>Sockets and FIFOs</title>
1475
1476     <variablelist>
1477       <varlistentry>
1478         <term><filename>/run/systemd/notify</filename></term>
1479
1480         <listitem><para>Daemon status notification socket. This is an
1481         <constant>AF_UNIX</constant> datagram socket and is used to
1482         implement the daemon notification logic as implemented by
1483         <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para></listitem>
1484
1485       </varlistentry>
1486
1487       <varlistentry>
1488         <term><filename>/run/systemd/private</filename></term>
1489
1490         <listitem><para>Used internally as communication channel
1491         between
1492         <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
1493         and the systemd process. This is an
1494         <constant>AF_UNIX</constant> stream socket. This interface is
1495         private to systemd and should not be used in external
1496         projects.</para></listitem>
1497       </varlistentry>
1498
1499       <varlistentry>
1500         <term><filename>/dev/initctl</filename></term>
1501
1502         <listitem><para>Limited compatibility support for the SysV
1503         client interface, as implemented by the
1504         <filename>systemd-initctl.service</filename> unit. This is a
1505         named pipe in the file system. This interface is obsolete and
1506         should not be used in new applications.</para></listitem>
1507       </varlistentry>
1508     </variablelist>
1509   </refsect1>
1510
1511   <refsect1>
1512       <title>History</title>
1513
1514       <variablelist>
1515         <varlistentry>
1516           <term>systemd 252</term>
1517           <listitem><para>Kernel command-line arguments <varname>systemd.unified_cgroup_hierarchy</varname>
1518           and <varname>systemd.legacy_systemd_cgroup_controller</varname> were deprecated. Please switch to
1519           the unified cgroup hierarchy.</para>
1520
1521           <xi:include href="version-info.xml" xpointer="v252"/></listitem>
1522         </varlistentry>
1523       </variablelist>
1524   </refsect1>
1525
1526   <refsect1>
1527     <title>See Also</title>
1528     <para><simplelist type="inline">
1529       <member>The <ulink url="https://systemd.io/">systemd Homepage</ulink></member>
1530       <member><citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry></member>
1531       <member><citerefentry project='man-pages'><refentrytitle>locale.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry></member>
1532       <member><citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry></member>
1533       <member><citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry></member>
1534       <member><citerefentry><refentrytitle>systemd-notify</refentrytitle><manvolnum>1</manvolnum></citerefentry></member>
1535       <member><citerefentry><refentrytitle>daemon</refentrytitle><manvolnum>7</manvolnum></citerefentry></member>
1536       <member><citerefentry><refentrytitle>sd-daemon</refentrytitle><manvolnum>3</manvolnum></citerefentry></member>
1537       <member><citerefentry><refentrytitle>org.freedesktop.systemd1</refentrytitle><manvolnum>5</manvolnum></citerefentry></member>
1538       <member><citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry></member>
1539       <member><citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry></member>
1540       <member><citerefentry project='die-net'><refentrytitle>pkg-config</refentrytitle><manvolnum>1</manvolnum></citerefentry></member>
1541       <member><citerefentry><refentrytitle>kernel-command-line</refentrytitle><manvolnum>7</manvolnum></citerefentry></member>
1542       <member><citerefentry project='man-pages'><refentrytitle>bootup</refentrytitle><manvolnum>7</manvolnum></citerefentry></member>
1543       <member><citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry></member>
1544     </simplelist></para>
1545   </refsect1>
1546
1547 </refentry>