]> git.ipfire.org Git - thirdparty/systemd.git/blobdiff - man/systemd.xml
Merge pull request #11580 from yuwata/fix-11579
[thirdparty/systemd.git] / man / systemd.xml
index 08ce99d0ccd5baf133572e117a44f85d6d79db00..5287bdaba89a47a4c1af0f5f88b80cace01d52b3 100644 (file)
@@ -1,24 +1,9 @@
-<?xml version='1.0'?> <!--*- Mode: nxml; nxml-child-indent: 2; indent-tabs-mode: nil -*-->
+<?xml version='1.0'?>
 <!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
   "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
 
 <!--
-  This file is part of systemd.
-
-  Copyright 2010 Lennart Poettering
-
-  systemd is free software; you can redistribute it and/or modify it
-  under the terms of the GNU Lesser General Public License as published by
-  the Free Software Foundation; either version 2.1 of the License, or
-  (at your option) any later version.
-
-  systemd is distributed in the hope that it will be useful, but
-  WITHOUT ANY WARRANTY; without even the implied warranty of
-  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-  Lesser General Public License for more details.
-
-  You should have received a copy of the GNU Lesser General Public License
-  along with systemd; If not, see <http://www.gnu.org/licenses/>.
+  SPDX-License-Identifier: LGPL-2.1+
 -->
 
 <refentry id="systemd"
   <refentryinfo>
     <title>systemd</title>
     <productname>systemd</productname>
-
-    <authorgroup>
-      <author>
-        <contrib>Developer</contrib>
-        <firstname>Lennart</firstname>
-        <surname>Poettering</surname>
-        <email>lennart@poettering.net</email>
-      </author>
-    </authorgroup>
   </refentryinfo>
 
   <refmeta>
 
   <refsynopsisdiv>
     <cmdsynopsis>
-      <command>systemd <arg choice="opt" rep="repeat">OPTIONS</arg></command>
+      <command>/usr/lib/systemd/systemd</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
     </cmdsynopsis>
     <cmdsynopsis>
-      <command>init <arg choice="opt" rep="repeat">OPTIONS</arg> <arg choice="req">COMMAND</arg></command>
+      <command>init</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="req">COMMAND</arg>
     </cmdsynopsis>
   </refsynopsisdiv>
 
         outputs a terse but complete list of configuration items
         understood in unit definition files.</para></listitem>
       </varlistentry>
+      <varlistentry>
+        <term><option>--dump-bus-properties</option></term>
+
+        <listitem><para>Dump exposed bus properties. This outputs
+        a terse but complete list of properties exposed to dbus.
+        </para></listitem>
+      </varlistentry>
       <varlistentry>
         <term><option>--unit=</option></term>
 
         user instance. This setting may also be enabled during boot,
         on the kernel command line via the
         <varname>systemd.crash_vt=</varname> option, see
+        <!-- FIXME: there is no crash_vt command line option? -->
         below.</para></listitem>
       </varlistentry>
 
       <varlistentry>
         <term><option>--show-status=</option></term>
 
-        <listitem><para>Show terse service status information while
-        booting. This switch has no effect when run as user instance.
-        Takes a boolean argument which may be omitted which is
-        interpreted as <option>true</option>.</para></listitem>
+        <listitem><para>Takes a boolean argument or the special value <constant>auto</constant>. If on, terse unit
+        status information is shown on the console during boot-up and shutdown. If off, no such status information is
+        shown. If set to <constant>auto</constant> behavior is similar to off, except that it is automatically switched
+        to on, as soon as the first unit failure or significant boot delay is encountered. This switch has no effect
+        when invoked as user instance. If specified, overrides both the kernel command line setting
+        <varname>systemd.show_status=</varname> (see below) and the configuration file option
+        <option>ShowStatus=</option>, see
+        <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
       </varlistentry>
       <varlistentry>
         <term><option>--log-target=</option></term>
         <option>inherit</option>.</para></listitem>
       </varlistentry>
 
