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_action=</varname></term>
 857
 858         <listitem><para>Takes one of <literal>freeze</literal>, <literal>reboot</literal> or
 859         <literal>poweroff</literal>. Defaults to <literal>freeze</literal>. If set to
 860         <literal>freeze</literal>, the system will hang indefinitely when the system manager (PID 1) crashes.
 861         If set to <literal>reboot</literal>, the system manager (PID 1) will reboot the machine automatically
 862         when it crashes, after a 10s delay. If set to <literal>poweroff</literal>, the system manager (PID 1)
 863         will power off the machine immediately when it crashes. If combined with
 864         <varname>systemd.crash_shell</varname>, the configured crash action is executed after the shell
 865         exits.</para>
 866
 867         <xi:include href="version-info.xml" xpointer="v256"/></listitem>
 868       </varlistentry>
 869
 870       <varlistentry>
 871         <term><varname>systemd.confirm_spawn</varname></term>
 872
 873         <listitem><para>Takes a boolean argument or a path to the virtual console
 874         where the confirmation messages should be emitted. Can be also specified
 875         without an argument, with the same effect as a positive boolean. If enabled,
 876         the system manager (PID 1) asks for confirmation when spawning processes
 877         using <option>/dev/console</option>. If a path or a console name (such as
 878         <literal>ttyS0</literal>) is provided, the virtual console pointed to by this
 879         path or described by the give name will be used instead. Defaults to disabled.
 880         </para>
 881
 882         <xi:include href="version-info.xml" xpointer="v233"/></listitem>
 883       </varlistentry>
 884
 885       <varlistentry>
 886         <term><varname>systemd.service_watchdogs=</varname></term>
 887
 888         <listitem><para>Takes a boolean argument. If disabled, all service runtime
 889         watchdogs (<option>WatchdogSec=</option>) and emergency actions (e.g.
 890         <option>OnFailure=</option> or <option>StartLimitAction=</option>) are
 891         ignored by the system manager (PID 1); see
 892         <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
 893         Defaults to enabled, i.e. watchdogs and failure actions are processed
 894         normally. The hardware watchdog is not affected by this
 895         option.</para>
 896
 897         <xi:include href="version-info.xml" xpointer="v237"/></listitem>
 898       </varlistentry>
 899
 900       <varlistentry>
 901         <term><varname>systemd.show_status</varname></term>
 902
 903         <listitem><para>Takes a boolean argument or the constants <constant>error</constant> and
 904         <constant>auto</constant>. Can be also specified without an argument, with the same effect as a
 905         positive boolean. If enabled, the systemd manager (PID 1) shows terse service status updates on the
 906         console during bootup. With <constant>error</constant>, only messages about failures are shown, but
 907         boot is otherwise quiet. <constant>auto</constant> behaves like <option>false</option> until there is
 908         a significant delay in boot. Defaults to enabled, unless <option>quiet</option> is passed as kernel
 909         command line option, in which case it defaults to <constant>error</constant>. If specified overrides
 910         the system manager configuration file option <option>ShowStatus=</option>, see
 911         <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
 912         </para>
 913
 914         <xi:include href="version-info.xml" xpointer="v233"/></listitem>
 915       </varlistentry>
 916
 917       <varlistentry>
 918         <term><varname>systemd.status_unit_format=</varname></term>
 919
 920         <listitem><para>Takes <option>name</option>, <option>description</option> or
 921         <option>combined</option> as the value. If <option>name</option>, the system manager will use unit
 922         names in status messages. If <option>combined</option>, the system manager will use unit names and
 923         description in status messages. When specified, overrides the system manager configuration file
 924         option <option>StatusUnitFormat=</option>, see
 925         <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
 926         </para>
 927
 928         <xi:include href="version-info.xml" xpointer="v243"/></listitem>
 929       </varlistentry>
 930
 931       <varlistentry>
 932         <term><varname>systemd.log_color</varname></term>
 933         <term><varname>systemd.log_level=</varname></term>
 934         <term><varname>systemd.log_location</varname></term>
 935         <term><varname>systemd.log_target=</varname></term>
 936         <term><varname>systemd.log_time</varname></term>
 937         <term><varname>systemd.log_tid</varname></term>
 938         <term><varname>systemd.log_ratelimit_kmsg</varname></term>
 939
 940         <listitem><para>Controls log output, with the same effect as the
 941         <varname>$SYSTEMD_LOG_COLOR</varname>, <varname>$SYSTEMD_LOG_LEVEL</varname>,
 942         <varname>$SYSTEMD_LOG_LOCATION</varname>, <varname>$SYSTEMD_LOG_TARGET</varname>,
 943         <varname>$SYSTEMD_LOG_TIME</varname>, <varname>$SYSTEMD_LOG_TID</varname> and
 944         <varname>$SYSTEMD_LOG_RATELIMIT_KMSG</varname> environment variables described above.
 945         <varname>systemd.log_color</varname>, <varname>systemd.log_location</varname>,
 946         <varname>systemd.log_time</varname>, <varname>systemd.log_tid</varname> and
 947         <varname>systemd.log_ratelimit_kmsg</varname> can be specified without
 948         an argument, with the same effect as a positive boolean.</para></listitem>
 949       </varlistentry>
 950
 951       <varlistentry>
 952         <term><varname>systemd.default_standard_output=</varname></term>
 953         <term><varname>systemd.default_standard_error=</varname></term>
 954
 955         <listitem><para>Controls default standard output and error output for services and sockets. That is,
 956         controls the default for <option>StandardOutput=</option> and <option>StandardError=</option> (see
 957         <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
 958         details). Takes one of <option>inherit</option>, <option>null</option>, <option>tty</option>,
 959         <option>journal</option>, <option>journal+console</option>, <option>kmsg</option>,
 960         <option>kmsg+console</option>. If the argument is omitted
 961         <varname>systemd.default-standard-output=</varname> defaults to <option>journal</option> and
 962         <varname>systemd.default-standard-error=</varname> to <option>inherit</option>.</para></listitem>
 963       </varlistentry>
 964
 965       <varlistentry>
 966         <term><varname>systemd.setenv=</varname></term>
 967
 968         <listitem><para>Takes a string argument in the form
 969         VARIABLE=VALUE. May be used to set default environment
 970         variables to add to forked child processes. May be used more
 971         than once to set multiple variables.</para></listitem>
 972       </varlistentry>
 973
 974       <varlistentry>
 975         <term><varname>systemd.machine_id=</varname></term>
 976
 977         <listitem><para>Takes a 32 character hex value to be
 978         used for setting the machine-id. Intended mostly for
 979         network booting where the same machine-id is desired
 980         for every boot.</para>
 981
 982         <xi:include href="version-info.xml" xpointer="v229"/></listitem>
 983       </varlistentry>
 984
 985       <varlistentry>
 986         <term><varname>systemd.set_credential=</varname></term>
 987         <term><varname>systemd.set_credential_binary=</varname></term>
 988
 989         <listitem><para>Sets a system credential, which can then be propagated to system services using the
 990         <varname>ImportCredential=</varname> or <varname>LoadCredential=</varname> setting, see
 991         <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
 992         details. Takes a pair of credential name and value, separated by a colon. The
 993         <varname>systemd.set_credential=</varname> parameter expects the credential value in literal text
 994         form, the <varname>systemd.set_credential_binary=</varname> parameter takes binary data encoded in
 995         Base64. Note that the kernel command line is typically accessible by unprivileged programs in
 996         <filename>/proc/cmdline</filename>. Thus, this mechanism is not suitable for transferring sensitive
 997         data. Use it only for data that is not sensitive (e.g. public keys/certificates, rather than private
 998         keys), or in testing/debugging environments.</para>
 999
