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