+      <varlistentry>
+        <term><option>--machine-id=</option></term>
+
+        <listitem><para>Override the machine-id set on the hard drive,
+        useful for network booting or for containers. May not be set
+        to all zeros.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--service-watchdogs=</option></term>
+
+        <listitem><para>Globally enable/disable all service watchdog timeouts and emergency
+        actions. This setting may also be specified during boot, on the kernel
+        command line via the <varname>systemd.service_watchdogs=</varname>
+        option, see below. Defaults to enabled.</para></listitem>
+      </varlistentry>
+
       <xi:include href="standard-options.xml" xpointer="help" />
       <xi:include href="standard-options.xml" xpointer="version" />
     </variablelist>
     <title>Concepts</title>
 
     <para>systemd provides a dependency system between various
-    entities called "units" of 12 different types. Units encapsulate
+    entities called "units" of 11 different types. Units encapsulate
     various objects that are relevant for system boot-up and
     maintenance. The majority of units are configured in unit
     configuration files, whose syntax and basic set of options is
     <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
     however some are created automatically from other configuration,
     dynamically from system state or programmatically at runtime.
-    Units may be "active" (meaning started, bound, plugged in, ...,
+    Units may be "active" (meaning started, bound, plugged in, ,
     depending on the unit type, see below), or "inactive" (meaning
-    stopped, unbound, unplugged, ...), as well as in the process of
+    stopped, unbound, unplugged, ), as well as in the process of
     being activated or deactivated, i.e. between the two states (these
     states are called "activating", "deactivating"). A special
     "failed" state is available as well, which is very similar to
     "inactive" and is entered when the service failed in some way
-    (process returned error code on exit, or crashed, or an operation
-    timed out). If this state is entered, the cause will be logged,
-    for later reference. Note that the various unit types may have a
-    number of additional substates, which are mapped to the five
-    generalized unit states described here.</para>
+    (process returned error code on exit, or crashed, an operation
+    timed out, or after too many restarts). If this state is entered,
+    the cause will be logged, for later reference. Note that the
+    various unit types may have a number of additional substates,
+    which are mapped to the five generalized unit states described
+    here.</para>
 
     <para>The following unit types are available:</para>
 
       boot-up. See
       <citerefentry><refentrytitle>systemd.automount</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
 
-      <listitem><para>Snapshot units can be used to temporarily save
-      the state of the set of systemd units, which later may be
-      restored by activating the saved snapshot unit. For more
-      information, see
-      <citerefentry><refentrytitle>systemd.snapshot</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
-
       <listitem><para>Timer units are useful for triggering activation
       of other units based on timers. You may find details in
       <citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
     <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>
     for details about these target units.</para>
 
+    <para>systemd only keeps a minimal set of units loaded into memory. Specifically, the only units that are kept
+    loaded into memory are those for which at least one of the following conditions is true:</para>
+
+    <orderedlist>
+      <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>
+      <listitem><para>It has a job queued for it</para></listitem>
+      <listitem><para>It is a dependency of some sort of at least one other unit that is loaded into memory</para></listitem>
+      <listitem><para>It has some form of resource still allocated (e.g. a service unit that is inactive but for which
+      a process is still lingering that ignored the request to be terminated)</para></listitem>
+      <listitem><para>It has been pinned into memory programmatically by a D-Bus call</para></listitem>
+    </orderedlist>
+
+    <para>systemd will automatically and implicitly load units from disk — if they are not loaded yet — as soon as
+    operations are requested for them. Thus, in many respects, the fact whether a unit is loaded or not is invisible to
+    clients. Use <command>systemctl list-units --all</command> to comprehensively list all units currently loaded. Any
+    unit for which none of the conditions above applies is promptly unloaded. Note that when a unit is unloaded from
+    memory its accounting data is flushed out too. However, this data is generally not lost, as a journal log record
+    is generated declaring the consumed resources whenever a unit shuts down.</para>
+
     <para>Processes systemd spawns are placed in individual Linux
     control groups named after the unit which they belong to in the
     private systemd hierarchy. (see <ulink
-    url="https://www.kernel.org/doc/Documentation/cgroups/cgroups.txt">cgroups.txt</ulink>
+    url="https://www.kernel.org/doc/Documentation/cgroup-v1/cgroups.txt">cgroups.txt</ulink>
     for more information about control groups, or short "cgroups").
     systemd uses this to effectively keep track of processes. Control
     group information is maintained in the kernel, and is accessible
     verify that it makes sense, fixing it if possible, and only
     failing if it really cannot work.</para>
 