1000         <para>For further information see <ulink url="https://systemd.io/CREDENTIALS">System and Service
1001         Credentials</ulink> documentation.</para>
1002
1003         <xi:include href="version-info.xml" xpointer="v251"/></listitem>
1004       </varlistentry>
1005
1006       <varlistentry>
1007         <term><varname>systemd.import_credentials=</varname></term>
1008
1009         <listitem><para>Takes a boolean argument. If false disables importing credentials from the kernel
1010         command line, the DMI/SMBIOS OEM string table, the qemu_fw_cfg subsystem or the EFI kernel
1011         stub.</para>
1012
1013         <xi:include href="version-info.xml" xpointer="v251"/></listitem>
1014       </varlistentry>
1015
1016       <varlistentry>
1017         <term><varname>quiet</varname></term>
1018
1019         <listitem><para>Turn off status output at boot, much like
1020         <varname>systemd.show_status=no</varname> would. Note that
1021         this option is also read by the kernel itself and disables
1022         kernel log output. Passing this option hence turns off the
1023         usual output from both the system manager and the kernel.
1024         </para>
1025
1026         <xi:include href="version-info.xml" xpointer="v186"/></listitem>
1027       </varlistentry>
1028
1029       <varlistentry>
1030         <term><varname>debug</varname></term>
1031
1032         <listitem><para>Turn on debugging output. This is equivalent
1033         to <varname>systemd.log_level=debug</varname>. Note that this
1034         option is also read by the kernel itself and enables kernel
1035         debug output. Passing this option hence turns on the debug
1036         output from both the system manager and the
1037         kernel.</para>
1038
1039         <xi:include href="version-info.xml" xpointer="v205"/></listitem>
1040       </varlistentry>
1041
1042       <varlistentry>
1043         <term><varname>emergency</varname></term>
1044         <term><varname>rd.emergency</varname></term>
1045         <term><varname>-b</varname></term>
1046
1047         <listitem><para>Boot into emergency mode. This is equivalent
1048         to <varname>systemd.unit=emergency.target</varname> or
1049         <varname>rd.systemd.unit=emergency.target</varname>, respectively, and
1050         provided for compatibility reasons and to be easier to type.</para>
1051
1052         <xi:include href="version-info.xml" xpointer="v186"/></listitem>
1053       </varlistentry>
1054
1055       <varlistentry>
1056         <term><varname>rescue</varname></term>
1057         <term><varname>rd.rescue</varname></term>
1058         <term><varname>single</varname></term>
1059         <term><varname>s</varname></term>
1060         <term><varname>S</varname></term>
1061         <term><varname>1</varname></term>
1062
1063         <listitem><para>Boot into rescue mode. This is equivalent to
1064         <varname>systemd.unit=rescue.target</varname> or
1065         <varname>rd.systemd.unit=rescue.target</varname>, respectively, and
1066         provided for compatibility reasons and to be easier to type.</para>
1067
1068         <xi:include href="version-info.xml" xpointer="v186"/></listitem>
1069       </varlistentry>
1070
1071       <varlistentry>
1072         <term><varname>2</varname></term>
1073         <term><varname>3</varname></term>
1074         <term><varname>4</varname></term>
1075         <term><varname>5</varname></term>
1076
1077         <listitem><para>Boot into the specified legacy SysV runlevel.
1078         These are equivalent to
1079         <varname>systemd.unit=runlevel2.target</varname>,
1080         <varname>systemd.unit=runlevel3.target</varname>,
1081         <varname>systemd.unit=runlevel4.target</varname>, and
1082         <varname>systemd.unit=runlevel5.target</varname>,
1083         respectively, and provided for compatibility reasons and to be
1084         easier to type.</para>
1085
1086         <xi:include href="version-info.xml" xpointer="v186"/></listitem>
1087       </varlistentry>
1088
1089       <varlistentry>
1090         <term><varname>locale.LANG=</varname></term>
1091         <term><varname>locale.LANGUAGE=</varname></term>
1092         <term><varname>locale.LC_CTYPE=</varname></term>
1093         <term><varname>locale.LC_NUMERIC=</varname></term>
1094         <term><varname>locale.LC_TIME=</varname></term>
1095         <term><varname>locale.LC_COLLATE=</varname></term>
1096         <term><varname>locale.LC_MONETARY=</varname></term>
1097         <term><varname>locale.LC_MESSAGES=</varname></term>
1098         <term><varname>locale.LC_PAPER=</varname></term>
1099         <term><varname>locale.LC_NAME=</varname></term>
1100         <term><varname>locale.LC_ADDRESS=</varname></term>
1101         <term><varname>locale.LC_TELEPHONE=</varname></term>
1102         <term><varname>locale.LC_MEASUREMENT=</varname></term>
1103         <term><varname>locale.LC_IDENTIFICATION=</varname></term>
1104
1105         <listitem><para>Set the system locale to use. This overrides
1106         the settings in <filename>/etc/locale.conf</filename>. For
1107         more information, see
1108         <citerefentry project='man-pages'><refentrytitle>locale.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
1109         and
1110         <citerefentry project='man-pages'><refentrytitle>locale</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
1111         </para>
1112
1113         <xi:include href="version-info.xml" xpointer="v186"/></listitem>
1114       </varlistentry>
1115     </variablelist>
1116
1117     <para>For other kernel command line parameters understood by
1118     components of the core OS, please refer to
1119     <citerefentry><refentrytitle>kernel-command-line</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
1120   </refsect1>
1121
1122   <refsect1>
1123     <title>System Credentials</title>
1124
1125     <para>During initialization the service manager will import credentials from various sources into the
1126     system's set of credentials, which can then be propagated into services and consumed by
1127     generators:</para>
1128
1129     <itemizedlist>
1130       <listitem><para>When the service manager first initializes it will read system credentials from SMBIOS
1131       Type 11 vendor strings
1132       <varname>io.systemd.credential:<replaceable>name</replaceable>=<replaceable>value</replaceable></varname>,
1133       and
1134       <varname>io.systemd.credential.binary:<replaceable>name</replaceable>=<replaceable>value</replaceable></varname>.</para></listitem>
1135
1136       <listitem><para>At the same time it will import credentials from QEMU <literal>fw_cfg</literal>. (Note
1137       that the SMBIOS mechanism is generally preferred, because it is faster and generic.)</para></listitem>
1138
1139       <listitem><para>Credentials may be passed via the kernel command line, using the
1140       <varname>systemd.set-credential=</varname> parameter, see above.</para></listitem>
1141
1142       <listitem><para>Credentials may be passed from the UEFI environment via
1143       <citerefentry><refentrytitle>systemd-stub</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para></listitem>
1144
1145       <listitem><para>When the service manager is invoked during the initrd → host transition it will import
1146       all files in <filename>/run/credentials/@initrd/</filename> as system credentials.</para></listitem>
1147     </itemizedlist>
1148
1149     <para>Invoke
1150     <citerefentry><refentrytitle>systemd-creds</refentrytitle><manvolnum>1</manvolnum></citerefentry> as
1151     follows to see the list of credentials passed into the system:</para>
1152
1153     <programlisting># systemd-creds --system list</programlisting>
1154
1155     <para>For further information see <ulink url="https://systemd.io/CREDENTIALS">System and Service
1156     Credentials</ulink> documentation.</para>
1157
1158     <para>The service manager when run as PID 1 consumes the following system credentials:</para>
1159
1160     <variablelist class='system-credentials'>
1161       <varlistentry>
1162         <term><varname>vmm.notify_socket</varname></term>
1163         <listitem>
1164           <para>Contains a <constant>AF_VSOCK</constant> or <constant>AF_UNIX</constant> address where to
1165           send a <constant>READY=1</constant> notification message when the service manager has completed
1166           booting. See
1167           <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry> and
1168           the next section for more information. Note that in case the hypervisor does not support
1169           <constant>SOCK_DGRAM</constant> over <constant>AF_VSOCK</constant>,
1170           <constant>SOCK_SEQPACKET</constant> will be tried instead. The credential payload for
1171           <constant>AF_VSOCK</constant> should be a string in the form
1172           <literal>vsock:CID:PORT</literal>. <literal>vsock-stream</literal>, <literal>vsock-dgram</literal>
1173           and <literal>vsock-seqpacket</literal> can be used instead of <literal>vsock</literal> to force
1174           usage of the corresponding socket type.</para>
1175
1176           <para>This feature is useful for machine managers or other processes on the host to receive a
1177           notification via VSOCK when a virtual machine has finished booting.</para>
1178
1179           <xi:include href="version-info.xml" xpointer="v254"/>
1180         </listitem>
1181       </varlistentry>
1182
1183       <varlistentry>
1184         <term><varname>system.machine_id</varname></term>
1185         <listitem>
1186           <para>Takes a 128bit hexadecimal ID to initialize <filename>/etc/machine-id</filename> from, if the
1187           file is not set up yet. See
1188           <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
1189           details.</para>
1190
1191         <xi:include href="version-info.xml" xpointer="v254"/>
1192         </listitem>
1193       </varlistentry>
1194     </variablelist>
1195
1196     <para>For a list of system credentials various other components of systemd consume, see
1197     <citerefentry><refentrytitle>systemd.system-credentials</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
1198   </refsect1>
1199
1200   <refsect1>
1201     <title>Readiness Protocol</title>
1202
1203     <para>The service manager implements a readiness notification protocol both between the manager and its
1204     services (i.e. down the stack), and between the manager and a potential supervisor further up the stack
1205     (the latter could be a machine or container manager, or in case of a per-user service manager the system
1206     service manager instance). The basic protocol (and the suggested API for it) is described in
1207     <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para>
1208
1209     <para>The notification socket the service manager (including PID 1) uses for reporting readiness to its
1210     own supervisor is set via the usual <varname>$NOTIFY_SOCKET</varname> environment variable (see
1211     above). Since this is directly settable only for container managers and for the per-user instance of the
1212     service manager, an additional mechanism to configure this is available, in particular intended for use
1213     in VM environments: the <varname>vmm.notify_socket</varname> system credential (see above) may be set to
1214     a suitable socket (typically an <constant>AF_VSOCK</constant> one) via SMBIOS Type 11 vendor strings. For
1215     details see above.</para>
1216
1217     <para>The notification protocol from the service manager up the stack towards a supervisor supports a
1218     number of extension fields that allow a supervisor to learn about specific properties of the system and
1219     track its boot progress. Specifically the following fields are sent:</para>
1220
1221     <itemizedlist>
1222       <listitem><para>An <varname>X_SYSTEMD_HOSTNAME=…</varname> message will be sent out once the initial
1223       hostname for the system has been determined. Note that during later runtime the hostname might be
1224       changed again programmatically, and (currently) no further notifications are sent out in that case.</para>
1225
1226       <xi:include href="version-info.xml" xpointer="v256"/></listitem>
1227
1228       <listitem><para>An <varname>X_SYSTEMD_MACHINE_ID=…</varname> message will be sent out once the machine
1229       ID of the system has been determined. See
1230       <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
1231       details.</para>
1232
1233       <xi:include href="version-info.xml" xpointer="v256"/></listitem>
1234
1235       <listitem><para>An <varname>X_SYSTEMD_SIGNALS_LEVEL=…</varname> message will be sent out once the
1236       service manager installed the various UNIX process signal handlers described above. The field's value
1237       is an unsigned integer formatted as decimal string, and indicates the supported UNIX process signal
1238       feature level of the service manager. Currently, only a single feature level is defined:</para>
1239
1240       <itemizedlist>
1241         <listitem><para><varname>X_SYSTEMD_SIGNALS_LEVEL=2</varname> covers the various UNIX process signals
1242         documented above – which are a superset of those supported by the historical SysV init
1243         system.</para></listitem>
1244       </itemizedlist>
1245
1246       <para>Signals sent to PID 1 before this message is sent might not be handled correctly yet. A consumer
1247       of these messages should parse the value as an unsigned integer indication the level of support. For
1248       now only the mentioned level 2 is defined, but later on additional levels might be defined with higher
1249       integers, that will implement a superset of the currently defined behaviour.</para>
1250
1251       <xi:include href="version-info.xml" xpointer="v256"/></listitem>
1252
1253       <listitem><para><varname>X_SYSTEMD_UNIT_ACTIVE=…</varname> and
1254       <varname>X_SYSTEMD_UNIT_INACTIVE=…</varname> messages will be sent out for each target unit as it
1255       becomes active or stops being active. This is useful to track boot progress and functionality. For
1256       example, once the <filename>ssh-access.target</filename> unit is reported started SSH access is
1257       typically available, see
1258       <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
1259       details.</para>
1260
1261       <xi:include href="version-info.xml" xpointer="v256"/></listitem>
1262
1263       <listitem><para>An <varname>X_SYSTEMD_SHUTDOWN=…</varname> message will be sent out very shortly before
1264       the system shuts down. The value is one of the strings <literal>reboot</literal>,
1265       <literal>halt</literal>, <literal>poweroff</literal>, <literal>kexec</literal> and indicates which kind
1266       of shutdown is being executed.</para>
1267
1268       <xi:include href="version-info.xml" xpointer="v256"/></listitem>
1269
1270       <listitem><para>An <varname>X_SYSTEMD_REBOOT_PARAMETER=…</varname> message will also be sent out very
1271       shortly before the system shuts down. Its value is the reboot argument as configured with
1272       <command>systemctl --reboot-argument=…</command>.</para>
1273
1274       <xi:include href="version-info.xml" xpointer="v256"/></listitem>
1275     </itemizedlist>
1276
1277     <para>Note that these extension fields are sent in addition to the regular <literal>READY=1</literal> and
1278     <literal>RELOADING=1</literal> notifications.</para>
1279   </refsect1>
1280
1281   <refsect1>
1282     <title>Options</title>
1283
1284     <para><command>systemd</command> is only very rarely invoked directly, since it is started early and is
1285     already running by the time users may interact with it. Normally, tools like
1286     <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> are used to
1287     give commands to the manager. Since <command>systemd</command> is usually not invoked directly, the
1288     options listed below are mostly useful for debugging and special purposes.</para>
1289
1290     <refsect2>
1291       <title>Introspection and debugging options</title>
1292
1293       <para>Those options are used for testing and introspection, and <command>systemd</command> may
1294       be invoked with them at any time:</para>
1295
1296       <variablelist>
1297         <varlistentry>
1298           <term><option>--dump-configuration-items</option></term>
1299
1300           <listitem><para>Dump understood unit configuration items. This outputs a terse but complete list of
1301           configuration items understood in unit definition files.</para></listitem>
1302         </varlistentry>
1303
1304         <varlistentry>
1305           <term><option>--dump-bus-properties</option></term>
1306
1307           <listitem><para>Dump exposed bus properties. This outputs a terse but complete list of properties
1308           exposed on D-Bus.</para>
1309
1310           <xi:include href="version-info.xml" xpointer="v239"/></listitem>
1311         </varlistentry>
1312
1313         <varlistentry>
1314           <term><option>--test</option></term>
1315
1316           <listitem><para>Determine the initial start-up transaction (i.e. the list of jobs enqueued at
1317           start-up), dump it and exit — without actually executing any of the determined jobs. This option is
1318           useful for debugging only. Note that during regular service manager start-up additional units not
1319           shown by this operation may be started, because hardware, socket, bus or other kinds of activation
1320           might add additional jobs as the transaction is executed. Use <option>--system</option> to request
1321           the initial transaction of the system service manager (this is also the implied default), combine
1322           with <option>--user</option> to request the initial transaction of the per-user service manager
1323           instead.</para></listitem>
1324         </varlistentry>
1325
1326         <varlistentry>
1327           <term><option>--system</option></term>
1328           <term><option>--user</option></term>
1329
1330           <listitem><para>When used in conjunction with <option>--test</option>, selects whether to calculate
1331           the initial transaction for the system instance or for a per-user instance. These options have no
1332           effect when invoked without <option>--test</option>, as during regular
1333           (i.e. non-<option>--test</option>) invocations the service manager will automatically detect
1334           whether it shall operate in system or per-user mode, by checking whether the PID it is run as is 1
1335           or not. Note that it is not supported booting and maintaining a system with the service manager
1336           running in <option>--system</option> mode but with a PID other than 1.</para></listitem>
1337         </varlistentry>
1338
1339         <xi:include href="standard-options.xml" xpointer="help" />
1340         <xi:include href="standard-options.xml" xpointer="version" />
1341       </variablelist>
1342     </refsect2>
1343
1344     <refsect2>
1345       <title>Options that duplicate kernel command line settings</title>
1346
1347       <para>Those options correspond directly to options listed above in "Kernel Command Line". Both forms
1348       may be used equivalently for the system manager, but it is recommended to use the forms listed above in
1349       this context, because they are properly namespaced. When an option is specified both on the kernel
1350       command line and as a normal command line argument, the latter has higher precedence.</para>
1351
1352       <para>When <command>systemd</command> is used as a user manager, the kernel command line is ignored and
1353       only the options described below are understood. Nevertheless, <command>systemd</command> is usually
1354       started in this mode through the
1355       <citerefentry><refentrytitle>user@.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>
1356       service, which is shared between all users. It may be more convenient to use configuration files to
1357       modify settings (see
1358       <citerefentry><refentrytitle>systemd-user.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>),
1359       or environment variables. See the "Environment" section above for a discussion of how the environment
1360       block is set.</para>
1361
1362       <variablelist>
1363         <varlistentry>
1364           <term><option>--unit=</option></term>
1365
1366           <listitem><para>Set default unit to activate on startup. If not specified, defaults to
1367           <filename>default.target</filename>. See <varname>systemd.unit=</varname> above.</para></listitem>
1368         </varlistentry>
1369
1370         <varlistentry>
1371           <term><option>--dump-core</option></term>
1372
1373           <listitem><para>Enable core dumping on crash. This switch has no effect when running as user
1374           instance. Same as <varname>systemd.dump_core=</varname> above.</para></listitem>
1375         </varlistentry>
1376
1377         <varlistentry>
1378           <term><option>--crash-vt=<replaceable>VT</replaceable></option></term>
1379
1380           <listitem><para>Switch to a specific virtual console (VT) on crash. This switch has no effect when
1381           running as user instance. Same as <varname>systemd.crash_chvt=</varname> above (but not the
1382           different spelling!).</para>
1383
1384           <xi:include href="version-info.xml" xpointer="v227"/></listitem>
1385         </varlistentry>
1386
1387         <varlistentry>
1388           <term><option>--crash-shell</option></term>
1389
1390           <listitem><para>Run a shell on crash. This switch has no effect when running as user instance. See
1391           <varname>systemd.crash_shell=</varname> above.</para></listitem>
1392         </varlistentry>
1393
1394         <varlistentry>
1395           <term><option>--crash-action=</option></term>
1396
1397           <listitem><para>Specify what to do when the system manager (PID 1) crashes. This switch has no
1398           effect when systemd is running as user instance. See <varname>systemd.crash_action=</varname>
1399           above.</para>
1400
1401           <xi:include href="version-info.xml" xpointer="v256"/></listitem>
1402         </varlistentry>
1403
1404         <varlistentry>
1405           <term><option>--confirm-spawn</option></term>
1406
1407           <listitem><para>Ask for confirmation when spawning processes. This switch has no effect when run as
1408           user instance. See <varname>systemd.confirm_spawn</varname> above.</para></listitem>
1409         </varlistentry>
1410
1411         <varlistentry>
1412           <term><option>--show-status</option></term>
1413
1414           <listitem><para>Show terse unit status information on the console during boot-up and shutdown. See
1415           <varname>systemd.show_status</varname> above.</para>
1416
1417           <xi:include href="version-info.xml" xpointer="v244"/></listitem>
1418         </varlistentry>
1419
1420         <varlistentry>
1421           <term><option>--log-color</option></term>
1422
1423           <listitem><para>Highlight important log messages. See <varname>systemd.log_color</varname> above.
1424           </para>
1425
1426           <xi:include href="version-info.xml" xpointer="v244"/></listitem>
1427         </varlistentry>
1428
1429         <varlistentry>
1430           <term><option>--log-level=</option></term>
1431
1432           <listitem><para>Set log level. See <varname>systemd.log_level</varname> above.</para></listitem>
1433         </varlistentry>
1434
1435         <varlistentry>
1436           <term><option>--log-location</option></term>
1437
1438           <listitem><para>Include code location in log messages. See <varname>systemd.log_location</varname>
1439           above.</para>
1440
1441           <xi:include href="version-info.xml" xpointer="v244"/></listitem>
1442         </varlistentry>
1443
1444         <varlistentry>
1445           <term><option>--log-target=</option></term>
1446
1447           <listitem><para>Set log target. See <varname>systemd.log_target</varname> above.</para></listitem>
1448         </varlistentry>
1449
1450         <varlistentry>
1451           <term><option>--log-time=</option></term>
1452
1453           <listitem><para>Prefix console messages with timestamp. See <varname>systemd.log_time</varname> above.
1454           </para>
1455
1456           <xi:include href="version-info.xml" xpointer="v246"/></listitem>
1457         </varlistentry>
1458
1459         <varlistentry>
1460           <term><option>--machine-id=</option></term>
1461
1462           <listitem><para>Override the machine-id set on the hard drive. See
1463           <varname>systemd.machine_id=</varname> above.</para>
1464
1465           <xi:include href="version-info.xml" xpointer="v229"/></listitem>
1466         </varlistentry>
1467
1468         <varlistentry>
1469           <term><option>--service-watchdogs</option></term>
1470
1471           <listitem><para>Globally enable/disable all service watchdog timeouts and emergency actions. See
1472           <varname>systemd.service_watchdogs</varname> above.</para>
1473
1474           <xi:include href="version-info.xml" xpointer="v237"/></listitem>
1475         </varlistentry>
1476
1477         <varlistentry>
1478           <term><option>--default-standard-output=</option></term>
1479           <term><option>--default-standard-error=</option></term>
1480
1481           <listitem><para>Sets the default output or error output for all services and sockets,
1482           respectively. See <varname>systemd.default_standard_output=</varname> and
1483           <varname>systemd.default_standard_error=</varname> above.</para></listitem>
1484         </varlistentry>
1485       </variablelist>
1486     </refsect2>
1487   </refsect1>
1488
1489   <refsect1>
1490     <title>Sockets and FIFOs</title>
1491
1492     <variablelist>
1493       <varlistentry>
1494         <term><filename>/run/systemd/notify</filename></term>
1495
1496         <listitem><para>Daemon status notification socket. This is an
1497         <constant>AF_UNIX</constant> datagram socket and is used to
1498         implement the daemon notification logic as implemented by
1499         <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para></listitem>
1500
1501       </varlistentry>
1502
1503       <varlistentry>
1504         <term><filename>/run/systemd/private</filename></term>
1505
1506         <listitem><para>Used internally as communication channel
1507         between
1508         <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
1509         and the systemd process. This is an
1510         <constant>AF_UNIX</constant> stream socket. This interface is
1511         private to systemd and should not be used in external
1512         projects.</para></listitem>
1513       </varlistentry>
1514
1515       <varlistentry>
1516         <term><filename>/dev/initctl</filename></term>
1517
1518         <listitem><para>Limited compatibility support for the SysV
1519         client interface, as implemented by the
1520         <filename>systemd-initctl.service</filename> unit. This is a
1521         named pipe in the file system. This interface is obsolete and
1522         should not be used in new applications.</para></listitem>
1523       </varlistentry>
1524     </variablelist>
1525   </refsect1>
1526
1527   <refsect1>
1528       <title>History</title>
1529
1530       <variablelist>
1531         <varlistentry>
1532           <term>systemd 252</term>
1533           <listitem><para>Kernel command-line arguments <varname>systemd.unified_cgroup_hierarchy</varname>
1534           and <varname>systemd.legacy_systemd_cgroup_controller</varname> were deprecated. Please switch to
1535           the unified cgroup hierarchy.</para>
1536
1537           <xi:include href="version-info.xml" xpointer="v252"/></listitem>
1538         </varlistentry>
1539       </variablelist>
1540   </refsect1>
1541
1542   <refsect1>
1543     <title>See Also</title>
1544     <para><simplelist type="inline">
1545       <member>The <ulink url="https://systemd.io/">systemd Homepage</ulink></member>
1546       <member><citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry></member>
1547       <member><citerefentry project='man-pages'><refentrytitle>locale.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry></member>
1548       <member><citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry></member>
1549       <member><citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry></member>
1550       <member><citerefentry><refentrytitle>systemd-notify</refentrytitle><manvolnum>1</manvolnum></citerefentry></member>
1551       <member><citerefentry><refentrytitle>daemon</refentrytitle><manvolnum>7</manvolnum></citerefentry></member>
1552       <member><citerefentry><refentrytitle>sd-daemon</refentrytitle><manvolnum>3</manvolnum></citerefentry></member>
1553       <member><citerefentry><refentrytitle>org.freedesktop.systemd1</refentrytitle><manvolnum>5</manvolnum></citerefentry></member>
1554       <member><citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry></member>
1555       <member><citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry></member>
1556       <member><citerefentry project='die-net'><refentrytitle>pkg-config</refentrytitle><manvolnum>1</manvolnum></citerefentry></member>
1557       <member><citerefentry><refentrytitle>kernel-command-line</refentrytitle><manvolnum>7</manvolnum></citerefentry></member>
1558       <member><citerefentry project='man-pages'><refentrytitle>bootup</refentrytitle><manvolnum>7</manvolnum></citerefentry></member>
1559       <member><citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry></member>
1560     </simplelist></para>
1561   </refsect1>
1562
1563 </refentry>