-    <para>Systemd contains native implementations of various tasks
+    <para>Note that transactions are generated independently of a unit's
+    state at runtime, hence, for example, if a start job is requested on an
+    already started unit, it will still generate a transaction and wake up any
+    inactive dependencies (and cause propagation of other jobs as per the
+    defined relationships). This is because the enqueued job is at the time of
+    execution compared to the target unit's state and is marked successful and
+    complete when both satisfy. However, this job also pulls in other
+    dependencies due to the defined relationships and thus leads to, in our
+    our example, start jobs for any of those inactive units getting queued as
+    well.</para>
+
+    <para>systemd contains native implementations of various tasks
     that need to be executed as part of the boot process. For example,
     it sets the hostname or configures the loopback network device. It
     also sets up and mounts various API file systems, such as
 
     <para>Note that some but not all interfaces provided
     by systemd are covered by the
-    <ulink url="http://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise">Interface
+    <ulink url="https://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise">Interface
     Stability Promise</ulink>.</para>
 
     <para>Units may be generated dynamically at boot and system
 
     <para>Systems which invoke systemd in a container or initrd
     environment should implement the
-    <ulink url="http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface">Container Interface</ulink> or
-    <ulink url="http://www.freedesktop.org/wiki/Software/systemd/InitrdInterface">initrd Interface</ulink>
+    <ulink url="https://www.freedesktop.org/wiki/Software/systemd/ContainerInterface">Container Interface</ulink> or
+    <ulink url="https://www.freedesktop.org/wiki/Software/systemd/InitrdInterface">initrd Interface</ulink>
     specifications, respectively.</para>
   </refsect1>
 
         <para>systemd user managers will start the
         <filename>exit.target</filename> unit when this signal is
         received. This is mostly equivalent to <command>systemctl
-        --user start exit.target</command>.</para></listitem>
+        --user start exit.target
+        --job-mode=replace-irreversible</command>.</para></listitem>
       </varlistentry>
 
       <varlistentry>
         <term><constant>SIGINT</constant></term>
 
-        <listitem><para>Upon receiving this signal the systemd system
-        manager will start the
-        <filename>ctrl-alt-del.target</filename> unit. This is mostly
-        equivalent to <command>systemctl start
-        ctl-alt-del.target</command>. If this signal is received more
-        than 7 times per 2s, an immediate reboot is triggered.
-        Note that pressing Ctrl-Alt-Del on the console will trigger
-        this signal. Hence, if a reboot is hanging, pressing
-        Ctrl-Alt-Del more than 7 times in 2s is a relatively safe way
-        to trigger an immediate reboot.</para>
+        <listitem><para>Upon receiving this signal the systemd system manager will start the
+        <filename>ctrl-alt-del.target</filename> unit. This is mostly equivalent to
+        <command>systemctl start ctrl-alt-del.target --job-mode=replace-irreversible</command>. If
+        this signal is received more than 7 times per 2s, an immediate reboot is triggered. Note
+        that pressing
+        <keycombo><keycap>Ctrl</keycap><keycap>Alt</keycap><keycap>Del</keycap></keycombo> on the
+        console will trigger this signal. Hence, if a reboot is hanging, pressing
+        <keycombo><keycap>Ctrl</keycap><keycap>Alt</keycap><keycap>Del</keycap></keycombo> more than
+        7 times in 2 seconds is a relatively safe way to trigger an immediate reboot.</para>
 
         <para>systemd user managers treat this signal the same way as
         <constant>SIGTERM</constant>.</para></listitem>
 
         <listitem><para>Enters default mode, starts the
         <filename>default.target</filename> unit. This is mostly
-        equivalent to <command>systemctl start
+        equivalent to <command>systemctl isolate
         default.target</command>.</para></listitem>
       </varlistentry>
 
 
         <listitem><para>Halts the machine, starts the
         <filename>halt.target</filename> unit. This is mostly
-        equivalent to <command>systemctl start
-        halt.target</command>.</para></listitem>
+        equivalent to <command>systemctl start halt.target
+        --job-mode=replace-irreversible</command>.</para>
+        </listitem>
       </varlistentry>
 
       <varlistentry>
 
         <listitem><para>Powers off the machine, starts the
         <filename>poweroff.target</filename> unit. This is mostly
-        equivalent to <command>systemctl start
-        poweroff.target</command>.</para></listitem>
+        equivalent to <command>systemctl start poweroff.target
+        --job-mode=replace-irreversible</command>.</para>
+        </listitem>
       </varlistentry>
 
       <varlistentry>
 
         <listitem><para>Reboots the machine, starts the
         <filename>reboot.target</filename> unit. This is mostly
-        equivalent to <command>systemctl start
-        reboot.target</command>.</para></listitem>
+        equivalent to <command>systemctl start reboot.target
+        --job-mode=replace-irreversible</command>.</para>
+        </listitem>
       </varlistentry>
 
       <varlistentry>
 
         <listitem><para>Reboots the machine via kexec, starts the
         <filename>kexec.target</filename> unit. This is mostly
-        equivalent to <command>systemctl start
-        kexec.target</command>.</para></listitem>
+        equivalent to <command>systemctl start kexec.target
+        --job-mode=replace-irreversible</command>.</para>
+        </listitem>
       </varlistentry>
 
       <varlistentry>
 
       <varlistentry>
         <term><constant>SIGRTMIN+22</constant></term>
+
+        <listitem><para>Sets the service manager's log level to <literal>debug</literal>, in a fashion equivalent to
+        <varname>systemd.log_level=debug</varname> on the kernel command line.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
         <term><constant>SIGRTMIN+23</constant></term>
 
-        <listitem><para>Sets the log level to <literal>debug</literal>
-        (or <literal>info</literal> on
-        <constant>SIGRTMIN+23</constant>), as controlled via
-        <varname>systemd.log_level=debug</varname> (or
-        <varname>systemd.log_level=info</varname> on
-        <constant>SIGRTMIN+23</constant>) on the kernel command
-        line.</para></listitem>
+        <listitem><para>Restores the log level to its configured value. The configured value is derived from – in order
+        of priority – the value specified with <varname>systemd.log-level=</varname> on the kernel command line, or the
+        value specified with <option>LogLevel=</option> in the configuration file, or the built-in default of
+        <literal>info</literal>.</para></listitem>
       </varlistentry>
 
       <varlistentry>
 
       <varlistentry>
         <term><constant>SIGRTMIN+26</constant></term>
+
+        <listitem><para>Restores the log target to its configured value. The configured value is derived from – in
+        order of priority – the value specified with <varname>systemd.log-target=</varname> on the kernel command line,
+        or the value specified with <option>LogTarget=</option> in the configuration file, or the built-in
+        default.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
         <term><constant>SIGRTMIN+27</constant></term>
         <term><constant>SIGRTMIN+28</constant></term>
 
-        <listitem><para>Sets the log level to
-        <literal>journal-or-kmsg</literal> (or
-        <literal>console</literal> on
-        <constant>SIGRTMIN+27</constant>, <literal>kmsg</literal> on
-        <constant>SIGRTMIN+28</constant>), as controlled via
-        <varname>systemd.log_target=journal-or-kmsg</varname> (or
-        <varname>systemd.log_target=console</varname> on
-        <constant>SIGRTMIN+27</constant> or
-        <varname>systemd.log_target=kmsg</varname> on
-        <constant>SIGRTMIN+28</constant>) on the kernel command
-        line.</para></listitem>
+        <listitem><para>Sets the log target to <literal>console</literal> on <constant>SIGRTMIN+27</constant> (or
+        <literal>kmsg</literal> on <constant>SIGRTMIN+28</constant>), in a fashion equivalent to
+        <varname>systemd.log_target=console</varname> (or <varname>systemd.log_target=kmsg</varname> on
+        <constant>SIGRTMIN+28</constant>) on the kernel command line.</para></listitem>
       </varlistentry>
     </variablelist>
   </refsect1>
         script runlevel link farms.</para></listitem>
       </varlistentry>
 
+      <varlistentry>
+        <term><varname>$SYSTEMD_COLORS</varname></term>
+
+        <listitem><para>The value must be a boolean. Controls whether colorized output should be
+        generated. This can be specified to override the decision that <command>systemd</command>
+        makes based on <varname>$TERM</varname> and what the console is connected to.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>$SYSTEMD_URLIFY</varname></term>
+
+        <listitem><para>The value must be a boolean. Controls whether clickable links should be generated in the output
+        for terminal emulators supporting this. This can be specified to override the decision that
+        <command>systemd</command> makes based on <varname>$TERM</varname> and other conditions.</para>
+        </listitem>
+      </varlistentry>
+
       <varlistentry>
         <term><varname>$LISTEN_PID</varname></term>
         <term><varname>$LISTEN_FDS</varname></term>
         <listitem><para>Set by systemd for supervised processes during
         socket-based activation. See
         <citerefentry><refentrytitle>sd_listen_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry>
-        for more information. </para></listitem>
+        for more information.</para></listitem>
       </varlistentry>
 
       <varlistentry>
         <listitem><para>Set by systemd for supervised processes for
         status and start-up completion notification. See
         <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>
-        for more information. </para></listitem>
+        for more information.</para></listitem>
       </varlistentry>
     </variablelist>
+
+    <para>For further environment variables understood by systemd and its various components, see <ulink
+    url="https://systemd.io/ENVIRONMENT">Known Environment Variables</ulink>.</para>
   </refsect1>
 
   <refsect1>
       </varlistentry>
 
       <varlistentry>
-        <term><varname>systemd.dump_core=</varname></term>
+        <term><varname>systemd.dump_core</varname></term>
 
-        <listitem><para>Takes a boolean argument. If
-        <option>yes</option>, the systemd manager (PID 1) dumps core
-        when it crashes.  Otherwise, no core dump is created. Defaults
-        to <option>yes</option>.</para></listitem>
+        <listitem><para>Takes a boolean argument or enables the option if specified
+        without an argument. If enabled, the systemd manager (PID 1) dumps core when
+        it crashes. Otherwise, no core dump is created. Defaults to enabled.</para>
+        </listitem>
       </varlistentry>
 
       <varlistentry>
-        <term><varname>systemd.crash_chvt=</varname></term>
+        <term><varname>systemd.crash_chvt</varname></term>
 
-        <listitem><para>Takes a positive integer, or a boolean
-        argument. If a positive integer (in the range 1–63) is
-        specified, the system manager (PID 1) will activate the specified
-        virtual terminal (VT) when it crashes. Defaults to
-        <constant>no</constant>, meaning that no such switch is
-        attempted. If set to <constant>yes</constant>, the VT the
-        kernel messages are written to is selected.</para></listitem>
+        <listitem><para>Takes a positive integer, or a boolean argument. Can be also
+        specified without an argument, with the same effect as a positive boolean. If
+        a positive integer (in the range 1–63) is specified, the system manager (PID
+        1) will activate the specified virtual terminal (VT) when it
+        crashes. Defaults to disabled, meaning that no such switch is attempted. If
+        set to enabled, the VT the kernel messages are written to is selected.
+        </para></listitem>
       </varlistentry>
 
       <varlistentry>
-        <term><varname>systemd.crash_shell=</varname></term>
+        <term><varname>systemd.crash_shell</varname></term>
 
-        <listitem><para>Takes a boolean argument. If
-        <option>yes</option>, the system manager (PID 1) spawns a
-        shell when it crashes, after a 10s delay. Otherwise, no shell
-        is spawned. Defaults to <option>no</option>, for security
-        reasons, as the shell is not protected by password
+        <listitem><para>Takes a boolean argument or enables the option if specified
+        without an argument. If enabled, the system manager (PID 1) spawns a shell
+        when it crashes, after a 10s delay. Otherwise, no shell is spawned. Defaults
+        to disabled, for security reasons, as the shell is not protected by password
         authentication.</para></listitem>
       </varlistentry>
 
       <varlistentry>
-        <term><varname>systemd.crash_reboot=</varname></term>
+        <term><varname>systemd.crash_reboot</varname></term>
 
-        <listitem><para>Takes a boolean argument. If
-        <option>yes</option>, the system manager (PID 1) will reboot
-        the machine automatically when it crashes, after a 10s delay.
-        Otherwise, the system will hang indefinitely. Defaults to
-        <option>no</option>, in order to avoid a reboot loop. If
-        combined with <varname>systemd.crash_shell=</varname>, the
+        <listitem><para>Takes a boolean argument or enables the option if specified
+        without an argument. If enabled, the system manager (PID 1) will reboot the
+        machine automatically when it crashes, after a 10s delay.  Otherwise, the
+        system will hang indefinitely. Defaults to disabled, in order to avoid a
+        reboot loop. If combined with <varname>systemd.crash_shell</varname>, the
         system is rebooted after the shell exits.</para></listitem>
       </varlistentry>
 
       <varlistentry>
-        <term><varname>systemd.confirm_spawn=</varname></term>
+        <term><varname>systemd.confirm_spawn</varname></term>
 
-        <listitem><para>Takes a boolean argument. If
-        <option>yes</option>, the system manager (PID 1) asks for
-        confirmation when spawning processes. Defaults to
-        <option>no</option>.</para></listitem>
+        <listitem><para>Takes a boolean argument or a path to the virtual console
+        where the confirmation messages should be emitted. Can be also specified
+        without an argument, with the same effect as a positive boolean. If enabled,
+        the system manager (PID 1) asks for confirmation when spawning processes
+        using <option>/dev/console</option>. If a path or a console name (such as
+        <literal>ttyS0</literal>) is provided, the virtual console pointed to by this
+        path or described by the give name will be used instead. Defaults to disabled.
+        </para></listitem>
       </varlistentry>
 
       <varlistentry>
-        <term><varname>systemd.show_status=</varname></term>
+        <term><varname>systemd.service_watchdogs=</varname></term>
+
+        <listitem><para>Takes a boolean argument. If disabled, all service runtime
+        watchdogs (<option>WatchdogSec=</option>) and emergency actions (e.g.
+        <option>OnFailure=</option> or <option>StartLimitAction=</option>) are
+        ignored by the system manager (PID 1); see
+        <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+        Defaults to enabled, i.e. watchdogs and failure actions are processed
+        normally. The hardware watchdog is not affected by this
+        option.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>systemd.show_status</varname></term>
 
         <listitem><para>Takes a boolean argument or the constant
-        <constant>auto</constant>. If <option>yes</option>, the
-        systemd manager (PID 1) shows terse service status updates on
-        the console during bootup.  <constant>auto</constant> behaves
-        like <option>false</option> until a service fails or there is
-        a significant delay in boot.  Defaults to
-        <option>yes</option>, unless <option>quiet</option> is passed
-        as kernel command line option, in which case it defaults to
-        <constant>auto</constant>.</para></listitem>
+        <constant>auto</constant>. Can be also specified without an argument, with
+        the same effect as a positive boolean.  If enabled, the systemd manager (PID
+        1) shows terse service status updates on the console during bootup.
+        <constant>auto</constant> behaves like <option>false</option> until a unit
+        fails or there is a significant delay in boot. Defaults to enabled, unless
+        <option>quiet</option> is passed as kernel command line option, in which case
+        it defaults to <constant>auto</constant>. If specified overrides the system
+        manager configuration file option <option>ShowStatus=</option>, see
+        <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+        However, the process command line option <option>--show-status=</option>
+        takes precedence over both this kernel command line option and the
+        configuration file option.</para></listitem>
       </varlistentry>
 
       <varlistentry>
         <term><varname>systemd.log_target=</varname></term>
         <term><varname>systemd.log_level=</varname></term>
-        <term><varname>systemd.log_color=</varname></term>
         <term><varname>systemd.log_location=</varname></term>
+        <term><varname>systemd.log_color</varname></term>
 
-        <listitem><para>Controls log output, with the same effect as
-        the <varname>$SYSTEMD_LOG_TARGET</varname>,
+        <listitem><para>Controls log output, with the same effect as the
+        <varname>$SYSTEMD_LOG_TARGET</varname>,
         <varname>$SYSTEMD_LOG_LEVEL</varname>,
-        <varname>$SYSTEMD_LOG_COLOR</varname>,
-        <varname>$SYSTEMD_LOG_LOCATION</varname> environment variables
-        described above.</para></listitem>
+        <varname>$SYSTEMD_LOG_LOCATION</varname>,
+        <varname>$SYSTEMD_LOG_COLOR</varname> environment variables described above.
+        <varname>systemd.log_color</varname> can be specified without an argument,
+        with the same effect as a positive boolean.</para></listitem>
       </varlistentry>
 
       <varlistentry>
         than once to set multiple variables.</para></listitem>
       </varlistentry>
 
+      <varlistentry>
+        <term><varname>systemd.machine_id=</varname></term>
+
+        <listitem><para>Takes a 32 character hex value to be
+        used for setting the machine-id. Intended mostly for
+        network booting where the same machine-id is desired
+        for every boot.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>systemd.unified_cgroup_hierarchy</varname></term>
+
+        <listitem><para>When specified without an argument or with a true argument,
+        enables the usage of
+        <ulink url="https://www.kernel.org/doc/Documentation/cgroup-v2.txt">unified cgroup hierarchy</ulink>
+        (a.k.a. cgroups-v2). When specified with a false argument, fall back to
+        hybrid or full legacy cgroup hierarchy.</para>
+
+        <para>If this option is not specified, the default behaviour is determined
+        during compilation (the <option>-Ddefault-hierarchy=</option> meson
+        option). If the kernel does not support unified cgroup hierarchy, the legacy
+        hierarchy will be used even if this option is specified.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>systemd.legacy_systemd_cgroup_controller</varname></term>
+
+        <listitem><para>Takes effect if the full unified cgroup hierarchy is not used
+        (see previous option). When specified without an argument or with a true
+        argument, disables the use of "hybrid" cgroup hierarchy (i.e. a cgroups-v2
+        tree used for systemd, and
+        <ulink url="https://www.kernel.org/doc/Documentation/cgroup-v1/">legacy
+        cgroup hierarchy</ulink>, a.k.a. cgroups-v1, for other controllers), and
+        forces a full "legacy" mode. When specified with a false argument, enables
+        the use of "hybrid" hierarchy.</para>
+
+        <para>If this option is not specified, the default behaviour is determined
+        during compilation (the <option>-Ddefault-hierarchy=</option> meson
+        option). If the kernel does not support unified cgroup hierarchy, the legacy
+        hierarchy will be used  even if this option is specified.</para>
+        </listitem>
+      </varlistentry>
+
       <varlistentry>
         <term><varname>quiet</varname></term>
 
         <listitem><para>Turn off status output at boot, much like
-        <varname>systemd.show_status=false</varname> would. Note that
+        <varname>systemd.show_status=no</varname> would. Note that
         this option is also read by the kernel itself and disables
         kernel log output. Passing this option hence turns off the
         usual output from both the system manager and the kernel.
 
       <varlistentry>
         <term><varname>emergency</varname></term>
+        <term><varname>rd.emergency</varname></term>
         <term><varname>-b</varname></term>
 
         <listitem><para>Boot into emergency mode. This is equivalent
-        to <varname>systemd.unit=emergency.target</varname> and
-        provided for compatibility reasons and to be easier to
-        type.</para></listitem>
+        to <varname>systemd.unit=emergency.target</varname> or
+        <varname>rd.systemd.unit=emergency.target</varname>, respectively, and
+        provided for compatibility reasons and to be easier to type.</para></listitem>
       </varlistentry>
 
       <varlistentry>
         <term><varname>rescue</varname></term>
+        <term><varname>rd.rescue</varname></term>
         <term><varname>single</varname></term>
         <term><varname>s</varname></term>
         <term><varname>S</varname></term>
         <term><varname>1</varname></term>
 
         <listitem><para>Boot into rescue mode. This is equivalent to
-        <varname>systemd.unit=rescue.target</varname> and provided for
-        compatibility reasons and to be easier to
-        type.</para></listitem>
+        <varname>systemd.unit=rescue.target</varname> or
+        <varname>rd.systemd.unit=rescue.target</varname>, respectively, and
+        provided for compatibility reasons and to be easier to type.</para></listitem>
       </varlistentry>
 
       <varlistentry>
   <refsect1>
     <title>See Also</title>
     <para>
-      The <ulink url="http://www.freedesktop.org/wiki/Software/systemd/">systemd Homepage</ulink>,
+      The <ulink url="https://www.freedesktop.org/wiki/Software/systemd/">systemd Homepage</ulink>,
       <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
       <citerefentry project='man-pages'><refentrytitle>locale.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
       <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,