Adding upstream version 255.4.upstream/255.4

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

449 files changed, 139636 insertions, 0 deletions

diff --git a/man/.dir-locals.el b/man/.dir-locals.el
new file mode 100644
index 0000000..bd028d1
--- /dev/null
+++ b/man/.dir-locals.el
@@ -0,0 +1,15 @@
+; SPDX-License-Identifier: LGPL-2.1-or-later
+; special .c mode with reduced indentation for man pages
+((c-mode . ((fill-column . 80)
+            (c-basic-offset . 2)
+            (eval . (c-set-offset 'substatement-open 0))
+            (eval . (c-set-offset 'statement-case-open 0))
+            (eval . (c-set-offset 'case-label 0))
+            (eval . (c-set-offset 'arglist-intro '++))
+            (eval . (c-set-offset 'arglist-close 0))))
+ (nxml-mode . ((nxml-child-indent . 2)
+               (fill-column . 109)))
+ (meson-mode . ((meson-indent-basic . 8)))
+ (nil . ((indent-tabs-mode . nil)
+         (tab-width . 8)
+         (fill-column . 79))))
diff --git a/man/50-xdg-data-dirs.sh b/man/50-xdg-data-dirs.sh
new file mode 100755
index 0000000..0a180ff
--- /dev/null
+++ b/man/50-xdg-data-dirs.sh
@@ -0,0 +1,13 @@
+#!/bin/sh
+# SPDX-License-Identifier: MIT-0
+
+# set the default value
+XDG_DATA_DIRS="${XDG_DATA_DIRS:-/usr/local/share/:/usr/share}"
+
+# add a directory if it exists
+if [ -d /opt/foo/share ]; then
+    XDG_DATA_DIRS="/opt/foo/share:${XDG_DATA_DIRS}"
+fi
+
+# write our output
+echo "XDG_DATA_DIRS=${XDG_DATA_DIRS}"
diff --git a/man/90-rearrange-path.py b/man/90-rearrange-path.py
new file mode 100755
index 0000000..5c727e4
--- /dev/null
+++ b/man/90-rearrange-path.py
@@ -0,0 +1,41 @@
+#!/usr/bin/env python3
+# SPDX-License-Identifier: MIT-0
+
+"""
+
+Proof-of-concept systemd environment generator that makes sure that bin dirs
+are always after matching sbin dirs in the path.
+(Changes /sbin:/bin:/foo/bar to /bin:/sbin:/foo/bar.)
+
+This generator shows how to override the configuration possibly created by
+earlier generators. It would be easier to write in bash, but let's have it
+in Python just to prove that we can, and to serve as a template for more
+interesting generators.
+
+"""
+
+import os
+import pathlib
+
+def rearrange_bin_sbin(path):
+    """Make sure any pair of …/bin, …/sbin directories is in this order
+
+    >>> rearrange_bin_sbin('/bin:/sbin:/usr/sbin:/usr/bin')
+    '/bin:/sbin:/usr/bin:/usr/sbin'
+    """
+    items = [pathlib.Path(p) for p in path.split(':')]
+    for i in range(len(items)):
+        if 'sbin' in items[i].parts:
+            ind = items[i].parts.index('sbin')
+            bin = pathlib.Path(*items[i].parts[:ind], 'bin', *items[i].parts[ind+1:])
+            if bin in items[i+1:]:
+                j = i + 1 + items[i+1:].index(bin)
+                items[i], items[j] = items[j], items[i]
+    return ':'.join(p.as_posix() for p in items)
+
+if __name__ == '__main__':
+    path = os.environ['PATH'] # This should be always set.
+                              # If it's not, we'll just crash, which is OK too.
+    new = rearrange_bin_sbin(path)
+    if new != path:
+        print('PATH={}'.format(new))
diff --git a/man/binfmt.d.xml b/man/binfmt.d.xml
new file mode 100644
index 0000000..ab56460
--- /dev/null
+++ b/man/binfmt.d.xml
@@ -0,0 +1,74 @@
+<?xml version="1.0"?>
+<!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+<refentry id="binfmt.d" conditional='ENABLE_BINFMT'
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>binfmt.d</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>binfmt.d</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>binfmt.d</refname>
+    <refpurpose>Configure additional binary formats for
+    executables at boot</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>/etc/binfmt.d/*.conf</filename></para>
+    <para><filename>/run/binfmt.d/*.conf</filename></para>
+    <para><filename>/usr/lib/binfmt.d/*.conf</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>At boot,
+    <citerefentry><refentrytitle>systemd-binfmt.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    reads configuration files from the above directories to register
+    in the kernel additional binary formats for executables.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Configuration Format</title>
+
+    <para>Each file contains a list of binfmt_misc kernel binary format rules. Consult the kernel's <ulink
+    url="https://docs.kernel.org/admin-guide/binfmt-misc.html">Kernel Support for
+    miscellaneous Binary Formats (binfmt_misc)</ulink> documentation file for more information on
+    registration of additional binary formats and how to write rules.</para>
+
+    <para>Empty lines and lines beginning with <literal>;</literal> and <literal>#</literal> are ignored.
+    Note that this means you may not use those symbols as the delimiter in binary format rules.</para>
+  </refsect1>
+
+  <xi:include href="standard-conf.xml" xpointer="confd" />
+
+  <refsect1>
+    <title>Example</title>
+    <example>
+      <title>/etc/binfmt.d/wine.conf example:</title>
+
+      <programlisting># Start WINE on Windows executables
+:DOSWin:M::MZ::/usr/bin/wine:</programlisting>
+    </example>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-binfmt.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-delta</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry project='die-net'><refentrytitle>wine</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/bootctl.xml b/man/bootctl.xml
new file mode 100644
index 0000000..68e4774
--- /dev/null
+++ b/man/bootctl.xml
@@ -0,0 +1,648 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="bootctl" conditional='ENABLE_BOOTLOADER'
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+  <refentryinfo>
+    <title>bootctl</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>bootctl</refentrytitle>
+    <manvolnum>1</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>bootctl</refname>
+    <refpurpose>Control EFI firmware boot settings and manage boot loader</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <cmdsynopsis>
+      <command>bootctl</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="req">COMMAND</arg>
+    </cmdsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>bootctl</command> can check the EFI firmware and boot loader status, list and manage
+    available boot loaders and boot loader entries, and install, update, or remove the
+    <citerefentry><refentrytitle>systemd-boot</refentrytitle><manvolnum>7</manvolnum></citerefentry> boot
+    loader on the current system.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Generic EFI Firmware/Boot Loader Commands</title>
+
+    <para>These commands are available on any EFI system, regardless of the boot loader used.</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><option>status</option></term>
+
+        <listitem><para>Shows brief information about the system firmware, the boot loader that was used to
+        boot the system, the boot loaders currently available in the ESP, the boot loaders listed in the
+        firmware's list of boot loaders and the current default boot loader entry. If no command is
+        specified, this is the implied default.</para>
+
+        <para>See the example below for details of the output.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>reboot-to-firmware</option> <optional><replaceable>BOOL</replaceable></optional></term>
+
+        <listitem><para>Query or set the "Reboot-Into-Firmware-Setup" flag of the EFI firmware. Takes a
+        boolean argument which controls whether to show the firmware setup on next system reboot. If the
+        argument is omitted shows the current status of the flag, or whether the flag is supported. This
+        controls the same flag as <command>systemctl reboot --firmware-setup</command>, but is more low-level
+        and allows setting the flag independently from actually requesting a reboot.</para>
+
+        <para>Hint: use <command>systemctl reboot --firmware-setup</command> to reboot into firmware setup
+        once. See
+        <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+        for details.</para>
+
+        <xi:include href="version-info.xml" xpointer="v251"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Boot Loader Specification Commands</title>
+
+    <para>These commands are available for all boot loaders that
+    implement the <ulink
+    url="https://uapi-group.org/specifications/specs/boot_loader_specification">Boot
+    Loader Specification</ulink>, such as
+    <command>systemd-boot</command>.</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><option>list</option></term>
+
+        <listitem><para>Shows all available boot loader entries implementing the <ulink
+        url="https://uapi-group.org/specifications/specs/boot_loader_specification">Boot Loader Specification</ulink>, as well as any
+        other entries discovered or automatically generated by a boot loader implementing the <ulink
+        url="https://systemd.io/BOOT_LOADER_INTERFACE">Boot Loader Interface</ulink>.
+        JSON output may be requested with <option>--json=</option>.</para>
+
+        <para>See the example below for details of the output.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>unlink</option> <replaceable>ID</replaceable></term>
+
+        <listitem><para>Removes a boot loader entry including the files it refers to. Takes a single boot
+        loader entry ID string or a glob pattern as argument. Referenced files such as kernel or initrd are
+        only removed if no other entry refers to them.</para>
+
+        <xi:include href="version-info.xml" xpointer="v253"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>cleanup</option></term>
+
+        <listitem><para>Removes files from the ESP and XBOOTLDR partitions that belong to the entry token but
+        are not referenced in any boot loader entries.</para>
+
+        <xi:include href="version-info.xml" xpointer="v253"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Boot Loader Interface Commands</title>
+
+    <para>These commands are available for all boot loaders that implement the <ulink
+    url="https://uapi-group.org/specifications/specs/boot_loader_specification">Boot Loader Specification</ulink> and the <ulink
+    url="https://systemd.io/BOOT_LOADER_INTERFACE">Boot Loader Interface</ulink>, such as
+    <command>systemd-boot</command>.</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><option>set-default</option> <replaceable>ID</replaceable></term>
+        <term><option>set-oneshot</option> <replaceable>ID</replaceable></term>
+
+        <listitem><para>Sets the default boot loader entry. Takes a single boot loader entry ID string or a glob
+        pattern as argument. The <option>set-oneshot</option> command will set the default entry only for the next boot,
+        the <option>set-default</option> will set it persistently for all future boots.</para>
+
+        <para><command>bootctl list</command> can be used to list available boot loader entries and their
+        IDs.</para>
+
+        <para>In addition, the boot loader entry ID may be specified as one of: <option>@default</option>,
+        <option>@oneshot</option> or <option>@current</option>, which correspond to the current default boot loader
+        entry for all future boots, the current default boot loader entry for the next boot, and the currently booted
+        boot loader entry. These special IDs are resolved to the current values of the EFI variables
+        <varname>LoaderEntryDefault</varname>, <varname>LoaderEntryOneShot</varname> and <varname>LoaderEntrySelected</varname>,
+        see <ulink url="https://uapi-group.org/specifications/specs/boot_loader_specification">Boot Loader Specification</ulink> for details.
+        These special IDs are primarily useful as a quick way to persistently make the currently booted boot loader
+        entry the default choice, or to upgrade the default boot loader entry for the next boot to the default boot
+        loader entry for all future boots, but may be used for other operations too.</para>
+
+        <para>If set to <option>@saved</option> the chosen entry will be saved as an EFI variable
+        on every boot and automatically selected the next time the boot loader starts.</para>
+
+        <para>When an empty string ("") is specified as the ID, then the corresponding EFI variable will be
+        unset.</para>
+
+        <para>Hint: use <command>systemctl reboot --boot-loader-entry=<replaceable>ID</replaceable></command>
+        to reboot into a specific boot entry and
+        <command>systemctl reboot --boot-loader-menu=<replaceable>timeout</replaceable></command>
+        to reboot into the boot loader menu once. See
+        <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+        for details.</para>
+
+        <xi:include href="version-info.xml" xpointer="v240"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>set-timeout</option> <replaceable>TIMEOUT</replaceable></term>
+        <term><option>set-timeout-oneshot</option> <replaceable>TIMEOUT</replaceable></term>
+
+        <listitem><para>Sets the boot loader menu timeout in seconds. The <option>set-timeout-oneshot</option>
+        command will set the timeout only for the next boot. See
+        <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+        for details about the syntax of time spans.</para>
+
+        <para>If this is set to <option>menu-disabled</option> or <option>menu-hidden</option> or
+        <option>0</option>, no menu is shown and the default entry will be booted immediately, while
+        setting this to <option>menu-force</option> disables the timeout while always showing the menu.
+        When an empty string ("") is specified the bootloader will revert to its default menu timeout.</para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title><command>systemd-boot</command> Commands</title>
+
+    <para>These commands manage the <command>systemd-boot</command> EFI boot loader, and do not work in
+    conjunction with other boot loaders.</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><option>install</option></term>
+
+        <listitem><para>Installs <command>systemd-boot</command> into the EFI system partition. A copy of
+        <command>systemd-boot</command> will be stored as the EFI default/fallback loader at
+        <filename><replaceable>ESP</replaceable>/EFI/BOOT/BOOT*.EFI</filename>. The boot loader is then added
+        to the top of the firmware's boot loader list.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>update</option></term>
+
+        <listitem><para>Updates all installed versions of
+        <citerefentry><refentrytitle>systemd-boot</refentrytitle><manvolnum>7</manvolnum></citerefentry>, if the
+        available version is newer than the version installed in the EFI system partition. This also includes the EFI
+        default/fallback loader at <filename><replaceable>ESP</replaceable>/EFI/BOOT/BOOT*.EFI</filename>. The boot
+        loader is then added to end of the firmware's boot loader list if missing.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>remove</option></term>
+
+        <listitem><para>Removes all installed versions of <command>systemd-boot</command> from the EFI system partition
+        and the firmware's boot loader list.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>is-installed</option></term>
+
+        <listitem><para>Checks whether <command>systemd-boot</command> is installed in the ESP. Note that a
+        single ESP might host multiple boot loaders; this hence checks whether
+        <command>systemd-boot</command> is one (of possibly many) installed boot loaders — and neither
+        whether it is the default nor whether it is registered in any EFI variables.</para>
+
+        <xi:include href="version-info.xml" xpointer="v243"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>random-seed</option></term>
+
+        <listitem><para>Generates a random seed and stores it in the EFI System Partition (ESP), for use by
+        the <command>systemd-boot</command> boot loader. If a random seed already exists in the ESP it is
+        refreshed. Also generates a random 'system token' and stores it persistently as an EFI variable, if
+        one has not been set before. If the boot loader finds the random seed in the ESP and the system token
+        in the EFI variable it will derive a random seed to pass to the OS and a new seed to store in the ESP
+        from the combination of both. The random seed passed to the OS is credited to the kernel's entropy
+        pool by the system manager during early boot, and permits userspace to boot up with an entropy pool
+        fully initialized very early on. Also see
+        <citerefentry><refentrytitle>systemd-boot-random-seed.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
+
+        <para>See <ulink url="https://systemd.io/RANDOM_SEEDS">Random Seeds</ulink> for further
+        information.</para>
+
+        <xi:include href="version-info.xml" xpointer="v243"/></listitem>
+      </varlistentry>
+
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Kernel Image Commands</title>
+
+    <variablelist>
+      <varlistentry>
+        <term><option>kernel-identify</option> <replaceable>kernel</replaceable></term>
+
+        <listitem><para>Takes a kernel image as argument. Checks what kind of kernel the image is. Returns
+        one of <literal>uki</literal>, <literal>pe</literal>, and <literal>unknown</literal>.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v253"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>kernel-inspect</option> <replaceable>kernel</replaceable></term>
+
+        <listitem><para>Takes a kernel image as argument. Prints details about the image.</para>
+
+        <xi:include href="version-info.xml" xpointer="v253"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+    <para>The following options are understood:</para>
+
+    <variablelist>
+      <xi:include href="standard-options.xml" xpointer="esp-path"/>
+      <xi:include href="standard-options.xml" xpointer="boot-path"/>
+
+      <varlistentry>
+        <term><option>--root=<replaceable>root</replaceable></option></term>
+        <listitem><para>Takes a directory path as an argument. All
+        paths will be prefixed with the given alternate
+        <replaceable>root</replaceable> path, including config search
+        paths. </para>
+
+        <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--image=<replaceable>image</replaceable></option></term>
+
+        <listitem><para>Takes a path to a disk image file or block device node. If specified, all operations
+        are applied to file system in the indicated disk image. This option is similar to
+        <option>--root=</option>, but operates on file systems stored in disk images or block devices. The
+        disk image should either contain just a file system or a set of file systems within a GPT partition
+        table, following the <ulink url="https://uapi-group.org/specifications/specs/discoverable_partitions_specification">Discoverable Partitions
+        Specification</ulink>. For further information on supported disk images, see
+        <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s
+        switch of the same name.</para>
+
+        <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+      </varlistentry>
+
+      <xi:include href="standard-options.xml" xpointer="image-policy-open" />
+
+      <varlistentry>
+        <term><option>--install-source=</option></term>
+        <listitem><para>When installing binaries with <option>--root=</option> or
+        <option>--image=</option>, selects where to source them from. Takes one of <literal>auto</literal>
+        (the default), <literal>image</literal> or <literal>host</literal>. With <literal>auto</literal>
+        binaries will be picked from the specified directory or image, and if not found they will be picked
+        from the host. With <literal>image</literal> or <literal>host</literal> no fallback search will be
+        performed if the binaries are not found in the selected source.</para>
+
+        <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-p</option></term>
+        <term><option>--print-esp-path</option></term>
+        <listitem><para>This option modifies the behaviour of <command>status</command>. Only prints the path
+        to the EFI System Partition (ESP) to standard output and exits.</para>
+
+        <xi:include href="version-info.xml" xpointer="v236"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-x</option></term>
+        <term><option>--print-boot-path</option></term>
+        <listitem><para>This option modifies the behaviour of <command>status</command>. Only prints the path
+        to the Extended Boot Loader partition if it exists, and the path to the ESP otherwise to standard
+        output and exit. This command is useful to determine where to place boot loader entries, as they are
+        preferably placed in the Extended Boot Loader partition if it exists and in the ESP otherwise.</para>
+
+        <para>Boot Loader Specification Type #1 entries should generally be placed in the directory
+        <literal>$(bootctl -x)/loader/entries/</literal>. Existence of that directory may also be used as
+        indication that boot loader entry support is available on the system. Similarly, Boot Loader
+        Specification Type #2 entries should be placed in the directory <literal>$(bootctl
+        -x)/EFI/Linux/</literal>.</para>
+
+        <para>Note that this option (similarly to the <option>--print-boot-path</option> option mentioned
+        above), is available independently from the boot loader used, i.e. also without
+        <command>systemd-boot</command> being installed.</para>
+
+        <xi:include href="version-info.xml" xpointer="v242"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-R</option></term>
+        <term><option>--print-root-device</option></term>
+
+        <listitem><para>Print the path to the block device node backing the root file system of the local
+        OS. This prints a path such as <filename>/dev/nvme0n1p5</filename>. If the root file system is backed
+        by dm-crypt/LUKS or dm-verity the underlying block device is returned. If the root file system is
+        backed by multiple block devices (as supported by btrfs) the operation will fail. If the switch is
+        specified twice (i.e. <option>-RR</option>) and the discovered block device is a partition device the
+        "whole" block device it belongs to is determined and printed
+        (e.g. <filename>/dev/nvme0n1</filename>). If the root file system is <literal>tmpfs</literal> (or a
+        similar in-memory file system), the block device backing <filename>/usr/</filename> is returned if
+        applicable. If the root file system is a network file system (e.g. NFS, CIFS) the operation will
+        fail.</para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--no-variables</option></term>
+        <listitem><para>Do not touch the firmware's boot loader list stored in EFI variables.</para>
+
+        <xi:include href="version-info.xml" xpointer="v220"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--graceful</option></term>
+        <listitem><para>Ignore failure when the EFI System Partition cannot be found, when EFI variables
+        cannot be written, or a different or newer boot loader is already installed. Currently only applies
+        to <command>is-installed</command>, <command>update</command>, and <command>random-seed</command>
+        verbs.</para>
+
+        <xi:include href="version-info.xml" xpointer="v244"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-q</option></term>
+        <term><option>--quiet</option></term>
+
+        <listitem><para>Suppress printing of the results of various commands and also the hints about ESP
+        being unavailable.</para>
+
+        <xi:include href="version-info.xml" xpointer="v251"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--make-entry-directory=yes|no</option></term>
+        <listitem><para>Controls creation and deletion of the <ulink
+        url="https://uapi-group.org/specifications/specs/boot_loader_specification">Boot Loader Specification</ulink> Type #1 entry
+        directory on the file system containing resources such as kernel and initrd images during
+        <option>install</option> and <option>remove</option>, respectively. The directory is named after the
+        entry token, as specified with <option>--entry-token=</option> parameter described below, and is
+        placed immediately below the <varname>$BOOT</varname> root directory (i.e. beneath the file system
+        returned by the <option>--print-boot-path</option> option, see above). Defaults to
+        <literal>no</literal>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v251"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--entry-token=</option></term>
+
+        <listitem><para>Controls how to name and identify boot loader entries for this OS
+        installation. Accepted during <option>install</option>, and takes one of <literal>auto</literal>,
+        <literal>machine-id</literal>, <literal>os-id</literal>, <literal>os-image-id</literal> or an
+        arbitrary string prefixed by <literal>literal:</literal> as argument.</para>
+
+        <para>If set to <option>machine-id</option> the entries are named after the machine ID of the running
+        system (e.g. <literal>b0e793a9baf14b5fa13ecbe84ff637ac</literal>). See
+        <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
+        details about the machine ID concept and file.</para>
+
+        <para>If set to <option>os-id</option> the entries are named after the OS ID of the running system,
+        i.e. the <varname>ID=</varname> field of
+        <citerefentry><refentrytitle>os-release</refentrytitle><manvolnum>5</manvolnum></citerefentry> (e.g.
+        <literal>fedora</literal>). Similarly, if set to <option>os-image-id</option> the entries are named
+        after the OS image ID of the running system, i.e. the <varname>IMAGE_ID=</varname> field of
+        <filename>os-release</filename> (e.g. <literal>vendorx-cashier-system</literal>).</para>
+
+        <para>If set to <option>auto</option> (the default), the <filename>/etc/kernel/entry-token</filename>
+        file will be read if it exists, and the stored value used.  Otherwise if the local machine ID is
+        initialized it is used. Otherwise <varname>IMAGE_ID=</varname> from <filename>os-release</filename>
+        will be used, if set.  Otherwise, <varname>ID=</varname> from <filename>os-release</filename> will be
+        used, if set.</para>
+
+        <para>Unless set to <literal>machine-id</literal>, or when
+        <option>--make-entry-directory=yes</option> is used the selected token string is written to a file
+        <filename>/etc/kernel/entry-token</filename>, to ensure it will be used for future entries. This file
+        is also read by
+        <citerefentry><refentrytitle>kernel-install</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+        in order to identify under which name to generate boot loader entries for newly installed kernels, or
+        to determine the entry names for removing old ones.</para>
+
+        <para>Using the machine ID for naming the entries is generally preferable, however there are cases
+        where using the other identifiers is a good option. Specifically: if the identification data that the
+        machine ID entails shall not be stored on the (unencrypted) <varname>$BOOT</varname> partition, or if
+        the ID shall be generated on first boot and is not known when the entries are prepared. Note that
+        using the machine ID has the benefit that multiple parallel installations of the same OS can coexist
+        on the same medium, and they can update their boot loader entries independently. When using another
+        identifier (such as the OS ID or the OS image ID), parallel installations of the same OS would try to
+        use the same entry name. To support parallel installations, the installer must use a different entry
+        token when adding a second installation.</para>
+
+        <xi:include href="version-info.xml" xpointer="v251"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--all-architectures</option></term>
+        <listitem><para>Install binaries for all supported EFI architectures (this implies <option>--no-variables</option>).</para>
+
+        <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--efi-boot-option-description=</option></term>
+        <listitem><para>Description of the entry added to the firmware's boot option list. Defaults to <literal>Linux
+        Boot Manager</literal>.</para>
+
+        <para>Using the default entry name <literal>Linux Boot Manager</literal> is generally preferable as only
+        one bootloader installed to a single ESP partition should be used to boot any number of OS installations
+        found on the various disks installed in the system. Specifically distributions should not use this flag
+        to install a branded entry in the boot option list. However in situations with multiple disks, each with
+        their own ESP partition, it can be beneficial to make it easier to identify the bootloader being used in
+        the firmware's boot option menu.</para>
+
+        <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--dry-run</option></term>
+        <listitem><para>Dry run for <option>unlink</option> and <option>cleanup</option>.</para>
+
+        <para>In dry run mode, the unlink and cleanup operations only print the files that would get deleted
+        without actually deleting them.</para>
+
+        <xi:include href="version-info.xml" xpointer="v253"/></listitem>
+      </varlistentry>
+
+      <xi:include href="standard-options.xml" xpointer="no-pager"/>
+      <xi:include href="standard-options.xml" xpointer="json" />
+      <xi:include href="standard-options.xml" xpointer="help"/>
+      <xi:include href="standard-options.xml" xpointer="version"/>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Signed .efi files</title>
+    <para><command>bootctl</command> <option>install</option> and <option>update</option> will look for a
+    <command>systemd-boot</command> file ending with the <literal>.efi.signed</literal> suffix first, and copy
+    that instead of the normal <literal>.efi</literal> file. This allows distributions or end-users to provide
+    signed images for UEFI SecureBoot.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Exit status</title>
+    <para>On success, 0 is returned, a non-zero failure code otherwise. <command>bootctl
+    --print-root-device</command> returns exit status 80 in case the root file system is not backed by single
+    block device, and other non-zero exit statuses on other errors.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Environment</title>
+    <para>If <varname>$SYSTEMD_RELAX_ESP_CHECKS=1</varname> is set the validation checks for the ESP are
+    relaxed, and the path specified with <option>--esp-path=</option> may refer to any kind of file system on
+    any kind of partition.</para>
+
+    <para>Similarly, <varname>$SYSTEMD_RELAX_XBOOTLDR_CHECKS=1</varname> turns off some validation checks for
+    the Extended Boot Loader partition.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Examples</title>
+
+    <example>
+      <title>Output from <command>status</command> and <command>list</command></title>
+
+      <programlisting>$ <command>bootctl status</command>
+System:
+     Firmware: UEFI 2.40 (<replaceable>firmware-version</replaceable>)  ← firmware vendor and version
+  Secure Boot: disabled (setup)              ← Secure Boot status
+ TPM2 Support: yes
+ Boot into FW: supported                     ← does the firmware support booting into itself
+
+Current Boot Loader:                         ← details about sd-boot or another boot loader
+      Product: systemd-boot <replaceable>version</replaceable>            implementing the <ulink
+    url="https://systemd.io/BOOT_LOADER_INTERFACE">Boot Loader Interface</ulink>
+     Features: ✓ Boot counting
+               ✓ Menu timeout control
+               ✓ One-shot menu timeout control
+               ✓ Default entry control
+               ✓ One-shot entry control
+               ✓ Support for XBOOTLDR partition
+               ✓ Support for passing random seed to OS
+               ✓ Load drop-in drivers
+               ✓ Boot loader sets ESP information
+               ✓ Menu can be disabled
+          ESP: /dev/disk/by-partuuid/01234567-89ab-cdef-dead-beef00000000
+         File: └─/EFI/systemd/systemd-bootx64.efi
+
+Random Seed:                                 ← random seed used for entropy in early boot
+ Passed to OS: yes
+ System Token: set
+       Exists: yes
+
+Available Boot Loaders on ESP:
+          ESP: /boot/efi (/dev/disk/by-partuuid/01234567-89ab-cdef-dead-beef00000000)
+         File: └─/EFI/systemd/systemd-bootx64.efi (systemd-boot 251
+         File: └─/EFI/BOOT/BOOTX64.EFI (systemd-boot 251
+
+Boot Loaders Listed in EFI Variables:
+        Title: Linux Boot Manager
+           ID: 0x0001
+       Status: active, boot-order
+    Partition: /dev/disk/by-partuuid/…
+         File: └─/EFI/systemd/systemd-bootx64.efi
+
+        Title: Fedora
+           ID: 0x0000
+       Status: active, boot-order
+    Partition: /dev/disk/by-partuuid/…
+         File: └─/EFI/fedora/shimx64.efi
+
+        Title: Linux-Firmware-Updater
+           ID: 0x0002
+       Status: active, boot-order
+    Partition: /dev/disk/by-partuuid/…
+         File: └─/EFI/fedora/fwupdx64.efi
+
+Boot Loader Entries:
+        $BOOT: /boot/efi (/dev/disk/by-partuuid/01234567-89ab-cdef-dead-beef00000000)
+
+Default Boot Loader Entry:
+         type: Boot Loader Specification Type #1 (.conf)
+        title: Fedora Linux 36 (Workstation Edition)
+           id: …
+       source: /boot/efi/loader/entries/<replaceable>entry-token</replaceable>-<replaceable>kernel-version</replaceable>.conf
+      version: <replaceable>kernel-version</replaceable>
+   machine-id: …
+        linux: /<replaceable>entry-token</replaceable>/<replaceable>kernel-version</replaceable>/linux
+       initrd: /<replaceable>entry-token</replaceable>/<replaceable>kernel-version</replaceable>/initrd
+      options: root=…
+</programlisting>
+
+      <programlisting>$ <command>bootctl list</command>
+Boot Loader Entries:
+         type: Boot Loader Specification Type #1 (.conf)
+        title: Fedora Linux 36 (Workstation Edition) (default) (selected)
+           id: …
+       source: /boot/efi/loader/entries/<replaceable>entry-token</replaceable>-<replaceable>kernel-version</replaceable>.conf
+      version: <replaceable>kernel-version</replaceable>
+   machine-id: …
+        linux: /<replaceable>entry-token</replaceable>/<replaceable>kernel-version</replaceable>/linux
+       initrd: /<replaceable>entry-token</replaceable>/<replaceable>kernel-version</replaceable>/initrd
+      options: root=…
+
+         type: Boot Loader Specification Type #2 (.efi)
+        title: Fedora Linux 35 (Workstation Edition)
+           id: …
+       source: /boot/efi/EFI/Linux/fedora-<replaceable>kernel-version</replaceable>.efi
+      version: <replaceable>kernel-version</replaceable>
+   machine-id: …
+        linux: /EFI/Linux/fedora-<replaceable>kernel-version</replaceable>.efi
+      options: root=…
+
+         type: Automatic
+        title: Reboot Into Firmware Interface
+           id: auto-reboot-to-firmware-setup
+       source: /sys/firmware/efi/efivars/LoaderEntries-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f
+</programlisting>
+
+       <para>In the listing, <literal>(default)</literal> specifies the entry that will be
+       used by default, and <literal>(selected)</literal> specifies the entry that was
+       selected the last time (i.e. is currently running).</para>
+    </example>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd-boot</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <ulink url="https://uapi-group.org/specifications/specs/boot_loader_specification">Boot Loader Specification</ulink>,
+      <ulink url="https://systemd.io/BOOT_LOADER_INTERFACE">Boot Loader Interface</ulink>,
+      <citerefentry><refentrytitle>systemd-boot-random-seed.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+</refentry>
diff --git a/man/bootup.xml b/man/bootup.xml
new file mode 100644
index 0000000..c872b13
--- /dev/null
+++ b/man/bootup.xml
@@ -0,0 +1,358 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="bootup">
+
+  <refentryinfo>
+    <title>bootup</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>bootup</refentrytitle>
+    <manvolnum>7</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>bootup</refname>
+    <refpurpose>System bootup process</refpurpose>
+  </refnamediv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>A number of different components are involved in the boot of a Linux system. Immediately after
+    power-up, the system firmware will do minimal hardware initialization, and hand control over to a boot
+    loader (e.g.
+    <citerefentry><refentrytitle>systemd-boot</refentrytitle><manvolnum>7</manvolnum></citerefentry> or
+    <ulink url="https://www.gnu.org/software/grub/">GRUB</ulink>) stored on a persistent storage device. This
+    boot loader will then invoke an OS kernel from disk (or the network). On systems using EFI or other types
+    of firmware, this firmware may also load the kernel directly.</para>
+
+    <para>The kernel (optionally) mounts an in-memory file system, often generated by <citerefentry
+    project='man-pages'><refentrytitle>dracut</refentrytitle><manvolnum>8</manvolnum></citerefentry>, which
+    looks for the root file system. Nowadays this is implemented as an "initramfs" — a compressed CPIO
+    archive that the kernel extracts into a tmpfs. In the past normal file systems using an in-memory block
+    device (ramdisk) were used, and the name "initrd" is still used to describe both concepts. It's the boot
+    loader or the firmware that loads both the kernel and initrd/initramfs images into memory, but the kernel
+    which interprets it as a file system.
+    <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> may be used
+    to manage services in the initrd, similarly to the real system.</para>
+
+    <para>After the root file system is found and mounted, the initrd hands over control to the host's system
+    manager (such as
+    <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>) stored in
+    the root file system, which is then responsible for probing all remaining hardware, mounting all
+    necessary file systems and spawning all configured services.</para>
+
+    <para>On shutdown, the system manager stops all services, unmounts
+    all file systems (detaching the storage technologies backing
+    them), and then (optionally) jumps back into the initrd code which
+    unmounts/detaches the root file system and the storage it resides
+    on. As a last step, the system is powered down.</para>
+
+    <para>Additional information about the system boot process may be
+    found in
+    <citerefentry project='man-pages'><refentrytitle>boot</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>System Manager Bootup</title>
+
+    <para>At boot, the system manager on the OS image is responsible
+    for initializing the required file systems, services and drivers
+    that are necessary for operation of the system. On
+    <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    systems, this process is split up in various discrete steps which
+    are exposed as target units. (See
+    <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for detailed information about target units.) The boot-up process
+    is highly parallelized so that the order in which specific target
+    units are reached is not deterministic, but still adheres to a
+    limited amount of ordering structure.</para>
+
+    <para>When systemd starts up the system, it will activate all
+    units that are dependencies of <filename>default.target</filename>
+    (as well as recursively all dependencies of these dependencies).
+    Usually, <filename>default.target</filename> is simply an alias of
+    <filename>graphical.target</filename> or
+    <filename>multi-user.target</filename>, depending on whether the
+    system is configured for a graphical UI or only for a text
+    console. To enforce minimal ordering between the units pulled in,
+    a number of well-known target units are available, as listed on
+    <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
+
+    <para>The following chart is a structural overview of these
+    well-known units and their position in the boot-up logic. The
+    arrows describe which units are pulled in and ordered before which
+    other units. Units near the top are started before units nearer to
+    the bottom of the chart.</para>
+
+    <!-- note: do not use unicode ellipsis here, because docbook will replace that
+         with three dots anyway, messing up alignment -->
+<programlisting>                             cryptsetup-pre.target veritysetup-pre.target
+                                                  |
+(various low-level                                v
+ API VFS mounts:             (various cryptsetup/veritysetup devices...)
+ mqueue, configfs,                                |    |
+ debugfs, ...)                                    v    |
+ |                                  cryptsetup.target  |
+ |  (various swap                                 |    |    remote-fs-pre.target
+ |   devices...)                                  |    |     |        |
+ |    |                                           |    |     |        v
+ |    v                       local-fs-pre.target |    |     |  (network file systems)
+ |  swap.target                       |           |    v     v                 |
+ |    |                               v           |  remote-cryptsetup.target  |
+ |    |  (various low-level  (various mounts and  |  remote-veritysetup.target |
+ |    |   services: udevd,    fsck services...)   |             |              |
+ |    |   tmpfiles, random            |           |             |    remote-fs.target
+ |    |   seed, sysctl, ...)          v           |             |              |
+ |    |      |                 local-fs.target    |             | _____________/
+ |    |      |                        |           |             |/
+ \____|______|_______________   ______|___________/             |
+                             \ /                                |
+                              v                                 |
+                       sysinit.target                           |
+                              |                                 |
+       ______________________/|\_____________________           |
+      /              |        |      |               \          |
+      |              |        |      |               |          |
+      v              v        |      v               |          |
+ (various       (various      |  (various            |          |
+  timers...)      paths...)   |   sockets...)        |          |
+      |              |        |      |               |          |
+      v              v        |      v               |          |
+timers.target  paths.target   |  sockets.target      |          |
+      |              |        |      |               v          |
+      v              \_______ | _____/         rescue.service   |
+                             \|/                     |          |
+                              v                      v          |
+                          basic.target         <emphasis>rescue.target</emphasis>    |
+                              |                                 |
+                      ________v____________________             |
+                     /              |              \            |
+                     |              |              |            |
+                     v              v              v            |
+                 display-    (various system   (various system  |
+             manager.service     services        services)      |
+                     |         required for        |            |
+                     |        graphical UIs)       v            v
+                     |              |            <emphasis>multi-user.target</emphasis>
+emergency.service    |              |              |
+        |            \_____________ | _____________/
+        v                          \|/
+<emphasis>emergency.target</emphasis>                    v
+                              <emphasis>graphical.target</emphasis></programlisting>
+
+    <para>Target units that are commonly used as boot targets are
+    <emphasis>emphasized</emphasis>. These units are good choices as
+    goal targets, for example by passing them to the
+    <varname>systemd.unit=</varname> kernel command line option (see
+    <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>)
+    or by symlinking <filename>default.target</filename> to them.
+    </para>
+
+    <para><filename>timers.target</filename> is pulled-in by
+    <filename>basic.target</filename> asynchronously. This allows
+    timers units to depend on services which become only available
+    later in boot.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>User manager startup</title>
+
+    <para>The system manager starts the <filename>user@<replaceable>uid</replaceable>.service</filename> unit
+    for each user, which launches a separate unprivileged instance of <command>systemd</command> for each
+    user — the user manager. Similarly to the system manager, the user manager starts units which are pulled
+    in by <filename>default.target</filename>. The following chart is a structural overview of the well-known
+    user units. For non-graphical sessions, <filename>default.target</filename> is used. Whenever the user
+    logs into a graphical session, the login manager will start the
+    <filename>graphical-session.target</filename> target that is used to pull in units required for the
+    graphical session. A number of targets (shown on the right side) are started when specific hardware is
+    available to the user.</para>
+
+<programlisting>
+   (various           (various         (various
+    timers...)         paths...)        sockets...)    (sound devices)
+        |                  |                 |               |
+        v                  v                 v               v
+  timers.target      paths.target     sockets.target    sound.target
+        |                  |                 |
+        \______________   _|_________________/         (bluetooth devices)
+                       \ /                                   |
+                        V                                    v
+                  basic.target                          bluetooth.target
+                        |
+             __________/ \_______                      (smartcard devices)
+            /                    \                           |
+            |                    |                           v
+            |                    v                      smartcard.target
+            v            graphical-session-pre.target
+(various user services)          |                       (printers)
+            |                    v                           |
+            |       (services for the graphical session)     v
+            |                    |                       printer.target
+            v                    v
+     <emphasis>default.target</emphasis>      graphical-session.target</programlisting>
+
+ </refsect1>
+
+  <refsect1>
+    <title>Bootup in the initrd</title>
+
+    <para>Systemd can be used in the initrd as well. It detects the initrd environment by checking for the
+    <filename>/etc/initrd-release</filename> file. The default target in the initrd is
+    <filename>initrd.target</filename>. The bootup process is identical to the system manager bootup until
+    the target <filename>basic.target</filename>. After that, systemd executes the special target
+    <filename>initrd.target</filename>.
+
+    Before any file systems are mounted, the manager will determine whether the system shall resume from
+    hibernation or proceed with normal boot. This is accomplished by
+    <filename>systemd-hibernate-resume.service</filename> which must be finished before
+    <filename>local-fs-pre.target</filename>, so no filesystems can be mounted before the check is complete.
+
+    When the root device becomes available,
+    <filename>initrd-root-device.target</filename> is reached.
+    If the root device can be mounted at
+    <filename>/sysroot</filename>, the
+    <filename>sysroot.mount</filename> unit becomes active and
+    <filename>initrd-root-fs.target</filename> is reached. The service
+    <filename>initrd-parse-etc.service</filename> scans
+    <filename>/sysroot/etc/fstab</filename> for a possible
+    <filename>/usr/</filename> mount point and additional entries
+    marked with the <emphasis>x-initrd.mount</emphasis> option. All
+    entries found are mounted below <filename>/sysroot</filename>, and
+    <filename>initrd-fs.target</filename> is reached. The service
+    <filename>initrd-cleanup.service</filename> isolates to the
+    <filename>initrd-switch-root.target</filename>, where cleanup
+    services can run. As the very last step, the
+    <filename>initrd-switch-root.service</filename> is activated,
+    which will cause the system to switch its root to
+    <filename>/sysroot</filename>.
+    </para>
+
+<programlisting>                               : (beginning identical to above)
+                               :
+                               v
+                         basic.target
+                               |                       emergency.service
+        ______________________/|                               |
+       /                       |                               v
+       |            initrd-root-device.target          <emphasis>emergency.target</emphasis>
+       |                       |
+       |                       v
+       |                  sysroot.mount
+       |                       |
+       |                       v
+       |             initrd-root-fs.target
+       |                       |
+       |                       v
+       v            initrd-parse-etc.service
+(custom initrd                 |
+ services...)                  v
+       |            (sysroot-usr.mount and
+       |             various mounts marked
+       |               with fstab option
+       |              x-initrd.mount...)
+       |                       |
+       |                       v
+       |                initrd-fs.target
+       \______________________ |
+                              \|
+                               v
+                          initrd.target
+                               |
+                               v
+                     initrd-cleanup.service
+                          isolates to
+                    initrd-switch-root.target
+                               |
+                               v
+        ______________________/|
+       /                       v
+       |        initrd-udevadm-cleanup-db.service
+       v                       |
+(custom initrd                 |
+ services...)                  |
+       \______________________ |
+                              \|
+                               v
+                   initrd-switch-root.target
+                               |
+                               v
+                   initrd-switch-root.service
+                               |
+                               v
+                     Transition to Host OS</programlisting>
+  </refsect1>
+
+  <refsect1>
+    <title>System Manager Shutdown</title>
+
+    <para>System shutdown with systemd also consists of various target
+    units with some minimal ordering structure applied:</para>
+
+<programlisting>                       (conflicts with  (conflicts with
+                          all system     all file system
+                           services)     mounts, swaps,
+                               |           cryptsetup/
+                               |           veritysetup
+                               |          devices, ...)
+                               |                |
+                               v                v
+                        shutdown.target    umount.target
+                               |                |
+                               \_______   ______/
+                                       \ /
+                                        v
+                               (various low-level
+                                    services)
+                                        |
+                                        v
+                                  final.target
+                                        |
+            ___________________________/ \_________________
+           /               |               |               \
+           |               |               |               |
+           v               |               |               |
+systemd-reboot.service     |               |               |
+           |               v               |               |
+           |    systemd-poweroff.service   |               |
+           v               |               v               |
+     <emphasis>reboot.target</emphasis>         |      systemd-halt.service     |
+                           v               |               v
+                   <emphasis>poweroff.target</emphasis>         |    systemd-kexec.service
+                                           v               |
+                                      <emphasis>halt.target</emphasis>          |
+                                                           v
+                                                     <emphasis>kexec.target</emphasis></programlisting>
+
+    <para>Commonly used system shutdown targets are <emphasis>emphasized</emphasis>.</para>
+
+    <para>Note that
+    <citerefentry><refentrytitle>systemd-halt.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+    <filename>systemd-reboot.service</filename>, <filename>systemd-poweroff.service</filename> and
+    <filename>systemd-kexec.service</filename> will transition the system and server manager (PID 1) into the second
+    phase of system shutdown (implemented in the <filename>systemd-shutdown</filename> binary), which will unmount any
+    remaining file systems, kill any remaining processes and release any other remaining resources, in a simple and
+    robust fashion, without taking any service or unit concept into account anymore. At that point, regular
+    applications and resources are generally terminated and released already, the second phase hence operates only as
+    safety net for everything that couldn't be stopped or released for some reason during the primary, unit-based
+    shutdown phase described above.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>boot</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-halt.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>dracut</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/busctl.xml b/man/busctl.xml
new file mode 100644
index 0000000..cc40452
--- /dev/null
+++ b/man/busctl.xml
@@ -0,0 +1,591 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="busctl"
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>busctl</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>busctl</refentrytitle>
+    <manvolnum>1</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>busctl</refname>
+    <refpurpose>Introspect the bus</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <cmdsynopsis>
+      <command>busctl</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="opt">COMMAND</arg>
+      <arg choice="opt" rep="repeat"><replaceable>NAME</replaceable></arg>
+    </cmdsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>busctl</command> may be used to
+    introspect and monitor the D-Bus bus.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Commands</title>
+
+    <para>The following commands are understood:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><command>list</command></term>
+
+        <listitem><para>Show all peers on the bus, by their service
+        names. By default, shows both unique and well-known names, but
+        this may be changed with the <option>--unique</option> and
+        <option>--acquired</option> switches. This is the default
+        operation if no command is specified.</para>
+
+        <xi:include href="version-info.xml" xpointer="v209"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>status</command> <arg choice="opt"><replaceable>SERVICE</replaceable></arg></term>
+
+        <listitem><para>Show process information and credentials of a
+        bus service (if one is specified by its unique or well-known
+        name), a process (if one is specified by its numeric PID), or
+        the owner of the bus (if no parameter is
+        specified).</para>
+
+        <xi:include href="version-info.xml" xpointer="v209"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>monitor</command> <arg choice="opt" rep="repeat"><replaceable>SERVICE</replaceable></arg></term>
+
+        <listitem><para>Dump messages being exchanged. If
+        <replaceable>SERVICE</replaceable> is specified, show messages
+        to or from this peer, identified by its well-known or unique
+        name. Otherwise, show all messages on the bus. Use
+        <keycombo><keycap>Ctrl</keycap><keycap>C</keycap></keycombo>
+        to terminate the dump.</para>
+
+        <xi:include href="version-info.xml" xpointer="v209"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>capture</command> <arg choice="opt" rep="repeat"><replaceable>SERVICE</replaceable></arg></term>
+
+        <listitem><para>Similar to <command>monitor</command> but
+        writes the output in pcapng format (for details, see
+        <ulink url="https://github.com/pcapng/pcapng/">
+        PCAP Next Generation (pcapng) Capture File Format</ulink>).
+        Make sure to redirect standard output to a file or pipe. Tools like
+        <citerefentry project='die-net'><refentrytitle>wireshark</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+        may be used to dissect and view the resulting
+        files.</para>
+
+        <xi:include href="version-info.xml" xpointer="v218"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>tree</command> <arg choice="opt" rep="repeat"><replaceable>SERVICE</replaceable></arg></term>
+
+        <listitem><para>Shows an object tree of one or more
+        services. If <replaceable>SERVICE</replaceable> is specified,
+        show object tree of the specified services only. Otherwise,
+        show all object trees of all services on the bus that acquired
+        at least one well-known name.</para>
+
+        <xi:include href="version-info.xml" xpointer="v218"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>introspect</command> <arg choice="plain"><replaceable>SERVICE</replaceable></arg> <arg choice="plain"><replaceable>OBJECT</replaceable></arg> <arg choice="opt"><replaceable>INTERFACE</replaceable></arg></term>
+
+        <listitem><para>Show interfaces, methods, properties and
+        signals of the specified object (identified by its path) on
+        the specified service. If the interface argument is passed, the
+        output is limited to members of the specified
+        interface.</para>
+
+        <xi:include href="version-info.xml" xpointer="v218"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>call</command> <arg choice="plain"><replaceable>SERVICE</replaceable></arg> <arg choice="plain"><replaceable>OBJECT</replaceable></arg> <arg choice="plain"><replaceable>INTERFACE</replaceable></arg> <arg choice="plain"><replaceable>METHOD</replaceable></arg> <arg choice="opt"><replaceable>SIGNATURE</replaceable> <arg choice="opt" rep="repeat"><replaceable>ARGUMENT</replaceable></arg></arg></term>
+
+        <listitem><para>Invoke a method and show the response. Takes a
+        service name, object path, interface name and method name. If
+        parameters shall be passed to the method call, a signature
+        string is required, followed by the arguments, individually
+        formatted as strings. For details on the formatting used, see
+        below. To suppress output of the returned data, use the
+        <option>--quiet</option> option.</para>
+
+        <xi:include href="version-info.xml" xpointer="v218"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>emit</command> <arg choice="plain"><replaceable>OBJECT</replaceable></arg> <arg choice="plain"><replaceable>INTERFACE</replaceable></arg> <arg choice="plain"><replaceable>SIGNAL</replaceable></arg> <arg choice="opt"><replaceable>SIGNATURE</replaceable> <arg choice="opt" rep="repeat"><replaceable>ARGUMENT</replaceable></arg></arg></term>
+
+        <listitem><para>Emit a signal. Takes an object path, interface name and method name. If parameters
+        shall be passed, a signature string is required, followed by the arguments, individually formatted as
+        strings. For details on the formatting used, see below. To specify the destination of the signal,
+        use the <option>--destination=</option> option.</para>
+
+        <xi:include href="version-info.xml" xpointer="v242"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>get-property</command> <arg choice="plain"><replaceable>SERVICE</replaceable></arg> <arg choice="plain"><replaceable>OBJECT</replaceable></arg> <arg choice="plain"><replaceable>INTERFACE</replaceable></arg> <arg choice="plain" rep="repeat"><replaceable>PROPERTY</replaceable></arg></term>
+
+        <listitem><para>Retrieve the current value of one or more
+        object properties. Takes a service name, object path,
+        interface name and property name. Multiple properties may be
+        specified at once, in which case their values will be shown one
+        after the other, separated by newlines. The output is, by
+        default, in terse format. Use <option>--verbose</option> for a
+        more elaborate output format.</para>
+
+        <xi:include href="version-info.xml" xpointer="v218"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>set-property</command> <arg choice="plain"><replaceable>SERVICE</replaceable></arg> <arg choice="plain"><replaceable>OBJECT</replaceable></arg> <arg choice="plain"><replaceable>INTERFACE</replaceable></arg> <arg choice="plain"><replaceable>PROPERTY</replaceable></arg> <arg choice="plain"><replaceable>SIGNATURE</replaceable></arg> <arg choice="plain" rep="repeat"><replaceable>ARGUMENT</replaceable></arg></term>
+
+        <listitem><para>Set the current value of an object
+        property. Takes a service name, object path, interface name,
+        property name, property signature, followed by a list of
+        parameters formatted as strings.</para>
+
+        <xi:include href="version-info.xml" xpointer="v218"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>help</command></term>
+
+        <listitem><para>Show command syntax help.</para>
+
+        <xi:include href="version-info.xml" xpointer="v209"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>The following options are understood:</para>
+
+    <variablelist>
+      <varlistentry>
+          <term><option>--address=<replaceable>ADDRESS</replaceable></option></term>
+
+          <listitem><para>Connect to the bus specified by
+          <replaceable>ADDRESS</replaceable> instead of using suitable
+          defaults for either the system or user bus (see
+          <option>--system</option> and <option>--user</option>
+          options).</para>
+
+          <xi:include href="version-info.xml" xpointer="v209"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+          <term><option>--show-machine</option></term>
+
+          <listitem><para>When showing the list of peers, show a
+          column containing the names of containers they belong to.
+          See
+          <citerefentry><refentrytitle>systemd-machined.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v209"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+          <term><option>--unique</option></term>
+
+          <listitem><para>When showing the list of peers, show only
+          "unique" names (of the form
+          <literal>:<replaceable>number</replaceable>.<replaceable>number</replaceable></literal>).
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v209"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+          <term><option>--acquired</option></term>
+
+          <listitem><para>The opposite of <option>--unique</option> —
+          only "well-known" names will be shown.</para>
+
+          <xi:include href="version-info.xml" xpointer="v209"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+          <term><option>--activatable</option></term>
+
+          <listitem><para>When showing the list of peers, show only
+          peers which have actually not been activated yet, but may be
+          started automatically if accessed.</para>
+
+          <xi:include href="version-info.xml" xpointer="v209"/>
+          </listitem>
+      </varlistentry>
+
+      <varlistentry>
+          <term><option>--match=<replaceable>MATCH</replaceable></option></term>
+
+          <listitem><para>When showing messages being exchanged, show only the
+          subset matching <replaceable>MATCH</replaceable>.
+          See
+          <citerefentry><refentrytitle>sd_bus_add_match</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v209"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--size=</option></term>
+
+        <listitem>
+          <para>When used with the <command>capture</command> command,
+          specifies the maximum bus message size to capture
+          ("snaplen"). Defaults to 4096 bytes.</para>
+
+        <xi:include href="version-info.xml" xpointer="v218"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--list</option></term>
+
+        <listitem>
+          <para>When used with the <command>tree</command> command, shows a
+          flat list of object paths instead of a tree.</para>
+
+        <xi:include href="version-info.xml" xpointer="v218"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-q</option></term>
+        <term><option>--quiet</option></term>
+
+        <listitem>
+          <para>When used with the <command>call</command> command,
+          suppresses display of the response message payload. Note that even
+          if this option is specified, errors returned will still be
+          printed and the tool will indicate success or failure with
+          the process exit code.</para>
+
+        <xi:include href="version-info.xml" xpointer="v218"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--verbose</option></term>
+
+        <listitem>
+          <para>When used with the <command>call</command> or
+          <command>get-property</command> command, shows output in a
+          more verbose format.</para>
+
+        <xi:include href="version-info.xml" xpointer="v218"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--xml-interface</option></term>
+
+        <listitem>
+          <para>When used with the <command>introspect</command> call, dump the XML description received from
+          the D-Bus <constant>org.freedesktop.DBus.Introspectable.Introspect</constant> call instead of the
+          normal output.</para>
+
+        <xi:include href="version-info.xml" xpointer="v243"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--json=</option><replaceable>MODE</replaceable></term>
+
+        <listitem>
+          <para>When used with the <command>call</command> or <command>get-property</command> command, shows output
+          formatted as JSON. Expects one of <literal>short</literal> (for the shortest possible output without any
+          redundant whitespace or line breaks) or <literal>pretty</literal> (for a pretty version of the same, with
+          indentation and line breaks). Note that transformation from D-Bus marshalling to JSON is done in a loss-less
+          way, which means type information is embedded into the JSON object tree.</para>
+
+        <xi:include href="version-info.xml" xpointer="v240"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-j</option></term>
+
+        <listitem>
+          <para>Equivalent to <option>--json=pretty</option> when invoked interactively from a terminal. Otherwise
+          equivalent to <option>--json=short</option>, in particular when the output is piped to some other
+          program.</para>
+
+        <xi:include href="version-info.xml" xpointer="v240"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--expect-reply=</option><replaceable>BOOL</replaceable></term>
+
+        <listitem>
+          <para>When used with the <command>call</command> command,
+          specifies whether <command>busctl</command> shall wait for
+          completion of the method call, output the returned method
+          response data, and return success or failure via the process
+          exit code. If this is set to <literal>no</literal>, the
+          method call will be issued but no response is expected, the
+          tool terminates immediately, and thus no response can be
+          shown, and no success or failure is returned via the exit
+          code. To only suppress output of the reply message payload,
+          use <option>--quiet</option> above. Defaults to
+          <literal>yes</literal>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v218"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--auto-start=</option><replaceable>BOOL</replaceable></term>
+
+        <listitem>
+          <para>When used with the <command>call</command> or <command>emit</command> command, specifies
+          whether the method call should implicitly activate the
+          called service, should it not be running yet but is
+          configured to be auto-started. Defaults to
+          <literal>yes</literal>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v218"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--allow-interactive-authorization=</option><replaceable>BOOL</replaceable></term>
+
+        <listitem>
+          <para>When used with the <command>call</command> command,
+          specifies whether the services may enforce interactive
+          authorization while executing the operation, if the security
+          policy is configured for this. Defaults to
+          <literal>yes</literal>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v218"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--timeout=</option><replaceable>SECS</replaceable></term>
+
+        <listitem>
+          <para>When used with the <command>call</command> command,
+          specifies the maximum time to wait for method call
+          completion. If no time unit is specified, assumes
+          seconds. The usual other units are understood, too (ms, us,
+          s, min, h, d, w, month, y). Note that this timeout does not
+          apply if <option>--expect-reply=no</option> is used, as the
+          tool does not wait for any reply message then. When not
+          specified or when set to 0, the default of
+          <literal>25s</literal> is assumed.</para>
+
+        <xi:include href="version-info.xml" xpointer="v218"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--augment-creds=</option><replaceable>BOOL</replaceable></term>
+
+        <listitem>
+          <para>Controls whether credential data reported by
+          <command>list</command> or <command>status</command> shall
+          be augmented with data from
+          <filename>/proc/</filename>. When this is turned on, the data
+          shown is possibly inconsistent, as the data read from
+          <filename>/proc/</filename> might be more recent than the rest of
+          the credential information. Defaults to <literal>yes</literal>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v218"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--watch-bind=</option><replaceable>BOOL</replaceable></term>
+
+        <listitem>
+          <para>Controls whether to wait for the specified <constant>AF_UNIX</constant> bus socket to appear in the
+          file system before connecting to it. Defaults to off. When enabled, the tool will watch the file system until
+          the socket is created and then connect to it.</para>
+
+        <xi:include href="version-info.xml" xpointer="v237"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--destination=</option><replaceable>SERVICE</replaceable></term>
+
+        <listitem>
+          <para>Takes a service name. When used with the <command>emit</command> command, a signal is
+          emitted to the specified service.</para>
+
+        <xi:include href="version-info.xml" xpointer="v242"/>
+        </listitem>
+      </varlistentry>
+
+      <xi:include href="user-system-options.xml" xpointer="user" />
+      <xi:include href="user-system-options.xml" xpointer="system" />
+      <xi:include href="user-system-options.xml" xpointer="host" />
+      <xi:include href="user-system-options.xml" xpointer="machine" />
+
+      <varlistentry>
+        <term><option>-l</option></term>
+        <term><option>--full</option></term>
+
+        <listitem>
+          <para>Do not ellipsize the output in <command>list</command> command.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/>
+        </listitem>
+      </varlistentry>
+
+      <xi:include href="standard-options.xml" xpointer="no-pager" />
+      <xi:include href="standard-options.xml" xpointer="no-legend" />
+      <xi:include href="standard-options.xml" xpointer="help" />
+      <xi:include href="standard-options.xml" xpointer="version" />
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Parameter Formatting</title>
+
+    <para>The <command>call</command> and
+    <command>set-property</command> commands take a signature string
+    followed by a list of parameters formatted as string (for details
+    on D-Bus signature strings, see the <ulink
+    url="https://dbus.freedesktop.org/doc/dbus-specification.html#type-system">Type
+    system chapter of the D-Bus specification</ulink>). For simple
+    types, each parameter following the signature should simply be the
+    parameter's value formatted as string. Positive boolean values may
+    be formatted as <literal>true</literal>, <literal>yes</literal>,
+    <literal>on</literal>, or <literal>1</literal>; negative boolean
+    values may be specified as <literal>false</literal>,
+    <literal>no</literal>, <literal>off</literal>, or
+    <literal>0</literal>. For arrays, a numeric argument for the
+    number of entries followed by the entries shall be specified. For
+    variants, the signature of the contents shall be specified,
+    followed by the contents. For dictionaries and structs, the
+    contents of them shall be directly specified.</para>
+
+    <para>For example,
+    <programlisting>s jawoll</programlisting> is the formatting
+    of a single string <literal>jawoll</literal>.</para>
+
+    <para>
+    <programlisting>as 3 hello world foobar</programlisting>
+    is the formatting of a string array with three entries,
+    <literal>hello</literal>, <literal>world</literal> and
+    <literal>foobar</literal>.</para>
+
+    <para>
+    <programlisting>a{sv} 3 One s Eins Two u 2 Yes b true</programlisting>
+    is the formatting of a dictionary
+    array that maps strings to variants, consisting of three
+    entries. The string <literal>One</literal> is assigned the
+    string <literal>Eins</literal>. The string
+    <literal>Two</literal> is assigned the 32-bit unsigned
+    integer 2. The string <literal>Yes</literal> is assigned a
+    positive boolean.</para>
+
+    <para>Note that the <command>call</command>,
+    <command>get-property</command>, <command>introspect</command>
+    commands will also generate output in this format for the returned
+    data. Since this format is sometimes too terse to be easily
+    understood, the <command>call</command> and
+    <command>get-property</command> commands may generate a more
+    verbose, multi-line output when passed the
+    <option>--verbose</option> option.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Examples</title>
+
+    <example>
+      <title>Write and Read a Property</title>
+
+      <para>The following two commands first write a property and then
+      read it back. The property is found on the
+      <literal>/org/freedesktop/systemd1</literal> object of the
+      <literal>org.freedesktop.systemd1</literal> service. The name of
+      the property is <literal>LogLevel</literal> on the
+      <literal>org.freedesktop.systemd1.Manager</literal>
+      interface. The property contains a single string:</para>
+
+      <programlisting># busctl set-property org.freedesktop.systemd1 /org/freedesktop/systemd1 org.freedesktop.systemd1.Manager LogLevel s debug
+# busctl get-property org.freedesktop.systemd1 /org/freedesktop/systemd1 org.freedesktop.systemd1.Manager LogLevel
+s "debug"</programlisting>
+
+    </example>
+
+    <example>
+      <title>Terse and Verbose Output</title>
+
+      <para>The following two commands read a property that contains
+      an array of strings, and first show it in terse format, followed
+      by verbose format:</para>
+
+      <programlisting>$ busctl get-property org.freedesktop.systemd1 /org/freedesktop/systemd1 org.freedesktop.systemd1.Manager Environment
+as 2 "LANG=en_US.UTF-8" "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin"
+$ busctl get-property --verbose org.freedesktop.systemd1 /org/freedesktop/systemd1 org.freedesktop.systemd1.Manager Environment
+ARRAY "s" {
+        STRING "LANG=en_US.UTF-8";
+        STRING "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin";
+};</programlisting>
+    </example>
+
+    <example>
+      <title>Invoking a Method</title>
+
+      <para>The following command invokes the
+      <literal>StartUnit</literal> method on the
+      <literal>org.freedesktop.systemd1.Manager</literal>
+      interface of the
+      <literal>/org/freedesktop/systemd1</literal> object
+      of the <literal>org.freedesktop.systemd1</literal>
+      service, and passes it two strings
+      <literal>cups.service</literal> and
+      <literal>replace</literal>. As a result of the method
+      call, a single object path parameter is received and
+      shown:</para>
+
+      <programlisting># busctl call org.freedesktop.systemd1 /org/freedesktop/systemd1 org.freedesktop.systemd1.Manager StartUnit ss "cups.service" "replace"
+o "/org/freedesktop/systemd1/job/42684"</programlisting>
+    </example>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry project='dbus'><refentrytitle>dbus-daemon</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <ulink url="https://www.freedesktop.org/wiki/Software/dbus">D-Bus</ulink>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>varlinkctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>machinectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry project='die-net'><refentrytitle>wireshark</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+</refentry>
diff --git a/man/cgroup-sandboxing.xml b/man/cgroup-sandboxing.xml
new file mode 100644
index 0000000..56f7c40
--- /dev/null
+++ b/man/cgroup-sandboxing.xml
@@ -0,0 +1,16 @@
+<?xml version="1.0"?>
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd">
+
+<!--
+  SPDX-License-Identifier: LGPL-2.1-or-later
+-->
+
+<refsect1>
+
+<para id="singular">This option cannot be bypassed by prefixing <literal>+</literal> to the executable path
+in the service unit, as it applies to the whole control group.</para>
+
+<para id="plural">These options cannot be bypassed by prefixing <literal>+</literal> to the executable path
+in the service unit, as it applies to the whole control group.</para>
+
+</refsect1>
diff --git a/man/check-os-release-simple.py b/man/check-os-release-simple.py
new file mode 100644
index 0000000..ce73c77
--- /dev/null
+++ b/man/check-os-release-simple.py
@@ -0,0 +1,12 @@
+#!/usr/bin/python
+# SPDX-License-Identifier: MIT-0
+
+import platform
+os_release = platform.freedesktop_os_release()
+
+pretty_name = os_release.get('PRETTY_NAME', 'Linux')
+print(f'Running on {pretty_name!r}')
+
+if 'fedora' in [os_release.get('ID', 'linux'),
+                *os_release.get('ID_LIKE', '').split()]:
+    print('Looks like Fedora!')
diff --git a/man/check-os-release.py b/man/check-os-release.py
new file mode 100644
index 0000000..19b193e
--- /dev/null
+++ b/man/check-os-release.py
@@ -0,0 +1,37 @@
+#!/usr/bin/python
+# SPDX-License-Identifier: MIT-0
+
+import ast
+import re
+import sys
+
+def read_os_release():
+    try:
+        filename = '/etc/os-release'
+        f = open(filename)
+    except FileNotFoundError:
+        filename = '/usr/lib/os-release'
+        f = open(filename)
+
+    for line_number, line in enumerate(f, start=1):
+        line = line.rstrip()
+        if not line or line.startswith('#'):
+            continue
+        m = re.match(r'([A-Z][A-Z_0-9]+)=(.*)', line)
+        if m:
+            name, val = m.groups()
+            if val and val[0] in '"\'':
+                val = ast.literal_eval(val)
+            yield name, val
+        else:
+            print(f'{filename}:{line_number}: bad line {line!r}',
+                  file=sys.stderr)
+
+os_release = dict(read_os_release())
+
+pretty_name = os_release.get('PRETTY_NAME', 'Linux')
+print(f'Running on {pretty_name!r}')
+
+if 'debian' in [os_release.get('ID', 'linux'),
+                *os_release.get('ID_LIKE', '').split()]:
+    print('Looks like Debian!')
diff --git a/man/check-os-release.sh b/man/check-os-release.sh
new file mode 100644
index 0000000..12f7ee1
--- /dev/null
+++ b/man/check-os-release.sh
@@ -0,0 +1,11 @@
+#!/bin/sh -eu
+# SPDX-License-Identifier: MIT-0
+
+test -e /etc/os-release && os_release='/etc/os-release' || os_release='/usr/lib/os-release'
+. "${os_release}"
+
+echo "Running on ${PRETTY_NAME:-Linux}"
+
+if [ "${ID:-linux}" = "debian" ] || [ "${ID_LIKE#*debian*}" != "${ID_LIKE}" ]; then
+    echo "Looks like Debian!"
+fi
diff --git a/man/common-variables.xml b/man/common-variables.xml
new file mode 100644
index 0000000..81425e5
--- /dev/null
+++ b/man/common-variables.xml
@@ -0,0 +1,210 @@
+<?xml version="1.0"?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refsect1>
+  <title>Environment</title>
+
+  <variablelist class='environment-variables'>
+    <varlistentry id='log-level'>
+      <term><varname>$SYSTEMD_LOG_LEVEL</varname></term>
+
+      <listitem><para id='log-level-body'>The maximum log level of emitted messages (messages with a higher
+      log level, i.e. less important ones, will be suppressed). Either one of (in order of decreasing
+      importance) <constant>emerg</constant>, <constant>alert</constant>, <constant>crit</constant>,
+      <constant>err</constant>, <constant>warning</constant>, <constant>notice</constant>,
+      <constant>info</constant>, <constant>debug</constant>, or an integer in the range 0…7. See
+      <citerefentry project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+      for more information.</para>
+      </listitem>
+    </varlistentry>
+
+    <varlistentry id='log-color'>
+      <term><varname>$SYSTEMD_LOG_COLOR</varname></term>
+
+      <listitem><para id='log-color-body'>A boolean. If true, messages written to the tty will be colored
+      according to priority.</para>
+
+      <para>This setting is only useful when messages are written directly to the terminal, because
+      <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> and
+      other tools that display logs will color messages based on the log level on their own.</para>
+      </listitem>
+    </varlistentry>
+
+    <varlistentry id='log-time'>
+      <term><varname>$SYSTEMD_LOG_TIME</varname></term>
+
+      <listitem><para id='log-time-body'>A boolean. If true, console log messages will be prefixed with a
+      timestamp.</para>
+
+      <para>This setting is only useful when messages are written directly to the terminal or a file, because
+      <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> and
+      other tools that display logs will attach timestamps based on the entry metadata on their own.</para>
+      </listitem>
+    </varlistentry>
+
+    <varlistentry id='log-location'>
+      <term><varname>$SYSTEMD_LOG_LOCATION</varname></term>
+
+      <listitem><para id='log-location-body'>A boolean. If true, messages will be prefixed with a filename
+      and line number in the source code where the message originates.</para>
+
+      <para>Note that the log location is often attached as metadata to journal entries anyway. Including it
+      directly in the message text can nevertheless be convenient when debugging programs.</para>
+      </listitem>
+    </varlistentry>
+
+    <varlistentry id='log-tid'>
+      <term><varname>$SYSTEMD_LOG_TID</varname></term>
+
+      <listitem><para id='log-tid-body'>A boolean. If true, messages will be prefixed with the current
+      numerical thread ID (TID).</para>
+
+      <para>Note that the this information is attached as metadata to journal entries anyway. Including it
+      directly in the message text can nevertheless be convenient when debugging programs.</para>
+      </listitem>
+    </varlistentry>
+
+    <varlistentry id='log-target'>
+      <term><varname>$SYSTEMD_LOG_TARGET</varname></term>
+
+      <listitem><para id='log-target-body'>The destination for log messages. One of
+      <constant>console</constant> (log to the attached tty), <constant>console-prefixed</constant> (log to
+      the attached tty but with prefixes encoding the log level and "facility", see <citerefentry
+      project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <constant>kmsg</constant> (log to the kernel circular log buffer), <constant>journal</constant> (log to
+      the journal), <constant>journal-or-kmsg</constant> (log to the journal if available, and to kmsg
+      otherwise), <constant>auto</constant> (determine the appropriate log target automatically, the default),
+      <constant>null</constant> (disable log output).</para>
+      <!-- <constant>syslog</constant>, <constant>syslog-or-kmsg</constant> are deprecated -->
+      </listitem>
+    </varlistentry>
+
+    <varlistentry id='log-ratelimit-kmsg'>
+      <term><varname>$SYSTEMD_LOG_RATELIMIT_KMSG</varname></term>
+
+      <listitem><para id='log-ratelimit-kmsg-body'> Whether to ratelimit kmsg or not. Takes a boolean.
+      Defaults to <literal>true</literal>. If disabled, systemd will not ratelimit messages written to kmsg.
+      </para></listitem>
+    </varlistentry>
+
+    <varlistentry id='pager'>
+      <term><varname>$SYSTEMD_PAGER</varname></term>
+
+      <listitem><para>Pager to use when <option>--no-pager</option> is not given; overrides
+      <varname>$PAGER</varname>. If neither <varname>$SYSTEMD_PAGER</varname> nor <varname>$PAGER</varname> are set, a
+      set of well-known pager implementations are tried in turn, including
+      <citerefentry project='man-pages'><refentrytitle>less</refentrytitle><manvolnum>1</manvolnum></citerefentry> and
+      <citerefentry project='man-pages'><refentrytitle>more</refentrytitle><manvolnum>1</manvolnum></citerefentry>, until one is found. If
+      no pager implementation is discovered no pager is invoked. Setting this environment variable to an empty string
+      or the value <literal>cat</literal> is equivalent to passing <option>--no-pager</option>.</para>
+
+      <para>Note: if <varname>$SYSTEMD_PAGERSECURE</varname> is not set, <varname>$SYSTEMD_PAGER</varname>
+      (as well as <varname>$PAGER</varname>) will be silently ignored.</para></listitem>
+    </varlistentry>
+
+    <varlistentry id='less'>
+      <term><varname>$SYSTEMD_LESS</varname></term>
+
+      <listitem><para>Override the options passed to <command>less</command> (by default
+      <literal>FRSXMK</literal>).</para>
+
+      <para>Users might want to change two options in particular:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><option>K</option></term>
+
+          <para>This option instructs the pager to exit immediately when
+          <keycombo><keycap>Ctrl</keycap><keycap>C</keycap></keycombo> is pressed. To allow
+          <command>less</command> to handle <keycombo><keycap>Ctrl</keycap><keycap>C</keycap></keycombo>
+          itself to switch back to the pager command prompt, unset this option.</para>
+
+          <para>If the value of <varname>$SYSTEMD_LESS</varname> does not include <literal>K</literal>,
+          and the pager that is invoked is <command>less</command>,
+          <keycombo><keycap>Ctrl</keycap><keycap>C</keycap></keycombo> will be ignored by the
+          executable, and needs to be handled by the pager.</para>
+        </varlistentry>
+
+        <varlistentry>
+          <term><option>X</option></term>
+
+          <para>This option instructs the pager to not send termcap initialization and deinitialization
+          strings to the terminal. It is set by default to allow command output to remain visible in the
+          terminal even after the pager exits. Nevertheless, this prevents some pager functionality from
+          working, in particular paged output cannot be scrolled with the mouse.</para>
+        </varlistentry>
+      </variablelist>
+
+      <para>See
+      <citerefentry project='man-pages'><refentrytitle>less</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+      for more discussion.</para></listitem>
+    </varlistentry>
+
+    <varlistentry id='lesscharset'>
+      <term><varname>$SYSTEMD_LESSCHARSET</varname></term>
+
+      <listitem><para>Override the charset passed to <command>less</command> (by default <literal>utf-8</literal>, if
+      the invoking terminal is determined to be UTF-8 compatible).</para></listitem>
+    </varlistentry>
+
+    <varlistentry id='lesssecure'>
+      <term><varname>$SYSTEMD_PAGERSECURE</varname></term>
+
+      <listitem><para>Takes a boolean argument. When true, the "secure" mode of the pager is enabled; if
+      false, disabled. If <varname>$SYSTEMD_PAGERSECURE</varname> is not set at all, secure mode is enabled
+      if the effective UID is not the same as the owner of the login session, see
+      <citerefentry project='man-pages'><refentrytitle>geteuid</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+      and <citerefentry><refentrytitle>sd_pid_get_owner_uid</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+      In secure mode, <option>LESSSECURE=1</option> will be set when invoking the pager, and the pager shall
+      disable commands that open or create new files or start new subprocesses. When
+      <varname>$SYSTEMD_PAGERSECURE</varname> is not set at all, pagers which are not known to implement
+      secure mode will not be used. (Currently only
+      <citerefentry project='man-pages'><refentrytitle>less</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+      implements secure mode.)</para>
+
+      <para>Note: when commands are invoked with elevated privileges, for example under <citerefentry
+      project='man-pages'><refentrytitle>sudo</refentrytitle><manvolnum>8</manvolnum></citerefentry> or
+      <citerefentry
+      project='die-net'><refentrytitle>pkexec</refentrytitle><manvolnum>1</manvolnum></citerefentry>, care
+      must be taken to ensure that unintended interactive features are not enabled. "Secure" mode for the
+      pager may be enabled automatically as describe above. Setting <varname>SYSTEMD_PAGERSECURE=0</varname>
+      or not removing it from the inherited environment allows the user to invoke arbitrary commands. Note
+      that if the <varname>$SYSTEMD_PAGER</varname> or <varname>$PAGER</varname> variables are to be
+      honoured, <varname>$SYSTEMD_PAGERSECURE</varname> must be set too. It might be reasonable to completely
+      disable the pager using <option>--no-pager</option> instead.</para></listitem>
+    </varlistentry>
+
+    <varlistentry id='colors'>
+      <term><varname>$SYSTEMD_COLORS</varname></term>
+
+      <listitem><para>Takes a boolean argument. When true, <command>systemd</command> and related utilities
+      will use colors in their output, otherwise the output will be monochrome. Additionally, the variable can
+      take one of the following special values: <literal>16</literal>, <literal>256</literal> to restrict the use
+      of colors to the base 16 or 256 ANSI colors, respectively. This can be specified to override the automatic
+      decision based on <varname>$TERM</varname> and what the console is connected to.</para></listitem>
+    </varlistentry>
+
+    <!-- This is not documented on purpose, because it is not clear if $NO_COLOR will become supported
+         widely enough. So let's provide support, but without advertising this.
+    <varlistentry id='no-color'>
+      <term><varname>$NO_COLOR</varname></term>
+
+      <listitem><para>If set (to any value), and <varname>$SYSTEMD_COLORS</varname> is not set, equivalent to
+      <option>SYSTEMD_COLORS=0</option>. See <ulink url="https://no-color.org/">no-color.org</ulink>.</para>
+      </listitem>
+    </varlistentry>
+    -->
+
+    <varlistentry id='urlify'>
+      <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>
+
+  </variablelist>
+</refsect1>
diff --git a/man/coredump.conf.xml b/man/coredump.conf.xml
new file mode 100644
index 0000000..61014d3
--- /dev/null
+++ b/man/coredump.conf.xml
@@ -0,0 +1,159 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="coredump.conf" conditional="ENABLE_COREDUMP"
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+  <refentryinfo>
+    <title>coredump.conf</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>coredump.conf</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>coredump.conf</refname>
+    <refname>coredump.conf.d</refname>
+    <refpurpose>Core dump storage configuration files</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>/etc/systemd/coredump.conf</filename></para>
+    <para><filename>/etc/systemd/coredump.conf.d/*.conf</filename></para>
+    <para><filename>/run/systemd/coredump.conf.d/*.conf</filename></para>
+    <para><filename>/usr/lib/systemd/coredump.conf.d/*.conf</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>These files configure the behavior of
+    <citerefentry><refentrytitle>systemd-coredump</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+    a handler for core dumps invoked by the kernel. Whether <command>systemd-coredump</command> is used
+    is determined by the kernel's
+    <varname>kernel.core_pattern</varname> <citerefentry project='man-pages'><refentrytitle>sysctl</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    setting. See
+    <citerefentry><refentrytitle>systemd-coredump</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    and
+    <citerefentry project='man-pages'><refentrytitle>core</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    pages for the details.</para>
+  </refsect1>
+
+  <xi:include href="standard-conf.xml" xpointer="main-conf" />
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>All options are configured in the
+    [Coredump] section:</para>
+
+    <variablelist class='config-directives'>
+
+      <varlistentry>
+        <term><varname>Storage=</varname></term>
+
+        <listitem><para>Controls where to store cores. One of <literal>none</literal>,
+        <literal>external</literal>, and <literal>journal</literal>. When <literal>none</literal>, the core
+        dumps may be logged (including the backtrace if possible), but not stored permanently. When
+        <literal>external</literal> (the default), cores will be stored in
+        <filename>/var/lib/systemd/coredump/</filename>.  When <literal>journal</literal>, cores will be
+        stored in the journal and rotated following normal journal rotation patterns.</para>
+
+        <para>When cores are stored in the journal, they might be compressed following journal compression
+        settings, see
+        <citerefentry><refentrytitle>journald.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+        When cores are stored externally, they will be compressed by default, see below.</para>
+
+        <para>Note that in order to process a coredump (i.e. extract a stack trace) the core must be written
+        to disk first. Thus, unless <varname>ProcessSizeMax=</varname> is set to 0 (see below), the core will
+        be written to <filename>/var/lib/systemd/coredump/</filename> either way (under a temporary filename,
+        or even in an unlinked file), <varname>Storage=</varname> thus only controls whether to leave it
+        there even after it was processed.</para>
+
+        <xi:include href="version-info.xml" xpointer="v215"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Compress=</varname></term>
+
+        <listitem><para>Controls compression for external
+        storage. Takes a boolean argument, which defaults to
+        <literal>yes</literal>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v215"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ProcessSizeMax=</varname></term>
+
+        <listitem><para>The maximum size in bytes of a core which will be processed. Core dumps exceeding
+        this size may be stored, but the stack trace will not be generated.  Like other sizes in this same
+        config file, the usual suffixes to the base of 1024 are allowed (B, K, M, G, T, P, and E). Defaults
+        to 1G on 32-bit systems, 32G on 64-bit systems.</para>
+
+        <para>Setting <varname>Storage=none</varname> and <varname>ProcessSizeMax=0</varname>
+        disables all coredump handling except for a log entry.</para>
+
+        <xi:include href="version-info.xml" xpointer="v215"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ExternalSizeMax=</varname></term>
+        <term><varname>JournalSizeMax=</varname></term>
+
+        <listitem><para>The maximum (compressed or uncompressed) size in bytes of a coredump to be saved in
+        separate files on disk (default: 1G on 32-bit systems, 32G on 64-bit systems) or in the journal
+        (default: 767M). Note that the journal service enforces a hard limit on journal log records of 767M,
+        and will ignore larger submitted log records. Hence, <varname>JournalSizeMax=</varname> may be
+        lowered relative to the default, but not increased. Unit suffixes are allowed just as in
+        <option>ProcessSizeMax=</option>.</para>
+
+        <para><varname>ExternalSizeMax=infinity</varname> sets the core size to unlimited.</para>
+
+        <xi:include href="version-info.xml" xpointer="v215"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>MaxUse=</varname></term>
+        <term><varname>KeepFree=</varname></term>
+
+        <listitem><para>Enforce limits on the disk space, specified
+        in bytes, taken up by externally stored core dumps.
+        Unit suffixes are allowed just as in <option>ProcessSizeMax=</option>.
+        <option>MaxUse=</option> makes
+        sure that old core dumps are removed as soon as the total disk
+        space taken up by core dumps grows beyond this limit (defaults
+        to 10% of the total disk size). <option>KeepFree=</option>
+        controls how much disk space to keep free at least (defaults
+        to 15% of the total disk size). Note that the disk space used
+        by core dumps might temporarily exceed these limits while
+        core dumps are processed. Note that old core dumps are also
+        removed based on time via
+        <citerefentry><refentrytitle>systemd-tmpfiles</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+        Set either value to 0 to turn off size-based cleanup.</para>
+
+        <xi:include href="version-info.xml" xpointer="v215"/></listitem>
+      </varlistentry>
+    </variablelist>
+
+    <para>The defaults for all values are listed as comments in the
+    template <filename>/etc/systemd/coredump.conf</filename> file that
+    is installed by default.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>coredumpctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-tmpfiles</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/coredumpctl.xml b/man/coredumpctl.xml
new file mode 100644
index 0000000..71eee17
--- /dev/null
+++ b/man/coredumpctl.xml
@@ -0,0 +1,500 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="coredumpctl" conditional='ENABLE_COREDUMP'
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>coredumpctl</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>coredumpctl</refentrytitle>
+    <manvolnum>1</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>coredumpctl</refname>
+    <refpurpose>Retrieve and process saved core dumps and metadata</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <cmdsynopsis>
+      <command>coredumpctl</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="req">COMMAND</arg>
+      <arg choice="opt" rep="repeat">PID|COMM|EXE|MATCH</arg>
+    </cmdsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>coredumpctl</command> is a tool that can be used to retrieve and process core
+    dumps and metadata which were saved by
+    <citerefentry><refentrytitle>systemd-coredump</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+    </para>
+  </refsect1>
+
+  <refsect1>
+    <title>Commands</title>
+
+    <para>The following commands are understood:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><command>list</command></term>
+
+        <listitem><para>List core dumps captured in the journal
+        matching specified characteristics. If no command is
+        specified, this is the implied default.</para>
+
+        <para>The output is designed to be human readable and contains a table with the following
+        columns:</para>
+        <variablelist>
+          <varlistentry>
+            <term>TIME</term>
+            <listitem><para>The timestamp of the crash, as reported by the kernel.</para>
+
+            <xi:include href="version-info.xml" xpointer="v233"/>
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term>PID</term>
+            <listitem><para>The identifier of the process that crashed.</para>
+
+            <xi:include href="version-info.xml" xpointer="v233"/>
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term>UID</term>
+            <term>GID</term>
+            <listitem><para>The user and group identifiers of the process that crashed.</para>
+
+            <xi:include href="version-info.xml" xpointer="v233"/>
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term>SIGNAL</term>
+            <listitem><para>The signal that caused the process to crash, when applicable.
+            </para>
+
+            <xi:include href="version-info.xml" xpointer="v233"/></listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term>COREFILE</term>
+            <listitem><para>Information whether the coredump was stored, and whether
+            it is still accessible: <literal>none</literal> means the core was
+            not stored, <literal>-</literal> means that it was not available (for
+            example because the process was not terminated by a signal),
+            <literal>present</literal> means that the core file is accessible by the
+            current user, <literal>journal</literal> means that the core was stored
+            in the <literal>journal</literal>, <literal>truncated</literal> is the
+            same as one of the previous two, but the core was too large and was not
+            stored in its entirety, <literal>error</literal> means that the core file
+            cannot be accessed, most likely because of insufficient permissions, and
+            <literal>missing</literal> means that the core was stored in a file, but
+            this file has since been removed.</para>
+
+            <xi:include href="version-info.xml" xpointer="v233"/></listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term>EXE</term>
+            <listitem><para>The full path to the executable. For backtraces of scripts
+            this is the name of the interpreter.</para>
+
+            <xi:include href="version-info.xml" xpointer="v233"/></listitem>
+          </varlistentry>
+        </variablelist>
+
+        <para>It's worth noting that different restrictions apply to
+        data saved in the journal and core dump files saved in
+        <filename>/var/lib/systemd/coredump</filename>, see overview in
+        <citerefentry><refentrytitle>systemd-coredump</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+        Thus it may very well happen that a particular core dump is still listed
+        in the journal while its corresponding core dump file has already been
+        removed.</para>
+
+        <xi:include href="version-info.xml" xpointer="v215"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>info</command></term>
+
+        <listitem><para>Show detailed information about the last core dump
+        or core dumps matching specified characteristics
+        captured in the journal.</para>
+
+        <xi:include href="version-info.xml" xpointer="v215"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>dump</command></term>
+
+        <listitem><para>Extract the last core dump matching specified
+        characteristics. The core dump will be written on standard
+        output, unless an output file is specified with
+        <option>--output=</option>. </para>
+
+        <xi:include href="version-info.xml" xpointer="v215"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>debug</command></term>
+
+        <listitem><para>Invoke a debugger on the last core dump
+        matching specified characteristics. By default,
+        <citerefentry project='man-pages'><refentrytitle>gdb</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+        will be used. This may be changed using the <option>--debugger=</option>
+        option or the <varname>$SYSTEMD_DEBUGGER</varname> environment
+        variable. Use the <option>--debugger-arguments=</option> option to pass extra
+        command line arguments to the debugger.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+    </variablelist>
+
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>The following options are understood:</para>
+
+    <variablelist>
+
+      <xi:include href="standard-options.xml" xpointer="help" />
+      <xi:include href="standard-options.xml" xpointer="version" />
+      <xi:include href="standard-options.xml" xpointer="no-pager" />
+      <xi:include href="standard-options.xml" xpointer="no-legend" />
+      <xi:include href="standard-options.xml" xpointer="json" />
+
+      <varlistentry>
+        <term><option>-1</option></term>
+
+        <listitem><para>Show information of the most recent core dump only, instead of listing all known core
+        dumps. Equivalent to <option>--reverse -n 1</option>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v215"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-n</option> <replaceable>INT</replaceable></term>
+
+        <listitem><para>Show at most the specified number of entries. The specified parameter must be an
+        integer greater or equal to 1.</para>
+
+        <xi:include href="version-info.xml" xpointer="v248"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-S</option></term>
+        <term><option>--since</option></term>
+
+        <listitem><para>Only print entries which are since the specified date.</para>
+
+        <xi:include href="version-info.xml" xpointer="v233"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-U</option></term>
+        <term><option>--until</option></term>
+
+        <listitem><para>Only print entries which are until the specified date.</para>
+
+        <xi:include href="version-info.xml" xpointer="v233"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-r</option></term>
+        <term><option>--reverse</option></term>
+
+        <listitem><para>Reverse output so that the newest entries are displayed first.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v233"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-F</option> <replaceable>FIELD</replaceable></term>
+        <term><option>--field=</option><replaceable>FIELD</replaceable></term>
+
+        <listitem><para>Print all possible data values the specified
+        field takes in matching core dump entries of the
+        journal.</para>
+
+        <xi:include href="version-info.xml" xpointer="v215"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-o</option> <replaceable>FILE</replaceable></term>
+        <term><option>--output=</option><replaceable>FILE</replaceable></term>
+
+        <listitem><para>Write the core to <option>FILE</option>.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v215"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--debugger=</option><replaceable>DEBUGGER</replaceable></term>
+
+        <listitem><para>Use the given debugger for the <command>debug</command>
+        command. If not given and <varname>$SYSTEMD_DEBUGGER</varname> is unset, then
+        <citerefentry project='man-pages'><refentrytitle>gdb</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+        will be used. </para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-A</option> <replaceable>ARGS</replaceable></term>
+        <term><option>--debugger-arguments=</option><replaceable>ARGS</replaceable></term>
+
+        <listitem><para>Pass the given <replaceable>ARGS</replaceable> as extra command line arguments
+        to the debugger. Quote as appropriate when <replaceable>ARGS</replaceable> contain whitespace.
+        (See Examples.)</para>
+
+        <xi:include href="version-info.xml" xpointer="v248"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--file=<replaceable>GLOB</replaceable></option></term>
+
+        <listitem><para>Takes a file glob as an argument. If
+        specified, coredumpctl will operate on the specified journal
+        files matching <replaceable>GLOB</replaceable> instead of the
+        default runtime and system journal paths. May be specified
+        multiple times, in which case files will be suitably
+        interleaved.</para>
+
+        <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-D</option> <replaceable>DIR</replaceable></term>
+        <term><option>--directory=</option><replaceable>DIR</replaceable></term>
+
+        <listitem><para>Use the journal files in the specified <option>DIR</option>.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v225"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--root=<replaceable>ROOT</replaceable></option></term>
+
+        <listitem><para>Use root directory <option>ROOT</option> when searching for coredumps.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--image=<replaceable>image</replaceable></option></term>
+
+        <listitem><para>Takes a path to a disk image file or block device node. If specified, all operations
+        are applied to file system in the indicated disk image. This option is similar to
+        <option>--root=</option>, but operates on file systems stored in disk images or block devices. The
+        disk image should either contain just a file system or a set of file systems within a GPT partition
+        table, following the <ulink url="https://uapi-group.org/specifications/specs/discoverable_partitions_specification">Discoverable Partitions
+        Specification</ulink>. For further information on supported disk images, see
+        <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s
+        switch of the same name.</para>
+
+        <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+      </varlistentry>
+
+      <xi:include href="standard-options.xml" xpointer="image-policy-open" />
+
+      <varlistentry>
+        <term><option>-q</option></term>
+        <term><option>--quiet</option></term>
+
+        <listitem><para>Suppresses informational messages about lack
+        of access to journal files and possible in-flight coredumps.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v233"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--all</option></term>
+
+        <listitem><para>Look at all available journal files in <filename>/var/log/journal/</filename>
+        (excluding journal namespaces) instead of only local ones.</para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Matching</title>
+
+    <para>A match can be:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><replaceable>PID</replaceable></term>
+
+        <listitem><para>Process ID of the
+        process that dumped
+        core. An integer.</para>
+
+        <xi:include href="version-info.xml" xpointer="v215"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><replaceable>COMM</replaceable></term>
+
+        <listitem><para>Name of the executable (matches
+        <option>COREDUMP_COMM=</option>). Must not contain slashes.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v215"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><replaceable>EXE</replaceable></term>
+
+        <listitem><para>Path to the executable (matches
+        <option>COREDUMP_EXE=</option>). Must contain at least one
+        slash. </para>
+
+        <xi:include href="version-info.xml" xpointer="v215"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><replaceable>MATCH</replaceable></term>
+
+        <listitem><para>General journalctl match filter, must contain an equals
+        sign (<literal>=</literal>). See
+        <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v215"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Exit status</title>
+    <para>On success, 0 is returned; otherwise, a non-zero failure
+    code is returned. Not finding any matching core dumps is treated as
+    failure.
+    </para>
+  </refsect1>
+
+  <refsect1>
+    <title>Environment</title>
+
+    <variablelist class='environment-variables'>
+      <varlistentry>
+        <term><varname>$SYSTEMD_DEBUGGER</varname></term>
+        <listitem><para>Use the given debugger for the <command>debug</command>
+        command. See the <option>--debugger=</option> option.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Examples</title>
+
+    <example>
+      <title>List all the core dumps of a program</title>
+
+      <programlisting>$ coredumpctl list /usr/lib64/firefox/firefox
+TIME       PID  UID  GID SIG     COREFILE EXE                         SIZE
+Tue …   8018 1000 1000 SIGSEGV missing  /usr/lib64/firefox/firefox     -
+Wed … 251609 1000 1000 SIGTRAP missing  /usr/lib64/firefox/firefox     -
+Fri … 552351 1000 1000 SIGSEGV present  /usr/lib64/firefox/firefox 28.7M
+</programlisting>
+
+       <para>The journal has three entries pertaining to <filename>/usr/lib64/firefox/firefox</filename>, and
+       only the last entry still has an available core file (in external storage on disk).</para>
+
+       <para>Note that <filename>coredumpctl</filename> needs access to the journal files to retrieve the
+       relevant entries from the journal. Thus, an unprivileged user will normally only see information about
+       crashing programs of this user.</para>
+    </example>
+
+    <example>
+      <title>Invoke <command>gdb</command> on the last core dump</title>
+
+      <programlisting>$ coredumpctl debug</programlisting>
+    </example>
+
+    <example>
+      <title>Use <command>gdb</command> to display full register info from the last core dump</title>
+
+      <programlisting>$ coredumpctl debug --debugger-arguments="-batch -ex 'info all-registers'"</programlisting>
+    </example>
+
+    <example>
+      <title>Show information about a core dump matched by PID</title>
+
+      <programlisting>$ coredumpctl info 6654
+           PID: 6654 (bash)
+           UID: 1000 (user)
+           GID: 1000 (user)
+        Signal: 11 (SEGV)
+     Timestamp: Mon 2021-01-01 00:00:01 CET (20s ago)
+  Command Line: bash -c $'kill -SEGV $$'
+    Executable: /usr/bin/bash
+ Control Group: /user.slice/user-1000.slice/…
+          Unit: user@1000.service
+     User Unit: vte-spawn-….scope
+         Slice: user-1000.slice
+     Owner UID: 1000 (user)
+       Boot ID: …
+    Machine ID: …
+      Hostname: …
+       Storage: /var/lib/systemd/coredump/core.bash.1000.….zst (present)
+  Size on Disk: 51.7K
+       Message: Process 130414 (bash) of user 1000 dumped core.
+
+                Stack trace of thread 130414:
+                #0  0x00007f398142358b kill (libc.so.6 + 0x3d58b)
+                #1  0x0000558c2c7fda09 kill_builtin (bash + 0xb1a09)
+                #2  0x0000558c2c79dc59 execute_builtin.lto_priv.0 (bash + 0x51c59)
+                #3  0x0000558c2c79709c execute_simple_command (bash + 0x4b09c)
+                #4  0x0000558c2c798408 execute_command_internal (bash + 0x4c408)
+                #5  0x0000558c2c7f6bdc parse_and_execute (bash + 0xaabdc)
+                #6  0x0000558c2c85415c run_one_command.isra.0 (bash + 0x10815c)
+                #7  0x0000558c2c77d040 main (bash + 0x31040)
+                #8  0x00007f398140db75 __libc_start_main (libc.so.6 + 0x27b75)
+                #9  0x0000558c2c77dd1e _start (bash + 0x31d1e)
+</programlisting>
+    </example>
+
+    <example>
+      <title>Extract the last core dump of /usr/bin/bar to a file named
+      <filename index="false">bar.coredump</filename></title>
+
+      <programlisting>$ coredumpctl -o bar.coredump dump /usr/bin/bar</programlisting>
+    </example>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd-coredump</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>coredump.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>gdb</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/crypttab.xml b/man/crypttab.xml
new file mode 100644
index 0000000..e94bf1c
--- /dev/null
+++ b/man/crypttab.xml
@@ -0,0 +1,1027 @@
+<?xml version="1.0"?>
+<!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!--
+  SPDX-License-Identifier: LGPL-2.1-or-later
+
+  This is based on crypttab(5) from Fedora's initscripts package, which in
+  turn is based on Debian's version.
+
+  The Red Hat version has been written by Miloslav Trmac <mitr@redhat.com>.
+-->
+<refentry id="crypttab" conditional='HAVE_LIBCRYPTSETUP' xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>crypttab</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>crypttab</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>crypttab</refname>
+    <refpurpose>Configuration for encrypted block devices</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>/etc/crypttab</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>The <filename>/etc/crypttab</filename> file describes
+    encrypted block devices that are set up during system boot.</para>
+
+    <para>Empty lines and lines starting with the <literal>#</literal>
+    character are ignored. Each of the remaining lines describes one
+    encrypted block device. Fields are delimited by white space.</para>
+
+    <para>Each line is in the form<programlisting><replaceable>volume-name</replaceable> <replaceable>encrypted-device</replaceable> <replaceable>key-file</replaceable> <replaceable>options</replaceable></programlisting>
+    The first two fields are mandatory, the remaining two are
+    optional.</para>
+
+    <para>Setting up encrypted block devices using this file supports four encryption modes: LUKS, TrueCrypt,
+    BitLocker and plain. See <citerefentry
+    project='die-net'><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry> for
+    more information about each mode. When no mode is specified in the options field and the block device
+    contains a LUKS signature, it is opened as a LUKS device; otherwise, it is assumed to be in raw dm-crypt
+    (plain mode) format.</para>
+
+    <para>The four fields of <filename>/etc/crypttab</filename> are defined as follows:</para>
+
+    <orderedlist>
+
+      <listitem><para>The first field contains the name of the resulting volume with decrypted data; its
+      block device is set up below <filename>/dev/mapper/</filename>.</para></listitem>
+
+      <listitem><para>The second field contains a path to the underlying block
+      device or file, or a specification of a block device via
+      <literal>UUID=</literal> followed by the UUID.</para></listitem>
+
+      <listitem><para>The third field specifies an absolute path to a file with the encryption
+      key. Optionally, the path may be followed by <literal>:</literal> and an
+      <filename>/etc/fstab</filename> style device specification (e.g. starting with
+      <literal>LABEL=</literal> or similar); in which case the path is taken relative to the specified
+      device's file system root. If the field is not present or is <literal>none</literal> or
+      <literal>-</literal>, a key file named after the volume to unlock (i.e. the first column of the line),
+      suffixed with <filename>.key</filename> is automatically loaded from the
+      <filename>/etc/cryptsetup-keys.d/</filename> and <filename>/run/cryptsetup-keys.d/</filename>
+      directories, if present. Otherwise, the password has to be manually entered during system boot. For
+      swap encryption, <filename>/dev/urandom</filename> may be used as key file, resulting in a randomized
+      key.</para>
+
+      <para>If the specified key file path refers to an <constant>AF_UNIX</constant> stream socket in the
+      file system, the key is acquired by connecting to the socket and reading it from the connection. This
+      allows the implementation of a service to provide key information dynamically, at the moment when it is
+      needed. For details see below.</para></listitem>
+
+      <listitem><para>The fourth field, if present, is a comma-delimited list of options. The supported
+      options are listed below.</para></listitem>
+    </orderedlist>
+  </refsect1>
+
+  <refsect1>
+    <title>Key Acquisition</title>
+
+    <para>Six different mechanisms for acquiring the decryption key or passphrase unlocking the encrypted
+    volume are supported. Specifically:</para>
+
+    <orderedlist>
+
+      <listitem><para>Most prominently, the user may be queried interactively during volume activation
+      (i.e. typically at boot), asking them to type in the necessary passphrases.</para></listitem>
+
+      <listitem><para>The (unencrypted) key may be read from a file on disk, possibly on removable media. The third field
+      of each line encodes the location, for details see above.</para></listitem>
+
+      <listitem><para>The (unencrypted) key may be requested from another service, by specifying an
+      <constant>AF_UNIX</constant> file system socket in place of a key file in the third field. For details
+      see above and below.</para></listitem>
+
+      <listitem><para>The key may be acquired via a PKCS#11 compatible hardware security token or
+      smartcard. In this case an encrypted key is stored on disk/removable media, acquired via
+      <constant>AF_UNIX</constant>, or stored in the LUKS2 JSON token metadata header. The encrypted key is
+      then decrypted by the PKCS#11 token with an RSA key stored on it, and then used to unlock the encrypted
+      volume. Use the <option>pkcs11-uri=</option> option described below to use this mechanism.</para></listitem>
+
+      <listitem><para>Similarly, the key may be acquired via a FIDO2 compatible hardware security token
+      (which must implement the "hmac-secret" extension). In this case a key generated randomly during
+      enrollment is stored on disk/removable media, acquired via <constant>AF_UNIX</constant>, or stored in
+      the LUKS2 JSON token metadata header. The random key is hashed via a keyed hash function (HMAC) on the
+      FIDO2 token, using a secret key stored on the token that never leaves it. The resulting hash value is
+      then used as key to unlock the encrypted volume. Use the <option>fido2-device=</option> option
+      described below to use this mechanism.</para></listitem>
+
+      <listitem><para>Similarly, the key may be acquired via a TPM2 security chip. In this case a (during
+      enrollment) randomly generated key — encrypted by an asymmetric key derived from the TPM2 chip's seed
+      key — is stored on disk/removable media, acquired via <constant>AF_UNIX</constant>, or stored in the
+      LUKS2 JSON token metadata header. Use the <option>tpm2-device=</option> option described below to use
+      this mechanism.</para></listitem>
+    </orderedlist>
+
+    <para>For the latter five mechanisms the source for the key material used for unlocking the volume is
+    primarily configured in the third field of each <filename>/etc/crypttab</filename> line, but may also
+    configured in <filename>/etc/cryptsetup-keys.d/</filename> and
+    <filename>/run/cryptsetup-keys.d/</filename> (see above) or in the LUKS2 JSON token header (in case of
+    the latter three). Use the
+    <citerefentry><refentrytitle>systemd-cryptenroll</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    tool to enroll PKCS#11, FIDO2 and TPM2 devices in LUKS2 volumes.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Supported Options</title>
+
+    <para>The following options may be used in the fourth field of each line:</para>
+
+    <variablelist class='fstab-options'>
+
+      <varlistentry>
+        <term><option>cipher=</option></term>
+
+        <listitem><para>Specifies the cipher to use. See <citerefentry
+        project='die-net'><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        for possible values and the default value of this option. A cipher with unpredictable IV values, such
+        as <literal>aes-cbc-essiv:sha256</literal>, is recommended. Embedded commas in the cipher
+        specification need to be escaped by preceding them with a backslash, see example below.</para>
+
+        <xi:include href="version-info.xml" xpointer="v186"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>discard</option></term>
+
+        <listitem><para>Allow discard requests to be passed through the encrypted block
+        device. This improves performance on SSD storage but has security implications.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v207"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>hash=</option></term>
+
+        <listitem><para>Specifies the hash to use for password
+        hashing. See
+        <citerefentry project='die-net'><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        for possible values and the default value of this
+        option.</para>
+
+        <xi:include href="version-info.xml" xpointer="v186"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>header=</option></term>
+
+        <listitem><para>Use a detached (separated) metadata device or file
+        where the header containing the master key(s) is stored. This
+        option is only relevant for LUKS and TrueCrypt/VeraCrypt devices. See
+        <citerefentry project='die-net'><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        for possible values and the default value of this option.</para>
+
+        <para>Optionally, the path may be followed by <literal>:</literal> and an
+        <filename>/etc/fstab</filename> device specification (e.g. starting with <literal>UUID=</literal> or
+        similar); in which case, the path is relative to the device file system root. The device gets mounted
+        automatically for LUKS device activation duration only.</para>
+
+        <xi:include href="version-info.xml" xpointer="v219"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>keyfile-offset=</option></term>
+
+        <listitem><para>Specifies the number of bytes to skip at the
+        start of the key file. See
+        <citerefentry project='die-net'><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        for possible values and the default value of this
+        option.</para>
+
+        <xi:include href="version-info.xml" xpointer="v187"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>keyfile-size=</option></term>
+
+        <listitem><para>Specifies the maximum number of bytes to read
+        from the key file. See
+        <citerefentry project='die-net'><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        for possible values and the default value of this option. This
+        option is ignored in plain encryption mode, as the key file
+        size is then given by the key size.</para>
+
+        <xi:include href="version-info.xml" xpointer="v188"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>keyfile-erase</option></term>
+
+        <listitem><para>If enabled, the specified key file is erased after the volume is activated or when
+        activation fails. This is in particular useful when the key file is only acquired transiently before
+        activation (e.g. via a file in <filename>/run/</filename>, generated by a service running before
+        activation), and shall be removed after use. Defaults to off.</para>
+
+        <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>key-slot=</option></term>
+
+        <listitem><para>Specifies the key slot to compare the
+        passphrase or key against. If the key slot does not match the
+        given passphrase or key, but another would, the setup of the
+        device will fail regardless. This option implies
+        <option>luks</option>. See
+        <citerefentry project='die-net'><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        for possible values. The default is to try all key slots in
+        sequential order.</para>
+
+        <xi:include href="version-info.xml" xpointer="v209"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>keyfile-timeout=</option></term>
+
+        <listitem><para> Specifies the timeout for the device on
+        which the key file resides or the device used as the key file,
+        and falls back to a password if it could not be accessed. See
+        <citerefentry><refentrytitle>systemd-cryptsetup-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        for key files on external devices.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v243"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>luks</option></term>
+
+        <listitem><para>Force LUKS mode. When this mode is used, the
+        following options are ignored since they are provided by the
+        LUKS header on the device: <option>cipher=</option>,
+        <option>hash=</option>,
+        <option>size=</option>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v186"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>bitlk</option></term>
+
+        <listitem><para>Decrypt BitLocker drive. Encryption parameters
+        are deduced by cryptsetup from BitLocker header.</para>
+
+        <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>_netdev</option></term>
+
+        <listitem><para>Marks this cryptsetup device as requiring network. It will be
+        started after the network is available, similarly to
+        <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        units marked with <option>_netdev</option>. The service unit to set up this device
+        will be ordered between <filename>remote-fs-pre.target</filename> and
+        <filename>remote-cryptsetup.target</filename>, instead of
+        <filename>cryptsetup-pre.target</filename> and
+        <filename>cryptsetup.target</filename>.</para>
+
+        <para>Hint: if this device is used for a mount point that is specified in
+        <citerefentry project='man-pages'><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        the <option>_netdev</option> option should also be used for the mount
+        point. Otherwise, a dependency loop might be created where the mount point
+        will be pulled in by <filename>local-fs.target</filename>, while the
+        service to configure the network is usually only started <emphasis>after</emphasis>
+        the local file system has been mounted.</para>
+
+        <xi:include href="version-info.xml" xpointer="v235"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>noauto</option></term>
+
+        <listitem><para>This device will not be added to <filename>cryptsetup.target</filename>.
+        This means that it will not be automatically unlocked on boot, unless something else pulls
+        it in. In particular, if the device is used for a mount point, it'll be unlocked
+        automatically during boot, unless the mount point itself is also disabled with
+        <option>noauto</option>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v186"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>nofail</option></term>
+
+        <listitem><para>This device will not be a hard dependency of
+        <filename>cryptsetup.target</filename>. It'll still be pulled in and started, but the system
+        will not wait for the device to show up and be unlocked, and boot will not fail if this is
+        unsuccessful. Note that other units that depend on the unlocked device may still fail. In
+        particular, if the device is used for a mount point, the mount point itself also needs to
+        have the <option>nofail</option> option, or the boot will fail if the device is not unlocked
+        successfully.</para>
+
+        <xi:include href="version-info.xml" xpointer="v186"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>offset=</option></term>
+
+        <listitem><para>Start offset in the backend device, in 512-byte sectors. This
+        option is only relevant for plain devices.</para>
+
+        <xi:include href="version-info.xml" xpointer="v220"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>plain</option></term>
+
+        <listitem><para>Force plain encryption mode.</para>
+
+        <xi:include href="version-info.xml" xpointer="v186"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>read-only</option></term><term><option>readonly</option></term>
+
+        <listitem><para>Set up the encrypted block device in read-only
+        mode.</para>
+
+        <xi:include href="version-info.xml" xpointer="v186"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>same-cpu-crypt</option></term>
+
+        <listitem><para>Perform encryption using the same CPU that IO was submitted on. The default is to use
+        an unbound workqueue so that encryption work is automatically balanced between available CPUs.</para>
+
+        <para>This requires kernel 4.0 or newer.</para>
+
+        <xi:include href="version-info.xml" xpointer="v242"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>submit-from-crypt-cpus</option></term>
+
+        <listitem><para>Disable offloading writes to a separate thread after encryption. There are some
+        situations where offloading write requests from the encryption threads to a dedicated thread degrades
+        performance significantly. The default is to offload write requests to a dedicated thread because it
+        benefits the CFQ scheduler to have writes submitted using the same context.</para>
+
+        <para>This requires kernel 4.0 or newer.</para>
+
+        <xi:include href="version-info.xml" xpointer="v242"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>no-read-workqueue</option></term>
+
+        <listitem><para>Bypass dm-crypt internal workqueue and process read requests synchronously. The
+        default is to queue these requests and process them asynchronously.</para>
+
+        <para>This requires kernel 5.9 or newer.</para>
+
+        <xi:include href="version-info.xml" xpointer="v248"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><option>no-write-workqueue</option></term>
+
+        <listitem><para>Bypass dm-crypt internal workqueue and process write requests synchronously. The
+        default is to queue these requests and process them asynchronously.</para>
+
+        <para>This requires kernel 5.9 or newer.</para>
+
+        <xi:include href="version-info.xml" xpointer="v248"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>skip=</option></term>
+
+        <listitem><para>How many 512-byte sectors of the encrypted data to skip at the
+        beginning. This is different from the <option>offset=</option> option with respect
+        to the sector numbers used in initialization vector (IV) calculation. Using
+        <option>offset=</option> will shift the IV calculation by the same negative
+        amount. Hence, if <option>offset=<replaceable>n</replaceable></option> is given,
+        sector <replaceable>n</replaceable> will get a sector number of 0 for the IV
+        calculation. Using <option>skip=</option> causes sector
+        <replaceable>n</replaceable> to also be the first sector of the mapped device, but
+        with its number for IV generation being <replaceable>n</replaceable>.</para>
+
+        <para>This option is only relevant for plain devices.</para>
+
+        <xi:include href="version-info.xml" xpointer="v220"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>size=</option></term>
+
+        <listitem><para>Specifies the key size in bits. See
+        <citerefentry project='die-net'><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        for possible values and the default value of this
+        option.</para>
+
+        <xi:include href="version-info.xml" xpointer="v186"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>sector-size=</option></term>
+
+        <listitem><para>Specifies the sector size in bytes. See
+        <citerefentry project='die-net'><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        for possible values and the default value of this
+        option.</para>
+
+        <xi:include href="version-info.xml" xpointer="v240"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>swap</option></term>
+
+        <listitem><para>The encrypted block device will be used as a
+        swap device, and will be formatted accordingly after setting
+        up the encrypted block device, with
+        <citerefentry project='man-pages'><refentrytitle>mkswap</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+        This option implies <option>plain</option>.</para>
+
+        <para>WARNING: Using the <option>swap</option> option will
+        destroy the contents of the named partition during every boot,
+        so make sure the underlying block device is specified
+        correctly.</para>
+
+        <xi:include href="version-info.xml" xpointer="v186"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>tcrypt</option></term>
+
+        <listitem><para>Use TrueCrypt encryption mode. When this mode
+        is used, the following options are ignored since they are
+        provided by the TrueCrypt header on the device or do not
+        apply:
+        <option>cipher=</option>,
+        <option>hash=</option>,
+        <option>keyfile-offset=</option>,
+        <option>keyfile-size=</option>,
+        <option>size=</option>.</para>
+
+        <para>When this mode is used, the passphrase is read from the
+        key file given in the third field. Only the first line of this
+        file is read, excluding the new line character.</para>
+
+        <para>Note that the TrueCrypt format uses both passphrase and
+        key files to derive a password for the volume. Therefore, the
+        passphrase and all key files need to be provided. Use
+        <option>tcrypt-keyfile=</option> to provide the absolute path
+        to all key files. When using an empty passphrase in
+        combination with one or more key files, use
+        <literal>/dev/null</literal> as the password file in the third
+        field.</para>
+
+        <xi:include href="version-info.xml" xpointer="v206"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>tcrypt-hidden</option></term>
+
+        <listitem><para>Use the hidden TrueCrypt volume. This option
+        implies <option>tcrypt</option>.</para>
+
+        <para>This will map the hidden volume that is inside of the
+        volume provided in the second field. Please note that there is
+        no protection for the hidden volume if the outer volume is
+        mounted instead. See
+        <citerefentry project='die-net'><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        for more information on this limitation.</para>
+
+        <xi:include href="version-info.xml" xpointer="v206"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>tcrypt-keyfile=</option></term>
+
+        <listitem><para>Specifies the absolute path to a key file to
+        use for a TrueCrypt volume. This implies
+        <option>tcrypt</option> and can be used more than once to
+        provide several key files.</para>
+
+        <para>See the entry for <option>tcrypt</option> on the
+        behavior of the passphrase and key files when using TrueCrypt
+        encryption mode.</para>
+
+        <xi:include href="version-info.xml" xpointer="v206"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>tcrypt-system</option></term>
+
+        <listitem><para>Use TrueCrypt in system encryption mode. This
+        option implies <option>tcrypt</option>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v206"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>tcrypt-veracrypt</option></term>
+
+        <listitem><para>Check for a VeraCrypt volume.  VeraCrypt is a fork of
+        TrueCrypt that is mostly compatible, but uses different, stronger key
+        derivation algorithms that cannot be detected without this flag.
+        Enabling this option could substantially slow down unlocking, because
+        VeraCrypt's key derivation takes much longer than TrueCrypt's.  This
+        option implies <option>tcrypt</option>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v232"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>veracrypt-pim=</option></term>
+
+        <listitem><para>Specifies a custom Personal Iteration Multiplier (PIM)
+        value, which can range from 0..2147468 for standard veracrypt volumes
+        and 0..65535 for veracrypt system volumes. A value of 0 will imply the
+        VeraCrypt default.
+
+        This option is only effective when <option>tcrypt-veracrypt</option> is
+        set.</para>
+
+        <para>Note that VeraCrypt enforces a minimal allowed PIM value depending on the
+        password strength and the hash algorithm used for key derivation, however
+        <option>veracrypt-pim=</option> is not checked against these bounds.
+        See
+        <ulink url="https://www.veracrypt.fr/en/Personal%20Iterations%20Multiplier%20%28PIM%29.html">Veracrypt Personal Iterations Multiplier</ulink>
+        documentation for more information.</para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>timeout=</option></term>
+
+        <listitem><para>Specifies the timeout for querying for a
+        password. If no unit is specified, seconds is used. Supported
+        units are s, ms, us, min, h, d. A timeout of 0 waits
+        indefinitely (which is the default).</para>
+
+        <xi:include href="version-info.xml" xpointer="v186"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>tmp=</option></term>
+
+        <listitem><para>The encrypted block device will be prepared for using it as
+        <filename>/tmp/</filename>; it will be formatted using <citerefentry
+        project='man-pages'><refentrytitle>mkfs</refentrytitle><manvolnum>8</manvolnum></citerefentry>. Takes
+        a file system type as argument, such as <literal>ext4</literal>, <literal>xfs</literal> or
+        <literal>btrfs</literal>. If no argument is specified defaults to <literal>ext4</literal>. This
+        option implies <option>plain</option>.</para>
+
+        <para>WARNING: Using the <option>tmp</option> option will destroy the contents of the named partition
+        during every boot, so make sure the underlying block device is specified correctly.</para>
+
+        <xi:include href="version-info.xml" xpointer="v186"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>tries=</option></term>
+
+        <listitem><para>Specifies the maximum number of times the user
+        is queried for a password. The default is 3. If set to 0, the
+        user is queried for a password indefinitely.</para>
+
+        <xi:include href="version-info.xml" xpointer="v186"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>headless=</option></term>
+
+        <listitem><para>Takes a boolean argument, defaults to false. If true, never query interactively
+        for the password/PIN. Useful for headless systems.</para>
+
+        <xi:include href="version-info.xml" xpointer="v249"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>verify</option></term>
+
+        <listitem><para>If the encryption password is read from console, it has to be entered twice to
+        prevent typos.</para>
+
+        <xi:include href="version-info.xml" xpointer="v186"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>password-echo=yes|no|masked</option></term>
+
+        <listitem><para>Controls whether to echo passwords or security token PINs
+        that are read from console. Takes a boolean or the special string <literal>masked</literal>.
+        The default is <option>password-echo=masked</option>.</para>
+
+        <para>If enabled, the typed characters are echoed literally. If disabled,
+        the typed characters are not echoed in any form, the user will not get
+        feedback on their input. If set to <literal>masked</literal>, an asterisk
+        (<literal>*</literal>) is echoed for each character typed. Regardless of
+        which mode is chosen, if the user hits the tabulator key (<literal>↹</literal>)
+        at any time, or the backspace key (<literal>⌫</literal>) before any other
+        data has been entered, then echo is turned off.</para>
+
+        <xi:include href="version-info.xml" xpointer="v249"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>pkcs11-uri=</option></term>
+
+        <listitem><para>Takes either the special value <literal>auto</literal> or an <ulink
+        url="https://tools.ietf.org/html/rfc7512">RFC7512 PKCS#11 URI</ulink> pointing to a private RSA key
+        which is used to decrypt the encrypted key specified in the third column of the line. This is useful
+        for unlocking encrypted volumes through PKCS#11 compatible security tokens or smartcards. See below
+        for an example how to set up this mechanism for unlocking a LUKS2 volume with a YubiKey security
+        token.</para>
+
+        <para>If specified as <literal>auto</literal> the volume must be of type LUKS2 and must carry PKCS#11
+        security token metadata in its LUKS2 JSON token section. In this mode the URI and the encrypted key
+        are automatically read from the LUKS2 JSON token header. Use
+        <citerefentry><refentrytitle>systemd-cryptenroll</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+        as simple tool for enrolling PKCS#11 security tokens or smartcards in a way compatible with
+        <literal>auto</literal>. In this mode the third column of the line should remain empty (that is,
+        specified as <literal>-</literal>).</para>
+
+        <para>The specified URI can refer directly to a private RSA key stored on a token or alternatively
+        just to a slot or token, in which case a search for a suitable private RSA key will be performed.  In
+        this case if multiple suitable objects are found the token is refused. The encrypted key configured
+        in the third column of the line is passed as is (i.e. in binary form, unprocessed) to RSA
+        decryption. The resulting decrypted key is then Base64 encoded before it is used to unlock the LUKS
+        volume.</para>
+
+        <para>Use <command>systemd-cryptenroll --pkcs11-token-uri=list</command> to list all suitable PKCS#11
+        security tokens currently plugged in, along with their URIs.</para>
+
+        <para>Note that many newer security tokens that may be used as PKCS#11 security token typically also
+        implement the newer and simpler FIDO2 standard. Consider using <option>fido2-device=</option>
+        (described below) to enroll it via FIDO2 instead. Note that a security token enrolled via PKCS#11
+        cannot be used to unlock the volume via FIDO2, unless also enrolled via FIDO2, and vice
+        versa.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>fido2-device=</option></term>
+
+        <listitem><para>Takes either the special value <literal>auto</literal> or the path to a
+        <literal>hidraw</literal> device node (e.g. <filename>/dev/hidraw1</filename>) referring to a FIDO2
+        security token that implements the <literal>hmac-secret</literal> extension (most current hardware
+        security tokens do). See below for an example how to set up this mechanism for unlocking an encrypted
+        volume with a FIDO2 security token.</para>
+
+        <para>If specified as <literal>auto</literal> the FIDO2 token device is automatically discovered, as
+        it is plugged in.</para>
+
+        <para>FIDO2 volume unlocking requires a client ID hash (CID) to be configured via
+        <option>fido2-cid=</option> (see below) and a key to pass to the security token's HMAC functionality
+        (configured in the line's third column) to operate. If not configured and the volume is of type
+        LUKS2, the CID and the key are read from LUKS2 JSON token metadata instead. Use
+        <citerefentry><refentrytitle>systemd-cryptenroll</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+        as simple tool for enrolling FIDO2 security tokens, compatible with this automatic mode, which is
+        only available for LUKS2 volumes.</para>
+
+        <para>Use <command>systemd-cryptenroll --fido2-device=list</command> to list all suitable FIDO2
+        security tokens currently plugged in, along with their device nodes.</para>
+
+        <para>This option implements the following mechanism: the configured key is hashed via they HMAC
+        keyed hash function the FIDO2 device implements, keyed by a secret key embedded on the device. The
+        resulting hash value is Base64 encoded and used to unlock the LUKS2 volume. As it should not be
+        possible to extract the secret from the hardware token, it should not be possible to retrieve the
+        hashed key given the configured key — without possessing the hardware token.</para>
+
+        <para>Note that many security tokens that implement FIDO2 also implement PKCS#11, suitable for
+        unlocking volumes via the <option>pkcs11-uri=</option> option described above. Typically the newer,
+        simpler FIDO2 standard is preferable.</para>
+
+        <xi:include href="version-info.xml" xpointer="v248"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>fido2-cid=</option></term>
+
+        <listitem><para>Takes a Base64 encoded FIDO2 client ID to use for the FIDO2 unlock operation. If
+        specified, but <option>fido2-device=</option> is not, <option>fido2-device=auto</option> is
+        implied. If <option>fido2-device=</option> is used but <option>fido2-cid=</option> is not, the volume
+        must be of LUKS2 type, and the CID is read from the LUKS2 JSON token header. Use
+        <citerefentry><refentrytitle>systemd-cryptenroll</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+        for enrolling a FIDO2 token in the LUKS2 header compatible with this automatic
+        mode.</para>
+
+        <xi:include href="version-info.xml" xpointer="v248"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>fido2-rp=</option></term>
+
+        <listitem><para>Takes a string, configuring the FIDO2 Relying Party (rp) for the FIDO2 unlock
+        operation. If not specified <literal>io.systemd.cryptsetup</literal> is used, except if the LUKS2
+        JSON token header contains a different value. It should normally not be necessary to override
+        this.</para>
+
+        <xi:include href="version-info.xml" xpointer="v248"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>tpm2-device=</option></term>
+
+        <listitem><para>Takes either the special value <literal>auto</literal> or the path to a device node
+        (e.g. <filename>/dev/tpmrm0</filename>) referring to a TPM2 security chip. See below for an example
+        how to set up this mechanism for unlocking an encrypted volume with a TPM2 chip.</para>
+
+        <para>Use <option>tpm2-pcrs=</option> (see below) to configure the set of TPM2 PCRs to bind the
+        volume unlocking to. Use
+        <citerefentry><refentrytitle>systemd-cryptenroll</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+        as simple tool for enrolling TPM2 security chips in LUKS2 volumes.</para>
+
+        <para>If specified as <literal>auto</literal> the TPM2 device is automatically discovered. Use
+        <command>systemd-cryptenroll --tpm2-device=list</command> to list all suitable TPM2 devices currently
+        available, along with their device nodes.</para>
+
+        <para>This option implements the following mechanism: when enrolling a TPM2 device via
+        <command>systemd-cryptenroll</command> on a LUKS2 volume, a randomized key unlocking the volume is
+        generated on the host and loaded into the TPM2 chip where it is encrypted with an asymmetric
+        "primary" key pair derived from the TPM2's internal "seed" key. Neither the seed key nor the primary
+        key are permitted to ever leave the TPM2 chip — however, the now encrypted randomized key may. It is
+        saved in the LUKS2 volume JSON token header. When unlocking the encrypted volume, the primary key
+        pair is generated on the TPM2 chip again (which works as long as the chip's seed key is correctly
+        maintained by the TPM2 chip), which is then used to decrypt (on the TPM2 chip) the encrypted key from
+        the LUKS2 volume JSON token header saved there during enrollment. The resulting decrypted key is then
+        used to unlock the volume. When the randomized key is encrypted the current values of the selected
+        PCRs (see below) are included in the operation, so that different PCR state results in different
+        encrypted keys and the decrypted key can only be recovered if the same PCR state is
+        reproduced.</para>
+
+        <xi:include href="version-info.xml" xpointer="v248"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>tpm2-pcrs=</option></term>
+
+        <listitem><para>Takes a <literal>+</literal> separated list of numeric TPM2 PCR (i.e. "Platform
+        Configuration Register") indexes to bind the TPM2 volume unlocking to. This option is only useful
+        when TPM2 enrollment metadata is not available in the LUKS2 JSON token header already, the way
+        <command>systemd-cryptenroll</command> writes it there. If not used (and no metadata in the LUKS2
+        JSON token header defines it), defaults to a list of a single entry: PCR 7. Assign an empty string to
+        encode a policy that binds the key to no PCRs, making the key accessible to local programs regardless
+        of the current PCR state.</para>
+
+        <xi:include href="version-info.xml" xpointer="v248"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>tpm2-pin=</option></term>
+
+        <listitem><para>Takes a boolean argument, defaults to <literal>false</literal>. Controls whether
+        TPM2 volume unlocking is bound to a PIN in addition to PCRs. Similarly, this option is only useful
+        when TPM2 enrollment metadata is not available.</para>
+
+        <xi:include href="version-info.xml" xpointer="v251"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>tpm2-signature=</option></term>
+
+        <listitem><para>Takes an absolute path to a TPM2 PCR JSON signature file, as produced by the
+        <citerefentry><refentrytitle>systemd-measure</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+        tool. This permits locking LUKS2 volumes to any PCR values for which a valid signature matching a
+        public key specified at key enrollment time can be provided. See
+        <citerefentry><refentrytitle>systemd-cryptenroll</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+        for details on enrolling TPM2 PCR public keys. If this option is not specified but it is attempted to
+        unlock a LUKS2 volume with a signed TPM2 PCR enrollment a suitable signature file
+        <filename>tpm2-pcr-signature.json</filename> is searched for in <filename>/etc/systemd/</filename>,
+        <filename>/run/systemd/</filename>, <filename>/usr/lib/systemd/</filename> (in this
+        order).</para>
+
+        <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>tpm2-pcrlock=</option></term>
+
+        <listitem><para>Takes an absolute path to a TPM2 pcrlock policy file, as produced by the
+        <citerefentry><refentrytitle>systemd-pcrlock</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+        tool. This permits locking LUKS2 volumes to a local policy of allowed PCR values with
+        variants. See
+        <citerefentry><refentrytitle>systemd-cryptenroll</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+        for details on enrolling TPM2 pcrlock policies. If this option is not specified but it is attempted
+        to unlock a LUKS2 volume with a TPM2 pcrlock enrollment a suitable signature file
+        <filename>pcrlock.json</filename> is searched for in <filename>/run/systemd/</filename> and
+        <filename>/var/lib/systemd/</filename> (in this order).</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>tpm2-measure-pcr=</option></term>
+
+        <listitem><para>Controls whether to measure the volume key of the encrypted volume to a TPM2 PCR. If
+        set to "no" (which is the default) no PCR extension is done. If set to "yes" the volume key is
+        measured into PCR 15. If set to a decimal integer in the range 0…23 the volume key is measured into
+        the specified PCR. The volume key is measured along with the activated volume name and its UUID. This
+        functionality is particularly useful for the encrypted volume backing the root file system, as it
+        then allows later TPM objects to be securely bound to the root file system and hence the specific
+        installation.</para>
+
+        <xi:include href="version-info.xml" xpointer="v253"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>tpm2-measure-bank=</option></term>
+
+        <listitem><para>Selects one or more TPM2 PCR banks to measure the volume key into, as configured with
+        <option>tpm2-measure-pcr=</option> above. Multiple banks may be specified, separated by a colon
+        character. If not specified automatically determines available and used banks. Expects a message
+        digest name (e.g. <literal>sha1</literal>, <literal>sha256</literal>, …) as argument, to identify the
+        bank.</para>
+
+        <xi:include href="version-info.xml" xpointer="v253"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>token-timeout=</option></term>
+
+        <listitem><para>Specifies how long to wait at most for configured security devices (i.e. FIDO2,
+        PKCS#11, TPM2) to show up. Takes a time value in seconds (but other time units may be specified too,
+        see <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+        for supported formats). Defaults to 30s. Once the specified timeout elapsed authentication via
+        password is attempted. Note that this timeout applies to waiting for the security device to show up —
+        it does not apply to the PIN prompt for the device (should one be needed) or similar. Pass 0 to turn
+        off the time-out and wait forever.</para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>try-empty-password=</option></term>
+
+        <listitem><para>Takes a boolean argument. If enabled, right before asking the user for a password it
+        is first attempted to unlock the volume with an empty password. This is useful for systems that are
+        initialized with an encrypted volume with only an empty password set, which shall be replaced with a
+        suitable password during first boot, but after activation.</para>
+
+        <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>x-systemd.device-timeout=</option></term>
+
+        <listitem><para>Specifies how long systemd should wait for a block device to show up before
+        giving up on the entry. The argument is a time in seconds or explicitly specified units of
+        <literal>s</literal>, <literal>min</literal>, <literal>h</literal>, <literal>ms</literal>.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v216"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>x-initrd.attach</option></term>
+
+        <listitem><para>Setup this encrypted block device in the initrd, similarly to
+        <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        units marked with <option>x-initrd.mount</option>.</para>
+
+        <para>Although it's not necessary to mark the mount entry for the root file system with
+        <option>x-initrd.mount</option>, <option>x-initrd.attach</option> is still recommended with
+        the encrypted block device containing the root file system as otherwise systemd will
+        attempt to detach the device during the regular system shutdown while it's still in
+        use. With this option the device will still be detached but later after the root file
+        system is unmounted.</para>
+
+        <para>All other encrypted block devices that contain file systems mounted in the initrd should use
+        this option.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/>
+        </listitem>
+      </varlistentry>
+
+    </variablelist>
+
+    <para>At early boot and when the system manager configuration is
+    reloaded, this file is translated into native systemd units by
+    <citerefentry><refentrytitle>systemd-cryptsetup-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title><constant>AF_UNIX</constant> Key Files</title>
+
+    <para>If the key file path (as specified in the third column of <filename>/etc/crypttab</filename>
+    entries, see above) refers to an <constant>AF_UNIX</constant> stream socket in the file system, the key
+    is acquired by connecting to the socket and reading the key from the connection. The connection is made
+    from an <constant>AF_UNIX</constant> socket name in the abstract namespace, see <citerefentry
+    project='man-pages'><refentrytitle>unix</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
+    details. The source socket name is chosen according the following format:</para>
+
+    <programlisting><constant>NUL</constant> <replaceable>RANDOM</replaceable> /cryptsetup/ <replaceable>VOLUME</replaceable></programlisting>
+
+    <para>In other words: a <constant>NUL</constant> byte (as required for abstract namespace sockets),
+    followed by a random string (consisting of alphanumeric characters only), followed by the literal
+    string <literal>/cryptsetup/</literal>, followed by the name of the volume to acquire they key
+    for. For example, for the volume <literal>myvol</literal>:</para>
+
+    <programlisting>\0d7067f78d9827418/cryptsetup/myvol</programlisting>
+
+    <para>Services listening on the <constant>AF_UNIX</constant> stream socket may query the source socket
+    name with <citerefentry
+    project='man-pages'><refentrytitle>getpeername</refentrytitle><manvolnum>2</manvolnum></citerefentry>,
+    and use this to determine which key to send, allowing a single listening socket to serve keys for
+    multiple volumes. If the PKCS#11 logic is used (see above), the socket source name is picked in similar
+    fashion, except that the literal string <literal>/cryptsetup-pkcs11/</literal> is used. And similarly for
+    FIDO2 (<literal>/cryptsetup-fido2/</literal>) and TPM2 (<literal>/cryptsetup-tpm2/</literal>). A different
+    path component is used so that services providing key material know that the secret key was not requested
+    directly, but instead an encrypted key that will be decrypted via the PKCS#11/FIDO2/TPM2 logic to acquire
+    the final secret key.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Examples</title>
+    <example>
+      <title>/etc/crypttab example</title>
+      <para>Set up four encrypted block devices. One using LUKS for normal storage, another one for usage as
+      a swap device and two TrueCrypt volumes. For the fourth device, the option string is interpreted as two
+      options <literal>cipher=xchacha12,aes-adiantum-plain64</literal>,
+      <literal>keyfile-timeout=10s</literal>.</para>
+
+      <programlisting>luks       UUID=2505567a-9e27-4efe-a4d5-15ad146c258b
+swap       /dev/sda7       /dev/urandom       swap
+truecrypt  /dev/sda2       /etc/container_password  tcrypt
+hidden     /mnt/tc_hidden  /dev/null    tcrypt-hidden,tcrypt-keyfile=/etc/keyfile
+external   /dev/sda3       keyfile:LABEL=keydev keyfile-timeout=10s,cipher=xchacha12\,aes-adiantum-plain64
+</programlisting>
+    </example>
+
+    <example>
+      <title>Yubikey-based PKCS#11 Volume Unlocking Example</title>
+
+      <para>The PKCS#11 logic allows hooking up any compatible security token that is capable of storing RSA
+      decryption keys for unlocking an encrypted volume. Here's an example how to set up a Yubikey security
+      token for this purpose on a LUKS2 volume, using <citerefentry
+      project='debian'><refentrytitle>ykmap</refentrytitle><manvolnum>1</manvolnum></citerefentry> from the
+      yubikey-manager project to initialize the token and
+      <citerefentry><refentrytitle>systemd-cryptenroll</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+      to add it in the LUKS2 volume:</para>
+
+      <programlisting><xi:include href="yubikey-crypttab.sh" parse="text" /></programlisting>
+
+      <para>A few notes on the above:</para>
+
+      <itemizedlist>
+        <listitem><para>We use RSA2048, which is the longest key size current Yubikeys support</para></listitem>
+        <listitem><para>We use Yubikey key slot 9d, since that's apparently the keyslot to use for decryption purposes,
+        see
+        <ulink url="https://developers.yubico.com/PIV/Introduction/Certificate_slots.html">Yubico PIV certificate slots</ulink>.
+        </para></listitem>
+      </itemizedlist>
+    </example>
+
+    <example>
+      <title>FIDO2 Volume Unlocking Example</title>
+
+      <para>The FIDO2 logic allows using any compatible FIDO2 security token that implements the
+      <literal>hmac-secret</literal> extension for unlocking an encrypted volume. Here's an example how to
+      set up a FIDO2 security token for this purpose for a LUKS2 volume, using
+      <citerefentry><refentrytitle>systemd-cryptenroll</refentrytitle><manvolnum>1</manvolnum></citerefentry>:</para>
+
+      <programlisting><xi:include href="fido2-crypttab.sh" parse="text" /></programlisting>
+    </example>
+
+    <example>
+      <title>TPM2 Volume Unlocking Example</title>
+
+      <para>The TPM2 logic allows using any TPM2 chip supported by the Linux kernel for unlocking an
+      encrypted volume. Here's an example how to set up a TPM2 chip for this purpose for a LUKS2 volume,
+      using
+      <citerefentry><refentrytitle>systemd-cryptenroll</refentrytitle><manvolnum>1</manvolnum></citerefentry>:</para>
+
+      <programlisting><xi:include href="tpm2-crypttab.sh" parse="text" /></programlisting>
+    </example>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-cryptsetup@.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-cryptsetup-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-cryptenroll</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry project='die-net'><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>mkswap</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>mke2fs</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/custom-entities.ent.in b/man/custom-entities.ent.in
new file mode 100644
index 0000000..a854d11
--- /dev/null
+++ b/man/custom-entities.ent.in
@@ -0,0 +1,22 @@
+<?xml version="1.0" encoding="utf-8" ?>
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+<!ENTITY MOUNT_PATH "{{MOUNT_PATH}}">
+<!ENTITY UMOUNT_PATH "{{UMOUNT_PATH}}">
+<!ENTITY SYSTEM_GENERATOR_DIR "{{SYSTEM_GENERATOR_DIR}}">
+<!ENTITY USER_GENERATOR_DIR "{{USER_GENERATOR_DIR}}">
+<!ENTITY SYSTEM_ENV_GENERATOR_DIR "{{SYSTEM_ENV_GENERATOR_DIR}}">
+<!ENTITY USER_ENV_GENERATOR_DIR "{{USER_ENV_GENERATOR_DIR}}">
+<!ENTITY CERTIFICATE_ROOT "{{CERTIFICATE_ROOT}}">
+<!ENTITY FALLBACK_HOSTNAME "{{FALLBACK_HOSTNAME}}">
+<!ENTITY MEMORY_ACCOUNTING_DEFAULT "{{ 'yes' if MEMORY_ACCOUNTING_DEFAULT else 'no' }}">
+<!ENTITY KILL_USER_PROCESSES "{{ 'yes' if KILL_USER_PROCESSES else 'no' }}">
+<!ENTITY DEBUGTTY "{{DEBUGTTY}}">
+<!ENTITY RC_LOCAL_PATH "{{RC_LOCAL_PATH}}">
+<!ENTITY HIGH_RLIMIT_NOFILE "{{HIGH_RLIMIT_NOFILE}}">
+<!ENTITY DEFAULT_DNSSEC_MODE "{{DEFAULT_DNSSEC_MODE_STR}}">
+<!ENTITY DEFAULT_DNS_OVER_TLS_MODE "{{DEFAULT_DNS_OVER_TLS_MODE_STR}}">
+<!ENTITY DEFAULT_TIMEOUT "{{DEFAULT_TIMEOUT_SEC}} s">
+<!ENTITY DEFAULT_USER_TIMEOUT "{{DEFAULT_USER_TIMEOUT_SEC}} s">
+<!ENTITY DEFAULT_KEYMAP "{{SYSTEMD_DEFAULT_KEYMAP}}">
+<!ENTITY fedora_latest_version "38">
+<!ENTITY fedora_cloud_release "1.6">
diff --git a/man/custom-html.xsl b/man/custom-html.xsl
new file mode 100644
index 0000000..8b21e15
--- /dev/null
+++ b/man/custom-html.xsl
@@ -0,0 +1,318 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
+
+<xsl:import href="http://docbook.sourceforge.net/release/xsl/current/html/docbook.xsl"/>
+<!--
+  - The docbook stylesheet injects empty anchor tags into generated HTML, identified by an auto-generated ID.
+  - Ask the docbook stylesheet to generate reproducible output when generating (these) ID values.
+  - This makes the output of this stylesheet reproducible across identical invocations on the same input,
+  - which is an easy and significant win for achieving reproducible builds.
+  -
+  - It may be even better to strip the empty anchors from the document output in addition to turning on consistent IDs,
+  - for this stylesheet contains its own custom ID logic (for generating permalinks) already.
+ -->
+<xsl:param name="generate.consistent.ids" select="1"/>
+
+<!-- translate man page references to links to html pages -->
+<xsl:template match="citerefentry[not(@project)]">
+  <a>
+    <xsl:attribute name="href">
+      <xsl:value-of select="refentrytitle"/>
+      <xsl:text>.html#</xsl:text>
+      <xsl:value-of select="refentrytitle/@target"/>
+    </xsl:attribute>
+    <xsl:call-template name="inline.charseq"/>
+  </a>
+</xsl:template>
+
+<xsl:template match="citerefentry[@project='man-pages'] | citerefentry[manvolnum='2'] | citerefentry[manvolnum='4']">
+  <a>
+    <xsl:attribute name="href">
+      <xsl:text>https://man7.org/linux/man-pages/man</xsl:text>
+      <xsl:value-of select="manvolnum"/>
+      <xsl:text>/</xsl:text>
+      <xsl:value-of select="refentrytitle"/>
+      <xsl:text>.</xsl:text>
+      <xsl:value-of select="manvolnum"/>
+      <xsl:text>.html</xsl:text>
+    </xsl:attribute>
+    <xsl:call-template name="inline.charseq"/>
+  </a>
+</xsl:template>
+
+<xsl:template match="citerefentry[@project='die-net']">
+  <a>
+    <xsl:attribute name="href">
+      <xsl:text>http://linux.die.net/man/</xsl:text>
+      <xsl:value-of select="manvolnum"/>
+      <xsl:text>/</xsl:text>
+      <xsl:value-of select="refentrytitle"/>
+    </xsl:attribute>
+    <xsl:call-template name="inline.charseq"/>
+  </a>
+</xsl:template>
+
+<xsl:template match="citerefentry[@project='wireguard']">
+  <a>
+    <xsl:attribute name="href">
+      <xsl:text>https://git.zx2c4.com/WireGuard/about/src/tools/</xsl:text>
+      <xsl:value-of select="refentrytitle"/>
+      <xsl:text>.</xsl:text>
+      <xsl:value-of select="manvolnum"/>
+    </xsl:attribute>
+    <xsl:call-template name="inline.charseq"/>
+  </a>
+</xsl:template>
+
+<xsl:template match="citerefentry[@project='mankier']">
+  <a>
+    <xsl:attribute name="href">
+      <xsl:text>https://www.mankier.com/</xsl:text>
+      <xsl:value-of select="manvolnum"/>
+      <xsl:text>/</xsl:text>
+      <xsl:value-of select="refentrytitle"/>
+    </xsl:attribute>
+    <xsl:call-template name="inline.charseq"/>
+  </a>
+</xsl:template>
+
+<xsl:template match="citerefentry[@project='archlinux']">
+  <a>
+    <xsl:attribute name="href">
+      <xsl:text>https://www.archlinux.org/</xsl:text>
+      <xsl:value-of select="refentrytitle"/>
+      <xsl:text>/</xsl:text>
+      <xsl:value-of select="refentrytitle"/>
+      <xsl:text>.</xsl:text>
+      <xsl:value-of select="manvolnum"/>
+      <xsl:text>.html</xsl:text>
+    </xsl:attribute>
+    <xsl:call-template name="inline.charseq"/>
+  </a>
+</xsl:template>
+
+<xsl:template match="citerefentry[@project='debian']">
+  <a>
+    <xsl:attribute name="href">
+      <xsl:text>https://manpages.debian.org/unstable/</xsl:text>
+      <xsl:value-of select="refentrytitle"/>
+      <xsl:text>/</xsl:text>
+      <xsl:value-of select="refentrytitle"/>
+      <xsl:text>.</xsl:text>
+      <xsl:value-of select="manvolnum"/>
+      <xsl:text>.en.html</xsl:text>
+    </xsl:attribute>
+    <xsl:call-template name="inline.charseq"/>
+  </a>
+</xsl:template>
+
+<xsl:template match="citerefentry[@project='freebsd']">
+  <a>
+    <xsl:attribute name="href">
+      <xsl:text>https://www.freebsd.org/cgi/man.cgi?</xsl:text>
+      <xsl:value-of select="refentrytitle"/>
+      <xsl:text>(</xsl:text>
+      <xsl:value-of select="manvolnum"/>
+      <xsl:text>)</xsl:text>
+    </xsl:attribute>
+    <xsl:call-template name="inline.charseq"/>
+  </a>
+</xsl:template>
+
+<xsl:template match="citerefentry[@project='dbus']">
+  <a>
+    <xsl:attribute name="href">
+      <xsl:text>https://dbus.freedesktop.org/doc/</xsl:text>
+      <xsl:value-of select="refentrytitle"/>
+      <xsl:text>.</xsl:text>
+      <xsl:value-of select="manvolnum"/>
+      <xsl:text>.html</xsl:text>
+    </xsl:attribute>
+    <xsl:call-template name="inline.charseq"/>
+  </a>
+</xsl:template>
+
+<xsl:template match="citerefentry[@project='url']">
+  <a>
+    <xsl:attribute name="href">
+      <xsl:value-of select="refentrytitle/@url"/>
+    </xsl:attribute>
+    <xsl:call-template name="inline.charseq"/>
+  </a>
+</xsl:template>
+
+<!--
+  - helper template to do conflict resolution between various headings with the same inferred ID attribute/tag from the headerlink template
+  - this conflict resolution is necessary to prevent malformed HTML output (multiple ID attributes with the same value)
+  - and it fixes xsltproc warnings during compilation of HTML man pages
+  -
+  - A simple top-to-bottom numbering scheme is implemented for nodes with the same ID value to derive unique ID values for HTML output.
+  - It uses two parameters:
+      templateID  the proposed ID string to use which must be checked for conflicts
+      keyNode     the context node which 'produced' the given templateID.
+  -
+  - Conflicts are detected solely based on keyNode, templateID is not taken into account for that purpose.
+ -->
+<xsl:template name="generateID">
+  <!-- node which generatedID needs to assume as the 'source' of the ID -->
+  <xsl:param name="keyNode"/>
+  <!-- suggested value for generatedID output, a contextually meaningful ID string -->
+  <xsl:param name="templateID"/>
+  <xsl:variable name="conflictSource" select="preceding::refsect1/title|preceding::refsect1/info/title|
+					      preceding::refsect2/title|preceding::refsect2/info/title|
+					      preceding::varlistentry/term[1]"/>
+  <xsl:variable name="conflictCount" select="count($conflictSource[. = $keyNode])"/>
+  <xsl:choose>
+    <!-- special case conflictCount = 0 to preserve compatibility with URLs generated by previous versions of this XSL stylesheet where possible -->
+    <xsl:when test="$conflictCount = 0">
+      <xsl:value-of select="$templateID"/>
+    </xsl:when>
+    <xsl:otherwise>
+      <xsl:value-of select="concat($templateID, $conflictCount)"/>
+    </xsl:otherwise>
+  </xsl:choose>
+</xsl:template>
+
+<!--
+  - a helper template to abstract over the structure of generated subheading + permalink HTML output
+  - It helps reduce tedious repetition and groups all actual markup output (as opposed to URL/ID logic) in a single location.
+ -->
+<xsl:template name="permalink">
+  <xsl:param name="nodeType"/> <!-- local name of the element node to generate, e.g. 'h2' for <h2></h2> -->
+  <xsl:param name="nodeContent"/> <!-- nodeset to apply further templates to obtain the content of the subheading/term -->
+  <xsl:param name="linkTitle"/> <!-- value for title attribute of generated permalink, e.g. 'this is a permalink' -->
+
+  <!-- parameters passed to generateID template, otherwise unused. -->
+  <xsl:param name="keyNode"/>
+  <xsl:param name="templateID"/>
+
+  <!--
+    - If stable URLs with fragment markers (references to the ID) turn out not to be important:
+    - generatedID could simply take the value of generate-id(), and various other helper templates may be dropped entirely.
+    - Alternatively, if xsltproc is patched to generate reproducible generate-id() output, the same simplifications can be
+    - applied at the cost of breaking compatibility with URLs generated from output of previous versions of this stylesheet.
+   -->
+  <xsl:variable name="generatedID">
+    <xsl:call-template name="generateID">
+      <xsl:with-param name="keyNode" select="$keyNode"/>
+      <xsl:with-param name="templateID" select="$templateID"/>
+    </xsl:call-template>
+  </xsl:variable>
+
+  <xsl:element name="{$nodeType}">
+    <xsl:attribute name="id">
+      <xsl:value-of select="$generatedID"/>
+    </xsl:attribute>
+    <xsl:apply-templates select="$nodeContent"/>
+    <a class="headerlink" title="{$linkTitle}" href="#{$generatedID}">¶</a>
+  </xsl:element>
+</xsl:template>
+
+<!-- simple wrapper around permalink to avoid repeating common info for each level of subheading covered by the permalink logic (h2, h3) -->
+<xsl:template name="headerlink">
+  <xsl:param name="nodeType"/>
+  <xsl:call-template name="permalink">
+    <xsl:with-param name="nodeType" select="$nodeType"/>
+    <xsl:with-param name="linkTitle" select="'Permalink to this headline'"/>
+    <xsl:with-param name="nodeContent" select="node()"/>
+    <xsl:with-param name="keyNode" select="."/>
+    <!--
+      - To retain compatibility with IDs generated by previous versions of the template, inline.charseq must be called.
+      - The purpose of that template is to generate markup (according to docbook documentation its purpose is to mark/format something as plain text).
+      - The only reason to call this template is to get the auto-generated text such as brackets ([]) before flattening it.
+     -->
+    <xsl:with-param name="templateID">
+      <xsl:call-template name="inline.charseq"/>
+    </xsl:with-param>
+  </xsl:call-template>
+</xsl:template>
+
+<xsl:template match="refsect1/title|refsect1/info/title">
+  <!-- the ID is output in the block.object call for refsect1 -->
+  <xsl:call-template name="headerlink">
+    <xsl:with-param name="nodeType" select="'h2'"/>
+  </xsl:call-template>
+</xsl:template>
+
+<xsl:template match="refsect2/title|refsect2/info/title">
+  <xsl:call-template name="headerlink">
+    <xsl:with-param name="nodeType" select="'h3'"/>
+  </xsl:call-template>
+</xsl:template>
+
+<xsl:template match="varlistentry">
+  <xsl:call-template name="permalink">
+    <xsl:with-param name="nodeType" select="'dt'"/>
+    <xsl:with-param name="linkTitle" select="'Permalink to this term'"/>
+    <xsl:with-param name="nodeContent" select="term"/>
+    <xsl:with-param name="keyNode" select="term[1]"/>
+    <!--
+      - To retain compatibility with IDs generated by previous versions of the template, inline.charseq must be called.
+      - The purpose of that template is to generate markup (according to docbook documentation its purpose is to mark/format something as plain text).
+      - The only reason to call this template is to get the auto-generated text such as brackets ([]) before flattening it.
+     -->
+    <xsl:with-param name="templateID">
+      <xsl:call-template name="inline.charseq">
+	<xsl:with-param name="content" select="term[1]"/>
+      </xsl:call-template>
+    </xsl:with-param>
+  </xsl:call-template>
+  <dd>
+    <xsl:apply-templates select="listitem"/>
+  </dd>
+</xsl:template>
+
+
+<!-- add Index link at top of page -->
+<xsl:template name="user.header.content">
+  <style>
+    a.headerlink {
+      color: #c60f0f;
+      font-size: 0.8em;
+      padding: 0 4px 0 4px;
+      text-decoration: none;
+      visibility: hidden;
+    }
+
+    a.headerlink:hover {
+      background-color: #c60f0f;
+      color: white;
+    }
+
+    h1:hover > a.headerlink, h2:hover > a.headerlink, h3:hover > a.headerlink, dt:hover > a.headerlink {
+      visibility: visible;
+    }
+  </style>
+
+  <a>
+    <xsl:attribute name="href">
+      <xsl:text>index.html</xsl:text>
+    </xsl:attribute>
+    <xsl:text>Index </xsl:text>
+  </a>·
+  <a>
+    <xsl:attribute name="href">
+      <xsl:text>systemd.directives.html</xsl:text>
+    </xsl:attribute>
+    <xsl:text>Directives </xsl:text>
+  </a>
+
+  <span style="float:right">
+    <xsl:text>systemd </xsl:text>
+    <xsl:value-of select="$systemd.version"/>
+  </span>
+  <hr/>
+</xsl:template>
+
+<xsl:template match="literal">
+  <xsl:text>"</xsl:text>
+  <xsl:call-template name="inline.monoseq"/>
+  <xsl:text>"</xsl:text>
+</xsl:template>
+
+<!-- Switch things to UTF-8, ISO-8859-1 is soo yesteryear -->
+<xsl:output method="html" encoding="UTF-8" indent="no"/>
+
+</xsl:stylesheet>
diff --git a/man/custom-man.xsl b/man/custom-man.xsl
new file mode 100644
index 0000000..2ed361f
--- /dev/null
+++ b/man/custom-man.xsl
@@ -0,0 +1,49 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+
+<!--
+  SPDX-License-Identifier: LGPL-2.1-or-later
+-->
+
+<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
+                xmlns:exsl="http://exslt.org/common"
+                extension-element-prefixes="exsl"
+                version="1.0">
+
+<xsl:import href="http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl"/>
+
+<xsl:template name="top.comment" />
+
+<xsl:template name="TH.title.line">
+    <xsl:param name="title"/>
+    <xsl:param name="section"/>
+    <xsl:param name="extra1"/>
+    <xsl:param name="extra2"/>
+    <xsl:param name="extra3"/>
+
+    <xsl:call-template name="mark.subheading"/>
+    <xsl:text>.TH "</xsl:text>
+    <xsl:call-template name="string.upper">
+      <xsl:with-param name="string">
+        <xsl:value-of select="normalize-space($title)"/>
+      </xsl:with-param>
+    </xsl:call-template>
+    <xsl:text>" "</xsl:text>
+    <xsl:value-of select="normalize-space($section)"/>
+    <xsl:text>" "" "systemd </xsl:text>
+    <xsl:value-of select="$systemd.version"/>
+    <xsl:text>" "</xsl:text>
+    <xsl:value-of select="normalize-space($extra3)"/>
+    <xsl:text>"&#10;</xsl:text>
+    <xsl:call-template name="mark.subheading"/>
+</xsl:template>
+
+<xsl:template match="literal">
+  <xsl:if test="$man.hyphenate.computer.inlines = 0">
+    <xsl:call-template name="suppress.hyphenation"/>
+  </xsl:if>
+  <xsl:text>"</xsl:text>
+  <xsl:call-template name="inline.monoseq"/>
+  <xsl:text>"</xsl:text>
+</xsl:template>
+
+</xsl:stylesheet>
diff --git a/man/daemon.xml b/man/daemon.xml
new file mode 100644
index 0000000..8fa2506
--- /dev/null
+++ b/man/daemon.xml
@@ -0,0 +1,700 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="daemon">
+
+  <refentryinfo>
+    <title>daemon</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>daemon</refentrytitle>
+    <manvolnum>7</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>daemon</refname>
+    <refpurpose>Writing and packaging system daemons</refpurpose>
+  </refnamediv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>A daemon is a service process that runs in the background
+    and supervises the system or provides functionality to other
+    processes. Traditionally, daemons are implemented following a
+    scheme originating in SysV Unix. Modern daemons should follow a
+    simpler yet more powerful scheme (here called "new-style"
+    daemons), as implemented by
+    <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
+    This manual page covers both schemes, and in particular includes
+    recommendations for daemons that shall be included in the systemd
+    init system.</para>
+
+    <refsect2>
+      <title>SysV Daemons</title>
+
+      <para>When a traditional SysV daemon starts, it should execute
+      the following steps as part of the initialization. Note that
+      these steps are unnecessary for new-style daemons (see below),
+      and should only be implemented if compatibility with SysV is
+      essential.</para>
+
+      <orderedlist>
+        <listitem><para>Close all open file descriptors except
+        standard input, output, and error (i.e. the first three file
+        descriptors 0, 1, 2). This ensures that no accidentally passed
+        file descriptor stays around in the daemon process. On Linux,
+        this is best implemented by iterating through
+        <filename>/proc/self/fd</filename>, with a fallback of
+        iterating from file descriptor 3 to the value returned by
+        <function>getrlimit()</function> for
+        <constant>RLIMIT_NOFILE</constant>. </para></listitem>
+
+        <listitem><para>Reset all signal handlers to their default.
+        This is best done by iterating through the available signals
+        up to the limit of <constant>_NSIG</constant> and resetting
+        them to <constant>SIG_DFL</constant>.</para></listitem>
+
+        <listitem><para>Reset the signal mask
+        using
+        <function>sigprocmask()</function>.</para></listitem>
+
+        <listitem><para>Sanitize the environment block, removing or
+        resetting environment variables that might negatively impact
+        daemon runtime.</para></listitem>
+
+        <listitem><para>Call <function>fork()</function>, to create a
+        background process.</para></listitem>
+
+        <listitem><para>In the child, call
+        <function>setsid()</function> to detach from any terminal and
+        create an independent session.</para></listitem>
+
+        <listitem><para>In the child, call <function>fork()</function> again, to ensure that the daemon can
+        never re-acquire a terminal again. (This relevant if the program — and all its dependencies — does
+        not carefully specify `O_NOCTTY` on each and every single `open()` call that might potentially open a
+        TTY device node.)</para></listitem>
+
+        <listitem><para>Call <function>exit()</function> in the first
+        child, so that only the second child (the actual daemon
+        process) stays around. This ensures that the daemon process is
+        re-parented to init/PID 1, as all daemons should
+        be.</para></listitem>
+
+        <listitem><para>In the daemon process, connect
+        <filename>/dev/null</filename> to standard input, output, and
+        error.</para></listitem>
+
+        <listitem><para>In the daemon process, reset the umask to 0,
+        so that the file modes passed to <function>open()</function>,
+        <function>mkdir()</function> and suchlike directly control the
+        access mode of the created files and
+        directories.</para></listitem>
+
+        <listitem><para>In the daemon process, change the current
+        directory to the root directory (/), in order to avoid that
+        the daemon involuntarily blocks mount points from being
+        unmounted.</para></listitem>
+
+        <listitem><para>In the daemon process, write the daemon PID
+        (as returned by <function>getpid()</function>) to a PID file,
+        for example <filename index='false'>/run/foobar.pid</filename> (for a
+        hypothetical daemon "foobar") to ensure that the daemon cannot
+        be started more than once. This must be implemented in
+        race-free fashion so that the PID file is only updated when it
+        is verified at the same time that the PID previously stored in
+        the PID file no longer exists or belongs to a foreign
+        process.</para></listitem>
+
+        <listitem><para>In the daemon process, drop privileges, if
+        possible and applicable.</para></listitem>
+
+        <listitem><para>From the daemon process, notify the original
+        process started that initialization is complete. This can be
+        implemented via an unnamed pipe or similar communication
+        channel that is created before the first
+        <function>fork()</function> and hence available in both the
+        original and the daemon process.</para></listitem>
+
+        <listitem><para>Call <function>exit()</function> in the
+        original process. The process that invoked the daemon must be
+        able to rely on that this <function>exit()</function> happens
+        after initialization is complete and all external
+        communication channels are established and
+        accessible.</para></listitem>
+      </orderedlist>
+
+      <para>The BSD <function>daemon()</function> function should not
+      be used, as it implements only a subset of these steps.</para>
+
+      <para>A daemon that needs to provide compatibility with SysV
+      systems should implement the scheme pointed out above. However,
+      it is recommended to make this behavior optional and
+      configurable via a command line argument to ease debugging as
+      well as to simplify integration into systems using
+      systemd.</para>
+    </refsect2>
+
+    <refsect2>
+      <title>New-Style Daemons</title>
+
+      <para>Modern services for Linux should be implemented as
+      new-style daemons. This makes it easier to supervise and control
+      them at runtime and simplifies their implementation.</para>
+
+      <para>For developing a new-style daemon, none of the initialization steps recommended for SysV daemons
+      need to be implemented. New-style init systems such as systemd make all of them redundant. Moreover,
+      since some of these steps interfere with process monitoring, file descriptor passing, and other
+      functionality of the service manager, it is recommended not to execute them when run as new-style
+      service.</para>
+
+      <para>Note that new-style init systems guarantee execution of daemon processes in a clean process context: it is
+      guaranteed that the environment block is sanitized, that the signal handlers and mask is reset and that no
+      left-over file descriptors are passed. Daemons will be executed in their own session, with standard input
+      connected to <filename>/dev/null</filename> and standard output/error connected to the
+      <citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+      logging service, unless otherwise configured. The umask is reset.
+      </para>
+
+      <para>It is recommended for new-style daemons to implement the
+      following:</para>
+
+      <orderedlist>
+        <listitem><para>If applicable, the daemon should notify the service manager about startup completion
+        or status updates via the
+        <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+        interface, in particular <varname>READY=1</varname> and <varname>STATUS=…</varname>.
+        </para></listitem>
+
+        <listitem><para>If <constant>SIGTERM</constant> is received, shut down the daemon and exit cleanly.
+        A <varname>STOPPING=1</varname> notification should be sent via
+        <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+        </para></listitem>
+
+        <listitem><para>If <constant>SIGHUP</constant> is received, reload the configuration files, if this
+        applies. This should be combined with notifications via
+        <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>:
+        <varname>RELOADING=1</varname> and <varname>READY=1</varname>.
+        </para></listitem>
+
+        <listitem><para>Provide a correct exit code from the main daemon process, as this is used by the
+        service manager to detect service errors and problems. It is recommended to follow the exit code
+        scheme as defined in the <ulink
+        url="http://refspecs.linuxbase.org/LSB_3.1.1/LSB-Core-generic/LSB-Core-generic/iniscrptact.html">LSB
+        recommendations for SysV init scripts</ulink>.</para></listitem>
+
+        <listitem><para>If possible and applicable, expose the
+        daemon's control interface via the D-Bus IPC system and grab a
+        bus name as last step of initialization.</para></listitem>
+
+        <listitem><para>For integration in systemd, provide a
+        <filename>.service</filename> unit file that carries
+        information about starting, stopping and otherwise maintaining
+        the daemon. See
+        <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for details.</para></listitem>
+
+        <listitem><para>As much as possible, rely on the service manager's functionality to limit the access
+        of the daemon to files, services, and other resources, i.e. in the case of systemd, rely on systemd's
+        resource limit control instead of implementing your own, rely on systemd's privilege dropping code
+        instead of implementing it in the daemon, and so on. See
+        <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
+        the available controls.</para></listitem>
+
+        <listitem><para>If D-Bus is used, make your daemon
+        bus-activatable by supplying a D-Bus service activation
+        configuration file. This has multiple advantages: your daemon
+        may be started lazily on-demand; it may be started in parallel
+        to other daemons requiring it — which maximizes
+        parallelization and boot-up speed; your daemon can be
+        restarted on failure without losing any bus requests, as the
+        bus queues requests for activatable services. See below for
+        details.</para></listitem>
+
+        <listitem><para>If your daemon provides services to other
+        local processes or remote clients via a socket, it should be
+        made socket-activatable following the scheme pointed out
+        below. Like D-Bus activation, this enables on-demand starting
+        of services as well as it allows improved parallelization of
+        service start-up. Also, for state-less protocols (such as
+        syslog, DNS), a daemon implementing socket-based activation
+        can be restarted without losing a single request. See below
+        for details.</para></listitem>
+
+        <listitem><para>If the service opens sockets or other files on it own, and those file descriptors
+        shall survive a restart, the daemon should store them in the service manager via
+        <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry> with
+        <varname>FDSTORE=1</varname>..</para></listitem>
+
+        <listitem><para>Instead of using the <function>syslog()</function> call to log directly to the system
+        syslog service, a new-style daemon may choose to simply log to standard error via
+        <function>fprintf()</function>, which is then forwarded to syslog. If log levels are necessary, these
+        can be encoded by prefixing individual log lines with strings like <literal>&lt;4&gt;</literal> (for
+        log level 4 "WARNING" in the syslog priority scheme), following a similar style as the Linux kernel's
+        <function>printk()</function> level system. For details, see
+        <citerefentry><refentrytitle>sd-daemon</refentrytitle><manvolnum>3</manvolnum></citerefentry> and
+        <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
+
+        <listitem><para>As new-style daemons are invoked without a controlling TTY (but as their own session
+        leaders) care should be taken to always specify <constant>O_NOCTTY</constant> on
+        <citerefentry><refentrytitle>open</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+        calls that possibly reference a TTY device node, so that no controlling TTY is accidentally
+        acquired.</para></listitem>
+
+      </orderedlist>
+
+      <para>These recommendations are similar but not identical to the
+      <ulink
+      url="https://developer.apple.com/library/mac/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingLaunchdJobs.html">Apple
+      MacOS X Daemon Requirements</ulink>.</para>
+    </refsect2>
+
+  </refsect1>
+  <refsect1>
+    <title>Activation</title>
+
+    <para>New-style init systems provide multiple additional
+    mechanisms to activate services, as detailed below. It is common
+    that services are configured to be activated via more than one
+    mechanism at the same time. An example for systemd:
+    <filename>bluetoothd.service</filename> might get activated either
+    when Bluetooth hardware is plugged in, or when an application
+    accesses its programming interfaces via D-Bus. Or, a print server
+    daemon might get activated when traffic arrives at an IPP port, or
+    when a printer is plugged in, or when a file is queued in the
+    printer spool directory. Even for services that are intended to be
+    started on system bootup unconditionally, it is a good idea to
+    implement some of the various activation schemes outlined below,
+    in order to maximize parallelization. If a daemon implements a
+    D-Bus service or listening socket, implementing the full bus and
+    socket activation scheme allows starting of the daemon with its
+    clients in parallel (which speeds up boot-up), since all its
+    communication channels are established already, and no request is
+    lost because client requests will be queued by the bus system (in
+    case of D-Bus) or the kernel (in case of sockets) until the
+    activation is completed.</para>
+
+    <refsect2>
+      <title>Activation on Boot</title>
+
+      <para>Old-style daemons are usually activated exclusively on boot (and manually by the administrator)
+      via SysV init scripts, as detailed in the <ulink
+      url="http://refspecs.linuxbase.org/LSB_3.1.1/LSB-Core-generic/LSB-Core-generic/iniscrptact.html">LSB
+      Linux Standard Base Core Specification</ulink>. This method of activation is supported ubiquitously on
+      Linux init systems, both old-style and new-style systems. Among other issues, SysV init scripts have
+      the disadvantage of involving shell scripts in the boot process. New-style init systems generally use
+      updated versions of activation, both during boot-up and during runtime and using more minimal service
+      description files.</para>
+
+      <para>In systemd, if the developer or administrator wants to
+      make sure that a service or other unit is activated
+      automatically on boot, it is recommended to place a symlink to
+      the unit file in the <filename>.wants/</filename> directory of
+      either <filename>multi-user.target</filename> or
+      <filename>graphical.target</filename>, which are normally used
+      as boot targets at system startup. See
+      <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+      for details about the <filename>.wants/</filename> directories,
+      and
+      <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+      for details about the two boot targets.</para>
+
+    </refsect2>
+
+    <refsect2>
+      <title>Socket-Based Activation</title>
+
+      <para>In order to maximize the possible parallelization and robustness and simplify configuration and
+      development, it is recommended for all new-style daemons that communicate via listening sockets to use
+      socket-based activation. In a socket-based activation scheme, the creation and binding of the listening
+      socket as primary communication channel of daemons to local (and sometimes remote) clients is moved out
+      of the daemon code and into the service manager. Based on per-daemon configuration, the service manager
+      installs the sockets and then hands them off to the spawned process as soon as the respective daemon is
+      to be started. Optionally, activation of the service can be delayed until the first inbound traffic
+      arrives at the socket to implement on-demand activation of daemons. However, the primary advantage of
+      this scheme is that all providers and all consumers of the sockets can be started in parallel as soon
+      as all sockets are established. In addition to that, daemons can be restarted with losing only a
+      minimal number of client transactions, or even any client request at all (the latter is particularly
+      true for state-less protocols, such as DNS or syslog), because the socket stays bound and accessible
+      during the restart, and all requests are queued while the daemon cannot process them.</para>
+
+      <para>New-style daemons which support socket activation must be able to receive their sockets from the
+      service manager instead of creating and binding them themselves. For details about the programming
+      interfaces for this scheme provided by systemd, see
+      <citerefentry><refentrytitle>sd_listen_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry> and
+      <citerefentry><refentrytitle>sd-daemon</refentrytitle><manvolnum>3</manvolnum></citerefentry>. For
+      details about porting existing daemons to socket-based activation, see below. With minimal effort, it
+      is possible to implement socket-based activation in addition to traditional internal socket creation in
+      the same codebase in order to support both new-style and old-style init systems from the same daemon
+      binary.</para>
+
+      <para>systemd implements socket-based activation via
+      <filename>.socket</filename> units, which are described in
+      <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+      When configuring socket units for socket-based activation, it is
+      essential that all listening sockets are pulled in by the
+      special target unit <filename>sockets.target</filename>. It is
+      recommended to place a
+      <varname>WantedBy=sockets.target</varname> directive in the
+      [Install] section to automatically add such a
+      dependency on installation of a socket unit. Unless
+      <varname>DefaultDependencies=no</varname> is set, the necessary
+      ordering dependencies are implicitly created for all socket
+      units. For more information about
+      <filename>sockets.target</filename>, see
+      <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
+      It is not necessary or recommended to place any additional
+      dependencies on socket units (for example from
+      <filename>multi-user.target</filename> or suchlike) when one is
+      installed in <filename>sockets.target</filename>.</para>
+    </refsect2>
+
+    <refsect2>
+      <title>Bus-Based Activation</title>
+
+      <para>When the D-Bus IPC system is used for communication with clients, new-style daemons should use
+      bus activation so that they are automatically activated when a client application accesses their IPC
+      interfaces. This is configured in D-Bus service files (not to be confused with systemd service unit
+      files!). To ensure that D-Bus uses systemd to start-up and maintain the daemon, use the
+      <varname>SystemdService=</varname> directive in these service files to configure the matching systemd
+      service for a D-Bus service. e.g.: For a D-Bus service whose D-Bus activation file is named
+      <filename>org.freedesktop.RealtimeKit.service</filename>, make sure to set
+      <varname>SystemdService=rtkit-daemon.service</varname> in that file to bind it to the systemd service
+      <filename>rtkit-daemon.service</filename>. This is needed to make sure that the daemon is started in a
+      race-free fashion when activated via multiple mechanisms simultaneously.</para>
+    </refsect2>
+
+    <refsect2>
+      <title>Device-Based Activation</title>
+
+      <para>Often, daemons that manage a particular type of hardware
+      should be activated only when the hardware of the respective
+      kind is plugged in or otherwise becomes available. In a
+      new-style init system, it is possible to bind activation to
+      hardware plug/unplug events. In systemd, kernel devices
+      appearing in the sysfs/udev device tree can be exposed as units
+      if they are tagged with the string <literal>systemd</literal>.
+      Like any other kind of unit, they may then pull in other units
+      when activated (i.e. plugged in) and thus implement device-based
+      activation. systemd dependencies may be encoded in the udev
+      database via the <varname>SYSTEMD_WANTS=</varname> property. See
+      <citerefentry><refentrytitle>systemd.device</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+      for details. Often, it is nicer to pull in services from devices
+      only indirectly via dedicated targets. Example: Instead of
+      pulling in <filename>bluetoothd.service</filename> from all the
+      various bluetooth dongles and other hardware available, pull in
+      bluetooth.target from them and
+      <filename>bluetoothd.service</filename> from that target. This
+      provides for nicer abstraction and gives administrators the
+      option to enable <filename>bluetoothd.service</filename> via
+      controlling a <filename>bluetooth.target.wants/</filename>
+      symlink uniformly with a command like <command>enable</command>
+      of
+      <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+      instead of manipulating the udev ruleset.</para>
+    </refsect2>
+
+    <refsect2>
+      <title>Path-Based Activation</title>
+
+      <para>Often, runtime of daemons processing spool files or
+      directories (such as a printing system) can be delayed until
+      these file system objects change state, or become non-empty.
+      New-style init systems provide a way to bind service activation
+      to file system changes. systemd implements this scheme via
+      path-based activation configured in <filename>.path</filename>
+      units, as outlined in
+      <citerefentry><refentrytitle>systemd.path</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+    </refsect2>
+
+    <refsect2>
+      <title>Timer-Based Activation</title>
+
+      <para>Some daemons that implement clean-up jobs that are
+      intended to be executed in regular intervals benefit from
+      timer-based activation. In systemd, this is implemented via
+      <filename>.timer</filename> units, as described in
+      <citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+    </refsect2>
+
+    <refsect2>
+      <title>Other Forms of Activation</title>
+
+      <para>Other forms of activation have been suggested and implemented in some systems. However, there are
+      often simpler or better alternatives, or they can be put together of combinations of the schemes above.
+      Example: Sometimes, it appears useful to start daemons or <filename>.socket</filename> units when a
+      specific IP address is configured on a network interface, because network sockets shall be bound to the
+      address. However, an alternative to implement this is by utilizing the Linux
+      <constant>IP_FREEBIND</constant>/<constant>IPV6_FREEBIND</constant> socket option, as accessible via
+      <varname>FreeBind=yes</varname> in systemd socket files (see
+      <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
+      details). This option, when enabled, allows sockets to be bound to a non-local, not configured IP
+      address, and hence allows bindings to a particular IP address before it actually becomes available,
+      making such an explicit dependency to the configured address redundant. Another often suggested trigger
+      for service activation is low system load. However, here too, a more convincing approach might be to
+      make proper use of features of the operating system, in particular, the CPU or I/O scheduler of Linux.
+      Instead of scheduling jobs from userspace based on monitoring the OS scheduler, it is advisable to
+      leave the scheduling of processes to the OS scheduler itself. systemd provides fine-grained access to
+      the CPU and I/O schedulers. If a process executed by the service manager shall not negatively impact
+      the amount of CPU or I/O bandwidth available to other processes, it should be configured with
+      <varname>CPUSchedulingPolicy=idle</varname> and/or <varname>IOSchedulingClass=idle</varname>.
+      Optionally, this may be combined with timer-based activation to schedule background jobs during runtime
+      and with minimal impact on the system, and remove it from the boot phase itself.</para>
+    </refsect2>
+
+  </refsect1>
+  <refsect1>
+    <title>Integration with systemd</title>
+
+    <refsect2>
+      <title>Writing systemd Unit Files</title>
+
+      <para>When writing systemd unit files, it is recommended to
+      consider the following suggestions:</para>
+
+      <orderedlist>
+        <listitem><para>If possible, do not use the
+        <varname>Type=forking</varname> setting in service files. But
+        if you do, make sure to set the PID file path using
+        <varname>PIDFile=</varname>. See
+        <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for details.</para></listitem>
+
+        <listitem><para>If your daemon registers a D-Bus name on the
+        bus, make sure to use <varname>Type=dbus</varname> in the
+        service file if possible.</para></listitem>
+
+        <listitem><para>Make sure to set a good human-readable
+        description string with
+        <varname>Description=</varname>.</para></listitem>
+
+        <listitem><para>Do not disable
+        <varname>DefaultDependencies=</varname>, unless you really
+        know what you do and your unit is involved in early boot or
+        late system shutdown.</para></listitem>
+
+        <listitem><para>Normally, little if any dependencies should
+        need to be defined explicitly. However, if you do configure
+        explicit dependencies, only refer to unit names listed on
+        <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+        or names introduced by your own package to keep the unit file
+        operating system-independent.</para></listitem>
+
+        <listitem><para>Make sure to include an
+        [Install] section including installation
+        information for the unit file. See
+        <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for details. To activate your service on boot, make sure to
+        add a <varname>WantedBy=multi-user.target</varname> or
+        <varname>WantedBy=graphical.target</varname> directive. To
+        activate your socket on boot, make sure to add
+        <varname>WantedBy=sockets.target</varname>. Usually, you also
+        want to make sure that when your service is installed, your
+        socket is installed too, hence add
+        <varname>Also=foo.socket</varname> in your service file
+        <filename>foo.service</filename>, for a hypothetical program
+        <filename>foo</filename>.</para></listitem>
+
+      </orderedlist>
+    </refsect2>
+
+    <refsect2>
+      <title>Installing systemd Service Files</title>
+
+      <para>At the build installation time (e.g. <command>make
+      install</command> during package build), packages are
+      recommended to install their systemd unit files in the directory
+      returned by <command>pkg-config systemd
+      --variable=systemdsystemunitdir</command> (for system services)
+      or <command>pkg-config systemd
+      --variable=systemduserunitdir</command> (for user services).
+      This will make the services available in the system on explicit
+      request but not activate them automatically during boot.
+      Optionally, during package installation (e.g. <command>rpm
+      -i</command> by the administrator), symlinks should be created
+      in the systemd configuration directories via the
+      <command>enable</command> command of the
+      <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+      tool to activate them automatically on boot.</para>
+
+      <para>Packages using
+      <citerefentry project='die-net'><refentrytitle>autoconf</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+      are recommended to use a configure script
+      excerpt like the following to determine the
+      unit installation path during source
+      configuration:</para>
+
+      <programlisting>PKG_PROG_PKG_CONFIG()
+AC_ARG_WITH([systemdsystemunitdir],
+     [AS_HELP_STRING([--with-systemdsystemunitdir=DIR], [Directory for systemd service files])],,
+     [with_systemdsystemunitdir=auto])
+AS_IF([test "x$with_systemdsystemunitdir" = "xyes" -o "x$with_systemdsystemunitdir" = "xauto"], [
+     def_systemdsystemunitdir=$($PKG_CONFIG --variable=systemdsystemunitdir systemd)
+
+     AS_IF([test "x$def_systemdsystemunitdir" = "x"],
+   [AS_IF([test "x$with_systemdsystemunitdir" = "xyes"],
+    [AC_MSG_ERROR([systemd support requested but pkg-config unable to query systemd package])])
+    with_systemdsystemunitdir=no],
+   [with_systemdsystemunitdir="$def_systemdsystemunitdir"])])
+AS_IF([test "x$with_systemdsystemunitdir" != "xno"],
+      [AC_SUBST([systemdsystemunitdir], [$with_systemdsystemunitdir])])
+AM_CONDITIONAL([HAVE_SYSTEMD], [test "x$with_systemdsystemunitdir" != "xno"])</programlisting>
+
+      <para>This snippet allows automatic
+      installation of the unit files on systemd
+      machines, and optionally allows their
+      installation even on machines lacking
+      systemd. (Modification of this snippet for the
+      user unit directory is left as an exercise for the
+      reader.)</para>
+
+      <para>Additionally, to ensure that
+      <command>make distcheck</command> continues to
+      work, it is recommended to add the following
+      to the top-level <filename>Makefile.am</filename>
+      file in
+      <citerefentry project='die-net'><refentrytitle>automake</refentrytitle><manvolnum>1</manvolnum></citerefentry>-based
+      projects:</para>
+
+      <programlisting>AM_DISTCHECK_CONFIGURE_FLAGS = \
+  --with-systemdsystemunitdir=$$dc_install_base/$(systemdsystemunitdir)</programlisting>
+
+      <para>Finally, unit files should be installed in the system with an automake excerpt like the following:</para>
+
+      <programlisting>if HAVE_SYSTEMD
+systemdsystemunit_DATA = \
+  foobar.socket \
+  foobar.service
+endif</programlisting>
+
+      <para>In the
+      <citerefentry project='die-net'><refentrytitle>rpm</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+      <filename>.spec</filename> file, use snippets like the following
+      to enable/disable the service during
+      installation/deinstallation. This makes use of the RPM macros
+      shipped along systemd. Consult the packaging guidelines of your
+      distribution for details and the equivalent for other package
+      managers.</para>
+
+      <para>At the top of the file:</para>
+
+      <programlisting>BuildRequires: systemd
+%{?systemd_requires}</programlisting>
+
+      <para>And as scriptlets, further down:</para>
+
+      <programlisting>%post
+%systemd_post foobar.service foobar.socket
+
+%preun
+%systemd_preun foobar.service foobar.socket
+
+%postun
+%systemd_postun</programlisting>
+
+      <para>If the service shall be restarted during upgrades, replace
+      the <literal>%postun</literal> scriptlet above with the
+      following:</para>
+
+      <programlisting>%postun
+%systemd_postun_with_restart foobar.service</programlisting>
+
+      <para>Note that <literal>%systemd_post</literal> and
+      <literal>%systemd_preun</literal> expect the names of all units
+      that are installed/removed as arguments, separated by spaces.
+      <literal>%systemd_postun</literal> expects no arguments.
+      <literal>%systemd_postun_with_restart</literal> expects the
+      units to restart as arguments.</para>
+
+      <para>To facilitate upgrades from a package version that shipped
+      only SysV init scripts to a package version that ships both a
+      SysV init script and a native systemd service file, use a
+      fragment like the following:</para>
+
+      <programlisting>%triggerun -- foobar &lt; 0.47.11-1
+if /sbin/chkconfig --level 5 foobar ; then
+  /bin/systemctl --no-reload enable foobar.service foobar.socket >/dev/null 2>&amp;1 || :
+fi</programlisting>
+
+      <para>Where 0.47.11-1 is the first package version that includes
+      the native unit file. This fragment will ensure that the first
+      time the unit file is installed, it will be enabled if and only
+      if the SysV init script is enabled, thus making sure that the
+      enable status is not changed. Note that
+      <command>chkconfig</command> is a command specific to Fedora
+      which can be used to check whether a SysV init script is
+      enabled. Other operating systems will have to use different
+      commands here.</para>
+    </refsect2>
+  </refsect1>
+
+  <refsect1>
+    <title>Porting Existing Daemons</title>
+
+    <para>Since new-style init systems such as systemd are compatible
+    with traditional SysV init systems, it is not strictly necessary
+    to port existing daemons to the new style. However, doing so
+    offers additional functionality to the daemons as well as
+    simplifying integration into new-style init systems.</para>
+
+    <para>To port an existing SysV compatible daemon, the following
+    steps are recommended:</para>
+
+    <orderedlist>
+      <listitem><para>If not already implemented, add an optional
+      command line switch to the daemon to disable daemonization. This
+      is useful not only for using the daemon in new-style init
+      systems, but also to ease debugging.</para></listitem>
+
+      <listitem><para>If the daemon offers interfaces to other software running on the local system via local
+      <constant>AF_UNIX</constant> sockets, consider implementing socket-based activation (see above).
+      Usually, a minimal patch is sufficient to implement this: Extend the socket creation in the daemon code
+      so that
+      <citerefentry><refentrytitle>sd_listen_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry> is
+      checked for already passed sockets first. If sockets are passed (i.e. when
+      <function>sd_listen_fds()</function> returns a positive value), skip the socket creation step and use
+      the passed sockets. Secondly, ensure that the file system socket nodes for local
+      <constant>AF_UNIX</constant> sockets used in the socket-based activation are not removed when the
+      daemon shuts down, if sockets have been passed. Third, if the daemon normally closes all remaining open
+      file descriptors as part of its initialization, the sockets passed from the service manager must be
+      spared. Since new-style init systems guarantee that no left-over file descriptors are passed to
+      executed processes, it might be a good choice to simply skip the closing of all remaining open file
+      descriptors if sockets are passed.</para></listitem>
+
+      <listitem><para>Write and install a systemd unit file for the
+      service (and the sockets if socket-based activation is used, as
+      well as a path unit file, if the daemon processes a spool
+      directory), see above for details.</para></listitem>
+
+      <listitem><para>If the daemon exposes interfaces via D-Bus,
+      write and install a D-Bus activation file for the service, see
+      above for details.</para></listitem>
+    </orderedlist>
+  </refsect1>
+
+  <refsect1>
+    <title>Placing Daemon Data</title>
+
+    <para>It is recommended to follow the general guidelines for
+    placing package files, as discussed in
+    <citerefentry><refentrytitle>file-hierarchy</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-daemon</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_listen_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>daemon</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>file-hierarchy</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/directives-template.xml b/man/directives-template.xml
new file mode 100644
index 0000000..0b6ee21
--- /dev/null
+++ b/man/directives-template.xml
@@ -0,0 +1,223 @@
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd.directives">
+  <refentryinfo>
+    <title>systemd.directives</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd.directives</refentrytitle>
+    <manvolnum>7</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd.directives</refname>
+    <refpurpose>Index of configuration directives</refpurpose>
+  </refnamediv>
+
+  <refsect1>
+    <title>Unit directives</title>
+
+    <para>Directives for configuring units, used in unit files.</para>
+
+    <variablelist id='unit-directives' />
+  </refsect1>
+
+  <refsect1>
+    <title>Options on the kernel command line</title>
+
+    <para>Kernel boot options for configuring the behaviour of the systemd process.</para>
+
+    <variablelist id='kernel-commandline-options' />
+  </refsect1>
+
+  <refsect1>
+    <title>SMBIOS Type 11 Variables</title>
+
+    <para>Data passed from VMM to system via SMBIOS Type 11.</para>
+
+    <variablelist id='smbios-type-11-options' />
+  </refsect1>
+
+  <refsect1>
+    <title>Environment variables</title>
+
+    <para>Environment variables understood by the systemd manager and other programs and environment
+    variable-compatible settings.</para>
+
+    <variablelist id='environment-variables' />
+  </refsect1>
+
+  <refsect1>
+    <title>System Credentials</title>
+
+    <para>System credentials understood by the system and service manager and various other
+    components:</para>
+
+    <variablelist id='system-credentials' />
+  </refsect1>
+
+  <refsect1>
+    <title>EFI variables</title>
+
+    <para>EFI variables understood by
+    <citerefentry><refentrytitle>systemd-boot</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+    and other programs.</para>
+
+    <variablelist id='efi-variables' />
+  </refsect1>
+
+  <refsect1>
+    <title>Home Area/User Account directives</title>
+
+    <para>Directives for configuring home areas and user accounts via
+    <citerefentry><refentrytitle>systemd-homed.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
+
+    <variablelist id='home-directives' />
+  </refsect1>
+
+  <refsect1>
+    <title>UDEV directives</title>
+
+    <para>Directives for configuring systemd units through the udev database.</para>
+
+    <variablelist id='udev-directives' />
+  </refsect1>
+
+  <refsect1>
+    <title>Network directives</title>
+
+    <para>Directives for configuring network links through the net-setup-link udev builtin and networks
+    through systemd-networkd.</para>
+
+    <variablelist id='network-directives' />
+  </refsect1>
+
+  <refsect1>
+    <title>Journal fields</title>
+
+    <para>Fields in the journal events with a well known meaning.</para>
+
+    <variablelist id='journal-directives' />
+  </refsect1>
+
+  <refsect1>
+    <title>PAM configuration directives</title>
+
+    <para>Directives for configuring PAM behaviour.</para>
+
+    <variablelist id='pam-directives' />
+  </refsect1>
+
+  <refsect1>
+    <title><filename>/etc/crypttab</filename>,
+    <filename>/etc/veritytab</filename> and
+    <filename>/etc/fstab</filename> options</title>
+
+    <para>Options which influence mounted filesystems and encrypted volumes.</para>
+
+    <variablelist id='fstab-options' />
+  </refsect1>
+
+  <refsect1>
+    <title><citerefentry><refentrytitle>systemd.nspawn</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    directives</title>
+
+    <para>Directives for configuring systemd-nspawn containers.</para>
+
+    <variablelist id='nspawn-directives' />
+  </refsect1>
+
+  <refsect1>
+    <title>Program configuration options</title>
+
+    <para>Directives for configuring the behaviour of the systemd process and other tools through
+    configuration files.</para>
+
+    <variablelist id='config-directives' />
+  </refsect1>
+
+  <refsect1>
+    <title>Command line options</title>
+
+    <para>Command-line options accepted by programs in the systemd suite.</para>
+
+    <variablelist id='options' />
+  </refsect1>
+
+  <refsect1>
+    <title>Constants</title>
+
+    <para>Various constants used and/or defined by systemd.</para>
+
+    <variablelist id='constants' />
+  </refsect1>
+
+  <refsect1>
+    <title>DNS resource record types</title>
+
+    <variablelist id='dns' />
+  </refsect1>
+
+  <refsect1>
+    <title>Miscellaneous options and directives</title>
+
+    <para>Other configuration elements which don't fit in any of the above groups.</para>
+
+    <variablelist id='miscellaneous' />
+  </refsect1>
+
+  <refsect1>
+    <title>Specifiers</title>
+
+    <para>Short strings which are substituted in configuration directives.</para>
+
+    <variablelist id='specifiers' />
+  </refsect1>
+
+  <refsect1>
+    <title>Files and directories</title>
+
+    <para>Paths and file names referred to in the documentation.</para>
+
+    <variablelist id='filenames' />
+  </refsect1>
+
+  <refsect1>
+    <title>D-Bus interfaces</title>
+
+    <para>Interfaces exposed over D-Bus.</para>
+
+    <variablelist id='dbus-interface' />
+  </refsect1>
+
+  <refsect1>
+    <title>D-Bus methods</title>
+
+    <para>Methods exposed in the D-Bus interface.</para>
+
+    <variablelist id='dbus-method' />
+  </refsect1>
+
+  <refsect1>
+    <title>D-Bus properties</title>
+
+    <para>Properties exposed in the D-Bus interface.</para>
+
+    <variablelist id='dbus-property' />
+  </refsect1>
+
+  <refsect1>
+    <title>D-Bus signals</title>
+
+    <para>Signals emitted in the D-Bus interface.</para>
+
+    <variablelist id='dbus-signal' />
+  </refsect1>
+
+  <refsect1>
+    <title>Colophon</title>
+    <para id='colophon' />
+  </refsect1>
+</refentry>
diff --git a/man/dnssec-trust-anchors.d.xml b/man/dnssec-trust-anchors.d.xml
new file mode 100644
index 0000000..39b9515
--- /dev/null
+++ b/man/dnssec-trust-anchors.d.xml
@@ -0,0 +1,172 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="dnssec-trust-anchors.d" conditional='ENABLE_RESOLVE'
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+  <refentryinfo>
+    <title>dnssec-trust-anchors.d</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>dnssec-trust-anchors.d</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>dnssec-trust-anchors.d</refname>
+    <refname>systemd.positive</refname>
+    <refname>systemd.negative</refname>
+    <refpurpose>DNSSEC trust anchor configuration files</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>/etc/dnssec-trust-anchors.d/*.positive</filename></para>
+    <para><filename>/run/dnssec-trust-anchors.d/*.positive</filename></para>
+    <para><filename>/usr/lib/dnssec-trust-anchors.d/*.positive</filename></para>
+    <para><filename>/etc/dnssec-trust-anchors.d/*.negative</filename></para>
+    <para><filename>/run/dnssec-trust-anchors.d/*.negative</filename></para>
+    <para><filename>/usr/lib/dnssec-trust-anchors.d/*.negative</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>The DNSSEC trust anchor configuration files define positive
+    and negative trust anchors
+    <citerefentry><refentrytitle>systemd-resolved.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    bases DNSSEC integrity proofs on.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Positive Trust Anchors</title>
+
+    <para>Positive trust anchor configuration files contain <constant class='dns'>DNSKEY</constant> and
+    <constant class='dns'>DS</constant> resource record definitions to use as base for DNSSEC integrity
+    proofs. See <ulink url="https://tools.ietf.org/html/rfc4035#section-4.4">RFC 4035, Section 4.4</ulink>
+    for more information about DNSSEC trust anchors.</para>
+
+    <para>Positive trust anchors are read from files with the suffix
+    <filename>.positive</filename> located in
+    <filename>/etc/dnssec-trust-anchors.d/</filename>,
+    <filename>/run/dnssec-trust-anchors.d/</filename> and
+    <filename>/usr/lib/dnssec-trust-anchors.d/</filename>. These
+    directories are searched in the specified order, and a trust
+    anchor file of the same name in an earlier path overrides a trust
+    anchor files in a later path. To disable a trust anchor file
+    shipped in <filename>/usr/lib/dnssec-trust-anchors.d/</filename>
+    it is sufficient to provide an identically-named file in
+    <filename>/etc/dnssec-trust-anchors.d/</filename> or
+    <filename>/run/dnssec-trust-anchors.d/</filename> that is either
+    empty or a symlink to <filename>/dev/null</filename> ("masked").</para>
+
+    <para>Positive trust anchor files are simple text files resembling DNS zone files, as documented in
+    <ulink url="https://tools.ietf.org/html/rfc1035#section-5">RFC 1035, Section 5</ulink>. One <constant
+    class='dns'>DS</constant> or <constant class='dns'>DNSKEY</constant> resource record may be listed per
+    line. Empty lines and lines starting with <literal>#</literal> or <literal>;</literal> are ignored, which
+    may be used for commenting. A <constant class='dns'>DS</constant> resource record is specified like in the
+    following example:</para>
+
+    <programlisting>. IN DS 19036 8 2 49aac11d7b6f6446702e54a1607371607a1a41855200fd2ce1cdde32f24e8fb5</programlisting>
+
+    <para>The first word specifies the domain, use
+    <literal>.</literal> for the root domain. The domain may be
+    specified with or without trailing dot, which is considered
+    equivalent. The second word must be <literal>IN</literal> the
+    third word <literal>DS</literal>. The following words specify the
+    key tag, signature algorithm, digest algorithm, followed by the
+    hex-encoded key fingerprint. See <ulink
+    url="https://tools.ietf.org/html/rfc4034#section-5">RFC 4034,
+    Section 5</ulink> for details about the precise syntax and meaning
+    of these fields.</para>
+
+    <para>Alternatively, <constant class='dns'>DNSKEY</constant> resource records may be used to define trust
+    anchors, like in the following example:</para>
+
+    <programlisting>. IN DNSKEY 257 3 8 AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0=</programlisting>
+
+    <para>The first word specifies the domain again, the second word must be <literal>IN</literal>, followed
+    by <literal>DNSKEY</literal>. The subsequent words encode the <constant class='dns'>DNSKEY</constant>
+    flags, protocol and algorithm fields, followed by the key data encoded in Base64. See <ulink
+    url="https://tools.ietf.org/html/rfc4034#section-2">RFC 4034, Section 2</ulink> for details about the
+    precise syntax and meaning of these fields.</para>
+
+    <para>If multiple <constant class='dns'>DS</constant> or <constant class='dns'>DNSKEY</constant> records
+    are defined for the same domain (possibly even in different trust anchor files), all keys are used and
+    are considered equivalent as base for DNSSEC proofs.</para>
+
+    <para>Note that <filename>systemd-resolved</filename> will
+    automatically use a built-in trust anchor key for the Internet
+    root domain if no positive trust anchors are defined for the root
+    domain. In most cases it is hence unnecessary to define an
+    explicit key with trust anchor files. The built-in key is disabled
+    as soon as at least one trust anchor key for the root domain is
+    defined in trust anchor files.</para>
+
+    <para>It is generally recommended to encode trust anchors in <constant class='dns'>DS</constant> resource
+    records, rather than <constant class='dns'>DNSKEY</constant> resource records.</para>
+
+    <para>If a trust anchor specified via a <constant class='dns'>DS</constant> record is found revoked it is
+    automatically removed from the trust anchor database for the runtime. See <ulink
+    url="https://tools.ietf.org/html/rfc5011">RFC 5011</ulink> for details about revoked trust anchors. Note
+    that <filename>systemd-resolved</filename> will not update its trust anchor database from DNS servers
+    automatically. Instead, it is recommended to update the resolver software or update the new trust anchor
+    via adding in new trust anchor files.</para>
+
+    <para>The current DNSSEC trust anchor for the Internet's root
+    domain is available at the <ulink
+    url="https://data.iana.org/root-anchors/root-anchors.xml">IANA
+    Trust Anchor and Keys</ulink> page.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Negative Trust Anchors</title>
+
+    <para>Negative trust anchors define domains where DNSSEC validation shall be turned
+    off. Negative trust anchor files are found at the same location as positive trust anchor files,
+    and follow the same overriding rules. They are text files with the
+    <filename>.negative</filename> suffix. Empty lines and lines whose first character is
+    <literal>;</literal> are ignored. Each line specifies one domain name which is the root of a DNS
+    subtree where validation shall be disabled. For example:</para>
+
+    <programlisting># Reverse IPv4 mappings
+10.in-addr.arpa
+16.172.in-addr.arpa
+168.192.in-addr.arpa
+...
+# Some custom domains
+prod
+stag
+</programlisting>
+
+    <para>Negative trust anchors are useful to support private DNS
+    subtrees that are not referenced from the Internet DNS hierarchy,
+    and not signed.</para>
+
+    <para><ulink url="https://tools.ietf.org/html/rfc7646">RFC
+    7646</ulink> for details on negative trust anchors.</para>
+
+    <para>If no negative trust anchor files are configured a built-in
+    set of well-known private DNS zone domains is used as negative
+    trust anchors.</para>
+
+    <para>It is also possibly to define per-interface negative trust
+    anchors using the <varname>DNSSECNegativeTrustAnchors=</varname>
+    setting in
+    <citerefentry><refentrytitle>systemd.network</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    files.</para>
+  </refsect1>
+
+  <refsect1>
+      <title>See Also</title>
+      <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-resolved.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>resolved.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.network</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+      </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/environment.d.xml b/man/environment.d.xml
new file mode 100644
index 0000000..fc03405
--- /dev/null
+++ b/man/environment.d.xml
@@ -0,0 +1,133 @@
+<?xml version="1.0"?>
+<!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!--
+  SPDX-License-Identifier: LGPL-2.1-or-later
+
+  Copyright © 2016 Red Hat, Inc.
+-->
+<refentry id="environment.d" conditional='ENABLE_ENVIRONMENT_D'
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>environment.d</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>environment.d</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>environment.d</refname>
+    <refpurpose>Definition of user service environment</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>~/.config/environment.d/*.conf</filename></para>
+    <para><filename>/etc/environment.d/*.conf</filename></para>
+    <para><filename>/run/environment.d/*.conf</filename></para>
+    <para><filename>/usr/lib/environment.d/*.conf</filename></para>
+    <para><filename>/etc/environment</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>Configuration files in the <filename>environment.d/</filename> directories contain lists of
+    environment variable assignments passed to services started by the systemd user instance.
+    <citerefentry><refentrytitle>systemd-environment-d-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    parses them and updates the environment exported by the systemd user instance. See below for an
+    discussion of which processes inherit those variables.</para>
+
+    <para>It is recommended to use numerical prefixes for file names to simplify ordering.</para>
+
+    <para>For backwards compatibility, a symlink to <filename>/etc/environment</filename> is
+    installed, so this file is also parsed.</para>
+  </refsect1>
+
+  <xi:include href="standard-conf.xml" xpointer="confd" />
+
+  <refsect1>
+    <title>Configuration Format</title>
+
+    <para>The configuration files contain a list of
+    <literal><replaceable>KEY</replaceable>=<replaceable>VALUE</replaceable></literal> environment
+    variable assignments, separated by newlines. The right hand side of these assignments may
+    reference previously defined environment variables, using the <literal>${OTHER_KEY}</literal>
+    and <literal>$OTHER_KEY</literal> format. It is also possible to use
+    <literal>${<replaceable>FOO</replaceable>:-<replaceable>DEFAULT_VALUE</replaceable>}</literal>
+    to expand in the same way as <literal>${<replaceable>FOO</replaceable>}</literal> unless the
+    expansion would be empty, in which case it expands to <replaceable>DEFAULT_VALUE</replaceable>,
+    and use
+    <literal>${<replaceable>FOO</replaceable>:+<replaceable>ALTERNATE_VALUE</replaceable>}</literal>
+    to expand to <replaceable>ALTERNATE_VALUE</replaceable> as long as
+    <literal>${<replaceable>FOO</replaceable>}</literal> would have expanded to a non-empty value.
+    No other elements of shell syntax are supported.</para>
+
+    <para>Each <replaceable>KEY</replaceable> must be a valid variable name. Empty lines
+    and lines beginning with the comment character <literal>#</literal> are ignored.</para>
+
+    <refsect2>
+      <title>Example</title>
+      <example>
+        <title>Setup environment to allow access to a program installed in
+        <filename index="false">/opt/foo</filename></title>
+
+        <para><filename index="false">/etc/environment.d/60-foo.conf</filename>:
+        </para>
+        <programlisting>
+        FOO_DEBUG=force-software-gl,log-verbose
+        PATH=/opt/foo/bin:$PATH
+        LD_LIBRARY_PATH=/opt/foo/lib${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}
+        XDG_DATA_DIRS=/opt/foo/share:${XDG_DATA_DIRS:-/usr/local/share/:/usr/share/}
+        </programlisting>
+      </example>
+    </refsect2>
+  </refsect1>
+
+  <refsect1>
+    <title>Applicability</title>
+
+    <para>Environment variables exported by the user service manager (<command>systemd --user</command>
+    instance started in the <filename>user@<replaceable>uid</replaceable>.service</filename> system service)
+    are passed to any services started by that service manager. In particular, this may include services
+    which run user shells. For example in the GNOME environment, the graphical terminal emulator runs as the
+    <filename>gnome-terminal-server.service</filename> user unit, which in turn runs the user shell, so that
+    shell will inherit environment variables exported by the user manager. For other instances of the shell,
+    not launched by the user service manager, the environment they inherit is defined by the program that
+    starts them. Hint: in general,
+    <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry> units
+    contain programs launched by systemd, and
+    <citerefentry><refentrytitle>systemd.scope</refentrytitle><manvolnum>5</manvolnum></citerefentry> units
+    contain programs launched by something else.</para>
+
+    <para>Note that these files do not affect the environment block of the service manager itself, but
+    exclusively the environment blocks passed to the services it manages. Environment variables set that way
+    thus cannot be used to influence behaviour of the service manager. In order to make changes to the
+    service manager's environment block the environment must be modified before the user's service manager is
+    invoked, for example from the system service manager or via a PAM module.</para>
+
+    <para>Specifically, for ssh logins, the
+    <citerefentry project='die-net'><refentrytitle>sshd</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    service builds an environment that is a combination of variables forwarded from the remote system and
+    defined by <command>sshd</command>, see the discussion in
+    <citerefentry project='die-net'><refentrytitle>ssh</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
+    A graphical display session will have an analogous mechanism to define the environment. Note that some
+    managers query the systemd user instance for the exported environment and inject this configuration into
+    programs they start, using <command>systemctl show-environment</command> or the underlying D-Bus call.
+    </para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-environment-d-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.environment-generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/event-quick-child.c b/man/event-quick-child.c
new file mode 100644
index 0000000..8195efb
--- /dev/null
+++ b/man/event-quick-child.c
@@ -0,0 +1,42 @@
+/* SPDX-License-Identifier: MIT-0 */
+
+#include <assert.h>
+#include <stdio.h>
+#include <unistd.h>
+#include <sd-event.h>
+
+int main(int argc, char **argv) {
+  pid_t pid = fork();
+  assert(pid >= 0);
+
+  /* SIGCHLD signal must be blocked for sd_event_add_child to work */
+  sigset_t ss;
+  sigemptyset(&ss);
+  sigaddset(&ss, SIGCHLD);
+  sigprocmask(SIG_BLOCK, &ss, NULL);
+
+  if (pid == 0)  /* child */
+    sleep(1);
+
+  else {         /* parent */
+    sd_event *e = NULL;
+    int r;
+
+    /* Create the default event loop */
+    sd_event_default(&e);
+    assert(e);
+
+    /* We create a floating child event source (attached to 'e').
+     * The default handler will be called with 666 as userdata, which
+     * will become the exit value of the loop. */
+    r = sd_event_add_child(e, NULL, pid, WEXITED, NULL, (void*) 666);
+    assert(r >= 0);
+
+    r = sd_event_loop(e);
+    assert(r == 666);
+
+    sd_event_unref(e);
+  }
+
+  return 0;
+}
diff --git a/man/fido2-crypttab.sh b/man/fido2-crypttab.sh
new file mode 100644
index 0000000..43654a5
--- /dev/null
+++ b/man/fido2-crypttab.sh
@@ -0,0 +1,25 @@
+# SPDX-License-Identifier: MIT-0
+
+# Enroll the security token in the LUKS2 volume. Replace /dev/sdXn by the
+# partition to use (e.g. /dev/sda1).
+sudo systemd-cryptenroll --fido2-device=auto /dev/sdXn
+
+# Test: Let's run systemd-cryptsetup to test if this worked.
+sudo systemd-cryptsetup attach mytest /dev/sdXn - fido2-device=auto
+
+# If that worked, let's now add the same line persistently to /etc/crypttab,
+# for the future. We don't want to use the (unstable) /dev/sdX name, so let's
+# figure out a stable link:
+udevadm info -q -r symlink /dev/sdXn
+
+# Now add the line using the by-uuid symlink to /etc/crypttab:
+sudo bash -c 'echo "mytest /dev/disk/by-uuid/... - fido2-device=auto" >>/etc/crypttab'
+
+# Depending on your distribution and encryption setup, you may need to manually
+# regenerate your initramfs to be able to use a FIDO2 device to unlock the
+# partition during early boot.
+# More information at https://unix.stackexchange.com/a/705809.
+# On Fedora based systems:
+sudo dracut --force
+# On Debian based systems:
+sudo update-initramfs -u
diff --git a/man/file-hierarchy.xml b/man/file-hierarchy.xml
new file mode 100644
index 0000000..583b9ab
--- /dev/null
+++ b/man/file-hierarchy.xml
@@ -0,0 +1,922 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="file-hierarchy" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>file-hierarchy</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>file-hierarchy</refentrytitle>
+    <manvolnum>7</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>file-hierarchy</refname>
+    <refpurpose>File system hierarchy overview</refpurpose>
+  </refnamediv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>Operating systems using the
+    <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> system and service
+    manager are organized based on a file system hierarchy inspired by UNIX, more specifically the hierarchy described
+    in the <ulink url="http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html">File System Hierarchy</ulink>
+    specification and <citerefentry
+    project='man-pages'><refentrytitle>hier</refentrytitle><manvolnum>7</manvolnum></citerefentry>, with various
+    extensions, partially documented in the <ulink
+    url="https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html">XDG Base Directory
+    Specification</ulink> and <ulink url="https://www.freedesktop.org/wiki/Software/xdg-user-dirs">XDG User
+    Directories</ulink>. This manual page describes a more generalized, though minimal and modernized subset of these
+    specifications that defines more strictly the suggestions and restrictions systemd makes on the file system
+    hierarchy.</para>
+
+    <para>Many of the paths described here can be queried
+    with the
+    <citerefentry><refentrytitle>systemd-path</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    tool.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>General Structure</title>
+
+    <variablelist>
+      <varlistentry>
+        <term><filename>/</filename></term>
+        <listitem><para>The file system root. Usually writable, but
+        this is not required. Possibly a temporary file system
+        (<literal>tmpfs</literal>). Not shared with other hosts
+        (unless read-only). </para>
+
+        <xi:include href="version-info.xml" xpointer="v215"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>/boot/</filename></term>
+        <listitem><para>The boot partition used for bringing up the
+        system. On EFI systems, this is possibly the EFI System
+        Partition (ESP), also see
+        <citerefentry><refentrytitle>systemd-gpt-auto-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+        This directory is usually strictly local to the host, and
+        should be considered read-only, except when a new kernel or
+        boot loader is installed. This directory only exists on
+        systems that run on physical or emulated hardware that
+        requires boot loaders.</para>
+
+        <xi:include href="version-info.xml" xpointer="v215"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>/efi/</filename></term>
+        <listitem><para>If the boot partition <filename>/boot/</filename> is maintained separately from the EFI System
+        Partition (ESP), the latter is mounted here. Tools that need to operate on the EFI system partition should look
+        for it at this mount point first, and fall back to <filename>/boot/</filename> — if the former doesn't qualify
+        (for example if it is not a mount point or does not have the correct file system type
+        <constant>MSDOS_SUPER_MAGIC</constant>).</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>/etc/</filename></term>
+        <listitem><para>System-specific configuration. This directory
+        may or may not be read-only. Frequently, this directory is
+        pre-populated with vendor-supplied configuration files, but
+        applications should not make assumptions about this directory
+        being fully populated or populated at all, and should fall
+        back to defaults if configuration is
+        missing.</para>
+
+        <xi:include href="version-info.xml" xpointer="v215"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>/home/</filename></term>
+        <listitem><para>The location for normal user's home
+        directories. Possibly shared with other systems, and never
+        read-only. This directory should only be used for normal
+        users, never for system users. This directory and possibly the
+        directories contained within it might only become available or
+        writable in late boot or even only after user authentication.
+        This directory might be placed on limited-functionality
+        network file systems, hence applications should not assume the
+        full set of file API is available on this directory.
+        Applications should generally not reference this directory
+        directly, but via the per-user <varname>$HOME</varname>
+        environment variable, or via the home directory field of the
+        user database.</para>
+
+        <xi:include href="version-info.xml" xpointer="v215"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>/root/</filename></term>
+        <listitem><para>The home directory of the root user. The root
+        user's home directory is located outside of
+        <filename>/home/</filename> in order to make sure the root user
+        may log in even without <filename>/home/</filename> being
+        available and mounted.</para>
+
+        <xi:include href="version-info.xml" xpointer="v215"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>/srv/</filename></term>
+        <listitem><para>The place to store general server payload,
+        managed by the administrator. No restrictions are made how
+        this directory is organized internally. Generally writable,
+        and possibly shared among systems. This directory might become
+        available or writable only very late during
+        boot.</para>
+
+        <xi:include href="version-info.xml" xpointer="v215"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>/tmp/</filename></term>
+        <listitem><para>The place for small temporary files. This directory is usually mounted as a
+        <literal>tmpfs</literal> instance, and should hence not be used for larger files. (Use
+        <filename>/var/tmp/</filename> for larger files.) This directory is usually flushed at boot-up. Also,
+        files that are not accessed within a certain time may be automatically deleted.</para>
+
+        <para>If applications find the environment variable <varname>$TMPDIR</varname> set, they should use
+        the directory specified in it instead of <filename>/tmp/</filename> (see <citerefentry
+        project='man-pages'><refentrytitle>environ</refentrytitle><manvolnum>7</manvolnum></citerefentry> and
+        <ulink url="http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08_03">IEEE
+        Std 1003.1</ulink> for details).</para>
+
+        <para>Since <filename>/tmp/</filename> is accessible to other users of the system, it is essential
+        that files and subdirectories under this directory are only created with <citerefentry
+        project='man-pages'><refentrytitle>mkstemp</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+        <citerefentry
+        project='man-pages'><refentrytitle>mkdtemp</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+        and similar calls. For more details, see <ulink url="https://systemd.io/TEMPORARY_DIRECTORIES">Using
+        /tmp/ and /var/tmp/ Safely</ulink>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v215"/>
+        </listitem>
+      </varlistentry>
+
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Runtime Data</title>
+
+    <variablelist>
+      <varlistentry>
+        <term><filename>/run/</filename></term>
+        <listitem><para>A <literal>tmpfs</literal> file system for system packages to place runtime data,
+        socket files, and similar. This directory is flushed on boot, and generally writable for privileged
+        programs only. Always writable.</para>
+
+        <xi:include href="version-info.xml" xpointer="v215"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>/run/log/</filename></term>
+        <listitem><para>Runtime system logs. System components may
+        place private logs in this directory. Always writable, even
+        when <filename>/var/log/</filename> might not be accessible
+        yet.</para>
+
+        <xi:include href="version-info.xml" xpointer="v215"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>/run/user/</filename></term>
+        <listitem><para>Contains per-user runtime directories, each
+        usually individually mounted <literal>tmpfs</literal>
+        instances. Always writable, flushed at each reboot and when
+        the user logs out. User code should not reference this
+        directory directly, but via the
+        <varname>$XDG_RUNTIME_DIR</varname> environment variable, as
+        documented in the <ulink
+        url="https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html">XDG
+        Base Directory Specification</ulink>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v215"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Vendor-supplied Operating System Resources</title>
+
+    <variablelist>
+
+      <varlistentry>
+        <term><filename>/usr/</filename></term>
+        <listitem><para>Vendor-supplied operating system resources.
+        Usually read-only, but this is not required. Possibly shared
+        between multiple hosts. This directory should not be modified
+        by the administrator, except when installing or removing
+        vendor-supplied packages.</para>
+
+        <xi:include href="version-info.xml" xpointer="v215"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>/usr/bin/</filename></term>
+        <listitem><para>Binaries and executables for user commands
+        that shall appear in the <varname>$PATH</varname> search path.
+        It is recommended not to place binaries in this directory that
+        are not useful for invocation from a shell (such as daemon
+        binaries); these should be placed in a subdirectory of
+        <filename>/usr/lib/</filename> instead.</para>
+
+        <xi:include href="version-info.xml" xpointer="v215"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>/usr/include/</filename></term>
+        <listitem><para>C and C++ API header files of system
+        libraries.</para>
+
+        <xi:include href="version-info.xml" xpointer="v215"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>/usr/lib/</filename></term>
+        <listitem><para>Static, private vendor data that is compatible
+        with all architectures (though not necessarily
+        architecture-independent). Note that this includes internal
+        executables or other binaries that are not regularly invoked
+        from a shell. Such binaries may be for any architecture
+        supported by the system. Do not place public libraries in this
+        directory, use <varname>$libdir</varname> (see below),
+        instead.</para>
+
+        <xi:include href="version-info.xml" xpointer="v215"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>/usr/lib/<replaceable>arch-id</replaceable>/</filename></term>
+        <listitem><para>Location for placing dynamic libraries into, also
+        called <varname>$libdir</varname>. The architecture identifier
+        to use is defined on <ulink
+        url="https://wiki.debian.org/Multiarch/Tuples">Multiarch
+        Architecture Specifiers (Tuples)</ulink> list. Legacy
+        locations of <varname>$libdir</varname> are
+        <filename>/usr/lib/</filename>,
+        <filename>/usr/lib64/</filename>. This directory should not be
+        used for package-specific data, unless this data is
+        architecture-dependent, too. To query
+        <varname>$libdir</varname> for the primary architecture of the
+        system, invoke:
+        <programlisting># systemd-path system-library-arch</programlisting></para>
+
+        <xi:include href="version-info.xml" xpointer="v215"/></listitem>
+
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>/usr/share/</filename></term>
+        <listitem><para>Resources shared between multiple packages,
+        such as documentation, man pages, time zone information, fonts
+        and other resources. Usually, the precise location and format
+        of files stored below this directory is subject to
+        specifications that ensure interoperability.</para>
+
+        <xi:include href="version-info.xml" xpointer="v215"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>/usr/share/doc/</filename></term>
+        <listitem><para>Documentation for the operating system or
+        system packages.</para>
+
+        <xi:include href="version-info.xml" xpointer="v215"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>/usr/share/factory/etc/</filename></term>
+        <listitem><para>Repository for vendor-supplied default
+        configuration files. This directory should be populated with
+        pristine vendor versions of all configuration files that may
+        be placed in <filename>/etc/</filename>. This is useful to
+        compare the local configuration of a system with vendor
+        defaults and to populate the local configuration with
+        defaults.</para>
+
+        <xi:include href="version-info.xml" xpointer="v215"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>/usr/share/factory/var/</filename></term>
+
+        <listitem><para>Similar to
+        <filename>/usr/share/factory/etc/</filename>, but for vendor
+        versions of files in the variable, persistent data directory
+        <filename>/var/</filename>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v215"/></listitem>
+
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Persistent Variable System Data</title>
+
+    <variablelist>
+      <varlistentry>
+        <term><filename>/var/</filename></term>
+        <listitem><para>Persistent, variable system data. Writable during normal system operation. This
+        directory might be pre-populated with vendor-supplied data, but applications should be able to
+        reconstruct necessary files and directories in this subhierarchy should they be missing, as the
+        system might start up without this directory being populated. Persistency is recommended, but
+        optional, to support ephemeral systems. This directory might become available or writable only very
+        late during boot. Components that are required to operate during early boot hence shall not
+        unconditionally rely on this directory.</para>
+
+        <xi:include href="version-info.xml" xpointer="v215"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>/var/cache/</filename></term>
+        <listitem><para>Persistent system cache data. System
+        components may place non-essential data in this directory.
+        Flushing this directory should have no effect on operation of
+        programs, except for increased runtimes necessary to rebuild
+        these caches.</para>
+
+        <xi:include href="version-info.xml" xpointer="v215"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>/var/lib/</filename></term>
+        <listitem><para>Persistent system data. System components may
+        place private data in this directory.</para>
+
+        <xi:include href="version-info.xml" xpointer="v215"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>/var/log/</filename></term>
+        <listitem><para>Persistent system logs. System components may
+        place private logs in this directory, though it is recommended
+        to do most logging via the
+        <citerefentry project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+        and
+        <citerefentry><refentrytitle>sd_journal_print</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+        calls.</para>
+
+        <xi:include href="version-info.xml" xpointer="v215"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>/var/spool/</filename></term>
+        <listitem><para>Persistent system spool data, such as printer
+        or mail queues.</para>
+
+        <xi:include href="version-info.xml" xpointer="v215"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>/var/tmp/</filename></term>
+        <listitem><para>The place for larger and persistent temporary files. In contrast to
+        <filename>/tmp/</filename>, this directory is usually mounted from a persistent physical file system
+        and can thus accept larger files. (Use <filename>/tmp/</filename> for small ephemeral files.) This
+        directory is generally not flushed at boot-up, but time-based cleanup of files that have not been
+        accessed for a certain time is applied.</para>
+
+        <para>If applications find the environment variable <varname>$TMPDIR</varname> set, they should use
+        the directory specified in it instead of <filename>/var/tmp/</filename> (see <citerefentry
+        project='man-pages'><refentrytitle>environ</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
+        details).</para>
+
+        <para>The same security restrictions as with <filename>/tmp/</filename> apply: <citerefentry
+        project='man-pages'><refentrytitle>mkstemp</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+        <citerefentry
+        project='man-pages'><refentrytitle>mkdtemp</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+        and similar calls should be used. For further details about this directory, see <ulink
+        url="https://systemd.io/TEMPORARY_DIRECTORIES">Using /tmp/ and /var/tmp/ Safely</ulink>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v215"/>
+        </listitem>
+      </varlistentry>
+
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Virtual Kernel and API File Systems</title>
+
+    <variablelist>
+      <varlistentry>
+        <term><filename>/dev/</filename></term>
+        <listitem><para>The root directory for device nodes. Usually,
+        this directory is mounted as a <literal>devtmpfs</literal>
+        instance, but might be of a different type in
+        sandboxed/containerized setups. This directory is managed
+        jointly by the kernel and
+        <citerefentry><refentrytitle>systemd-udevd</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+        and should not be written to by other components. A number of
+        special purpose virtual file systems might be mounted below
+        this directory.</para>
+
+        <xi:include href="version-info.xml" xpointer="v215"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>/dev/shm/</filename></term>
+        <listitem><para>Place for POSIX shared memory segments, as
+        created via
+        <citerefentry project='die-net'><refentrytitle>shm_open</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+        This directory is flushed on boot, and is a
+        <literal>tmpfs</literal> file system. Since all users have
+        write access to this directory, special care should be taken
+        to avoid name clashes and vulnerabilities. For normal users,
+        shared memory segments in this directory are usually deleted
+        when the user logs out. Usually, it is a better idea to use
+        memory mapped files in <filename>/run/</filename> (for system
+        programs) or <varname>$XDG_RUNTIME_DIR</varname> (for user
+        programs) instead of POSIX shared memory segments, since these
+        directories are not world-writable and hence not vulnerable to
+        security-sensitive name clashes.</para>
+
+        <xi:include href="version-info.xml" xpointer="v215"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>/proc/</filename></term>
+        <listitem><para>A virtual kernel file system exposing the
+        process list and other functionality. This file system is
+        mostly an API to interface with the kernel and not a place
+        where normal files may be stored. For details, see
+        <citerefentry project='man-pages'><refentrytitle>proc</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+        A number of special purpose virtual file systems might be
+        mounted below this directory.</para>
+
+        <xi:include href="version-info.xml" xpointer="v215"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>/proc/sys/</filename></term>
+        <listitem><para>A hierarchy below <filename>/proc/</filename>
+        that exposes a number of kernel tunables. The primary way to
+        configure the settings in this API file tree is via
+        <citerefentry><refentrytitle>sysctl.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        files. In sandboxed/containerized setups, this directory is
+        generally mounted read-only.</para>
+
+        <xi:include href="version-info.xml" xpointer="v215"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>/sys/</filename></term>
+        <listitem><para>A virtual kernel file system exposing
+        discovered devices and other functionality. This file system
+        is mostly an API to interface with the kernel and not a place
+        where normal files may be stored. In sandboxed/containerized
+        setups, this directory is generally mounted read-only. A number
+        of special purpose virtual file systems might be mounted below
+        this directory.</para>
+
+        <xi:include href="version-info.xml" xpointer="v215"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>/sys/fs/cgroup/</filename></term>
+        <listitem><para>A virtual kernel file system exposing process
+        control groups (cgroups). This file system is an API to interface
+        with the kernel and not a place where normal files may be stored. On
+        current systems running in the default "unified" mode,
+        this directory serves as the mount point for the
+        <literal>cgroup2</literal> filesystem, which provides a unified
+        cgroup hierarchy for all resource controllers. On systems with
+        non-default configurations, this directory may instead be a tmpfs
+        filesystem containing mount points for various
+        <literal>cgroup</literal> (v1) resource controllers; in such
+        configurations, if <literal>cgroup2</literal> is mounted it will be
+        mounted on <filename>/sys/fs/cgroup/unified/</filename>, but
+        cgroup2 will not have resource controllers attached. In
+        sandboxed/containerized setups, this directory may either not exist or
+        may include a subset of functionality.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v251"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Compatibility Symlinks</title>
+
+    <variablelist>
+      <varlistentry>
+        <term><filename>/bin/</filename></term>
+        <term><filename>/sbin/</filename></term>
+        <term><filename>/usr/sbin/</filename></term>
+
+        <listitem><para>These compatibility symlinks point to
+        <filename>/usr/bin/</filename>, ensuring that scripts and
+        binaries referencing these legacy paths correctly find their
+        binaries.</para>
+
+        <xi:include href="version-info.xml" xpointer="v215"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>/lib/</filename></term>
+
+        <listitem><para>This compatibility symlink points to
+        <filename>/usr/lib/</filename>, ensuring that programs
+        referencing this legacy path correctly find their
+        resources.</para>
+
+        <xi:include href="version-info.xml" xpointer="v215"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>/lib64/</filename></term>
+
+        <listitem><para>On some architecture ABIs, this compatibility
+        symlink points to <varname>$libdir</varname>, ensuring that
+        binaries referencing this legacy path correctly find their
+        dynamic loader. This symlink only exists on architectures
+        whose ABI places the dynamic loader in this
+        path.</para>
+
+        <xi:include href="version-info.xml" xpointer="v215"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>/var/run/</filename></term>
+
+        <listitem><para>This compatibility symlink points to
+        <filename>/run/</filename>, ensuring that programs referencing
+        this legacy path correctly find their runtime
+        data.</para>
+
+        <xi:include href="version-info.xml" xpointer="v215"/></listitem>
+      </varlistentry>
+
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Home Directory</title>
+
+    <para>User applications may want to place files and directories in
+    the user's home directory. They should follow the following basic
+    structure. Note that some of these directories are also
+    standardized (though more weakly) by the <ulink
+    url="https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html">XDG
+    Base Directory Specification</ulink>. Additional locations for
+    high-level user resources are defined by <ulink
+    url="https://www.freedesktop.org/wiki/Software/xdg-user-dirs">xdg-user-dirs</ulink>.</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><filename>~/.cache/</filename></term>
+
+        <listitem><para>Persistent user cache data. User programs may place non-essential data in this
+        directory. Flushing this directory should have no effect on operation of programs, except for
+        increased runtimes necessary to rebuild these caches. If an application finds
+        <varname>$XDG_CACHE_HOME</varname> set, it should use the directory specified in it instead of this
+        directory.</para>
+
+        <xi:include href="version-info.xml" xpointer="v215"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>~/.config/</filename></term>
+
+        <listitem><para>Application configuration. When a new user is created, this directory will be empty
+        or not exist at all. Applications should fall back to defaults should their configuration in this
+        directory be missing. If an application finds <varname>$XDG_CONFIG_HOME</varname> set, it should use
+        the directory specified in it instead of this directory.</para>
+
+        <xi:include href="version-info.xml" xpointer="v215"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>~/.local/bin/</filename></term>
+
+        <listitem><para>Executables that shall appear in the user's <varname>$PATH</varname> search path. It
+        is recommended not to place executables in this directory that are not useful for invocation from a
+        shell; these should be placed in a subdirectory of <filename>~/.local/lib/</filename> instead. Care
+        should be taken when placing architecture-dependent binaries in this place, which might be
+        problematic if the home directory is shared between multiple hosts with different
+        architectures.</para>
+
+        <xi:include href="version-info.xml" xpointer="v215"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>~/.local/lib/</filename></term>
+
+        <listitem><para>Static, private vendor data that is compatible with all
+        architectures.</para>
+
+        <xi:include href="version-info.xml" xpointer="v215"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>~/.local/lib/<replaceable>arch-id</replaceable>/</filename></term>
+
+        <listitem><para>Location for placing public dynamic libraries. The architecture identifier to use is
+        defined on <ulink url="https://wiki.debian.org/Multiarch/Tuples">Multiarch Architecture Specifiers
+        (Tuples)</ulink> list.</para>
+
+        <xi:include href="version-info.xml" xpointer="v215"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>~/.local/share/</filename></term>
+
+        <listitem><para>Resources shared between multiple packages, such as fonts or artwork. Usually, the
+        precise location and format of files stored below this directory is subject to specifications that
+        ensure interoperability. If an application finds <varname>$XDG_DATA_HOME</varname> set, it should use
+        the directory specified in it instead of this directory.</para>
+
+        <xi:include href="version-info.xml" xpointer="v215"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>~/.local/state/</filename></term>
+
+        <listitem><para>Application state. When a new user is created, this directory will be empty or not
+        exist at all. Applications should fall back to defaults should their state in this directory be
+        missing. If an application finds <varname>$XDG_STATE_HOME</varname> set, it should use the directory
+        specified in it instead of this directory.</para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+      </varlistentry>
+
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Write Access</title>
+
+    <refsect2>
+      <title>Unprivileged Write Access</title>
+
+      <para>Unprivileged processes generally lack write access to most of the hierarchy.</para>
+
+      <para>The exceptions for normal users are
+      <filename>/tmp/</filename>,
+      <filename>/var/tmp/</filename>,
+      <filename>/dev/shm/</filename>, as well as the home directory
+      <varname>$HOME</varname> (usually found below
+      <filename>/home/</filename>) and the runtime directory
+      <varname>$XDG_RUNTIME_DIR</varname> (found below
+      <filename>/run/user/</filename>) of the user, which are all
+      writable.</para>
+
+      <para>For unprivileged system processes, only
+      <filename>/tmp/</filename>,
+      <filename>/var/tmp/</filename> and
+      <filename>/dev/shm/</filename> are writable. If an
+      unprivileged system process needs a private writable directory in
+      <filename>/var/</filename> or <filename>/run/</filename>, it is
+      recommended to either create it before dropping privileges in the
+      daemon code, to create it via
+      <citerefentry><refentrytitle>tmpfiles.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+      fragments during boot, or via the
+      <varname>StateDirectory=</varname> and <varname>RuntimeDirectory=</varname>
+      directives of service units (see
+      <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+      for details).</para>
+
+      <para><filename>/tmp/</filename>, <filename>/var/tmp/</filename> and <filename>/dev/shm/</filename>
+      should be mounted <option>nosuid</option> and <option>nodev</option>, which means that set-user-id mode
+      and character or block special devices are not interpreted on those file systems. In general it is not
+      possible to mount them <option>noexec</option>, because various programs use those directories for
+      dynamically generated or optimized code, and with that flag those use cases would break. Using this
+      flag is OK on special-purpose installations or systems where all software that may be installed is
+      known and doesn't require such functionality. See the discussion of
+      <option>nosuid</option>/<option>nodev</option>/<option>noexec</option> in <citerefentry
+      project='man-pages'><refentrytitle>mount</refentrytitle><manvolnum>8</manvolnum></citerefentry> and
+      <constant>PROT_EXEC</constant> in <citerefentry
+      project='man-pages'><refentrytitle>mmap</refentrytitle><manvolnum>2</manvolnum></citerefentry>.
+      </para>
+    </refsect2>
+
+    <refsect2>
+      <title>Lack of Write Access on Read-Only Systems and during System Recovery</title>
+
+      <para>As noted above, some systems operate with the <filename>/usr</filename> and
+      <filename>/etc</filename> hierarchies mounted read-only, possibly only allowing write access during
+      package upgrades. Other part of the hierarchy are generally mounted read-write (in particular
+      <filename>/var</filename> and <filename>/var/tmp</filename>), but may be read-only when the kernel
+      remounts the file system read-only in response to errors, or when the system is booted read-only for
+      recovery purposes. To the extent reasonable, applications should be prepared to execute without write
+      access, so that for example, failure to save non-essential data to <filename>/var/cache/</filename> or
+      failure to create a custom log file under <filename>/var/log</filename> does not prevent the
+      application from running.</para>
+
+      <para>The <filename>/run/</filename> directory is available since the earliest boot and is always
+      writable. It should be used for any runtime data and sockets, so that write access to e.g.
+      <filename>/etc</filename> or <filename>/var</filename> is not needed.</para>
+    </refsect2>
+  </refsect1>
+
+  <refsect1>
+    <title>Node Types</title>
+
+    <para>Unix file systems support different types of file nodes,
+    including regular files, directories, symlinks, character and
+    block device nodes, sockets and FIFOs.</para>
+
+    <para>It is strongly recommended that <filename>/dev/</filename> is
+    the only location below which device nodes shall be placed.
+    Similarly, <filename>/run/</filename> shall be the only location to
+    place sockets and FIFOs. Regular files, directories and symlinks
+    may be used in all directories.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>System Packages</title>
+
+    <para>Developers of system packages should follow strict rules when placing their files in the file
+    system. The following table lists recommended locations for specific types of files supplied by the
+    vendor.</para>
+
+    <table>
+      <title>System package vendor files locations</title>
+      <tgroup cols='2' align='left' colsep='1' rowsep='1'>
+        <colspec colname="directory" />
+        <colspec colname="purpose" />
+        <thead>
+          <row>
+      <entry>Directory</entry>
+      <entry>Purpose</entry>
+          </row>
+        </thead>
+        <tbody>
+          <row>
+      <entry><filename>/usr/bin/</filename></entry>
+      <entry>Package executables that shall appear in the <varname>$PATH</varname> executable search path, compiled for any of the supported architectures compatible with the operating system. It is not recommended to place internal binaries or binaries that are not commonly invoked from the shell in this directory, such as daemon binaries. As this directory is shared with most other packages of the system, special care should be taken to pick unique names for files placed here, that are unlikely to clash with other package's files.</entry>
+          </row>
+          <row>
+      <entry><filename>/usr/lib/<replaceable>arch-id</replaceable>/</filename></entry>
+      <entry>Public shared libraries of the package. As above, be careful with using too generic names, and pick unique names for your libraries to place here to avoid name clashes.</entry>
+          </row>
+          <row>
+      <entry><filename>/usr/lib/<replaceable>package</replaceable>/</filename></entry>
+      <entry>Private static vendor resources of the package, including private binaries and libraries, or any other kind of read-only vendor data.</entry>
+          </row>
+          <row>
+      <entry><filename>/usr/lib/<replaceable>arch-id</replaceable>/<replaceable>package</replaceable>/</filename></entry>
+      <entry>Private other vendor resources of the package that are architecture-specific and cannot be shared between architectures. Note that this generally does not include private executables since binaries of a specific architecture may be freely invoked from any other supported system architecture.</entry>
+          </row>
+          <row>
+      <entry><filename>/usr/include/<replaceable>package</replaceable>/</filename></entry>
+      <entry>Public C/C++ APIs of public shared libraries of the package.</entry>
+          </row>
+        </tbody>
+      </tgroup>
+    </table>
+
+    <para>Additional static vendor files may be installed in the
+    <filename>/usr/share/</filename> hierarchy to the locations
+    defined by the various relevant specifications.</para>
+
+    <para>The following directories shall be used by the package for local configuration and files created
+    during runtime:</para>
+
+    <table>
+      <title>System package variable files locations</title>
+      <tgroup cols='2' align='left' colsep='1' rowsep='1'>
+        <colspec colname="directory" />
+        <colspec colname="purpose" />
+        <thead>
+          <row>
+      <entry>Directory</entry>
+      <entry>Purpose</entry>
+          </row>
+        </thead>
+        <tbody>
+          <row>
+      <entry><filename>/etc/<replaceable>package</replaceable>/</filename></entry>
+      <entry>System-specific configuration for the package. It is recommended to default to safe fallbacks if this configuration is missing, if this is possible. Alternatively, a <citerefentry><refentrytitle>tmpfiles.d</refentrytitle><manvolnum>5</manvolnum></citerefentry> fragment may be used to copy or symlink the necessary files and directories from <filename>/usr/share/factory/</filename> during boot, via the <literal>L</literal> or <literal>C</literal> directives.</entry>
+          </row>
+          <row>
+      <entry><filename>/run/<replaceable>package</replaceable>/</filename></entry>
+      <entry>Runtime data for the package. Packages must be able to create the necessary subdirectories in this tree on their own, since the directory is flushed automatically on boot. Alternatively, a <citerefentry><refentrytitle>tmpfiles.d</refentrytitle><manvolnum>5</manvolnum></citerefentry> fragment may be used to create the necessary directories during boot, or the <varname>RuntimeDirectory=</varname> directive of service units may be used to create them at service startup (see <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> for details).</entry>
+          </row>
+          <row>
+      <entry><filename>/run/log/<replaceable>package</replaceable>/</filename></entry>
+      <entry>Runtime log data for the package. As above, the package needs to make sure to create this directory if necessary, as it will be flushed on every boot.</entry>
+          </row>
+          <row>
+      <entry><filename>/var/cache/<replaceable>package</replaceable>/</filename></entry>
+      <entry>Persistent cache data of the package. If this directory is flushed, the application should work correctly on next invocation, though possibly slowed down due to the need to rebuild any local cache files. The application must be capable of recreating this directory should it be missing and necessary. To create an empty directory, a <citerefentry><refentrytitle>tmpfiles.d</refentrytitle><manvolnum>5</manvolnum></citerefentry> fragment or the <varname>CacheDirectory=</varname> directive of service units (see <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>) may be used.</entry>
+          </row>
+          <row>
+      <entry><filename>/var/lib/<replaceable>package</replaceable>/</filename></entry>
+      <entry>Persistent private data of the package. This is the primary place to put persistent data that does not fall into the other categories listed. Packages should be able to create the necessary subdirectories in this tree on their own, since the directory might be missing on boot. To create an empty directory, a <citerefentry><refentrytitle>tmpfiles.d</refentrytitle><manvolnum>5</manvolnum></citerefentry> fragment or the <varname>StateDirectory=</varname> directive of service units (see <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>) may be used.</entry>
+          </row>
+          <row>
+      <entry><filename>/var/log/<replaceable>package</replaceable>/</filename></entry>
+      <entry>Persistent log data of the package. As above, the package should make sure to create this directory if necessary, possibly using <citerefentry><refentrytitle>tmpfiles.d</refentrytitle><manvolnum>5</manvolnum></citerefentry> or <varname>LogsDirectory=</varname> (see <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>), as it might be missing.</entry>
+          </row>
+          <row>
+      <entry><filename>/var/spool/<replaceable>package</replaceable>/</filename></entry>
+      <entry>Persistent spool/queue data of the package. As above, the package should make sure to create this directory if necessary, as it might be missing.</entry>
+          </row>
+        </tbody>
+      </tgroup>
+    </table>
+  </refsect1>
+
+  <refsect1>
+    <title>User Packages</title>
+
+    <para>Programs running in user context should follow strict rules when placing their own files in the
+    user's home directory. The following table lists recommended locations in the home directory for specific
+    types of files supplied by the vendor if the application is installed in the home directory. (User
+    applications installed system-wide are covered by the rules outlined above for vendor files.)</para>
+
+    <table>
+      <title>Vendor package file locations under the home directory of the user</title>
+      <tgroup cols='2' align='left' colsep='1' rowsep='1'>
+        <colspec colname="directory" />
+        <colspec colname="purpose" />
+        <thead>
+          <row>
+      <entry>Directory</entry>
+      <entry>Purpose</entry>
+          </row>
+        </thead>
+        <tbody>
+          <row>
+      <entry><filename>~/.local/bin/</filename></entry>
+      <entry>Package executables that shall appear in the <varname>$PATH</varname> executable search path. It is not recommended to place internal executables or executables that are not commonly invoked from the shell in this directory, such as daemon executables. As this directory is shared with most other packages of the user, special care should be taken to pick unique names for files placed here, that are unlikely to clash with other package's files.</entry>
+          </row>
+          <row>
+      <entry><filename>~/.local/lib/<replaceable>arch-id</replaceable>/</filename></entry>
+      <entry>Public shared libraries of the package. As above, be careful with using overly generic names, and pick unique names for your libraries to place here to avoid name clashes.</entry>
+          </row>
+          <row>
+      <entry><filename>~/.local/lib/<replaceable>package</replaceable>/</filename></entry>
+      <entry>Private, static vendor resources of the package, compatible with any architecture, or any other kind of read-only vendor data.</entry>
+          </row>
+          <row>
+      <entry><filename>~/.local/lib/<replaceable>arch-id</replaceable>/<replaceable>package</replaceable>/</filename></entry>
+      <entry>Private other vendor resources of the package that are architecture-specific and cannot be shared between architectures.</entry>
+          </row>
+        </tbody>
+      </tgroup>
+    </table>
+
+    <para>Additional static vendor files may be installed in the <filename>~/.local/share/</filename>
+    hierarchy, mirroring the subdirectories specified in the section "Vendor-supplied operating system
+    resources" above.</para>
+
+    <para>The following directories shall be used by the package for per-user local configuration and files
+    created during runtime:</para>
+
+    <table>
+      <title>User package variable file locations</title>
+      <tgroup cols='2' align='left' colsep='1' rowsep='1'>
+        <colspec colname="directory" />
+        <colspec colname="purpose" />
+        <thead>
+          <row>
+      <entry>Directory</entry>
+      <entry>Purpose</entry>
+          </row>
+        </thead>
+        <tbody>
+          <row>
+      <entry><filename>~/.config/<replaceable>package</replaceable>/</filename></entry>
+      <entry>User-specific configuration and state for the package. It is required to default to safe fallbacks if this configuration is missing.</entry>
+          </row>
+          <row>
+      <entry><filename><varname>$XDG_RUNTIME_DIR</varname>/<replaceable>package</replaceable>/</filename></entry>
+      <entry>User runtime data for the package.</entry>
+          </row>
+          <row>
+      <entry><filename>~/.cache/<replaceable>package</replaceable>/</filename></entry>
+      <entry>Persistent cache data of the package. If this directory is flushed, the application should work correctly on next invocation, though possibly slowed down due to the need to rebuild any local cache files. The application must be capable of recreating this directory should it be missing and necessary.</entry>
+          </row>
+        </tbody>
+      </tgroup>
+    </table>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>hier</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-path</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-gpt-auto-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sysctl.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>tmpfiles.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry project='die-net'><refentrytitle>pkg-config</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/glib-event-glue.c b/man/glib-event-glue.c
new file mode 100644
index 0000000..61e8bf6
--- /dev/null
+++ b/man/glib-event-glue.c
@@ -0,0 +1,48 @@
+/* SPDX-License-Identifier: MIT-0 */
+
+#include <stdlib.h>
+#include <glib.h>
+#include <systemd/sd-event.h>
+
+typedef struct SDEventSource {
+  GSource source;
+  GPollFD pollfd;
+  sd_event *event;
+} SDEventSource;
+
+static gboolean event_prepare(GSource *source, gint *timeout_) {
+  return sd_event_prepare(((SDEventSource *)source)->event) > 0;
+}
+
+static gboolean event_check(GSource *source) {
+  return sd_event_wait(((SDEventSource *)source)->event, 0) > 0;
+}
+
+static gboolean event_dispatch(GSource *source, GSourceFunc callback, gpointer user_data) {
+  return sd_event_dispatch(((SDEventSource *)source)->event) > 0;
+}
+
+static void event_finalize(GSource *source) {
+  sd_event_unref(((SDEventSource *)source)->event);
+}
+
+static GSourceFuncs event_funcs = {
+  .prepare = event_prepare,
+  .check = event_check,
+  .dispatch = event_dispatch,
+  .finalize = event_finalize,
+};
+
+GSource *g_sd_event_create_source(sd_event *event) {
+  SDEventSource *source;
+
+  source = (SDEventSource *)g_source_new(&event_funcs, sizeof(SDEventSource));
+
+  source->event = sd_event_ref(event);
+  source->pollfd.fd = sd_event_get_fd(event);
+  source->pollfd.events = G_IO_IN | G_IO_HUP | G_IO_ERR;
+
+  g_source_add_poll((GSource *)source, &source->pollfd);
+
+  return (GSource *)source;
+}
diff --git a/man/homectl.xml b/man/homectl.xml
new file mode 100644
index 0000000..7fc7d5f
--- /dev/null
+++ b/man/homectl.xml
@@ -0,0 +1,1219 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="homectl" conditional='ENABLE_HOMED'
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>homectl</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>homectl</refentrytitle>
+    <manvolnum>1</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>homectl</refname>
+    <refpurpose>Create, remove, change or inspect home directories</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <cmdsynopsis>
+      <command>homectl</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="req">COMMAND</arg>
+      <arg choice="opt" rep="repeat">NAME</arg>
+    </cmdsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>homectl</command> may be used to create, remove, change or inspect a user's home
+    directory. It's primarily a command interfacing with
+    <citerefentry><refentrytitle>systemd-homed.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    which manages home directories of users.</para>
+
+    <para>Home directories managed by <filename>systemd-homed.service</filename> are self-contained, and thus
+    include the user's full metadata record in the home's data storage itself, making them easy to migrate
+    between machines. In particular, a home directory describes a matching user record, and every user record
+    managed by <filename>systemd-homed.service</filename> also implies existence and encapsulation of a home
+    directory. The user account and home directory become the same concept.</para>
+
+    <para>The following backing storage mechanisms are supported:</para>
+
+    <itemizedlist>
+      <listitem><para>An individual LUKS2 encrypted loopback file for a user, stored in
+      <filename>/home/*.home</filename>. At login the file system contained in this files is mounted, after
+      the LUKS2 encrypted volume has been attached. The user's password is identical to the encryption
+      passphrase of the LUKS2 volume. Access to data without preceding user authentication is thus not
+      possible, even for the system administrator. This storage mechanism provides the strongest data
+      security and is thus recommended.</para></listitem>
+
+      <listitem><para>Similar, but the LUKS2 encrypted file system is located on regular block device, such
+      as a USB storage stick. In this mode home directories and all data they include are nicely migratable
+      between machines, simply by plugging the USB stick into different systems at different
+      times.</para></listitem>
+
+      <listitem><para>An encrypted directory using <literal>fscrypt</literal> on file systems that support it
+      (at the moment this is primarily <literal>ext4</literal>), located in
+      <filename>/home/*.homedir</filename>. This mechanism also provides encryption, but substantially
+      weaker than LUKS2, as most file system metadata is unprotected. Moreover
+      it currently does not support changing user passwords once the home directory has been
+      created.</para></listitem>
+
+      <listitem><para>A <literal>btrfs</literal> subvolume for each user, also located in
+      <filename>/home/*.homedir</filename>. This provides no encryption, but good quota
+      support.</para></listitem>
+
+      <listitem><para>A regular directory for each user, also located in
+      <filename>/home/*.homedir</filename>. This provides no encryption, but is a suitable fallback
+      available on all machines, even where LUKS2, <literal>fscrypt</literal> or <literal>btrfs</literal>
+      support is not available.</para></listitem>
+
+      <listitem><para>An individual Windows file share (CIFS) for each user.</para></listitem>
+    </itemizedlist>
+
+    <para>Note that <filename>systemd-homed.service</filename> and <command>homectl</command> will not manage
+    "classic" UNIX user accounts as created with <citerefentry
+    project='man-pages'><refentrytitle>useradd</refentrytitle><manvolnum>8</manvolnum></citerefentry> or
+    similar tools. In particular, this functionality is not suitable for managing system users (i.e. users
+    with a UID below 1000) but is exclusive to regular ("human") users.</para>
+
+    <para>Note that users/home directories managed via <command>systemd-homed.service</command> do not show
+    up in <filename>/etc/passwd</filename> and similar files, they are synthesized via glibc NSS during
+    runtime. They are thus resolvable and may be enumerated via the <citerefentry
+    project='man-pages'><refentrytitle>getent</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    tool.</para>
+
+    <para>This tool interfaces directly with <filename>systemd-homed.service</filename>, and may execute
+    specific commands on the home directories it manages. Since every home directory managed that way also
+    defines a JSON user and group record these home directories may also be inspected and enumerated via
+    <citerefentry><refentrytitle>userdbctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>.</para>
+
+    <para>Home directories managed by <filename>systemd-homed.service</filename> are usually in one of two
+    states, or in a transition state between them: when <literal>active</literal> they are unlocked and
+    mounted, and thus accessible to the system and its programs; when <literal>inactive</literal> they are
+    not mounted and thus not accessible. Activation happens automatically at login of the user and usually
+    can only complete after a password (or other authentication token) has been supplied. Deactivation
+    happens after the user fully logged out. A home directory remains active as long as the user is logged in
+    at least once, i.e. has at least one login session. When the user logs in a second time simultaneously
+    the home directory remains active. It is deactivated only after the last of the user's sessions
+    ends.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>The following general options are understood (further options that control the various properties
+    of user records managed by <filename>systemd-homed.service</filename> are documented further
+    down):</para>
+
+    <variablelist>
+
+      <varlistentry>
+        <term><option>--identity=</option><replaceable>FILE</replaceable></term>
+
+        <listitem><para>Read the user's JSON record from the specified file. If passed as
+        <literal>-</literal> read the user record from standard input. The supplied JSON object must follow
+        the structure documented in <ulink url="https://systemd.io/USER_RECORD">JSON User Records</ulink>.
+        This option may be used in conjunction with the <command>create</command> and
+        <command>update</command> commands (see below), where it allows configuring the user record in JSON
+        as-is, instead of setting the individual user record properties (see below).</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--json=</option><replaceable>FORMAT</replaceable></term>
+        <term><option>-j</option></term>
+
+        <listitem><para>Controls whether to output the user record in JSON format, if the
+        <command>inspect</command> command (see below) is used. Takes one of <literal>pretty</literal>,
+        <literal>short</literal> or <literal>off</literal>. If <literal>pretty</literal> human-friendly
+        whitespace and newlines are inserted in the output to make the JSON data more readable. If
+        <literal>short</literal> all superfluous whitespace is suppressed. If <literal>off</literal> (the
+        default) the user information is not shown in JSON format but in a friendly human readable formatting
+        instead. The <option>-j</option> option picks <literal>pretty</literal> when run interactively and
+        <literal>short</literal> otherwise.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--export-format=</option><replaceable>FORMAT</replaceable></term>
+        <term><option>-E</option></term>
+        <term><option>-EE</option></term>
+
+        <listitem><para>When used with the <command>inspect</command> verb in JSON mode (see above) may be
+        used to suppress certain aspects of the JSON user record on output. Specifically, if
+        <literal>stripped</literal> format is used the binding and runtime fields of the record are
+        removed. If <literal>minimal</literal> format is used the cryptographic signature is removed too. If
+        <literal>full</literal> format is used the full JSON record is shown (this is the default). This
+        option is useful for copying an existing user record to a different system in order to create a
+        similar user there with the same settings. Specifically: <command>homectl inspect -EE | ssh
+        root@othersystem homectl create -i-</command> may be used as simple command line for replicating a
+        user on another host. <option>-E</option> is equivalent to <option>-j --export-format=stripped</option>,
+        <option>-EE</option> to <option>-j --export-format=minimal</option>. Note that when replicating user
+        accounts user records acquired in <literal>stripped</literal> mode will retain the original
+        cryptographic signatures and thus may only be modified when the private key to update them is available
+        on the destination machine. When replicating users in <literal>minimal</literal> mode, the signature
+        is removed during the replication and thus the record will be implicitly signed with the key of the destination
+        machine and may be updated there without any private key replication.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <xi:include href="user-system-options.xml" xpointer="host" />
+      <xi:include href="user-system-options.xml" xpointer="machine" />
+
+      <xi:include href="standard-options.xml" xpointer="no-pager" />
+      <xi:include href="standard-options.xml" xpointer="no-legend" />
+      <xi:include href="standard-options.xml" xpointer="no-ask-password" />
+      <xi:include href="standard-options.xml" xpointer="help" />
+      <xi:include href="standard-options.xml" xpointer="version" />
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>User Record Properties</title>
+
+    <para>The following options control various properties of the user records/home directories that
+    <filename>systemd-homed.service</filename> manages. These switches may be used in conjunction with the
+    <command>create</command> and <command>update</command> commands for configuring various aspects of the
+    home directory and the user account:</para>
+
+    <variablelist>
+
+      <varlistentry>
+        <term><option>--real-name=</option><replaceable>NAME</replaceable></term>
+        <term><option>-c</option> <replaceable>NAME</replaceable></term>
+
+        <listitem><para>The real name for the user. This corresponds with the GECOS field on classic UNIX NSS
+        records.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--realm=</option><replaceable>REALM</replaceable></term>
+
+        <listitem><para>The realm for the user. The realm associates a user with a specific organization or
+        installation, and allows distinguishing users of the same name defined in different contexts. The
+        realm can be any string that also qualifies as valid DNS domain name, and it is recommended to use
+        the organization's or installation's domain name for this purpose, but this is not enforced nor
+        required. On each system only a single user of the same name may exist, and if a user with the same
+        name and realm is seen it is assumed to refer to the same user while a user with the same name but
+        different realm is considered a different user. Note that this means that two users sharing the same
+        name but with distinct realms are not allowed on the same system. Assigning a realm to a user is
+        optional.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--email-address=</option><replaceable>EMAIL</replaceable></term>
+
+        <listitem><para>Takes an electronic mail address to associate with the user. On log-in the
+        <varname>$EMAIL</varname> environment variable is initialized from this value.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--location=</option><replaceable>TEXT</replaceable></term>
+
+        <listitem><para>Takes location specification for this user. This is free-form text, which might or
+        might not be usable by geo-location applications. Example: <option>--location="Berlin,
+        Germany"</option> or <option>--location="Basement, Room 3a"</option></para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--icon-name=</option><replaceable>ICON</replaceable></term>
+
+        <listitem><para>Takes an icon name to associate with the user, following the scheme defined by the <ulink
+        url="https://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html">Icon Naming
+        Specification</ulink>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--home-dir=</option><replaceable>PATH</replaceable></term>
+        <term><option>-d</option><replaceable>PATH</replaceable></term>
+
+        <listitem><para>Takes a path to use as home directory for the user. Note that this is the directory
+        the user's home directory is mounted to while the user is logged in. This is not where the user's
+        data is actually stored, see <option>--image-path=</option> for that. If not specified defaults to
+        <filename>/home/$USER</filename>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--uid=</option><replaceable>UID</replaceable></term>
+
+        <listitem><para>Takes a preferred numeric UNIX UID to assign this user. If a user is to be created
+        with the specified UID and it is already taken by a different user on the local system then creation
+        of the home directory is refused. Note though, if after creating the home directory it is used on a
+        different system and the configured UID is taken by another user there, then
+        <command>systemd-homed</command> may assign the user a different UID on that system. The specified
+        UID must be outside of the system user range. It is recommended to use the 60001…60513 UID range for
+        this purpose. If not specified, the UID is automatically picked. If the home directory is found to be
+        owned by a different UID when logging in, the home directory and everything underneath it will have
+        its ownership changed automatically before login completes.</para>
+
+        <para>Note that changing this option for existing home directories generally has no effect on home
+        directories that already have been registered locally (have a local <emphasis>binding</emphasis>), as
+        the UID used for an account on the local system is determined when the home directory is first
+        activated on it, and then remains in effect until the home directory is removed.</para>
+
+        <para>Note that users managed by <command>systemd-homed</command> always have a matching group
+        associated with the same name as well as a GID matching the UID of the user. Thus, configuring the
+        GID separately is not permitted.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--member-of=</option><replaceable>GROUP</replaceable></term>
+        <term><option>-G</option> <replaceable>GROUP</replaceable></term>
+
+        <listitem><para>Takes a comma-separated list of auxiliary UNIX groups this user shall belong
+        to. Example: <option>--member-of=wheel</option> to provide the user with administrator
+        privileges. Note that <command>systemd-homed</command> does not manage any groups besides a group
+        matching the user in name and numeric UID/GID. Thus any groups listed here must be registered
+        independently, for example with <citerefentry
+        project='man-pages'><refentrytitle>groupadd</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+        Any non-existent groups are ignored. This option may be used more than once, in which case all
+        specified group lists are combined. If the user is currently a member of a group which is not listed,
+        the user will be removed from the group.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--capability-bounding-set=</option><replaceable>CAPABILITIES</replaceable></term>
+        <term><option>--capability-ambient-set=</option><replaceable>CAPABILITIES</replaceable></term>
+
+        <listitem><para>These options take a space separated list of process capabilities
+        (e.g. <constant>CAP_WAKE_ALARM</constant>, <constant>CAP_BLOCK_SUSPEND</constant>, …) that shall be
+        set in the capability bounding and ambient sets for all the user's sessions. See <citerefentry
+        project='man-pages'><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+        for details on the capabilities concept. These options may be used more than once, in which case the
+        specified lists are combined. If the parameter begins with a <literal>~</literal> character the
+        effect is inverted: the specified capability is dropped from the specific set.</para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--skel=</option><replaceable>PATH</replaceable></term>
+
+        <listitem><para>Takes a file system path to a directory. Specifies the skeleton directory to
+        initialize the home directory with. All files and directories in the specified path are copied into
+        any newly create home directory. If not specified defaults to <filename>/etc/skel/</filename>.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--shell=</option><replaceable>SHELL</replaceable></term>
+
+        <listitem><para>Takes a file system path. Specifies the shell binary to execute on terminal
+        logins. If not specified defaults to <filename>/bin/bash</filename>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--setenv=</option><replaceable>VARIABLE</replaceable>[=<replaceable>VALUE</replaceable>]</term>
+
+        <listitem><para>Takes an environment variable assignment to set for all user processes. May be used
+        multiple times to set multiple environment variables. When <literal>=</literal> and
+        <replaceable>VALUE</replaceable> are omitted, the value of the variable with the same name in the
+        program environment will be used.</para>
+
+        <para>Note that a number of other settings also result in environment variables to be set for the
+        user, including <option>--email=</option>, <option>--timezone=</option> and
+        <option>--language=</option>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--timezone=</option><replaceable>TIMEZONE</replaceable></term>
+
+        <listitem><para>Takes a time zone location name that sets the timezone for the specified user. When
+        the user logs in the <varname>$TZ</varname> environment variable is initialized from this
+        setting. Example: <option>--timezone=Europe/Amsterdam</option> will result in the environment
+        variable <literal>TZ=:Europe/Amsterdam</literal>. (<literal>:</literal> is used intentionally as part
+        of the timezone specification, see
+        <citerefentry project='man-pages'><refentrytitle>tzset</refentrytitle><manvolnum>3</manvolnum></citerefentry>.)
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--language=</option><replaceable>LANG</replaceable></term>
+
+        <listitem><para>Takes a specifier indicating the preferred language of the user. The
+        <varname>$LANG</varname> environment variable is initialized from this value on login, and thus a
+        value suitable for this environment variable is accepted here, for example
+        <option>--language=de_DE.UTF8</option>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--ssh-authorized-keys=</option><replaceable>KEYS</replaceable></term>
+        <listitem><para>Either takes a SSH authorized key line to associate with the user record or a
+        <literal>@</literal> character followed by a path to a file to read one or more such lines from. SSH
+        keys configured this way are made available to SSH to permit access to this home directory and user
+        record. This option may be used more than once to configure multiple SSH keys.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--pkcs11-token-uri=</option><replaceable>URI</replaceable></term>
+        <listitem><para>Takes an RFC 7512 PKCS#11 URI referencing a security token (e.g. YubiKey or PIV
+        smartcard) that shall be able to unlock the user account. The security token URI should reference a
+        security token with exactly one pair of X.509 certificate and private key. A random secret key is
+        then generated, encrypted with the public key of the X.509 certificate, and stored as part of the
+        user record. At login time it is decrypted with the PKCS#11 module and then used to unlock the
+        account and associated resources. See below for an example how to set up authentication with a
+        security token.</para>
+
+        <para>Instead of a valid PKCS#11 URI, the special strings <literal>list</literal> and
+        <literal>auto</literal> may be specified. If <literal>list</literal> is passed, a brief table of
+        suitable, currently plugged in PKCS#11 hardware tokens is shown, along with their URIs. If
+        <literal>auto</literal> is passed, a suitable PKCS#11 hardware token is automatically selected (this
+        operation will fail if there isn't exactly one suitable token discovered). The latter is a useful
+        shortcut for the most common case where a single PKCS#11 hardware token is plugged in.</para>
+
+        <para>Note that many hardware security tokens implement both PKCS#11/PIV and FIDO2 with the
+        <literal>hmac-secret</literal> extension (for example: the YubiKey 5 series), as supported with the
+        <option>--fido2-device=</option> option below. Both mechanisms are similarly powerful, though FIDO2
+        is the more modern technology. PKCS#11/PIV tokens have the benefit of being recognizable before
+        authentication and hence can be used for implying the user identity to use for logging in, which
+        FIDO2 does not allow. PKCS#11/PIV devices generally require initialization (i.e. storing a
+        private/public key pair on them, see example below) before they can be used; FIDO2 security tokens
+        generally do not required that, and work out of the box.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--fido2-credential-algorithm=</option><replaceable>STRING</replaceable></term>
+        <listitem><para>Specify COSE algorithm used in credential generation. The default value is
+        <literal>es256</literal>. Supported values are <literal>es256</literal>, <literal>rs256</literal>
+        and <literal>eddsa</literal>.</para>
+
+        <para><literal>es256</literal> denotes ECDSA over NIST P-256 with SHA-256. <literal>rs256</literal>
+        denotes 2048-bit RSA with PKCS#1.5 padding and SHA-256. <literal>eddsa</literal> denotes
+        EDDSA over Curve25519 with SHA-512.</para>
+
+        <para>Note that your authenticator may not support some algorithms.</para>
+
+        <xi:include href="version-info.xml" xpointer="v251"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--fido2-device=</option><replaceable>PATH</replaceable></term>
+
+        <listitem><para>Takes a path to a Linux <literal>hidraw</literal> device
+        (e.g. <filename>/dev/hidraw1</filename>), referring to a FIDO2 security token implementing the
+        <literal>hmac-secret</literal> extension that shall be able to unlock the user account. A random salt
+        value is generated on the host and passed to the FIDO2 device, which calculates a HMAC hash of the
+        salt using an internal secret key. The result is then used as the key to unlock the user account. The
+        random salt is included in the user record, so that whenever authentication is needed it can be
+        passed to the FIDO2 token again.</para>
+
+        <para>Instead of a valid path to a FIDO2 <literal>hidraw</literal> device the special strings
+        <literal>list</literal> and <literal>auto</literal> may be specified. If <literal>list</literal> is
+        passed, a brief table of suitable discovered FIDO2 devices is shown. If <literal>auto</literal> is
+        passed, a suitable FIDO2 token is automatically selected, if exactly one is discovered. The latter is
+        a useful shortcut for the most common case where a single FIDO2 hardware token is plugged in.</para>
+
+        <para>Note that FIDO2 devices suitable for this option must implement the
+        <literal>hmac-secret</literal> extension. Most current devices (such as the YubiKey 5 series) do. If
+        the extension is not implemented the device cannot be used for unlocking home directories.</para>
+
+        <para>The FIDO2 device may be subsequently removed by setting the device path to an empty string
+        (e.g. <command>homectl update $USER --fido2-device=""</command>).</para>
+
+        <para>Note that many hardware security tokens implement both FIDO2 and PKCS#11/PIV (and thus may be
+        used with either <option>--fido2-device=</option> or <option>--pkcs11-token-uri=</option>), for a
+        discussion see above.</para>
+
+        <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--fido2-with-client-pin=</option><replaceable>BOOL</replaceable></term>
+
+        <listitem><para>When enrolling a FIDO2 security token, controls whether to require the user to enter
+        a PIN when unlocking the account (the FIDO2 <literal>clientPin</literal> feature). Defaults to
+        <literal>yes</literal>. (Note: this setting is without effect if the security token does not support
+        the <literal>clientPin</literal> feature at all, or does not allow enabling or disabling
+        it.)</para>
+
+        <xi:include href="version-info.xml" xpointer="v249"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--fido2-with-user-presence=</option><replaceable>BOOL</replaceable></term>
+
+        <listitem><para>When enrolling a FIDO2 security token, controls whether to require the user to
+        verify presence (tap the token, the FIDO2 <literal>up</literal> feature) when unlocking the account.
+        Defaults to <literal>yes</literal>. (Note: this setting is without effect if the security token does not support
+        the <literal>up</literal> feature at all, or does not allow enabling or disabling it.)
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v249"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--fido2-with-user-verification=</option><replaceable>BOOL</replaceable></term>
+
+        <listitem><para>When enrolling a FIDO2 security token, controls whether to require user verification
+        when unlocking the account (the FIDO2 <literal>uv</literal> feature). Defaults to
+        <literal>no</literal>. (Note: this setting is without effect if the security token does not support
+        the <literal>uv</literal> feature at all, or does not allow enabling or disabling it.)</para>
+
+        <xi:include href="version-info.xml" xpointer="v249"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--recovery-key=</option><replaceable>BOOL</replaceable></term>
+
+        <listitem><para>Accepts a boolean argument. If enabled a recovery key is configured for the
+        account. A recovery key is a computer generated access key that may be used to regain access to an
+        account if the password has been forgotten or the authentication token lost. The key is generated and
+        shown on screen, and should be printed or otherwise transferred to a secure location. A recovery key
+        may be entered instead of a regular password to unlock the account.</para>
+
+        <xi:include href="version-info.xml" xpointer="v247"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--locked=</option><replaceable>BOOLEAN</replaceable></term>
+
+        <listitem><para>Takes a boolean argument. Specifies whether this user account shall be locked. If
+        true logins into this account are prohibited, if false (the default) they are permitted (of course,
+        only if authorization otherwise succeeds).</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--not-before=</option><replaceable>TIMESTAMP</replaceable></term>
+        <term><option>--not-after=</option><replaceable>TIMESTAMP</replaceable></term>
+
+        <listitem><para>These options take a timestamp string, in the format documented in
+        <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry> and
+        configures points in time before and after logins into this account are not
+        permitted.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--rate-limit-interval=</option><replaceable>SECS</replaceable></term>
+        <term><option>--rate-limit-burst=</option><replaceable>NUMBER</replaceable></term>
+
+        <listitem><para>Configures a rate limit on authentication attempts for this user. If the user
+        attempts to authenticate more often than the specified number, on a specific system, within the
+        specified time interval authentication is refused until the time interval passes. Defaults to 10
+        times per 1min.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--password-hint=</option><replaceable>TEXT</replaceable></term>
+
+        <listitem><para>Takes a password hint to store alongside the user record. This string is stored
+        accessible only to privileged users and the user itself and may not be queried by other users.
+        Example: <option>--password-hint="My first pet's name"</option>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--enforce-password-policy=</option><replaceable>BOOL</replaceable></term>
+        <term><option>-P</option></term>
+
+        <listitem><para>Takes a boolean argument. Configures whether to enforce the system's password policy
+        for this user, regarding quality and strength of selected passwords. Defaults to
+        on. <option>-P</option> is short for
+        <option>---enforce-password-policy=no</option>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--password-change-now=</option><replaceable>BOOL</replaceable></term>
+
+        <listitem><para>Takes a boolean argument. If true the user is asked to change their password on next
+        login.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--password-change-min=</option><replaceable>TIME</replaceable></term>
+        <term><option>--password-change-max=</option><replaceable>TIME</replaceable></term>
+        <term><option>--password-change-warn=</option><replaceable>TIME</replaceable></term>
+        <term><option>--password-change-inactive=</option><replaceable>TIME</replaceable></term>
+
+        <listitem><para>Each of these options takes a time span specification as argument (in the syntax
+        documented in
+        <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry>) and
+        configures various aspects of the user's password expiration policy. Specifically,
+        <option>--password-change-min=</option> configures how much time has to pass after changing the
+        password of the user until the password may be changed again. If the user tries to change their
+        password before this time passes the attempt is refused. <option>--password-change-max=</option>
+        configures how soon after it has been changed the password expires and needs to be changed again.
+        After this time passes logging in may only proceed after the password is changed.
+        <option>--password-change-warn=</option> specifies how much earlier than then the time configured
+        with <option>--password-change-max=</option> the user is warned at login to change their password as
+        it will expire soon. Finally <option>--password-change-inactive=</option> configures the time which
+        has to pass after the password as expired until the user is not permitted to log in or change the
+        password anymore. Note that these options only apply to password authentication, and do not apply to
+        other forms of authentication, for example PKCS#11-based security token
+        authentication.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--disk-size=</option><replaceable>BYTES</replaceable></term>
+        <listitem><para>Either takes a size in bytes as argument (possibly using the usual K, M, G, …
+        suffixes for 1024 base values), a percentage value, or the special strings <literal>min</literal> or
+        <literal>max</literal>, and configures the disk space to assign to the user. If a percentage value is
+        specified (i.e. the argument suffixed with <literal>%</literal>) it is taken relative to the
+        available disk space of the backing file system. If specified as <literal>min</literal> assigns the
+        minimal disk space permitted by the constraints of the backing file system and other limits, when
+        specified as <literal>max</literal> assigns the maximum disk space available. If the LUKS2 backend is
+        used this configures the size of the loopback file and file system contained therein. For the other
+        storage backends configures disk quota using the filesystem's native quota logic, if available. If
+        not specified, defaults to 85% of the available disk space for the LUKS2 backend and to no quota for
+        the others.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--access-mode=</option><replaceable>MODE</replaceable></term>
+
+        <listitem><para>Takes a UNIX file access mode written in octal. Configures the access mode of the
+        home directory itself. Note that this is only used when the directory is first created, and the user
+        may change this any time afterwards. Example:
+        <option>--access-mode=0700</option></para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--umask=</option><replaceable>MASK</replaceable></term>
+
+        <listitem><para>Takes the access mode mask (in octal syntax) to apply to newly created files and
+        directories of the user ("umask"). If set this controls the initial umask set for all login sessions of
+        the user, possibly overriding the system's defaults.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--nice=</option><replaceable>NICE</replaceable></term>
+
+        <listitem><para>Takes the numeric scheduling priority ("nice level") to apply to the processes of the user at login
+        time. Takes a numeric value in the range -20 (highest priority) to 19 (lowest priority).</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--rlimit=</option><replaceable>LIMIT</replaceable>=<replaceable>VALUE</replaceable><optional>:<replaceable>VALUE</replaceable></optional></term>
+
+        <listitem><para>Allows configuration of resource limits for processes of this user, see <citerefentry
+        project='man-pages'><refentrytitle>getrlimit</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+        for details. Takes a resource limit name (e.g. <literal>LIMIT_NOFILE</literal>) followed by an equal
+        sign, followed by a numeric limit. Optionally, separated by colon a second numeric limit may be
+        specified. If two are specified this refers to the soft and hard limits, respectively. If only one
+        limit is specified the setting sets both limits in one.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--tasks-max=</option><replaceable>TASKS</replaceable></term>
+
+        <listitem><para>Takes a non-zero unsigned integer as argument. Configures the maximum number of tasks
+        (i.e. threads, where each process is at least one thread) the user may have at any given time. This
+        limit applies to all tasks forked off the user's sessions, even if they change user identity via
+        <citerefentry project='man-pages'><refentrytitle>su</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+        or a similar tool. Use <option>--rlimit=LIMIT_NPROC=</option> to place a limit on the tasks actually
+        running under the UID of the user, thus excluding any child processes that might have changed user
+        identity. This controls the <varname>TasksMax=</varname> setting of the per-user systemd slice unit
+        <filename>user-$UID.slice</filename>. See
+        <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for further details.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--memory-high=</option><replaceable>BYTES</replaceable></term>
+        <term><option>--memory-max=</option><replaceable>BYTES</replaceable></term>
+
+        <listitem><para>Set a limit on the memory a user may take up on a system at any given time in bytes
+        (the usual K, M, G, … suffixes are supported, to the base of 1024). This includes all memory used by
+        the user itself and all processes they forked off that changed user credentials. This controls the
+        <varname>MemoryHigh=</varname> and <varname>MemoryMax=</varname> settings of the per-user systemd
+        slice unit <filename>user-$UID.slice</filename>. See
+        <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for further details.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--cpu-weight=</option><replaceable>WEIGHT</replaceable></term>
+        <term><option>--io-weight=</option><replaceable>WEIGHT</replaceable></term>
+
+        <listitem><para>Set CPU and IO scheduling weights of the processes of the user, including those of
+        processes forked off by the user that changed user credentials. Takes a numeric value in the range
+        1…10000. This controls the <varname>CPUWeight=</varname> and <varname>IOWeight=</varname> settings of
+        the per-user systemd slice unit <filename>user-$UID.slice</filename>. See
+        <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for further details.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--storage=</option><replaceable>STORAGE</replaceable></term>
+
+        <listitem><para>Selects the storage mechanism to use for this home directory. Takes one of
+        <literal>luks</literal>, <literal>fscrypt</literal>, <literal>directory</literal>,
+        <literal>subvolume</literal>, <literal>cifs</literal>. For details about these mechanisms, see
+        above. If a new home directory is created and the storage type is not specifically specified,
+        <citerefentry><refentrytitle>homed.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        defines which default storage to use.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--image-path=</option><replaceable>PATH</replaceable></term>
+
+        <listitem><para>Takes a file system path. Configures where to place the user's home directory. When
+        LUKS2 storage is used refers to the path to the loopback file, otherwise to the path to the home
+        directory (which may be in <filename>/home/</filename> or any other accessible filesystem). When
+        unspecified defaults to <filename>/home/$USER.home</filename> when LUKS storage is used and
+        <filename>/home/$USER.homedir</filename> for the other storage mechanisms. Not defined for the
+        <literal>cifs</literal> storage mechanism. To use LUKS2 storage on a regular block device (for
+        example a USB stick) pass the path to the block device here. Specifying the path to a directory here
+        when using LUKS2 storage is not allowed. Similar, specifying the path to a regular file or device
+        node is not allowed if any of the other storage backends are used.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--drop-caches=</option><replaceable>BOOL</replaceable></term>
+
+        <listitem><para>Automatically flush OS file system caches on logout. This is useful in combination
+        with the fscrypt storage backend to ensure the OS does not keep decrypted versions of the files and
+        directories in memory (and accessible) after logout. This option is also supported on other backends,
+        but should not bring any benefit there. Defaults to off, except if the selected storage backend is
+        fscrypt, where it defaults to on. Note that flushing OS caches will negatively influence performance
+        of the OS shortly after logout.</para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--fs-type=</option><replaceable>TYPE</replaceable></term>
+
+        <listitem><para>When LUKS2 storage is used configures the file system type to use inside the home
+        directory LUKS2 container. One of <literal>btrfs</literal>, <literal>ext4</literal>,
+        <literal>xfs</literal>. If not specified
+        <citerefentry><refentrytitle>homed.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        defines which default file system type to use. Note that <literal>xfs</literal> is not recommended as
+        its support for file system resizing is too limited.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--luks-discard=</option><replaceable>BOOL</replaceable></term>
+
+        <listitem><para>When LUKS2 storage is used configures whether to enable the
+        <literal>discard</literal> feature of the file system. If enabled the file system on top of the LUKS2
+        volume will report empty block information to LUKS2 and the loopback file below, ensuring that empty
+        space in the home directory is returned to the backing file system below the LUKS2 volume, resulting
+        in a "sparse" loopback file. This option mostly defaults to off, since this permits over-committing
+        home directories which results in I/O errors if the underlying file system runs full while the upper
+        file system wants to allocate a block. Such I/O errors are generally not handled well by file systems
+        nor applications. When LUKS2 storage is used on top of regular block devices (instead of on top a
+        loopback file) the discard logic defaults to on.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--luks-offline-discard=</option><replaceable>BOOL</replaceable></term>
+
+        <listitem><para>Similar to <option>--luks-discard=</option>, controls the trimming of the file
+        system. However, while <option>--luks-discard=</option> controls what happens when the home directory
+        is active, <option>--luks-offline-discard=</option> controls what happens when it becomes inactive,
+        i.e. whether to trim/allocate the storage when deactivating the home directory. This option defaults
+        to on, to ensure disk space is minimized while a user is not logged in.</para>
+
+        <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--luks-extra-mount-options=</option><replaceable>OPTIONS</replaceable></term>
+
+        <listitem><para>Takes a string containing additional mount options to use when mounting the LUKS
+        volume. If specified, this string will be appended to the default, built-in mount
+        options.</para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--luks-cipher=</option><replaceable>CIPHER</replaceable></term>
+        <term><option>--luks-cipher-mode=</option><replaceable>MODE</replaceable></term>
+        <term><option>--luks-volume-key-size=</option><replaceable>BYTES</replaceable></term>
+        <term><option>--luks-pbkdf-type=</option><replaceable>TYPE</replaceable></term>
+        <term><option>--luks-pbkdf-hash-algorithm=</option><replaceable>ALGORITHM</replaceable></term>
+        <term><option>--luks-pbkdf-force-iterations=</option><replaceable>ITERATIONS</replaceable></term>
+        <term><option>--luks-pbkdf-time-cost=</option><replaceable>SECONDS</replaceable></term>
+        <term><option>--luks-pbkdf-memory-cost=</option><replaceable>BYTES</replaceable></term>
+        <term><option>--luks-pbkdf-parallel-threads=</option><replaceable>THREADS</replaceable></term>
+        <term><option>--luks-sector-size=</option><replaceable>BYTES</replaceable></term>
+
+        <listitem><para>Configures various cryptographic parameters for the LUKS2 storage mechanism. See
+        <citerefentry
+        project='man-pages'><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        for details on the specific attributes.</para>
+
+        <para>Note that <command>homectl</command> uses bytes for key size, like
+        <filename>/proc/crypto</filename>, but <citerefentry
+        project='man-pages'><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        uses bits.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--auto-resize-mode=</option></term>
+
+        <listitem><para>Configures whether to automatically grow and/or shrink the backing file system on
+        login and logout. Takes one of the strings <literal>off</literal>, <literal>grow</literal>,
+        <literal>shrink-and-grow</literal>. Only applies to the LUKS2 backend currently, and if the btrfs
+        file system is used inside it (since only then online growing/shrinking of the file system is
+        supported). Defaults to <literal>shrink-and-grow</literal>, if LUKS2/btrfs is used, otherwise is
+        off. If set to <literal>off</literal> no automatic shrinking/growing during login or logout is
+        done. If set to <literal>grow</literal> the home area is grown to the size configured via
+        <option>--disk-size=</option> should it currently be smaller. If it already matches the configured
+        size or is larger no operation is executed. If set to <literal>shrink-and-grow</literal> the home
+        area is also resized during logout to the minimal size the used disk space and file system
+        constraints permit. This mode thus ensures that while a home area is activated it is sized to the
+        configured size, but while deactivated it is compacted taking up only the minimal space possible.
+        Note that if the system is powered off abnormally or if the user otherwise not logged out cleanly the
+        shrinking operation will not take place, and the user has to re-login/logout again before it is
+        executed again.</para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--rebalance-weight=</option></term>
+
+        <listitem><para>Configures the weight parameter for the free disk space rebalancing logic. Only
+        applies to the LUKS2 backend (since for the LUKS2 backend disk space is allocated from a per-user
+        loopback file system instead of immediately from a common pool like the other backends do it). In
+        regular intervals free disk space in the active home areas and their backing storage is redistributed
+        among them, taking the weight value configured here into account. Expects an integer in the range
+        1…10000, or the special string <literal>off</literal>. If not specified defaults to 100. The weight
+        is used to scale free space made available to the home areas: a home area with a weight of 200 will
+        get twice the free space as one with a weight of 100; a home area with a weight of 50 will get half
+        of that. The backing file system will be assigned space for a weight of 20. If set to
+        <literal>off</literal> no automatic free space distribution is done for this home area. Note that
+        resizing the home area explicitly (with <command>homectl resize</command> see below) will implicitly
+        turn off the automatic rebalancing. To reenable the automatic rebalancing use
+        <option>--rebalance-weight=</option> with an empty parameter.</para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--nosuid=</option><replaceable>BOOL</replaceable></term>
+        <term><option>--nodev=</option><replaceable>BOOL</replaceable></term>
+        <term><option>--noexec=</option><replaceable>BOOL</replaceable></term>
+
+        <listitem><para>Configures the <literal>nosuid</literal>, <literal>nodev</literal> and
+        <literal>noexec</literal> mount options for the home directories. By default <literal>nodev</literal>
+        and <literal>nosuid</literal> are on, while <literal>noexec</literal> is off. For details about these
+        mount options see <citerefentry
+        project='man-pages'><refentrytitle>mount</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--cifs-domain=</option><replaceable>DOMAIN</replaceable></term>
+        <term><option>--cifs-user-name=</option><replaceable>USER</replaceable></term>
+        <term><option>--cifs-service=</option><replaceable>SERVICE</replaceable></term>
+        <term><option>--cifs-extra-mount-options=</option><replaceable>OPTIONS</replaceable></term>
+
+        <listitem><para>Configures the Windows File Sharing (CIFS) domain and user to associate with the home
+        directory/user account, as well as the file share ("service") to mount as directory. The latter is
+        used when <literal>cifs</literal> storage is selected. The file share should be specified in format
+        <literal>//<replaceable>host</replaceable>/<replaceable>share</replaceable>/<replaceable>directory/…</replaceable></literal>. The
+        directory part is optional — if not specified the home directory will be placed in the top-level
+        directory of the share. The <option>--cifs-extra-mount-options=</option> setting allows specifying
+        additional mount options when mounting the share, see <citerefentry
+        project='man-pages'><refentrytitle>mount.cifs</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        for details.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--stop-delay=</option><replaceable>SECS</replaceable></term>
+
+        <listitem><para>Configures the time the per-user service manager shall continue to run after the all
+        sessions of the user ended. The default is configured in
+        <citerefentry><refentrytitle>logind.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> (for
+        home directories of LUKS2 storage located on removable media this defaults to 0 though). A longer
+        time makes sure quick, repetitive logins are more efficient as the user's service manager doesn't
+        have to be started every time.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--kill-processes=</option><replaceable>BOOL</replaceable></term>
+
+        <listitem><para>Configures whether to kill all processes of the user on logout. The default is
+        configured in
+        <citerefentry><refentrytitle>logind.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--auto-login=</option><replaceable>BOOL</replaceable></term>
+
+        <listitem><para>Takes a boolean argument. Configures whether the graphical UI of the system should
+        automatically log this user in if possible. Defaults to off. If less or more than one user is marked
+        this way automatic login is disabled.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Commands</title>
+
+    <para>The following commands are understood:</para>
+
+    <variablelist>
+
+      <varlistentry>
+        <term><command>list</command></term>
+
+        <listitem><para>List all home directories (along with brief details) currently managed by
+        <filename>systemd-homed.service</filename>. This command is also executed if none is specified on the
+        command line. (Note that the list of users shown by this command does not include users managed by
+        other subsystems, such as system users or any traditional users listed in
+        <filename>/etc/passwd</filename>.)</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>activate</command> <replaceable>USER</replaceable> [<replaceable>USER…</replaceable>]</term>
+
+        <listitem><para>Activate one or more home directories. The home directories of each listed user will
+        be activated and made available under their mount points (typically in
+        <filename>/home/$USER</filename>). Note that any home activated this way stays active indefinitely,
+        until it is explicitly deactivated again (with <command>deactivate</command>, see below), or the user
+        logs in and out again and it thus is deactivated due to the automatic deactivation-on-logout
+        logic.</para>
+
+        <para>Activation of a home directory involves various operations that depend on the selected storage
+        mechanism. If the LUKS2 mechanism is used, this generally involves: inquiring the user for a
+        password, setting up a loopback device, validating and activating the LUKS2 volume, checking the file
+        system, mounting the file system, and potentially changing the ownership of all included files to the
+        correct UID/GID.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>deactivate</command> <replaceable>USER</replaceable> [<replaceable>USER…</replaceable>]</term>
+
+        <listitem><para>Deactivate one or more home directories. This undoes the effect of
+        <command>activate</command>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>inspect</command> <replaceable>USER</replaceable> [<replaceable>USER…</replaceable>]</term>
+
+        <listitem><para>Show various details about the specified home directories. This shows various
+        information about the home directory and its user account, including runtime data such as current
+        state, disk use and similar. Combine with <option>--json=</option> to show the detailed JSON user
+        record instead, possibly combined with <option>--export-format=</option> to suppress certain aspects
+        of the output.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>authenticate</command> <replaceable>USER</replaceable> [<replaceable>USER…</replaceable>]</term>
+
+        <listitem><para>Validate authentication credentials of a home directory. This queries the caller for
+        a password (or similar) and checks that it correctly unlocks the home directory. This leaves the home
+        directory in the state it is in, i.e. it leaves the home directory in inactive state if it was
+        inactive before, and in active state if it was active before.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>create</command> <replaceable>USER</replaceable></term>
+        <term><command>create</command> <option>--identity=</option><replaceable>PATH</replaceable> <optional><replaceable>USER</replaceable></optional></term>
+
+        <listitem><para>Create a new home directory/user account of the specified name. Use the various
+        user record property options (as documented above) to control various aspects of the home directory
+        and its user accounts.</para>
+
+        <para>The specified user name should follow the strict syntax described on <ulink
+        url="https://systemd.io/USER_NAMES">User/Group Name Syntax</ulink>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>remove</command> <replaceable>USER</replaceable></term>
+
+        <listitem><para>Remove a home directory/user account. This will remove both the home directory's user
+        record and the home directory itself, and thus delete all files and directories owned by the
+        user.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>update</command> <replaceable>USER</replaceable></term>
+        <term><command>update</command> <option>--identity=</option><replaceable>PATH</replaceable> <optional><replaceable>USER</replaceable></optional></term>
+
+        <listitem><para>Update a home directory/user account. Use the various user record property options
+        (as documented above) to make changes to the account, or alternatively provide a full, updated JSON
+        user record via the <option>--identity=</option> option.</para>
+
+        <para>Note that changes to user records not signed by a cryptographic private key available locally
+        are not permitted, unless <option>--identity=</option> is used with a user record that is already
+        correctly signed by a recognized private key.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>passwd</command> <replaceable>USER</replaceable></term>
+
+        <listitem><para>Change the password of the specified home directory/user account.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>resize</command> <replaceable>USER</replaceable> <replaceable>BYTES</replaceable></term>
+
+        <listitem><para>Change the disk space assigned to the specified home directory. If the LUKS2 storage
+        mechanism is used this will automatically resize the loopback file and the file system contained
+        within. Note that if <literal>ext4</literal> is used inside of the LUKS2 volume, it is necessary to
+        deactivate the home directory before shrinking it (i.e the user has to log out). Growing can be done
+        while the home directory is active. If <literal>xfs</literal> is used inside of the LUKS2 volume the
+        home directory may not be shrunk whatsoever. On all three of <literal>ext4</literal>,
+        <literal>xfs</literal> and <literal>btrfs</literal> the home directory may be grown while the user is
+        logged in, and on the latter also shrunk while the user is logged in. If the
+        <literal>subvolume</literal>, <literal>directory</literal>, <literal>fscrypt</literal> storage
+        mechanisms are used, resizing will change file system quota. The size parameter may make use of the
+        usual suffixes B, K, M, G, T (to the base of 1024). The special strings <literal>min</literal> and
+        <literal>max</literal> may be specified in place of a numeric size value, for minimizing or
+        maximizing disk space assigned to the home area, taking constraints of the file system, disk usage inside
+        the home area and on the backing storage into account.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>lock</command> <replaceable>USER</replaceable></term>
+
+        <listitem><para>Temporarily suspend access to the user's home directory and remove any associated
+        cryptographic keys from memory. Any attempts to access the user's home directory will stall until the
+        home directory is unlocked again (i.e. re-authenticated). This functionality is primarily intended to
+        be used during system suspend to make sure the user's data cannot be accessed until the user
+        re-authenticates on resume. This operation is only defined for home directories that use the LUKS2
+        storage mechanism.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>unlock</command> <replaceable>USER</replaceable></term>
+
+        <listitem><para>Resume access to the user's home directory again, undoing the effect of
+        <command>lock</command> above. This requires authentication of the user, as the cryptographic keys
+        required for access to the home directory need to be reacquired.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>lock-all</command></term>
+
+        <listitem><para>Execute the <command>lock</command> command on all suitable home directories at
+        once. This operation is generally executed on system suspend (i.e. by <command>systemctl
+        suspend</command> and related commands), to ensure all active user's cryptographic keys for accessing
+        their home directories are removed from memory.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>deactivate-all</command></term>
+
+        <listitem><para>Execute the <command>deactivate</command> command on all active home directories at
+        once. This operation is generally executed on system shut down (i.e. by <command>systemctl
+        poweroff</command> and related commands), to ensure all active user's home directories are fully
+        deactivated before <filename>/home/</filename> and related file systems are unmounted.</para>
+
+        <xi:include href="version-info.xml" xpointer="v247"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>with</command> <replaceable>USER</replaceable> <replaceable>COMMAND…</replaceable></term>
+
+        <listitem><para>Activate the specified user's home directory, run the specified command (under the
+        caller's identity, not the specified user's) and deactivate the home directory afterwards again
+        (unless the user is logged in otherwise). This command is useful for running privileged backup
+        scripts and such, but requires authentication with the user's credentials in order to be able to
+        unlock the user's home directory.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>rebalance</command></term>
+
+        <listitem><para>Rebalance free disk space between active home areas and the backing storage. See
+        <option>--rebalance-weight=</option> above. This executes no operation unless there's at least one
+        active LUKS2 home area that has disk space rebalancing enabled. This operation is synchronous: it
+        will only complete once disk space is rebalanced according to the rebalancing weights. Note that
+        rebalancing also takes place automatically in the background in regular intervals. Use this command
+        to synchronously ensure disk space is properly redistributed before initiating an operation requiring
+        large amounts of disk space.</para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Exit status</title>
+
+    <para>On success, 0 is returned, a non-zero failure code otherwise.</para>
+
+    <para>When a command is invoked with <command>with</command>, the exit status of the child is
+    propagated. Effectively, <command>homectl</command> will exit without error if the command is
+    successfully invoked <emphasis>and</emphasis> finishes successfully.</para>
+  </refsect1>
+
+  <xi:include href="common-variables.xml" />
+
+  <refsect1>
+    <title>Examples</title>
+
+    <example>
+      <title>Create a user <literal>waldo</literal> in the administrator group <literal>wheel</literal>, and
+      assign 500 MiB disk space to them.</title>
+
+      <programlisting>homectl create waldo --real-name="Waldo McWaldo" -G wheel --disk-size=500M</programlisting>
+    </example>
+
+    <example>
+      <title>Create a user <literal>wally</literal> on a USB stick, and assign a maximum of 500 concurrent
+      tasks to them.</title>
+
+      <programlisting>homectl create wally --real-name="Wally McWally" --image-path=/dev/disk/by-id/usb-SanDisk_Ultra_Fit_476fff954b2b5c44-0:0 --tasks-max=500</programlisting>
+    </example>
+
+    <example>
+      <title>Change nice level of user <literal>odlaw</literal> to +5 and make sure the environment variable
+      <varname>$SOME</varname> is set to the string <literal>THING</literal> for them on login.</title>
+
+      <programlisting>homectl update odlaw --nice=5 --setenv=SOME=THING</programlisting>
+    </example>
+
+    <example>
+      <title>Set up authentication with a YubiKey security token using PKCS#11/PIV:</title>
+
+      <programlisting># Clear the Yubikey from any old keys (careful!)
+ykman piv reset
+
+# Generate a new private/public key pair on the device, store the public key in 'pubkey.pem'.
+ykman piv generate-key -a RSA2048 9d pubkey.pem
+
+# Create a self-signed certificate from this public key, and store it on the device.
+ykman piv generate-certificate --subject "Knobelei" 9d pubkey.pem
+
+# We don't need the public key on disk anymore
+rm pubkey.pem
+
+# Allow the security token to unlock the account of user 'lafcadio'.
+homectl update lafcadio --pkcs11-token-uri=auto</programlisting>
+    </example>
+
+    <example>
+      <title>Set up authentication with a FIDO2 security token:</title>
+
+      <programlisting># Allow a FIDO2 security token to unlock the account of user 'nihilbaxter'.
+homectl update nihilbaxter --fido2-device=auto</programlisting>
+    </example>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-homed.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>homed.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>userdbctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>useradd</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/homed.conf.xml b/man/homed.conf.xml
new file mode 100644
index 0000000..acc5f5f
--- /dev/null
+++ b/man/homed.conf.xml
@@ -0,0 +1,88 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="homed.conf" conditional='ENABLE_HOMED'
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+  <refentryinfo>
+    <title>homed.conf</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>homed.conf</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>homed.conf</refname>
+    <refname>homed.conf.d</refname>
+    <refpurpose>Home area/user account manager configuration files</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>/etc/systemd/homed.conf</filename></para>
+    <para><filename>/etc/systemd/homed.conf.d/*.conf</filename></para>
+    <para><filename>/run/systemd/homed.conf.d/*.conf</filename></para>
+    <para><filename>/usr/lib/systemd/homed.conf.d/*.conf</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>These configuration files control default parameters for home areas/user accounts created and
+    managed by
+    <citerefentry><refentrytitle>systemd-homed.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
+
+  </refsect1>
+
+  <xi:include href="standard-conf.xml" xpointer="main-conf" />
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>The following options are available in the [Home] section:</para>
+
+    <variablelist class='home-directives'>
+
+      <varlistentry>
+        <term><varname>DefaultStorage=</varname></term>
+        <listitem><para>The default storage to use for home areas. Takes one of <literal>luks</literal>,
+        <literal>fscrypt</literal>, <literal>directory</literal>, <literal>subvolume</literal>,
+        <literal>cifs</literal>. For details about these options, see
+        <citerefentry><refentrytitle>homectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>. If not
+        configured or assigned the empty string, the default storage is automatically determined: if not
+        running in a container environment and <filename>/home/</filename> is not itself encrypted, defaults
+        to <literal>luks</literal>. Otherwise defaults to <literal>subvolume</literal> if
+        <filename>/home/</filename> is on a btrfs file system, and <literal>directory</literal>
+        otherwise. Note that the storage selected on the <command>homectl</command> command line always takes
+        precedence.</para>
+
+        <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>DefaultFileSystemType=</varname></term>
+        <listitem><para>When using <literal>luks</literal> as storage (see above), selects the default file
+        system to use inside the user's LUKS volume. Takes one of <literal>btrfs</literal>,
+        <literal>ext4</literal> or <literal>xfs</literal>. If not specified defaults to
+        <literal>btrfs</literal>. This setting has no effect if a different storage mechanism is used. The
+        file system type selected on the <command>homectl</command> command line always takes
+        precedence.</para>
+
+        <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+      </varlistentry>
+
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+      <title>See Also</title>
+      <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-homed.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+      </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/hostname.xml b/man/hostname.xml
new file mode 100644
index 0000000..a3dae72
--- /dev/null
+++ b/man/hostname.xml
@@ -0,0 +1,116 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [
+<!ENTITY % entities SYSTEM "custom-entities.ent" >
+%entities;
+]>
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="hostname">
+  <refentryinfo>
+    <title>hostname</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>hostname</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>hostname</refname>
+    <refpurpose>Local hostname configuration file</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>/etc/hostname</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>The <filename>/etc/hostname</filename> file configures the name of the local system. Unless
+    overridden as described in the next section,
+    <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> will set this
+    hostname during boot using the
+    <citerefentry><refentrytitle>sethostname</refentrytitle><manvolnum>2</manvolnum></citerefentry> system
+    call.</para>
+
+    <para>The file should contain a single newline-terminated hostname string. Comments (lines starting with
+    a <literal>#</literal>) are ignored. The hostname should be composed of up to 64 7-bit ASCII lower-case
+    alphanumeric characters or hyphens forming a valid DNS domain name. It is recommended that this name
+    contains only a single label, i.e. without any dots. Invalid characters will be filtered out in an
+    attempt to make the name valid, but obviously it is recommended to use a valid name and not rely on this
+    filtering.</para>
+
+    <para>You may use
+    <citerefentry><refentrytitle>hostnamectl</refentrytitle><manvolnum>1</manvolnum></citerefentry> to change
+    the value of this file during runtime from the command line. Use
+    <citerefentry><refentrytitle>systemd-firstboot</refentrytitle><manvolnum>1</manvolnum></citerefentry> to
+    initialize it on mounted (but not booted) system images.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Hostname semantics</title>
+
+    <para><citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> and the
+    associated tools will obtain the hostname in the following ways:</para>
+    <itemizedlist>
+      <listitem><para>If the kernel command line parameter <varname>systemd.hostname=</varname> specifies a
+      valid hostname,
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> will use it
+      to set the hostname during early boot, see
+      <citerefentry><refentrytitle>kernel-command-line</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      </para></listitem>
+
+      <listitem><para>Otherwise, the "static" hostname specified by <filename>/etc/hostname</filename> as
+      described above will be used.</para></listitem>
+
+      <listitem><para>Otherwise, a transient hostname may be set during runtime, for example based on
+      information in a DHCP lease, see
+      <citerefentry><refentrytitle>systemd-hostnamed.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+      Both <ulink url="https://developer.gnome.org/NetworkManager/stable/">NetworkManager</ulink> and
+      <citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+      allow this. Note that
+      <citerefentry><refentrytitle>systemd-hostnamed.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+      gives higher priority to the static hostname, so the transient hostname will only be used if the static
+      hostname is not configured.</para></listitem>
+
+      <listitem><para>Otherwise, a fallback hostname configured at compilation time will be used
+      (<literal>&FALLBACK_HOSTNAME;</literal>).</para></listitem>
+
+      <!-- what about the "linux" fallback fallback? -->
+    </itemizedlist>
+
+    <para>Effectively, the static hostname has higher priority than a transient hostname, which has higher
+    priority than the fallback hostname. Transient hostnames are equivalent, so setting a new transient
+    hostname causes the previous transient hostname to be forgotten. The hostname specified on the kernel
+    command line is like a transient hostname, with the exception that it has higher priority when the
+    machine boots. Also note that those are the semantics implemented by systemd tools, but other programs
+    may also set the hostname.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>History</title>
+
+    <para>The simple configuration file format of
+    <filename>/etc/hostname</filename> originates from Debian
+    GNU/Linux.</para>
+  </refsect1>
+
+  <refsect1>
+      <title>See Also</title>
+      <para>
+        <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>sethostname</refentrytitle><manvolnum>2</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>hostname</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>hostname</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>machine-info</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>hostnamectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd-hostnamed.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd-firstboot</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+      </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/hostnamectl.xml b/man/hostnamectl.xml
new file mode 100644
index 0000000..85594b0
--- /dev/null
+++ b/man/hostnamectl.xml
@@ -0,0 +1,227 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [
+<!ENTITY % entities SYSTEM "custom-entities.ent" >
+%entities;
+]>
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="hostnamectl" conditional='ENABLE_HOSTNAMED'
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>hostnamectl</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>hostnamectl</refentrytitle>
+    <manvolnum>1</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>hostnamectl</refname>
+    <refpurpose>Control the system hostname</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <cmdsynopsis>
+      <command>hostnamectl</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="req">COMMAND</arg>
+    </cmdsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>hostnamectl</command> may be used to query and change the system hostname and related
+    settings.</para>
+
+    <para><citerefentry><refentrytitle>systemd-hostnamed.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    and this tool distinguish three different hostnames: the high-level "pretty" hostname which might include
+    all kinds of special characters (e.g. "Lennart's Laptop"), the "static" hostname which is the
+    user-configured hostname (e.g. "lennarts-laptop"), and the transient hostname which is a fallback value
+    received from network configuration (e.g. "node12345678"). If a static hostname is set to a valid value,
+    then the transient hostname is not used.</para>
+
+    <para>Note that the pretty hostname has little restrictions on the characters and length used, while the static and
+    transient hostnames are limited to the usually accepted characters of Internet domain names, and 64 characters at
+    maximum (the latter being a Linux limitation).</para>
+
+    <para>Use
+    <citerefentry><refentrytitle>systemd-firstboot</refentrytitle><manvolnum>1</manvolnum></citerefentry> to
+    initialize the system hostname for mounted (but not booted) system images.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Commands</title>
+
+    <para>The following commands are understood:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><command>status</command></term>
+
+        <listitem><para>Show system hostname and related information. If no command is specified,
+        this is the implied default.</para>
+
+        <xi:include href="version-info.xml" xpointer="v195"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>hostname</command> [<replaceable>NAME</replaceable>]</term>
+
+        <listitem><para>If no argument is given, print the system hostname. If an
+        optional argument <replaceable>NAME</replaceable> is provided then the command changes the
+        system hostname to <replaceable>NAME</replaceable>. By default, this will alter the
+        pretty, the static, and the transient hostname alike; however, if one or more of <option>--static</option>,
+        <option>--transient</option>, <option>--pretty</option> are used, only the selected hostnames are changed. If
+        the pretty hostname is being set, and static or transient are being set as well, the specified hostname will be
+        simplified in regards to the character set used before the latter are updated. This is done by removing special
+        characters and spaces. This ensures that the pretty and the static hostname are always closely related while
+        still following the validity rules of the specific name. This simplification of the hostname string is not done
+        if only the transient and/or static hostnames are set, and the pretty hostname is left untouched.</para>
+
+        <para>The static and transient hostnames must each be either a single DNS label (a string composed of
+        7-bit ASCII lower-case characters and no spaces or dots, limited to the format allowed for DNS domain
+        name labels), or a sequence of such labels separated by single dots that forms a valid DNS FQDN. The
+        hostname must be at most 64 characters, which is a Linux limitation (DNS allows longer names).</para>
+
+        <xi:include href="version-info.xml" xpointer="v249"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>icon-name</command> [<replaceable>NAME</replaceable>]</term>
+
+        <listitem><para>If no argument is given, print the icon name of the system. If an
+        optional argument <replaceable>NAME</replaceable> is provided then the command changes the
+        icon name to <replaceable>NAME</replaceable>. The icon name is used by some
+        graphical applications to visualize this host. The icon name
+        should follow the <ulink
+        url="https://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html">Icon
+        Naming Specification</ulink>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v249"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>chassis</command> [<replaceable>TYPE</replaceable>]</term>
+
+        <listitem><para>If no argument is given, print the chassis type. If an
+        optional argument <replaceable>TYPE</replaceable> is provided then the command changes the
+        chassis type to <replaceable>TYPE</replaceable>. The chassis type is used by
+        some graphical applications to visualize the host or alter user interaction.
+        Currently, the following chassis types are defined:
+        <literal>desktop</literal>,
+        <literal>laptop</literal>,
+        <literal>convertible</literal>,
+        <literal>server</literal>,
+        <literal>tablet</literal>,
+        <literal>handset</literal>,
+        <literal>watch</literal>,
+        <literal>embedded</literal>,
+        as well as the special chassis types
+        <literal>vm</literal> and
+        <literal>container</literal> for virtualized systems that lack
+        an immediate physical chassis.</para>
+
+        <xi:include href="version-info.xml" xpointer="v249"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>deployment</command> [<replaceable>ENVIRONMENT</replaceable>]</term>
+
+        <listitem><para>If no argument is given, print the deployment environment. If an
+        optional argument <replaceable>ENVIRONMENT</replaceable> is provided then the command changes the
+        deployment environment to <replaceable>ENVIRONMENT</replaceable>.
+        Argument <replaceable>ENVIRONMENT</replaceable>
+        must be a single word without any control characters. One of the following is suggested:
+        <literal>development</literal>,
+        <literal>integration</literal>,
+        <literal>staging</literal>,
+        <literal>production</literal>.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v249"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>location</command> [<replaceable>LOCATION</replaceable>]</term>
+
+        <listitem><para>If no argument is given, print the location string for the system. If an
+        optional argument <replaceable>LOCATION</replaceable> is provided then the command changes the
+        location string for the system to <replaceable>LOCATION</replaceable>.
+        Argument <replaceable>LOCATION</replaceable> should be a
+        human-friendly, free-form string describing the physical
+        location of the system, if it is known and applicable. This
+        may be as generic as <literal>Berlin, Germany</literal> or as
+        specific as <literal>Left Rack, 2nd Shelf</literal>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v249"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>The following options are understood:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><option>--no-ask-password</option></term>
+
+        <listitem><para>Do not query the user for authentication for
+        privileged operations.</para>
+
+        <xi:include href="version-info.xml" xpointer="v195"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--static</option></term>
+        <term><option>--transient</option></term>
+        <term><option>--pretty</option></term>
+
+        <listitem><para>If <command>status</command> is invoked (or no explicit command is given) and one of these
+        switches is specified, <command>hostnamectl</command> will print out just this selected hostname.</para>
+
+        <para>If used with <command>hostname</command>, only the selected hostnames will be updated. When more
+        than one of these switches are specified, all the specified hostnames will be updated. </para>
+
+        <xi:include href="version-info.xml" xpointer="v195"/></listitem>
+      </varlistentry>
+
+      <xi:include href="user-system-options.xml" xpointer="host" />
+      <xi:include href="user-system-options.xml" xpointer="machine" />
+
+      <xi:include href="standard-options.xml" xpointer="help" />
+      <xi:include href="standard-options.xml" xpointer="version" />
+      <xi:include href="standard-options.xml" xpointer="json" />
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Exit status</title>
+
+    <para>On success, 0 is returned, a non-zero failure code
+    otherwise.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>hostname</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>hostname</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>machine-info</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-hostnamed.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-firstboot</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/html.in b/man/html.in
new file mode 100755
index 0000000..aaff9d1
--- /dev/null
+++ b/man/html.in
@@ -0,0 +1,29 @@
+#!/bin/sh
+# SPDX-License-Identifier: LGPL-2.1-or-later
+set -e
+
+if [ -z "$1" ]; then
+    echo "Use: $0 page-name (with no section suffix)"
+    exit 1
+fi
+
+# make sure the rules have been regenerated (in case update-man-rules was just run)
+ninja -C "@BUILD_ROOT@" version.h
+
+target="man/$1.html"
+ninja -C "@BUILD_ROOT@" "$target"
+
+fullname="@BUILD_ROOT@/$target"
+if [ -f "$fullname" ]; then
+    redirect="$(readlink "$fullname" || :)"
+else
+    redirect=""
+fi
+if [ -n "$redirect" ]; then
+    ninja -C "@BUILD_ROOT@" "man/$redirect"
+
+    fullname="@BUILD_ROOT@/man/$redirect"
+fi
+
+set -x
+exec xdg-open "$fullname"
diff --git a/man/hwdb-usb-device.c b/man/hwdb-usb-device.c
new file mode 100644
index 0000000..19a5db8
--- /dev/null
+++ b/man/hwdb-usb-device.c
@@ -0,0 +1,30 @@
+/* SPDX-License-Identifier: MIT-0 */
+
+#include <stdio.h>
+#include <stdint.h>
+#include <sd-hwdb.h>
+
+int print_usb_properties(uint16_t vid, uint16_t pid) {
+  char match[STRLEN("usb:vp") + DECIMAL_STR_MAX(uint16_t) * 2];
+  sd_hwdb *hwdb;
+  const char *key, *value;
+  int r;
+
+  /* Match this USB vendor and product ID combination */
+  xsprintf(match, "usb:v%04Xp%04X", vid, pid);
+
+  r = sd_hwdb_new(&hwdb);
+  if (r < 0)
+    return r;
+
+  SD_HWDB_FOREACH_PROPERTY(hwdb, match, key, value)
+    printf("%s: \"%s\" → \"%s\"\n", match, key, value);
+
+  sd_hwdb_unref(hwdb);
+  return 0;
+}
+
+int main(int argc, char **argv) {
+  print_usb_properties(0x046D, 0xC534);
+  return 0;
+}
diff --git a/man/hwdb.xml b/man/hwdb.xml
new file mode 100644
index 0000000..4efa375
--- /dev/null
+++ b/man/hwdb.xml
@@ -0,0 +1,154 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="hwdb" conditional="ENABLE_HWDB">
+  <refentryinfo>
+    <title>hwdb</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>hwdb</refentrytitle>
+    <manvolnum>7</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>hwdb</refname>
+    <refpurpose>Hardware Database</refpurpose>
+  </refnamediv>
+
+  <refsect1><title>Description</title>
+    <para>The hardware database is a key-value store for associating modalias-like keys to
+    udev-property-like values. It is used primarily by udev to add the relevant properties
+    to matching devices, but it can also be queried directly.</para>
+  </refsect1>
+
+  <refsect1><title>Hardware Database Files</title>
+      <para>The hwdb files are read from the files located in the
+      system hwdb directory <filename>/usr/lib/udev/hwdb.d</filename> and
+      the local administration directory <filename>/etc/udev/hwdb.d</filename>.
+      All hwdb files are collectively sorted and processed in lexical order,
+      regardless of the directories in which they live. However, files with
+      identical filenames replace each other. Files in <filename>/etc/</filename>
+      have the highest priority and take precedence over files with the same
+      name in <filename>/usr/lib/</filename>. This can be used to override a
+      system-supplied hwdb file with a local file if needed;
+      a symlink in <filename>/etc/</filename> with the same name as a hwdb file in
+      <filename>/usr/lib/</filename>, pointing to <filename>/dev/null</filename>,
+      disables that hwdb file entirely. hwdb files must have the extension
+      <filename>.hwdb</filename>; other extensions are ignored.</para>
+
+      <para>Each hwdb file contains data records consisting of matches and associated
+      key-value pairs. Every record in the hwdb starts with one or more match strings,
+      specifying a shell glob to compare the lookup string against. Multiple match lines
+      are specified in consecutive lines. Every match line is compared individually, and
+      they are combined by OR. Every match line must start at the first character of the
+      line.</para>
+
+      <para>Match patterns consist of literal characters, and shell-style wildcards:</para>
+      <itemizedlist>
+        <listitem><para>Asterisk <literal>*</literal> matches any number of characters
+        </para></listitem>
+        <listitem><para>Question mark <literal>?</literal> matches a single character
+        </para></listitem>
+        <listitem><para>Character list <literal>[<replaceable>chars</replaceable>]</literal> matches one of
+        the characters <replaceable>chars</replaceable> listed between <literal>[</literal> and
+        <literal>]</literal>. A range may be specified as with a dash as
+        <literal>[<replaceable>first</replaceable>-<replaceable>last</replaceable>]</literal>. The match may
+        be inverted with a caret <literal>[^…]</literal>.</para></listitem>
+      </itemizedlist>
+
+      <para>The match lines are followed by one or more key-value pair lines, which are
+      recognized by a leading space character. The key name and value are separated by
+      <literal>=</literal>. An empty line signifies the end of a record. Lines beginning
+      with <literal>#</literal> are ignored.</para>
+
+      <para>In case multiple records match a given lookup string, the key-value pairs
+      from all records are combined. If a key is specified multiple times, the value
+      from the record with the highest priority is used (each key can have only a single
+      value). The priority is higher when the record is in a file that sorts later
+      lexicographically, and in case of records in the same file, later records have
+      higher priority.</para>
+
+      <para>The content of all hwdb files is read by
+      <citerefentry><refentrytitle>systemd-hwdb</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+      and compiled to a binary database located at <filename>/etc/udev/hwdb.bin</filename>,
+      or alternatively <filename>/usr/lib/udev/hwdb.bin</filename> if you want ship the
+      compiled database in an immutable image.  During runtime, only the binary database
+      is used.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Examples</title>
+
+    <example>
+      <title>General syntax of hwdb files</title>
+
+      <programlisting># /usr/lib/udev/hwdb.d/example.hwdb
+# Comments can be placed before any records. This is a good spot
+# to describe what that file is used for, what kind of properties
+# it defines, and the ordering convention.
+
+# A record with three matches and one property
+mouse:*:name:*Trackball*:*
+mouse:*:name:*trackball*:*
+mouse:*:name:*TrackBall*:*
+ ID_INPUT_TRACKBALL=1
+
+# The rule above could be also be written in a form that
+# matches Tb, tb, TB, tB:
+mouse:*:name:*[tT]rack[bB]all*:*
+ ID_INPUT_TRACKBALL=1
+
+# A record with a single match and five properties
+mouse:usb:v046dp4041:name:Logitech MX Master:*
+ MOUSE_DPI=1000@166
+ MOUSE_WHEEL_CLICK_ANGLE=15
+ MOUSE_WHEEL_CLICK_ANGLE_HORIZONTAL=26
+ MOUSE_WHEEL_CLICK_COUNT=24
+ MOUSE_WHEEL_CLICK_COUNT_HORIZONTAL=14
+</programlisting>
+    </example>
+
+    <example>
+      <title>Overriding of properties</title>
+
+      <programlisting># /usr/lib/udev/hwdb.d/60-keyboard.hwdb
+evdev:atkbd:dmi:bvn*:bvr*:bd*:svnAcer*:pn*:*
+ KEYBOARD_KEY_a1=help
+ KEYBOARD_KEY_a2=setup
+ KEYBOARD_KEY_a3=battery
+
+# Match vendor name "Acer" and any product name starting with "X123"
+evdev:atkbd:dmi:bvn*:bvr*:bd*:svnAcer:pnX123*:*
+ KEYBOARD_KEY_a2=wlan
+
+# /etc/udev/hwdb.d/70-keyboard.hwdb
+# disable wlan key on all at keyboards
+evdev:atkbd:*
+ KEYBOARD_KEY_a2=reserved
+ PROPERTY_WITH_SPACES=some string</programlisting>
+
+      <para>If the hwdb consists of those two files, a keyboard with the lookup string
+      <literal>evdev:atkbd:dmi:bvnAcer:bvr:bdXXXXX:bd08/05/2010:svnAcer:pnX123:</literal>
+      will match all three records, and end up with the following properties:</para>
+
+      <programlisting>KEYBOARD_KEY_a1=help
+KEYBOARD_KEY_a2=reserved
+KEYBOARD_KEY_a3=battery
+PROPERTY_WITH_SPACES=some string</programlisting>
+
+    </example>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry>
+        <refentrytitle>systemd-hwdb</refentrytitle><manvolnum>8</manvolnum>
+      </citerefentry>
+    </para>
+  </refsect1>
+</refentry>
diff --git a/man/id128-app-specific.c b/man/id128-app-specific.c
new file mode 100644
index 0000000..b8982c7
--- /dev/null
+++ b/man/id128-app-specific.c
@@ -0,0 +1,13 @@
+/* SPDX-License-Identifier: MIT-0 */
+
+#include <stdio.h>
+#include <systemd/sd-id128.h>
+
+#define OUR_APPLICATION_ID SD_ID128_MAKE(c2,73,27,73,23,db,45,4e,a6,3b,b9,6e,79,b5,3e,97)
+
+int main(int argc, char *argv[]) {
+  sd_id128_t id;
+  sd_id128_get_machine_app_specific(OUR_APPLICATION_ID, &id);
+  printf("Our application ID: " SD_ID128_FORMAT_STR "\n", SD_ID128_FORMAT_VAL(id));
+  return 0;
+}
diff --git a/man/inotify-watch-tmp.c b/man/inotify-watch-tmp.c
new file mode 100644
index 0000000..07ee8f6
--- /dev/null
+++ b/man/inotify-watch-tmp.c
@@ -0,0 +1,58 @@
+/* SPDX-License-Identifier: MIT-0 */
+
+#include <stdio.h>
+#include <string.h>
+#include <sys/inotify.h>
+
+#include <systemd/sd-event.h>
+
+#define _cleanup_(f) __attribute__((cleanup(f)))
+
+static int inotify_handler(sd_event_source *source,
+                           const struct inotify_event *event,
+                           void *userdata) {
+
+  const char *desc = NULL;
+
+  sd_event_source_get_description(source, &desc);
+
+  if (event->mask & IN_Q_OVERFLOW)
+    printf("inotify-handler <%s>: overflow\n", desc);
+  else if (event->mask & IN_CREATE)
+    printf("inotify-handler <%s>: create on %s\n", desc, event->name);
+  else if (event->mask & IN_DELETE)
+    printf("inotify-handler <%s>: delete on %s\n", desc, event->name);
+  else if (event->mask & IN_MOVED_TO)
+    printf("inotify-handler <%s>: moved-to on %s\n", desc, event->name);
+
+  /* Terminate the program if an "exit" file appears */
+  if ((event->mask & (IN_CREATE|IN_MOVED_TO)) &&
+      strcmp(event->name, "exit") == 0)
+    sd_event_exit(sd_event_source_get_event(source), 0);
+
+  return 1;
+}
+
+int main(int argc, char **argv) {
+  _cleanup_(sd_event_unrefp) sd_event *event = NULL;
+  _cleanup_(sd_event_source_unrefp) sd_event_source *source1 = NULL, *source2 = NULL;
+
+  const char *path1 = argc > 1 ? argv[1] : "/tmp";
+  const char *path2 = argc > 2 ? argv[2] : NULL;
+
+  /* Note: failure handling is omitted for brevity */
+
+  sd_event_default(&event);
+
+  sd_event_add_inotify(event, &source1, path1,
+                       IN_CREATE | IN_DELETE | IN_MODIFY | IN_MOVED_TO,
+                       inotify_handler, NULL);
+  if (path2)
+    sd_event_add_inotify(event, &source2, path2,
+                         IN_CREATE | IN_DELETE | IN_MODIFY | IN_MOVED_TO,
+                         inotify_handler, NULL);
+
+  sd_event_loop(event);
+
+  return 0;
+}
diff --git a/man/integritytab.xml b/man/integritytab.xml
new file mode 100644
index 0000000..a4b18af
--- /dev/null
+++ b/man/integritytab.xml
@@ -0,0 +1,187 @@
+<?xml version="1.0"?>
+<!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!--
+  SPDX-License-Identifier: LGPL-2.1-or-later
+
+-->
+<refentry id="integritytab" conditional='HAVE_LIBCRYPTSETUP' xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>integritytab</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>integritytab</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>integritytab</refname>
+    <refpurpose>Configuration for integrity block devices</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>/etc/integritytab</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>The <filename>/etc/integritytab</filename> file describes
+    integrity protected block devices that are set up during
+    system boot.</para>
+
+    <para>Empty lines and lines starting with the <literal>#</literal>
+    character are ignored. Each of the remaining lines describes one
+    verity integrity protected block device. Fields are delimited by
+    white space.</para>
+
+    <para>Each line is in the form<programlisting><replaceable>volume-name</replaceable> <replaceable>block-device</replaceable>
+    <replaceable>[keyfile|-]</replaceable> <replaceable>[options|-]</replaceable></programlisting>
+    The first two fields are mandatory, the remaining two are optional and only required if user specified non-default options during integrity format.</para>
+
+    <para>The first field contains the name of the resulting integrity volume; its block device is set up
+    below <filename>/dev/mapper/</filename>.</para>
+
+    <para>The second field contains a path to the underlying block device, or a specification of a block device via
+    <literal>UUID=</literal> followed by the UUID,
+    <literal>PARTUUID=</literal> followed by the partition UUID,
+    <literal>LABEL=</literal> followed by the label,
+    <literal>PARTLABEL=</literal> followed by the partition label.
+    </para>
+
+    <para>The third field if present contains an absolute filename path to a key file or a <literal>-</literal>
+    to specify none.  When the filename is present, the "integrity-algorithm" defaults to <literal>hmac-sha256</literal>
+    with the key length derived from the number of bytes in the key file.  At this time the only supported integrity algorithm
+    when using key file is hmac-sha256.  The maximum size of the key file is 4096 bytes.
+    </para>
+
+     <para>The fourth field, if present, is a comma-delimited list of options or a <literal>-</literal> to specify none. The following options are
+    recognized:</para>
+      <variablelist>
+
+      <varlistentry>
+        <term><option>allow-discards</option></term>
+
+        <listitem><para>
+        Allow the use of discard (TRIM) requests for the device.
+        This option is available since the Linux kernel version 5.7.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>mode=(journal|bitmap|direct)</option></term>
+
+        <listitem><para>
+        Enable journaled, bitmapped or direct (passthrough) mode. Journaled mode is the default when this option is not specified.
+        It provides safety against crashes, but can be slow because all data has to be written twice.
+        Bitmap mode is more efficient since it requires only a single write, but it is less reliable because if data corruption happens when the machine crashes, it may not be detected.
+        Direct mode disables the journal and the bitmap. Corresponds to the "direct writes" mode documented in
+        <ulink url="https://docs.kernel.org/admin-guide/device-mapper/dm-integrity.html">the dm-integrity documentation</ulink>.
+        Note that without a journal, if there is a crash, it is possible that the integrity tags and data will not match. If used, the journal-*
+        options below will have no effect if passed.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>journal-watermark=[0..100]%</option></term>
+
+        <listitem><para>
+        Journal watermark in percent. When the journal percentage exceeds this watermark, the journal flush will be started.  Setting a value of
+        "0%" uses default value.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>journal-commit-time=[0..N]</option></term>
+
+        <listitem><para>
+        Commit time in milliseconds. When this time passes (and no explicit flush operation was issued), the journal is written.  Setting a value of
+        zero uses default value.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>data-device=/dev/disk/by-...</option></term>
+
+        <listitem><para>
+        Specify a separate block device that contains existing data. The second field specified in the
+        integritytab for block device then will contain calculated integrity tags and journal for data-device,
+        but not the end user data.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>integrity-algorithm=[crc32c|crc32|sha1|sha256|hmac-sha256]</option></term>
+
+        <listitem><para>
+        The algorithm used for integrity checking.  The default is crc32c. Must match option used during format.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+    </variablelist>
+
+    <para>At early boot and when the system manager configuration is
+    reloaded, this file is translated into native systemd units by
+    <citerefentry><refentrytitle>systemd-integritysetup-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Examples</title>
+    <example>
+      <title>/etc/integritytab</title>
+      <para>Set up two integrity protected block devices. </para>
+
+      <programlisting>home PARTUUID=4973d0b8-1b15-c449-96ec-94bab7f6a7b8 - journal-commit-time=10,allow-discards,journal-watermark=55%
+data PARTUUID=5d4b1808-be76-774d-88af-03c4c3a41761 - allow-discards
+</programlisting>
+    </example>
+
+    <example>
+      <title>/etc/integritytab</title>
+      <para>Set up 1 integrity protected block device using defaults </para>
+
+      <programlisting>home PARTUUID=4973d0b8-1b15-c449-96ec-94bab7f6a7b8</programlisting>
+    </example>
+
+    <example>
+      <title>/etc/integritytab</title>
+      <para>Set up 1 integrity device using existing data block device which contains user data </para>
+
+      <programlisting>home PARTUUID=4973d0b8-1b15-c449-96ec-94bab7f6a7b8 - data-device=/dev/disk/by-uuid/9276d9c0-d4e3-4297-b4ff-3307cd0d092f</programlisting>
+    </example>
+
+    <example>
+      <title>/etc/integritytab</title>
+      <para>Set up 1 integrity device using a HMAC key file using defaults </para>
+
+      <programlisting>home PARTUUID=4973d0b8-1b15-c449-96ec-94bab7f6a7b8 /etc/hmac.key</programlisting>
+    </example>
+
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-integritysetup@.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-integritysetup-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry project='die-net'><refentrytitle>integritysetup</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/iocost.conf.xml b/man/iocost.conf.xml
new file mode 100644
index 0000000..a7fdc66
--- /dev/null
+++ b/man/iocost.conf.xml
@@ -0,0 +1,78 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="iocost.conf" xmlns:xi="http://www.w3.org/2001/XInclude">
+  <refentryinfo>
+    <title>iocost.conf</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>iocost.conf</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>iocost.conf</refname>
+    <refpurpose>Configuration files for the iocost solution manager</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para>
+      <filename>/etc/systemd/iocost.conf</filename>
+      <filename>/etc/systemd/iocost.conf.d/*.conf</filename>
+    </para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>This file configures the behavior of <literal>iocost</literal>, a tool mostly used by
+    <citerefentry><refentrytitle>systemd-udevd</refentrytitle><manvolnum>8</manvolnum></citerefentry> rules
+    to automatically apply I/O cost solutions to <filename>/sys/fs/cgroup/io.cost.*</filename>.</para>
+
+    <para>The qos and model values are calculated based on benchmarks collected on the
+    <ulink url="https://github.com/iocost-benchmark/iocost-benchmarks">iocost-benchmark</ulink>
+    project and turned into a set of solutions that go from most to least isolated.
+    Isolation allows the system to remain responsive in face of high I/O load.
+    Which solutions are available for a device can be queried from the udev metadata attached to it. By
+    default the naive solution is used, which provides the most bandwidth.</para>
+  </refsect1>
+
+  <xi:include href="standard-conf.xml" xpointer="main-conf" />
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>All options are configured in the [IOCost] section:</para>
+
+    <variablelist class='config-directives'>
+
+      <varlistentry>
+        <term><varname>TargetSolution=</varname></term>
+
+        <listitem><para>Chooses which I/O cost solution (identified by named string) should be used
+        for the devices in this system. The known solutions can be queried from the udev metadata
+        attached to the devices. If a device does not have the specified solution, the first one
+        listed in <varname>IOCOST_SOLUTIONS</varname> is used instead.</para>
+
+        <para>E.g. <literal>TargetSolution=isolated-bandwidth</literal>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>udevadm</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <ulink url="https://github.com/iocost-benchmark/iocost-benchmarks">The iocost-benchmarks github project</ulink>,
+      <ulink url="https://github.com/facebookexperimental/resctl-demo/tree/main/resctl-bench/doc">The resctl-bench
+      documentation details how the values are obtained</ulink>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/journal-enumerate-fields.c b/man/journal-enumerate-fields.c
new file mode 100644
index 0000000..bb09319
--- /dev/null
+++ b/man/journal-enumerate-fields.c
@@ -0,0 +1,22 @@
+/* SPDX-License-Identifier: MIT-0 */
+
+#include <errno.h>
+#include <stdio.h>
+#include <systemd/sd-journal.h>
+
+int main(int argc, char *argv[]) {
+  sd_journal *j;
+  const char *field;
+  int r;
+
+  r = sd_journal_open(&j, SD_JOURNAL_LOCAL_ONLY);
+  if (r < 0) {
+    errno = -r;
+    fprintf(stderr, "Failed to open journal: %m\n");
+    return 1;
+  }
+  SD_JOURNAL_FOREACH_FIELD(j, field)
+    printf("%s\n", field);
+  sd_journal_close(j);
+  return 0;
+}
diff --git a/man/journal-iterate-foreach.c b/man/journal-iterate-foreach.c
new file mode 100644
index 0000000..381b50f
--- /dev/null
+++ b/man/journal-iterate-foreach.c
@@ -0,0 +1,31 @@
+/* SPDX-License-Identifier: MIT-0 */
+
+#include <errno.h>
+#include <stdio.h>
+#include <systemd/sd-journal.h>
+
+int main(int argc, char *argv[]) {
+  int r;
+  sd_journal *j;
+  r = sd_journal_open(&j, SD_JOURNAL_LOCAL_ONLY);
+  if (r < 0) {
+    errno = -r;
+    fprintf(stderr, "Failed to open journal: %m\n");
+    return 1;
+  }
+  SD_JOURNAL_FOREACH(j) {
+    const char *d;
+    size_t l;
+
+    r = sd_journal_get_data(j, "MESSAGE", (const void **)&d, &l);
+    if (r < 0) {
+      errno = -r;
+      fprintf(stderr, "Failed to read message field: %m\n");
+      continue;
+    }
+
+    printf("%.*s\n", (int) l, d);
+  }
+  sd_journal_close(j);
+  return 0;
+}
diff --git a/man/journal-iterate-poll.c b/man/journal-iterate-poll.c
new file mode 100644
index 0000000..d377324
--- /dev/null
+++ b/man/journal-iterate-poll.c
@@ -0,0 +1,27 @@
+/* SPDX-License-Identifier: MIT-0 */
+
+#include <poll.h>
+#include <time.h>
+#include <systemd/sd-journal.h>
+
+int wait_for_changes(sd_journal *j) {
+  uint64_t t;
+  int msec;
+  struct pollfd pollfd;
+
+  sd_journal_get_timeout(j, &t);
+  if (t == (uint64_t) -1)
+    msec = -1;
+  else {
+    struct timespec ts;
+    uint64_t n;
+    clock_gettime(CLOCK_MONOTONIC, &ts);
+    n = (uint64_t) ts.tv_sec * 1000000 + ts.tv_nsec / 1000;
+    msec = t > n ? (int) ((t - n + 999) / 1000) : 0;
+  }
+
+  pollfd.fd = sd_journal_get_fd(j);
+  pollfd.events = sd_journal_get_events(j);
+  poll(&pollfd, 1, msec);
+  return sd_journal_process(j);
+}
diff --git a/man/journal-iterate-unique.c b/man/journal-iterate-unique.c
new file mode 100644
index 0000000..5fe98b3
--- /dev/null
+++ b/man/journal-iterate-unique.c
@@ -0,0 +1,29 @@
+/* SPDX-License-Identifier: MIT-0 */
+
+#include <errno.h>
+#include <stdio.h>
+#include <systemd/sd-journal.h>
+
+int main(int argc, char *argv[]) {
+  sd_journal *j;
+  const void *d;
+  size_t l;
+  int r;
+
+  r = sd_journal_open(&j, SD_JOURNAL_LOCAL_ONLY);
+  if (r < 0) {
+    errno = -r;
+    fprintf(stderr, "Failed to open journal: %m\n");
+    return 1;
+  }
+  r = sd_journal_query_unique(j, "_SYSTEMD_UNIT");
+  if (r < 0) {
+    errno = -r;
+    fprintf(stderr, "Failed to query journal: %m\n");
+    return 1;
+  }
+  SD_JOURNAL_FOREACH_UNIQUE(j, d, l)
+    printf("%.*s\n", (int) l, (const char*) d);
+  sd_journal_close(j);
+  return 0;
+}
diff --git a/man/journal-iterate-wait.c b/man/journal-iterate-wait.c
new file mode 100644
index 0000000..ac4b60b
--- /dev/null
+++ b/man/journal-iterate-wait.c
@@ -0,0 +1,45 @@
+/* SPDX-License-Identifier: MIT-0 */
+
+#include <errno.h>
+#include <stdio.h>
+#include <systemd/sd-journal.h>
+
+int main(int argc, char *argv[]) {
+  int r;
+  sd_journal *j;
+  r = sd_journal_open(&j, SD_JOURNAL_LOCAL_ONLY);
+  if (r < 0) {
+    errno = -r;
+    fprintf(stderr, "Failed to open journal: %m\n");
+    return 1;
+  }
+  for (;;)  {
+    const void *d;
+    size_t l;
+    r = sd_journal_next(j);
+    if (r < 0) {
+      errno = -r;
+      fprintf(stderr, "Failed to iterate to next entry: %m\n");
+      break;
+    }
+    if (r == 0) {
+      /* Reached the end, let's wait for changes, and try again */
+      r = sd_journal_wait(j, (uint64_t) -1);
+      if (r < 0) {
+        errno = -r;
+        fprintf(stderr, "Failed to wait for changes: %m\n");
+        break;
+      }
+      continue;
+    }
+    r = sd_journal_get_data(j, "MESSAGE", &d, &l);
+    if (r < 0) {
+      errno = -r;
+      fprintf(stderr, "Failed to read message field: %m\n");
+      continue;
+    }
+    printf("%.*s\n", (int) l, (const char*) d);
+  }
+  sd_journal_close(j);
+  return 0;
+}
diff --git a/man/journal-remote.conf.xml b/man/journal-remote.conf.xml
new file mode 100644
index 0000000..a5a5b56
--- /dev/null
+++ b/man/journal-remote.conf.xml
@@ -0,0 +1,140 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+
+<!--
+  SPDX-License-Identifier: LGPL-2.1-or-later
+
+  Copyright © 2015 Chris Morgan
+-->
+
+<refentry id="journal-remote.conf" conditional='HAVE_MICROHTTPD'
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+  <refentryinfo>
+    <title>journal-remote.conf</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>journal-remote.conf</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>journal-remote.conf</refname>
+    <refname>journal-remote.conf.d</refname>
+    <refpurpose>Configuration files for the service accepting remote journal uploads</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>/etc/systemd/journal-remote.conf</filename></para>
+    <para><filename>/etc/systemd/journal-remote.conf.d/*.conf</filename></para>
+    <para><filename>/run/systemd/journal-remote.conf.d/*.conf</filename></para>
+    <para><filename>/usr/lib/systemd/journal-remote.conf.d/*.conf</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>These files configure various parameters of
+    <citerefentry><refentrytitle>systemd-journal-remote.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+    See
+    <citerefentry><refentrytitle>systemd.syntax</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+    for a general description of the syntax.</para>
+  </refsect1>
+
+  <xi:include href="standard-conf.xml" xpointer="main-conf" />
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>All options are configured in the
+    [Remote] section:</para>
+
+    <variablelist class='config-directives'>
+      <varlistentry>
+        <term><varname>Seal=</varname></term>
+
+        <listitem><para>Periodically sign the data in the journal using Forward Secure Sealing.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v229"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SplitMode=</varname></term>
+
+        <listitem><para>One of <literal>host</literal> or <literal>none</literal>.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v220"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ServerKeyFile=</varname></term>
+
+        <listitem><para>SSL key in PEM format.</para>
+
+        <xi:include href="version-info.xml" xpointer="v220"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ServerCertificateFile=</varname></term>
+
+        <listitem><para>SSL certificate in PEM format.</para>
+
+        <xi:include href="version-info.xml" xpointer="v220"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>TrustedCertificateFile=</varname></term>
+
+        <listitem><para>SSL CA certificate.</para>
+
+        <xi:include href="version-info.xml" xpointer="v220"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>MaxUse=</varname></term>
+        <term><varname>KeepFree=</varname></term>
+        <term><varname>MaxFileSize=</varname></term>
+        <term><varname>MaxFiles=</varname></term>
+
+        <listitem><para>These are analogous to <varname>SystemMaxUse=</varname>,
+        <varname>SystemKeepFree=</varname>, <varname>SystemMaxFileSize=</varname>
+        and <varname>SystemMaxFiles=</varname> in
+        <citerefentry><refentrytitle>journald.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+
+        <para><varname>MaxUse=</varname> controls how much disk space
+        the <command>systemd-journal-remote</command> may use up at most.
+        <varname>KeepFree=</varname> controls how much disk
+        space <command>systemd-journal-remote</command> shall leave free for other uses.
+        <command>systemd-journal-remote</command> will respect both limits
+        and use the smaller of the two values.</para>
+
+        <para><varname>MaxFiles=</varname> controls how many
+        individual journal files to keep at most. Note that only
+        archived files are deleted to reduce the number of files until
+        this limit is reached; active files will stay around. This
+        means that, in effect, there might still be more journal files
+        around in total than this limit after a vacuuming operation is
+        complete.</para>
+
+        <xi:include href="version-info.xml" xpointer="v253"/></listitem>
+      </varlistentry>
+
+    </variablelist>
+
+  </refsect1>
+
+  <refsect1>
+      <title>See Also</title>
+      <para>
+        <citerefentry><refentrytitle>journald.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd-journal-remote.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+      </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/journal-stream-fd.c b/man/journal-stream-fd.c
new file mode 100644
index 0000000..8aad5ff
--- /dev/null
+++ b/man/journal-stream-fd.c
@@ -0,0 +1,29 @@
+/* SPDX-License-Identifier: MIT-0 */
+
+#include <errno.h>
+#include <syslog.h>
+#include <stdio.h>
+#include <unistd.h>
+#include <systemd/sd-journal.h>
+#include <systemd/sd-daemon.h>
+
+int main(int argc, char *argv[]) {
+  int fd;
+  FILE *log;
+  fd = sd_journal_stream_fd("test", LOG_INFO, 1);
+  if (fd < 0) {
+    errno = -fd;
+    fprintf(stderr, "Failed to create stream fd: %m\n");
+    return 1;
+  }
+  log = fdopen(fd, "w");
+  if (!log) {
+    fprintf(stderr, "Failed to create file object: %m\n");
+    close(fd);
+    return 1;
+  }
+  fprintf(log, "Hello World!\n");
+  fprintf(log, SD_WARNING "This is a warning!\n");
+  fclose(log);
+  return 0;
+}
diff --git a/man/journal-upload.conf.xml b/man/journal-upload.conf.xml
new file mode 100644
index 0000000..1bc7f08
--- /dev/null
+++ b/man/journal-upload.conf.xml
@@ -0,0 +1,111 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="journal-upload.conf" conditional='HAVE_MICROHTTPD'
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+  <refentryinfo>
+    <title>journal-upload.conf</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>journal-upload.conf</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>journal-upload.conf</refname>
+    <refname>journal-upload.conf.d</refname>
+    <refpurpose>Configuration files for the journal upload service</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>/etc/systemd/journal-upload.conf</filename></para>
+    <para><filename>/etc/systemd/journal-upload.conf.d/*.conf</filename></para>
+    <para><filename>/run/systemd/journal-upload.conf.d/*.conf</filename></para>
+    <para><filename>/usr/lib/systemd/journal-upload.conf.d/*.conf</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>These files configure various parameters of
+    <citerefentry><refentrytitle>systemd-journal-upload.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+    See
+    <citerefentry><refentrytitle>systemd.syntax</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+    for a general description of the syntax.</para>
+  </refsect1>
+
+  <xi:include href="standard-conf.xml" xpointer="main-conf" />
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>All options are configured in the [Upload] section:</para>
+
+    <variablelist class='config-directives'>
+      <varlistentry>
+        <term><varname>URL=</varname></term>
+
+        <listitem><para>The URL to upload the journal entries to. See the description
+        of <option>--url=</option> option in
+        <citerefentry><refentrytitle>systemd-journal-upload</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        for the description of possible values. There is no default value, so either this
+        option or the command-line option must be always present to make an upload.</para>
+
+        <xi:include href="version-info.xml" xpointer="v232"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ServerKeyFile=</varname></term>
+
+        <listitem><para>SSL key in PEM format.</para>
+
+        <xi:include href="version-info.xml" xpointer="v232"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ServerCertificateFile=</varname></term>
+
+        <listitem><para>SSL CA certificate in PEM format.</para>
+
+        <xi:include href="version-info.xml" xpointer="v232"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>TrustedCertificateFile=</varname></term>
+
+        <listitem><para>SSL CA certificate.</para>
+
+        <xi:include href="version-info.xml" xpointer="v232"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>NetworkTimeoutSec=</varname></term>
+
+        <listitem><para>When network connectivity to the server is lost, this option
+        configures the time to wait for the connectivity to get restored. If the server is
+        not reachable over the network for the configured time, <command>systemd-journal-upload</command>
+        exits. Takes a value in seconds (or in other time units if suffixed with "ms", "min", "h", etc).
+        For details, see <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v249"/></listitem>
+      </varlistentry>
+
+    </variablelist>
+
+  </refsect1>
+
+  <refsect1>
+      <title>See Also</title>
+      <para>
+        <citerefentry><refentrytitle>systemd-journal-upload.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+      </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/journalctl.xml b/man/journalctl.xml
new file mode 100644
index 0000000..bdead3f
--- /dev/null
+++ b/man/journalctl.xml
@@ -0,0 +1,1112 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="journalctl"
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>journalctl</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>journalctl</refentrytitle>
+    <manvolnum>1</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>journalctl</refname>
+    <refpurpose>Print log entries from the systemd journal</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <cmdsynopsis>
+      <command>journalctl</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="opt" rep="repeat">MATCHES</arg>
+    </cmdsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>journalctl</command> is used to print the log entries stored in the journal by
+    <citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    and
+    <citerefentry><refentrytitle>systemd-journal-remote.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+    </para>
+
+    <para>If called without parameters, it will show the contents of the journal accessible to the calling
+    user, starting with the oldest entry collected.</para>
+
+    <para>If one or more match arguments are passed, the output is filtered accordingly. A match is in the
+    format <literal>FIELD=VALUE</literal>, e.g. <literal>_SYSTEMD_UNIT=httpd.service</literal>, referring to
+    the components of a structured journal entry. See
+    <citerefentry><refentrytitle>systemd.journal-fields</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+    for a list of well-known fields. If multiple matches are specified matching different fields, the log
+    entries are filtered by both, i.e. the resulting output will show only entries matching all the specified
+    matches of this kind. If two matches apply to the same field, then they are automatically matched as
+    alternatives, i.e. the resulting output will show entries matching any of the specified matches for the
+    same field. Finally, the character <literal>+</literal> may appear as a separate word between other terms
+    on the command line. This causes all matches before and after to be combined in a disjunction
+    (i.e. logical OR).</para>
+
+    <para>It is also possible to filter the entries by specifying an absolute file path as an argument. The
+    file path may be a file or a symbolic link and the file must exist at the time of the query. If a file
+    path refers to an executable binary, an <literal>_EXE=</literal> match for the canonicalized binary path
+    is added to the query. If a file path refers to an executable script, a <literal>_COMM=</literal> match
+    for the script name is added to the query. If a file path refers to a device node,
+    <literal>_KERNEL_DEVICE=</literal> matches for the kernel name of the device and for each of its ancestor
+    devices is added to the query. Symbolic links are dereferenced, kernel names are synthesized, and parent
+    devices are identified from the environment at the time of the query. In general, a device node is the
+    best proxy for an actual device, as log entries do not usually contain fields that identify an actual
+    device. For the resulting log entries to be correct for the actual device, the relevant parts of the
+    environment at the time the entry was logged, in particular the actual device corresponding to the device
+    node, must have been the same as those at the time of the query. Because device nodes generally change
+    their corresponding devices across reboots, specifying a device node path causes the resulting entries to
+    be restricted to those from the current boot.</para>
+
+    <para>Additional constraints may be added using options <option>--boot</option>,
+    <option>--unit=</option>, etc., to further limit what entries will be shown (logical AND).</para>
+
+    <para>Output is interleaved from all accessible journal files, whether they are rotated or currently
+    being written, and regardless of whether they belong to the system itself or are accessible user
+    journals. The <option>--header</option> option can be used to identify which files
+    <emphasis>are</emphasis> being shown.</para>
+
+    <para>The set of journal files which will be used can be modified using the <option>--user</option>,
+    <option>--system</option>, <option>--directory</option>, and <option>--file</option> options, see
+    below.</para>
+
+    <para>All users are granted access to their private per-user journals. However, by default, only root and
+    users who are members of a few special groups are granted access to the system journal and the journals
+    of other users. Members of the groups <literal>systemd-journal</literal>, <literal>adm</literal>, and
+    <literal>wheel</literal> can read all journal files. Note that the two latter groups traditionally have
+    additional privileges specified by the distribution. Members of the <literal>wheel</literal> group can
+    often perform administrative tasks.</para>
+
+    <para>The output is paged through <command>less</command> by default, and long lines are "truncated" to
+    screen width. The hidden part can be viewed by using the left-arrow and right-arrow keys. Paging can be
+    disabled; see the <option>--no-pager</option> option and the "Environment" section below.</para>
+
+    <para>When outputting to a tty, lines are colored according to priority: lines of level ERROR and higher
+    are colored red; lines of level WARNING are colored yellow; lines of level NOTICE are highlighted;
+    lines of level INFO are displayed normally; lines of level DEBUG are colored grey.</para>
+
+    <para>To write entries <emphasis>to</emphasis> the journal, a few methods may be used. In general, output
+    from systemd units is automatically connected to the journal, see
+    <citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+    In addition,
+    <citerefentry><refentrytitle>systemd-cat</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    may be used to send messages to the journal directly.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Source Options</title>
+
+    <para>The following options control where to read journal records from:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><option>--system</option></term>
+        <term><option>--user</option></term>
+
+        <listitem><para>Show messages from system services and the kernel (with
+        <option>--system</option>). Show messages from service of current user (with
+        <option>--user</option>).  If neither is specified, show all messages that the user can see.
+        </para>
+
+        <para>The <option>--user</option> option affects how <option>--unit=</option> arguments are
+        treated. See <option>--unit=</option>.</para>
+
+        <para>Note that <option>--user</option> only works if persistent logging is enabled, via the
+        <varname>Storage=</varname> setting in
+        <citerefentry><refentrytitle>journald.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v205"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-M</option></term>
+        <term><option>--machine=</option></term>
+
+        <listitem><para>Show messages from a running, local container. Specify a container name to connect
+        to.</para>
+
+        <xi:include href="version-info.xml" xpointer="v209"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-m</option></term>
+        <term><option>--merge</option></term>
+
+        <listitem><para>Show entries interleaved from all available journals, including remote
+        ones.</para>
+
+        <xi:include href="version-info.xml" xpointer="v190"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-D <replaceable>DIR</replaceable></option></term>
+        <term><option>--directory=<replaceable>DIR</replaceable></option></term>
+
+        <listitem><para>Takes a directory path as argument. If specified, journalctl will operate on the
+        specified journal directory <replaceable>DIR</replaceable> instead of the default runtime and system
+        journal paths.</para>
+
+        <xi:include href="version-info.xml" xpointer="v187"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--file=<replaceable>GLOB</replaceable></option></term>
+
+        <listitem><para>Takes a file glob as an argument. If specified, journalctl will operate on the
+        specified journal files matching <replaceable>GLOB</replaceable> instead of the default runtime and
+        system journal paths. May be specified multiple times, in which case files will be suitably
+        interleaved.</para>
+
+        <xi:include href="version-info.xml" xpointer="v205"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--root=<replaceable>ROOT</replaceable></option></term>
+
+        <listitem><para>Takes a directory path as an argument. If specified, <command>journalctl</command>
+        will operate on journal directories and catalog file hierarchy underneath the specified directory
+        instead of the root directory (e.g. <option>--update-catalog</option> will create
+        <filename><replaceable>ROOT</replaceable>/var/lib/systemd/catalog/database</filename>, and journal
+        files under <filename><replaceable>ROOT</replaceable>/run/journal/</filename> or
+        <filename><replaceable>ROOT</replaceable>/var/log/journal/</filename> will be displayed).
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v201"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--image=<replaceable>IMAGE</replaceable></option></term>
+
+        <listitem><para>Takes a path to a disk image file or block device node. If specified,
+        <command>journalctl</command> will operate on the file system in the indicated disk image. This
+        option is similar to <option>--root=</option>, but operates on file systems stored in disk images or
+        block devices, thus providing an easy way to extract log data from disk images. The disk image should
+        either contain just a file system or a set of file systems within a GPT partition table, following
+        the <ulink url="https://uapi-group.org/specifications/specs/discoverable_partitions_specification">Discoverable Partitions
+        Specification</ulink>. For further information on supported disk images, see
+        <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s
+        switch of the same name.</para>
+
+        <xi:include href="version-info.xml" xpointer="v247"/></listitem>
+      </varlistentry>
+
+      <xi:include href="standard-options.xml" xpointer="image-policy-open" />
+
+      <varlistentry>
+        <term><option>--namespace=<replaceable>NAMESPACE</replaceable></option></term>
+
+        <listitem><para>Takes a journal namespace identifier string as argument. If not specified the data
+        collected by the default namespace is shown. If specified shows the log data of the specified
+        namespace instead. If the namespace is specified as <literal>*</literal> data from all namespaces is
+        shown, interleaved. If the namespace identifier is prefixed with <literal>+</literal> data from the
+        specified namespace and the default namespace is shown, interleaved, but no other. For details about
+        journal namespaces see
+        <citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Filtering Options</title>
+
+    <para>The following options control how to filter journal records:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><option>-S</option></term>
+        <term><option>--since=</option></term>
+        <term><option>-U</option></term>
+        <term><option>--until=</option></term>
+
+        <listitem><para>Start showing entries on or newer than the specified date, or on or older than the
+        specified date, respectively. Date specifications should be of the format <literal>2012-10-30
+        18:17:16</literal>.  If the time part is omitted, <literal>00:00:00</literal> is assumed.  If only
+        the seconds component is omitted, <literal>:00</literal> is assumed. If the date component is
+        omitted, the current day is assumed. Alternatively the strings <literal>yesterday</literal>,
+        <literal>today</literal>, <literal>tomorrow</literal> are understood, which refer to 00:00:00 of the
+        day before the current day, the current day, or the day after the current day,
+        respectively. <literal>now</literal> refers to the current time. Finally, relative times may be
+        specified, prefixed with <literal>-</literal> or <literal>+</literal>, referring to times before or
+        after the current time, respectively. For complete time and date specification, see
+        <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry>. Note
+        that <option>--output=short-full</option> prints timestamps that follow precisely this format.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v195"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-c</option></term>
+        <term><option>--cursor=</option></term>
+
+        <listitem><para>Start showing entries from the location in the journal specified by the passed
+        cursor.</para>
+
+        <xi:include href="version-info.xml" xpointer="v193"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--after-cursor=</option></term>
+
+        <listitem><para>Start showing entries from the location in the journal <emphasis>after</emphasis>
+        the location specified by the passed cursor.  The cursor is shown when the
+        <option>--show-cursor</option> option is used.</para>
+
+        <xi:include href="version-info.xml" xpointer="v206"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--cursor-file=<replaceable>FILE</replaceable></option></term>
+
+        <listitem><para>If <replaceable>FILE</replaceable> exists and contains a cursor, start showing
+        entries <emphasis>after</emphasis> this location.  Otherwise show entries according to the other
+        given options. At the end, write the cursor of the last entry to
+        <replaceable>FILE</replaceable>. Use this option to continually read the journal by sequentially
+        calling <command>journalctl</command>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v242"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-b <optional><optional><replaceable>ID</replaceable></optional><optional><replaceable>±offset</replaceable></optional>|<constant>all</constant></optional></option></term>
+        <term><option>--boot<optional>=<optional><replaceable>ID</replaceable></optional><optional><replaceable>±offset</replaceable></optional>|<constant>all</constant></optional></option></term>
+
+        <listitem><para>Show messages from a specific boot. This will add a match for
+        <literal>_BOOT_ID=</literal>.</para>
+
+        <para>The argument may be empty, in which case logs for the current boot will be shown.</para>
+
+        <para>If the boot ID is omitted, a positive <replaceable>offset</replaceable> will look up the boots
+        starting from the beginning of the journal, and an equal-or-less-than zero
+        <replaceable>offset</replaceable> will look up boots starting from the end of the journal. Thus,
+        <constant>1</constant> means the first boot found in the journal in chronological order,
+        <constant>2</constant> the second and so on; while <constant>-0</constant> is the last boot,
+        <constant>-1</constant> the boot before last, and so on. An empty <replaceable>offset</replaceable>
+        is equivalent to specifying <constant>-0</constant>, except when the current boot is not the last
+        boot (e.g. because <option>--directory</option> was specified to look at logs from a different
+        machine).</para>
+
+        <para>If the 32-character <replaceable>ID</replaceable> is specified, it may optionally be followed
+        by <replaceable>offset</replaceable> which identifies the boot relative to the one given by boot
+        <replaceable>ID</replaceable>. Negative values mean earlier boots and positive values mean later
+        boots. If <replaceable>offset</replaceable> is not specified, a value of zero is assumed, and the
+        logs for the boot given by <replaceable>ID</replaceable> are shown.</para>
+
+        <para>The special argument <constant>all</constant> can be used to negate the effect of an earlier
+        use of <option>-b</option>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v186"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-u</option></term>
+        <term><option>--unit=<replaceable>UNIT</replaceable>|<replaceable>PATTERN</replaceable></option></term>
+
+        <listitem><para>Show messages for the specified systemd unit <replaceable>UNIT</replaceable> (such as
+        a service unit), or for any of the units matched by <replaceable>PATTERN</replaceable>.  If a pattern
+        is specified, a list of unit names found in the journal is compared with the specified pattern and
+        all that match are used. For each unit name, a match is added for messages from the unit
+        (<literal>_SYSTEMD_UNIT=<replaceable>UNIT</replaceable></literal>), along with additional matches for
+        messages from systemd and messages about coredumps for the specified unit. A match is also added for
+        <literal>_SYSTEMD_SLICE=<replaceable>UNIT</replaceable></literal>, such that if the provided
+        <replaceable>UNIT</replaceable> is a
+        <citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        unit, all logs of children of the slice will be shown.</para>
+
+        <para>With <option>--user</option>, all <option>--unit=</option> arguments will be converted to match
+        user messages as if specified with <option>--user-unit=</option>.</para>
+
+        <para>This parameter can be specified multiple times.</para>
+
+        <xi:include href="version-info.xml" xpointer="v195"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--user-unit=</option></term>
+
+        <listitem><para>Show messages for the specified user session unit. This will add a match for messages
+        from the unit (<literal>_SYSTEMD_USER_UNIT=</literal> and <literal>_UID=</literal>) and additional
+        matches for messages from session systemd and messages about coredumps for the specified unit. A
+        match is also added for <literal>_SYSTEMD_USER_SLICE=<replaceable>UNIT</replaceable></literal>, such
+        that if the provided <replaceable>UNIT</replaceable> is a
+        <citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        unit, all logs of children of the unit will be shown.</para>
+
+        <para>This parameter can be specified multiple times.</para>
+
+        <xi:include href="version-info.xml" xpointer="v198"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-t</option></term>
+        <term><option>--identifier=<replaceable>SYSLOG_IDENTIFIER</replaceable></option></term>
+
+        <listitem><para>Show messages for the specified syslog identifier
+        <replaceable>SYSLOG_IDENTIFIER</replaceable>.</para>
+
+        <para>This parameter can be specified multiple times.</para>
+
+        <xi:include href="version-info.xml" xpointer="v217"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-p</option></term>
+        <term><option>--priority=</option></term>
+
+        <listitem><para>Filter output by message priorities or priority ranges. Takes either a single numeric
+        or textual log level (i.e. between 0/<literal>emerg</literal> and 7/<literal>debug</literal>), or a
+        range of numeric/text log levels in the form FROM..TO. The log levels are the usual syslog log levels
+        as documented in <citerefentry
+        project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+        i.e. <literal>emerg</literal> (0), <literal>alert</literal> (1), <literal>crit</literal> (2),
+        <literal>err</literal> (3), <literal>warning</literal> (4), <literal>notice</literal> (5),
+        <literal>info</literal> (6), <literal>debug</literal> (7). If a single log level is specified, all
+        messages with this log level or a lower (hence more important) log level are shown. If a range is
+        specified, all messages within the range are shown, including both the start and the end value of the
+        range. This will add <literal>PRIORITY=</literal> matches for the specified
+        priorities.</para>
+
+        <xi:include href="version-info.xml" xpointer="v188"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--facility=</option></term>
+
+        <listitem><para>Filter output by syslog facility. Takes a comma-separated list of numbers or
+        facility names. The names are the usual syslog facilities as documented in <citerefentry
+        project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+        <option>--facility=help</option> may be used to display a list of known facility names and exit.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-g</option></term>
+        <term><option>--grep=</option></term>
+
+        <listitem><para>Filter output to entries where the <varname>MESSAGE=</varname> field matches the
+        specified regular expression. PERL-compatible regular expressions are used, see <citerefentry
+        project='url'><refentrytitle
+        url='http://pcre.org/current/doc/html/pcre2pattern.html'>pcre2pattern</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+        for a detailed description of the syntax.</para>
+
+        <para>If the pattern is all lowercase, matching is case insensitive.  Otherwise, matching is case
+        sensitive. This can be overridden with the <option>--case-sensitive</option> option, see
+        below.</para>
+
+        <para>When used with <option>--lines=</option> (not prefixed with <literal>+</literal>),
+        <option>--reverse</option> is implied.</para>
+
+        <xi:include href="version-info.xml" xpointer="v237"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--case-sensitive<optional>=BOOLEAN</optional></option></term>
+
+        <listitem><para>Make pattern matching case sensitive or case insensitive.</para>
+
+        <xi:include href="version-info.xml" xpointer="v237"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-k</option></term>
+        <term><option>--dmesg</option></term>
+
+        <listitem><para>Show only kernel messages. This implies <option>-b</option> and adds the match
+        <literal>_TRANSPORT=kernel</literal>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v205"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Output Options</title>
+
+    <para>The following options control how journal records are printed:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><option>-o</option></term>
+        <term><option>--output=</option></term>
+
+        <listitem><para>Controls the formatting of the journal entries that are shown. Takes one of the
+        following options:</para>
+
+        <variablelist>
+          <varlistentry>
+            <term><option>short</option></term>
+            <listitem><para>is the default and generates an output that is mostly identical to the
+            formatting of classic syslog files, showing one line per journal entry.</para>
+
+            <xi:include href="version-info.xml" xpointer="v206"/></listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><option>short-full</option></term>
+            <listitem><para>is very similar, but shows timestamps in the format the
+            <option>--since=</option> and <option>--until=</option> options accept. Unlike the timestamp
+            information shown in <option>short</option> output mode this mode includes weekday, year and
+            timezone information in the output, and is locale-independent.</para>
+
+            <xi:include href="version-info.xml" xpointer="v232"/></listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><option>short-iso</option></term>
+            <listitem><para>is very similar, but shows timestamps in the
+            <ulink url="https://tools.ietf.org/html/rfc3339">RFC 3339</ulink> profile of ISO 8601.</para>
+
+            <xi:include href="version-info.xml" xpointer="v206"/></listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><option>short-iso-precise</option></term>
+            <listitem><para>as for <option>short-iso</option> but includes full microsecond
+            precision.</para>
+
+            <xi:include href="version-info.xml" xpointer="v234"/></listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><option>short-precise</option></term>
+            <listitem><para>is very similar, but shows classic syslog timestamps with full microsecond
+            precision.</para>
+
+            <xi:include href="version-info.xml" xpointer="v207"/></listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><option>short-monotonic</option></term>
+            <listitem><para>is very similar, but shows monotonic timestamps instead of wallclock
+            timestamps.</para>
+
+            <xi:include href="version-info.xml" xpointer="v206"/></listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><option>short-delta</option></term>
+            <listitem><para>as for <option>short-monotonic</option> but includes the time difference
+            to the previous entry.
+            Maybe unreliable time differences are marked by a <literal>*</literal>.</para>
+
+            <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><option>short-unix</option></term>
+            <listitem><para>is very similar, but shows seconds passed since January 1st 1970 UTC instead of
+            wallclock timestamps ("UNIX time"). The time is shown with microsecond accuracy.</para>
+
+            <xi:include href="version-info.xml" xpointer="v230"/></listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><option>verbose</option></term>
+            <listitem><para>shows the full-structured entry items with all fields.</para>
+
+            <xi:include href="version-info.xml" xpointer="v206"/></listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><option>export</option></term>
+            <listitem><para>serializes the journal into a binary (but mostly text-based) stream suitable
+            for backups and network transfer (see <ulink
+            url="https://systemd.io/JOURNAL_EXPORT_FORMATS#journal-export-format">Journal Export
+            Format</ulink> for more information). To import the binary stream back into native journald
+            format use
+            <citerefentry><refentrytitle>systemd-journal-remote</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
+
+            <xi:include href="version-info.xml" xpointer="v206"/></listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><option>json</option></term>
+            <listitem><para>formats entries as JSON objects, separated by newline characters (see <ulink
+            url="https://systemd.io/JOURNAL_EXPORT_FORMATS#journal-json-format">Journal JSON Format</ulink>
+            for more information). Field values are generally encoded as JSON strings, with three exceptions:
+            <orderedlist>
+              <listitem><para>Fields larger than 4096 bytes are encoded as <constant>null</constant>
+              values. (This may be turned off by passing <option>--all</option>, but be aware that this may
+              allocate overly long JSON objects.)</para></listitem>
+
+              <listitem><para>Journal entries permit non-unique fields within the same log entry. JSON does
+              not allow non-unique fields within objects. Due to this, if a non-unique field is encountered a
+              JSON array is used as field value, listing all field values as elements.</para></listitem>
+
+              <listitem><para>Fields containing non-printable or non-UTF8 bytes are encoded as arrays
+              containing the raw bytes individually formatted as unsigned numbers.</para></listitem>
+            </orderedlist>
+
+            Note that this encoding is reversible (with the exception of the size limit).</para>
+
+            <xi:include href="version-info.xml" xpointer="v206"/></listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><option>json-pretty</option></term>
+            <listitem><para>formats entries as JSON data structures, but formats them in multiple lines in
+            order to make them more readable by humans.</para>
+
+            <xi:include href="version-info.xml" xpointer="v206"/></listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><option>json-sse</option></term>
+            <listitem><para>formats entries as JSON data structures, but wraps them in a format suitable for
+            <ulink
+            url="https://developer.mozilla.org/en-US/docs/Server-sent_events/Using_server-sent_events">Server-Sent
+            Events</ulink>.</para>
+
+            <xi:include href="version-info.xml" xpointer="v206"/></listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><option>json-seq</option></term>
+            <listitem><para>formats entries as JSON data structures, but prefixes them with an ASCII Record
+            Separator character (0x1E) and suffixes them with an ASCII Line Feed character (0x0A), in
+            accordance with <ulink url="https://tools.ietf.org/html/rfc7464">JavaScript Object Notation
+            (JSON) Text Sequences </ulink> (<literal>application/json-seq</literal>).</para>
+
+            <xi:include href="version-info.xml" xpointer="v240"/></listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><option>cat</option></term>
+            <listitem><para>generates a very terse output, only showing the actual message of each journal
+            entry with no metadata, not even a timestamp. If combined with the
+            <option>--output-fields=</option> option will output the listed fields for each log record,
+            instead of the message.</para>
+
+            <xi:include href="version-info.xml" xpointer="v206"/></listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><option>with-unit</option></term>
+            <listitem><para>similar to <option>short-full</option>, but prefixes the unit and user unit names
+            instead of the traditional syslog identifier. Useful when using templated instances, as it will
+            include the arguments in the unit names.</para>
+
+            <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+          </varlistentry>
+        </variablelist></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--truncate-newline</option></term>
+
+        <listitem><para>Truncate each log message at the first newline character on output, so that only the
+        first line of each message is displayed.</para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--output-fields=</option></term>
+
+        <listitem><para>A comma separated list of the fields which should be included in the output. This
+        has an effect only for the output modes which would normally show all fields
+        (<option>verbose</option>, <option>export</option>, <option>json</option>,
+        <option>json-pretty</option>, <option>json-sse</option> and <option>json-seq</option>), as well as
+        on <option>cat</option>. For the former, the <literal>__CURSOR</literal>,
+        <literal>__REALTIME_TIMESTAMP</literal>, <literal>__MONOTONIC_TIMESTAMP</literal>, and
+        <literal>_BOOT_ID</literal> fields are always printed.</para>
+
+        <xi:include href="version-info.xml" xpointer="v236"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-n</option></term>
+        <term><option>--lines=</option></term>
+
+        <listitem><para>Show the most recent journal events and limit the number of events shown. The argument
+        is a positive integer or <literal>all</literal> to disable the limit. Additionally, if the number is
+        prefixed with <literal>+</literal>, the oldest journal events are used instead. The default value is
+        10 if no argument is given.</para>
+
+        <para>If <option>--follow</option> is used, this option is implied. When not prefixed with <literal>+</literal>
+        and used with <option>--grep=</option>, <option>--reverse</option> is implied.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-r</option></term>
+        <term><option>--reverse</option></term>
+
+        <listitem><para>Reverse output so that the newest entries are displayed first.</para>
+
+        <xi:include href="version-info.xml" xpointer="v198"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--show-cursor</option></term>
+
+        <listitem><para>The cursor is shown after the last entry after two dashes:</para>
+        <programlisting>-- cursor: s=0639…</programlisting>
+        <para>The format of the cursor is private and subject to change.</para>
+
+        <xi:include href="version-info.xml" xpointer="v209"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--utc</option></term>
+
+        <listitem><para>Express time in Coordinated Universal Time (UTC).</para>
+
+        <xi:include href="version-info.xml" xpointer="v217"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-x</option></term>
+        <term><option>--catalog</option></term>
+
+        <listitem><para>Augment log lines with explanation texts from the message catalog. This will add
+        explanatory help texts to log messages in the output where this is available. These short help texts
+        will explain the context of an error or log event, possible solutions, as well as pointers to support
+        forums, developer documentation, and any other relevant manuals. Note that help texts are not
+        available for all messages, but only for selected ones. For more information on the message catalog,
+        please refer to the <ulink url="https://www.freedesktop.org/wiki/Software/systemd/catalog">Message
+        Catalog Developer Documentation</ulink>.</para>
+
+        <para>Note: when attaching <command>journalctl</command> output to bug reports, please do
+        <emphasis>not</emphasis> use <option>-x</option>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v196"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--no-hostname</option></term>
+
+        <listitem><para>Don't show the hostname field of log messages originating from the local host. This
+        switch has an effect only on the <option>short</option> family of output modes (see above).</para>
+
+        <para>Note: this option does not remove occurrences of the hostname from log entries themselves, so
+        it does not prevent the hostname from being visible in the logs.</para>
+
+        <xi:include href="version-info.xml" xpointer="v230"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--no-full</option></term>
+        <term><option>--full</option></term>
+        <term><option>-l</option></term>
+
+        <listitem><para>Ellipsize fields when they do not fit in available columns.  The default is to show
+        full fields, allowing them to wrap or be truncated by the pager, if one is used.</para>
+
+        <para>The old options <option>-l</option>/<option>--full</option> are not useful anymore, except to
+        undo <option>--no-full</option>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v196"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-a</option></term>
+        <term><option>--all</option></term>
+
+        <listitem><para>Show all fields in full, even if they include unprintable characters or are very
+        long. By default, fields with unprintable characters are abbreviated as "blob data". (Note that the
+        pager may escape unprintable characters again.)</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-f</option></term>
+        <term><option>--follow</option></term>
+
+        <listitem><para>Show only the most recent journal entries, and continuously print new entries as
+        they are appended to the journal.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--no-tail</option></term>
+
+        <listitem><para>Show all stored output lines, even in follow mode. Undoes the effect of
+        <option>--lines=</option>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-q</option></term>
+        <term><option>--quiet</option></term>
+
+        <listitem><para>Suppresses all informational messages (i.e. "-- Journal begins at …", "-- Reboot
+        --"), any warning messages regarding inaccessible system journals when run as a normal
+        user.</para></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Pager Control Options</title>
+
+    <para>The following options control page support:</para>
+
+    <variablelist>
+
+      <xi:include href="standard-options.xml" xpointer="no-pager" />
+
+      <varlistentry>
+        <term><option>-e</option></term>
+        <term><option>--pager-end</option></term>
+
+        <listitem><para>Immediately jump to the end of the journal inside the implied pager tool. This
+        implies <option>-n1000</option> to guarantee that the pager will not buffer logs of unbounded
+        size. This may be overridden with an explicit <option>-n</option> with some other numeric value,
+        while <option>-nall</option> will disable this cap.  Note that this option is only supported for
+        the <citerefentry
+        project='man-pages'><refentrytitle>less</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+        pager.</para>
+
+        <xi:include href="version-info.xml" xpointer="v198"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Forward Secure Sealing (FSS) Options</title>
+
+    <para>The following options may be used together with the <option>--setup-keys</option> command described
+    below:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><option>--interval=</option></term>
+
+        <listitem><para>Specifies the change interval for the sealing key when generating an FSS key pair
+        with <option>--setup-keys</option>. Shorter intervals increase CPU consumption but shorten the time
+        range of undetectable journal alterations. Defaults to 15min.</para>
+
+        <xi:include href="version-info.xml" xpointer="v189"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--verify-key=</option></term>
+
+        <listitem><para>Specifies the FSS verification key to use for the <option>--verify</option>
+        operation.</para>
+
+        <xi:include href="version-info.xml" xpointer="v189"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--force</option></term>
+
+        <listitem><para>When <option>--setup-keys</option> is passed and Forward Secure Sealing (FSS) has
+        already been configured, recreate FSS keys.</para>
+
+        <xi:include href="version-info.xml" xpointer="v206"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Commands</title>
+
+    <para>The following commands are understood. If none is specified the default is to display journal records.</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><option>-N</option></term>
+        <term><option>--fields</option></term>
+
+        <listitem><para>Print all field names currently used in all entries of the journal.</para>
+
+        <xi:include href="version-info.xml" xpointer="v229"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-F</option></term>
+        <term><option>--field=</option></term>
+
+        <listitem><para>Print all possible data values the specified field can take in all entries of the
+        journal.</para>
+
+        <xi:include href="version-info.xml" xpointer="v195"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--list-boots</option></term>
+
+        <listitem><para>Show a tabular list of boot numbers (relative to the current boot), their IDs, and
+        the timestamps of the first and last message pertaining to the boot.</para>
+
+        <xi:include href="version-info.xml" xpointer="v209"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--disk-usage</option></term>
+
+        <listitem><para>Shows the current disk usage of all journal files. This shows the sum of the disk
+        usage of all archived and active journal files.</para>
+
+        <xi:include href="version-info.xml" xpointer="v190"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--vacuum-size=</option></term>
+        <term><option>--vacuum-time=</option></term>
+        <term><option>--vacuum-files=</option></term>
+
+        <listitem><para><option>--vacuum-size=</option> removes the oldest archived journal files until the
+        disk space they use falls below the specified size. Accepts the usual <literal>K</literal>,
+        <literal>M</literal>, <literal>G</literal> and <literal>T</literal> suffixes (to the base of
+        1024).</para>
+
+        <para><option>--vacuum-time=</option> removes archived journal files older than the specified
+        timespan. Accepts the usual <literal>s</literal> (default), <literal>m</literal>,
+        <literal>h</literal>, <literal>days</literal>, <literal>weeks</literal>, <literal>months</literal>,
+        and <literal>years</literal> suffixes, see
+        <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
+        details.</para>
+
+        <para><option>--vacuum-files=</option> leaves only the specified number of separate journal
+        files.</para>
+
+        <para>Note that running <option>--vacuum-size=</option> has only an indirect effect on the output
+        shown by <option>--disk-usage</option>, as the latter includes active journal files, while the
+        vacuuming operation only operates on archived journal files. Similarly,
+        <option>--vacuum-files=</option> might not actually reduce the number of journal files to below the
+        specified number, as it will not remove active journal files.</para>
+
+        <para><option>--vacuum-size=</option>, <option>--vacuum-time=</option> and
+        <option>--vacuum-files=</option> may be combined in a single invocation to enforce any combination of
+        a size, a time and a number of files limit on the archived journal files. Specifying any of these
+        three parameters as zero is equivalent to not enforcing the specific limit, and is thus
+        redundant.</para>
+
+        <para>These three switches may also be combined with <option>--rotate</option> into one command. If
+        so, all active files are rotated first, and the requested vacuuming operation is executed right
+        after. The rotation has the effect that all currently active files are archived (and potentially new,
+        empty journal files opened as replacement), and hence the vacuuming operation has the greatest effect
+        as it can take all log data written so far into account.</para>
+
+        <xi:include href="version-info.xml" xpointer="v218"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--verify</option></term>
+
+        <listitem><para>Check the journal file for internal consistency. If the file has been generated
+        with FSS enabled and the FSS verification key has been specified with
+        <option>--verify-key=</option>, authenticity of the journal file is verified.</para>
+
+        <xi:include href="version-info.xml" xpointer="v189"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--sync</option></term>
+
+        <listitem><para>Asks the journal daemon to write all yet unwritten journal data to the backing file
+        system and synchronize all journals. This call does not return until the synchronization operation
+        is complete. This command guarantees that any log messages written before its invocation are safely
+        stored on disk at the time it returns.</para>
+
+        <xi:include href="version-info.xml" xpointer="v228"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--relinquish-var</option></term>
+
+        <listitem><para>Asks the journal daemon for the reverse operation to <option>--flush</option>: if
+        requested the daemon will write further log data to <filename>/run/log/journal/</filename> and
+        stops writing to <filename>/var/log/journal/</filename>. A subsequent call to
+        <option>--flush</option> causes the log output to switch back to
+        <filename>/var/log/journal/</filename>, see above.</para>
+
+        <xi:include href="version-info.xml" xpointer="v243"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--smart-relinquish-var</option></term>
+
+        <listitem><para>Similar to <option>--relinquish-var</option>, but executes no operation if the root
+        file system and <filename>/var/log/journal/</filename> reside on the same mount point. This operation
+        is used during system shutdown in order to make the journal daemon stop writing data to
+        <filename>/var/log/journal/</filename> in case that directory is located on a mount point that needs
+        to be unmounted.</para>
+
+        <xi:include href="version-info.xml" xpointer="v243"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--flush</option></term>
+
+        <listitem><para>Asks the journal daemon to flush any log data stored in
+        <filename>/run/log/journal/</filename> into <filename>/var/log/journal/</filename>, if persistent
+        storage is enabled. This call does not return until the operation is complete. Note that this call is
+        idempotent: the data is only flushed from <filename>/run/log/journal/</filename> into
+        <filename>/var/log/journal/</filename> once during system runtime (but see
+        <option>--relinquish-var</option> below), and this command exits cleanly without executing any
+        operation if this has already happened. This command effectively guarantees that all data is flushed
+        to <filename>/var/log/journal/</filename> at the time it returns.</para>
+
+        <xi:include href="version-info.xml" xpointer="v217"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--rotate</option></term>
+
+        <listitem><para>Asks the journal daemon to rotate journal files. This call does not return until
+        the rotation operation is complete. Journal file rotation has the effect that all currently active
+        journal files are marked as archived and renamed, so that they are never written to in future. New
+        (empty) journal files are then created in their place. This operation may be combined with
+        <option>--vacuum-size=</option>, <option>--vacuum-time=</option> and
+        <option>--vacuum-file=</option> into a single command, see above.</para>
+
+        <xi:include href="version-info.xml" xpointer="v227"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--header</option></term>
+
+        <listitem><para>Instead of showing journal contents, show internal header information of the
+        journal fields accessed.</para>
+
+        <para>This option is particularly useful when trying to identify out-of-order journal entries, as
+        happens for example when the machine is booted with the wrong system time.</para>
+
+        <xi:include href="version-info.xml" xpointer="v187"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--list-catalog <optional><replaceable>128-bit-ID…</replaceable></optional></option></term>
+
+        <listitem><para>List the contents of the message catalog as a table of message IDs, plus their
+        short description strings.</para>
+
+        <para>If any <replaceable>128-bit-ID</replaceable>s are specified, only those entries are
+        shown.</para>
+
+        <xi:include href="version-info.xml" xpointer="v196"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--dump-catalog <optional><replaceable>128-bit-ID…</replaceable></optional></option></term>
+
+        <listitem><para>Show the contents of the message catalog, with entries separated by a line
+        consisting of two dashes and the ID (the format is the same as <filename>.catalog</filename>
+        files).</para>
+
+        <para>If any <replaceable>128-bit-ID</replaceable>s are specified, only those entries are
+        shown.</para>
+
+        <xi:include href="version-info.xml" xpointer="v199"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--update-catalog</option></term>
+
+        <listitem><para>Update the message catalog index. This command needs to be executed each time new
+        catalog files are installed, removed, or updated to rebuild the binary catalog
+        index.</para>
+
+        <xi:include href="version-info.xml" xpointer="v196"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--setup-keys</option></term>
+
+        <listitem><para>Instead of showing journal contents, generate a new key pair for Forward Secure
+        Sealing (FSS). This will generate a sealing key and a verification key. The sealing key is stored in
+        the journal data directory and shall remain on the host. The verification key should be stored
+        externally. Refer to the <option>Seal=</option> option in
+        <citerefentry><refentrytitle>journald.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
+        information on Forward Secure Sealing and for a link to a refereed scholarly paper detailing the
+        cryptographic theory it is based on.</para>
+
+        <xi:include href="version-info.xml" xpointer="v189"/></listitem>
+      </varlistentry>
+
+      <xi:include href="standard-options.xml" xpointer="help" />
+      <xi:include href="standard-options.xml" xpointer="version" />
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Exit status</title>
+
+    <para>On success, 0 is returned; otherwise, a non-zero failure code is returned.</para>
+  </refsect1>
+
+  <xi:include href="common-variables.xml" />
+
+  <refsect1>
+    <title>Examples</title>
+
+    <para>Without arguments, all collected logs are shown unfiltered:</para>
+
+    <programlisting>journalctl</programlisting>
+
+    <para>With one match specified, all entries with a field matching the expression are shown:</para>
+
+    <programlisting>journalctl _SYSTEMD_UNIT=avahi-daemon.service
+journalctl _SYSTEMD_CGROUP=/user.slice/user-42.slice/session-c1.scope</programlisting>
+
+    <para>If two different fields are matched, only entries matching both expressions at the same time are
+    shown:</para>
+
+    <programlisting>journalctl _SYSTEMD_UNIT=avahi-daemon.service _PID=28097</programlisting>
+
+    <para>If two matches refer to the same field, all entries matching either expression are shown:</para>
+
+    <programlisting>journalctl _SYSTEMD_UNIT=avahi-daemon.service _SYSTEMD_UNIT=dbus.service</programlisting>
+
+    <para>If the separator <literal>+</literal> is used, two expressions may be combined in a logical OR. The
+    following will show all messages from the Avahi service process with the PID 28097 plus all messages from
+    the D-Bus service (from any of its processes):</para>
+
+    <programlisting>journalctl _SYSTEMD_UNIT=avahi-daemon.service _PID=28097 + _SYSTEMD_UNIT=dbus.service</programlisting>
+
+    <para>To show all fields emitted <emphasis>by</emphasis> a unit and <emphasis>about</emphasis> the unit,
+    option <option>-u</option>/<option>--unit=</option> should be used. <command>journalctl -u
+    <replaceable>name</replaceable></command> expands to a complex filter similar to
+
+    <programlisting>_SYSTEMD_UNIT=<replaceable>name</replaceable>.service
+  + UNIT=<replaceable>name</replaceable>.service _PID=1
+  + OBJECT_SYSTEMD_UNIT=<replaceable>name</replaceable>.service _UID=0
+  + COREDUMP_UNIT=<replaceable>name</replaceable>.service _UID=0 MESSAGE_ID=fc2e22bc6ee647b6b90729ab34a250b1</programlisting>
+
+    (see
+    <citerefentry><refentrytitle>systemd.journal-fields</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+    for an explanation of those patterns).</para>
+
+    <para>Show all logs generated by the D-Bus executable:</para>
+
+    <programlisting>journalctl /usr/bin/dbus-daemon</programlisting>
+
+    <para>Show all kernel logs from previous boot:</para>
+
+    <programlisting>journalctl -k -b -1</programlisting>
+
+    <para>Show a live log display from a system service <filename>apache.service</filename>:</para>
+
+    <programlisting>journalctl -f -u apache</programlisting>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-cat</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>coredumpctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.journal-fields</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>journald.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-journal-remote.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-journal-upload.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+</refentry>
diff --git a/man/journald.conf.xml b/man/journald.conf.xml
new file mode 100644
index 0000000..e150d04
--- /dev/null
+++ b/man/journald.conf.xml
@@ -0,0 +1,541 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="journald.conf"
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+  <refentryinfo>
+    <title>journald.conf</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>journald.conf</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>journald.conf</refname>
+    <refname>journald.conf.d</refname>
+    <refname>journald@.conf</refname>
+    <refpurpose>Journal service configuration files</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>/etc/systemd/journald.conf</filename></para>
+    <para><filename>/etc/systemd/journald.conf.d/*.conf</filename></para>
+    <para><filename>/run/systemd/journald.conf.d/*.conf</filename></para>
+    <para><filename>/usr/lib/systemd/journald.conf.d/*.conf</filename></para>
+    <para><filename>/etc/systemd/journald@<replaceable>NAMESPACE</replaceable>.conf</filename></para>
+    <para><filename>/etc/systemd/journald@<replaceable>NAMESPACE</replaceable>.conf.d/*.conf</filename></para>
+    <para><filename>/run/systemd/journald@<replaceable>NAMESPACE</replaceable>.conf.d/*.conf</filename></para>
+    <para><filename>/usr/lib/systemd/journald@<replaceable>NAMESPACE</replaceable>.conf.d/*.conf</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>These files configure various parameters of the systemd journal service,
+    <citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+    See
+    <citerefentry><refentrytitle>systemd.syntax</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+    for a general description of the syntax.</para>
+
+    <para>The <command>systemd-journald</command> instance managing the default namespace is configured by
+    <filename>/etc/systemd/journald.conf</filename> and associated drop-ins. Instances managing other
+    namespaces read <filename>/etc/systemd/journald@<replaceable>NAMESPACE</replaceable>.conf</filename>
+    and associated drop-ins with the namespace identifier filled in. This allows each namespace to carry
+    a distinct configuration. See
+    <citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    for details about journal namespaces.</para>
+  </refsect1>
+
+  <xi:include href="standard-conf.xml" xpointer="main-conf" />
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>All options are configured in the
+    [Journal] section:</para>
+
+    <variablelist class='config-directives'>
+
+      <varlistentry>
+        <term><varname>Storage=</varname></term>
+
+        <listitem><para>Controls where to store journal data. One of <literal>volatile</literal>,
+        <literal>persistent</literal>, <literal>auto</literal> and <literal>none</literal>. If
+        <literal>volatile</literal>, journal log data will be stored only in memory, i.e. below the
+        <filename>/run/log/journal</filename> hierarchy (which is created if needed). If
+        <literal>persistent</literal>, data will be stored preferably on disk, i.e. below the
+        <filename>/var/log/journal</filename> hierarchy (which is created if needed), with a fallback to
+        <filename>/run/log/journal</filename> (which is created if needed), during early boot and if the disk
+        is not writable. <literal>auto</literal> behaves like <literal>persistent</literal> if the
+        <filename>/var/log/journal</filename> directory exists, and <literal>volatile</literal> otherwise
+        (the existence of the directory controls the storage mode). <literal>none</literal> turns off all
+        storage, all log data received will be dropped (but forwarding to other targets, such as the console,
+        the kernel log buffer, or a syslog socket will still work). Defaults to <literal>auto</literal> in
+        the default journal namespace, and <literal>persistent</literal> in all others.</para>
+
+        <para>Note that journald will initially use volatile storage, until a call to
+        <command>journalctl --flush</command> (or sending <constant>SIGUSR1</constant> to journald) will cause
+        it to switch to persistent logging (under the conditions mentioned above). This is done automatically
+        on boot via <literal>systemd-journal-flush.service</literal>.</para>
+
+        <para>Note that when this option is changed to <literal>volatile</literal>, existing persistent data
+        is not removed. In the other direction,
+        <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> with
+        the <option>--flush</option> option may be used to move volatile data to persistent storage.</para>
+
+        <para>When journal namespacing (see <varname>LogNamespace=</varname> in
+        <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>) is
+        used, setting <varname>Storage=</varname> to <literal>volatile</literal> or <literal>auto</literal>
+        will not have an effect on the creation of the per-namespace logs directory in
+        <filename>/var/log/journal/</filename>, as the <filename>systemd-journald@.service</filename> service
+        file by default carries <varname>LogsDirectory=</varname>. To turn that off, add a unit file drop-in
+        file that sets <varname>LogsDirectory=</varname> to an empty string.</para>
+
+        <para>Note that per-user journal files are not supported unless persistent storage is enabled, thus
+        making <command>journalctl --user</command> unavailable.</para>
+
+        <xi:include href="version-info.xml" xpointer="v186"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Compress=</varname></term>
+
+        <listitem><para>Can take a boolean value. If enabled (the
+        default), data objects that shall be stored in the journal
+        and are larger than the default threshold of 512 bytes are
+        compressed before they are written to the file system. It
+        can also be set to a number of bytes to specify the
+        compression threshold directly. Suffixes like K, M, and G
+        can be used to specify larger units.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Seal=</varname></term>
+
+        <listitem><para>Takes a boolean value. If enabled (the
+        default), and a sealing key is available (as created by
+        <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s
+        <option>--setup-keys</option> command), Forward Secure Sealing
+        (FSS) for all persistent journal files is enabled. FSS is
+        based on <ulink
+        url="https://eprint.iacr.org/2013/397">Seekable Sequential Key
+        Generators</ulink> by G. A. Marson and B. Poettering
+        (doi:10.1007/978-3-642-40203-6_7) and may be used to protect
+        journal files from unnoticed alteration.</para>
+
+        <xi:include href="version-info.xml" xpointer="v189"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SplitMode=</varname></term>
+
+        <listitem><para>Controls whether to split up journal files per user, either <literal>uid</literal> or
+        <literal>none</literal>. Split journal files are primarily useful for access control: on UNIX/Linux access
+        control is managed per file, and the journal daemon will assign users read access to their journal files. If
+        <literal>uid</literal>, all regular users (with UID outside the range of system users, dynamic service users,
+        and the nobody user) will each get their own journal files, and system users will log to the system journal.
+        See <ulink url="https://systemd.io/UIDS-GIDS">Users, Groups, UIDs and GIDs on systemd systems</ulink>
+        for more details about UID ranges.
+        If <literal>none</literal>, journal files are not split up by user and all messages are
+        instead stored in the single system journal. In this mode unprivileged users generally do not have access to
+        their own log data. Note that splitting up journal files by user is only available for journals stored
+        persistently. If journals are stored on volatile storage (see <varname>Storage=</varname> above), only a single
+        journal file is used. Defaults to <literal>uid</literal>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v190"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RateLimitIntervalSec=</varname></term>
+        <term><varname>RateLimitBurst=</varname></term>
+
+        <listitem><para>Configures the rate limiting that is applied
+        to all messages generated on the system. If, in the time
+        interval defined by <varname>RateLimitIntervalSec=</varname>,
+        more messages than specified in
+        <varname>RateLimitBurst=</varname> are logged by a service,
+        all further messages within the interval are dropped until the
+        interval is over. A message about the number of dropped
+        messages is generated. This rate limiting is applied
+        per-service, so that two services which log do not interfere
+        with each other's limits. Defaults to 10000 messages in 30s.
+        The time specification for
+        <varname>RateLimitIntervalSec=</varname> may be specified in the
+        following units: <literal>s</literal>, <literal>min</literal>,
+        <literal>h</literal>, <literal>ms</literal>,
+        <literal>us</literal>. To turn off any kind of rate limiting,
+        set either value to 0.</para>
+
+        <para>Note that the effective rate limit is multiplied by a
+        factor derived from the available free disk space for the journal.
+        Currently, this factor is calculated using the base 2 logarithm.</para>
+
+        <table>
+          <title>Example <varname>RateLimitBurst=</varname> rate
+            modifications by the available disk space</title>
+          <tgroup cols='2'>
+            <colspec colname='freespace' />
+            <colspec colname='multiplier' />
+            <thead>
+              <row>
+                <entry>Available Disk Space</entry>
+                <entry>Burst Multiplier</entry>
+              </row>
+            </thead>
+            <tbody>
+              <row>
+                <entry>&lt;= 1MB</entry>
+                <entry>1</entry>
+              </row>
+              <row>
+                <entry>&lt;= 16MB</entry>
+                <entry>2</entry>
+              </row>
+              <row>
+                <entry>&lt;= 256MB</entry>
+                <entry>3</entry>
+              </row>
+              <row>
+                <entry>&lt;= 4GB</entry>
+                <entry>4</entry>
+              </row>
+              <row>
+                <entry>&lt;= 64GB</entry>
+                <entry>5</entry>
+              </row>
+              <row>
+                <entry>&lt;= 1TB</entry>
+                <entry>6</entry>
+              </row>
+            </tbody>
+          </tgroup>
+        </table>
+
+        <para>If a service provides rate limits for itself through
+        <varname>LogRateLimitIntervalSec=</varname> and/or <varname>LogRateLimitBurst=</varname>
+        in <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        those values will override the settings specified here.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SystemMaxUse=</varname></term>
+        <term><varname>SystemKeepFree=</varname></term>
+        <term><varname>SystemMaxFileSize=</varname></term>
+        <term><varname>SystemMaxFiles=</varname></term>
+        <term><varname>RuntimeMaxUse=</varname></term>
+        <term><varname>RuntimeKeepFree=</varname></term>
+        <term><varname>RuntimeMaxFileSize=</varname></term>
+        <term><varname>RuntimeMaxFiles=</varname></term>
+
+        <listitem><para>Enforce size limits on the journal files
+        stored. The options prefixed with <literal>System</literal>
+        apply to the journal files when stored on a persistent file
+        system, more specifically
+        <filename>/var/log/journal</filename>. The options prefixed
+        with <literal>Runtime</literal> apply to the journal files
+        when stored on a volatile in-memory file system, more
+        specifically <filename>/run/log/journal</filename>. The former
+        is used only when <filename>/var/</filename> is mounted,
+        writable, and the directory
+        <filename>/var/log/journal</filename> exists. Otherwise, only
+        the latter applies. Note that this means that during early
+        boot and if the administrator disabled persistent logging,
+        only the latter options apply, while the former apply if
+        persistent logging is enabled and the system is fully booted
+        up. <command>journalctl</command> and
+        <command>systemd-journald</command> ignore all files with
+        names not ending with <literal>.journal</literal> or
+        <literal>.journal~</literal>, so only such files, located in
+        the appropriate directories, are taken into account when
+        calculating current disk usage.</para>
+
+        <para><varname>SystemMaxUse=</varname> and
+        <varname>RuntimeMaxUse=</varname> control how much disk space
+        the journal may use up at most.
+        <varname>SystemKeepFree=</varname> and
+        <varname>RuntimeKeepFree=</varname> control how much disk
+        space systemd-journald shall leave free for other uses.
+        <command>systemd-journald</command> will respect both limits
+        and use the smaller of the two values.</para>
+
+        <para>The first pair defaults to 10% and the second to 15% of
+        the size of the respective file system, but each value is
+        capped to 4G. If the file system is nearly full and either
+        <varname>SystemKeepFree=</varname> or
+        <varname>RuntimeKeepFree=</varname> are violated when
+        systemd-journald is started, the limit will be raised to the
+        percentage that is actually free. This means that if there was
+        enough free space before and journal files were created, and
+        subsequently something else causes the file system to fill up,
+        journald will stop using more space, but it will not be
+        removing existing files to reduce the footprint again,
+        either. Also note that only archived files are deleted to reduce the
+        space occupied by journal files. This means that, in effect, there might
+        still be more space used than <varname>SystemMaxUse=</varname> or
+        <varname>RuntimeMaxUse=</varname> limit after a vacuuming operation is
+        complete.</para>
+
+        <para><varname>SystemMaxFileSize=</varname> and <varname>RuntimeMaxFileSize=</varname> control how
+        large individual journal files may grow at most. This influences the granularity in which disk space
+        is made available through rotation, i.e. deletion of historic data. Defaults to one eighth of the
+        values configured with <varname>SystemMaxUse=</varname> and <varname>RuntimeMaxUse=</varname> capped
+        to 128M, so that usually seven rotated journal files are kept as history. If the journal compact 
+        mode is enabled (enabled by default), the maximum file size is capped to 4G.</para>
+
+        <para>Specify values in bytes or use K, M, G, T, P, E as units for the specified sizes (equal to
+        1024, 1024², … bytes). Note that size limits are enforced synchronously when journal files are
+        extended, and no explicit rotation step triggered by time is needed.</para>
+
+        <para><varname>SystemMaxFiles=</varname> and
+        <varname>RuntimeMaxFiles=</varname> control how many
+        individual journal files to keep at most. Note that only
+        archived files are deleted to reduce the number of files until
+        this limit is reached; active files will stay around. This
+        means that, in effect, there might still be more journal files
+        around in total than this limit after a vacuuming operation is
+        complete. This setting defaults to 100.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>MaxFileSec=</varname></term>
+
+        <listitem><para>The maximum time to store entries in a single
+        journal file before rotating to the next one. Normally,
+        time-based rotation should not be required as size-based
+        rotation with options such as
+        <varname>SystemMaxFileSize=</varname> should be sufficient to
+        ensure that journal files do not grow without bounds. However,
+        to ensure that not too much data is lost at once when old
+        journal files are deleted, it might make sense to change this
+        value from the default of one month. Set to 0 to turn off this
+        feature. This setting takes time values which may be suffixed
+        with the units <literal>year</literal>,
+        <literal>month</literal>, <literal>week</literal>,
+        <literal>day</literal>, <literal>h</literal> or
+        <literal>m</literal> to override the default time unit of
+        seconds.</para>
+
+        <xi:include href="version-info.xml" xpointer="v195"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>MaxRetentionSec=</varname></term>
+
+        <listitem><para>The maximum time to store journal entries.
+        This controls whether journal files containing entries older
+        than the specified time span are deleted. Normally, time-based
+        deletion of old journal files should not be required as
+        size-based deletion with options such as
+        <varname>SystemMaxUse=</varname> should be sufficient to
+        ensure that journal files do not grow without bounds. However,
+        to enforce data retention policies, it might make sense to
+        change this value from the default of 0 (which turns off this
+        feature). This setting also takes time values which may be
+        suffixed with the units <literal>year</literal>,
+        <literal>month</literal>, <literal>week</literal>,
+        <literal>day</literal>, <literal>h</literal> or <literal>
+        m</literal> to override the default time unit of
+        seconds.</para>
+
+        <xi:include href="version-info.xml" xpointer="v195"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SyncIntervalSec=</varname></term>
+
+        <listitem><para>The timeout before synchronizing journal files
+        to disk. After syncing, journal files are placed in the
+        OFFLINE state. Note that syncing is unconditionally done
+        immediately after a log message of priority CRIT, ALERT or
+        EMERG has been logged. This setting hence applies only to
+        messages of the levels ERR, WARNING, NOTICE, INFO, DEBUG. The
+        default timeout is 5 minutes. </para>
+
+        <xi:include href="version-info.xml" xpointer="v199"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ForwardToSyslog=</varname></term>
+        <term><varname>ForwardToKMsg=</varname></term>
+        <term><varname>ForwardToConsole=</varname></term>
+        <term><varname>ForwardToWall=</varname></term>
+
+        <listitem><para>Control whether log messages received by the journal daemon shall be forwarded to a
+        traditional syslog daemon, to the kernel log buffer (kmsg), to the system console, or sent as wall
+        messages to all logged-in users.  These options take boolean arguments. If forwarding to syslog is
+        enabled but nothing reads messages from the socket, forwarding to syslog has no effect. By default,
+        only forwarding to wall is enabled. These settings may be overridden at boot time with the kernel
+        command line options <literal>systemd.journald.forward_to_syslog</literal>,
+        <literal>systemd.journald.forward_to_kmsg</literal>,
+        <literal>systemd.journald.forward_to_console</literal>, and
+        <literal>systemd.journald.forward_to_wall</literal>. If the option name is specified without
+        <literal>=</literal> and the following argument, true is assumed. Otherwise, the argument is parsed
+        as a boolean.</para>
+
+        <para>When forwarding to the console, the TTY to log to can be changed with
+        <varname>TTYPath=</varname>, described below.</para>
+
+        <para>When forwarding to the kernel log buffer (kmsg), make sure to select a suitably large size for
+        the log buffer, for example by adding <literal>log_buf_len=8M</literal> to the kernel command line.
+        <command>systemd</command> will automatically disable kernel's rate-limiting applied to userspace
+        processes (equivalent to setting <literal>printk.devkmsg=on</literal>).</para></listitem>
+
+        <para>Note: Forwarding is performed synchronously within journald, and may significantly affect its
+        performance.  This is particularly relevant when using ForwardToConsole=yes in cloud environments,
+        where the console is often a slow, virtual serial port.  Since journald is implemented as a
+        conventional single-process daemon, forwarding to a completely hung console will block journald.
+        This can have a cascading effect resulting in any services synchronously logging to the blocked
+        journal also becoming blocked.  Unless actively debugging/developing something, it's generally
+        preferable to setup a <command>journalctl --follow</command> style service redirected to the
+        console, instead of ForwardToConsole=yes, for production use.</para>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>MaxLevelStore=</varname></term>
+        <term><varname>MaxLevelSyslog=</varname></term>
+        <term><varname>MaxLevelKMsg=</varname></term>
+        <term><varname>MaxLevelConsole=</varname></term>
+        <term><varname>MaxLevelWall=</varname></term>
+
+        <listitem><para>Controls the maximum log level of messages
+        that are stored in the journal, forwarded to syslog, kmsg, the
+        console or wall (if that is enabled, see above). As argument,
+        takes one of
+        <literal>emerg</literal>,
+        <literal>alert</literal>,
+        <literal>crit</literal>,
+        <literal>err</literal>,
+        <literal>warning</literal>,
+        <literal>notice</literal>,
+        <literal>info</literal>,
+        <literal>debug</literal>,
+        or integer values in the range of 0–7 (corresponding to the
+        same levels). Messages equal or below the log level specified
+        are stored/forwarded, messages above are dropped. Defaults to
+        <literal>debug</literal> for <varname>MaxLevelStore=</varname>
+        and <varname>MaxLevelSyslog=</varname>, to ensure that the all
+        messages are stored in the journal and forwarded to syslog.
+        Defaults to
+        <literal>notice</literal> for <varname>MaxLevelKMsg=</varname>,
+        <literal>info</literal> for <varname>MaxLevelConsole=</varname>,
+        and <literal>emerg</literal> for
+        <varname>MaxLevelWall=</varname>. These settings may be
+        overridden at boot time with the kernel command line options
+        <literal>systemd.journald.max_level_store=</literal>,
+        <literal>systemd.journald.max_level_syslog=</literal>,
+        <literal>systemd.journald.max_level_kmsg=</literal>,
+        <literal>systemd.journald.max_level_console=</literal>,
+        <literal>systemd.journald.max_level_wall=</literal>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v185"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ReadKMsg=</varname></term>
+
+        <listitem><para>Takes a boolean value. If enabled <command>systemd-journal</command> processes
+        <filename>/dev/kmsg</filename> messages generated by the kernel. In the default journal namespace
+        this option is enabled by default, it is disabled in all others.</para>
+
+        <xi:include href="version-info.xml" xpointer="v235"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Audit=</varname></term>
+
+        <listitem><para>Takes a boolean value. If enabled <command>systemd-journald</command> will turn on
+        kernel auditing on start-up. If disabled it will turn it off. If unset it will neither enable nor
+        disable it, leaving the previous state unchanged.  This means if another tool turns on auditing even
+        if <command>systemd-journald</command> left it off, it will still collect the generated
+        messages. Defaults to on.</para>
+
+        <para>Note that this option does not control whether <command>systemd-journald</command> collects
+        generated audit records, it just controls whether it tells the kernel to generate them. If you need
+        to prevent <command>systemd-journald</command> from collecting the generated messages, the socket
+        unit <literal>systemd-journald-audit.socket</literal> can be disabled and in this case this setting
+        is without effect.</para>
+
+        <xi:include href="version-info.xml" xpointer="v246"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>TTYPath=</varname></term>
+
+        <listitem><para>Change the console TTY to use if
+        <varname>ForwardToConsole=yes</varname> is used. Defaults to
+        <filename>/dev/console</filename>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v185"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>LineMax=</varname></term>
+
+        <listitem><para>The maximum line length to permit when converting stream logs into record logs. When a systemd
+        unit's standard output/error are connected to the journal via a stream socket, the data read is split into
+        individual log records at newline (<literal>\n</literal>, ASCII 10) and <constant>NUL</constant> characters. If no such delimiter is
+        read for the specified number of bytes a hard log record boundary is artificially inserted, breaking up overly
+        long lines into multiple log records. Selecting overly large values increases the possible memory usage of the
+        Journal daemon for each stream client, as in the worst case the journal daemon needs to buffer the specified
+        number of bytes in memory before it can flush a new log record to disk. Also note that permitting overly large
+        line maximum line lengths affects compatibility with traditional log protocols as log records might not fit
+        anymore into a single <constant>AF_UNIX</constant> or <constant>AF_INET</constant> datagram. Takes a size in
+        bytes. If the value is suffixed with K, M, G or T, the specified size is parsed as Kilobytes, Megabytes,
+        Gigabytes, or Terabytes (with the base 1024), respectively. Defaults to 48K, which is relatively large but
+        still small enough so that log records likely fit into network datagrams along with extra room for
+        metadata. Note that values below 79 are not accepted and will be bumped to 79.</para>
+
+        <xi:include href="version-info.xml" xpointer="v235"/></listitem>
+      </varlistentry>
+
+    </variablelist>
+
+  </refsect1>
+
+  <refsect1>
+    <title>Forwarding to traditional syslog daemons</title>
+
+    <para>
+      Journal events can be transferred to a different logging daemon
+      in two different ways. With the first method, messages are
+      immediately forwarded to a socket
+      (<filename>/run/systemd/journal/syslog</filename>), where the
+      traditional syslog daemon can read them. This method is
+      controlled by the <varname>ForwardToSyslog=</varname> option. With a
+      second method, a syslog daemon behaves like a normal journal
+      client, and reads messages from the journal files, similarly to
+      <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
+      With this, messages do not have to be read immediately,
+      which allows a logging daemon which is only started late in boot
+      to access all messages since the start of the system. In
+      addition, full structured meta-data is available to it. This
+      method of course is available only if the messages are stored in
+      a journal file at all. So it will not work if
+      <varname>Storage=none</varname> is set. It should be noted that
+      usually the <emphasis>second</emphasis> method is used by syslog
+      daemons, so the <varname>Storage=</varname> option, and not the
+      <varname>ForwardToSyslog=</varname> option, is relevant for them.
+    </para>
+  </refsect1>
+
+  <refsect1>
+      <title>See Also</title>
+      <para>
+        <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.journal-fields</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+      </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/kernel-command-line.xml b/man/kernel-command-line.xml
new file mode 100644
index 0000000..6ac20ad
--- /dev/null
+++ b/man/kernel-command-line.xml
@@ -0,0 +1,740 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="kernel-command-line" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>kernel-command-line</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>kernel-command-line</refentrytitle>
+    <manvolnum>7</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>kernel-command-line</refname>
+    <refpurpose>Kernel command line parameters</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>/proc/cmdline</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>The kernel, the programs running in the initrd and in the host system may be configured at boot via
+    kernel command line arguments. In addition, various systemd tools look at the EFI variable
+    <literal>SystemdOptions</literal> (if available). Both sources are combined, but the kernel command line
+    has higher priority. Please note that <emphasis>the EFI variable is only used by systemd tools, and is
+    ignored by the kernel and other user space tools</emphasis>, so it is not a replacement for the kernel
+    command line.</para>
+
+    <para>For command line parameters understood by the kernel, please
+    see
+    <ulink url="https://docs.kernel.org/admin-guide/kernel-parameters.html"><filename>kernel-parameters.html</filename></ulink>
+    and
+    <citerefentry project='man-pages'><refentrytitle>bootparam</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
+
+    <para>For command line parameters understood by the initrd, see
+    <citerefentry project='man-pages'><refentrytitle>dracut.cmdline</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+    or the documentation of the specific initrd implementation of your
+    installation.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Core OS Command Line Arguments</title>
+
+    <variablelist class='kernel-commandline-options'>
+      <varlistentry>
+        <term><varname>systemd.unit=</varname></term>
+        <term><varname>rd.systemd.unit=</varname></term>
+        <term><varname>systemd.dump_core</varname></term>
+        <term><varname>systemd.crash_chvt</varname></term>
+        <term><varname>systemd.crash_shell</varname></term>
+        <term><varname>systemd.crash_reboot</varname></term>
+        <term><varname>systemd.confirm_spawn</varname></term>
+        <term><varname>systemd.service_watchdogs</varname></term>
+        <term><varname>systemd.show_status</varname></term>
+        <term><varname>systemd.status_unit_format=</varname></term>
+        <term><varname>systemd.log_target=</varname></term>
+        <term><varname>systemd.log_level=</varname></term>
+        <term><varname>systemd.log_location=</varname></term>
+        <term><varname>systemd.log_color</varname></term>
+        <term><varname>systemd.log_ratelimit_kmsg</varname></term>
+        <term><varname>systemd.default_standard_output=</varname></term>
+        <term><varname>systemd.default_standard_error=</varname></term>
+        <term><varname>systemd.setenv=</varname></term>
+        <term><varname>systemd.machine_id=</varname></term>
+        <term><varname>systemd.set_credential=</varname></term>
+        <term><varname>systemd.set_credential_binary=</varname></term>
+        <term><varname>systemd.import_credentials=</varname></term>
+        <term><varname>systemd.reload_limit_interval_sec=</varname></term>
+        <term><varname>systemd.reload_limit_burst=</varname></term>
+        <listitem>
+          <para>Parameters understood by the system and service
+          manager to control system behavior. For details, see
+          <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v186"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>systemd.mask=</varname></term>
+        <term><varname>systemd.wants=</varname></term>
+        <term><varname>systemd.debug_shell</varname></term>
+        <listitem>
+          <para>Additional parameters understood by
+          <citerefentry><refentrytitle>systemd-debug-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+          to mask or start specific units at boot, or invoke a debug
+          shell on tty9.</para>
+
+          <xi:include href="version-info.xml" xpointer="v215"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>systemd.run=</varname></term>
+        <term><varname>systemd.run_success_action=</varname></term>
+        <term><varname>systemd.run_failure_action=</varname></term>
+        <listitem>
+          <para>Additional parameters understood by
+          <citerefentry><refentrytitle>systemd-run-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>, to
+          run a command line specified on the kernel command line as system service after booting up.</para>
+
+          <xi:include href="version-info.xml" xpointer="v240"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>systemd.early_core_pattern=</varname></term>
+        <listitem>
+          <para>During early boot, the generation of core dump files is disabled until a core dump handler (if any)
+          takes over. This parameter allows specifying an absolute path where core dump files should be stored until
+          a handler is installed. The path should be absolute and may contain specifiers, see
+          <citerefentry project='man-pages'><refentrytitle>core</refentrytitle><manvolnum>5</manvolnum></citerefentry> for details.</para>
+
+          <xi:include href="version-info.xml" xpointer="v240"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>systemd.restore_state=</varname></term>
+        <listitem>
+          <para>This parameter is understood by several system tools
+          to control whether or not they should restore system state
+          from the previous boot. For details, see
+          <citerefentry><refentrytitle>systemd-backlight@.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+          and
+          <citerefentry><refentrytitle>systemd-rfkill.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v209"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>systemd.volatile=</varname></term>
+        <listitem>
+          <para>This parameter controls whether the system shall boot up in volatile mode. Takes a boolean argument, or
+          the special value <literal>state</literal>. If false (the default), normal boot mode is selected, the root
+          directory and <filename>/var/</filename> are mounted as specified on the kernel command line or
+          <filename>/etc/fstab</filename>, or otherwise configured. If true, full state-less boot mode is selected. In
+          this case the root directory is mounted as volatile memory file system (<literal>tmpfs</literal>), and only
+          <filename>/usr/</filename> is mounted from the file system configured as root device, in read-only mode. This
+          enables fully state-less boots were the vendor-supplied OS is used as shipped, with only default
+          configuration and no stored state in effect, as <filename>/etc/</filename> and <filename>/var/</filename> (as
+          well as all other resources shipped in the root file system) are reset at boot and lost on shutdown. If this
+          setting is set to <literal>state</literal> the root file system is mounted read-only, however
+          <filename>/var/</filename> is mounted as a volatile memory file system (<literal>tmpfs</literal>), so that the
+          system boots up with the normal configuration applied, but all state reset at boot and lost at shutdown. If
+          this setting is set to <literal>overlay</literal> the root file system is set up as
+          <literal>overlayfs</literal> mount combining the read-only root directory with a writable
+          <literal>tmpfs</literal>, so that no modifications are made to disk, but the file system may be modified
+          nonetheless with all changes being lost at reboot. For details, see
+          <citerefentry><refentrytitle>systemd-volatile-root.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+          and
+          <citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v233"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>quiet</varname></term>
+        <listitem>
+          <para>Parameter understood by both the kernel and the system
+          and service manager to control console log verbosity. For
+          details, see
+          <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v186"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>debug</varname></term>
+        <listitem>
+          <para>Parameter understood by both the kernel and the system
+          and service manager to control console log verbosity. For
+          details, see
+          <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v205"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>-b</varname></term>
+        <term><varname>rd.emergency</varname></term>
+        <term><varname>emergency</varname></term>
+        <term><varname>rd.rescue</varname></term>
+        <term><varname>rescue</varname></term>
+        <term><varname>single</varname></term>
+        <term><varname>s</varname></term>
+        <term><varname>S</varname></term>
+        <term><varname>1</varname></term>
+        <term><varname>2</varname></term>
+        <term><varname>3</varname></term>
+        <term><varname>4</varname></term>
+        <term><varname>5</varname></term>
+        <listitem>
+          <para>Parameters understood by the system and service
+          manager, as compatibility and convenience options. For details, see
+          <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v186"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>locale.LANG=</varname></term>
+        <term><varname>locale.LANGUAGE=</varname></term>
+        <term><varname>locale.LC_CTYPE=</varname></term>
+        <term><varname>locale.LC_NUMERIC=</varname></term>
+        <term><varname>locale.LC_TIME=</varname></term>
+        <term><varname>locale.LC_COLLATE=</varname></term>
+        <term><varname>locale.LC_MONETARY=</varname></term>
+        <term><varname>locale.LC_MESSAGES=</varname></term>
+        <term><varname>locale.LC_PAPER=</varname></term>
+        <term><varname>locale.LC_NAME=</varname></term>
+        <term><varname>locale.LC_ADDRESS=</varname></term>
+        <term><varname>locale.LC_TELEPHONE=</varname></term>
+        <term><varname>locale.LC_MEASUREMENT=</varname></term>
+        <term><varname>locale.LC_IDENTIFICATION=</varname></term>
+        <listitem>
+          <para>Parameters understood by the system and service
+          manager to control locale and language settings. For
+          details, see
+          <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v186"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>fsck.mode=</varname></term>
+        <term><varname>fsck.repair=</varname></term>
+
+        <listitem>
+          <para>Parameters understood by the file system checker
+          services. For details, see
+          <citerefentry><refentrytitle>systemd-fsck@.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v186"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>quotacheck.mode=</varname></term>
+
+        <listitem>
+          <para>Parameter understood by the file quota checker
+          service. For details, see
+          <citerefentry><refentrytitle>systemd-quotacheck.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v186"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>systemd.journald.forward_to_syslog=</varname></term>
+        <term><varname>systemd.journald.forward_to_kmsg=</varname></term>
+        <term><varname>systemd.journald.forward_to_console=</varname></term>
+        <term><varname>systemd.journald.forward_to_wall=</varname></term>
+
+        <listitem>
+          <para>Parameters understood by the journal service. For
+          details, see
+          <citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v186"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>vconsole.keymap=</varname></term>
+        <term><varname>vconsole.keymap_toggle=</varname></term>
+        <term><varname>vconsole.font=</varname></term>
+        <term><varname>vconsole.font_map=</varname></term>
+        <term><varname>vconsole.font_unimap=</varname></term>
+
+        <listitem>
+          <para>Parameters understood by the virtual console setup logic. For details, see
+          <citerefentry><refentrytitle>vconsole.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v186"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>udev.log_level=</varname></term>
+        <term><varname>rd.udev.log_level=</varname></term>
+        <term><varname>udev.children_max=</varname></term>
+        <term><varname>rd.udev.children_max=</varname></term>
+        <term><varname>udev.exec_delay=</varname></term>
+        <term><varname>rd.udev.exec_delay=</varname></term>
+        <term><varname>udev.event_timeout=</varname></term>
+        <term><varname>rd.udev.event_timeout=</varname></term>
+        <term><varname>udev.timeout_signal=</varname></term>
+        <term><varname>rd.udev.timeout_signal=</varname></term>
+        <term><varname>udev.blockdev_read_only</varname></term>
+        <term><varname>rd.udev.blockdev_read_only</varname></term>
+        <term><varname>net.ifnames=</varname></term>
+        <term><varname>net.naming-scheme=</varname></term>
+
+        <listitem>
+          <para>Parameters understood by the device event managing
+          daemon. For details, see
+          <citerefentry><refentrytitle>systemd-udevd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v186"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>plymouth.enable=</varname></term>
+
+        <listitem>
+          <para>May be used to disable the Plymouth boot splash. For
+          details, see
+          <citerefentry project='die-net'><refentrytitle>plymouth</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v186"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>luks=</varname></term>
+        <term><varname>rd.luks=</varname></term>
+        <term><varname>luks.crypttab=</varname></term>
+        <term><varname>rd.luks.crypttab=</varname></term>
+        <term><varname>luks.name=</varname></term>
+        <term><varname>rd.luks.name=</varname></term>
+        <term><varname>luks.uuid=</varname></term>
+        <term><varname>rd.luks.uuid=</varname></term>
+        <term><varname>luks.options=</varname></term>
+        <term><varname>rd.luks.options=</varname></term>
+        <term><varname>luks.key=</varname></term>
+        <term><varname>rd.luks.key=</varname></term>
+
+        <listitem>
+          <para>Configures the LUKS full-disk encryption logic at
+          boot. For details, see
+          <citerefentry><refentrytitle>systemd-cryptsetup-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v186"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>fstab=</varname></term>
+        <term><varname>rd.fstab=</varname></term>
+
+        <listitem>
+          <para>Configures the <filename>/etc/fstab</filename> logic
+          at boot. For details, see
+          <citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v186"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>root=</varname></term>
+        <term><varname>rootfstype=</varname></term>
+        <term><varname>rootflags=</varname></term>
+        <term><varname>ro</varname></term>
+        <term><varname>rw</varname></term>
+
+        <listitem>
+          <para>Configures the root file system and its file system type and mount options, as well as
+          whether it shall be mounted read-only or read-write initially. For details, see
+          <citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
+
+          <para>If <varname>root=</varname> is not set (or set to <literal>gpt-auto</literal>) the automatic
+          root partition discovery implemented by
+          <citerefentry><refentrytitle>systemd-gpt-auto-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+          will be in effect. In this case <varname>rootfstype=</varname>, <varname>rootflags=</varname>,
+          <varname>ro</varname>, <varname>rw</varname> will be interpreted by
+          <command>systemd-gpt-auto-generator</command>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v215"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>mount.usr=</varname></term>
+        <term><varname>mount.usrfstype=</varname></term>
+        <term><varname>mount.usrflags=</varname></term>
+
+        <listitem>
+          <para>Configures the /usr file system (if required) and
+          its file system type and mount options. For details, see
+          <citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v235"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>veritytab=</varname></term>
+        <term><varname>rd.veritytab=</varname></term>
+        <term><varname>roothash=</varname></term>
+        <term><varname>systemd.verity=</varname></term>
+        <term><varname>rd.systemd.verity=</varname></term>
+        <term><varname>systemd.verity_root_data=</varname></term>
+        <term><varname>systemd.verity_root_hash=</varname></term>
+        <term><varname>systemd.verity.root_options=</varname></term>
+        <term><varname>usrhash=</varname></term>
+        <term><varname>systemd.verity_usr_data=</varname></term>
+        <term><varname>systemd.verity_usr_hash=</varname></term>
+        <term><varname>systemd.verity_usr_options=</varname></term>
+        <listitem>
+          <para>Configures the integrity protection root hash for the root and <filename>/usr</filename> file systems, and other related
+          parameters. For details, see
+          <citerefentry><refentrytitle>systemd-veritysetup-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v233"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>systemd.getty_auto=</varname></term>
+
+        <listitem>
+          <para>Configures whether the <filename>serial-getty@.service</filename> will run.
+          For details, see
+          <citerefentry><refentrytitle>systemd-getty-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>systemd.gpt_auto=</varname></term>
+        <term><varname>rd.systemd.gpt_auto=</varname></term>
+
+        <listitem>
+          <para>Configures whether GPT-based partition auto-discovery shall be attempted. For details, see
+          <citerefentry><refentrytitle>systemd-gpt-auto-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v215"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>systemd.image_policy=</varname></term>
+        <term><varname>rd.systemd.image_policy=</varname></term>
+
+        <listitem><para>When GPT-based partition auto-discovery is used, configures the image dissection
+        policy string to apply, as per
+        <citerefentry><refentrytitle>systemd.image-policy</refentrytitle><manvolnum>7</manvolnum></citerefentry>. For
+        details see
+        <citerefentry><refentrytitle>systemd-gpt-auto-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>systemd.default_timeout_start_sec=</varname></term>
+
+        <listitem>
+          <para>Overrides the default start job timeout <varname>DefaultTimeoutStartSec=</varname> at
+          boot. For details, see
+          <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v230"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>systemd.default_device_timeout_sec=</varname></term>
+
+        <listitem>
+          <para>Overrides the default device timeout <varname>DefaultDeviceTimeoutSec=</varname> at boot. For
+          details, see
+          <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>systemd.watchdog_device=</varname></term>
+
+        <listitem>
+          <para>Overrides the watchdog device path <varname>WatchdogDevice=</varname>. For details, see
+          <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v236"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>systemd.watchdog_sec=</varname></term>
+
+        <listitem>
+          <para>Overrides the watchdog timeout settings otherwise configured with
+          <varname>RuntimeWatchdog=</varname>, <varname>RebootWatchdog=</varname> and
+          <varname>KExecWatchdogSec=</varname>. Takes a time value (if no unit is specified, seconds is the
+          implicitly assumed time unit) or the special strings <literal>off</literal> or
+          <literal>default</literal>. For details, see
+          <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v250"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>systemd.watchdog_pre_sec=</varname></term>
+
+        <listitem>
+          <para>Overrides the watchdog pre-timeout settings otherwise configured with
+          <varname>RuntimeWatchdogPreSec=</varname>. Takes a time value (if no unit is specified, seconds is the
+          implicitly assumed time unit) or the special strings <literal>off</literal> or
+          <literal>default</literal>. For details, see
+          <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v251"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>systemd.watchdog_pretimeout_governor=</varname></term>
+
+        <listitem>
+          <para>Overrides the watchdog pre-timeout settings otherwise configured with
+          <varname>RuntimeWatchdogPreGovernor=</varname>. Takes a string value. For details, see
+          <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v251"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>systemd.cpu_affinity=</varname></term>
+
+        <listitem>
+          <para>Overrides the CPU affinity mask for the service manager and the default for all child
+          processes it forks. This takes precedence over <varname>CPUAffinity=</varname>, see
+          <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+          for details.</para>
+
+          <xi:include href="version-info.xml" xpointer="v245"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>modules_load=</varname></term>
+        <term><varname>rd.modules_load=</varname></term>
+
+        <listitem>
+          <para>Load a specific kernel module early at boot. For
+          details, see
+          <citerefentry><refentrytitle>systemd-modules-load.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v187"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>nameserver=</varname></term>
+        <term><varname>domain=</varname></term>
+
+        <listitem><para>Configures DNS server information and search domains, see
+        <citerefentry><refentrytitle>systemd-resolved.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        for details.</para>
+
+        <xi:include href="version-info.xml" xpointer="v253"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>resume=</varname></term>
+        <term><varname>resumeflags=</varname></term>
+
+        <listitem>
+          <para>Enables resume from hibernation using the specified
+          device and mount options. All
+          <citerefentry project='man-pages'><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry>-like
+          paths are supported. For details, see
+          <citerefentry><refentrytitle>systemd-hibernate-resume-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v217"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>systemd.firstboot=</varname></term>
+
+        <listitem><para>Takes a boolean argument, defaults to on. If off,
+        <citerefentry><refentrytitle>systemd-firstboot.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        will not query the user for basic system settings, even if the system boots up for the first time and
+        the relevant settings are not initialized yet. Not to be confused with
+        <varname>systemd.condition-first-boot=</varname> (see below), which overrides the result of the
+        <varname>ConditionFirstBoot=</varname> unit file condition, and thus controls more than just
+        <filename>systemd-firstboot.service</filename> behaviour.</para>
+
+        <xi:include href="version-info.xml" xpointer="v233"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>systemd.condition-needs-update=</varname></term>
+
+        <listitem><para>Takes a boolean argument. If specified, overrides the result of
+        <varname>ConditionNeedsUpdate=</varname> unit condition checks. See
+        <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
+        details.</para>
+
+        <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>systemd.condition-first-boot=</varname></term>
+
+        <listitem><para>Takes a boolean argument. If specified, overrides the result of
+        <varname>ConditionFirstBoot=</varname> unit condition checks. See
+        <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
+        details. Not to be confused with <varname>systemd.firstboot=</varname> which only controls behaviour
+        of the <filename>systemd-firstboot.service</filename> system service but has no effect on the
+        condition check (see above).</para>
+
+        <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>systemd.clock-usec=</varname></term>
+
+        <listitem><para>Takes a decimal, numeric timestamp in μs since January 1st 1970, 00:00am, to set the
+        system clock to. The system time is set to the specified timestamp early during boot. It is not
+        propagated to the hardware clock (RTC).</para>
+
+        <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>systemd.random-seed=</varname></term>
+
+        <listitem><para>Takes a base64 encoded random seed value to credit with full entropy to the kernel's
+        random pool during early service manager initialization. This option is useful in testing
+        environments where delays due to random pool initialization in entropy starved virtual machines shall
+        be avoided.</para>
+
+        <para>Note that if this option is used the seed is accessible to unprivileged programs from
+        <filename>/proc/cmdline</filename>. This option is hence a security risk when used outside of test
+        systems, since the (possibly) only seed used for initialization of the kernel's entropy pool might be
+        easily acquired by unprivileged programs.</para>
+
+        <para>It is recommended to pass 512 bytes of randomized data (as that matches the Linux kernel pool
+        size), which may be generated with a command like the following:</para>
+
+        <programlisting>dd if=/dev/urandom bs=512 count=1 status=none | base64 -w 0</programlisting>
+
+        <para>Again: do not use this option outside of testing environments, it's a security risk elsewhere,
+        as secret key material derived from the entropy pool can possibly be reconstructed by unprivileged
+        programs.</para>
+
+        <xi:include href="version-info.xml" xpointer="v246"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>systemd.hostname=</varname></term>
+
+        <listitem><para>Accepts a hostname to set during early boot. If specified takes precedence over what
+        is set in <filename>/etc/hostname</filename>. Note that this does not bar later runtime changes to
+        the hostname, it simply controls the initial hostname set during early boot.</para>
+
+        <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>systemd.tty.term.<replaceable>tty</replaceable>=</varname></term>
+        <term><varname>systemd.tty.rows.<replaceable>tty</replaceable>=</varname></term>
+        <term><varname>systemd.tty.columns.<replaceable>tty</replaceable>=</varname></term>
+
+        <listitem><para>These arguments allow configuring default values for <varname>$TERM</varname>,
+        <varname>TTYRows=</varname>, and <varname>TTYColumns=</varname> for tty
+        <replaceable>tty</replaceable>. Additionally, <varname>systemd.tty.term.console</varname> will
+        configure the <varname>$TERM</varname> value used by <command>systemd</command> if not set explicitly
+        using <varname>TERM</varname> on the kernel command line. The tty name should be specified without
+        the <filename>/dev/</filename> prefix (e.g. <literal>systemd.tty.rows.ttyS0=80</literal>).
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+      <title>History</title>
+
+      <variablelist>
+        <varlistentry>
+          <term>systemd 252</term>
+          <listitem><para>Kernel command-line arguments <varname>systemd.unified_cgroup_hierarchy</varname>
+          and <varname>systemd.legacy_systemd_cgroup_controller</varname> were deprecated. Please switch to
+          the unified cgroup hierarchy.</para>
+
+          <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+        </varlistentry>
+      </variablelist>
+  </refsect1>
+
+  <refsect1>
+      <title>See Also</title>
+      <para>
+        <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry project='man-pages'><refentrytitle>bootparam</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.system-credentials</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+        <citerefentry><refentrytitle>smbios-type-11</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+        <citerefentry project='man-pages'><refentrytitle>dracut.cmdline</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd-debug-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd-fsck@.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd-quotacheck.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd-vconsole-setup.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd-udevd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+        <citerefentry project='die-net'><refentrytitle>plymouth</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd-cryptsetup-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd-veritysetup-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd-getty-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd-gpt-auto-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd-volatile-root.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd-modules-load.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd-backlight@.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd-rfkill.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd-hibernate-resume-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd-firstboot.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>bootctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+      </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/kernel-install.xml b/man/kernel-install.xml
new file mode 100644
index 0000000..c05176a
--- /dev/null
+++ b/man/kernel-install.xml
@@ -0,0 +1,722 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="kernel-install" conditional='ENABLE_KERNEL_INSTALL'
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>kernel-install</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>kernel-install</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>kernel-install</refname>
+    <refpurpose>Add and remove kernel and initrd images to and from /boot</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <cmdsynopsis>
+      <command>kernel-install</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="plain">add</arg>
+      <arg choice="plain"><replaceable>KERNEL-VERSION</replaceable></arg>
+      <arg choice="plain"><replaceable>KERNEL-IMAGE</replaceable></arg>
+      <arg choice="opt" rep="repeat"><replaceable>INITRD-FILE</replaceable></arg>
+    </cmdsynopsis>
+    <cmdsynopsis>
+      <command>kernel-install</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="plain">remove</arg>
+      <arg choice="plain"><replaceable>KERNEL-VERSION</replaceable></arg>
+    </cmdsynopsis>
+    <cmdsynopsis>
+      <command>kernel-install</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="plain">inspect</arg>
+      <arg choice="opt"><replaceable>KERNEL-VERSION</replaceable></arg>
+      <arg choice="opt"><replaceable>KERNEL-IMAGE</replaceable></arg>
+      <arg choice="opt" rep="repeat"><replaceable>INITRD-FILE</replaceable></arg>
+    </cmdsynopsis>
+    <cmdsynopsis>
+      <command>kernel-install</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="plain">list</arg>
+    </cmdsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+    <para><command>kernel-install</command> is used to install and remove kernel and initrd images
+    <footnote>
+      <para>Nowadays actually CPIO archives used as an "initramfs", rather than "initrd". See
+      <citerefentry><refentrytitle>bootup</refentrytitle><manvolnum>7</manvolnum></citerefentry> for an
+      explanation.</para>
+    </footnote>
+    to and from the boot loader partition, referred to as <varname>$BOOT</varname> here. It will usually be
+    one of <filename>/boot/</filename>, <filename>/efi/</filename>, or <filename>/boot/efi/</filename>, see
+    below.</para>
+
+    <para><command>kernel-install</command> will run the executable files ("plugins") located in the
+    directory <filename>/usr/lib/kernel/install.d/</filename> and the local administration directory
+    <filename>/etc/kernel/install.d/</filename>.  All files are collectively sorted and executed in lexical
+    order, regardless of the directory in which they live. However, files with identical filenames replace
+    each other.  Files in <filename>/etc/kernel/install.d/</filename> take precedence over files with the
+    same name in <filename>/usr/lib/kernel/install.d/</filename>. This can be used to override a
+    system-supplied executables with a local file if needed; a symbolic link in
+    <filename>/etc/kernel/install.d/</filename> with the same name as an executable in
+    <filename>/usr/lib/kernel/install.d/</filename>, pointing to <filename>/dev/null</filename>, disables the
+    executable entirely. Executables must have the extension <literal>.install</literal>; other extensions
+    are ignored.</para>
+
+    <para>An executable placed in these directories should return <constant>0</constant> on success. It may
+    also return <constant>77</constant> to cause the whole operation to terminate (executables later in
+    lexical order will be skipped).</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Commands</title>
+    <para>The following commands are understood:</para>
+    <variablelist>
+      <varlistentry>
+        <term>
+          <command>add [[[<replaceable>KERNEL-VERSION</replaceable>] <replaceable>KERNEL-IMAGE</replaceable>] [<replaceable>INITRD-FILE</replaceable> ...]]</command>
+        </term>
+
+        <listitem>
+          <para>This command takes a kernel version string and a path to a kernel image file as arguments. If
+          the former is omitted, specified as an empty string or as "-" it defaults to the current kernel
+          version, i.e. the same string <command>uname -r</command> returns. If the latter is omitted,
+          specified as an empty string or as "-" defaults to
+          <filename>/usr/lib/modules/<replaceable>KERNEL_VERSION</replaceable>/vmlinuz</filename>. Optionally,
+          one or more initrd images may be specified as well (note that plugins might generate additional
+          ones).</para>
+
+          <para>The executable files from <filename>/usr/lib/kernel/install.d/*.install</filename> and
+          <filename>/etc/kernel/install.d/*.install</filename> (i.e. the plugins) are called with the
+          following arguments:</para>
+
+          <programlisting>add <replaceable>KERNEL-VERSION</replaceable> <filename>$BOOT/<replaceable>ENTRY-TOKEN</replaceable>/<replaceable>KERNEL-VERSION</replaceable>/</filename> <replaceable>KERNEL-IMAGE</replaceable> \
+          [<replaceable>INITRD-FILE</replaceable> ...]</programlisting>
+
+          <para>The third argument directly refers to the path where to place kernel images, initrd
+          images and other resources for
+          <ulink url="https://uapi-group.org/specifications/specs/boot_loader_specification">Boot
+          Loader Specification</ulink> Type #1 entries (the "entry directory"). If other boot loader schemes
+          are used the parameter may be ignored.</para>
+
+          <para>The <replaceable>ENTRY-TOKEN</replaceable> string is typically the machine ID and is supposed
+          to identify the local installation on the system. For details see below.</para>
+
+          <para>Two default plugins execute the following operations in this case:</para>
+
+          <itemizedlist>
+            <listitem><para><command>kernel-install</command> creates
+            <filename>$BOOT/<replaceable>ENTRY-TOKEN</replaceable>/<replaceable>KERNEL-VERSION</replaceable></filename>,
+            if enabled (see <varname>$KERNEL_INSTALL_LAYOUT</varname>).</para></listitem>
+
+            <listitem><para><filename>50-depmod.install</filename> runs
+            <citerefentry project='man-pages'><refentrytitle>depmod</refentrytitle><manvolnum>8</manvolnum></citerefentry> for the
+            <replaceable>KERNEL-VERSION</replaceable>.</para></listitem>
+
+            <listitem><para><filename>90-loaderentry.install</filename> copies
+            <replaceable>KERNEL-IMAGE</replaceable> to
+            <filename>$BOOT/<replaceable>ENTRY-TOKEN</replaceable>/<replaceable>KERNEL-VERSION</replaceable>/linux</filename>.
+            If <replaceable>INITRD-FILE</replaceable>s are provided, it also copies them to
+            <filename>$BOOT/<replaceable>ENTRY-TOKEN</replaceable>/<replaceable>KERNEL_VERSION</replaceable>/<replaceable>INITRD-FILE</replaceable></filename>.
+            This can also be used to prepend microcode before the actual initrd. It also creates a boot loader entry according to the <ulink
+            url="https://uapi-group.org/specifications/specs/boot_loader_specification">Boot Loader Specification</ulink> (Type #1) in
+            <filename>$BOOT/loader/entries/<replaceable>ENTRY-TOKEN</replaceable>-<replaceable>KERNEL-VERSION</replaceable>.conf</filename>.
+            The title of the entry is the <replaceable>PRETTY_NAME</replaceable> parameter specified in
+            <filename>/etc/os-release</filename> or <filename>/usr/lib/os-release</filename> (if the former
+            is missing), or "Linux <replaceable>KERNEL-VERSION</replaceable>", if unset.</para>
+
+            <para>If <varname>$KERNEL_INSTALL_LAYOUT</varname> is not "bls", this plugin does nothing.</para></listitem>
+
+            <listitem><para><filename>90-uki-copy.install</filename> copies a file
+            <filename>uki.efi</filename> from <varname>$KERNEL_INSTALL_STAGING_AREA</varname> or if it does
+            not exist the <replaceable>KERNEL-IMAGE</replaceable> argument, only if it has a
+            <literal>.efi</literal> extension, to
+            <filename>$BOOT/EFI/Linux/<replaceable>ENTRY-TOKEN</replaceable>-<replaceable>KERNEL-VERSION</replaceable>.efi</filename>.</para>
+
+            <para>If <varname>$KERNEL_INSTALL_LAYOUT</varname> is not "uki", this plugin does nothing.</para></listitem>
+          </itemizedlist>
+
+            <xi:include href="version-info.xml" xpointer="v198"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term>
+          <command>add-all</command>
+        </term>
+
+        <listitem>
+          <para>This is the same as <command>add</command> (see above), but invokes the operation iteratively
+          for every installed kernel in <filename>/usr/lib/modules/</filename>. This operation is only
+          supported on systems where the kernel image is installed in
+          <filename>/usr/lib/modules/<replaceable>KERNEL-VERSION</replaceable>/vmlinuz</filename>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v255"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><command>remove <replaceable>KERNEL-VERSION</replaceable></command></term>
+        <listitem>
+          <para>This command expects a kernel version string as single argument.</para>
+
+          <para>The executable files from <filename>/usr/lib/kernel/install.d/*.install</filename> and
+          <filename>/etc/kernel/install.d/*.install</filename> (i.e. the plugins) are called with the
+          following arguments:</para>
+
+          <programlisting>remove <replaceable>KERNEL-VERSION</replaceable> <filename>$BOOT/<replaceable>ENTRY-TOKEN</replaceable>/<replaceable>KERNEL-VERSION</replaceable>/</filename></programlisting>
+
+          <para>Afterwards, <command>kernel-install</command> removes the entry directory
+          <filename>$BOOT/<replaceable>ENTRY-TOKEN</replaceable>/<replaceable>KERNEL-VERSION</replaceable>/</filename>
+          and its contents, if it exists.</para>
+
+          <para>Two default plugins execute the following operations in this case:</para>
+
+          <itemizedlist>
+            <listitem><para><filename>50-depmod.install</filename> removes the files generated by
+            <command>depmod</command> for this kernel again.</para></listitem>
+
+            <listitem><para><filename>90-loaderentry.install</filename> removes the file
+            <filename>$BOOT/loader/entries/<replaceable>ENTRY-TOKEN</replaceable>-<replaceable>KERNEL-VERSION</replaceable>.conf</filename>.
+            </para></listitem>
+
+            <listitem><para><filename>90-uki-copy.install</filename> removes the file
+            <filename>$BOOT/EFI/Linux/<replaceable>ENTRY-TOKEN</replaceable>-<replaceable>KERNEL-VERSION</replaceable>.efi</filename>.
+            </para></listitem>
+          </itemizedlist>
+
+            <xi:include href="version-info.xml" xpointer="v198"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term>
+          <command>inspect [[[<replaceable>KERNEL-VERSION</replaceable>] <replaceable>KERNEL-IMAGE</replaceable>] [<replaceable>INITRD-FILE</replaceable> ...]]</command>
+        </term>
+        <listitem>
+          <para>Takes the same parameters as <command>add</command>.</para>
+
+          <para>Shows the various paths and parameters configured or auto-detected. In particular shows the
+          values of the various <varname>$KERNEL_INSTALL_*</varname> environment variables listed below, as
+          they would be passed to plugins. The <option>--json</option> option can be used to get the output
+          of this verb as a JSON object.</para>
+
+          <xi:include href="version-info.xml" xpointer="v251"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><command>list</command></term>
+        <listitem>
+          <para>Shows the various installed kernels. This enumerates the subdirectories of
+          <filename>/usr/lib/modules/</filename>, and shows whether a kernel image is installed there.</para>
+
+          <xi:include href="version-info.xml" xpointer="v255"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Compatibility with the kernel build system</title>
+
+    <cmdsynopsis>
+      <command>installkernel</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="plain">VERSION</arg>
+      <arg choice="plain">VMLINUZ</arg>
+      <arg choice="opt">MAP</arg>
+      <arg choice="opt">INSTALLATION-DIR</arg>
+    </cmdsynopsis>
+
+    <para>When invoked as <command>installkernel</command>, this program accepts arguments as specified by
+    the kernel build system's <command>make install</command> command. The <parameter>VERSION</parameter> and
+    <parameter>VMLINUZ</parameter> parameters specify the kernel version and the kernel binary. The other two
+    parameters (<parameter>MAP</parameter> and <parameter>INSTALLATION-DIR</parameter>) are currently
+    ignored.
+    </para>
+  </refsect1>
+
+  <refsect1>
+    <title>The <varname>$BOOT</varname> partition</title>
+
+    <para>The partition where the kernels and <ulink url="https://uapi-group.org/specifications/specs/boot_loader_specification">Boot
+    Loader Specification</ulink> snippets are located is called <varname>$BOOT</varname>.
+    <command>kernel-install</command> determines the location of this partition by checking
+    <filename>/efi/</filename>, <filename>/boot/</filename>, and <filename>/boot/efi/</filename> in turn. The
+    first location where <filename>$BOOT/loader/entries/</filename> or
+    <filename>$BOOT/<replaceable>ENTRY-TOKEN</replaceable>/</filename> exists is used.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+    <para>The following options are understood:</para>
+
+    <variablelist>
+      <xi:include href="standard-options.xml" xpointer="esp-path"/>
+      <xi:include href="standard-options.xml" xpointer="boot-path"/>
+
+      <varlistentry>
+        <term><option>--make-entry-directory=yes|no|auto</option></term>
+        <listitem>
+          <para>Controls creation and deletion of the
+          <ulink url="https://uapi-group.org/specifications/specs/boot_loader_specification">Boot Loader Specification</ulink>
+          Type #1 entry directory on the file system containing resources such as kernel and initrd images
+          during <option>add</option> and <option>remove</option>, respectively. The directory is named after
+          the entry token, and is placed immediately below the boot root directory. When
+          <literal>auto</literal>, the directory is created or removed only when the install layout is
+          <literal>bls</literal>. Defaults to <literal>auto</literal>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v254"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--entry-token=</option></term>
+
+        <listitem>
+          <para>Controls how to name and identify boot loader entries for this kernel installation or
+          deletion. Takes one of <literal>auto</literal>, <literal>machine-id</literal>,
+          <literal>os-id</literal>, <literal>os-image-id</literal>, or an arbitrary string prefixed by
+          <literal>literal:</literal> as argument.</para>
+
+          <para>If set to <option>machine-id</option> the entries are named after the machine ID of the
+          running system (e.g. <literal>b0e793a9baf14b5fa13ecbe84ff637ac</literal>). See
+          <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
+          details about the machine ID concept and file.</para>
+
+          <para>If set to <option>os-id</option> the entries are named after the OS ID of the running system,
+          i.e. the <varname>ID=</varname> field of
+          <citerefentry><refentrytitle>os-release</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+          (e.g. <literal>fedora</literal>). Similarly, if set to <option>os-image-id</option> the entries are
+          named after the OS image ID of the running system, i.e. the <varname>IMAGE_ID=</varname> field of
+          <filename>os-release</filename> (e.g. <literal>vendorx-cashier-system</literal>).</para>
+
+          <para>If set to <option>auto</option> (the default), the
+          <filename>/etc/kernel/entry-token</filename> (or
+          <filename>$KERNEL_INSTALL_CONF_ROOT/entry-token</filename>) file will be read if it exists, and the
+          stored value used. Otherwise if the local machine ID is initialized it is used. Otherwise
+          <varname>IMAGE_ID=</varname> from <filename>os-release</filename> will be used, if set. Otherwise,
+          <varname>ID=</varname> from <filename>os-release</filename> will be used, if set. Otherwise a
+          randomly generated machine ID is used.</para>
+
+          <para>Using the machine ID for naming the entries is generally preferable, however there are cases
+          where using the other identifiers is a good option. Specifically: if the identification data that
+          the machine ID entails shall not be stored on the (unencrypted) <varname>$BOOT_ROOT</varname>
+          partition, or if the ID shall be generated on first boot and is not known when the entries are
+          prepared. Note that using the machine ID has the benefit that multiple parallel installations of
+          the same OS can coexist on the same medium, and they can update their boot loader entries
+          independently. When using another identifier (such as the OS ID or the OS image ID), parallel
+          installations of the same OS would try to use the same entry name. To support parallel
+          installations, the installer must use a different entry token when adding a second installation.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v254"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-v</option></term>
+        <term><option>--verbose</option></term>
+        <listitem>
+          <para>Output additional information about operations being performed.</para>
+
+        <xi:include href="version-info.xml" xpointer="v242"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--root=<replaceable>root</replaceable></option></term>
+
+        <listitem><para>Takes a directory path as an argument. All paths will be prefixed with the given
+        alternate <replaceable>root</replaceable> path, including config search paths. This is useful to
+        operate on a system image mounted to the specified directory instead of the host system
+        itself.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--image=<replaceable>image</replaceable></option></term>
+
+        <listitem><para>Takes a path to a disk image file or block device node. If specified, all operations
+        are applied to the file system in the indicated disk image. This option is similar to
+        <option>--root=</option>, but operates on file systems stored in disk images or block devices. The
+        disk image should either contain just a file system or a set of file systems within a GPT partition
+        table, following the <ulink url="https://uapi-group.org/specifications/specs/discoverable_partitions_specification">Discoverable Partitions
+        Specification</ulink>. For further information on supported disk images, see
+        <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s
+        switch of the same name.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+
+      <xi:include href="standard-options.xml" xpointer="help" />
+      <xi:include href="standard-options.xml" xpointer="version" />
+      <xi:include href="standard-options.xml" xpointer="no-pager"/>
+      <xi:include href="standard-options.xml" xpointer="json" />
+      <xi:include href="standard-options.xml" xpointer="image-policy-open" />
+      <xi:include href="standard-options.xml" xpointer="no-legend"/>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Environment variables</title>
+
+    <refsect2>
+      <title>Environment variables exported for plugins</title>
+
+      <para>If <option>--verbose</option> is used, <varname>$KERNEL_INSTALL_VERBOSE=1</varname> will be
+      exported for plugins. They may output additional logs in this case.</para>
+
+      <para><varname>$KERNEL_INSTALL_IMAGE_TYPE=uki|pe|unknown</varname> is set for the plugins to specify the
+      type of the kernel image.</para>
+
+      <variablelist>
+        <varlistentry>
+          <term>uki</term>
+          <listitem>
+            <para>Unified kernel image.</para>
+
+            <xi:include href="version-info.xml" xpointer="v254"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term>pe</term>
+          <listitem>
+            <para>PE binary.</para>
+
+            <xi:include href="version-info.xml" xpointer="v254"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term>unknown</term>
+          <listitem>
+            <para>Unknown type.</para>
+
+            <xi:include href="version-info.xml" xpointer="v254"/>
+          </listitem>
+        </varlistentry>
+      </variablelist>
+
+      <para><varname>$KERNEL_INSTALL_MACHINE_ID</varname> is set for the plugins to the desired machine-id to
+      use. It's always a 128-bit ID. Normally it's read from <filename>/etc/machine-id</filename>, but it can
+      also be overridden via <varname>$MACHINE_ID</varname> (see below). If not specified via these methods,
+      a fallback value will generated by <command>kernel-install</command> and used only for a single
+      invocation.</para>
+
+      <para><varname>$KERNEL_INSTALL_ENTRY_TOKEN</varname> is set for the plugins to the desired entry
+      "token" to use. It's an identifier that shall be used to identify the local installation, and is often
+      the machine ID, i.e. same as <varname>$KERNEL_INSTALL_MACHINE_ID</varname>, but might also be a
+      different type of identifier, for example a fixed string or the <varname>ID=</varname>,
+      <varname>IMAGE_ID=</varname> values from <filename>/etc/os-release</filename>. The string passed here
+      will be used to name Boot Loader Specification entries, or the directories the kernel image and initial
+      RAM disk images are placed into.</para>
+
+      <para>Note that while <varname>$KERNEL_INSTALL_ENTRY_TOKEN</varname> and
+      <varname>$KERNEL_INSTALL_MACHINE_ID</varname> are often set to the same value, the latter is guaranteed
+      to be a valid 32 character ID in lowercase hexadecimals while the former can be any short string. The
+      entry token to use is read from <filename>/etc/kernel/entry-token</filename>, if it exists. Otherwise a
+      few possible candidates below <varname>$BOOT</varname> are checked for Boot Loader Specification Type 1
+      entry directories, and if found the entry token is derived from that. If that is not successful,
+      <varname>$KERNEL_INSTALL_MACHINE_ID</varname> is used as fallback.</para>
+
+      <para><varname>$KERNEL_INSTALL_BOOT_ROOT</varname> is set for the plugins to the absolute path of the
+      root directory (mount point, usually) of the hierarchy where boot loader entries, kernel images, and
+      associated resources should be placed. This usually is the path where the XBOOTLDR partition or the ESP
+      (EFI System Partition) are mounted, and also conceptually referred to as <varname>$BOOT</varname>. Can
+      be overridden by setting <varname>$BOOT_ROOT</varname> (see below).</para>
+
+      <para><varname>$KERNEL_INSTALL_LAYOUT=auto|bls|uki|other|...</varname> is set for the plugins to specify the
+      installation layout. Additional layout names may be defined by convention. If a plugin uses a special layout,
+      it's encouraged to declare its own layout name and configure <varname>layout=</varname> in
+      <filename>install.conf</filename> upon initial installation. The following values are currently
+      understood:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term>bls</term>
+          <listitem>
+            <para>Standard <ulink url="https://uapi-group.org/specifications/specs/boot_loader_specification">Boot Loader
+            Specification</ulink> Type #1 layout, compatible with
+            <citerefentry><refentrytitle>systemd-boot</refentrytitle><manvolnum>7</manvolnum></citerefentry>:
+            entries in
+            <filename>$BOOT/loader/entries/<replaceable>ENTRY-TOKEN</replaceable>-<replaceable>KERNEL-VERSION</replaceable>[+<replaceable>TRIES</replaceable>].conf</filename>,
+            kernel and initrds under
+            <filename>$BOOT/<replaceable>ENTRY-TOKEN</replaceable>/<replaceable>KERNEL-VERSION</replaceable>/</filename></para>
+            <para>Implemented by <filename>90-loaderentry.install</filename>.</para>
+
+            <xi:include href="version-info.xml" xpointer="v250"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term>uki</term>
+          <listitem>
+            <para>Standard <ulink
+            url="https://uapi-group.org/specifications/specs/boot_loader_specification">Boot Loader
+            Specification</ulink> Type #2 layout, compatible with
+            <citerefentry><refentrytitle>systemd-boot</refentrytitle><manvolnum>7</manvolnum></citerefentry>:
+            unified kernel images under <filename>$BOOT/EFI/Linux</filename> as
+            <filename>$BOOT/EFI/Linux/<replaceable>ENTRY-TOKEN</replaceable>-<replaceable>KERNEL-VERSION</replaceable>[+<replaceable>TRIES</replaceable>].efi</filename>.</para>
+            <para>Implemented by <filename>90-uki-copy.install</filename>.</para>
+
+            <xi:include href="version-info.xml" xpointer="v253"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term>other</term>
+          <listitem>
+            <para>Some other layout not understood natively by <command>kernel-install</command>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v250"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term>auto</term>
+          <listitem>
+            <para>Pick the layout automatically. If the kernel is a UKI set layout to
+            <option>uki</option>. If not default to <option>bls</option> if
+            <filename>$BOOT/loader/entries.srel</filename> with content <literal>type1</literal> or
+            <filename>$BOOT/<replaceable>ENTRY-TOKEN</replaceable></filename> exists, or
+            <option>other</option> otherwise.</para>
+            <para>Leaving layout blank has the same effect. This is the default.</para>
+
+            <xi:include href="version-info.xml" xpointer="v254"/>
+          </listitem>
+        </varlistentry>
+      </variablelist>
+
+      <para><varname>$KERNEL_INSTALL_INITRD_GENERATOR</varname> and <varname>$KERNEL_INSTALL_UKI_GENERATOR</varname>
+      are set for plugins to select the initrd and/or UKI generator. This may be configured as
+      <varname>initrd_generator=</varname> and <varname>uki_generator=</varname> in <filename>install.conf</filename>, see below.</para>
+
+      <para><varname>$KERNEL_INSTALL_STAGING_AREA</varname> is set for plugins to a path to a directory.
+      Plugins may drop files in that directory, and they will be installed as part of the loader entry, based
+      on the file name and extension: Files named <filename>initrd*</filename> will be installed as <replaceable>INITRD-FILE</replaceable>s,
+      and files named <filename>microcode*</filename> will be prepended before <replaceable>INITRD-FILE</replaceable>s.</para>
+
+    </refsect2>
+
+    <refsect2>
+      <title>Environment variables understood by <command>kernel-install</command></title>
+
+      <para><varname>$KERNEL_INSTALL_CONF_ROOT</varname> can be set to override the location of the
+      configuration files read by <command>kernel-install</command>. When set,
+      <filename>install.conf</filename>, <filename>entry-token</filename>, and other files will be
+      read from this directory.</para>
+
+      <para><varname>$KERNEL_INSTALL_PLUGINS</varname> can be set to override the list of plugins executed by
+      <command>kernel-install</command>. The argument is a whitespace-separated list of paths.
+      <literal>KERNEL_INSTALL_PLUGINS=:</literal> may be used to prevent any plugins from running.
+      </para>
+
+      <para><varname>$MACHINE_ID</varname> can be set for <command>kernel-install</command> to override
+      <varname>$KERNEL_INSTALL_MACHINE_ID</varname>, the machine ID.</para>
+
+      <para><varname>$BOOT_ROOT</varname> can be set for <command>kernel-install</command> to override
+      <varname>$KERNEL_INSTALL_BOOT_ROOT</varname>, the installation location for boot entries.</para>
+
+      <para>The last two variables may also be set in <filename>install.conf</filename>. Variables set in the
+      environment take precedence over the values specified in the config file.</para>
+    </refsect2>
+  </refsect1>
+
+  <refsect1>
+    <title>Exit status</title>
+    <para>If every executable returns 0 or 77, 0 is returned, and a non-zero failure code otherwise.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Files</title>
+    <variablelist>
+      <varlistentry>
+        <term><filename>/etc/kernel/install.d/*.install</filename></term>
+        <term><filename>/usr/lib/kernel/install.d/*.install</filename></term>
+        <listitem>
+          <para>Drop-in files which are executed by <command>kernel-install</command>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v198"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>/etc/kernel/cmdline</filename></term>
+        <term><filename>/usr/lib/kernel/cmdline</filename></term>
+        <term><filename>/proc/cmdline</filename></term>
+        <listitem>
+          <para>Specifies the kernel command line to use. The first of the files that is found will be used.
+          <varname>$KERNEL_INSTALL_CONF_ROOT</varname> may be used to override the search path; see below for
+          details.</para>
+
+          <xi:include href="version-info.xml" xpointer="v198"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>/etc/kernel/devicetree</filename></term>
+        <term><filename>/usr/lib/kernel/devicetree</filename></term>
+        <listitem>
+          <para>Specifies the partial path to the file containing the device tree blob to install with the
+          kernel and use at boot. The first of the files that is found will be used.
+          <varname>$KERNEL_INSTALL_CONF_ROOT</varname> may be used to override the search path; see below for
+          details.</para>
+
+          <para>The <filename>devicetree</filename> file contains a path, and this path specifies a location
+          relative to the kernel install tree. A set of locations is checked, including in particular
+          <filename>/usr/lib/modules/<replaceable>KERNEL_VERSION</replaceable>/dtb/</filename>, which is the
+          recommended location to place the dtb files under. For example, with
+          <literal>broadcom/bcm2711-rpi-4-b.dtb</literal> in the <filename>devicetree</filename> file, the
+          device tree blob for the Raspberry Pi 4 Model B would be installed, and the actual file would be
+          <filename index='false'>/usr/lib/modules/<replaceable>KERNEL_VERSION</replaceable>/dtb/broadcom/bcm2711-rpi-4-b.dtb</filename>.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v255"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>/etc/kernel/tries</filename></term>
+        <listitem>
+          <para>Read by <filename>90-loaderentry.install</filename> and
+          <filename>90-uki-copy.install</filename>. If this file exists, a numeric value is read from it and
+          the naming of the generated entry file or UKI is altered to include it as
+          <filename>$BOOT/loader/entries/<replaceable>ENTRY-TOKEN</replaceable>-<replaceable>KERNEL-VERSION</replaceable>+<replaceable>TRIES</replaceable>.conf</filename>
+          or
+          <filename>$BOOT/EFI/Linux/<replaceable>ENTRY-TOKEN</replaceable>-<replaceable>KERNEL-VERSION</replaceable>+<replaceable>TRIES</replaceable>.efi</filename>,
+          respectively. This is useful for boot loaders such as
+          <citerefentry><refentrytitle>systemd-boot</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+          which implement boot attempt counting with a counter embedded in the entry file name.
+          <varname>$KERNEL_INSTALL_CONF_ROOT</varname> may be used to override the search path; see below for
+          details.</para>
+
+          <xi:include href="version-info.xml" xpointer="v240"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>/etc/kernel/entry-token</filename></term>
+        <listitem>
+          <para>If this file exists it is read and used as "entry token" for this system, i.e. is used for
+          naming Boot Loader Specification entries. See <varname>$KERNEL_INSTALL_ENTRY_TOKEN</varname> above
+          for details. <varname>$KERNEL_INSTALL_CONF_ROOT</varname> may be used to override the search path; see
+          below for details.</para>
+
+          <xi:include href="version-info.xml" xpointer="v251"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term>
+          <filename>/etc/machine-id</filename>
+        </term>
+          <listitem>
+            <para>The content of this file specifies the machine identification
+            <replaceable>MACHINE-ID</replaceable>.</para>
+
+            <xi:include href="version-info.xml" xpointer="v198"/>
+          </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>/etc/os-release</filename></term>
+        <term><filename>/usr/lib/os-release</filename></term>
+        <listitem>
+            <para>Read by <filename>90-loaderentry.install</filename>. If available,
+            <varname>PRETTY_NAME=</varname> is read from these files and used as the title of the boot menu
+            entry. Otherwise, <literal>Linux <replaceable>KERNEL-VERSION</replaceable></literal> will be
+            used.</para>
+
+            <xi:include href="version-info.xml" xpointer="v198"/>
+          </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><filename>/etc/kernel/install.conf</filename></term>
+        <term><filename>/usr/lib/kernel/install.conf</filename></term>
+        <listitem>
+          <para>Configuration file with options for <command>kernel-install</command>, as a series of
+          <varname>KEY=</varname><replaceable>VALUE</replaceable> assignments, compatible with shell syntax,
+          following the same rules as described in
+          <citerefentry><refentrytitle>os-release</refentrytitle><manvolnum>5</manvolnum></citerefentry>. The
+          first of the files that is found will be used. <varname>$KERNEL_INSTALL_CONF_ROOT</varname> may be
+          used to override the search path; see below for details.</para>
+
+          <para>Currently, the following keys are supported:
+          <varname>MACHINE_ID=</varname>,
+          <varname>BOOT_ROOT=</varname>,
+          <varname>layout=</varname>,
+          <varname>initrd_generator=</varname>,
+          <varname>uki_generator=</varname>.
+          See the Environment variables section above for details.</para>
+
+          <xi:include href="version-info.xml" xpointer="v250"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><filename>/etc/kernel/uki.conf</filename></term>
+        <listitem>
+          <para>Ini-style configuration file for
+          <citerefentry><refentrytitle>ukify</refentrytitle><manvolnum>1</manvolnum></citerefentry> which is
+          only effective when <varname>$KERNEL_INSTALL_LAYOUT</varname> or <varname>layout=</varname> in
+          <filename>install.conf</filename> is set to <option>uki</option> and
+          <varname>$KERNEL_INSTALL_UKI_GENERATOR</varname> or <varname>uki_generator=</varname> in
+          <filename>install.conf</filename> is set to <option>ukify</option>, or is unset.
+          <varname>$KERNEL_INSTALL_CONF_ROOT</varname> may be used to override the search path; see below for
+          details.</para>
+
+          <xi:include href="version-info.xml" xpointer="v255"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>/usr/lib/modules/<replaceable>KERNEL-VERSION/</replaceable></filename></term>
+
+        <listitem>
+          <para>Location for installed kernel modules and other kernel related resources. For each locally
+          installed kernel a directory named after the kernel version (<command>uname -r</command>) is
+          kept.</para>
+
+          <xi:include href="version-info.xml" xpointer="v255"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>/usr/lib/modules/<replaceable>KERNEL-VERSION/vmlinuz</replaceable></filename></term>
+
+        <listitem>
+          <para>Location for installed kernel images. This is the recommended location for OS package
+          managers to install kernel images into (as applicable), from which <command>kernel-install
+          add</command> then copies it into the final boot partition.</para>
+
+          <xi:include href="version-info.xml" xpointer="v255"/>
+        </listitem>
+      </varlistentry>
+
+    </variablelist>
+
+    <para>For various cases listed above, if the <varname>$KERNEL_INSTALL_CONF_ROOT</varname> environment
+    variable is set, it will override the search path. The files will be loaded <emphasis>only</emphasis>
+    from the directory specified by the environment variable. When the variable is not set, the listed paths
+    are tried in turn, and the first file that exists is used.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>os-release</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>depmod</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-boot</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>ukify</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <ulink url="https://uapi-group.org/specifications/specs/boot_loader_specification">Boot Loader Specification</ulink>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/libsystemd-pkgconfig.xml b/man/libsystemd-pkgconfig.xml
new file mode 100644
index 0000000..3d22870
--- /dev/null
+++ b/man/libsystemd-pkgconfig.xml
@@ -0,0 +1,16 @@
+<?xml version="1.0"?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refsect1 xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <title>Notes</title>
+
+  <para id='pkgconfig-text'>Functions described here are available as a shared
+  library, which can be compiled against and linked to with the
+  <constant>libsystemd</constant> <citerefentry project='die-net'><refentrytitle>pkg-config</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+  file.</para>
+
+  <xi:include href="threads-aware.xml" xpointer="getenv"/>
+</refsect1>
diff --git a/man/libsystemd.xml b/man/libsystemd.xml
new file mode 100644
index 0000000..e9de64c
--- /dev/null
+++ b/man/libsystemd.xml
@@ -0,0 +1,89 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="libsystemd"
+  xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>libsystemd</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>libsystemd</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>libsystemd</refname>
+    <refpurpose>Functions for implementing services and interacting with systemd</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <programlisting>
+#include &lt;systemd/sd-bus.h&gt;
+#include &lt;systemd/sd-bus-vtable.h&gt;
+#include &lt;systemd/sd-bus-protocol.h&gt;
+#include &lt;systemd/sd-daemon.h&gt;
+#include &lt;systemd/sd-device.h&gt;
+#include &lt;systemd/sd-event.h&gt;
+#include &lt;systemd/sd-gpt.h&gt;
+#include &lt;systemd/sd-hwdb.h&gt;
+#include &lt;systemd/sd-id128.h&gt;
+#include &lt;systemd/sd-journal.h&gt;
+#include &lt;systemd/sd-login.h&gt;
+#include &lt;systemd/sd-messages.h&gt;
+#include &lt;systemd/sd-path.h&gt;
+    </programlisting>
+
+    <cmdsynopsis>
+      <command>pkg-config --cflags --libs libsystemd</command>
+    </cmdsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>The <filename>libsystemd</filename> library provides functions that allow interacting with various
+    interfaces provided by the
+    <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> service
+    manager, as well as various other functions and constants useful for implementing services in
+    general.</para>
+
+    <para>See
+    <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd-bus-errors</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd-daemon</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd-device</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd-hwdb</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd-id128</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd-journal</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    and
+    <citerefentry><refentrytitle>sd-login</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    for information about different parts of the library interface.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Interface stability</title>
+
+    <para>Strict backwards-compatibility is maintained for the API (application programming interface) and
+    ABI (application binary interface). Symbol versioning is used, with symbols only added and never removed.
+    </para>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>libudev</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry project='die-net'><refentrytitle>pkg-config</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <ulink url="https://systemd.io/PORTABILITY_AND_STABILITY/">Interface Portability and Stability Promise</ulink>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/libudev.xml b/man/libudev.xml
new file mode 100644
index 0000000..684bd47
--- /dev/null
+++ b/man/libudev.xml
@@ -0,0 +1,99 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [
+<!ENTITY % entities SYSTEM "custom-entities.ent" >
+%entities;
+]>
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="libudev"
+  xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>libudev</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>libudev</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>libudev</refname>
+    <refpurpose>API for enumerating and introspecting local devices</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;libudev.h&gt;</funcsynopsisinfo>
+    </funcsynopsis>
+
+    <cmdsynopsis>
+      <command>pkg-config --cflags --libs libudev</command>
+    </cmdsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><filename>libudev.h</filename> provides an API to introspect and enumerate devices on the local
+    system. This library is supported, but should not be used in new projects. Please see
+    <citerefentry><refentrytitle>sd-device</refentrytitle><manvolnum>3</manvolnum></citerefentry> for an
+    equivalent replacement with a more modern API.</para>
+
+    <para>All functions require a libudev context to operate. This
+    context can be created via
+    <citerefentry><refentrytitle>udev_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+    It is used to track library state and link objects together. No
+    global state is used by libudev, everything is always linked to
+    a udev context.</para>
+
+    <xi:include href="threads-aware.xml" xpointer="strict"/>
+    <xi:include href="threads-aware.xml" xpointer="getenv"/>
+
+    <para>To introspect a local device on a system, a udev device
+    object can be created via
+    <citerefentry><refentrytitle>udev_device_new_from_syspath</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    and friends. The device object allows one to query current state,
+    read and write attributes and lookup properties of the device in
+    question.</para>
+
+    <para>To enumerate local devices on the system, an enumeration
+    object can be created via
+    <citerefentry><refentrytitle>udev_enumerate_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para>
+
+    <para>To monitor the local system for hotplugged or unplugged
+    devices, a monitor can be created via
+    <citerefentry><refentrytitle>udev_monitor_new_from_netlink</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para>
+
+    <para>Whenever libudev returns a list of objects, the
+    <citerefentry><refentrytitle>udev_list_entry</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    API should be used to iterate, access and modify those lists.</para>
+
+    <para>Furthermore, libudev also exports legacy APIs that should
+    not be used by new software (and as such are not documented as
+    part of this manual). This includes the hardware database known
+    as <constant>udev_hwdb</constant> (please use the new
+    <citerefentry><refentrytitle>sd-hwdb</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    API instead) and the <constant>udev_queue</constant> object to
+    query the udev daemon (which should not be used by new software
+    at all).</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>udev_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>udev_device_new_from_syspath</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>udev_enumerate_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>udev_monitor_new_from_netlink</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>udev_list_entry</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-device</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-hwdb</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry project='die-net'><refentrytitle>pkg-config</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/loader.conf.xml b/man/loader.conf.xml
new file mode 100644
index 0000000..a7db82d
--- /dev/null
+++ b/man/loader.conf.xml
@@ -0,0 +1,430 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="loader.conf" conditional='ENABLE_BOOTLOADER'
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+  <refentryinfo>
+    <title>loader.conf</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>loader.conf</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>loader.conf</refname>
+    <refpurpose>Configuration file for systemd-boot</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename><replaceable>ESP</replaceable>/loader/loader.conf</filename>,
+    <filename><replaceable>ESP</replaceable>/loader/entries/*.conf</filename>
+    <filename><replaceable>XBOOTLDR</replaceable>/loader/entries/*.conf</filename>
+    </para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>
+    <citerefentry><refentrytitle>systemd-boot</refentrytitle><manvolnum>7</manvolnum></citerefentry> will
+    read <filename><replaceable>ESP</replaceable>/loader/loader.conf</filename>, and any files with the
+    <literal>.conf</literal> extension under
+    <filename><replaceable>ESP</replaceable>/loader/entries/</filename> on the EFI system partition (ESP),
+    and <filename><replaceable>XBOOTLDR</replaceable>/loader/entries/</filename> on the extended boot loader
+    partition (XBOOTLDR) as defined by <ulink url="https://uapi-group.org/specifications/specs/boot_loader_specification">Boot Loader
+    Specification</ulink>.
+    </para>
+
+    <para>Each of these configuration files must consist of series of newline (i.e. ASCII code 10) separated
+    lines, each consisting of an option name, followed by whitespace, and the option
+    value. <literal>#</literal> may be used to start a comment line. Empty and comment lines are ignored. The
+    files use UTF-8 encoding.</para>
+
+    <para>Boolean arguments may be written as
+    <literal>yes</literal>/<literal>y</literal>/<literal>true</literal>/<literal>t</literal>/<literal>on</literal>/<literal>1</literal> or
+    <literal>no</literal>/<literal>n</literal>/<literal>false</literal>/<literal>f</literal>/<literal>off</literal>/<literal>0</literal>.
+    </para>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>The configuration options supported by
+    <filename><replaceable>ESP</replaceable>/loader/entries/*.conf</filename> and
+    <filename><replaceable>XBOOTLDR</replaceable>/loader/entries/*.conf</filename> files are defined as part
+    of the <ulink url="https://uapi-group.org/specifications/specs/boot_loader_specification">Boot Loader
+    Specification</ulink>.</para>
+
+    <para>The following configuration are supported by the <filename>loader.conf</filename> configuration
+    file:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term>default</term>
+
+        <listitem><para>A glob pattern to select the default entry. The default entry
+        may be changed in the boot menu itself, in which case the name of the
+        selected entry will be stored as an EFI variable, overriding this option.
+        </para>
+
+        <para>If set to <literal>@saved</literal> the chosen entry will be saved as an EFI variable
+        on every boot and automatically selected the next time the boot loader starts.</para>
+
+        <table>
+          <title>Automatically detected entries will use the following names:</title>
+
+          <tgroup cols='2'>
+            <colspec colname='name' />
+            <colspec colname='expl' />
+            <thead>
+              <row>
+                <entry>Name</entry>
+                <entry>Description</entry>
+              </row>
+            </thead>
+            <tbody>
+              <row>
+                <entry>auto-efi-default</entry>
+                <entry>EFI Default Loader</entry>
+              </row>
+              <row>
+                <entry>auto-efi-shell</entry>
+                <entry>EFI Shell</entry>
+              </row>
+              <row>
+                <entry>auto-osx</entry>
+                <entry>macOS</entry>
+              </row>
+              <row>
+                <entry>auto-poweroff</entry>
+                <entry>Power Off The System</entry>
+              </row>
+              <row>
+                <entry>auto-reboot</entry>
+                <entry>Reboot The System</entry>
+              </row>
+              <row>
+                <entry>auto-reboot-to-firmware-setup</entry>
+                <entry>Reboot Into Firmware Interface</entry>
+              </row>
+              <row>
+                <entry>auto-windows</entry>
+                <entry>Windows Boot Manager</entry>
+              </row>
+            </tbody>
+          </tgroup>
+        </table>
+
+        <para>Supported glob wildcard patterns are <literal>?</literal>, <literal>*</literal>, and
+        <literal>[…]</literal> (including ranges). Note that these patterns use the same syntax as
+        <citerefentry project='man-pages'><refentrytitle>glob</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+        but do not support all features. In particular, set negation and named character classes are not
+        supported. The matching is done case-insensitively on the entry ID (as shown by <command>bootctl
+        list</command>).</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term>timeout</term>
+
+        <listitem><para>How long the boot menu should be shown before the default
+        entry is booted, in seconds. This may be changed in the boot menu itself and
+        will be stored as an EFI variable in that case, overriding this option.
+        </para>
+
+        <para>If set to <literal>menu-disabled</literal> or <literal>menu-hidden</literal> or <literal>0</literal>
+        (the default), no menu is shown and the default entry will be booted immediately. Unless
+        <literal>menu-disabled</literal> is used, the menu can be shown
+        by pressing and holding a key before systemd-boot is launched. Setting this to
+        <literal>menu-force</literal> disables the timeout while always showing the menu.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term>console-mode</term>
+
+        <listitem><para>This option configures the resolution of the console. This may be changed in
+        the boot menu itself and will be stored as an EFI variable in that case, overriding this
+        option.</para>
+
+        <para>Takes a number or one of the special values listed below. The following
+        values may be used:</para>
+
+        <variablelist>
+          <varlistentry>
+            <term>0</term>
+            <listitem>
+              <para>Standard UEFI 80x25 mode</para>
+
+            <xi:include href="version-info.xml" xpointer="v239"/>
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term>1</term>
+            <listitem>
+              <para>80x50 mode, not supported by all devices</para>
+
+            <xi:include href="version-info.xml" xpointer="v239"/>
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term>2</term>
+            <listitem>
+              <para>the first non-standard mode provided by the device
+              firmware, if any</para>
+
+              <xi:include href="version-info.xml" xpointer="v239"/>
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term>auto</term>
+            <listitem>
+              <para>Pick a suitable mode automatically using heuristics</para>
+
+            <xi:include href="version-info.xml" xpointer="v239"/>
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term>max</term>
+            <listitem>
+              <para>Pick the highest-numbered available mode</para>
+
+            <xi:include href="version-info.xml" xpointer="v239"/>
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term>keep</term>
+            <listitem>
+              <para>Keep the mode selected by firmware (the default)</para>
+
+            <xi:include href="version-info.xml" xpointer="v239"/>
+            </listitem>
+          </varlistentry>
+        </variablelist>
+
+          <xi:include href="version-info.xml" xpointer="v239"/>
+
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term>editor</term>
+
+        <listitem><para>Takes a boolean argument. Enable (the default) or disable the
+        editor. The editor should be disabled if the machine can be accessed by
+        unauthorized persons.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term>auto-entries</term>
+
+        <listitem><para>Takes a boolean argument. Enable (the default) or disable
+        entries for other boot entries found on the boot partition. In particular,
+        this may be useful when loader entries are created to show replacement
+        descriptions for those entries.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term>auto-firmware</term>
+
+        <listitem><para>A boolean controlling the presence of the <literal>Reboot Into Firmware
+        Interface</literal> entry (enabled by default). If this is disabled, the firmware interface may still
+        be reached by using the <keycap>f</keycap> key.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term>beep</term>
+
+        <listitem><para>Takes a boolean argument. If timeout enabled beep every second, otherwise beep n times when n-th entry in boot menu is selected (default disabled).
+        Currently, only x86 is supported, where it uses the PC speaker.</para>
+
+        <xi:include href="version-info.xml" xpointer="v251"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term>secure-boot-enroll</term>
+
+        <listitem><para>Danger: this feature might soft-brick your device if used improperly.</para>
+
+        <para>Controls enrollment of secure boot keys found on the ESP if the system is in setup mode:
+        <variablelist>
+          <varlistentry>
+            <term><option>off</option></term>
+            <listitem><para>No action is taken.</para>
+
+            <xi:include href="version-info.xml" xpointer="v253"/></listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><option>manual</option></term>
+            <listitem><para>Boot entries for found secure boot keys are created that allow manual
+            enrollment.</para>
+
+            <xi:include href="version-info.xml" xpointer="v253"/></listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><option>if-safe</option></term>
+            <listitem><para>Same behavior as <option>manual</option>, but will try to automatically
+            enroll the key <literal>auto</literal> if it is considered to be safe. Currently, this is only
+            the case if the system is running inside a virtual machine.</para>
+
+            <xi:include href="version-info.xml" xpointer="v253"/></listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><option>force</option></term>
+            <listitem><para>Always enroll the <literal>auto</literal> key if found. Note that a warning
+            message with a timeout will still be shown if this operation is unknown to be safe.</para>
+
+            <xi:include href="version-info.xml" xpointer="v253"/></listitem>
+          </varlistentry>
+        </variablelist>
+        </para>
+
+        <para>The different sets of variables can be set up under
+        <filename>/loader/keys/<replaceable>NAME</replaceable></filename> where
+        <replaceable>NAME</replaceable> is the name that is going to be used as the name of the entry. This
+        allows one to ship multiple sets of Secure Boot variables and choose which one to enroll at runtime.
+        </para>
+
+        <para>Supported Secure Boot variables are one database for authorized images, one for the key
+        exchange key (KEK) and one for the platform key (PK). For more information, refer to the
+        <ulink url="https://uefi.org/specifications">UEFI specification</ulink>, under Secure Boot and Driver
+        Signing. Another resource that describe the interplay of the different variables is the
+        <ulink url="https://edk2-docs.gitbook.io/understanding-the-uefi-secure-boot-chain/secure_boot_chain_in_uefi/uefi_secure_boot">
+        EDK2 documentation</ulink>.</para>
+
+        <para>A complete set of UEFI variable includes <filename>db.auth</filename>, <filename>KEK.auth</filename>
+        and <filename>PK.auth</filename>. Note that these files need to be authenticated UEFI variables. See
+        below for an example of how to generate them from regular X.509 keys.</para>
+
+        <programlisting>uuid=$(systemd-id128 new --uuid)
+for key in PK KEK db; do
+  openssl req -new -x509 -subj "/CN=${key}/" -keyout "${key}.key" -out "${key}.pem"
+  openssl x509 -outform DER -in "${key}.pem" -out "${key}.der"
+  sbsiglist --owner "${uuid}" --type x509 --output "${key}.esl" "${key}.der"
+done
+
+# See also: <ulink url="https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance">Windows Secure Boot Key Creation and Management Guidance</ulink>
+curl --location \
+     "https://go.microsoft.com/fwlink/p/?linkid=321192" -o ms-db-2011.der \
+     "https://go.microsoft.com/fwlink/p/?linkid=321185" -o ms-kek-2011.der \
+     "https://go.microsoft.com/fwlink/p/?linkid=321194" -o ms-uefi-db-2011.der \
+     "https://go.microsoft.com/fwlink/p/?linkid=2239776" -o ms-db-2023.der \
+     "https://go.microsoft.com/fwlink/p/?linkid=2239775" -o ms-kek-2023.der \
+     "https://go.microsoft.com/fwlink/p/?linkid=2239872" -o ms-uefi-db-2023.der
+sha1sum -c &lt;&lt;END
+580a6f4cc4e4b669b9ebdc1b2b3e087b80d0678d  ms-db-2011.der
+31590bfd89c9d74ed087dfac66334b3931254b30  ms-kek-2011.der
+46def63b5ce61cf8ba0de2e6639c1019d0ed14f3  ms-uefi-db-2011.der
+45a0fa32604773c82433c3b7d59e7466b3ac0c67  ms-db-2023.der
+459ab6fb5e284d272d5e3e6abc8ed663829d632b  ms-kek-2023.der
+b5eeb4a6706048073f0ed296e7f580a790b59eaa  ms-uefi-db-2023.der
+END
+for key in ms-*.der; do
+  sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output "${key%der}esl" "${key}"
+done
+
+# Optionally add Microsoft Windows certificates (needed to boot into Windows).
+cat ms-db-*.esl >>db.esl
+
+# Optionally add Microsoft UEFI certificates for firmware drivers / option ROMs and third-party
+# boot loaders (including shim). This is highly recommended on real hardware as not including this
+# may soft-brick your device (see next paragraph).
+cat ms-uefi-*.esl >>db.esl
+
+# Optionally add Microsoft KEK certificates. Recommended if either of the Microsoft keys is used as
+# the official UEFI revocation database is signed with this key. The revocation database can be
+# updated with <citerefentry project='man-pages'><refentrytitle>fwupdmgr</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
+cat ms-kek-*.esl >>KEK.esl
+
+attr=NON_VOLATILE,RUNTIME_ACCESS,BOOTSERVICE_ACCESS,TIME_BASED_AUTHENTICATED_WRITE_ACCESS
+sbvarsign --attr "${attr}" --key PK.key --cert PK.pem --output PK.auth PK PK.esl
+sbvarsign --attr "${attr}" --key PK.key --cert PK.pem --output KEK.auth KEK KEK.esl
+sbvarsign --attr "${attr}" --key KEK.key --cert KEK.pem --output db.auth db db.esl
+        </programlisting>
+
+        <para>This feature is considered dangerous because even if all the required files are signed with the
+        keys being loaded, some files necessary for the system to function properly still won't be. This
+        is especially the case with Option ROMs (e.g. for storage controllers or graphics cards). See
+        <ulink url="https://github.com/Foxboron/sbctl/wiki/FAQ#option-rom">Secure Boot and Option ROMs</ulink>
+        for more details.</para>
+
+        <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term>reboot-for-bitlocker</term>
+
+        <listitem><para>Caveat: This feature is experimental, and is likely to be changed (or removed in its
+        current form) in a future version of systemd.</para>
+
+        <para>Work around BitLocker requiring a recovery key when the boot loader was
+        updated (disabled by default).</para>
+
+        <para>Try to detect BitLocker encrypted drives along with an active TPM. If both are found and
+        Windows Boot Manager is selected in the boot menu, set the <literal>BootNext</literal> EFI variable
+        and restart the system. The firmware will then start Windows Boot Manager directly, leaving the TPM
+        PCRs in expected states so that Windows can unseal the encryption key. This allows
+        <citerefentry><refentrytitle>systemd-boot</refentrytitle><manvolnum>7</manvolnum></citerefentry> to
+        be updated without having to provide the recovery key for BitLocker drive unlocking.</para>
+
+        <para>Note that the PCRs that Windows uses can be configured with the
+        <literal>Configure TPM platform validation profile for native UEFI firmware configurations</literal>
+        group policy under <literal>Computer Configuration\Administrative Templates\Windows Components\BitLocker Drive Encryption</literal>.
+        When Secure Boot is enabled, changing this to PCRs <literal>0,2,7,11</literal> should be safe.
+        The TPM key protector needs to be removed and then added back for the PCRs on an already
+        encrypted drive to change. If PCR 4 is not measured, this setting can be disabled to speed
+        up booting into Windows.</para>
+
+        <xi:include href="version-info.xml" xpointer="v251"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Example</title>
+
+    <programlisting># /boot/efi/loader/loader.conf
+timeout 0
+default 01234567890abcdef1234567890abdf0-*
+editor no
+    </programlisting>
+
+    <para>The menu will not be shown by default (the menu can still be shown by
+    pressing and holding a key during boot). One of the entries with files with a
+    name starting with <literal>01234567890abcdef1234567890abdf0-</literal> will be
+    selected by default. If more than one entry matches, the one with the highest
+    priority will be selected (generally the one with the highest version number).
+    The editor will be disabled, so it is not possible to alter the kernel command
+    line.</para>
+  </refsect1>
+
+  <refsect1>
+      <title>See Also</title>
+      <para>
+        <citerefentry><refentrytitle>systemd-boot</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>bootctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+      </para>
+  </refsect1>
+</refentry>
diff --git a/man/locale.conf.xml b/man/locale.conf.xml
new file mode 100644
index 0000000..24be105
--- /dev/null
+++ b/man/locale.conf.xml
@@ -0,0 +1,128 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="locale.conf">
+  <refentryinfo>
+    <title>locale.conf</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>locale.conf</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>locale.conf</refname>
+    <refpurpose>Configuration file for locale settings</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>/etc/locale.conf</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>The <filename>/etc/locale.conf</filename> file configures
+    system-wide locale settings. It is read at early boot by
+    <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>.</para>
+
+    <para>The format of <filename>locale.conf</filename> is a newline-separated list of environment-like
+    shell-compatible variable assignments, ignoring comments and empty lines. It is possible to source the
+    configuration from shell scripts, however, beyond mere variable assignments, no shell features are
+    supported, allowing applications to read the file without implementing a shell compatible execution
+    engine. See
+    <citerefentry><refentrytitle>os-release</refentrytitle><manvolnum>5</manvolnum></citerefentry> for a
+    detailed description of the format.</para>
+
+    <para>Note that the kernel command line options
+    <varname>locale.LANG=</varname>,
+    <varname>locale.LANGUAGE=</varname>,
+    <varname>locale.LC_CTYPE=</varname>,
+    <varname>locale.LC_NUMERIC=</varname>,
+    <varname>locale.LC_TIME=</varname>,
+    <varname>locale.LC_COLLATE=</varname>,
+    <varname>locale.LC_MONETARY=</varname>,
+    <varname>locale.LC_MESSAGES=</varname>,
+    <varname>locale.LC_PAPER=</varname>,
+    <varname>locale.LC_NAME=</varname>,
+    <varname>locale.LC_ADDRESS=</varname>,
+    <varname>locale.LC_TELEPHONE=</varname>,
+    <varname>locale.LC_MEASUREMENT=</varname>,
+    <varname>locale.LC_IDENTIFICATION=</varname> may be
+    used to override the locale settings at boot.</para>
+
+    <para>The locale settings configured in
+    <filename>/etc/locale.conf</filename> are system-wide and are
+    inherited by every service or user, unless overridden or unset by
+    individual programs or users.</para>
+
+    <para>Depending on the operating system, other configuration files
+    might be checked for locale configuration as well, however only as
+    fallback.</para>
+
+    <para><filename>/etc/locale.conf</filename> can be updated
+    using
+    <citerefentry><refentrytitle>systemd-localed.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+    <citerefentry project='man-pages'><refentrytitle>localectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    may be used to alter the settings in this file during runtime from
+    the command line. Use
+    <citerefentry><refentrytitle>systemd-firstboot</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    to customize them on mounted (but not booted) system images.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>The following locale settings may be set using
+    <filename>/etc/locale.conf</filename>:
+    <varname>LANG=</varname>,
+    <varname>LANGUAGE=</varname>,
+    <varname>LC_CTYPE=</varname>,
+    <varname>LC_NUMERIC=</varname>,
+    <varname>LC_TIME=</varname>,
+    <varname>LC_COLLATE=</varname>,
+    <varname>LC_MONETARY=</varname>,
+    <varname>LC_MESSAGES=</varname>,
+    <varname>LC_PAPER=</varname>,
+    <varname>LC_NAME=</varname>,
+    <varname>LC_ADDRESS=</varname>,
+    <varname>LC_TELEPHONE=</varname>,
+    <varname>LC_MEASUREMENT=</varname>,
+    <varname>LC_IDENTIFICATION=</varname>.
+    Note that <varname>LC_ALL</varname> may not be configured in this
+    file. For details about the meaning and semantics of these
+    settings, refer to
+    <citerefentry project='man-pages'><refentrytitle>locale</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Example</title>
+
+    <example>
+      <title>German locale with English messages</title>
+
+      <para><filename>/etc/locale.conf</filename>:</para>
+
+      <programlisting># Custom settings
+
+LANG=de_DE.UTF-8
+LC_MESSAGES=en_US.UTF-8</programlisting>
+    </example>
+
+  </refsect1>
+
+  <refsect1>
+      <title>See Also</title>
+      <para>
+        <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+        <citerefentry project='man-pages'><refentrytitle>locale</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+        <citerefentry project='man-pages'><refentrytitle>localectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd-localed.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd-firstboot</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+      </para>
+  </refsect1>
+</refentry>
diff --git a/man/localectl.xml b/man/localectl.xml
new file mode 100644
index 0000000..eb22857
--- /dev/null
+++ b/man/localectl.xml
@@ -0,0 +1,229 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="localectl" conditional='ENABLE_LOCALED'
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>localectl</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>localectl</refentrytitle>
+    <manvolnum>1</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>localectl</refname>
+    <refpurpose>Control the system locale and keyboard layout settings</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <cmdsynopsis>
+      <command>localectl</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="req">COMMAND</arg>
+    </cmdsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>localectl</command> may be used to query and change
+    the system locale and keyboard layout settings. It communicates with
+    <citerefentry><refentrytitle>systemd-localed</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    to modify files such as <filename>/etc/locale.conf</filename> and
+    <filename>/etc/vconsole.conf</filename>.</para>
+
+    <para>The system locale controls the language settings of system
+    services and of the UI before the user logs in, such as the
+    display manager, as well as the default for users after
+    login.</para>
+
+    <para>The keyboard settings control the keyboard layout used on
+    the text console and of the graphical UI before the user logs in,
+    such as the display manager, as well as the default for users
+    after login.</para>
+
+    <para>Note that the changes performed using this tool might require the initrd to be rebuilt to take
+    effect during early system boot.  The initrd is not rebuilt automatically by
+    <filename>localectl</filename>, this task has to be performed manually, usually using a tool like
+    <citerefentry
+    project='man-pages'><refentrytitle>dracut</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+    </para>
+
+    <para>Note that
+    <citerefentry><refentrytitle>systemd-firstboot</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    may be used to initialize the system locale for mounted (but not booted)
+    system images.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Commands</title>
+
+    <para>The following commands are understood:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><command>status</command></term>
+
+        <listitem><para>Show current settings of the system locale and keyboard mapping.
+        If no command is specified, this is the implied default.</para>
+
+        <xi:include href="version-info.xml" xpointer="v195"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>set-locale LOCALE</command></term>
+        <term><command>set-locale VARIABLE=LOCALE…</command></term>
+
+        <listitem><para>Set the system locale. This takes one locale such as <literal>en_US.UTF-8</literal>, or takes one or more
+        locale assignments such as <literal>LANG=de_DE.utf8</literal>, <literal>LC_MESSAGES=en_GB.utf8</literal>, and so on. If
+        one locale without variable name is provided, then <literal>LANG=</literal> locale variable will be set. See
+        <citerefentry project='man-pages'><refentrytitle>locale</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+        for details on the available settings and their meanings. Use
+        <command>list-locales</command> for a list of available
+        locales (see below). </para>
+
+        <xi:include href="version-info.xml" xpointer="v195"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>list-locales</command></term>
+
+        <listitem><para>List available locales useful for
+        configuration with
+        <command>set-locale</command>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v195"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>set-keymap MAP [TOGGLEMAP]</command></term>
+
+        <listitem><para>Set the system keyboard mapping for the
+        console and X11. This takes a mapping name (such as "de" or
+        "us"), and possibly a second one to define a toggle keyboard
+        mapping. Unless <option>--no-convert</option> is passed, the
+        selected setting is also applied as the default system
+        keyboard mapping of X11, after converting it to the closest
+        matching X11 keyboard mapping. Use
+        <command>list-keymaps</command> for a list of available
+        keyboard mappings (see below).</para>
+
+        <xi:include href="version-info.xml" xpointer="v195"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>list-keymaps</command></term>
+
+        <listitem><para>List available keyboard mappings for the
+        console, useful for configuration with
+        <command>set-keymap</command>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v195"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>set-x11-keymap LAYOUT [MODEL [VARIANT [OPTIONS]]]</command></term>
+
+        <listitem><para>Set the system default keyboard mapping for
+        X11 and the virtual console. This takes a keyboard mapping
+        name (such as <literal>de</literal> or <literal>us</literal>),
+        and possibly a model, variant, and options, see
+        <citerefentry><refentrytitle>kbd</refentrytitle><manvolnum>4</manvolnum></citerefentry>
+        for details. Unless <option>--no-convert</option> is passed,
+        the selected setting is also applied as the system console
+        keyboard mapping, after converting it to the closest matching
+        console keyboard mapping.</para>
+
+        <xi:include href="version-info.xml" xpointer="v195"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>list-x11-keymap-models</command></term>
+        <term><command>list-x11-keymap-layouts</command></term>
+        <term><command>list-x11-keymap-variants [LAYOUT]</command></term>
+        <term><command>list-x11-keymap-options</command></term>
+
+        <listitem><para>List available X11 keymap models, layouts,
+        variants and options, useful for configuration with
+        <command>set-keymap</command>. The command
+        <command>list-x11-keymap-variants</command> optionally takes a
+        layout parameter to limit the output to the variants suitable
+        for the specific layout.</para>
+
+        <xi:include href="version-info.xml" xpointer="v201"/></listitem>
+      </varlistentry>
+    </variablelist>
+
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>The following options are understood:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><option>--no-ask-password</option></term>
+
+        <listitem><para>Do not query the user for authentication for
+        privileged operations.</para>
+
+        <xi:include href="version-info.xml" xpointer="v195"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--no-convert</option></term>
+
+        <listitem><para>If <command>set-keymap</command> or
+        <command>set-x11-keymap</command> is invoked and this option
+        is passed, then the keymap will not be converted from the
+        console to X11, or X11 to console,
+        respectively.</para>
+
+        <xi:include href="version-info.xml" xpointer="v195"/></listitem>
+      </varlistentry>
+
+      <xi:include href="user-system-options.xml" xpointer="host" />
+      <xi:include href="user-system-options.xml" xpointer="machine" />
+
+      <xi:include href="standard-options.xml" xpointer="help" />
+      <xi:include href="standard-options.xml" xpointer="version" />
+      <xi:include href="standard-options.xml" xpointer="no-pager" />
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Exit status</title>
+
+    <para>On success, 0 is returned, a non-zero failure code
+    otherwise.</para>
+  </refsect1>
+
+  <xi:include href="common-variables.xml" />
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>locale</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>locale.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>vconsole.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry project='mankier'><refentrytitle>loadkeys</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>kbd</refentrytitle><manvolnum>4</manvolnum></citerefentry>,
+      <ulink url="http://www.x.org/releases/current/doc/xorg-docs/input/XKB-Config.html">
+        The XKB Configuration Guide
+      </ulink>,
+      <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-localed.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-firstboot</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>dracut</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/localtime.xml b/man/localtime.xml
new file mode 100644
index 0000000..e486474
--- /dev/null
+++ b/man/localtime.xml
@@ -0,0 +1,72 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="localtime">
+  <refentryinfo>
+    <title>localtime</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>localtime</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>localtime</refname>
+    <refpurpose>Local timezone configuration file</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>/etc/localtime</filename> -&gt; <filename>../usr/share/zoneinfo/…</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>The <filename>/etc/localtime</filename> file configures the
+    system-wide timezone of the local system that is used by
+    applications for presentation to the user. It should be an
+    absolute or relative symbolic link pointing to
+    <filename>/usr/share/zoneinfo/</filename>, followed by a timezone
+    identifier such as <literal>Europe/Berlin</literal> or
+    <literal>Etc/UTC</literal>. The resulting link should lead to the
+    corresponding binary
+    <citerefentry project='man-pages'><refentrytitle>tzfile</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    timezone data for the configured timezone.</para>
+
+    <para>Because the timezone identifier is extracted from the
+    symlink target name of <filename>/etc/localtime</filename>, this
+    file may not be a normal file or hardlink.</para>
+
+    <para>If <filename>/etc/localtime</filename> is missing, the
+    default <literal>UTC</literal> timezone is used.</para>
+
+    <para>The timezone may be overridden for individual programs by
+    using the <varname>$TZ</varname> environment variable. See
+    <citerefentry project='man-pages'><refentrytitle>environ</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
+
+    <para>You may use
+    <citerefentry><refentrytitle>timedatectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    to change the settings of this file from the command line during
+    runtime. Use
+    <citerefentry><refentrytitle>systemd-firstboot</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    to initialize the time zone on mounted (but not booted) system
+    images.</para>
+  </refsect1>
+
+  <refsect1>
+      <title>See Also</title>
+      <para>
+        <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+        <citerefentry project='man-pages'><refentrytitle>tzset</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>localtime</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>timedatectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd-timedated.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd-firstboot</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+      </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/logcontrol-example.c b/man/logcontrol-example.c
new file mode 100644
index 0000000..c199ec7
--- /dev/null
+++ b/man/logcontrol-example.c
@@ -0,0 +1,239 @@
+/* SPDX-License-Identifier: MIT-0 */
+
+/* Implements the LogControl1 interface as per specification:
+ * https://www.freedesktop.org/software/systemd/man/org.freedesktop.LogControl1.html
+ *
+ * Compile with 'cc logcontrol-example.c $(pkg-config --libs --cflags libsystemd)'
+ *
+ * To get and set properties via busctl:
+ *
+ * $ busctl --user get-property org.freedesktop.Example \
+ *                              /org/freedesktop/LogControl1 \
+ *                              org.freedesktop.LogControl1 \
+ *                              SyslogIdentifier
+ *   s "example"
+ * $ busctl --user get-property org.freedesktop.Example \
+ *                              /org/freedesktop/LogControl1 \
+ *                              org.freedesktop.LogControl1 \
+ *                              LogTarget
+ *   s "journal"
+ * $ busctl --user get-property org.freedesktop.Example \
+ *                              /org/freedesktop/LogControl1 \
+ *                              org.freedesktop.LogControl1 \
+ *                              LogLevel
+ *   s "info"
+ * $ busctl --user set-property org.freedesktop.Example \
+ *                              /org/freedesktop/LogControl1 \
+ *                              org.freedesktop.LogControl1 \
+ *                              LogLevel \
+ *                              "s" debug
+ * $ busctl --user get-property org.freedesktop.Example \
+ *                              /org/freedesktop/LogControl1 \
+ *                              org.freedesktop.LogControl1 \
+ *                              LogLevel
+ *   s "debug"
+ */
+
+#include <errno.h>
+#include <stdlib.h>
+#include <stdio.h>
+#include <syslog.h>
+#include <systemd/sd-bus.h>
+#include <systemd/sd-journal.h>
+
+#define _cleanup_(f) __attribute__((cleanup(f)))
+
+#define check(log_level, x) ({                  \
+  int _r = (x);                                 \
+  errno = _r < 0 ? -_r : 0;                     \
+  sd_journal_print((log_level), #x ": %m");     \
+  if (_r < 0)                                   \
+    return EXIT_FAILURE;                        \
+  })
+
+typedef enum LogTarget {
+  LOG_TARGET_JOURNAL,
+  LOG_TARGET_KMSG,
+  LOG_TARGET_SYSLOG,
+  LOG_TARGET_CONSOLE,
+  _LOG_TARGET_MAX,
+} LogTarget;
+
+static const char* const log_target_table[_LOG_TARGET_MAX] = {
+  [LOG_TARGET_JOURNAL] = "journal",
+  [LOG_TARGET_KMSG]    = "kmsg",
+  [LOG_TARGET_SYSLOG]  = "syslog",
+  [LOG_TARGET_CONSOLE] = "console",
+};
+
+static const char* const log_level_table[LOG_DEBUG + 1] = {
+  [LOG_EMERG]   = "emerg",
+  [LOG_ALERT]   = "alert",
+  [LOG_CRIT]    = "crit",
+  [LOG_ERR]     = "err",
+  [LOG_WARNING] = "warning",
+  [LOG_NOTICE]  = "notice",
+  [LOG_INFO]    = "info",
+  [LOG_DEBUG]   = "debug",
+};
+
+typedef struct object {
+  const char *syslog_identifier;
+  LogTarget log_target;
+  int log_level;
+} object;
+
+static int property_get(
+                sd_bus *bus,
+                const char *path,
+                const char *interface,
+                const char *property,
+                sd_bus_message *reply,
+                void *userdata,
+                sd_bus_error *error) {
+
+  object *o = userdata;
+
+  if (strcmp(property, "LogLevel") == 0)
+    return sd_bus_message_append(reply, "s", log_level_table[o->log_level]);
+
+  if (strcmp(property, "LogTarget") == 0)
+    return sd_bus_message_append(reply, "s", log_target_table[o->log_target]);
+
+  if (strcmp(property, "SyslogIdentifier") == 0)
+    return sd_bus_message_append(reply, "s", o->syslog_identifier);
+
+  return sd_bus_error_setf(error,
+                           SD_BUS_ERROR_UNKNOWN_PROPERTY,
+                           "Unknown property '%s'",
+                           property);
+}
+
+static int property_set(
+                sd_bus *bus,
+                const char *path,
+                const char *interface,
+                const char *property,
+                sd_bus_message *message,
+                void *userdata,
+                sd_bus_error *error) {
+
+  object *o = userdata;
+  const char *value;
+  int r;
+
+  r = sd_bus_message_read(message, "s", &value);
+  if (r < 0)
+    return r;
+
+  if (strcmp(property, "LogLevel") == 0) {
+    for (int i = 0; i < LOG_DEBUG + 1; i++)
+      if (strcmp(value, log_level_table[i]) == 0) {
+        o->log_level = i;
+        setlogmask(LOG_UPTO(i));
+        return 0;
+      }
+
+    return sd_bus_error_setf(error,
+                             SD_BUS_ERROR_INVALID_ARGS,
+                             "Invalid value for LogLevel: '%s'",
+                             value);
+  }
+
+  if (strcmp(property, "LogTarget") == 0) {
+    for (LogTarget i = 0; i < _LOG_TARGET_MAX; i++)
+      if (strcmp(value, log_target_table[i]) == 0) {
+        o->log_target = i;
+        return 0;
+      }
+
+    return sd_bus_error_setf(error,
+                             SD_BUS_ERROR_INVALID_ARGS,
+                             "Invalid value for LogTarget: '%s'",
+                             value);
+  }
+
+  return sd_bus_error_setf(error,
+                           SD_BUS_ERROR_UNKNOWN_PROPERTY,
+                           "Unknown property '%s'",
+                           property);
+}
+
+/* https://www.freedesktop.org/software/systemd/man/sd_bus_add_object.html
+ */
+static const sd_bus_vtable vtable[] = {
+  SD_BUS_VTABLE_START(0),
+  SD_BUS_WRITABLE_PROPERTY(
+    "LogLevel", "s",
+    property_get, property_set,
+    0,
+    0),
+  SD_BUS_WRITABLE_PROPERTY(
+    "LogTarget", "s",
+    property_get, property_set,
+    0,
+    0),
+  SD_BUS_PROPERTY(
+    "SyslogIdentifier", "s",
+    property_get,
+    0,
+    SD_BUS_VTABLE_PROPERTY_CONST),
+  SD_BUS_VTABLE_END
+};
+
+int main(int argc, char **argv) {
+  /* The bus should be relinquished before the program terminates. The cleanup
+   * attribute allows us to do it nicely and cleanly whenever we exit the
+   * block.
+   */
+  _cleanup_(sd_bus_flush_close_unrefp) sd_bus *bus = NULL;
+
+  object o = {
+    .log_level = LOG_INFO,
+    .log_target = LOG_TARGET_JOURNAL,
+    .syslog_identifier = "example",
+  };
+
+  /* https://man7.org/linux/man-pages/man3/setlogmask.3.html
+   * Programs using syslog() instead of sd_journal can use this API to cut logs
+   * emission at the source.
+   */
+  setlogmask(LOG_UPTO(o.log_level));
+
+  /* Acquire a connection to the bus, letting the library work out the details.
+   * https://www.freedesktop.org/software/systemd/man/sd_bus_default.html
+   */
+  check(o.log_level, sd_bus_default(&bus));
+
+  /* Publish an interface on the bus, specifying our well-known object access
+   * path and public interface name.
+   * https://www.freedesktop.org/software/systemd/man/sd_bus_add_object.html
+   * https://dbus.freedesktop.org/doc/dbus-tutorial.html
+   */
+  check(o.log_level, sd_bus_add_object_vtable(bus, NULL,
+                                              "/org/freedesktop/LogControl1",
+                                              "org.freedesktop.LogControl1",
+                                              vtable,
+                                              &o));
+
+  /* By default the service is assigned an ephemeral name. Also add a fixed
+   * one, so that clients know whom to call.
+   * https://www.freedesktop.org/software/systemd/man/sd_bus_request_name.html
+   */
+  check(o.log_level, sd_bus_request_name(bus, "org.freedesktop.Example", 0));
+
+  for (;;) {
+    /* https://www.freedesktop.org/software/systemd/man/sd_bus_wait.html
+     */
+    check(o.log_level, sd_bus_wait(bus, UINT64_MAX));
+    /* https://www.freedesktop.org/software/systemd/man/sd_bus_process.html
+     */
+    check(o.log_level, sd_bus_process(bus, NULL));
+  }
+
+  /* https://www.freedesktop.org/software/systemd/man/sd_bus_release_name.html
+   */
+  check(o.log_level, sd_bus_release_name(bus, "org.freedesktop.Example"));
+
+  return 0;
+}
diff --git a/man/loginctl.xml b/man/loginctl.xml
new file mode 100644
index 0000000..bf489a2
--- /dev/null
+++ b/man/loginctl.xml
@@ -0,0 +1,469 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="loginctl" conditional='ENABLE_LOGIND'
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>loginctl</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>loginctl</refentrytitle>
+    <manvolnum>1</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>loginctl</refname>
+    <refpurpose>Control the systemd login manager</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <cmdsynopsis>
+      <command>loginctl</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="req">COMMAND</arg>
+      <arg choice="opt" rep="repeat">NAME</arg>
+    </cmdsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>loginctl</command> may be used to introspect and
+    control the state of the
+    <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    login manager
+    <citerefentry><refentrytitle>systemd-logind.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Commands</title>
+
+    <para>The following commands are understood:</para>
+
+    <refsect2><title>Session Commands</title><variablelist>
+
+      <varlistentry>
+        <term><command>list-sessions</command></term>
+
+        <listitem><para>List current sessions.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>session-status</command> <optional><replaceable>ID</replaceable>…</optional></term>
+
+        <listitem><para>Show terse runtime status information about
+        one or more sessions, followed by the most recent log data
+        from the journal. Takes one or more session identifiers as
+        parameters. If no session identifiers are passed, the status of
+        the caller's session is shown. This function is intended to
+        generate human-readable output. If you are looking for
+        computer-parsable output, use <command>show-session</command>
+        instead.</para>
+
+        <xi:include href="version-info.xml" xpointer="v233"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>show-session</command> <optional><replaceable>ID</replaceable>…</optional></term>
+
+        <listitem><para>Show properties of one or more sessions or the manager itself. If no argument is
+        specified, properties of the manager will be shown. If a session ID is specified, properties of
+        the session are shown. Specially, if the given ID is <literal>self</literal>, the session to which
+        the <command>loginctl</command> process belongs is used. If <literal>auto</literal>, the current
+        session is used as with <literal>self</literal> if exists, and falls back to the current user's
+        graphical session. By default, empty properties are suppressed. Use <option>--all</option> to show
+        those too. To select specific properties to show, use <option>--property=</option>. This command
+        is intended to be used whenever computer-parsable output is required. Use <command>session-status</command>
+        if you are looking for formatted human-readable output.</para>
+
+        <xi:include href="version-info.xml" xpointer="v233"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>activate</command> <optional><replaceable>ID</replaceable></optional></term>
+
+        <listitem><para>Activate a session. This brings a session into
+        the foreground if another session is currently in the
+        foreground on the respective seat. Takes a session identifier
+        as argument. If no argument is specified, the session of the
+        caller is put into foreground.</para>
+
+        <xi:include href="version-info.xml" xpointer="v219"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>lock-session</command> <optional><replaceable>ID</replaceable>…</optional></term>
+        <term><command>unlock-session</command> <optional><replaceable>ID</replaceable>…</optional></term>
+
+        <listitem><para>Activates/deactivates the screen lock on one
+        or more sessions, if the session supports it. Takes one or
+        more session identifiers as arguments. If no argument is
+        specified, the session of the caller is locked/unlocked.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v233"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>lock-sessions</command></term>
+        <term><command>unlock-sessions</command></term>
+
+        <listitem><para>Activates/deactivates the screen lock on all
+        current sessions supporting it. </para>
+
+        <xi:include href="version-info.xml" xpointer="v188"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>terminate-session</command> <replaceable>ID</replaceable>…</term>
+
+        <listitem><para>Terminates a session. This kills all processes of the session and deallocates all
+        resources attached to the session. If the argument is specified as empty string the session invoking
+        the command is terminated.</para>
+
+        <xi:include href="version-info.xml" xpointer="v233"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>kill-session</command> <replaceable>ID</replaceable>…</term>
+
+        <listitem><para>Send a signal to one or more processes of the session. Use
+        <option>--kill-whom=</option> to select which process to kill. Use <option>--signal=</option> to
+        select the signal to send. If the argument is specified as empty string the signal is sent to the
+        session invoking the command.</para>
+
+        <xi:include href="version-info.xml" xpointer="v233"/></listitem>
+      </varlistentry>
+    </variablelist></refsect2>
+
+    <refsect2><title>User Commands</title><variablelist>
+      <varlistentry>
+        <term><command>list-users</command></term>
+
+        <listitem><para>List currently logged in users.
+        </para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>user-status</command> <optional><replaceable>USER</replaceable>…</optional></term>
+
+        <listitem><para>Show terse runtime status information about
+        one or more logged in users, followed by the most recent log
+        data from the journal. Takes one or more user names or numeric
+        user IDs as parameters. If no parameters are passed, the status
+        is shown for the user of the session of the caller. This
+        function is intended to generate human-readable output. If you
+        are looking for computer-parsable output, use
+        <command>show-user</command> instead.</para>
+
+        <xi:include href="version-info.xml" xpointer="v233"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>show-user</command> <optional><replaceable>USER</replaceable>…</optional></term>
+
+        <listitem><para>Show properties of one or more users or the
+        manager itself. If no argument is specified, properties of the
+        manager will be shown. If a user is specified, properties of
+        the user are shown. By default, empty properties are
+        suppressed. Use <option>--all</option> to show those too. To
+        select specific properties to show, use
+        <option>--property=</option>. This command is intended to be
+        used whenever computer-parsable output is required. Use
+        <command>user-status</command> if you are looking for
+        formatted human-readable output.</para>
+
+        <xi:include href="version-info.xml" xpointer="v233"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>enable-linger</command> <optional><replaceable>USER</replaceable>…</optional></term>
+        <term><command>disable-linger</command> <optional><replaceable>USER</replaceable>…</optional></term>
+
+        <listitem><para>Enable/disable user lingering for one or more
+        users. If enabled for a specific user, a user manager is
+        spawned for the user at boot and kept around after logouts.
+        This allows users who are not logged in to run long-running
+        services. Takes one or more user names or numeric UIDs as
+        argument. If no argument is specified, enables/disables
+        lingering for the user of the session of the caller.</para>
+
+        <para>See also <varname>KillUserProcesses=</varname> setting in
+        <citerefentry><refentrytitle>logind.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v233"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>terminate-user</command> <replaceable>USER</replaceable>…</term>
+
+        <listitem><para>Terminates all sessions of a user. This kills all processes of all sessions of the
+        user and deallocates all runtime resources attached to the user. If the argument is specified as
+        empty string the sessions of the user invoking the command are terminated.</para>
+
+        <xi:include href="version-info.xml" xpointer="v233"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>kill-user</command> <replaceable>USER</replaceable>…</term>
+
+        <listitem><para>Send a signal to all processes of a user. Use <option>--signal=</option> to select
+        the signal to send. If the argument is specified as empty string the signal is sent to the sessions
+        of the user invoking the command.</para>
+
+        <xi:include href="version-info.xml" xpointer="v233"/></listitem>
+      </varlistentry>
+    </variablelist></refsect2>
+
+    <refsect2><title>Seat Commands</title><variablelist>
+      <varlistentry>
+        <term><command>list-seats</command></term>
+
+        <listitem><para>List currently available seats on the local
+        system.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>seat-status</command> <optional><replaceable>NAME</replaceable>…</optional></term>
+
+        <listitem><para>Show terse runtime status information about
+        one or more seats. Takes one or more seat names as parameters.
+        If no seat names are passed the status of the caller's
+        session's seat is shown. This function is intended to generate
+        human-readable output. If you are looking for
+        computer-parsable output, use <command>show-seat</command>
+        instead.</para>
+
+        <xi:include href="version-info.xml" xpointer="v233"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>show-seat</command> <optional><replaceable>NAME</replaceable>…</optional></term>
+
+        <listitem><para>Show properties of one or more seats or the
+        manager itself. If no argument is specified, properties of the
+        manager will be shown. If a seat is specified, properties of
+        the seat are shown. By default, empty properties are
+        suppressed. Use <option>--all</option> to show those too. To
+        select specific properties to show, use
+        <option>--property=</option>. This command is intended to be
+        used whenever computer-parsable output is required. Use
+        <command>seat-status</command> if you are looking for
+        formatted human-readable output.</para>
+
+        <xi:include href="version-info.xml" xpointer="v233"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>attach</command> <replaceable>NAME</replaceable> <replaceable>DEVICE</replaceable>…</term>
+
+        <listitem><para>Persistently attach one or more devices to a
+        seat. The devices should be specified via device paths in the
+        <filename>/sys/</filename> file system. To create a new seat,
+        attach at least one graphics card to a previously unused seat
+        name. Seat names may consist only of a–z, A–Z, 0–9,
+        <literal>-</literal> and <literal>_</literal> and must be
+        prefixed with <literal>seat</literal>. To drop assignment of a
+        device to a specific seat, just reassign it to a different
+        seat, or use <command>flush-devices</command>.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v233"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>flush-devices</command></term>
+
+        <listitem><para>Removes all device assignments previously
+        created with <command>attach</command>. After this call, only
+        automatically generated seats will remain, and all seat
+        hardware is assigned to them.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>terminate-seat</command> <replaceable>NAME</replaceable>…</term>
+
+        <listitem><para>Terminates all sessions on a seat. This kills
+        all processes of all sessions on the seat and deallocates all
+        runtime resources attached to them.</para>
+
+        <xi:include href="version-info.xml" xpointer="v233"/></listitem>
+      </varlistentry>
+    </variablelist></refsect2>
+
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>The following options are understood:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><option>--no-ask-password</option></term>
+
+        <listitem><para>Do not query the user for authentication for
+        privileged operations.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-p</option></term>
+        <term><option>--property=</option></term>
+
+        <listitem><para>When showing session/user/seat properties,
+        limit display to certain properties as specified as argument.
+        If not specified, all set properties are shown. The argument
+        should be a property name, such as
+        <literal>Sessions</literal>. If specified more than once, all
+        properties with the specified names are
+        shown.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--value</option></term>
+
+        <listitem><para>When showing session/user/seat properties,
+        only print the value, and skip the property name and
+        <literal>=</literal>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v230"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-a</option></term>
+        <term><option>--all</option></term>
+
+        <listitem><para>When showing session/user/seat properties,
+        show all properties regardless of whether they are set or
+        not.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-l</option></term>
+        <term><option>--full</option></term>
+
+        <listitem><para>Do not ellipsize process tree entries.</para>
+
+        <xi:include href="version-info.xml" xpointer="v198"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--kill-whom=</option></term>
+
+        <listitem><para>When used with <command>kill-session</command>, choose which processes to kill.
+        Takes one of <literal>leader</literal> or <literal>all</literal>, to select whether to kill only
+        the leader process of the session or all processes of the session. If omitted, defaults to
+        <option>all</option>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-s</option></term>
+        <term><option>--signal=</option></term>
+
+        <listitem><para>When used with <command>kill-session</command> or <command>kill-user</command>,
+        choose which signal to send to selected processes. Must be one of the well known signal specifiers,
+        such as <constant>SIGTERM</constant>, <constant>SIGINT</constant> or <constant>SIGSTOP</constant>.
+        If omitted, defaults to <constant>SIGTERM</constant>.</para>
+
+        <para>The special value <literal>help</literal> will list the known values and the program will exit
+        immediately, and the special value <literal>list</literal> will list known values along with the
+        numerical signal numbers and the program will exit immediately.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-n</option></term>
+        <term><option>--lines=</option></term>
+
+        <listitem><para>When used with <command>user-status</command>
+        and <command>session-status</command>, controls the number of
+        journal lines to show, counting from the most recent ones.
+        Takes a positive integer argument. Defaults to 10.</para>
+
+        <xi:include href="version-info.xml" xpointer="v219"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-o</option></term>
+        <term><option>--output=</option></term>
+
+        <listitem><para>When used with <command>user-status</command>
+        and <command>session-status</command>, controls the formatting
+        of the journal entries that are shown. For the available
+        choices, see
+        <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
+        Defaults to <literal>short</literal>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v219"/></listitem>
+      </varlistentry>
+
+      <xi:include href="user-system-options.xml" xpointer="host" />
+      <xi:include href="user-system-options.xml" xpointer="machine" />
+
+      <xi:include href="standard-options.xml" xpointer="no-pager" />
+      <xi:include href="standard-options.xml" xpointer="no-legend" />
+      <xi:include href="standard-options.xml" xpointer="help" />
+      <xi:include href="standard-options.xml" xpointer="version" />
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Exit status</title>
+
+    <para>On success, 0 is returned, a non-zero failure code
+    otherwise.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Examples</title>
+
+    <example>
+      <title>Querying user status</title>
+
+      <programlisting>$ loginctl user-status
+fatima (1005)
+           Since: Sat 2016-04-09 14:23:31 EDT; 54min ago
+           State: active
+        Sessions: 5 *3
+            Unit: user-1005.slice
+                  ├─user@1005.service
+                    …
+                  ├─session-3.scope
+                    …
+                  └─session-5.scope
+                    ├─3473 login -- fatima
+                    └─3515 -zsh
+
+Apr 09 14:40:30 laptop login[2325]: pam_unix(login:session):
+                       session opened for user fatima by LOGIN(uid=0)
+Apr 09 14:40:30 laptop login[2325]: LOGIN ON tty3 BY fatima
+</programlisting>
+
+      <para>There are two sessions, 3 and 5. Session 3 is a graphical session,
+      marked with a star. The tree of processing including the two corresponding
+      scope units and the user manager unit are shown.</para>
+    </example>
+  </refsect1>
+
+  <xi:include href="common-variables.xml" />
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-logind.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>logind.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/logind.conf.xml b/man/logind.conf.xml
new file mode 100644
index 0000000..72f657c
--- /dev/null
+++ b/man/logind.conf.xml
@@ -0,0 +1,397 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [
+<!ENTITY % entities SYSTEM "custom-entities.ent" >
+%entities;
+]>
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="logind.conf" conditional='ENABLE_LOGIND'
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+  <refentryinfo>
+    <title>logind.conf</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>logind.conf</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>logind.conf</refname>
+    <refname>logind.conf.d</refname>
+    <refpurpose>Login manager configuration files</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>/etc/systemd/logind.conf</filename></para>
+    <para><filename>/etc/systemd/logind.conf.d/*.conf</filename></para>
+    <para><filename>/run/systemd/logind.conf.d/*.conf</filename></para>
+    <para><filename>/usr/lib/systemd/logind.conf.d/*.conf</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>These files configure various parameters of the systemd login manager,
+    <citerefentry><refentrytitle>systemd-logind.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>. See
+    <citerefentry><refentrytitle>systemd.syntax</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+    for a general description of the syntax.</para>
+  </refsect1>
+
+  <xi:include href="standard-conf.xml" xpointer="main-conf" />
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>All options are configured in the
+    [Login] section:</para>
+
+    <variablelist class='config-directives'>
+
+      <varlistentry>
+        <term><varname>NAutoVTs=</varname></term>
+
+        <listitem><para>Takes a positive integer. Configures how many
+        virtual terminals (VTs) to allocate by default that, when
+        switched to and are previously unused,
+        <literal>autovt</literal> services are automatically spawned
+        on. These services are instantiated from the template unit
+        <filename>autovt@.service</filename> for the respective VT TTY
+        name, for example, <filename>autovt@tty4.service</filename>.
+        By default, <filename>autovt@.service</filename> is linked to
+        <filename>getty@.service</filename>. In other words, login
+        prompts are started dynamically as the user switches to unused
+        virtual terminals. Hence, this parameter controls how many
+        login <literal>gettys</literal> are available on the VTs. If a
+        VT is already used by some other subsystem (for example, a
+        graphical login), this kind of activation will not be
+        attempted. Note that the VT configured in
+        <varname>ReserveVT=</varname> is always subject to this kind
+        of activation, even if it is not one of the VTs configured
+        with the <varname>NAutoVTs=</varname> directive. Defaults to
+        6. When set to 0, automatic spawning of
+        <literal>autovt</literal> services is
+        disabled.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ReserveVT=</varname></term>
+
+        <listitem><para>Takes a positive integer. Identifies one
+        virtual terminal that shall unconditionally be reserved for
+        <filename>autovt@.service</filename> activation (see above).
+        The VT selected with this option will be marked busy
+        unconditionally, so that no other subsystem will allocate it.
+        This functionality is useful to ensure that, regardless of how
+        many VTs are allocated by other subsystems, one login
+        <literal>getty</literal> is always available. Defaults to 6
+        (in other words, there will always be a
+        <literal>getty</literal> available on Alt-F6.). When set to 0,
+        VT reservation is disabled.</para>
+
+        <xi:include href="version-info.xml" xpointer="v190"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>KillUserProcesses=</varname></term>
+
+        <listitem><para>Takes a boolean argument. Configures whether the processes of a
+        user should be killed when the user logs out. If true, the scope unit
+        corresponding to the session and all processes inside that scope will be
+        terminated. If false, the scope is "abandoned", see
+        <citerefentry><refentrytitle>systemd.scope</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        and processes are not killed. Defaults to <literal>&KILL_USER_PROCESSES;</literal>,
+        but see the options <varname>KillOnlyUsers=</varname> and
+        <varname>KillExcludeUsers=</varname> below.</para>
+
+        <para>In addition to session processes, user process may run under the user
+        manager unit <filename>user@.service</filename>. Depending on the linger
+        settings, this may allow users to run processes independent of their login
+        sessions. See the description of <command>enable-linger</command> in
+        <citerefentry><refentrytitle>loginctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
+        </para>
+
+        <para>Note that setting <varname>KillUserProcesses=yes</varname>
+        will break tools like
+        <citerefentry project='die-net'><refentrytitle>screen</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+        and
+        <citerefentry project='die-net'><refentrytitle>tmux</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+        unless they are moved out of the session scope. See example in
+        <citerefentry><refentrytitle>systemd-run</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
+        </para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>KillOnlyUsers=</varname></term>
+        <term><varname>KillExcludeUsers=</varname></term>
+
+        <listitem><para>These settings take space-separated lists of usernames that override the
+        <varname>KillUserProcesses=</varname> setting. A user name may be added to
+        <varname>KillExcludeUsers=</varname> to exclude the processes in the session scopes of that user from
+        being killed even if <varname>KillUserProcesses=yes</varname> is set. If
+        <varname>KillExcludeUsers=</varname> is not set, the <literal>root</literal> user is excluded by
+        default. <varname>KillExcludeUsers=</varname> may be set to an empty value to override this
+        default. If a user is not excluded, <varname>KillOnlyUsers=</varname> is checked next. If this
+        setting is specified, only the processes in the session scopes of those users will be
+        killed. Otherwise, users are subject to the <varname>KillUserProcesses=yes</varname> setting.
+        </para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>IdleAction=</varname></term>
+
+        <listitem><para>Configures the action to take when the system
+        is idle. Takes one of
+        <literal>ignore</literal>,
+        <literal>poweroff</literal>,
+        <literal>reboot</literal>,
+        <literal>halt</literal>,
+        <literal>kexec</literal>,
+        <literal>suspend</literal>,
+        <literal>hibernate</literal>,
+        <literal>hybrid-sleep</literal>,
+        <literal>suspend-then-hibernate</literal>, and
+        <literal>lock</literal>.
+        Defaults to <literal>ignore</literal>.</para>
+
+        <para>Note that this requires that user sessions correctly
+        report the idle status to the system. The system will execute
+        the action after all sessions report that they are idle, no
+        idle inhibitor lock is active, and subsequently, the time
+        configured with <varname>IdleActionSec=</varname> (see below)
+        has expired.</para>
+
+        <xi:include href="version-info.xml" xpointer="v198"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>IdleActionSec=</varname></term>
+
+        <listitem><para>Configures the delay after which the action
+        configured in <varname>IdleAction=</varname> (see above) is
+        taken after the system is idle.</para>
+
+        <xi:include href="version-info.xml" xpointer="v198"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>InhibitDelayMaxSec=</varname></term>
+
+        <listitem><para>Specifies the maximum time a system shutdown
+        or sleep request is delayed due to an inhibitor lock of type
+        <literal>delay</literal> being active before the inhibitor is
+        ignored and the operation executes anyway. Defaults to
+        5.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>UserStopDelaySec=</varname></term>
+
+        <listitem><para>Specifies how long to keep the user record and per-user service
+        <filename>user@.service</filename> around for a user after they logged out fully. If set to zero, the per-user
+        service is terminated immediately when the last session of the user has ended. If this option is configured to
+        non-zero rapid logout/login cycles are sped up, as the user's service manager is not constantly restarted. If
+        set to <literal>infinity</literal> the per-user service for a user is never terminated again after first login,
+        and continues to run until system shutdown. Defaults to 10s.</para>
+
+        <xi:include href="version-info.xml" xpointer="v240"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>HandlePowerKey=</varname></term>
+        <term><varname>HandlePowerKeyLongPress=</varname></term>
+        <term><varname>HandleRebootKey=</varname></term>
+        <term><varname>HandleRebootKeyLongPress=</varname></term>
+        <term><varname>HandleSuspendKey=</varname></term>
+        <term><varname>HandleSuspendKeyLongPress=</varname></term>
+        <term><varname>HandleHibernateKey=</varname></term>
+        <term><varname>HandleHibernateKeyLongPress=</varname></term>
+        <term><varname>HandleLidSwitch=</varname></term>
+        <term><varname>HandleLidSwitchExternalPower=</varname></term>
+        <term><varname>HandleLidSwitchDocked=</varname></term>
+
+        <listitem><para>Controls how logind shall handle the system power, reboot and sleep keys and the lid
+        switch to trigger actions such as system power-off, reboot or suspend. Can be one of
+        <literal>ignore</literal>, <literal>poweroff</literal>, <literal>reboot</literal>,
+        <literal>halt</literal>, <literal>kexec</literal>, <literal>suspend</literal>,
+        <literal>hibernate</literal>, <literal>hybrid-sleep</literal>,
+        <literal>suspend-then-hibernate</literal>, <literal>lock</literal>, and
+        <literal>factory-reset</literal>.  If <literal>ignore</literal>, <command>systemd-logind</command>
+        will never handle these keys. If <literal>lock</literal>, all running sessions will be screen-locked;
+        otherwise, the specified action will be taken in the respective event. Only input devices with the
+        <literal>power-switch</literal> udev tag will be watched for key/lid switch
+        events.</para>
+
+        <para><varname>HandlePowerKey=</varname> defaults to <literal>poweroff</literal>,
+        <varname>HandleRebootKey=</varname> defaults to <literal>reboot</literal>,
+        <varname>HandleSuspendKey=</varname> defaults to <literal>suspend</literal>,
+        <varname>HandleHibernateKey=</varname> defaults to <literal>hibernate</literal>,
+        <varname>HandlePowerKeyLongPress=</varname> defaults to <literal>ignore</literal>,
+        <varname>HandleRebootKeyLongPress=</varname> defaults to <literal>poweroff</literal>,
+        <varname>HandleSuspendKeyLongPress=</varname> defaults to <literal>hibernate</literal>,
+        <varname>HandleHibernateKeyLongPress=</varname> defaults to <literal>ignore</literal>.
+        <varname>HandleLidSwitch=</varname> defaults to <literal>suspend</literal>.
+        <varname>HandleLidSwitchExternalPower=</varname> is completely ignored by default (for backwards
+        compatibility) — an explicit value must be set before it will be used to determine
+        behaviour. <varname>HandleLidSwitchDocked=</varname> defaults to <literal>ignore</literal>. If the
+        system is inserted in a docking station, or if more than one display is connected, the action
+        specified by <varname>HandleLidSwitchDocked=</varname> occurs; if the system is on external power the
+        action (if any) specified by <varname>HandleLidSwitchExternalPower=</varname> occurs; otherwise the
+        <varname>HandleLidSwitch=</varname> action occurs.</para>
+
+        <para>A different application may disable logind's handling of system power and
+        sleep keys and the lid switch by taking a low-level inhibitor lock
+        (<literal>handle-power-key</literal>, <literal>handle-suspend-key</literal>,
+        <literal>handle-hibernate-key</literal>, <literal>handle-lid-switch</literal>,
+        <literal>handle-reboot-key</literal>).
+        This is most commonly used by graphical desktop environments
+        to take over suspend and hibernation handling, and to use their own configuration
+        mechanisms. If a low-level inhibitor lock is taken, logind will not take any
+        action when that key or switch is triggered and the <varname>Handle*=</varname>
+        settings are irrelevant.</para>
+
+        <xi:include href="version-info.xml" xpointer="v184"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>PowerKeyIgnoreInhibited=</varname></term>
+        <term><varname>SuspendKeyIgnoreInhibited=</varname></term>
+        <term><varname>HibernateKeyIgnoreInhibited=</varname></term>
+        <term><varname>LidSwitchIgnoreInhibited=</varname></term>
+        <term><varname>RebootKeyIgnoreInhibited=</varname></term>
+
+        <listitem><para>Controls whether actions that <command>systemd-logind</command>
+        takes when the power, reboot and sleep keys and the lid switch are triggered are subject
+        to high-level inhibitor locks ("shutdown", "reboot", "sleep", "idle"). Low level inhibitor
+        locks (<literal>handle-power-key</literal>, <literal>handle-suspend-key</literal>,
+        <literal>handle-hibernate-key</literal>, <literal>handle-lid-switch</literal>,
+        <literal>handle-reboot-key</literal>),
+        are always honored, irrespective of this setting.</para>
+
+        <para>These settings take boolean arguments. If <literal>no</literal>, the
+        inhibitor locks taken by applications are respected. If <literal>yes</literal>,
+        "shutdown", "reboot" "sleep", and "idle" inhibitor locks are ignored.
+        <varname>PowerKeyIgnoreInhibited=</varname>,
+        <varname>SuspendKeyIgnoreInhibited=</varname>,
+        <varname>HibernateKeyIgnoreInhibited=</varname> and
+        <varname>RebootKeyIgnoreInhibited=</varname> default to <literal>no</literal>.
+        <varname>LidSwitchIgnoreInhibited=</varname> defaults to <literal>yes</literal>.
+        This means that when <command>systemd-logind</command> is handling events by
+        itself (no low level inhibitor locks are taken by another application), the lid
+        switch does not respect suspend blockers by default, but the power and sleep keys
+        do.</para>
+
+        <xi:include href="version-info.xml" xpointer="v190"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>HoldoffTimeoutSec=</varname></term>
+
+        <listitem><para>Specifies a period of time after system startup or
+        system resume in which systemd will hold off on reacting to
+        lid events. This is required for the system to properly
+        detect any hotplugged devices so systemd can ignore lid events
+        if external monitors, or docks, are connected. If set to 0,
+        systemd will always react immediately, possibly before the
+        kernel fully probed all hotplugged devices. This is safe, as
+        long as you do not care for systemd to account for devices
+        that have been plugged or unplugged while the system was off.
+        Defaults to 30s.</para>
+
+        <xi:include href="version-info.xml" xpointer="v220"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RuntimeDirectorySize=</varname></term>
+
+        <listitem><para>Sets the size limit on the
+        <varname>$XDG_RUNTIME_DIR</varname> runtime directory for each
+        user who logs in. Takes a size in bytes, optionally suffixed
+        with the usual K, G, M, and T suffixes, to the base 1024
+        (IEC). Alternatively, a numerical percentage suffixed by
+        <literal>%</literal> may be specified, which sets the size
+        limit relative to the amount of physical RAM. Defaults to 10%.
+        Note that this size is a safety limit only. As each runtime
+        directory is a tmpfs file system, it will only consume as much
+        memory as is needed.</para>
+
+        <xi:include href="version-info.xml" xpointer="v211"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RuntimeDirectoryInodesMax=</varname></term>
+
+        <listitem><para>Sets the limit on number of inodes for the
+        <varname>$XDG_RUNTIME_DIR</varname> runtime directory for each
+        user who logs in. Takes a number, optionally suffixed with the
+        usual K, G, M, and T suffixes, to the base 1024 (IEC).
+        Defaults to <varname>RuntimeDirectorySize=</varname> divided
+        by 4096. Note that this size is a safety limit only.
+        As each runtime directory is a tmpfs file system, it will
+        only consume as much memory as is needed.</para>
+
+        <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>InhibitorsMax=</varname></term>
+
+        <listitem><para>Controls the maximum number of concurrent inhibitors to permit. Defaults to 8192
+        (8K).</para>
+
+        <xi:include href="version-info.xml" xpointer="v230"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SessionsMax=</varname></term>
+
+        <listitem><para>Controls the maximum number of concurrent user sessions to manage. Defaults to 8192
+        (8K). Depending on how the <filename>pam_systemd.so</filename> module is included in the PAM stack
+        configuration, further login sessions will either be refused, or permitted but not tracked by
+        <filename>systemd-logind</filename>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v230"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RemoveIPC=</varname></term>
+
+        <listitem><para>Controls whether System V and POSIX IPC objects belonging to the user shall be removed when the
+        user fully logs out. Takes a boolean argument. If enabled, the user may not consume IPC resources after the
+        last of the user's sessions terminated. This covers System V semaphores, shared memory and message queues, as
+        well as POSIX shared memory and message queues. Note that IPC objects of the root user and other system users
+        are excluded from the effect of this setting. Defaults to <literal>yes</literal>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v212"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>StopIdleSessionSec=</varname></term>
+
+        <listitem><para>Specifies a timeout in seconds, or a time span value after which
+        <filename>systemd-logind</filename> checks the idle state of all sessions. Every session that is idle for
+        longer then the timeout will be stopped. Defaults to <literal>infinity</literal>
+        (<filename>systemd-logind</filename> is not checking the idle state of sessions). For details about the syntax
+        of time spans, see
+        <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+      <title>See Also</title>
+      <para>
+        <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd-logind.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>loginctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+      </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/machine-id.xml b/man/machine-id.xml
new file mode 100644
index 0000000..e57a7c1
--- /dev/null
+++ b/man/machine-id.xml
@@ -0,0 +1,204 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="machine-id">
+  <refentryinfo>
+    <title>machine-id</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>machine-id</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>machine-id</refname>
+    <refpurpose>Local machine ID configuration file</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>/etc/machine-id</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>The <filename>/etc/machine-id</filename> file contains the unique machine ID of
+    the local system that is set during installation or boot. The machine ID is a single
+    newline-terminated, hexadecimal, 32-character, lowercase ID. When decoded from
+    hexadecimal, this corresponds to a 16-byte/128-bit value. This ID may not be all
+    zeros.</para>
+
+    <para>The machine ID is usually generated from a random source during system
+    installation or first boot and stays constant for all subsequent boots. Optionally,
+    for stateless systems, it is generated during runtime during early boot if necessary.
+    </para>
+
+    <para>The machine ID may be set, for example when network booting, with the
+    <varname>systemd.machine_id=</varname> kernel command line parameter or by passing the
+    option <option>--machine-id=</option> to systemd. An ID specified in this manner
+    has higher priority and will be used instead of the ID stored in
+    <filename>/etc/machine-id</filename>.</para>
+
+    <para>The machine ID does not change based on local or network configuration or when
+    hardware is replaced. Due to this and its greater length, it is a more useful
+    replacement for the
+    <citerefentry project='man-pages'><refentrytitle>gethostid</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    call that POSIX specifies.</para>
+
+    <para>This machine ID adheres to the same format and logic as the
+    D-Bus machine ID.</para>
+
+    <para>This ID uniquely identifies the host. It should be considered "confidential", and must not be exposed in
+    untrusted environments, in particular on the network. If a stable unique identifier that is tied to the machine is
+    needed for some application, the machine ID or any part of it must not be used directly. Instead the machine ID
+    should be hashed with a cryptographic, keyed hash function, using a fixed, application-specific key. That way the
+    ID will be properly unique, and derived in a constant way from the machine ID but there will be no way to retrieve
+    the original machine ID from the application-specific one. The
+    <citerefentry><refentrytitle>sd_id128_get_machine_app_specific</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    API provides an implementation of such an algorithm.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Initialization</title>
+
+    <para>Each machine should have a non-empty ID in normal operation. The ID of each
+    machine should be unique. To achieve those objectives,
+    <filename>/etc/machine-id</filename> can be initialized in a few different ways.
+    </para>
+
+    <para>For normal operating system installations, where a custom image is created for a
+    specific machine, <filename>/etc/machine-id</filename> should be populated during
+    installation.</para>
+
+    <para>
+    <citerefentry><refentrytitle>systemd-machine-id-setup</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    may be used by installer tools to initialize the machine ID at install time, but
+    <filename>/etc/machine-id</filename> may also be written using any other means.
+    </para>
+
+    <para>For operating system images which are created once and used on multiple machines, for example for
+    containers or in the cloud, <filename>/etc/machine-id</filename> should be either missing or an empty
+    file in the generic file system image (the difference between the two options is described under "First
+    Boot Semantics" below). An ID will be generated during boot and saved to this file if possible. Having an
+    empty file in place is useful because it allows a temporary file to be bind-mounted over the real file,
+    in case the image is used read-only. Also see <ulink url="https://systemd.io/BUILDING_IMAGES">Safely
+    Building Images</ulink>.</para>
+
+    <para><citerefentry><refentrytitle>systemd-firstboot</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    may be used to initialize <filename>/etc/machine-id</filename> on mounted (but not
+    booted) system images.</para>
+
+    <para>When a machine is booted with
+    <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    the ID of the machine will be established. If <varname>systemd.machine_id=</varname>
+    or <option>--machine-id=</option> options (see first section) are specified, this
+    value will be used. Otherwise, the value in <filename>/etc/machine-id</filename> will
+    be used. If this file is empty or missing, <filename>systemd</filename> will attempt
+    to use the D-Bus machine ID from <filename>/var/lib/dbus/machine-id</filename>, the
+    value of the kernel command line option <varname>container_uuid</varname>, the KVM DMI
+    <filename>product_uuid</filename> or the devicetree <filename>vm,uuid</filename>
+    (on KVM systems), the Xen hypervisor <filename>uuid</filename>, and finally a randomly
+    generated UUID.</para>
+
+    <para>After the machine ID is established,
+    <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    will attempt to save it to <filename>/etc/machine-id</filename>. If this fails, it
+    will attempt to bind-mount a temporary file over <filename>/etc/machine-id</filename>.
+    It is an error if the file system is read-only and does not contain a (possibly empty)
+    <filename>/etc/machine-id</filename> file.</para>
+
+    <para><citerefentry><refentrytitle>systemd-machine-id-commit.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    will attempt to write the machine ID to the file system if
+    <filename>/etc/machine-id</filename> or <filename>/etc/</filename> are read-only during
+    early boot but become writable later on.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>First Boot Semantics</title>
+
+    <para><filename>/etc/machine-id</filename> is used to decide whether a boot is the first one. The rules
+    are as follows:</para>
+
+    <orderedlist>
+      <listitem><para>The kernel command argument <varname>systemd.condition-first-boot=</varname> may be
+      used to override the autodetection logic, see
+      <citerefentry><refentrytitle>kernel-command-line</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
+      </para></listitem>
+
+      <listitem><para>Otherwise, if <filename>/etc/machine-id</filename> does not exist, this is a first
+      boot. During early boot, <command>systemd</command> will write <literal>uninitialized\n</literal> to
+      this file and overmount a temporary file which contains the actual machine ID. Later (after
+      <filename>first-boot-complete.target</filename> has been reached), the real machine ID will be written
+      to disk.</para></listitem>
+
+      <listitem><para>If <filename>/etc/machine-id</filename> contains the string <literal>uninitialized</literal>,
+      a boot is also considered the first boot. The same mechanism as above applies.</para></listitem>
+
+      <listitem><para>If <filename>/etc/machine-id</filename> exists and is empty, a boot is
+      <emphasis>not</emphasis> considered the first boot. <command>systemd</command> will still bind-mount a file
+      containing the actual machine-id over it and later try to commit it to disk (if <filename>/etc/</filename> is
+      writable).</para></listitem>
+
+      <listitem><para>If <filename>/etc/machine-id</filename> already contains a valid machine-id, this is
+      not a first boot.</para></listitem>
+    </orderedlist>
+
+    <para>If according to the above rules a first boot is detected, units with
+    <varname>ConditionFirstBoot=yes</varname> will be run and <command>systemd</command> will perform
+    additional initialization steps, in particular presetting units.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Relation to OSF UUIDs</title>
+
+    <para>Note that the machine ID historically is not an OSF UUID as defined by <ulink
+    url="https://tools.ietf.org/html/rfc4122">RFC 4122</ulink>, nor a Microsoft GUID; however, starting with
+    systemd v30, newly generated machine IDs do qualify as Variant 1 Version 4 UUIDs, as per RFC 4122.</para>
+
+    <para>In order to maintain compatibility with existing installations, an application requiring a strictly
+    RFC 4122 compliant UUID should decode the machine ID, and then (non-reversibly) apply the following
+    operations to turn it into a valid RFC 4122 Variant 1 Version 4 UUID. With <literal>id</literal> being an
+    unsigned character array:</para>
+
+    <programlisting>/* Set UUID version to 4 --- truly random generation */
+id[6] = (id[6] &amp; 0x0F) | 0x40;
+/* Set the UUID variant to DCE */
+id[8] = (id[8] &amp; 0x3F) | 0x80;</programlisting>
+
+    <para>(This code is inspired by
+    <literal>generate_random_uuid()</literal> of
+    <filename>drivers/char/random.c</filename> from the Linux kernel
+    sources.)</para>
+
+  </refsect1>
+
+  <refsect1>
+    <title>History</title>
+
+    <para>The simple configuration file format of
+    <filename>/etc/machine-id</filename> originates in the
+    <filename>/var/lib/dbus/machine-id</filename> file introduced by
+    D-Bus. In fact, this latter file might be a symlink to
+    <filename>/etc/machine-id</filename>.</para>
+  </refsect1>
+
+  <refsect1>
+      <title>See Also</title>
+      <para>
+        <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd-machine-id-setup</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+        <citerefentry project='man-pages'><refentrytitle>gethostid</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>hostname</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>machine-info</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>os-release</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>sd-id128</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>sd_id128_get_machine</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd-firstboot</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+      </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/machine-info.xml b/man/machine-info.xml
new file mode 100644
index 0000000..1b26531
--- /dev/null
+++ b/man/machine-info.xml
@@ -0,0 +1,181 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="machine-info" xmlns:xi="http://www.w3.org/2001/XInclude">
+  <refentryinfo>
+    <title>machine-info</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>machine-info</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>machine-info</refname>
+    <refpurpose>Local machine information file</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>/etc/machine-info</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>The <filename>/etc/machine-info</filename> file contains
+    machine metadata.</para>
+
+    <para>The format of <filename>machine-info</filename> is a newline-separated list of environment-like
+    shell-compatible variable assignments, ignoring comments and empty lines. It is possible to source the
+    configuration from shell scripts, however, beyond mere variable assignments no shell features are
+    supported, allowing applications to read the file without implementing a shell compatible execution
+    engine. See
+    <citerefentry><refentrytitle>os-release</refentrytitle><manvolnum>5</manvolnum></citerefentry> for a
+    detailed description of the format.</para>
+
+    <para><filename>/etc/machine-info</filename> contains metadata about the machine that is set by the user
+    or administrator. The settings configured here have the highest precedence. When not set, appropriate
+    values may be determined automatically, based on the information about the hardware or other
+    configuration files. It is thus completely fine for this file to not be present.</para>
+
+    <para>You may use
+    <citerefentry><refentrytitle>hostnamectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    to change the settings of this file from the command line.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>The following machine metadata parameters may be set using
+    <filename>/etc/machine-info</filename>:</para>
+
+    <variablelist class='environment-variables'>
+
+      <varlistentry>
+        <term><varname>PRETTY_HOSTNAME=</varname></term>
+
+        <listitem><para>A pretty human-readable UTF-8 machine
+        identifier string. This should contain a name like
+        <literal>Lennart's Laptop</literal> which is useful to present
+        to the user and does not suffer by the syntax limitations of
+        internet domain names. If possible, the internet hostname as
+        configured in <filename>/etc/hostname</filename> should be
+        kept similar to this one. Example: if this value is
+        <literal>Lennart's Computer</literal> an Internet hostname of
+        <literal>lennarts-computer</literal> might be a good choice.
+        If this parameter is not set, an application should fall back
+        to the Internet hostname for presentation
+        purposes.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ICON_NAME=</varname></term>
+
+        <listitem><para>An icon identifying this machine according to
+        the <ulink
+        url="https://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html">XDG
+        Icon Naming Specification</ulink>. If this parameter is not
+        set, an application should fall back to
+        <literal>computer</literal> or a similar icon
+        name.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>CHASSIS=</varname></term>
+
+        <listitem><para>The chassis type. Currently, the following
+        chassis types are defined:
+        <literal>desktop</literal>,
+        <literal>laptop</literal>,
+        <literal>convertible</literal>,
+        <literal>server</literal>,
+        <literal>tablet</literal>,
+        <literal>handset</literal>,
+        <literal>watch</literal>, and
+        <literal>embedded</literal>,
+        as well as the special chassis types
+        <literal>vm</literal> and
+        <literal>container</literal> for
+        virtualized systems that lack an immediate physical chassis.</para>
+
+        <para>Note that most systems allow detection of the chassis type automatically (based on firmware
+        information or suchlike). This setting should only be used to override a misdetection or to manually
+        configure the chassis type where automatic detection is not available.</para>
+
+        <xi:include href="version-info.xml" xpointer="v197"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>DEPLOYMENT=</varname></term>
+
+        <listitem><para>Describes the system deployment environment.
+        One of the following is suggested:
+        <literal>development</literal>,
+        <literal>integration</literal>,
+        <literal>staging</literal>,
+        <literal>production</literal>.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v216"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>LOCATION=</varname></term>
+
+        <listitem><para>Describes the system location if applicable
+        and known. Takes a human-friendly, free-form string. This may
+        be as generic as <literal>Berlin, Germany</literal> or as
+        specific as <literal>Left Rack, 2nd Shelf</literal>.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v216"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>HARDWARE_VENDOR=</varname></term>
+
+        <listitem><para>Specifies the hardware vendor. If unspecified, the hardware vendor set in DMI or
+        <citerefentry><refentrytitle>hwdb</refentrytitle><manvolnum>7</manvolnum></citerefentry> will be
+        used.</para>
+
+        <xi:include href="version-info.xml" xpointer="v251"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>HARDWARE_MODEL=</varname></term>
+
+        <listitem><para>Specifies the hardware model. If unspecified, the hardware model set in DMI or
+        <citerefentry><refentrytitle>hwdb</refentrytitle><manvolnum>7</manvolnum></citerefentry> will be
+        used.</para>
+
+        <xi:include href="version-info.xml" xpointer="v251"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Example</title>
+
+    <programlisting>PRETTY_HOSTNAME="Lennart's Tablet"
+ICON_NAME=computer-tablet
+CHASSIS=tablet
+DEPLOYMENT=production</programlisting>
+  </refsect1>
+
+  <refsect1>
+      <title>See Also</title>
+      <para>
+        <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>os-release</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>hostname</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>hostnamectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd-hostnamed.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+      </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/machinectl.xml b/man/machinectl.xml
new file mode 100644
index 0000000..1afd431
--- /dev/null
+++ b/man/machinectl.xml
@@ -0,0 +1,1126 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [
+<!ENTITY % entities SYSTEM "custom-entities.ent" >
+%entities;
+]>
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="machinectl" conditional='ENABLE_MACHINED'
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>machinectl</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>machinectl</refentrytitle>
+    <manvolnum>1</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>machinectl</refname>
+    <refpurpose>Control the systemd machine manager</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <cmdsynopsis>
+      <command>machinectl</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="req">COMMAND</arg>
+      <arg choice="opt" rep="repeat">NAME</arg>
+    </cmdsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>machinectl</command> may be used to introspect and
+    control the state of the
+    <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    virtual machine and container registration manager
+    <citerefentry><refentrytitle>systemd-machined.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
+
+    <para><command>machinectl</command> may be used to execute
+    operations on machines and images. Machines in this sense are
+    considered running instances of:</para>
+
+    <itemizedlist>
+      <listitem><para>Virtual Machines (VMs) that virtualize hardware
+      to run full operating system (OS) instances (including their kernels)
+      in a virtualized environment on top of the host OS.</para></listitem>
+
+      <listitem><para>Containers that share the hardware and
+      OS kernel with the host OS, in order to run
+      OS userspace instances on top the host OS.</para></listitem>
+
+      <listitem><para>The host system itself.</para></listitem>
+    </itemizedlist>
+
+    <para>Machines are identified by names that follow the same rules
+    as UNIX and DNS hostnames. For details, see below.</para>
+
+    <para>Machines are instantiated from disk or file system images that
+    frequently — but not necessarily — carry the same name as machines running
+    from them. Images in this sense may be:</para>
+
+    <itemizedlist>
+      <listitem><para>Directory trees containing an OS, including the
+      top-level directories <filename>/usr/</filename>,
+      <filename>/etc/</filename>, and so on.</para></listitem>
+
+      <listitem><para>btrfs subvolumes containing OS trees, similar to regular directory trees.</para></listitem>
+
+      <listitem><para>Binary "raw" disk image files containing MBR or GPT partition tables and Linux file
+      systems.</para></listitem>
+
+      <listitem><para>Similarly, block devices containing MBR or GPT partition tables and file systems.</para></listitem>
+
+      <listitem><para>The file system tree of the host OS itself.</para></listitem>
+    </itemizedlist>
+
+  </refsect1>
+
+  <refsect1>
+    <title>Commands</title>
+
+    <para>The following commands are understood:</para>
+
+    <refsect2><title>Machine Commands</title><variablelist>
+
+      <varlistentry>
+        <term><command>list</command></term>
+
+        <listitem><para>List currently running (online) virtual
+        machines and containers. To enumerate machine images that can
+        be started, use <command>list-images</command> (see
+        below). Note that this command hides the special
+        <literal>.host</literal> machine by default. Use the
+        <option>--all</option> switch to show it.</para>
+
+        <xi:include href="version-info.xml" xpointer="v206"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>status</command> <replaceable>NAME</replaceable>…</term>
+
+        <listitem><para>Show runtime status information about
+        one or more virtual machines and containers, followed by the
+        most recent log data from the journal. This function is
+        intended to generate human-readable output. If you are looking
+        for computer-parsable output, use <command>show</command>
+        instead. Note that the log data shown is reported by the
+        virtual machine or container manager, and frequently contains
+        console output of the machine, but not necessarily journal
+        contents of the machine itself.</para>
+
+        <xi:include href="version-info.xml" xpointer="v206"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>show</command> [<replaceable>NAME</replaceable>…]</term>
+
+        <listitem><para>Show properties of one or more registered virtual machines or containers or the manager
+        itself. If no argument is specified, properties of the manager will be shown. If a NAME is specified,
+        properties of this virtual machine or container are shown. By default, empty properties are suppressed. Use
+        <option>--all</option> to show those too.  To select specific properties to show, use
+        <option>--property=</option>. This command is intended to be used whenever computer-parsable output is
+        required, and does not print the control group tree or journal entries. Use <command>status</command> if you
+        are looking for formatted human-readable output.</para>
+
+        <xi:include href="version-info.xml" xpointer="v206"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>start</command> <replaceable>NAME</replaceable>…</term>
+
+        <listitem><para>Start a container as a system service, using
+        <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
+        This starts <filename>systemd-nspawn@.service</filename>,
+        instantiated for the specified machine name, similar to the
+        effect of <command>systemctl start</command> on the service
+        name. <command>systemd-nspawn</command> looks for a container
+        image by the specified name in
+        <filename>/var/lib/machines/</filename> (and other search
+        paths, see below) and runs it. Use
+        <command>list-images</command> (see below) for listing
+        available container images to start.</para>
+
+        <para>Note that
+        <citerefentry><refentrytitle>systemd-machined.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        also interfaces with a variety of other container and VM
+        managers, <command>systemd-nspawn</command> is just one
+        implementation of it. Most of the commands available in
+        <command>machinectl</command> may be used on containers or VMs
+        controlled by other managers, not just
+        <command>systemd-nspawn</command>. Starting VMs and container
+        images on those managers requires manager-specific
+        tools.</para>
+
+        <para>To interactively start a container on the command line
+        with full access to the container's console, please invoke
+        <command>systemd-nspawn</command> directly. To stop a running
+        container use <command>machinectl poweroff</command>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v219"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>login</command> [<replaceable>NAME</replaceable>]</term>
+
+        <listitem><para>Open an interactive terminal login session in
+        a container or on the local host. If an argument is supplied,
+        it refers to the container machine to connect to. If none is
+        specified, or the container name is specified as the empty
+        string, or the special machine name <literal>.host</literal>
+        (see below) is specified, the connection is made to the local
+        host instead. This will create a TTY connection to a specific
+        container or the local host and asks for the execution of a
+        getty on it. Note that this is only supported for containers
+        running
+        <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+        as init system.</para>
+
+        <para>This command will open a full login prompt on the
+        container or the local host, which then asks for username and
+        password. Use <command>shell</command> (see below) or
+        <citerefentry><refentrytitle>systemd-run</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+        with the <option>--machine=</option> switch to directly invoke
+        a single command, either interactively or in the
+        background.</para>
+
+        <xi:include href="version-info.xml" xpointer="v209"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>shell</command> [[<replaceable>NAME</replaceable>@]<replaceable>NAME</replaceable> [<replaceable>PATH</replaceable> [<replaceable>ARGUMENTS</replaceable>…]]] </term>
+
+        <listitem><para>Open an interactive shell session in a
+        container or on the local host. The first argument refers to
+        the container machine to connect to. If none is specified, or
+        the machine name is specified as the empty string, or the
+        special machine name <literal>.host</literal> (see below) is
+        specified, the connection is made to the local host
+        instead. This works similarly to <command>login</command>, but
+        immediately invokes a user process. This command runs the
+        specified executable with the specified arguments, or the
+        default shell for the user if none is specified, or
+        <filename>/bin/sh</filename> if no default shell is found. By default,
+        <option>--uid=</option>, or by prefixing the machine name with
+        a username and an <literal>@</literal> character, a different
+        user may be selected. Use <option>--setenv=</option> to set
+        environment variables for the executed process.</para>
+
+        <para>Note that <command>machinectl shell</command> does not propagate the exit code/status of the invoked
+        shell process. Use <command>systemd-run</command> instead if that information is required (see below).</para>
+
+        <para>Using the <command>shell</command> command without arguments (thus invoking the executed shell
+        or command on the local host), is in many ways similar to a <citerefentry
+        project='die-net'><refentrytitle>su</refentrytitle><manvolnum>1</manvolnum></citerefentry> session,
+        but, unlike <command>su</command>, completely isolates the new session from the originating session,
+        so that it shares no process or session properties and is in a clean well-defined state. It will be
+        tracked in a new utmp, login, audit, security, and keyring sessions, and will not inherit any
+        environment variables or resource limits, among other properties.</para>
+
+        <para>Note that
+        <citerefentry><refentrytitle>systemd-run</refentrytitle><manvolnum>1</manvolnum></citerefentry> with
+        its <option>--machine=</option> switch may be used in place of the <command>machinectl
+        shell</command> command, and allows non-interactive operation, more detailed and low-level
+        configuration of the invoked unit, as well as access to runtime and exit code/status information of
+        the invoked shell process. In particular, use <command>systemd-run</command>'s
+        <option>--wait</option> switch to propagate exit status information of the invoked process. Use
+        <command>systemd-run</command>'s <option>--pty</option> switch to acquire an interactive shell,
+        similarly to <command>machinectl shell</command>. In general, <command>systemd-run</command> is
+        preferable for scripting purposes. However, note that <command>systemd-run</command> might require
+        higher privileges than <command>machinectl shell</command>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v225"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>enable</command> <replaceable>NAME</replaceable>…</term>
+        <term><command>disable</command> <replaceable>NAME</replaceable>…</term>
+
+        <listitem><para>Enable or disable a container as a system service to start at system boot, using
+        <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
+        This enables or disables <filename>systemd-nspawn@.service</filename>, instantiated for the specified
+        machine name, similarly to the effect of <command>systemctl enable</command> or <command>systemctl
+        disable</command> on the service name.</para>
+
+        <para>This command implicitly reloads the system manager configuration after completing the operation.
+        Note that this command does not implicitly start or power off the containers that are being operated on.
+        If this is desired, combine the command with the <option>--now</option> switch.</para>
+
+        <xi:include href="version-info.xml" xpointer="v219"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>poweroff</command> <replaceable>NAME</replaceable>…</term>
+
+        <listitem><para>Power off one or more containers. This will
+        trigger a reboot by sending SIGRTMIN+4 to the container's init
+        process, which causes systemd-compatible init systems to shut
+        down cleanly. Use <command>stop</command> as alias for <command>poweroff</command>.
+        This operation does not work on containers that do not run a
+        <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>-compatible
+        init system, such as sysvinit. Use
+        <command>terminate</command> (see below) to immediately
+        terminate a container or VM, without cleanly shutting it
+        down.</para>
+
+        <xi:include href="version-info.xml" xpointer="v212"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>reboot</command> <replaceable>NAME</replaceable>…</term>
+
+        <listitem><para>Reboot one or more containers. This will
+        trigger a reboot by sending SIGINT to the container's init
+        process, which is roughly equivalent to pressing Ctrl+Alt+Del
+        on a non-containerized system, and is compatible with
+        containers running any system manager.</para>
+
+        <xi:include href="version-info.xml" xpointer="v209"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>terminate</command> <replaceable>NAME</replaceable>…</term>
+
+        <listitem><para>Immediately terminates a virtual machine or
+        container, without cleanly shutting it down. This kills all
+        processes of the virtual machine or container and deallocates
+        all resources attached to that instance. Use
+        <command>poweroff</command> to issue a clean shutdown
+        request.</para>
+
+        <xi:include href="version-info.xml" xpointer="v206"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>kill</command> <replaceable>NAME</replaceable>…</term>
+
+        <listitem><para>Send a signal to one or more processes of the
+        virtual machine or container. This means processes as seen by
+        the host, not the processes inside the virtual machine or
+        container. Use <option>--kill-whom=</option> to select which
+        process to kill. Use <option>--signal=</option> to select the
+        signal to send.</para>
+
+        <xi:include href="version-info.xml" xpointer="v206"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>bind</command> <replaceable>NAME</replaceable> <replaceable>PATH</replaceable> [<replaceable>PATH</replaceable>]</term>
+
+        <listitem><para>Bind mounts a file or directory from the host into the specified container. The first path
+        argument is the source file or directory on the host, the second path argument is the destination file or
+        directory in the container. When the latter is omitted, the destination path in the container is the same as
+        the source path on the host. When combined with the <option>--read-only</option> switch, a ready-only bind
+        mount is created. When combined with the <option>--mkdir</option> switch, the destination path is first created
+        before the mount is applied. Note that this option is currently only supported for
+        <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry> containers,
+        and only if user namespacing (<option>--private-users</option>) is not used. This command supports bind
+        mounting directories, regular files, device nodes, <constant>AF_UNIX</constant> socket nodes, as well as
+        FIFOs.</para>
+
+        <xi:include href="version-info.xml" xpointer="v219"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>copy-to</command> <replaceable>NAME</replaceable> <replaceable>PATH</replaceable> [<replaceable>PATH</replaceable>] <option>--force</option></term>
+
+        <listitem><para>Copies files or directories from the host
+        system into a running container. Takes a container name,
+        followed by the source path on the host and the destination
+        path in the container. If the destination path is omitted, the
+        same as the source path is used.</para>
+
+        <para>If host and container share the same user and group namespace, file ownership by numeric user ID and
+        group ID is preserved for the copy, otherwise all files and directories in the copy will be owned by the root
+        user and group (UID/GID 0).</para>
+
+        <xi:include href="version-info.xml" xpointer="v219"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>copy-from</command> <replaceable>NAME</replaceable> <replaceable>PATH</replaceable> [<replaceable>PATH</replaceable>] <option>--force</option></term>
+
+        <listitem><para>Copies files or directories from a container
+        into the host system. Takes a container name, followed by the
+        source path in the container and the destination path on the host.
+        If the destination path is omitted, the same as the source path
+        is used.</para>
+
+        <para>If host and container share the same user and group namespace, file ownership by numeric user ID and
+        group ID is preserved for the copy, otherwise all files and directories in the copy will be owned by the root
+        user and group (UID/GID 0).</para>
+
+        <xi:include href="version-info.xml" xpointer="v219"/></listitem>
+      </varlistentry>
+    </variablelist></refsect2>
+
+    <refsect2><title>Image Commands</title><variablelist>
+
+      <varlistentry>
+        <term><command>list-images</command></term>
+
+        <listitem><para>Show a list of locally installed container and
+        VM images. This enumerates all raw disk images and container
+        directories and subvolumes in
+        <filename>/var/lib/machines/</filename> (and other search
+        paths, see below). Use <command>start</command> (see above) to
+        run a container off one of the listed images. Note that, by
+        default, containers whose name begins with a dot
+        (<literal>.</literal>) are not shown. To show these too,
+        specify <option>--all</option>. Note that a special image
+        <literal>.host</literal> always implicitly exists and refers
+        to the image the host itself is booted from.</para>
+
+        <xi:include href="version-info.xml" xpointer="v219"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>image-status</command> [<replaceable>NAME</replaceable>…]</term>
+
+        <listitem><para>Show terse status information about one or
+        more container or VM images. This function is intended to
+        generate human-readable output. Use
+        <command>show-image</command> (see below) to generate
+        computer-parsable output instead.</para>
+
+        <xi:include href="version-info.xml" xpointer="v219"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>show-image</command> [<replaceable>NAME</replaceable>…]</term>
+
+        <listitem><para>Show properties of one or more registered
+        virtual machine or container images, or the manager itself. If
+        no argument is specified, properties of the manager will be
+        shown. If a NAME is specified, properties of this virtual
+        machine or container image are shown. By default, empty
+        properties are suppressed. Use <option>--all</option> to show
+        those too. To select specific properties to show, use
+        <option>--property=</option>. This command is intended to be
+        used whenever computer-parsable output is required. Use
+        <command>image-status</command> if you are looking for
+        formatted human-readable output.</para>
+
+        <xi:include href="version-info.xml" xpointer="v219"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>edit</command> <replaceable>NAME|FILE</replaceable></term>
+
+        <listitem><para>Edit the settings file of the specified machines. For the format of the settings
+        file, refer to
+        <citerefentry project='man-pages'><refentrytitle>systemd.nspawn</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+        If an existing settings file of the given machine can't be found, <command>edit</command>
+        automatically create a new settings file from scratch under
+        <filename>/etc/systemd/nspawn/</filename>.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>cat</command> <replaceable>NAME|FILE</replaceable></term>
+
+        <listitem><para>Show the settings file of the specified machines.</para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>clone</command> <replaceable>NAME</replaceable> <replaceable>NAME</replaceable></term>
+
+        <listitem><para>Clones a container or VM image. The arguments specify the name of the image to clone and the
+        name of the newly cloned image. Note that plain directory container images are cloned into btrfs subvolume
+        images with this command, if the underlying file system supports this.  Note that cloning a container or VM
+        image is optimized for file systems that support copy-on-write, and might not be efficient on others, due to
+        file system limitations.</para>
+
+        <para>Note that this command leaves hostname, machine ID and
+        all other settings that could identify the instance
+        unmodified. The original image and the cloned copy will hence
+        share these credentials, and it might be necessary to manually
+        change them in the copy.</para>
+
+        <para>If combined with the <option>--read-only</option> switch a read-only cloned image is
+        created.</para>
+
+        <xi:include href="version-info.xml" xpointer="v219"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>rename</command> <replaceable>NAME</replaceable> <replaceable>NAME</replaceable></term>
+
+        <listitem><para>Renames a container or VM image. The
+        arguments specify the name of the image to rename and the new
+        name of the image.</para>
+
+        <xi:include href="version-info.xml" xpointer="v219"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>read-only</command> <replaceable>NAME</replaceable> [<replaceable>BOOL</replaceable>]</term>
+
+        <listitem><para>Marks or (unmarks) a container or VM image
+        read-only. Takes a VM or container image name, followed by a
+        boolean as arguments. If the boolean is omitted, positive is
+        implied, i.e. the image is marked read-only.</para>
+
+        <xi:include href="version-info.xml" xpointer="v219"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>remove</command> <replaceable>NAME</replaceable>…</term>
+
+        <listitem><para>Removes one or more container or VM images.
+        The special image <literal>.host</literal>, which refers to
+        the host's own directory tree, may not be
+        removed.</para>
+
+        <xi:include href="version-info.xml" xpointer="v219"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>set-limit</command> [<replaceable>NAME</replaceable>] <replaceable>BYTES</replaceable></term>
+
+        <listitem><para>Sets the maximum size in bytes that a specific
+        container or VM image, or all images, may grow up to on disk
+        (disk quota). Takes either one or two parameters. The first,
+        optional parameter refers to a container or VM image name. If
+        specified, the size limit of the specified image is changed. If
+        omitted, the overall size limit of the sum of all images stored
+        locally is changed. The final argument specifies the size
+        limit in bytes, possibly suffixed by the usual K, M, G, T
+        units. If the size limit shall be disabled, specify
+        <literal>-</literal> as size.</para>
+
+        <para>Note that per-container size limits are only supported on btrfs file systems.</para>
+
+        <xi:include href="version-info.xml" xpointer="v220"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>clean</command></term>
+
+        <listitem><para>Remove hidden VM or container images (or all). This command removes all hidden machine images
+        from <filename>/var/lib/machines/</filename>, i.e. those whose name begins with a dot. Use <command>machinectl
+        list-images --all</command> to see a list of all machine images, including the hidden ones.</para>
+
+        <para>When combined with the <option>--all</option> switch removes all images, not just hidden ones. This
+        command effectively empties <filename>/var/lib/machines/</filename>.</para>
+
+        <para>Note that commands such as <command>machinectl pull-tar</command> or <command>machinectl
+        pull-raw</command> usually create hidden, read-only, unmodified machine images from the downloaded image first,
+        before cloning a writable working copy of it, in order to avoid duplicate downloads in case of images that are
+        reused multiple times. Use <command>machinectl clean</command> to remove old, hidden images created this
+        way.</para>
+
+        <xi:include href="version-info.xml" xpointer="v230"/></listitem>
+      </varlistentry>
+
+    </variablelist></refsect2>
+
+    <refsect2><title>Image Transfer Commands</title><variablelist>
+
+      <varlistentry>
+        <term><command>pull-tar</command> <replaceable>URL</replaceable> [<replaceable>NAME</replaceable>]</term>
+
+        <listitem><para>Downloads a <filename>.tar</filename>
+        container image from the specified URL, and makes it available
+        under the specified local machine name. The URL must be of
+        type <literal>http://</literal> or
+        <literal>https://</literal>, and must refer to a
+        <filename>.tar</filename>, <filename>.tar.gz</filename>,
+        <filename>.tar.xz</filename> or <filename>.tar.bz2</filename>
+        archive file. If the local machine name is omitted, it
+        is automatically derived from the last component of the URL,
+        with its suffix removed.</para>
+
+        <para>The image is verified before it is made available, unless
+        <option>--verify=no</option> is specified.
+        Verification is done either via an inline signed file with the name
+        of the image and the suffix <filename>.sha256</filename> or via
+        separate <filename>SHA256SUMS</filename> and
+        <filename>SHA256SUMS.gpg</filename> files.
+        The signature files need to be made available on the same web
+        server, under the same URL as the <filename>.tar</filename> file.
+        With <option>--verify=checksum</option>, only the SHA256 checksum
+        for the file is verified, based on the <filename>.sha256</filename>
+        suffixed file or the <filename>SHA256SUMS</filename> file.
+        With <option>--verify=signature</option>, the sha checksum file is
+        first verified with the inline signature in the
+        <filename>.sha256</filename> file or the detached GPG signature file
+        <filename>SHA256SUMS.gpg</filename>.
+        The public key for this verification step needs to be available in
+        <filename>/usr/lib/systemd/import-pubring.gpg</filename> or
+        <filename>/etc/systemd/import-pubring.gpg</filename>.</para>
+
+        <para>The container image will be downloaded and stored in a
+        read-only subvolume in
+        <filename>/var/lib/machines/</filename> that is named after
+        the specified URL and its HTTP etag. A writable snapshot is
+        then taken from this subvolume, and named after the specified
+        local name. This behavior ensures that creating multiple
+        container instances of the same URL is efficient, as multiple
+        downloads are not necessary. In order to create only the
+        read-only image, and avoid creating its writable snapshot,
+        specify <literal>-</literal> as local machine name.</para>
+
+        <para>Note that the read-only subvolume is prefixed with
+        <filename>.tar-</filename>, and is thus not shown by
+        <command>list-images</command>, unless <option>--all</option>
+        is passed.</para>
+
+        <para>Note that pressing C-c during execution of this command
+        will not abort the download. Use
+        <command>cancel-transfer</command>, described
+        below.</para>
+
+        <xi:include href="version-info.xml" xpointer="v219"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>pull-raw</command> <replaceable>URL</replaceable> [<replaceable>NAME</replaceable>]</term>
+
+        <listitem><para>Downloads a <filename>.raw</filename>
+        container or VM disk image from the specified URL, and makes
+        it available under the specified local machine name. The URL
+        must be of type <literal>http://</literal> or
+        <literal>https://</literal>. The container image must either
+        be a <filename>.qcow2</filename> or raw disk image, optionally
+        compressed as <filename>.gz</filename>,
+        <filename>.xz</filename>, or <filename>.bz2</filename>. If the
+        local machine name is omitted, it is automatically
+        derived from the last component of the URL, with its suffix
+        removed.</para>
+
+        <para>Image verification is identical for raw and tar images
+        (see above).</para>
+
+        <para>If the downloaded image is in
+        <filename>.qcow2</filename> format it is converted into a raw
+        image file before it is made available.</para>
+
+        <para>Downloaded images of this type will be placed as
+        read-only <filename>.raw</filename> file in
+        <filename>/var/lib/machines/</filename>. A local, writable
+        (reflinked) copy is then made under the specified local
+        machine name. To omit creation of the local, writable copy
+        pass <literal>-</literal> as local machine name.</para>
+
+        <para>Similarly to the behavior of <command>pull-tar</command>, the read-only image is prefixed with
+        <filename>.raw-</filename>, and thus not shown by <command>list-images</command>, unless
+        <option>--all</option> is passed.</para>
+
+        <para>Note that pressing C-c during execution of this command
+        will not abort the download. Use
+        <command>cancel-transfer</command>, described
+        below.</para>
+
+        <xi:include href="version-info.xml" xpointer="v219"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>import-tar</command> <replaceable>FILE</replaceable> [<replaceable>NAME</replaceable>]</term>
+        <term><command>import-raw</command> <replaceable>FILE</replaceable> [<replaceable>NAME</replaceable>]</term>
+        <listitem><para>Imports a TAR or RAW container or VM image,
+        and places it under the specified name in
+        <filename>/var/lib/machines/</filename>. When
+        <command>import-tar</command> is used, the file specified as
+        the first argument should be a tar archive, possibly compressed
+        with xz, gzip or bzip2. It will then be unpacked into its own
+        subvolume in <filename>/var/lib/machines/</filename>. When
+        <command>import-raw</command> is used, the file should be a
+        qcow2 or raw disk image, possibly compressed with xz, gzip or
+        bzip2. If the second argument (the resulting image name) is
+        not specified, it is automatically derived from the file
+        name. If the filename is passed as <literal>-</literal>, the
+        image is read from standard input, in which case the second
+        argument is mandatory.</para>
+
+        <para>Optionally, the <option>--read-only</option> switch may be used to create a read-only container or VM
+        image. No cryptographic validation is done when importing the images.</para>
+
+        <para>Much like image downloads, ongoing imports may be listed
+        with <command>list-transfers</command> and aborted with
+        <command>cancel-transfer</command>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v220"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>import-fs</command> <replaceable>DIRECTORY</replaceable> [<replaceable>NAME</replaceable>]</term>
+
+        <listitem><para>Imports a container image stored in a local directory into
+        <filename>/var/lib/machines/</filename>, operates similarly to <command>import-tar</command> or
+        <command>import-raw</command>, but the first argument is the source directory. If supported, this
+        command will create a btrfs snapshot or subvolume for the new image.</para>
+
+        <xi:include href="version-info.xml" xpointer="v240"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>export-tar</command> <replaceable>NAME</replaceable> [<replaceable>FILE</replaceable>]</term>
+        <term><command>export-raw</command> <replaceable>NAME</replaceable> [<replaceable>FILE</replaceable>]</term>
+        <listitem><para>Exports a TAR or RAW container or VM image and
+        stores it in the specified file. The first parameter should be
+        a VM or container image name. The second parameter should be a
+        file path the TAR or RAW image is written to. If the path ends
+        in <literal>.gz</literal>, the file is compressed with gzip, if
+        it ends in <literal>.xz</literal>, with xz, and if it ends in
+        <literal>.bz2</literal>, with bzip2. If the path ends in
+        neither, the file is left uncompressed. If the second argument
+        is missing, the image is written to standard output. The
+        compression may also be explicitly selected with the
+        <option>--format=</option> switch. This is in particular
+        useful if the second parameter is left unspecified.</para>
+
+        <para>Much like image downloads and imports, ongoing exports
+        may be listed with <command>list-transfers</command> and
+        aborted with
+        <command>cancel-transfer</command>.</para>
+
+        <para>Note that, currently, only directory and subvolume images
+        may be exported as TAR images, and only raw disk images as RAW
+        images.</para>
+
+        <xi:include href="version-info.xml" xpointer="v220"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>list-transfers</command></term>
+
+        <listitem><para>Shows a list of container or VM image
+        downloads, imports and exports that are currently in
+        progress.</para>
+
+        <xi:include href="version-info.xml" xpointer="v219"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>cancel-transfer</command> <replaceable>ID</replaceable>…</term>
+
+        <listitem><para>Aborts a download, import or export of the
+        container or VM image with the specified ID. To list ongoing
+        transfers and their IDs, use
+        <command>list-transfers</command>. </para>
+
+        <xi:include href="version-info.xml" xpointer="v219"/></listitem>
+      </varlistentry>
+
+    </variablelist></refsect2>
+
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>The following options are understood:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><option>-p</option></term>
+        <term><option>--property=</option></term>
+
+        <listitem><para>When showing machine or image properties,
+        limit the output to certain properties as specified by the
+        argument. If not specified, all set properties are shown. The
+        argument should be a property name, such as
+        <literal>Name</literal>. If specified more than once, all
+        properties with the specified names are
+        shown.</para>
+
+        <xi:include href="version-info.xml" xpointer="v206"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-a</option></term>
+        <term><option>--all</option></term>
+
+        <listitem><para>When showing machine or image properties, show
+        all properties regardless of whether they are set or
+        not.</para>
+
+        <para>When listing VM or container images, do not suppress
+        images beginning in a dot character
+        (<literal>.</literal>).</para>
+
+        <para>When cleaning VM or container images, remove all images, not just hidden ones.</para>
+
+        <xi:include href="version-info.xml" xpointer="v206"/></listitem>
+      </varlistentry>
+
+       <varlistentry>
+        <term><option>--value</option></term>
+
+        <listitem><para>When printing properties with <command>show</command>, only print the value,
+        and skip the property name and <literal>=</literal>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v230"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-l</option></term>
+        <term><option>--full</option></term>
+
+        <listitem><para>Do not ellipsize process tree entries or table. This implies
+        <option>--max-addresses=full</option>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v206"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--kill-whom=</option></term>
+
+        <listitem><para>When used with <command>kill</command>, choose
+        which processes to kill. Must be one of
+        <option>leader</option>, or <option>all</option> to select
+        whether to kill only the leader process of the machine or all
+        processes of the machine. If omitted, defaults to
+        <option>all</option>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v206"/></listitem>
+      </varlistentry>
+
+      <xi:include href="standard-options.xml" xpointer="signal" />
+
+      <varlistentry>
+         <term><option>--uid=</option></term>
+
+         <listitem><para>When used with the <command>shell</command> command, chooses the user ID to
+         open the interactive shell session as. If the argument to the <command>shell</command>
+         command also specifies a user name, this option is ignored. If the name is not specified
+         in either way, <literal>root</literal> will be used by default. Note that this switch is
+         not supported for the <command>login</command> command (see below).</para>
+
+         <xi:include href="version-info.xml" xpointer="v225"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-E <replaceable>NAME</replaceable>[=<replaceable>VALUE</replaceable>]</option></term>
+        <term><option>--setenv=<replaceable>NAME</replaceable>[=<replaceable>VALUE</replaceable>]</option></term>
+
+        <listitem><para>When used with the <command>shell</command> command, sets an environment variable for
+        the executed shell. This option may be used more than once to set multiple variables. When
+        <literal>=</literal> and <replaceable>VALUE</replaceable> are omitted, the value of the variable with
+        the same name in the program environment will be used.</para>
+
+        <para>Note that this option is not supported for the <command>login</command> command.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v230"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--mkdir</option></term>
+
+        <listitem><para>When used with <command>bind</command>, creates the destination file or directory before
+        applying the bind mount. Note that even though the name of this option suggests that it is suitable only for
+        directories, this option also creates the destination file node to mount over if the object to mount is not
+        a directory, but a regular file, device node, socket or FIFO.</para>
+
+        <xi:include href="version-info.xml" xpointer="v219"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--read-only</option></term>
+
+        <listitem><para>When used with <command>bind</command>, creates a read-only bind mount.</para>
+
+        <para>When used with <command>clone</command>, <command>import-raw</command> or <command>import-tar</command> a
+        read-only container or VM image is created.</para>
+
+        <xi:include href="version-info.xml" xpointer="v219"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-n</option></term>
+        <term><option>--lines=</option></term>
+
+        <listitem><para>When used with <command>status</command>,
+        controls the number of journal lines to show, counting from
+        the most recent ones. Takes a positive integer argument.
+        Defaults to 10.</para>
+
+        <xi:include href="version-info.xml" xpointer="v219"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-o</option></term>
+        <term><option>--output=</option></term>
+
+        <listitem><para>When used with <command>status</command>,
+        controls the formatting of the journal entries that are shown.
+        For the available choices, see
+        <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
+        Defaults to <literal>short</literal>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v219"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--verify=</option></term>
+
+        <listitem><para>When downloading a container or VM image,
+        specify whether the image shall be verified before it is made
+        available. Takes one of <literal>no</literal>,
+        <literal>checksum</literal> and <literal>signature</literal>.
+        If <literal>no</literal>, no verification is done. If
+        <literal>checksum</literal> is specified, the download is
+        checked for integrity after the transfer is complete, but no
+        signatures are verified. If <literal>signature</literal> is
+        specified, the checksum is verified and the image's signature
+        is checked against a local keyring of trustable vendors. It is
+        strongly recommended to set this option to
+        <literal>signature</literal> if the server and protocol
+        support this. Defaults to
+        <literal>signature</literal>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v219"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--now</option></term>
+
+        <listitem>
+          <para>When used with <command>enable</command> or <command>disable</command>,
+          the containers will also be started or powered off. The start or poweroff
+          operation is only carried out when the respective enable or disable
+          operation has been successful.</para>
+
+        <xi:include href="version-info.xml" xpointer="v253"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--force</option></term>
+
+        <listitem><para>When downloading a container or VM image, and
+        a local copy by the specified local machine name already
+        exists, delete it first and replace it by the newly downloaded
+        image.</para>
+
+        <xi:include href="version-info.xml" xpointer="v219"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--format=</option></term>
+
+        <listitem><para>When used with the <option>export-tar</option>
+        or <option>export-raw</option> commands, specifies the
+        compression format to use for the resulting file. Takes one of
+        <literal>uncompressed</literal>, <literal>xz</literal>,
+        <literal>gzip</literal>, <literal>bzip2</literal>. By default,
+        the format is determined automatically from the image file
+        name passed.</para>
+
+        <xi:include href="version-info.xml" xpointer="v220"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--max-addresses=</option></term>
+
+        <listitem><para>When used with the <option>list-machines</option> command, limits the number of IP
+        addresses shown for every machine. Defaults to 1. All addresses can be requested with
+        <literal>all</literal>. If the limit is 0, the address column is not shown. Otherwise, if the machine
+        has more addresses than shown, <literal>…</literal> follows the last address.</para>
+
+        <xi:include href="version-info.xml" xpointer="v232"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-q</option></term>
+        <term><option>--quiet</option></term>
+
+        <listitem><para>Suppresses additional informational output while running.</para>
+
+        <xi:include href="version-info.xml" xpointer="v236"/></listitem>
+      </varlistentry>
+
+      <xi:include href="user-system-options.xml" xpointer="host" />
+
+      <varlistentry>
+        <term><option>-M</option></term>
+        <term><option>--machine=</option></term>
+
+        <listitem><para>Connect to
+        <citerefentry><refentrytitle>systemd-machined.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        running in a local container, to perform the specified operation within
+        the container.</para>
+
+        <xi:include href="version-info.xml" xpointer="v235"/></listitem>
+      </varlistentry>
+
+      <xi:include href="standard-options.xml" xpointer="no-pager" />
+      <xi:include href="standard-options.xml" xpointer="no-legend" />
+      <xi:include href="standard-options.xml" xpointer="no-ask-password" />
+      <xi:include href="standard-options.xml" xpointer="help" />
+      <xi:include href="standard-options.xml" xpointer="version" />
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Machine and Image Names</title>
+
+    <para>The <command>machinectl</command> tool operates on machines
+    and images whose names must be chosen following strict
+    rules. Machine names must be suitable for use as hostnames
+    following a conservative subset of DNS and UNIX/Linux
+    semantics. Specifically, they must consist of one or more
+    non-empty label strings, separated by dots. No leading or trailing
+    dots are allowed. No sequences of multiple dots are allowed. The
+    label strings may only consist of alphanumeric characters as well
+    as the dash and underscore. The maximum length of a machine name
+    is 64 characters.</para>
+
+    <para>A special machine with the name <literal>.host</literal>
+    refers to the running host system itself. This is useful for execution
+    operations or inspecting the host system as well. Note that
+    <command>machinectl list</command> will not show this special
+    machine unless the <option>--all</option> switch is specified.</para>
+
+    <para>Requirements on image names are less strict, however, they must be
+    valid UTF-8, must be suitable as file names (hence not be the
+    single or double dot, and not include a slash), and may not
+    contain control characters. Since many operations search for an
+    image by the name of a requested machine, it is recommended to name
+    images in the same strict fashion as machines.</para>
+
+    <para>A special image with the name <literal>.host</literal>
+    refers to the image of the running host system. It hence
+    conceptually maps to the special <literal>.host</literal> machine
+    name described above. Note that <command>machinectl
+    list-images</command> will not show this special image either, unless
+    <option>--all</option> is specified.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Files and Directories</title>
+
+    <para>Machine images are preferably stored in
+    <filename>/var/lib/machines/</filename>, but are also searched for
+    in <filename>/usr/local/lib/machines/</filename> and
+    <filename>/usr/lib/machines/</filename>. For compatibility reasons,
+    the directory <filename>/var/lib/container/</filename> is
+    searched, too. Note that images stored below
+    <filename>/usr/</filename> are always considered read-only. It is
+    possible to symlink machines images from other directories into
+    <filename>/var/lib/machines/</filename> to make them available for
+    control with <command>machinectl</command>.</para>
+
+    <para>Note that some image operations are only supported, efficient or atomic on btrfs file systems.</para>
+
+    <para>Disk images are understood by
+    <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    and <command>machinectl</command> in three formats:</para>
+
+    <itemizedlist>
+      <listitem><para>A simple directory tree, containing the files
+      and directories of the container to boot.</para></listitem>
+
+      <listitem><para>Subvolumes (on btrfs file systems), which are
+      similar to the simple directories, described above. However,
+      they have additional benefits, such as efficient cloning and
+      quota reporting.</para></listitem>
+
+      <listitem><para>"Raw" disk images, i.e. binary images of disks
+      with a GPT or MBR partition table. Images of this type are
+      regular files with the suffix
+      <literal>.raw</literal>.</para></listitem>
+    </itemizedlist>
+
+    <para>See
+    <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    for more information on image formats, in particular its
+    <option>--directory=</option> and <option>--image=</option>
+    options.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Examples</title>
+    <example>
+      <title>Download a Ubuntu image and open a shell in it</title>
+
+      <programlisting># machinectl pull-tar https://cloud-images.ubuntu.com/trusty/current/trusty-server-cloudimg-amd64-root.tar.gz
+# systemd-nspawn -M trusty-server-cloudimg-amd64-root</programlisting>
+
+      <para>This downloads and verifies the specified
+      <filename>.tar</filename> image, and then uses
+      <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+      to open a shell in it.</para>
+    </example>
+
+    <example>
+      <title>Download a Fedora image, set a root password in it, start
+      it as a service</title>
+
+      <programlisting># machinectl pull-raw --verify=no \
+      https://download.fedoraproject.org/pub/fedora/linux/releases/&fedora_latest_version;/Cloud/x86_64/images/Fedora-Cloud-Base-&fedora_latest_version;-&fedora_cloud_release;.x86_64.raw.xz \
+      Fedora-Cloud-Base-&fedora_latest_version;-&fedora_cloud_release;.x86-64
+# systemd-nspawn -M Fedora-Cloud-Base-&fedora_latest_version;-&fedora_cloud_release;.x86-64
+# passwd
+# exit
+# machinectl start Fedora-Cloud-Base-&fedora_latest_version;-&fedora_cloud_release;.x86-64
+# machinectl login Fedora-Cloud-Base-&fedora_latest_version;-&fedora_cloud_release;.x86-64</programlisting>
+
+      <para>This downloads the specified <filename>.raw</filename>
+      image with verification disabled. Then, a shell is opened in it
+      and a root password is set. Afterwards the shell is left, and
+      the machine started as system service. With the last command a
+      login prompt into the container is requested.</para>
+    </example>
+
+    <example>
+      <title>Exports a container image as tar file</title>
+
+      <programlisting># machinectl export-tar fedora myfedora.tar.xz</programlisting>
+
+      <para>Exports the container <literal>fedora</literal> as an
+      xz-compressed tar file <filename>myfedora.tar.xz</filename> into the
+      current directory.</para>
+    </example>
+
+    <example>
+      <title>Create a new shell session</title>
+
+      <programlisting># machinectl shell --uid=lennart</programlisting>
+
+      <para>This creates a new shell session on the local host for
+      the user ID <literal>lennart</literal>, in a <citerefentry
+      project='die-net'><refentrytitle>su</refentrytitle><manvolnum>1</manvolnum></citerefentry>-like
+      fashion.</para>
+    </example>
+
+  </refsect1>
+
+  <refsect1>
+    <title>Exit status</title>
+
+    <para>On success, 0 is returned, a non-zero failure code
+    otherwise.</para>
+  </refsect1>
+
+  <xi:include href="common-variables.xml" />
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-machined.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry project='die-net'><refentrytitle>tar</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry project='die-net'><refentrytitle>xz</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry project='die-net'><refentrytitle>gzip</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry project='die-net'><refentrytitle>bzip2</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/man.in b/man/man.in
new file mode 100755
index 0000000..201c32d
--- /dev/null
+++ b/man/man.in
@@ -0,0 +1,30 @@
+#!/bin/sh
+# SPDX-License-Identifier: LGPL-2.1-or-later
+
+set -e
+
+if [ -z "$1" ]; then
+    echo "Use: $0 page-name (with no section suffix)"
+    exit 1
+fi
+
+# make sure the rules have been regenerated (in case update-man-rules was just run)
+ninja -C "@BUILD_ROOT@" version.h
+
+page="$(echo "$1" | sed 's/\./\\./')"
+target=$(ninja -C "@BUILD_ROOT@" -t query man/man | grep -E -m1 "man/$page\.[0-9]$" | awk '{print $2}')
+if [ -z "$target" ]; then
+    echo "Cannot find page $1"
+    exit 1
+fi
+ninja -C "@BUILD_ROOT@" "$target"
+
+fullname="@BUILD_ROOT@/$target"
+redirect="$(sed -n -r '1 s|^\.so man[0-9]/(.*)|\1|p' "$fullname")"
+if [ -n "$redirect" ]; then
+    ninja -C "@BUILD_ROOT@" "man/$redirect"
+
+    fullname="@BUILD_ROOT@/man/$redirect"
+fi
+
+exec man "$fullname"
diff --git a/man/meson.build b/man/meson.build
new file mode 100644
index 0000000..403098a
--- /dev/null
+++ b/man/meson.build
@@ -0,0 +1,242 @@
+# SPDX-License-Identifier: LGPL-2.1-or-later
+
+# This is lame, I know, but meson has no other include mechanism
+subdir('rules')
+
+want_man = get_option('man')
+want_html = get_option('html')
+xsltproc = find_program('xsltproc',
+                        required : want_man.enabled() or want_html.enabled())
+want_man = want_man.allowed() and xsltproc.found()
+want_html = want_html.allowed() and xsltproc.found()
+
+xsltproc_flags = [
+        '--nonet',
+        '--xinclude',
+        '--maxdepth', '9000',
+        '--stringparam', 'man.output.quietly', '1',
+        '--stringparam', 'funcsynopsis.style', 'ansi',
+        '--stringparam', 'man.authors.section.enabled', '0',
+        '--stringparam', 'man.copyright.section.enabled', '0',
+        '--stringparam', 'systemd.version', '@0@'.format(meson.project_version()),
+        '--path',
+        '@0@:@1@:@2@'.format(meson.current_build_dir(),
+                             meson.current_source_dir(),
+                             libshared_build_dir)]
+
+custom_man_xsl = files('custom-man.xsl')
+custom_html_xsl = files('custom-html.xsl')
+xslt_cmd = [xsltproc, '-o', '@OUTPUT0@'] + xsltproc_flags
+
+custom_entities_ent = custom_target(
+        'custom-entities.ent',
+        input : 'custom-entities.ent.in',
+        output : 'custom-entities.ent',
+        command : [jinja2_cmdline, '@INPUT@', '@OUTPUT@'])
+
+man_page_depends += custom_entities_ent
+
+man_pages = []
+html_pages = []
+source_xml_files = []
+dbus_docs = []
+foreach tuple : manpages
+        stem = tuple[0]
+        section = tuple[1]
+        aliases = tuple[2]
+        condition = tuple[3]
+
+        xml = stem + '.xml'
+        html = stem + '.html'
+        man = stem + '.' + section
+
+        manaliases = []
+        htmlaliases = []
+        foreach alias : aliases
+                manaliases += alias + '.' + section
+                htmlaliases += alias + '.html'
+        endforeach
+
+        mandirn = get_option('mandir') / ('man' + section)
+
+        if condition == '' or conf.get(condition) == 1
+                file = files(tuple[0] + '.xml')
+                source_xml_files += file
+                if tuple[0].startswith('org.freedesktop.')
+                        dbus_docs += file
+                endif
+
+                if xsltproc.found()
+                        p1 = custom_target(
+                                man,
+                                input : xml,
+                                output : [man] + manaliases,
+                                command : xslt_cmd + [custom_man_xsl, '@INPUT@'],
+                                depends : man_page_depends,
+                                install : want_man,
+                                install_dir : mandirn)
+                        man_pages += p1
+
+                        p2 = []
+                        foreach htmlalias : htmlaliases
+                                link = custom_target(
+                                        htmlalias,
+                                        output : htmlalias,
+                                        command : [ln, '-fs', html, '@OUTPUT@'])
+                                if want_html
+                                        meson.add_install_script(sh, '-c', ln_s.format(docdir / 'html' / html, docdir / 'html' / htmlalias))
+                                        p2 += link
+                                endif
+                                html_pages += link
+                        endforeach
+
+                        p3 = custom_target(
+                                html,
+                                input : xml,
+                                output : html,
+                                command : xslt_cmd + [custom_html_xsl, '@INPUT@'],
+                                depends : [man_page_depends, p2],
+                                install : want_html,
+                                install_dir : docdir / 'html')
+                        html_pages += p3
+                endif
+        else
+                message('Skipping @0@.@1@ because @2@ is false'.format(stem, section, condition))
+        endif
+endforeach
+
+############################################################
+
+have_lxml = run_command(xml_helper_py, check: false).returncode() == 0
+if not have_lxml
+        message('python-lxml not available, not making man page indices')
+endif
+
+systemd_directives_xml = custom_target(
+        'systemd.directives.xml',
+        input : ['directives-template.xml', source_xml_files],
+        output : 'systemd.directives.xml',
+        depends : man_page_depends,
+        command : [make_directive_index_py, '@OUTPUT@', '@INPUT@'])
+
+nonindex_xml_files = source_xml_files + [systemd_directives_xml]
+systemd_index_xml = custom_target(
+        'systemd.index.xml',
+        input : nonindex_xml_files,
+        output : 'systemd.index.xml',
+        command : [make_man_index_py, '@OUTPUT@'] + nonindex_xml_files)
+
+foreach tuple : xsltproc.found() ? [['systemd.directives', '7', systemd_directives_xml],
+                                    ['systemd.index',      '7', systemd_index_xml]] : []
+        stem = tuple[0]
+        section = tuple[1]
+        xml = tuple[2]
+
+        html = stem + '.html'
+        man = stem + '.' + section
+
+        mandirn = get_option('mandir') / ('man' + section)
+
+        p1 = custom_target(
+                man,
+                input : xml,
+                output : man,
+                command : xslt_cmd + [custom_man_xsl, '@INPUT@'],
+                install : want_man and have_lxml,
+                install_dir : mandirn)
+        man_pages += p1
+
+        p2 = []
+        if html == 'systemd.index.html'
+                htmlalias = 'index.html'
+                link = custom_target(
+                        htmlalias,
+                        input : p2,
+                        output : htmlalias,
+                        command : [ln, '-fs', html, '@OUTPUT@'])
+                if want_html
+                        meson.add_install_script(sh, '-c', ln_s.format(docdir / 'html' / html, docdir / 'html' / htmlalias))
+                        p2 += link
+                endif
+                html_pages += link
+        endif
+
+        p3 = custom_target(
+                html,
+                input : xml,
+                output : html,
+                command : xslt_cmd + [custom_html_xsl, '@INPUT@'],
+                depends : [man_page_depends, p2],
+                install : want_html and have_lxml,
+                install_dir : docdir / 'html')
+        html_pages += p3
+endforeach
+
+# Cannot use run_target because those targets are used in depends
+# Also see https://github.com/mesonbuild/meson/issues/368.
+man = custom_target(
+        'man',
+        output : 'man',
+        depends : man_pages,
+        command : [echo])
+
+html = custom_target(
+        'html',
+        output : 'html',
+        depends : html_pages,
+        command : [echo])
+
+if rsync.found()
+        run_target(
+                'doc-sync',
+                depends : man_pages + html_pages,
+                command : [sync_docs_py,
+                           '--version',
+                           '@0@'.format(meson.project_version()),
+                           meson.current_build_dir(),
+                           get_option('www-target')])
+endif
+
+############################################################
+
+buildroot_substs = configuration_data()
+buildroot_substs.set_quoted('BUILD_ROOT', project_build_root)
+
+configure_file(
+        input : 'man.in',
+        output : 'man',
+        configuration : buildroot_substs)
+
+configure_file(
+        input : 'html.in',
+        output : 'html',
+        configuration : buildroot_substs)
+
+############################################################
+
+update_dbus_docs = custom_target(
+        'update-dbus-docs-impl',
+        output : 'update-dbus-docs',
+        command : [update_dbus_docs_py, '--build-dir', project_build_root, '@INPUT@'],
+        input : dbus_docs)
+
+if conf.get('BUILD_MODE_DEVELOPER') == 1
+        test('dbus-docs-fresh',
+             update_dbus_docs_py,
+             suite : 'dist',
+             args : ['--build-dir', project_build_root, '--test', dbus_docs],
+             depends : dbus_programs)
+
+        test('check-version-history',
+             check_version_history_py,
+             suite : 'dist',
+             args : source_xml_files)
+endif
+
+update_man_rules = custom_target(
+        'update-man-rules-impl',
+        output : 'update-man-rules',
+        command : [update_man_rules_py,
+                   '@0@/man/*.xml'.format(project_source_root),
+                   '@0@/rules/meson.build'.format(meson.current_source_dir())],
+        depends : man_page_depends)
diff --git a/man/modules-load.d.xml b/man/modules-load.d.xml
new file mode 100644
index 0000000..cd0c006
--- /dev/null
+++ b/man/modules-load.d.xml
@@ -0,0 +1,76 @@
+<?xml version="1.0"?>
+<!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+<refentry id="modules-load.d" conditional='HAVE_KMOD'
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>modules-load.d</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>modules-load.d</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>modules-load.d</refname>
+    <refpurpose>Configure kernel modules to load at boot</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>/etc/modules-load.d/*.conf</filename></para>
+    <para><filename>/run/modules-load.d/*.conf</filename></para>
+    <para><filename>/usr/lib/modules-load.d/*.conf</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><citerefentry><refentrytitle>systemd-modules-load.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    reads files from the above directories which contain kernel
+    modules to load during boot in a static list. Each configuration
+    file is named in the style of
+    <filename>/etc/modules-load.d/<replaceable>program</replaceable>.conf</filename>.
+    Note that it is usually a better idea to rely on the automatic
+    module loading by PCI IDs, USB IDs, DMI IDs or similar triggers
+    encoded in the kernel modules themselves instead of static
+    configuration like this. In fact, most modern kernel modules are
+    prepared for automatic loading already.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Configuration Format</title>
+
+    <para>The configuration files should simply contain a list of
+    kernel module names to load, separated by newlines. Empty lines
+    and lines whose first non-whitespace character is # or ; are
+    ignored.</para>
+  </refsect1>
+
+  <xi:include href="standard-conf.xml" xpointer="confd" />
+
+  <refsect1>
+    <title>Example</title>
+    <example>
+      <title>/etc/modules-load.d/virtio-net.conf example:</title>
+
+      <programlisting># Load virtio-net.ko at boot
+virtio-net</programlisting>
+    </example>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-modules-load.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-delta</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>modprobe</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/networkctl.xml b/man/networkctl.xml
new file mode 100644
index 0000000..68b1d97
--- /dev/null
+++ b/man/networkctl.xml
@@ -0,0 +1,570 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="networkctl" conditional='ENABLE_NETWORKD'
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>networkctl</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>networkctl</refentrytitle>
+    <manvolnum>1</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>networkctl</refname>
+    <refpurpose>Query or modify the status of network links</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <cmdsynopsis>
+      <command>networkctl</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="plain">COMMAND</arg>
+      <arg choice="opt" rep="repeat">LINK</arg>
+    </cmdsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>networkctl</command> may be used to query or modify the
+    state of the network links as seen by
+    <command>systemd-networkd</command>.  Please refer to
+    <citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    for an introduction to the basic concepts, functionality, and
+    configuration syntax.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Commands</title>
+
+    <para>The following commands are understood:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term>
+          <command>list</command>
+          <optional><replaceable>PATTERN…</replaceable></optional>
+        </term>
+
+        <listitem>
+          <para>Show a list of existing links and their status. If one or more
+          <replaceable>PATTERN</replaceable>s are specified, only links matching one of them are shown.
+          If no further arguments are specified shows all links,
+          otherwise just the specified links. Produces output similar to:
+
+          <programlisting>IDX LINK         TYPE     OPERATIONAL SETUP
+  1 lo           loopback carrier     unmanaged
+  2 eth0         ether    routable    configured
+  3 virbr0       ether    no-carrier  unmanaged
+  4 virbr0-nic   ether    off         unmanaged
+
+4 links listed.</programlisting></para>
+
+        <para>The operational status is one of the following:
+            <variablelist>
+              <varlistentry>
+                <term>missing</term>
+                <listitem>
+                    <para>The device is missing.</para>
+
+                    <xi:include href="version-info.xml" xpointer="v245"/>
+                </listitem>
+              </varlistentry>
+              <varlistentry>
+                <term>off</term>
+                <listitem>
+                  <para>The device is powered down.</para>
+
+                  <xi:include href="version-info.xml" xpointer="v240"/>
+                </listitem>
+              </varlistentry>
+              <varlistentry>
+                <term>no-carrier</term>
+                <listitem>
+                  <para>The device is powered up, but does not yet have a carrier.</para>
+
+                  <xi:include href="version-info.xml" xpointer="v240"/>
+                </listitem>
+              </varlistentry>
+              <varlistentry>
+                <term>dormant</term>
+                <listitem>
+                  <para>The device has a carrier, but is not yet ready for normal traffic.</para>
+
+                  <xi:include href="version-info.xml" xpointer="v240"/>
+                </listitem>
+              </varlistentry>
+              <varlistentry>
+                <term>degraded-carrier</term>
+                <listitem>
+                  <para>One of the bonding or bridge slave network interfaces is in off, no-carrier, or
+                  dormant state, and the master interface has no address.</para>
+
+                  <xi:include href="version-info.xml" xpointer="v242"/>
+                </listitem>
+              </varlistentry>
+              <varlistentry>
+                <term>carrier</term>
+                <listitem>
+                  <para>The link has carrier, or for bond or bridge master, all bonding or bridge slave
+                  network interfaces are enslaved to the master.</para>
+
+                  <xi:include href="version-info.xml" xpointer="v240"/>
+                </listitem>
+              </varlistentry>
+              <varlistentry>
+                <term>degraded</term>
+                <listitem>
+                  <para>The link has carrier and addresses valid on the local link configured. For bond or
+                  bridge master this means that not all slave network interfaces have carrier but at least
+                  one does.</para>
+
+                  <xi:include href="version-info.xml" xpointer="v240"/>
+                </listitem>
+              </varlistentry>
+              <varlistentry>
+                <term>enslaved</term>
+                <listitem>
+                  <para>The link has carrier and is enslaved to bond or bridge master network interface.
+                  </para>
+
+                  <xi:include href="version-info.xml" xpointer="v242"/>
+                </listitem>
+              </varlistentry>
+              <varlistentry>
+                <term>routable</term>
+                <listitem>
+                  <para>The link has carrier and routable address configured. For bond or bridge master it is
+                  not necessary for all slave network interfaces to have carrier, but at least one must.</para>
+
+                  <xi:include href="version-info.xml" xpointer="v240"/>
+                </listitem>
+              </varlistentry>
+            </variablelist>
+        </para>
+
+        <para>The setup status is one of the following:
+            <variablelist>
+              <varlistentry>
+                <term>pending</term>
+                <listitem>
+                  <para><citerefentry><refentrytitle>systemd-udevd</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+                  is still processing the link, we don't yet know if we will manage it.</para>
+
+                  <xi:include href="version-info.xml" xpointer="v240"/>
+                </listitem>
+              </varlistentry>
+              <varlistentry>
+                <term>initialized</term>
+                <listitem>
+                  <para><citerefentry><refentrytitle>systemd-udevd</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+                  has processed the link, but we don't yet know if we will manage it.</para>
+
+                  <xi:include href="version-info.xml" xpointer="v251"/>
+                </listitem>
+              </varlistentry>
+              <varlistentry>
+                <term>configuring</term>
+                <listitem>
+                  <para>Configuration for the link is being retrieved or the link is being configured.</para>
+
+                  <xi:include href="version-info.xml" xpointer="v240"/>
+                </listitem>
+              </varlistentry>
+              <varlistentry>
+                <term>configured</term>
+                <listitem>
+                  <para>Link has been configured successfully.</para>
+
+                  <xi:include href="version-info.xml" xpointer="v240"/>
+                </listitem>
+              </varlistentry>
+              <varlistentry>
+                <term>unmanaged</term>
+                <listitem>
+                  <para><command>systemd-networkd</command> is not handling the link.</para>
+
+                  <xi:include href="version-info.xml" xpointer="v240"/>
+                </listitem>
+              </varlistentry>
+              <varlistentry>
+                <term>failed</term>
+                <listitem>
+                  <para><command>systemd-networkd</command> failed to configure the link.</para>
+
+                  <xi:include href="version-info.xml" xpointer="v240"/>
+                </listitem>
+              </varlistentry>
+              <varlistentry>
+                <term>linger</term>
+                <listitem>
+                  <para>The link is gone, but has not yet been dropped by <command>systemd-networkd</command>.</para>
+
+                  <xi:include href="version-info.xml" xpointer="v240"/>
+                </listitem>
+              </varlistentry>
+            </variablelist>
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v219"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term>
+          <command>status</command>
+          <optional><replaceable>PATTERN…</replaceable></optional>
+        </term>
+
+        <listitem>
+          <para>Show information about the specified links: type, state, kernel module driver, hardware and
+          IP address, configured DNS servers, etc. If one or more <replaceable>PATTERN</replaceable>s are
+          specified, only links matching one of them are shown.</para>
+
+          <para>When no links are specified, an overall network status is shown. Also see the option
+          <option>--all</option>.</para>
+
+          <para>Produces output similar to:
+          <programlisting>
+●        State: routable
+  Online state: online
+       Address: 10.193.76.5 on eth0
+                192.168.122.1 on virbr0
+                169.254.190.105 on eth0
+                fe80::5054:aa:bbbb:cccc on eth0
+       Gateway: 10.193.11.1 (CISCO SYSTEMS, INC.) on eth0
+           DNS: 8.8.8.8
+                8.8.4.4</programlisting></para>
+
+          <para>In the overall network status, the online state depends on the individual online state of all
+          required links. Managed links are required for online by default. In this case, the online state is
+          one of the following:
+          <variablelist>
+            <varlistentry>
+              <term>unknown</term>
+              <listitem>
+                <para>All links have unknown online status (i.e. there are no required links).</para>
+
+                <xi:include href="version-info.xml" xpointer="v249"/>
+              </listitem>
+            </varlistentry>
+            <varlistentry>
+              <term>offline</term>
+              <listitem>
+                <para>All required links are offline.</para>
+
+                <xi:include href="version-info.xml" xpointer="v249"/>
+              </listitem>
+            </varlistentry>
+            <varlistentry>
+              <term>partial</term>
+              <listitem>
+                <para>Some, but not all, required links are online.</para>
+
+                <xi:include href="version-info.xml" xpointer="v249"/>
+              </listitem>
+            </varlistentry>
+            <varlistentry>
+              <term>online</term>
+              <listitem>
+                <para>All required links are online.</para>
+
+                <xi:include href="version-info.xml" xpointer="v249"/>
+              </listitem>
+            </varlistentry>
+          </variablelist>
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v219"/>
+        </listitem>
+
+      </varlistentry>
+
+      <varlistentry>
+        <term>
+          <command>lldp</command>
+          <optional><replaceable>PATTERN…</replaceable></optional>
+        </term>
+
+        <listitem>
+          <para>Show discovered LLDP (Link Layer Discovery Protocol) neighbors. If one or more
+          <replaceable>PATTERN</replaceable>s are specified only neighbors on those interfaces are shown.
+          Otherwise shows discovered neighbors on all interfaces. Note that for this feature to work,
+          <varname>LLDP=</varname> must be turned on for the specific interface, see
+          <citerefentry><refentrytitle>systemd.network</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
+          details.</para>
+
+          <para>Produces output similar to:
+          <programlisting>LINK             CHASSIS ID        SYSTEM NAME      CAPS        PORT ID           PORT DESCRIPTION
+enp0s25          00:e0:4c:00:00:00 GS1900           ..b........ 2                 Port #2
+
+Capability Flags:
+o - Other; p - Repeater;  b - Bridge; w - WLAN Access Point; r - Router;
+t - Telephone; d - DOCSIS cable device; a - Station; c - Customer VLAN;
+s - Service VLAN, m - Two-port MAC Relay (TPMR)
+
+1 neighbors listed.</programlisting></para>
+
+          <xi:include href="version-info.xml" xpointer="v219"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term>
+          <command>label</command>
+        </term>
+
+        <listitem><para>Show numerical address labels that can be used for address selection.
+        This is the same information that
+        <citerefentry project='die-net'><refentrytitle>ip-addrlabel</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        shows. See <ulink url="https://tools.ietf.org/html/rfc3484">RFC 3484</ulink>
+        for a discussion of address labels.</para>
+
+        <para>Produces output similar to:
+        <programlisting>Prefix/Prefixlen                          Label
+        ::/0                                  1
+    fc00::/7                                  5
+    fec0::/10                                11
+    2002::/16                                 2
+    3ffe::/16                                12
+ 2001:10::/28                                 7
+    2001::/32                                 6
+::ffff:0.0.0.0/96                             4
+        ::/96                                 3
+       ::1/128                                0</programlisting></para>
+
+        <xi:include href="version-info.xml" xpointer="v234"/>
+        </listitem>
+      </varlistentry>
+
+       <varlistentry>
+        <term>
+          <command>delete</command>
+          <replaceable>DEVICE…</replaceable>
+        </term>
+        <listitem><para>Deletes virtual netdevs. Takes interface name or index number.</para>
+
+        <xi:include href="version-info.xml" xpointer="v243"/></listitem>
+      </varlistentry>
+
+       <varlistentry>
+        <term>
+          <command>up</command>
+          <replaceable>DEVICE…</replaceable>
+        </term>
+        <listitem><para>Bring devices up. Takes interface name or index number.</para>
+
+        <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+      </varlistentry>
+
+       <varlistentry>
+        <term>
+          <command>down</command>
+          <replaceable>DEVICE…</replaceable>
+        </term>
+        <listitem><para>Bring devices down. Takes interface name or index number.</para>
+
+        <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+      </varlistentry>
+
+       <varlistentry>
+        <term>
+          <command>renew</command>
+          <replaceable>DEVICE…</replaceable>
+        </term>
+        <listitem><para>Renew dynamic configurations e.g. addresses received from DHCP server.
+        Takes interface name or index number.</para>
+
+        <xi:include href="version-info.xml" xpointer="v244"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term>
+          <command>forcerenew</command>
+          <replaceable>DEVICE…</replaceable>
+        </term>
+        <listitem><para>Send a FORCERENEW message to all connected clients, triggering DHCP reconfiguration.
+        Takes interface name or index number.</para>
+
+        <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term>
+          <command>reconfigure</command>
+          <replaceable>DEVICE…</replaceable>
+        </term>
+        <listitem><para>Reconfigure network interfaces. Takes interface name or index number. Note that
+        this does not reload <filename>.netdev</filename> or <filename>.network</filename>
+        corresponding to the specified interface. So, if you edit config files, it is necessary to call
+        <command>networkctl reload</command> first to apply new settings.</para>
+
+        <xi:include href="version-info.xml" xpointer="v244"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term>
+          <command>reload</command>
+        </term>
+        <listitem><para>Reload <filename>.netdev</filename> and <filename>.network</filename> files.
+        If a new <filename>.netdev</filename> file is found, then the corresponding netdev is created.
+        Note that even if an existing <filename>.netdev</filename> is modified or removed,
+        <command>systemd-networkd</command> does not update or remove the netdev.
+        If a new, modified or removed <filename>.network</filename> file is found, then all interfaces
+        which match the file are reconfigured.</para>
+
+        <xi:include href="version-info.xml" xpointer="v244"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term>
+          <command>edit</command>
+          <replaceable>FILE</replaceable>|<replaceable>@DEVICE</replaceable>…
+        </term>
+        <listitem><para>Edit network configuration files, which include <filename>.network</filename>,
+        <filename>.netdev</filename>, and <filename>.link</filename> files. If no network config file
+        matching the given name is found, a new one will be created under <filename>/etc/</filename>.
+        Specially, if the name is prefixed by <literal>@</literal>, it will be treated as
+        a network interface, and editing will be performed on the network config files associated
+        with it. Additionally, the interface name can be suffixed with <literal>:network</literal> (default)
+        or <literal>:link</literal>, in order to choose the type of network config to operate on.</para>
+
+        <para>If <option>--drop-in=</option> is specified, edit the drop-in file instead of
+        the main configuration file. Unless <option>--no-reload</option> is specified,
+        <command>systemd-networkd</command> will be reloaded after the edit of the
+        <filename>.network</filename> or <filename>.netdev</filename> files finishes.
+        The same applies for <filename>.link</filename> files and
+        <citerefentry><refentrytitle>systemd-udevd</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+        Note that the changed link settings are not automatically applied after reloading.
+        To achieve that, trigger uevents for the corresponding interface. Refer to
+        <citerefentry><refentrytitle>systemd.link</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for more information.</para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term>
+          <command>cat</command>
+          <replaceable>FILE</replaceable>|<replaceable>@DEVICE</replaceable>…
+        </term>
+        <listitem><para>Show network configuration files. This command honors
+        the <literal>@</literal> prefix in the same way as <command>edit</command>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>The following options are understood:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term>
+          <option>-a</option>
+          <option>--all</option>
+        </term>
+
+        <listitem>
+          <para>Show all links with <command>status</command>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v219"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term>
+          <option>-s</option>
+          <option>--stats</option>
+        </term>
+
+        <listitem>
+          <para>Show link statistics with <command>status</command>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v243"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-l</option></term>
+        <term><option>--full</option></term>
+
+        <listitem>
+          <para>Do not ellipsize the output.</para>
+
+          <xi:include href="version-info.xml" xpointer="v245"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-n</option></term>
+        <term><option>--lines=</option></term>
+
+        <listitem>
+          <para>When used with <command>status</command>, controls the number of journal lines to show,
+          counting from the most recent ones. Takes a positive integer argument. Defaults to 10.</para>
+
+          <xi:include href="version-info.xml" xpointer="v245"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--drop-in=</option><replaceable>NAME</replaceable></term>
+
+        <listitem>
+          <para>When used with <command>edit</command>, edit the drop-in file <replaceable>NAME</replaceable>
+          instead of the main configuration file.</para>
+
+          <xi:include href="version-info.xml" xpointer="v254"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--no-reload</option></term>
+
+        <listitem>
+          <para>When used with <command>edit</command>,
+          <citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+          or
+          <citerefentry><refentrytitle>systemd-udevd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+          will not be reloaded after the editing finishes.</para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/>
+        </listitem>
+      </varlistentry>
+
+      <xi:include href="standard-options.xml" xpointer="json" />
+      <xi:include href="standard-options.xml" xpointer="help" />
+      <xi:include href="standard-options.xml" xpointer="version" />
+      <xi:include href="standard-options.xml" xpointer="no-legend" />
+      <xi:include href="standard-options.xml" xpointer="no-pager" />
+
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Exit status</title>
+
+    <para>On success, 0 is returned, a non-zero failure code otherwise.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.network</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.netdev</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry project='die-net'><refentrytitle>ip</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+</refentry>
diff --git a/man/networkd.conf.xml b/man/networkd.conf.xml
new file mode 100644
index 0000000..018bde0
--- /dev/null
+++ b/man/networkd.conf.xml
@@ -0,0 +1,256 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+
+<!--
+  SPDX-License-Identifier: LGPL-2.1-or-later
+
+  Copyright © 2014 Vinay Kulkarni
+-->
+
+<refentry id="networkd.conf" conditional='ENABLE_NETWORKD'
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+  <refentryinfo>
+    <title>networkd.conf</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>networkd.conf</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>networkd.conf</refname>
+    <refname>networkd.conf.d</refname>
+    <refpurpose>Global Network configuration files</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>/etc/systemd/networkd.conf</filename></para>
+    <para><filename>/etc/systemd/networkd.conf.d/*.conf</filename></para>
+    <para><filename>/usr/lib/systemd/networkd.conf.d/*.conf</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>These configuration files control global network parameters.
+    Currently the DHCP Unique Identifier (DUID).</para>
+
+  </refsect1>
+
+  <xi:include href="standard-conf.xml" xpointer="main-conf" />
+
+  <refsect1>
+    <title>[Network] Section Options</title>
+
+    <para>The following options are available in the [Network] section:</para>
+
+    <variablelist class='network-directives'>
+      <varlistentry>
+        <term><varname>SpeedMeter=</varname></term>
+        <listitem><para>Takes a boolean. If set to yes, then <command>systemd-networkd</command>
+        measures the traffic of each interface, and
+        <command>networkctl status <replaceable>INTERFACE</replaceable></command> shows the measured speed.
+        Defaults to no.</para>
+
+        <xi:include href="version-info.xml" xpointer="v244"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SpeedMeterIntervalSec=</varname></term>
+        <listitem><para>Specifies the time interval to calculate the traffic speed of each interface.
+        If <varname>SpeedMeter=no</varname>, the value is ignored. Defaults to 10sec.</para>
+
+        <xi:include href="version-info.xml" xpointer="v244"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ManageForeignRoutingPolicyRules=</varname></term>
+        <listitem><para>A boolean. When true, <command>systemd-networkd</command> will remove rules
+        that are not configured in .network files (except for rules with protocol
+        <literal>kernel</literal>). When false, it will not remove any foreign rules, keeping them even
+        if they are not configured in a .network file. Defaults to yes.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v249"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ManageForeignRoutes=</varname></term>
+        <listitem><para>A boolean. When true, <command>systemd-networkd</command> will remove routes
+        that are not configured in .network files (except for routes with protocol
+        <literal>kernel</literal>, <literal>dhcp</literal> when <varname>KeepConfiguration=</varname>
+        is true or <literal>dhcp</literal>, and <literal>static</literal> when
+        <varname>KeepConfiguration=</varname> is true or <literal>static</literal>). When false, it will
+        not remove any foreign routes, keeping them even if they are not configured in a .network file.
+        Defaults to yes.</para>
+
+        <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RouteTable=</varname></term>
+        <listitem><para>Defines the route table name. Takes a whitespace-separated list of the pairs of
+        route table name and number. The route table name and number in each pair are separated with a
+        colon, i.e., <literal><replaceable>name</replaceable>:<replaceable>number</replaceable></literal>.
+        The route table name must not be <literal>default</literal>, <literal>main</literal>, or
+        <literal>local</literal>, as these route table names are predefined with route table number 253,
+        254, and 255, respectively. The route table number must be an integer in the range 1…4294967295,
+        except for predefined numbers 253, 254, and 255. This setting can be specified multiple times.
+        If an empty string is specified, then the list specified earlier are cleared. Defaults to unset.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v248"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>IPv6PrivacyExtensions=</varname></term>
+        <listitem>
+          <para>Specifies the default value for per-network <varname>IPv6PrivacyExtensions=</varname>.
+          Takes a boolean or the special values <literal>prefer-public</literal> and
+          <literal>kernel</literal>. See for details in
+          <citerefentry><refentrytitle>systemd.network</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+          Defaults to <literal>no</literal>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[DHCPv4] Section Options</title>
+
+    <para>This section configures the DHCP Unique Identifier (DUID) value used by DHCP protocol. DHCPv4
+    client protocol sends IAID and DUID to the DHCP server when acquiring a dynamic IPv4 address if
+    <option>ClientIdentifier=duid</option>. IAID and DUID allows a DHCP server to uniquely identify the
+    machine and the interface requesting a DHCP IP address. To configure IAID and ClientIdentifier, see
+    <citerefentry><refentrytitle>systemd.network</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+    </para>
+
+    <para>The following options are understood:</para>
+
+    <variablelist class='network-directives'>
+      <varlistentry>
+        <term><varname>DUIDType=</varname></term>
+        <listitem><para>Specifies how the DUID should be generated. See
+        <ulink url="https://tools.ietf.org/html/rfc3315#section-9">RFC 3315</ulink>
+        for a description of all the options.</para>
+
+        <para>This takes an integer in the range 0…65535, or one of the following string values:
+        <variablelist>
+          <varlistentry>
+            <term><option>vendor</option></term>
+            <listitem><para>If <literal>DUIDType=vendor</literal>, then the DUID value will be generated using
+            <literal>43793</literal> as the vendor identifier (systemd) and hashed contents of
+            <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+            This is the default if <varname>DUIDType=</varname> is not specified.
+            </para>
+
+            <xi:include href="version-info.xml" xpointer="v230"/></listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><option>uuid</option></term>
+            <listitem><para>If <literal>DUIDType=uuid</literal>, and <varname>DUIDRawData=</varname> is not set,
+            then the product UUID is used as a DUID value. If a system does not have valid product UUID, then
+            an application-specific
+            <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+            is used as a DUID value. About the application-specific machine ID, see
+            <citerefentry><refentrytitle>sd_id128_get_machine_app_specific</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+            </para>
+
+            <xi:include href="version-info.xml" xpointer="v230"/></listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><option>link-layer-time[:<replaceable>TIME</replaceable>]</option></term>
+            <term><option>link-layer</option></term>
+            <listitem><para>If <literal>link-layer-time</literal> or <literal>link-layer</literal> is specified,
+            then the MAC address of the interface is used as a DUID value. The value <literal>link-layer-time</literal>
+            can take additional time value after a colon, e.g. <literal>link-layer-time:2018-01-23 12:34:56 UTC</literal>.
+            The default time value is <literal>2000-01-01 00:00:00 UTC</literal>.
+            </para>
+
+            <xi:include href="version-info.xml" xpointer="v240"/></listitem>
+          </varlistentry>
+        </variablelist>
+        </para>
+
+        <para>In all cases, <varname>DUIDRawData=</varname> can be used to override the
+        actual DUID value that is used.</para>
+
+        <xi:include href="version-info.xml" xpointer="v230"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>DUIDRawData=</varname></term>
+        <listitem><para>Specifies the DHCP DUID value as a single newline-terminated, hexadecimal string, with each
+        byte separated by <literal>:</literal>. The DUID that is sent is composed of the DUID type specified by
+        <varname>DUIDType=</varname> and the value configured here.</para>
+
+        <para>The DUID value specified here overrides the DUID that
+        <citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        generates from the machine ID. To configure DUID per-network, see
+        <citerefentry><refentrytitle>systemd.network</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+        The configured DHCP DUID should conform to the specification in
+        <ulink url="http://tools.ietf.org/html/rfc3315#section-9">RFC 3315</ulink>,
+        <ulink url="http://tools.ietf.org/html/rfc6355">RFC 6355</ulink>. To configure IAID, see
+        <citerefentry><refentrytitle>systemd.network</refentrytitle><manvolnum>5</manvolnum>
+        </citerefentry>.</para>
+
+        <example>
+          <title>A <option>DUIDType=vendor</option> with a custom value</title>
+
+          <programlisting>DUIDType=vendor
+DUIDRawData=00:00:ab:11:f9:2a:c2:77:29:f9:5c:00</programlisting>
+
+          <para>This specifies a 14 byte DUID, with the type DUID-EN (<literal>00:02</literal>), enterprise number
+          43793 (<literal>00:00:ab:11</literal>), and identifier value <literal>f9:2a:c2:77:29:f9:5c:00</literal>.
+          </para>
+        </example>
+
+          <xi:include href="version-info.xml" xpointer="v230"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[DHCPv6] Section Options</title>
+
+    <para>This section configures the DHCP Unique Identifier (DUID) value used by DHCPv6 protocol.
+    DHCPv6 client protocol sends the DHCP Unique Identifier and the interface Identity Association
+    Identifier (IAID) to a DHCPv6 server when acquiring a dynamic IPv6 address. IAID and DUID allows a
+    DHCPv6 server to uniquely identify the machine and the interface requesting a DHCP IP address. To
+    configure IAID, see
+    <citerefentry><refentrytitle>systemd.network</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+    </para>
+
+    <para>The following options are understood:</para>
+
+    <variablelist class='network-directives'>
+      <varlistentry>
+        <term><varname>DUIDType=</varname></term>
+        <term><varname>DUIDRawData=</varname></term>
+        <listitem><para>As in the [DHCPv4] section.</para>
+
+        <xi:include href="version-info.xml" xpointer="v249"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+      <title>See Also</title>
+      <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.network</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_id128_get_machine_app_specific</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+      </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/nss-myhostname.xml b/man/nss-myhostname.xml
new file mode 100644
index 0000000..360e6d7
--- /dev/null
+++ b/man/nss-myhostname.xml
@@ -0,0 +1,139 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="nss-myhostname" conditional='ENABLE_NSS_MYHOSTNAME'>
+
+  <refentryinfo>
+    <title>nss-myhostname</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>nss-myhostname</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>nss-myhostname</refname>
+    <refname>libnss_myhostname.so.2</refname>
+    <refpurpose>Hostname resolution for the locally configured system hostname</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>libnss_myhostname.so.2</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>nss-myhostname</command> is a plug-in module for the GNU Name Service Switch (NSS) functionality of
+    the GNU C Library (<command>glibc</command>), primarily providing hostname resolution for the locally configured
+    system hostname as returned by
+    <citerefentry><refentrytitle>gethostname</refentrytitle><manvolnum>2</manvolnum></citerefentry>.  The precise
+    hostnames resolved by this module are:</para>
+
+    <itemizedlist>
+      <listitem><para>The local, configured hostname is resolved to
+      all locally configured IP addresses ordered by their scope, or
+      — if none are configured — the IPv4 address 127.0.0.2 (which
+      is on the local loopback) and the IPv6 address ::1 (which is the
+      local host).</para></listitem>
+
+      <listitem><para>The hostnames <literal>localhost</literal> and
+      <literal>localhost.localdomain</literal> (as well as any hostname
+      ending in <literal>.localhost</literal> or <literal>.localhost.localdomain</literal>)
+      are resolved to the IP addresses 127.0.0.1 and ::1.</para></listitem>
+
+      <listitem><para>The hostname <literal>_gateway</literal> is
+      resolved to all current default routing gateway addresses,
+      ordered by their metric. This assigns a stable hostname to the
+      current gateway, useful for referencing it independently of the
+      current network configuration state.</para></listitem>
+
+      <listitem><para>The hostname <literal>_outbound</literal> is resolved to the local IPv4 and IPv6
+      addresses that are most likely used for communication with other hosts. This is determined by
+      requesting a routing decision to the configured default gateways from the kernel and then using the
+      local IP addresses selected by this decision. This hostname is only available if there is at least one
+      local default gateway configured. This assigns a stable hostname to the local outbound IP addresses,
+      useful for referencing them independently of the current network configuration state.</para></listitem>
+    </itemizedlist>
+
+    <para>Various software relies on an always-resolvable local
+    hostname. When using dynamic hostnames, this is traditionally
+    achieved by patching <filename>/etc/hosts</filename> at the same
+    time as changing the hostname. This is problematic since it
+    requires a writable <filename>/etc/</filename> file system and is
+    fragile because the file might be edited by the administrator at
+    the same time. With <command>nss-myhostname</command> enabled,
+    changing <filename>/etc/hosts</filename> is unnecessary, and on
+    many systems, the file becomes entirely optional.</para>
+
+    <para>To activate the NSS modules, add <literal>myhostname</literal> to the line starting with
+    <literal>hosts:</literal> in <filename>/etc/nsswitch.conf</filename>.</para>
+
+    <para>It is recommended to place <literal>myhostname</literal> after <literal>file</literal> and before <literal>dns</literal>.
+    This resolves well-known hostnames like <literal>localhost</literal>
+    and the machine hostnames locally. It is consistent with the behaviour
+    of <command>nss-resolve</command>, and still allows overriding via
+    <filename>/etc/hosts</filename>.</para>
+
+    <para>Please keep in mind that <command>nss-myhostname</command> (and <command>nss-resolve</command>) also resolve
+    in the other direction — from locally attached IP addresses to
+    hostnames. If you rely on that lookup being provided by DNS, you might
+    want to order things differently.
+    </para>
+  </refsect1>
+
+  <refsect1>
+    <title>Example</title>
+
+    <para>Here is an example <filename>/etc/nsswitch.conf</filename> file that enables
+    <command>nss-myhostname</command> correctly:</para>
+
+    <!-- synchronize with other nss-* man pages and factory/etc/nsswitch.conf -->
+<programlisting>passwd:         files systemd
+group:          files [SUCCESS=merge] systemd
+shadow:         files systemd
+gshadow:        files systemd
+
+hosts:          mymachines resolve [!UNAVAIL=return] files <command>myhostname</command> dns
+networks:       files
+
+protocols:      db files
+services:       db files
+ethers:         db files
+rpc:            db files
+
+netgroup:       nis</programlisting>
+
+    <para>To test, use <command>glibc</command>'s
+    <citerefentry project='man-pages'><refentrytitle>getent</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    tool:</para>
+
+    <programlisting>$ getent ahosts `hostname`
+::1       STREAM omega
+::1       DGRAM
+::1       RAW
+127.0.0.2       STREAM
+127.0.0.2       DGRAM
+127.0.0.2       RAW</programlisting>
+
+    <para>In this case, the local hostname is <varname>omega</varname>.</para>
+
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>nss-systemd</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>nss-resolve</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>nss-mymachines</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>nsswitch.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>getent</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/nss-mymachines.xml b/man/nss-mymachines.xml
new file mode 100644
index 0000000..717ecc5
--- /dev/null
+++ b/man/nss-mymachines.xml
@@ -0,0 +1,137 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="nss-mymachines" conditional='ENABLE_NSS_MYMACHINES'>
+
+  <refentryinfo>
+    <title>nss-mymachines</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>nss-mymachines</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>nss-mymachines</refname>
+    <refname>libnss_mymachines.so.2</refname>
+    <refpurpose>Hostname resolution for local container instances</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>libnss_mymachines.so.2</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>nss-mymachines</command> is a plug-in module for the GNU Name Service Switch (NSS) functionality of
+    the GNU C Library (<command>glibc</command>), providing hostname resolution for the names of containers running
+    locally that are registered with
+    <citerefentry><refentrytitle>systemd-machined.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>. The
+    container names are resolved to the IP addresses of the specific container, ordered by their scope. This
+    functionality only applies to containers using network namespacing (see the description of
+    <option>--private-network</option> in
+    <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>).
+    Note that the name that is resolved is the one registered with <command>systemd-machined</command>, which
+    may be different than the hostname configured inside of the container.</para>
+
+    <para>Note that this NSS module only makes available names of the containers running immediately below
+    the current system context. It does not provide host name resolution for containers running side-by-side
+    with the invoking system context, or containers further up or down the container hierarchy. Or in other
+    words, on the host system it provides host name resolution for the containers running immediately below
+    the host environment. When used inside a container environment however, it will not be able to provide
+    name resolution for containers running on the host (as those are siblings and not children of the current
+    container environment), but instead only for nested containers running immediately below its own
+    container environment.</para>
+
+    <para>To activate the NSS module, add <literal>mymachines</literal> to the line starting with
+    <literal>hosts:</literal> in <filename>/etc/nsswitch.conf</filename>.</para>
+
+    <para>It is recommended to place <literal>mymachines</literal> before the <literal>resolve</literal> or
+    <literal>dns</literal> entry of the <literal>hosts:</literal> line of
+    <filename>/etc/nsswitch.conf</filename> in order to make sure that its mappings are preferred over other
+    resolvers such as DNS.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Configuration in <filename>/etc/nsswitch.conf</filename></title>
+
+    <para>Here is an example <filename>/etc/nsswitch.conf</filename> file that enables
+    <command>nss-mymachines</command> correctly:</para>
+
+    <!-- synchronize with other nss-* man pages and factory/etc/nsswitch.conf -->
+    <programlisting>passwd:         files systemd
+group:          files [SUCCESS=merge] systemd
+shadow:         files systemd
+gshadow:        files systemd
+
+hosts:          <command>mymachines</command> resolve [!UNAVAIL=return] files myhostname dns
+networks:       files
+
+protocols:      db files
+services:       db files
+ethers:         db files
+rpc:            db files
+
+netgroup:       nis</programlisting>
+
+  </refsect1>
+
+  <refsect1>
+    <title>Example: Mappings provided by <filename>nss-mymachines</filename></title>
+
+    <para>The container <literal>rawhide</literal> is spawned using
+    <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>:
+    </para>
+
+    <programlisting># systemd-nspawn -M rawhide --boot --network-veth --private-users=pick
+Spawning container rawhide on /var/lib/machines/rawhide.
+Selected user namespace base 20119552 and range 65536.
+...
+
+$ machinectl --max-addresses=3
+MACHINE CLASS     SERVICE        OS     VERSION ADDRESSES
+rawhide container systemd-nspawn fedora 30      169.254.40.164 fe80::94aa:3aff:fe7b:d4b9
+
+$ ping -c1 rawhide
+PING rawhide(fe80::94aa:3aff:fe7b:d4b9%ve-rawhide (fe80::94aa:3aff:fe7b:d4b9%ve-rawhide)) 56 data bytes
+64 bytes from fe80::94aa:3aff:fe7b:d4b9%ve-rawhide (fe80::94aa:3aff:fe7b:d4b9%ve-rawhide): icmp_seq=1 ttl=64 time=0.045 ms
+...
+$ ping -c1 -4 rawhide
+PING rawhide (169.254.40.164) 56(84) bytes of data.
+64 bytes from 169.254.40.164 (169.254.40.164): icmp_seq=1 ttl=64 time=0.064 ms
+...
+
+# machinectl shell rawhide /sbin/ip a
+Connected to machine rawhide. Press ^] three times within 1s to exit session.
+1: lo: &lt;LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
+    ...
+2: host0@if21: &lt;BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
+    link/ether 96:aa:3a:7b:d4:b9 brd ff:ff:ff:ff:ff:ff link-netnsid 0
+    inet 169.254.40.164/16 brd 169.254.255.255 scope link host0
+       valid_lft forever preferred_lft forever
+    inet6 fe80::94aa:3aff:fe7b:d4b9/64 scope link
+       valid_lft forever preferred_lft forever
+Connection to machine rawhide terminated.
+</programlisting>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-machined.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>machinectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>nss-systemd</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>nss-resolve</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>nss-myhostname</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>nsswitch.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>getent</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/nss-resolve.xml b/man/nss-resolve.xml
new file mode 100644
index 0000000..d633be2
--- /dev/null
+++ b/man/nss-resolve.xml
@@ -0,0 +1,182 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="nss-resolve" conditional='ENABLE_NSS_RESOLVE'
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>nss-resolve</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>nss-resolve</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>nss-resolve</refname>
+    <refname>libnss_resolve.so.2</refname>
+    <refpurpose>Hostname resolution via <filename>systemd-resolved.service</filename></refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>libnss_resolve.so.2</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>nss-resolve</command> is a plug-in module for the GNU Name Service Switch (NSS) functionality of the
+    GNU C Library (<command>glibc</command>) enabling it to resolve hostnames via the
+    <citerefentry><refentrytitle>systemd-resolved</refentrytitle><manvolnum>8</manvolnum></citerefentry> local network
+    name resolution service. It replaces the <command>nss-dns</command> plug-in module that traditionally resolves
+    hostnames via DNS.</para>
+
+    <para>To activate the NSS module, add <literal>resolve [!UNAVAIL=return]</literal> to the line starting
+    with <literal>hosts:</literal> in <filename>/etc/nsswitch.conf</filename>. Specifically, it is
+    recommended to place <literal>resolve</literal> early in <filename>/etc/nsswitch.conf</filename>'s
+    <literal>hosts:</literal> line. It should be before the <literal>files</literal> entry, since
+    <filename>systemd-resolved</filename> supports <filename>/etc/hosts</filename> internally, but with
+    caching. To the contrary, it should be after <literal>mymachines</literal>, to give hostnames given to
+    local VMs and containers precedence over names received over DNS. Finally, we recommend placing
+    <literal>dns</literal> somewhere after <literal>resolve</literal>, to fall back to
+    <command>nss-dns</command> if <filename>systemd-resolved.service</filename> is not available.</para>
+
+    <para>Note that <command>systemd-resolved</command> will synthesize DNS resource records in a few cases,
+    for example for <literal>localhost</literal> and the current local hostname, see
+    <citerefentry><refentrytitle>systemd-resolved</refentrytitle><manvolnum>8</manvolnum></citerefentry> for
+    the full list. This duplicates the functionality of
+    <citerefentry><refentrytitle>nss-myhostname</refentrytitle><manvolnum>8</manvolnum></citerefentry>, but
+    it is still recommended (see examples below) to keep <command>nss-myhostname</command> configured in
+    <filename>/etc/nsswitch.conf</filename>, to keep those names resolveable if
+    <command>systemd-resolved</command> is not running.</para>
+
+    <para>Please keep in mind that <command>nss-myhostname</command> (and <command>nss-resolve</command>) also resolve
+    in the other direction — from locally attached IP addresses to
+    hostnames. If you rely on that lookup being provided by DNS, you might
+    want to order things differently.
+    </para>
+
+    <para>Communication between <command>nss-resolve</command> and
+    <filename>systemd-resolved.service</filename> takes place via the
+    <filename>/run/systemd/resolve/io.systemd.Resolve</filename> <constant>AF_UNIX</constant> socket.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Environment variables</title>
+
+    <variablelist class='environment-variables'>
+      <varlistentry>
+        <term><varname>$SYSTEMD_NSS_RESOLVE_VALIDATE</varname></term>
+
+        <listitem><para>Takes a boolean argument. When false, cryptographic validation of resource records
+        via DNSSEC will be disabled. This may be useful for testing, or when system time is known to be
+        unreliable.</para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+    </variablelist>
+
+    <variablelist class='environment-variables'>
+      <varlistentry>
+        <term><varname>$SYSTEMD_NSS_RESOLVE_SYNTHESIZE</varname></term>
+
+        <listitem><para>Takes a boolean argument. When false, synthetic records, e.g. for the local host
+        name, will not be returned. See section SYNTHETIC RECORDS in
+        <citerefentry><refentrytitle>systemd-resolved.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        for more information. This may be useful to query the "public" resource records, independent of the
+        configuration of the local machine.</para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+    </variablelist>
+
+    <variablelist class='environment-variables'>
+      <varlistentry>
+        <term><varname>$SYSTEMD_NSS_RESOLVE_CACHE</varname></term>
+
+        <listitem><para>Takes a boolean argument. When false, the cache of previously queried records will
+        not be used by
+        <citerefentry><refentrytitle>systemd-resolved</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+    </variablelist>
+
+    <variablelist class='environment-variables'>
+      <varlistentry>
+        <term><varname>$SYSTEMD_NSS_RESOLVE_ZONE</varname></term>
+
+        <listitem><para>Takes a boolean argument. When false, answers using locally registered public
+        LLMNR/mDNS resource records will not be returned.</para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+    </variablelist>
+
+    <variablelist class='environment-variables'>
+      <varlistentry>
+        <term><varname>$SYSTEMD_NSS_RESOLVE_TRUST_ANCHOR</varname></term>
+
+        <listitem><para>Takes a boolean argument. When false, answers using locally configured trust anchors
+        will not be used.</para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+    </variablelist>
+
+    <variablelist class='environment-variables'>
+      <varlistentry>
+        <term><varname>$SYSTEMD_NSS_RESOLVE_NETWORK</varname></term>
+
+        <listitem><para>Takes a boolean argument. When false, answers will be returned without using the
+        network, i.e. either from local sources or the cache in
+        <citerefentry><refentrytitle>systemd-resolved</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Example</title>
+
+    <para>Here is an example <filename>/etc/nsswitch.conf</filename> file that enables
+    <command>nss-resolve</command> correctly:</para>
+
+    <!-- synchronize with other nss-* man pages and factory/etc/nsswitch.conf -->
+<programlisting>passwd:         files systemd
+group:          files [SUCCESS=merge] systemd
+shadow:         files systemd
+gshadow:        files systemd
+
+hosts:          mymachines <command>resolve [!UNAVAIL=return]</command> files myhostname dns
+networks:       files
+
+protocols:      db files
+services:       db files
+ethers:         db files
+rpc:            db files
+
+netgroup:       nis</programlisting>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-resolved</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>nss-systemd</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>nss-myhostname</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>nss-mymachines</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>nsswitch.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.syntax</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/nss-systemd.xml b/man/nss-systemd.xml
new file mode 100644
index 0000000..bc975c0
--- /dev/null
+++ b/man/nss-systemd.xml
@@ -0,0 +1,183 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="nss-systemd" conditional='ENABLE_NSS_SYSTEMD'>
+
+  <refentryinfo>
+    <title>nss-systemd</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>nss-systemd</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>nss-systemd</refname>
+    <refname>libnss_systemd.so.2</refname>
+    <refpurpose>UNIX user and group name resolution for user/group lookup via Varlink</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>libnss_systemd.so.2</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>nss-systemd</command> is a plug-in module for the GNU Name Service Switch (NSS)
+    functionality of the GNU C Library (<command>glibc</command>), providing UNIX user and group name
+    resolution for services implementing the <ulink url="https://systemd.io/USER_GROUP_API">User/Group Record
+    Lookup API via Varlink</ulink>, such as the system and service manager
+    <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> (for its
+    <varname>DynamicUser=</varname> feature, see
+    <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
+    details),
+    <citerefentry><refentrytitle>systemd-homed.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, or <citerefentry><refentrytitle>systemd-machined.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
+
+    <para>This module also ensures that the root and nobody users and groups (i.e. the users/groups with the UIDs/GIDs
+    0 and 65534) remain resolvable at all times, even if they aren't listed in <filename>/etc/passwd</filename> or
+    <filename>/etc/group</filename>, or if these files are missing.</para>
+
+    <para>This module preferably utilizes
+    <citerefentry><refentrytitle>systemd-userdbd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    for resolving users and groups, but also works without the service running.</para>
+
+    <para>To activate the NSS module, add <literal>systemd</literal> to the lines starting with
+    <literal>passwd:</literal>, <literal>group:</literal>, <literal>shadow:</literal> and
+    <literal>gshadow:</literal> in <filename>/etc/nsswitch.conf</filename>.</para>
+
+    <para>It is recommended to place <literal>systemd</literal> after the <literal>files</literal> entry of
+    the <filename>/etc/nsswitch.conf</filename> lines so that <filename>/etc/passwd</filename>,
+    <filename>/etc/group</filename>, <filename>/etc/shadow</filename> and <filename>/etc/gshadow</filename>
+    based mappings take precedence.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Static Drop-In JSON User/Group Records</title>
+
+    <para>Besides user/group records acquired via the aforementioned Varlink IPC interfaces and the
+    synthesized root and nobody accounts, this module also makes user and group accounts available to the
+    system that are defined in static drop-in files in the <filename>/etc/userdb/</filename>,
+    <filename>/run/userdb/</filename>, <filename>/run/host/userdb/</filename> and
+    <filename>/usr/lib/userdb/</filename> directories.</para>
+
+    <para>This is a simple mechanism to provide static user and group records via JSON drop-in files. Such
+    user records should be defined in the format described by the <ulink
+    url="https://systemd.io/USER_RECORD">JSON User Records</ulink> specification and be placed in one of the
+    aforementioned directories under a file name composed of the user name suffixed with
+    <filename>.user</filename>, with a world-readable access mode. A symlink named after the user record's
+    UID formatted in decimal and suffixed with <filename>.user</filename> pointing to the primary record file
+    should be created as well, in order to allow both lookups by username and by UID. Privileged user record
+    data (e.g. hashed UNIX passwords) may optionally be provided as well, in a pair of separate companion
+    files with the <filename>.user-privileged</filename> suffix. The data should be stored in a regular file
+    named after the user name, suffixed with <filename>.user-privileged</filename>, and a symlink pointing to
+    it, named after the used numeric UID formatted in decimal with the same suffix. These companion files
+    should not be readable to anyone but root. Example:</para>
+
+    <programlisting>-rw-r--r--. 1 root root  723 May 10 foobar.user
+-rw-------. 1 root root  123 May 10 foobar.user-privileged
+lrwxrwxrwx. 1 root root   19 May 10 4711.user -> foobar.user
+lrwxrwxrwx. 1 root root   19 May 10 4711.user-privileged -> foobar.user-privileged</programlisting>
+
+    <para>Similarly, group records following the format described in <ulink
+    url="https://systemd.io/GROUP_RECORD">JSON Group Record</ulink> may be defined, using the file suffixes
+    <filename>.group</filename> and <filename>.group-privileged</filename>.</para>
+
+    <para>The primary user/group record files (i.e. those with the <filename>.user</filename> and
+    <filename>.group</filename> suffixes) should not contain the <literal>privileged</literal> section as
+    described in the specifications. The privileged user/group record files (i.e. those with the
+    <filename>.user-privileged</filename> and <filename>.group-privileged</filename> suffixes) should
+    contain this section, exclusively.</para>
+
+    <para>Note that static user/group records generally do not override conflicting records in
+    <filename>/etc/passwd</filename> or <filename>/etc/group</filename> or other account databases. In fact,
+    before dropping in these files a reasonable level of care should be taken to avoid user/group name and
+    UID/GID conflicts.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Configuration in <filename>/etc/nsswitch.conf</filename></title>
+
+    <para>Here is an example <filename>/etc/nsswitch.conf</filename> file that enables
+    <command>nss-systemd</command> correctly:</para>
+
+    <!-- synchronize with other nss-* man pages and factory/etc/nsswitch.conf -->
+    <programlisting>passwd:         files <command>systemd</command>
+group:          files <command>[SUCCESS=merge] systemd</command>
+shadow:         files <command>systemd</command>
+gshadow:        files <command>systemd</command>
+
+hosts:          mymachines resolve [!UNAVAIL=return] files myhostname dns
+networks:       files
+
+protocols:      db files
+services:       db files
+ethers:         db files
+rpc:            db files
+
+netgroup:       nis</programlisting>
+
+  </refsect1>
+
+  <refsect1>
+    <title>Example: Mappings provided by <filename>systemd-machined.service</filename></title>
+
+    <para>The container <literal>rawhide</literal> is spawned using
+    <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>:
+    </para>
+
+    <programlisting># systemd-nspawn -M rawhide --boot --network-veth --private-users=pick
+Spawning container rawhide on /var/lib/machines/rawhide.
+Selected user namespace base 20119552 and range 65536.
+...
+
+$ machinectl --max-addresses=3
+MACHINE CLASS     SERVICE        OS     VERSION ADDRESSES
+rawhide container systemd-nspawn fedora 30      169.254.40.164 fe80::94aa:3aff:fe7b:d4b9
+
+$ getent passwd vu-rawhide-0 vu-rawhide-81
+vu-rawhide-0:*:20119552:65534:vu-rawhide-0:/:/usr/sbin/nologin
+vu-rawhide-81:*:20119633:65534:vu-rawhide-81:/:/usr/sbin/nologin
+
+$ getent group vg-rawhide-0 vg-rawhide-81
+vg-rawhide-0:*:20119552:
+vg-rawhide-81:*:20119633:
+
+$ ps -o user:15,pid,tty,command -e|grep '^vu-rawhide'
+vu-rawhide-0      692 ?        /usr/lib/systemd/systemd
+vu-rawhide-0      731 ?        /usr/lib/systemd/systemd-journald
+vu-rawhide-192    734 ?        /usr/lib/systemd/systemd-networkd
+vu-rawhide-193    738 ?        /usr/lib/systemd/systemd-resolved
+vu-rawhide-0      742 ?        /usr/lib/systemd/systemd-logind
+vu-rawhide-81     744 ?        /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
+vu-rawhide-0      746 ?        /usr/sbin/sshd -D ...
+vu-rawhide-0      752 ?        /usr/lib/systemd/systemd --user
+vu-rawhide-0      753 ?        (sd-pam)
+vu-rawhide-0     1628 ?        login -- zbyszek
+vu-rawhide-1000  1630 ?        /usr/lib/systemd/systemd --user
+vu-rawhide-1000  1631 ?        (sd-pam)
+vu-rawhide-1000  1637 pts/8    -zsh
+</programlisting>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>nss-resolve</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>nss-myhostname</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>nss-mymachines</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-userdbd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-homed.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-machined.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>nsswitch.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>getent</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/oomctl.xml b/man/oomctl.xml
new file mode 100644
index 0000000..fd366c7
--- /dev/null
+++ b/man/oomctl.xml
@@ -0,0 +1,88 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="oomctl" conditional='ENABLE_OOMD'
+  xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>oomctl</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>oomctl</refentrytitle>
+    <manvolnum>1</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>oomctl</refname>
+    <refpurpose>Analyze the state stored in <command>systemd-oomd</command></refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <cmdsynopsis>
+      <command>oomctl</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="req">COMMAND</arg>
+    </cmdsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>oomctl</command> may be used to get information about the various contexts read in by
+    the <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> userspace
+    out-of-memory (OOM) killer,
+    <citerefentry><refentrytitle>systemd-oomd</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
+
+  </refsect1>
+
+  <refsect1>
+    <title>Commands</title>
+
+    <para>The following commands are understood:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><command>dump</command></term>
+
+        <listitem><para>Show the current state of the cgroups and system contexts stored by
+        <command>systemd-oomd</command>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v247"/></listitem>
+      </varlistentry>
+
+    </variablelist>
+
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>The following options are understood:</para>
+
+    <variablelist>
+      <xi:include href="standard-options.xml" xpointer="help" />
+      <xi:include href="standard-options.xml" xpointer="version" />
+      <xi:include href="standard-options.xml" xpointer="no-pager" />
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Exit status</title>
+
+    <para>On success, 0 is returned, a non-zero failure code otherwise.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-oomd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>oomd.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/oomd.conf.xml b/man/oomd.conf.xml
new file mode 100644
index 0000000..4fc7abd
--- /dev/null
+++ b/man/oomd.conf.xml
@@ -0,0 +1,106 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="oomd.conf" conditional='ENABLE_OOMD'
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+  <refentryinfo>
+    <title>oomd.conf</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>oomd.conf</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>oomd.conf</refname>
+    <refname>oomd.conf.d</refname>
+    <refpurpose>Global <command>systemd-oomd</command> configuration files</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>/etc/systemd/oomd.conf</filename></para>
+    <para><filename>/etc/systemd/oomd.conf.d/*.conf</filename></para>
+    <para><filename>/usr/lib/systemd/oomd.conf.d/*.conf</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>These files configure the various parameters of the
+    <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> userspace
+    out-of-memory (OOM) killer,
+    <citerefentry><refentrytitle>systemd-oomd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+    See <citerefentry><refentrytitle>systemd.syntax</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+    for a general description of the syntax.</para>
+
+  </refsect1>
+
+  <xi:include href="standard-conf.xml" xpointer="main-conf" />
+
+  <refsect1>
+    <title>[OOM] Section Options</title>
+
+    <para>The following options are available in the [OOM] section:</para>
+
+    <variablelist class='config-directives'>
+      <varlistentry>
+        <term><varname>SwapUsedLimit=</varname></term>
+
+        <listitem><para>Sets the limit for memory and swap usage on the system before <command>systemd-oomd</command>
+        will take action. If the fraction of memory used and the fraction of swap used on the system are both more than
+        what is defined here, <command>systemd-oomd</command> will act on eligible descendant control groups with swap
+        usage greater than 5% of total swap, starting from the ones with the highest swap usage. Which
+        control groups are monitored and what action gets taken depends on what the unit has configured for
+        <varname>ManagedOOMSwap=</varname>.  Takes a value specified in percent (when suffixed with "%"),
+        permille ("‰") or permyriad ("‱"), between 0% and 100%, inclusive. Defaults to 90%.</para>
+
+        <xi:include href="version-info.xml" xpointer="v247"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>DefaultMemoryPressureLimit=</varname></term>
+
+        <listitem><para>Sets the limit for memory pressure on the unit's control group before
+        <command>systemd-oomd</command> will take action. A unit can override this value with
+        <varname>ManagedOOMMemoryPressureLimit=</varname>.  The memory pressure for this property represents
+        the fraction of time in a 10 second window in which all tasks in the control group were delayed. For
+        each monitored control group, if the memory pressure on that control group exceeds the limit set for
+        longer than the duration set by <varname>DefaultMemoryPressureDurationSec=</varname>,
+        <command>systemd-oomd</command> will act on eligible descendant control groups, starting from the
+        ones with the most reclaim activity to the least reclaim activity. Which control groups are monitored
+        and what action gets taken depends on what the unit has configured for
+        <varname>ManagedOOMMemoryPressure=</varname>. Takes a fraction specified in the same way as
+        <varname>SwapUsedLimit=</varname> above. Defaults to 60%.</para>
+
+        <xi:include href="version-info.xml" xpointer="v247"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>DefaultMemoryPressureDurationSec=</varname></term>
+
+        <listitem><para>Sets the amount of time a unit's control group needs to have exceeded memory pressure
+        limits before <command>systemd-oomd</command> will take action. Memory pressure limits are defined by
+        <varname>DefaultMemoryPressureLimit=</varname> and <varname>ManagedOOMMemoryPressureLimit=</varname>.
+        Must be set to 0, or at least 1 second. Defaults to 30 seconds when unset or 0.</para>
+
+        <xi:include href="version-info.xml" xpointer="v248"/></listitem>
+      </varlistentry>
+
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+      <title>See Also</title>
+      <para>
+        <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd-oomd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>oomctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+      </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/org.freedesktop.LogControl1.xml b/man/org.freedesktop.LogControl1.xml
new file mode 100644
index 0000000..1694453
--- /dev/null
+++ b/man/org.freedesktop.LogControl1.xml
@@ -0,0 +1,143 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" >
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="org.freedesktop.LogControl1"
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+  <refentryinfo>
+    <title>org.freedesktop.LogControl1</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>org.freedesktop.LogControl1</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>org.freedesktop.LogControl1</refname>
+    <refpurpose>D-Bus interface to query and set logging configuration</refpurpose>
+  </refnamediv>
+
+  <refsect1>
+    <title>Introduction</title>
+
+    <para><interfacename>org.freedesktop.LogControl1</interfacename> is a generic interface that is intended
+    to be used by any daemon which allows the log level and target to be set over D-Bus. It is implemented by
+    various daemons that are part of the
+    <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> suite.</para>
+
+    <para>It is assumed that those settings are global for the whole program, so a fixed object path is
+    used. The interface should always be available under the path
+    <filename>/org/freedesktop/LogControl1</filename>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>The following interface is exposed:</para>
+
+    <programlisting executable="systemd" node="/org/freedesktop/LogControl1" interface="org.freedesktop.LogControl1">
+node /org/freedesktop/LogControl1 {
+  interface org.freedesktop.LogControl1 {
+    properties:
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      @org.freedesktop.systemd1.Privileged("true")
+      readwrite s LogLevel = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      @org.freedesktop.systemd1.Privileged("true")
+      readwrite s LogTarget = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s SyslogIdentifier = '...';
+  };
+  interface org.freedesktop.DBus.Peer { ... };
+  interface org.freedesktop.DBus.Introspectable { ... };
+  interface org.freedesktop.DBus.Properties { ... };
+};
+    </programlisting>
+
+    <!--Autogenerated cross-references for systemd.directives, do not edit-->
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.LogControl1"/>
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.LogControl1"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LogLevel"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LogTarget"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SyslogIdentifier"/>
+
+    <!--End of Autogenerated section-->
+
+    <refsect2>
+      <title>Properties</title>
+
+      <para><varname>LogLevel</varname> describes the
+      <citerefentry project="man-pages"><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>-style
+      log-level, and should be one of <literal>emerg</literal>, <literal>alert</literal>,
+      <literal>crit</literal>, <literal>err</literal>, <literal>warning</literal>, <literal>notice</literal>,
+      <literal>info</literal>, <literal>debug</literal>, in order of increasing verbosity.</para>
+
+      <para><varname>LogTarget</varname> describes the log target (mechanism). It should be one of
+      <literal>console</literal> (log to the console or standard output),
+      <literal>kmsg</literal> (log to the kernel ring buffer),
+      <literal>journal</literal> (log to the journal natively, see
+      <citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>),
+      <literal>syslog</literal> (log using the
+      <citerefentry project="man-pages"><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry> call).
+      </para>
+
+      <para>Those two properties are writable, so they may be set by sufficiently privileged users.</para>
+
+      <para><varname>SyslogIdentifier</varname> is a read-only property that shows the "syslog identifier".
+      It is a short string that identifies the program that is the source of log messages that is passed to
+      the <citerefentry project="man-pages"><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry> call.
+      </para>
+    </refsect2>
+  </refsect1>
+
+  <refsect1>
+    <title>Tools</title>
+
+    <para><command>journalctl</command> option <option>-p</option>/<option>--priority=</option> may be used
+    to filter log messages by log level, option <option>-t</option>/<option>--identifier=</option> may be
+    used to by the syslog identifier, and filters like <literal>_TRANSPORT=syslog</literal>,
+    <literal>_TRANSPORT=journal</literal>, and <literal>_TRANSPORT=kernel</literal> may be used to filter
+    messages by the mechanism through which they reached <command>systemd-journald</command>.</para>
+
+    <para><command>systemctl log-level</command> and <command>systemctl log-target</command> verbs may be
+    used to query and set the <varname>LogLevel</varname> and <varname>LogTarget</varname> properties of the
+    service manager. <command>systemctl service-log-level</command> and <command>systemctl
+    service-log-target</command> may similarly be used for individual services. (Services must have the
+    <varname>BusName=</varname> property set and must implement the interface described here. See
+    <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for details about <varname>BusName=</varname>.)</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Example</title>
+
+    <example>
+      <title>Create a simple listener on the bus that implements LogControl1</title>
+
+      <programlisting><xi:include href="logcontrol-example.c" parse="text"/></programlisting>
+
+      <para>This creates a simple server on the bus. It implements the LogControl1 interface by providing
+      the required properties and allowing to set the writable ones. It logs at the configured log level using
+      <citerefentry><refentrytitle>sd_journal_print</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para>
+    </example>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry project="man-pages"><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+</refentry>
diff --git a/man/org.freedesktop.home1.xml b/man/org.freedesktop.home1.xml
new file mode 100644
index 0000000..f217fb8
--- /dev/null
+++ b/man/org.freedesktop.home1.xml
@@ -0,0 +1,533 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" >
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="org.freedesktop.home1" conditional='ENABLE_HOMED'
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+  <refentryinfo>
+    <title>org.freedesktop.home1</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>org.freedesktop.home1</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>org.freedesktop.home1</refname>
+    <refpurpose>The D-Bus interface of systemd-homed</refpurpose>
+  </refnamediv>
+
+  <refsect1>
+    <title>Introduction</title>
+
+    <para><citerefentry><refentrytitle>systemd-homed.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    is a system service which may be used to create, remove, change or inspect home areas. This page
+    describes the D-Bus interface.
+    </para>
+  </refsect1>
+
+  <refsect1>
+    <title>The Manager Object</title>
+
+    <para>The service exposes the following interfaces on the Manager object on the bus:</para>
+
+    <programlisting executable="systemd-homed" node="/org/freedesktop/home1" interface="org.freedesktop.home1.Manager">
+node /org/freedesktop/home1 {
+  interface org.freedesktop.home1.Manager {
+    methods:
+      GetHomeByName(in  s user_name,
+                    out u uid,
+                    out s home_state,
+                    out u gid,
+                    out s real_name,
+                    out s home_directory,
+                    out s shell,
+                    out o bus_path);
+      GetHomeByUID(in  u uid,
+                   out s user_name,
+                   out s home_state,
+                   out u gid,
+                   out s real_name,
+                   out s home_directory,
+                   out s shell,
+                   out o bus_path);
+      GetUserRecordByName(in  s user_name,
+                          out s user_record,
+                          out b incomplete,
+                          out o bus_path);
+      GetUserRecordByUID(in  u uid,
+                         out s user_record,
+                         out b incomplete,
+                         out o bus_path);
+      ListHomes(out a(susussso) home_areas);
+      @org.freedesktop.systemd1.Privileged("true")
+      ActivateHome(in  s user_name,
+                   in  s secret);
+      @org.freedesktop.systemd1.Privileged("true")
+      DeactivateHome(in  s user_name);
+      RegisterHome(in  s user_record);
+      UnregisterHome(in  s user_name);
+      CreateHome(in  s user_record);
+      RealizeHome(in  s user_name,
+                  in  s secret);
+      RemoveHome(in  s user_name);
+      @org.freedesktop.systemd1.Privileged("true")
+      FixateHome(in  s user_name,
+                 in  s secret);
+      AuthenticateHome(in  s user_name,
+                       in  s secret);
+      UpdateHome(in  s user_record);
+      ResizeHome(in  s user_name,
+                 in  t size,
+                 in  s secret);
+      ChangePasswordHome(in  s user_name,
+                         in  s new_secret,
+                         in  s old_secret);
+      @org.freedesktop.systemd1.Privileged("true")
+      LockHome(in  s user_name);
+      @org.freedesktop.systemd1.Privileged("true")
+      UnlockHome(in  s user_name,
+                 in  s secret);
+      AcquireHome(in  s user_name,
+                  in  s secret,
+                  in  b please_suspend,
+                  out h send_fd);
+      @org.freedesktop.systemd1.Privileged("true")
+      RefHome(in  s user_name,
+              in  b please_suspend,
+              out h send_fd);
+      @org.freedesktop.systemd1.Privileged("true")
+      ReleaseHome(in  s user_name);
+      @org.freedesktop.systemd1.Privileged("true")
+      LockAllHomes();
+      @org.freedesktop.systemd1.Privileged("true")
+      DeactivateAllHomes();
+      @org.freedesktop.systemd1.Privileged("true")
+      Rebalance();
+    properties:
+      readonly a(sso) AutoLogin = [...];
+  };
+  interface org.freedesktop.DBus.Peer { ... };
+  interface org.freedesktop.DBus.Introspectable { ... };
+  interface org.freedesktop.DBus.Properties { ... };
+};
+    </programlisting>
+
+    <!--Autogenerated cross-references for systemd.directives, do not edit-->
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.home1.Manager"/>
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.home1.Manager"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="GetHomeByName()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="GetHomeByUID()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="GetUserRecordByName()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="GetUserRecordByUID()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="ListHomes()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="ActivateHome()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="DeactivateHome()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="RegisterHome()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="UnregisterHome()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="CreateHome()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="RealizeHome()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="RemoveHome()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="FixateHome()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="AuthenticateHome()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="UpdateHome()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="ResizeHome()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="ChangePasswordHome()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="LockHome()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="UnlockHome()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="AcquireHome()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="RefHome()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="ReleaseHome()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="LockAllHomes()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="DeactivateAllHomes()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="Rebalance()"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="AutoLogin"/>
+
+    <!--End of Autogenerated section-->
+
+    <refsect2>
+      <title>Methods</title>
+
+      <para><function>GetHomeByName()</function> returns basic user information (a minimal subset of the full
+      user record), provided a user name. The information supplied more or less matches what
+      <citerefentry project="man-pages"><refentrytitle>getpwnam</refentrytitle><manvolnum>3</manvolnum></citerefentry> returns:
+      the numeric UID and GID, the real name, home directory and shell. In addition it returns a state
+      identifier describing the state the user's home directory is in, as well as a bus path referring to the
+      bus object encapsulating the user record and home directory. This object implements the
+      <classname>org.freedesktop.home1.Home</classname> interface documented below.</para>
+
+      <para><function>GetHomeByUID()</function> is similar to <function>GetHomeByName()</function> but
+      acquires the information based on the numeric UID of the user.</para>
+
+      <para><function>GetUserRecordByName()</function> is also similar to
+      <function>GetHomeByName()</function> but returns the full JSON user record data instead of the broken
+      down records. An additional returned boolean indicates whether the record is complete or not. A record
+      is considered complete when its <literal>privileged</literal> section is included, and incomplete if it
+      was removed (see <ulink url="https://systemd.io/USER_RECORD">JSON User Records</ulink> for details
+      about the various sections of a user record). Generally, only privileged clients and clients running
+      under the identity of the user itself get access to the <literal>privileged</literal> section and will
+      thus see complete records.</para>
+
+      <para><function>GetUserRecordByUID()</function> is similar to <function>GetUserRecordByName()</function>
+      but returns the user record matching the specified numeric UID.</para>
+
+      <para><function>ListHomes()</function> returns an array of all locally managed users. The array
+      contains the same fields <function>GetHomeByName()</function> returns: user name, numeric UID, state,
+      numeric GID, real name, home directory, shell and bus path of the matching bus object.</para>
+
+      <para><function>ActivateHome()</function> activates (i.e. mounts) the home directory of the specified
+      user. The second argument shall contain a user record consisting only of a <literal>secret</literal>
+      section (all other sections should be stripped, see <ulink url="https://systemd.io/USER_RECORD">JSON
+      User Records</ulink> for details), and should contain only the secret credentials necessary for
+      unlocking the home directory. Typically a client would invoke this function first with an entirely
+      empty record (which is possibly sufficient if single-factor authentication with a plugged-in security
+      token is configured), and would then retry with a record populated with more information, depending on
+      the returned error code, in case more credentials are necessary. This function is synchronous and
+      returns only after the home directory was fully activated (or the operation failed), which might take
+      some time. Clients must be prepared for that, and typically should extend the D-Bus method call
+      timeout accordingly. This method is equivalent to the <function>Activate()</function> method on the
+      <classname>org.freedesktop.home1.Home</classname> interface documented below, but may be called on the
+      manager object and takes a user name as additional argument, instead.</para>
+
+      <para><function>DeactivateHome()</function> deactivates (i.e. unmounts) the home directory of the
+      specified user. It is equivalent to the <function>Deactivate()</function> method on the
+      <classname>org.freedesktop.home1.Home</classname> interface documented below.</para>
+
+      <para><function>RegisterHome()</function> registers a new home directory locally. It receives the JSON
+      user record as only argument (which typically excludes the <literal>secret</literal>
+      section). Registering a home directory just makes the user record known to the system, it does not
+      create a home directory or such (which is expected to exist already, or created later). This operation
+      is useful to register home directories locally that are not located where
+      <filename>systemd-homed.service</filename> would find them automatically.</para>
+
+      <para><function>UnregisterHome()</function> unregisters an existing home directory. It takes a user
+      name as argument and undoes what <function>RegisterHome()</function> does. It does not attempt to
+      remove the home directory itself, it just unregisters it with the local system. Note that if the home
+      directory is placed where <filename>systemd-homed.service</filename> looks for home directories anyway
+      this call will only undo fixation (see below), but the record will remain known to
+      <filename>systemd-homed.service</filename> and be listed among known records. Since the user record is
+      embedded into the home directory this operation generally does not discard data belonging to the user
+      or their record. This method is equivalent to
+      <function>Unregister()</function> on the <classname>org.freedesktop.home1.Home</classname>
+      interface.</para>
+
+      <para><function>CreateHome()</function> registers and creates a new home directory. This takes a fully
+      specified JSON user record as argument (including the <literal>secret</literal> section). This registers
+      the user record locally and creates a home directory matching it, depending on the settings specified
+      in the record in combination with local configuration.</para>
+
+      <para><function>RealizeHome()</function> creates a home directory whose user record is already
+      registered locally. This takes a user name plus a user record consisting only of the
+      <literal>secret</literal> section. Invoking <function>RegisterHome()</function> followed by
+      <function>RealizeHome()</function> is mostly equivalent to calling <function>CreateHome()</function>,
+      except that the latter combines the two in atomic fashion. This method is equivalent to
+      <function>Realize()</function> on the <classname>org.freedesktop.home1.Home</classname>
+      interface.</para>
+
+      <para><function>RemoveHome()</function> unregisters a user record locally, and removes the home
+      directory belonging to it, if it is accessible. It takes a user name as argument. This method is equivalent to
+      <function>Remove()</function> on the <classname>org.freedesktop.home1.Home</classname>
+      interface.</para>
+
+      <para><function>FixateHome()</function> <literal>fixates</literal> an automatically discovered home
+      directory. <filename>systemd-homed.service</filename> automatically discovers home directories dropped
+      in our plugged in and adds them to the runtime list of user records it manages. A user record
+      discovered that way may be <literal>fixated</literal>, in which case it is copied out of the home
+      directory, onto persistent storage, to fixate the UID/GID assignment of the record, and extract
+      additional (typically previously encrypted) user record data from the home directory. A home directory
+      mus be fixated before it can be logged into. This method call takes a user name and a JSON user record
+      consisting only of the <literal>secret</literal> section as argument. This method is equivalent to
+      <function>Fixate()</function> on the <classname>org.freedesktop.home1.Home</classname> interface.</para>
+
+      <para><function>AuthenticateHome()</function> checks passwords or other authentication credentials
+      associated with the home directory. It takes a user name and a JSON user record consisting only of the
+      <literal>secret</literal> section as argument. Note that many of the other method calls authenticate
+      the user first, in order to execute some other operation. This method call only authenticates and
+      executes no further operation. Like <function>ActivateHome()</function> it is usually first invoked
+      with an empty JSON user record, which is then populated for subsequent tries with additional
+      authentication data supplied. This method is equivalent to
+      <function>Authenticate()</function> on the <classname>org.freedesktop.home1.Home</classname>
+      interface.</para>
+
+      <para><function>UpdateHome()</function> updates a locally registered user record. Takes a fully
+      specified JSON user record as argument (including the <literal>secret</literal> section). A user with a
+      matching name and realm must be registered locally already, and the last change timestamp of the newly
+      supplied record must be newer than the previously existing user record. Note this operation updates the
+      user record only, it does not propagate passwords/authentication tokens from the user record to the
+      storage back-end, or resizes the storage back-end. Typically a home directory is first updated, and then
+      the password of the underlying storage updated using <function>ChangePasswordHome()</function> as well
+      as the storage resized using <function>ResizeHome()</function>. This method is equivalent to
+      <function>Update()</function> on the <classname>org.freedesktop.home1.Home</classname> interface.</para>
+
+      <para><function>ResizeHome()</function> resizes the storage associated with a user record. Takes a user
+      name, a disk size in bytes and a user record consisting only of the <literal>secret</literal> section
+      as argument. If the size is specified as <constant>UINT64_MAX</constant> the storage is resized to the
+      size already specified in the user record. Typically, if the user record is updated using
+      <function>UpdateHome()</function> above this is used to propagate the size configured there-in down to
+      the underlying storage back-end. This method is equivalent to
+      <function>Resize()</function> on the <classname>org.freedesktop.home1.Home</classname>
+      interface.</para>
+
+      <para><function>ChangePasswordHome()</function> changes the passwords/authentication tokens of a home
+      directory. Takes a user name, and two JSON user record objects, each consisting only of the
+      <literal>secret</literal> section, for the old and for the new passwords/authentication tokens. If the
+      user record with the new passwords/authentication token data is specified as empty the existing user
+      record's settings are propagated down to the home directory storage. This is typically used after a
+      user record is updated using <function>UpdateHome()</function> in order to propagate the
+      secrets/authentication tokens down to the storage. Background: depending on the backend the user's
+      authentication credentials are stored at multiple places: the user record kept on the host, the user
+      record kept in the home directory and the encrypted LUKS volume slot. If the home directory is used on
+      a different machined temporarily, and the password is changed there, and then is moved back to the
+      original host, the passwords of the three might get out of sync. By issuing
+      <function>ChangePasswordHome()</function> the three locations are updated to match the newest
+      information. This method is equivalent to <function>ChangePassword()</function> on the
+      <classname>org.freedesktop.home1.Home</classname> interface.</para>
+
+      <para><function>LockHome()</function> temporarily suspends access to a home directory, flushing out any
+      cryptographic keys from memory. This is only supported on some back-ends, and usually done during system
+      suspend, in order to effectively secure home directories while the system is sleeping. Takes a user
+      name as single argument. If an application attempts to access a home directory while it is locked it
+      will typically freeze until the home directory is unlocked again. This method is equivalent to
+      <function>Lock()</function> on the <classname>org.freedesktop.home1.Home</classname> interface.</para>
+
+      <para><function>UnlockHome()</function> undoes the effect of <function>LockHome()</function>. Takes a
+      user name and a user record consisting only of the <literal>secret</literal> section as arguments. This
+      method is equivalent to <function>Unlock()</function> on the
+      <classname>org.freedesktop.home1.Home</classname> interface.</para>
+
+      <para><function>AcquireHome()</function> activates or unlocks a home directory in a reference counted
+      mode of operation. Takes a user name and user record consisting only of <literal>secret</literal>
+      section as argument. If the home directory is not active yet, it is activated. If it is currently
+      locked it is unlocked. After completion a reference to the activation/unlocking of the home directory
+      is returned via a file descriptor. When the last client which acquired such a file descriptor closes it
+      the home directory is automatically deactivated again. This method is typically invoked when a user
+      logs in, and the file descriptor is held until the user logs out again, thus ensuring the user's home
+      directory can be unmounted automatically again in a robust fashion, when the user logs out. The third
+      argument is a boolean which indicates whether the client invoking the call is able to automatically
+      re-authenticate when the system comes back from suspending. It should be set by all clients that
+      implement a secure lock screen running outside of the user's context, that is brought up when the
+      system comes back from suspend and can be used to re-acquire the credentials to unlock the user's home
+      directory. If a home directory has at least one client with an open reference to the home directory
+      that does not support this it is not suspended automatically at system suspend, otherwise it is. This
+      method is equivalent to <function>Acquire()</function> on the
+      <classname>org.freedesktop.home1.Home</classname> interface.</para>
+
+      <para><function>RefHome()</function> is similar to <function>AcquireHome()</function> but takes no user
+      record with <literal>secret</literal> section, i.e. will take an additional reference to an already
+      activated/unlocked home directory without attempting to activate/unlock it itself. It will fail if the
+      home directory is not already activated. This method is equivalent to
+      <function>Ref()</function> on the <classname>org.freedesktop.home1.Home</classname>
+      interface.</para>
+
+      <para><function>ReleaseHome()</function> releases a home directory again, if all file descriptors
+      referencing it are already closed, that where acquired through <function>AcquireHome()</function> or
+      <function>RefHome()</function>. Note that this call does not actually cause the deactivation of the
+      home directory (which happens automatically when the last referencing file descriptor is closed), but
+      is simply a synchronization mechanism that allows delaying of the user session's termination until any
+      triggered deactivation is completed. This method is equivalent to <function>Release()</function> on the
+      <classname>org.freedesktop.home1.Home</classname> interface.</para>
+
+      <para><function>LockAllHomes()</function> locks all active home directories that only have references
+      that opted into automatic suspending during system suspend. This is usually invoked automatically
+      shortly before system suspend.</para>
+
+      <para><function>DeactivateAllHomes()</function> deactivates all home areas that are currently
+      active. This is usually invoked automatically shortly before system shutdown.</para>
+
+      <para><function>Rebalance()</function> synchronously rebalances free disk space between home
+      areas. This only executes an operation if at least one home area using the LUKS2 backend is active and
+      has rebalancing enabled, and is otherwise a NOP.</para>
+    </refsect2>
+
+    <refsect2>
+      <title>Properties</title>
+
+      <para><varname>AutoLogin</varname> exposes an array of structures consisting of user name, seat name
+      and object path of an home directory object. All locally managed users that have the
+      <literal>autoLogin</literal> field set are listed here, with the seat name they are associated with. A
+      display manager may watch this property and pre-fill the login screen with the users exposed this
+      way.</para>
+    </refsect2>
+  </refsect1>
+
+  <refsect1>
+    <title>The Home Object</title>
+
+    <programlisting executable="systemd-homed" node="/org/freedesktop/home1/home" interface="org.freedesktop.home1.Home">
+node /org/freedesktop/home1/home {
+  interface org.freedesktop.home1.Home {
+    methods:
+      @org.freedesktop.systemd1.Privileged("true")
+      Activate(in  s secret);
+      @org.freedesktop.systemd1.Privileged("true")
+      Deactivate();
+      Unregister();
+      Realize(in  s secret);
+      Remove();
+      @org.freedesktop.systemd1.Privileged("true")
+      Fixate(in  s secret);
+      Authenticate(in  s secret);
+      Update(in  s user_record);
+      Resize(in  t size,
+             in  s secret);
+      ChangePassword(in  s new_secret,
+                     in  s old_secret);
+      @org.freedesktop.systemd1.Privileged("true")
+      Lock();
+      @org.freedesktop.systemd1.Privileged("true")
+      Unlock(in  s secret);
+      @org.freedesktop.systemd1.Privileged("true")
+      Acquire(in  s secret,
+              in  b please_suspend,
+              out h send_fd);
+      @org.freedesktop.systemd1.Privileged("true")
+      Ref(in  b please_suspend,
+          out h send_fd);
+      @org.freedesktop.systemd1.Privileged("true")
+      Release();
+    properties:
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s UserName = '...';
+      readonly u UID = ...;
+      readonly (suusss) UnixRecord = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s State = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates")
+      readonly (sb) UserRecord = ...;
+  };
+  interface org.freedesktop.DBus.Peer { ... };
+  interface org.freedesktop.DBus.Introspectable { ... };
+  interface org.freedesktop.DBus.Properties { ... };
+  interface org.freedesktop.DBus.ObjectManager { ... };
+};
+    </programlisting>
+
+    <!--Autogenerated cross-references for systemd.directives, do not edit-->
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.DBus.ObjectManager"/>
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.home1.Home"/>
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.DBus.ObjectManager"/>
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.home1.Home"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="Activate()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="Deactivate()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="Unregister()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="Realize()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="Remove()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="Fixate()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="Authenticate()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="Update()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="Resize()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="ChangePassword()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="Lock()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="Unlock()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="Acquire()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="Ref()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="Release()"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="UserName"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="UID"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="UnixRecord"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="State"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="UserRecord"/>
+
+    <!--End of Autogenerated section-->
+
+    <refsect2>
+      <title>Methods</title>
+
+      <para><function>Activate()</function>, <function>Deactivate()</function>,
+      <function>Unregister()</function>, <function>Realize()</function>, <function>Remove()</function>,
+      <function>Fixate()</function>, <function>Authenticate()</function>, <function>Update()</function>,
+      <function>Resize()</function>, <function>ChangePassword()</function>, <function>Lock()</function>,
+      <function>Unlock()</function>, <function>Acquire()</function>, <function>Ref()</function>,
+      <function>Release()</function> operate like their matching counterparts on the
+      <classname>org.freedesktop.home1.Manager</classname> interface (see above). The main difference is that
+      they are methods of the home directory objects, and hence carry no additional user name
+      parameter. Which of the two flavors of methods to call depends on the handles to the user known on the
+      client side: if only the user name is known, it's preferable to use the methods on the manager object
+      since they operate with user names only. If however the home object path was already acquired some way
+      it is preferable to operate on the <classname>org.freedesktop.home1.Home</classname> objects
+      instead.</para>
+    </refsect2>
+
+    <refsect2>
+      <title>Properties</title>
+
+      <para><varname>UserName</varname> contains the user name of the user account/home directory.</para>
+
+      <para><varname>UID</varname> contains the numeric UNIX UID of the user account.</para>
+
+      <para><varname>UnixRecord</varname> contains a structure encapsulating the six fields a
+      <structname>struct passwd</structname> typically contains (the password field is suppressed).</para>
+
+      <para><varname>State</varname> exposes the current state home the home directory.</para>
+
+      <para><varname>UserRecord</varname> contains the full JSON user record string of the user account.</para>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="org.freedesktop.locale1.xml" xpointer="versioning"/>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-homed.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>homectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/org.freedesktop.hostname1.xml b/man/org.freedesktop.hostname1.xml
new file mode 100644
index 0000000..0c5b0f2
--- /dev/null
+++ b/man/org.freedesktop.hostname1.xml
@@ -0,0 +1,447 @@
+<?xml version="1.0"?>
+<!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [
+<!ENTITY % entities SYSTEM "custom-entities.ent" >
+%entities;
+]>
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="org.freedesktop.hostname1" conditional='ENABLE_HOSTNAMED'
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+  <refentryinfo>
+    <title>org.freedesktop.hostname1</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>org.freedesktop.hostname1</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>org.freedesktop.hostname1</refname>
+    <refpurpose>The D-Bus interface of systemd-hostnamed</refpurpose>
+  </refnamediv>
+
+  <refsect1>
+    <title>Introduction</title>
+
+    <para>
+    <citerefentry><refentrytitle>systemd-hostnamed.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    is a system service that can be used to control the hostname and related machine metadata from user
+    programs. This page describes the hostname semantics and the D-Bus interface.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>The D-Bus API</title>
+
+    <para>The service exposes the following interfaces on the bus:</para>
+
+    <programlisting executable="systemd-hostnamed" node="/org/freedesktop/hostname1" interface="org.freedesktop.hostname1">
+node /org/freedesktop/hostname1 {
+  interface org.freedesktop.hostname1 {
+    methods:
+      SetHostname(in  s hostname,
+                  in  b interactive);
+      SetStaticHostname(in  s hostname,
+                        in  b interactive);
+      SetPrettyHostname(in  s hostname,
+                        in  b interactive);
+      SetIconName(in  s icon,
+                  in  b interactive);
+      SetChassis(in  s chassis,
+                 in  b interactive);
+      SetDeployment(in  s deployment,
+                    in  b interactive);
+      SetLocation(in  s location,
+                  in  b interactive);
+      GetProductUUID(in  b interactive,
+                     out ay uuid);
+      GetHardwareSerial(out s serial);
+      Describe(out s json);
+    properties:
+      readonly s Hostname = '...';
+      readonly s StaticHostname = '...';
+      readonly s PrettyHostname = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s DefaultHostname = '...';
+      readonly s HostnameSource = '...';
+      readonly s IconName = '...';
+      readonly s Chassis = '...';
+      readonly s Deployment = '...';
+      readonly s Location = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s KernelName = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s KernelRelease = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s KernelVersion = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s OperatingSystemPrettyName = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s OperatingSystemCPEName = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t OperatingSystemSupportEnd = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s HomeURL = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s HardwareVendor = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s HardwareModel = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s FirmwareVersion = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s FirmwareVendor = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t FirmwareDate = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly ay MachineID = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly ay BootID = [...];
+  };
+  interface org.freedesktop.DBus.Peer { ... };
+  interface org.freedesktop.DBus.Introspectable { ... };
+  interface org.freedesktop.DBus.Properties { ... };
+};
+    </programlisting>
+
+    <!--method GetHardwareSerial is not documented!-->
+
+    <!--property OperatingSystemSupportEnd is not documented!-->
+
+    <!--property HardwareVendor is not documented!-->
+
+    <!--property HardwareModel is not documented!-->
+
+    <!--property FirmwareVersion is not documented!-->
+
+    <!--property FirmwareVendor is not documented!-->
+
+    <!--property FirmwareDate is not documented!-->
+
+    <!--property MachineID is not documented!-->
+
+    <!--property BootID is not documented!-->
+
+    <!--Autogenerated cross-references for systemd.directives, do not edit-->
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.hostname1"/>
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.hostname1"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SetHostname()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SetStaticHostname()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SetPrettyHostname()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SetIconName()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SetChassis()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SetDeployment()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SetLocation()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="GetProductUUID()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="GetHardwareSerial()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="Describe()"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Hostname"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StaticHostname"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="PrettyHostname"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DefaultHostname"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="HostnameSource"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IconName"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Chassis"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Deployment"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Location"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="KernelName"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="KernelRelease"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="KernelVersion"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="OperatingSystemPrettyName"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="OperatingSystemCPEName"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="OperatingSystemSupportEnd"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="HomeURL"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="HardwareVendor"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="HardwareModel"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="FirmwareVersion"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="FirmwareVendor"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="FirmwareDate"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MachineID"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="BootID"/>
+
+    <!--End of Autogenerated section-->
+
+    <para>Whenever the hostname or other metadata is changed via the daemon,
+    <function>PropertyChanged</function> signals are sent out to subscribed clients. Changing a hostname
+    using this interface is authenticated via
+    <ulink url="https://www.freedesktop.org/software/polkit/docs/latest/">polkit</ulink>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Semantics</title>
+
+    <para>The <varname>StaticHostname</varname> property exposes the "static" hostname configured in
+    <filename>/etc/hostname</filename>. It is not always in sync with the current hostname as returned by the
+    <citerefentry project="man-pages"><refentrytitle>gethostname</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    system call. If no static hostname is configured this property will be the empty string.</para>
+
+    <para>When <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> or
+    <citerefentry><refentrytitle>systemd-hostnamed.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    set the hostname, this static hostname <emphasis>has the highest priority</emphasis>.</para>
+
+    <para>The <varname>Hostname</varname> property exposes the actual hostname configured in the kernel via
+    <citerefentry project="man-pages"><refentrytitle>sethostname</refentrytitle><manvolnum>2</manvolnum></citerefentry>.
+    It can be different from the static hostname. This property is never empty.</para>
+
+    <para>The <varname>PrettyHostname</varname> property exposes the <emphasis>pretty hostname</emphasis>
+    which is a free-form UTF-8 hostname for presentation to the user. User interfaces should ensure that the
+    pretty hostname and the static hostname stay in sync. E.g. when the former is <literal>Lennart’s
+    Computer</literal> the latter should be <literal>lennarts-computer</literal>. If no pretty hostname is
+    set this setting will be the empty string. Applications should then find a suitable fallback, such as the
+    dynamic hostname.</para>
+
+    <para>The <varname>DefaultHostname</varname> property exposes the default hostname (configured through
+    <citerefentry><refentrytitle>os-release</refentrytitle><manvolnum>5</manvolnum></citerefentry>, or a
+    fallback set at compilation time).</para>
+
+    <para>The <varname>HostnameSource</varname> property exposes the origin of the currently configured
+    hostname. One of <literal>static</literal> (set from <filename>/etc/hostname</filename>),
+    <literal>transient</literal> (a non-permanent hostname from an external source),
+    <literal>default</literal> (the value from <filename>os-release</filename> or the compiled-in
+    fallback).</para>
+
+    <para>The <varname>IconName</varname> property exposes the <emphasis>icon name</emphasis> following the
+    XDG icon naming spec. If not set, information such as the chassis type (see below) is used to find a
+    suitable fallback icon name (i.e. <literal>computer-laptop</literal>
+    vs. <literal>computer-desktop</literal> is picked based on the chassis information). If no such data is
+    available, the empty string is returned. In that case an application should fall back to a replacement
+    icon, for example <literal>computer</literal>. If this property is set to the empty string, the automatic
+    fallback name selection is enabled again.</para>
+
+    <para>The <varname>Chassis</varname> property exposes a <emphasis>chassis type</emphasis>, one of the
+    currently defined chassis types: <literal>desktop</literal>, <literal>laptop</literal>,
+    <literal>server</literal>, <literal>tablet</literal>, <literal>handset</literal>, as well as the special
+    chassis types <literal>vm</literal> and <literal>container</literal> for virtualized systems. Note that
+    in most cases the chassis type will be determined automatically from DMI/SMBIOS/ACPI firmware
+    information. Writing to this setting is hence useful only to override misdetected chassis types, or to
+    configure the chassis type if it could not be auto-detected. Set this property to the empty string to
+    reenable the automatic detection of the chassis type from firmware information.</para>
+
+    <para>Note that <filename>systemd-hostnamed</filename> starts only on request and terminates after a
+    short idle period. This effectively means that <function>PropertyChanged</function> messages are not sent
+    out for changes made directly on the files (as in: administrator edits the files with vi). This is
+    the intended behavior: manual configuration changes should require manual reloading.</para>
+
+    <para>The transient (dynamic) hostname exposed by the <varname>Hostname</varname> property maps directly
+    to the kernel hostname. This hostname should be assumed to be highly dynamic, and hence should be watched
+    directly, without depending on <function>PropertyChanged</function> messages from
+    <filename>systemd-hostnamed</filename>. To accomplish this, open
+    <filename>/proc/sys/kernel/hostname</filename> and
+    <citerefentry project="man-pages"><refentrytitle>poll</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    for <constant>SIGHUP</constant> which is triggered by the kernel every time the hostname changes. Again:
+    this is special for the transient (dynamic) hostname, and does not apply to the configured (fixed)
+    hostname.</para>
+
+    <para>Applications may read the hostname data directly if hostname change notifications
+    are not necessary. Use
+    <citerefentry project="man-pages"><refentrytitle>gethostname</refentrytitle><manvolnum>2</manvolnum></citerefentry>,
+    <filename>/etc/hostname</filename> (possibly with per-distribution fallbacks), and
+    <citerefentry><refentrytitle>machine-info</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    for that. For more information on these files and syscalls see the respective man pages.</para>
+
+    <para><varname>KernelName</varname>, <varname>KernelRelease</varname>, and
+    <varname>KernelVersion</varname> expose the kernel name (e.g. <literal>Linux</literal>), release
+    (e.g. <literal>5.0.0-11</literal>), and version (i.e. the build number, e.g. <literal>#11</literal>) as
+    reported by <citerefentry project="man-pages"><refentrytitle>uname</refentrytitle><manvolnum>2</manvolnum></citerefentry>.
+    <varname>OperatingSystemPrettyName</varname>, <varname>OperatingSystemCPEName</varname>, and
+    <varname>HomeURL</varname> expose the <varname>PRETTY_NAME=</varname>, <varname>CPE_NAME=</varname> and
+    <varname>HOME_URL=</varname> fields from
+    <citerefentry><refentrytitle>os-release</refentrytitle><manvolnum>5</manvolnum></citerefentry>. The
+    purpose of those properties is to allow remote clients to access this information over D-Bus. Local
+    clients can access the information directly.</para>
+
+    <refsect2>
+      <title>Methods</title>
+
+      <para><function>SetHostname()</function> sets the transient (dynamic) hostname, which is used if no
+      static hostname is set. This value must be an internet-style hostname, 7-bit lowercase ASCII, no
+      special chars/spaces. An empty string will unset the transient hostname.</para>
+
+      <para><function>SetStaticHostname()</function> sets the static hostname which is exposed by the
+      <varname>StaticHostname</varname> property. When called with an empty argument, the static
+      configuration in <filename>/etc/hostname</filename> is removed. Since the static hostname has the
+      highest priority, calling this function usually affects also the <varname>Hostname</varname> property
+      and the effective hostname configured in the kernel.</para>
+
+      <para><function>SetPrettyHostname()</function> sets the pretty hostname which is exposed by the
+      <varname>PrettyHostname</varname> property.</para>
+
+      <para><function>SetIconName()</function>, <function>SetChassis()</function>,
+      <function>SetDeployment()</function>, and <function>SetLocation()</function> set the properties
+      <varname>IconName</varname> (the name of the icon representing for the machine),
+      <varname>Chassis</varname> (the machine form factor), <varname>Deployment</varname> (the system
+      deployment environment), and <varname>Location</varname> (physical system location), respectively.
+      </para>
+
+      <para><varname>PrettyHostname</varname>, <varname>IconName</varname>, <varname>Chassis</varname>,
+      <varname>Deployment</varname>, and <varname>Location</varname> are stored in
+      <filename>/etc/machine-info</filename>. See
+      <citerefentry><refentrytitle>machine-info</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
+      the semantics of those settings.</para>
+
+      <para><function>GetProductUUID()</function> returns the "product UUID" as exposed by the kernel based
+      on DMI information in <filename>/sys/class/dmi/id/product_uuid</filename>. Reading the file directly
+      requires root privileges, and this method allows access to unprivileged clients through the polkit
+      framework.</para>
+
+      <para><function>Describe()</function> returns a JSON representation of all properties in one.</para>
+    </refsect2>
+
+    <refsect2>
+      <title>Security</title>
+
+      <para>The <varname>interactive</varname> boolean parameters can be used to control whether polkit
+      should interactively ask the user for authentication credentials if required.</para>
+
+      <para>The polkit action for <function>SetHostname()</function> is
+      <interfacename>org.freedesktop.hostname1.set-hostname</interfacename>. For
+      <function>SetStaticHostname()</function> and <function>SetPrettyHostname()</function> it is
+      <interfacename>org.freedesktop.hostname1.set-static-hostname</interfacename>. For
+      <function>SetIconName()</function>, <function>SetChassis()</function>, <function>SetDeployment()</function>
+      and <function>SetLocation()</function> it is
+      <interfacename>org.freedesktop.hostname1.set-machine-info</interfacename>.</para>
+    </refsect2>
+  </refsect1>
+
+  <refsect1>
+    <title>Recommendations</title>
+
+    <para>Here are three examples that show how the pretty hostname and the icon name should be used:
+    <itemizedlist>
+      <listitem><para>When registering DNS-SD services: use the pretty hostname in the service name, and pass
+      the icon name in the TXT data, if there is an icon name. Browsing clients can then show the server icon
+      on each service. This is especially useful for WebDAV applications or UPnP media sharing.
+      </para></listitem>
+
+      <listitem><para>Set the bluetooth name to the pretty hostname.</para></listitem>
+
+      <listitem><para>When your file browser has a "Computer" icon, replace the name with the pretty hostname
+      if set, and the icon with the icon name, if it is set.</para></listitem>
+    </itemizedlist></para>
+
+    <para>To properly handle name lookups with changing local hostnames without having to edit
+    <filename>/etc/hosts</filename>, we recommend using <filename>systemd-hostnamed</filename> in combination
+    with <citerefentry><refentrytitle>nss-myhostname</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+    </para>
+
+    <para>Here are some recommendations to follow when generating a static (internet) hostname from a pretty
+    name:
+    <itemizedlist>
+      <listitem><para>Generate a single DNS label only, not an FQDN. That means no dots allowed. Strip them,
+      or replace them with <literal>-</literal>.</para></listitem>
+
+      <listitem><para>It's probably safer to not use any non-ASCII chars, even if DNS allows this in some way
+      these days. In fact, restrict your charset to <literal>a-zA-Z0-9</literal> and <literal>-</literal>.
+      Strip other chars, or try to replace them in some smart way with chars from this set, for example
+      <literal>ä</literal> → <literal>ae</literal>, and use <literal>-</literal> as the replacement for all
+      punctuation characters and whitespace.</para></listitem>
+
+      <listitem><para>Try to avoid creating repeated <literal>-</literal>, as well as <literal>-</literal> as
+      the first or last char.</para></listitem>
+
+      <listitem><para>Limit the hostname to 63 chars, which is the length of a DNS label.</para></listitem>
+
+      <listitem><para>If after stripping special chars the empty string is the result, you can pass this
+      as-is to <filename>systemd-hostnamed</filename> in which case it will automatically use a suitable
+      fallback.</para></listitem>
+
+      <listitem><para>Uppercase characters should be replaced with their lowercase equivalents.
+      </para></listitem>
+    </itemizedlist></para>
+
+    <para>Note that while <filename>systemd-hostnamed</filename> applies some checks to the hostname you pass
+    they are much looser than the recommendations above. For example, <filename>systemd-hostnamed</filename>
+    will also accept <literal>_</literal> in the hostname, but we recommend not using this to avoid clashes
+    with DNS-SD service types. Also <filename>systemd-hostnamed</filename> allows longer hostnames, but
+    because of the DNS label limitations, we recommend not making use of this.</para>
+
+    <para>Here are a couple of example conversions:
+    <itemizedlist>
+      <listitem><para><literal>Lennart's PC</literal> → <literal>lennarts-pc</literal></para></listitem>
+      <listitem><para><literal>Müllers Computer</literal> → <literal>muellers-computer</literal></para></listitem>
+      <listitem><para><literal>Voran!</literal> → <literal>voran</literal></para></listitem>
+      <listitem><para><literal>Es war einmal ein Männlein</literal> → <literal>es-war-einmal-ein-maennlein</literal></para></listitem>
+      <listitem><para><literal>Jawoll. Ist doch wahr!</literal> → <literal>jawoll-ist-doch-wahr</literal></para></listitem>
+      <listitem><para><literal>レナート</literal> → <literal>localhost</literal></para></listitem>
+      <listitem><para><literal>...zack!!! zack!...</literal> → <literal>zack-zack</literal></para></listitem>
+    </itemizedlist></para>
+
+    <para>Of course, an already valid internet hostname label you enter and pass through this
+    conversion should stay unmodified, so that users have direct control of it, if they want — by simply
+    ignoring the fact that the pretty hostname is pretty and just edit it as if it was the normal internet
+    name.</para>
+  </refsect1>
+
+  <xi:include href="org.freedesktop.locale1.xml" xpointer="versioning"/>
+
+  <refsect1>
+    <title>Examples</title>
+
+    <example>
+      <title>Introspect <interfacename>org.freedesktop.hostname1</interfacename> on the bus</title>
+
+      <programlisting>$ gdbus introspect --system \
+  --dest org.freedesktop.hostname1 \
+  --object-path /org/freedesktop/hostname1
+      </programlisting>
+    </example>
+  </refsect1>
+
+  <refsect1>
+    <title>See also</title>
+
+    <para>David Zeuthen's original Fedora
+    <ulink url="https://fedoraproject.org/wiki/Features/BetterHostname">Feature page about xdg-hostname</ulink></para>
+  </refsect1>
+
+  <refsect1>
+    <title>History</title>
+    <refsect2>
+      <title>The D-Bus API</title>
+      <para><varname>FirmwareVersion</varname> and
+      <function>GetHardwareSerial()</function> were added in version 251.</para>
+      <para><varname>OperatingSystemSupportEnd</varname>,
+      <varname>FirmwareVendor</varname>, and
+      <varname>FirmwareDate</varname> were added in version 253.</para>
+      <para><varname>MachineID</varname>, and
+      <varname>BootID</varname> were added in version 256.</para>
+    </refsect2>
+  </refsect1>
+</refentry>
diff --git a/man/org.freedesktop.import1.xml b/man/org.freedesktop.import1.xml
new file mode 100644
index 0000000..3ef6264
--- /dev/null
+++ b/man/org.freedesktop.import1.xml
@@ -0,0 +1,343 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" >
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="org.freedesktop.import1" conditional='ENABLE_IMPORTD'
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+  <refentryinfo>
+    <title>org.freedesktop.import1</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>org.freedesktop.import1</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>org.freedesktop.import1</refname>
+    <refpurpose>The D-Bus interface of systemd-importd</refpurpose>
+  </refnamediv>
+
+  <refsect1>
+    <title>Introduction</title>
+
+    <para>
+    <citerefentry><refentrytitle>systemd-importd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    is a system service which may be used to import, export and download additional system images. These
+    images can be used by tools such as
+    <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+     to run local containers. The service is used as the backend for <command>machinectl pull-raw</command>,
+     <command>machinectl pull-tar</command> and related commands. This page describes the D-Bus interface.
+    </para>
+
+    <para>Note that
+    <citerefentry><refentrytitle>systemd-importd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    is mostly a small companion service for
+    <citerefentry><refentrytitle>systemd-machined.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+    Many operations to manipulate local container and VM images are hence available via the <command>systemd-machined</command> D-Bus API, c.f.
+    <citerefentry><refentrytitle>org.freedesktop.machine1</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+    </para>
+  </refsect1>
+
+  <refsect1>
+    <title>The Manager Object</title>
+
+    <para>The service exposes the following interfaces on the Manager object on the bus:</para>
+
+    <programlisting executable="systemd-importd" node="/org/freedesktop/import1" interface="org.freedesktop.import1.Manager">
+node /org/freedesktop/import1 {
+  interface org.freedesktop.import1.Manager {
+    methods:
+      ImportTar(in  h fd,
+                in  s local_name,
+                in  b force,
+                in  b read_only,
+                out u transfer_id,
+                out o transfer_path);
+      ImportRaw(in  h fd,
+                in  s local_name,
+                in  b force,
+                in  b read_only,
+                out u transfer_id,
+                out o transfer_path);
+      ImportFileSystem(in  h fd,
+                       in  s local_name,
+                       in  b force,
+                       in  b read_only,
+                       out u transfer_id,
+                       out o transfer_path);
+      ExportTar(in  s local_name,
+                in  h fd,
+                in  s format,
+                out u transfer_id,
+                out o transfer_path);
+      ExportRaw(in  s local_name,
+                in  h fd,
+                in  s format,
+                out u transfer_id,
+                out o transfer_path);
+      PullTar(in  s url,
+              in  s local_name,
+              in  s verify_mode,
+              in  b force,
+              out u transfer_id,
+              out o transfer_path);
+      PullRaw(in  s url,
+              in  s local_name,
+              in  s verify_mode,
+              in  b force,
+              out u transfer_id,
+              out o transfer_path);
+      ListTransfers(out a(usssdo) transfers);
+      CancelTransfer(in  u transfer_id);
+    signals:
+      TransferNew(u transfer_id,
+                  o transfer_path);
+      TransferRemoved(u transfer_id,
+                      o transfer_path,
+                      s result);
+  };
+  interface org.freedesktop.DBus.Peer { ... };
+  interface org.freedesktop.DBus.Introspectable { ... };
+  interface org.freedesktop.DBus.Properties { ... };
+};
+    </programlisting>
+
+    <!--method ImportFileSystem is not documented!-->
+
+    <!--Autogenerated cross-references for systemd.directives, do not edit-->
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.import1.Manager"/>
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.import1.Manager"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="ImportTar()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="ImportRaw()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="ImportFileSystem()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="ExportTar()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="ExportRaw()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="PullTar()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="PullRaw()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="ListTransfers()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="CancelTransfer()"/>
+
+    <variablelist class="dbus-signal" generated="True" extra-ref="TransferNew"/>
+
+    <variablelist class="dbus-signal" generated="True" extra-ref="TransferRemoved"/>
+
+    <!--End of Autogenerated section-->
+
+    <refsect2>
+      <title>Methods</title>
+
+      <para><function>ImportTar()</function> and <function>ImportRaw()</function> import a system image and
+      place it into <filename>/var/lib/machines/</filename>. The first argument should be a file descriptor
+      (opened for reading) referring to the tar or raw file to import. It should reference a file on disk,
+      a pipe or a socket. When <function>ImportTar()</function> is used the file descriptor should
+      refer to a tar file, optionally compressed with
+      <citerefentry project="die-net"><refentrytitle>gzip</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry project="die-net"><refentrytitle>bzip2</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      or
+      <citerefentry project="die-net"><refentrytitle>xz</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
+      <command>systemd-importd</command> will detect the used compression scheme (if any) automatically. When
+      <function>ImportRaw()</function> is used the file descriptor should refer to a raw or qcow2 disk image
+      containing an MBR or GPT disk label, also optionally compressed with gzip, bzip2 or xz. In either case,
+      if the file is specified as a file descriptor on disk, progress information is generated for the import
+      operation (as in that case we know the total size on disk). If a socket or pipe is specified, progress information is not
+      available. The file descriptor argument is followed by a local name for the image. This should be a
+      name suitable as a hostname and will be used to name the imported image below
+      <filename>/var/lib/machines/</filename>. A tar import is placed as a directory tree or a
+      <citerefentry project="url"><refentrytitle url="https://btrfs.readthedocs.io/en/latest/btrfs.html">btrfs</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+      subvolume below <filename>/var/lib/machines/</filename> under the specified name with no suffix
+      appended. A raw import is placed as a file in <filename>/var/lib/machines/</filename> with the
+      <filename>.raw</filename> suffix appended. If the <option>force</option> argument is true, any
+      pre-existing image with the same name is removed before starting the operation. Otherwise, the
+      operation fails if an image with the same name already exists. Finally, the
+      <option>read_only</option> argument controls
+      whether to create a writable or read-only image. Both methods return immediately after starting the import,
+      with the import transfer ongoing. They return a pair of transfer identifier and object path, which may
+      be used to retrieve progress information about the transfer or to cancel it. The transfer identifier is a
+      simple numeric identifier, the object path references an
+      <interfacename>org.freedesktop.import1.Transfer</interfacename> object, see below. Listen for a
+      <function>TransferRemoved</function> signal for the transfer ID in order to detect when a transfer is
+      complete. The returned transfer object is useful to determine the current progress or log output of the
+      ongoing import operation.</para>
+
+      <para><function>ExportTar()</function> and <function>ExportRaw()</function> implement the reverse
+      operation, and may be used to export a system image in order to place it in a tar or raw image. They
+      take the machine name to export as their first parameter, followed by a file descriptor (opened for writing)
+      where the tar or raw file will be written. It may either reference a file on disk or a pipe/socket. The
+      third argument specifies in which compression format to write the image. It takes one of
+      <literal>uncompressed</literal>, <literal>xz</literal>, <literal>bzip2</literal> or
+      <literal>gzip</literal>, depending on which compression scheme is required. The image written to the
+      specified file descriptor will be a tar file in case of <function>ExportTar()</function> or a raw disk
+      image in case of <function>ExportRaw()</function>. Note that currently raw disk images may not be
+      exported as tar files, and vice versa. This restriction might be lifted eventually. The method
+      returns a transfer identifier and object path for cancelling or tracking the export operation, similarly
+      to <function>ImportTar()</function> or <function>ImportRaw()</function> as described above.</para>
+
+      <para><function>PullTar()</function> and <function>PullRaw()</function> may be used to download, verify
+      and import a system image from a URL. They take a URL argument which should point to a tar or
+      raw file on the <literal>http://</literal> or <literal>https://</literal> protocols, possibly
+      compressed with xz, bzip2 or gzip. The second argument is a local name for the image. It should be
+      suitable as a hostname, similarly to the matching argument of the <function>ImportTar()</function> and
+      <function>ImportRaw()</function> methods above. The third argument indicates the verification mode for
+      the image. It may be one of <literal>no</literal>, <literal>checksum</literal>,
+      <literal>signature</literal>. <literal>no</literal> turns off any kind of verification of the image;
+      <literal>checksum</literal> looks for a <filename>SHA256SUM</filename> file next to the downloaded
+      image and verifies any SHA256 hash value in that file against the image; <literal>signature</literal>
+      does the same but also tries to authenticate the <filename>SHA256SUM</filename> file via
+      <citerefentry project="man-pages"><refentrytitle>gpg</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+      first. The last argument indicates whether to replace a possibly pre-existing image with the same local
+      name (if <literal>true</literal>), or whether to fail (if <literal>false</literal>). Like the import
+      and export calls above, these calls return a pair of transfer identifier and object path for the ongoing
+      download.</para>
+
+      <para><function>ListTransfers()</function> returns a list of ongoing import, export or download
+      operations as created with the six calls described above. It returns an array of structures which
+      consist of the numeric transfer identifier, a string indicating the operation (one of
+      <literal>import-tar</literal>, <literal>import-raw</literal>, <literal>export-tar</literal>,
+      <literal>export-raw</literal>, <literal>pull-tar</literal> or <literal>pull-raw</literal>), a string
+      describing the remote file (in case of download operations this is the source URL, in case of
+      import/export operations this is a short string describing the file descriptor passed in), a string
+      with the local machine image name, a progress value between 0.0 (for 0%) and 1.0 (for 100%), as well as
+      the transfer object path.</para>
+
+      <para><function>CancelTransfer()</function> may be used to cancel an ongoing import, export or download
+      operation. Simply specify the transfer identifier to cancel the ongoing operation.</para>
+    </refsect2>
+
+    <refsect2>
+      <title>Signals</title>
+
+      <para>The <function>TransferNew</function> signal is generated each time a new transfer is started with
+      the import, export or download calls described above. It carries the transfer ID and object path that
+      have just been created.</para>
+
+      <para>The <function>TransferRemoved</function> signal is sent each time a transfer finishes,
+      is canceled or fails. It also carries the transfer ID and object path, followed by a string indicating
+      the result of the operation, which is one of <literal>done</literal> (on success),
+      <literal>canceled</literal> or <literal>failed</literal>.</para>
+    </refsect2>
+  </refsect1>
+
+  <refsect1>
+    <title>The Transfer Object</title>
+
+    <programlisting executable="systemd-importd" node="/org/freedesktop/import1/transfer/_1" interface="org.freedesktop.import1.Transfer">
+node /org/freedesktop/import1/transfer/_1 {
+  interface org.freedesktop.import1.Transfer {
+    methods:
+      Cancel();
+    signals:
+      LogMessage(u priority,
+                 s line);
+    properties:
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly u Id = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s Local = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s Remote = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s Type = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s Verify = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly d Progress = ...;
+  };
+  interface org.freedesktop.DBus.Peer { ... };
+  interface org.freedesktop.DBus.Introspectable { ... };
+  interface org.freedesktop.DBus.Properties { ... };
+};
+    </programlisting>
+
+    <!--signal LogMessage is not documented!-->
+
+    <!--Autogenerated cross-references for systemd.directives, do not edit-->
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.import1.Transfer"/>
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.import1.Transfer"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="Cancel()"/>
+
+    <variablelist class="dbus-signal" generated="True" extra-ref="LogMessage"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Id"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Local"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Remote"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Type"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Verify"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Progress"/>
+
+    <!--End of Autogenerated section-->
+
+    <refsect2>
+      <title>Methods</title>
+
+      <para>The <function>Cancel()</function> method may be used to cancel the transfer. It takes no
+      parameters. This method is pretty much equivalent to the <function>CancelTransfer()</function> method
+      on the <structname>Manager</structname> interface (see above), but is exposed on the
+      <structname>Transfer</structname> object itself instead of taking a transfer ID.</para>
+    </refsect2>
+
+    <refsect2>
+      <title>Properties</title>
+
+      <para>The <varname>Id</varname> property exposes the numeric transfer ID of the transfer object.</para>
+
+      <para>The <varname>Local</varname>, <varname>Remote</varname> and <varname>Type</varname> properties
+      expose the local container name of this transfer, the remote source (in case of download: the URL, in
+      case of import/export: a string describing the file descriptor passed in), and the type of operation
+      (see the Manager's <function>ListTransfer()</function> method above for an explanation of the possible
+      values).</para>
+
+      <para>The <varname>Verify</varname> property exposes the selected verification setting and is only
+      defined for download operations (see above).</para>
+
+      <para>The <varname>Progress</varname> property exposes the current progress of the transfer as a value
+      between 0.0 and 1.0. To show a progress bar on screen we recommend to query this value in regular
+      intervals, for example every 500 ms or so.</para>
+    </refsect2>
+  </refsect1>
+
+  <refsect1>
+    <title>Examples</title>
+
+    <example>
+      <title>Introspect <interfacename>org.freedesktop.import1.Manager</interfacename> on the bus</title>
+
+      <programlisting>$ gdbus introspect --system \
+  --dest org.freedesktop.import1 \
+  --object-path /org/freedesktop/import1
+      </programlisting>
+    </example>
+
+    <example>
+      <title>Introspect <interfacename>org.freedesktop.import1.Transfer</interfacename> on the bus</title>
+
+      <programlisting>$ gdbus introspect --system \
+  --dest org.freedesktop.import1 \
+  --object-path /org/freedesktop/import1/transfer/_1
+      </programlisting>
+    </example>
+  </refsect1>
+
+  <xi:include href="org.freedesktop.locale1.xml" xpointer="versioning"/>
+</refentry>
diff --git a/man/org.freedesktop.locale1.xml b/man/org.freedesktop.locale1.xml
new file mode 100644
index 0000000..d5c93af
--- /dev/null
+++ b/man/org.freedesktop.locale1.xml
@@ -0,0 +1,188 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" >
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="org.freedesktop.locale1" conditional='ENABLE_LOCALED'
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+  <refentryinfo>
+    <title>org.freedesktop.locale1</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>org.freedesktop.locale1</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>org.freedesktop.locale1</refname>
+    <refpurpose>The D-Bus interface of systemd-localed</refpurpose>
+  </refnamediv>
+
+  <refsect1>
+    <title>Introduction</title>
+
+    <para>
+    <citerefentry><refentrytitle>systemd-localed.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    is a system service that can be used to control the system locale and keyboard mapping from user
+    programs. This page describes the D-Bus interface.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>The D-Bus API</title>
+
+    <para>The service exposes the following interfaces on the bus:</para>
+
+    <programlisting executable="systemd-localed" node="/org/freedesktop/locale1" interface="org.freedesktop.locale1">
+node /org/freedesktop/locale1 {
+  interface org.freedesktop.locale1 {
+    methods:
+      SetLocale(in  as locale,
+                in  b interactive);
+      SetVConsoleKeyboard(in  s keymap,
+                          in  s keymap_toggle,
+                          in  b convert,
+                          in  b interactive);
+      SetX11Keyboard(in  s layout,
+                     in  s model,
+                     in  s variant,
+                     in  s options,
+                     in  b convert,
+                     in  b interactive);
+    properties:
+      readonly as Locale = ['...', ...];
+      readonly s X11Layout = '...';
+      readonly s X11Model = '...';
+      readonly s X11Variant = '...';
+      readonly s X11Options = '...';
+      readonly s VConsoleKeymap = '...';
+      readonly s VConsoleKeymapToggle = '...';
+  };
+  interface org.freedesktop.DBus.Peer { ... };
+  interface org.freedesktop.DBus.Introspectable { ... };
+  interface org.freedesktop.DBus.Properties { ... };
+};
+    </programlisting>
+
+    <!--Autogenerated cross-references for systemd.directives, do not edit-->
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.locale1"/>
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.locale1"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SetLocale()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SetVConsoleKeyboard()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SetX11Keyboard()"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Locale"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="X11Layout"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="X11Model"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="X11Variant"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="X11Options"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="VConsoleKeymap"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="VConsoleKeymapToggle"/>
+
+    <!--End of Autogenerated section-->
+
+    <refsect2>
+      <title>Methods</title>
+
+      <para>If you set a new system locale all old system locale settings will be dropped and the new
+      settings will be saved to disk. The locale will also be passed to the system manager, and subsequently started
+      daemons will inherit the new system locale. Note that already running daemons will not learn about the
+      new value.</para>
+
+      <para>The <function>SetVConsoleKeyboard()</function> method may be used to set the key mapping for the
+      virtual console. Similarly, <function>SetX11Keyboard()</function> may be used to set the default key
+      mapping of any X11 servers.</para>
+
+      <para>Note that <function>SetVConsoleKeyboard()</function> instantly applies the new key mapping to the
+      console, while <function>SetX11Keyboard()</function> simply sets a default that may be used by later
+      sessions.</para>
+
+      <para>The boolean argument <varname>convert</varname> may be set to optionally convert the console
+      keyboard configuration to X11 keyboard mappings and vice versa. If true and
+      <function>SetVConsoleKeyboard()</function> is used, the nearest X11 keyboard setting for the chosen
+      console setting is set. If true and <function>SetX11Keyboard()</function> is used, the nearest console
+      keyboard setting for the chosen X11 setting is set. Hence, it is usually sufficient to call only one of the
+      two functions.</para>
+
+      <para>For graphical UIs that need to set the system keyboard mapping simply invoke
+      <function>SetX11Keyboard()</function>, set <varname>convert=true</varname> and ignore
+      <function>SetVConsoleKeyboard()</function>.</para>
+
+      <para>Use the empty string for the keymap parameters you wish not to set.</para>
+
+      <para>The <varname>interactive</varname> boolean parameters can be used to control whether
+      <ulink url="https://www.freedesktop.org/software/polkit/docs/latest/">polkit</ulink>
+      should interactively ask the user for authentication credentials if required.</para>
+    </refsect2>
+
+    <refsect2>
+      <title>Signals</title>
+
+      <para>Whenever the system locale or keymap is changed via the daemon,
+      <function>PropertyChanged</function> signals are sent out to which clients can subscribe.</para>
+    </refsect2>
+
+    <refsect2>
+      <title>Properties</title>
+
+      <para>The system locale is shown in the <varname>Locale</varname> property. It is an array containing
+      environment-variable-assignment-like strings. The following strings are known:
+      <varname>LANG=</varname>, <varname>LC_CTYPE=</varname>, <varname>LC_NUMERIC=</varname>,
+      <varname>LC_TIME=</varname>, <varname>LC_COLLATE=</varname>, <varname>LC_MONETARY=</varname>,
+      <varname>LC_MESSAGES=</varname>, <varname>LC_PAPER=</varname>, <varname>LC_NAME=</varname>,
+      <varname>LC_ADDRESS=</varname>, <varname>LC_TELEPHONE=</varname>, <varname>LC_MEASUREMENT=</varname>,
+      <varname>LC_IDENTIFICATION=</varname>.</para>
+
+      <para>The <varname>X11Layout</varname>, <varname>X11Model</varname>, <varname>X11Variant</varname>, and
+      <varname>X11Options</varname> properties show values configurable with
+      <function>SetX11Keyboard()</function> described above (or <function>SetVConsoleKeyboard()</function>
+      with <varname>convert=true</varname>). The <varname>VConsoleKeymap</varname> and
+      <varname>VConsoleKeymapToggle</varname> properties show values configurable with
+      <function>SetVConsoleKeyboard()</function> (or <function>SetX11Keyboard()</function> with
+      <varname>convert=true</varname>).</para>
+    </refsect2>
+
+    <refsect2>
+      <title>Security</title>
+
+      <para>Changing the system locale or keymap using this interface is authenticated via polkit. The
+      polkit action for <function>SetLocale()</function> is
+      <constant>org.freedesktop.locale1.set-locale</constant>. The polkit action for
+      <function>SetX11Keyboard()</function> and <function>SetVConsoleKeyboard()</function> is
+      <constant>org.freedesktop.locale1.set-keyboard</constant>.</para>
+    </refsect2>
+  </refsect1>
+
+  <refsect1>
+    <title>Examples</title>
+
+    <example>
+      <title>Introspect <interfacename>org.freedesktop.locale1</interfacename> on the bus</title>
+
+      <programlisting>
+$ gdbus introspect --system \
+  --dest org.freedesktop.locale1 \
+  --object-path /org/freedesktop/locale1
+      </programlisting>
+    </example>
+  </refsect1>
+
+  <refsect1 id="versioning">
+    <title>Versioning</title>
+
+    <para>These D-Bus interfaces follow <ulink url="https://0pointer.de/blog/projects/versioning-dbus.html">
+    the usual interface versioning guidelines</ulink>.</para>
+  </refsect1>
+</refentry>
diff --git a/man/org.freedesktop.login1.xml b/man/org.freedesktop.login1.xml
new file mode 100644
index 0000000..519a686
--- /dev/null
+++ b/man/org.freedesktop.login1.xml
@@ -0,0 +1,1555 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" >
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="org.freedesktop.login1" conditional='ENABLE_LOGIND'
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+  <refentryinfo>
+    <title>org.freedesktop.login1</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>org.freedesktop.login1</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>org.freedesktop.login1</refname>
+    <refpurpose>The D-Bus interface of systemd-logind</refpurpose>
+  </refnamediv>
+
+  <refsect1>
+    <title>Introduction</title>
+
+    <para><citerefentry><refentrytitle>systemd-logind.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    is a system service that keeps track of user logins and seats.</para>
+
+    <para>The daemon provides both a C library interface as well as a D-Bus interface. The library interface
+    may be used to introspect and watch the state of user logins and seats. The bus interface provides the
+    same functionality but in addition may also be used to make changes to the system state. For more information please
+    consult <citerefentry><refentrytitle>sd-login</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+    </para>
+  </refsect1>
+
+  <refsect1>
+    <title>The Manager Object</title>
+
+    <para>The service exposes the following interfaces on the Manager object on the bus:</para>
+
+    <programlisting executable="systemd-logind" node="/org/freedesktop/login1" interface="org.freedesktop.login1.Manager">
+node /org/freedesktop/login1 {
+  interface org.freedesktop.login1.Manager {
+    methods:
+      GetSession(in  s session_id,
+                 out o object_path);
+      GetSessionByPID(in  u pid,
+                      out o object_path);
+      GetUser(in  u uid,
+              out o object_path);
+      GetUserByPID(in  u pid,
+                   out o object_path);
+      GetSeat(in  s seat_id,
+              out o object_path);
+      ListSessions(out a(susso) sessions);
+      ListUsers(out a(uso) users);
+      ListSeats(out a(so) seats);
+      ListInhibitors(out a(ssssuu) inhibitors);
+      @org.freedesktop.systemd1.Privileged("true")
+      CreateSession(in  u uid,
+                    in  u pid,
+                    in  s service,
+                    in  s type,
+                    in  s class,
+                    in  s desktop,
+                    in  s seat_id,
+                    in  u vtnr,
+                    in  s tty,
+                    in  s display,
+                    in  b remote,
+                    in  s remote_user,
+                    in  s remote_host,
+                    in  a(sv) properties,
+                    out s session_id,
+                    out o object_path,
+                    out s runtime_path,
+                    out h fifo_fd,
+                    out u uid,
+                    out s seat_id,
+                    out u vtnr,
+                    out b existing);
+      @org.freedesktop.systemd1.Privileged("true")
+      CreateSessionWithPIDFD(in  u uid,
+                             in  h pidfd,
+                             in  s service,
+                             in  s type,
+                             in  s class,
+                             in  s desktop,
+                             in  s seat_id,
+                             in  u vtnr,
+                             in  s tty,
+                             in  s display,
+                             in  b remote,
+                             in  s remote_user,
+                             in  s remote_host,
+                             in  t flags,
+                             in  a(sv) properties,
+                             out s session_id,
+                             out o object_path,
+                             out s runtime_path,
+                             out h fifo_fd,
+                             out u uid,
+                             out s seat_id,
+                             out u vtnr,
+                             out b existing);
+      @org.freedesktop.systemd1.Privileged("true")
+      ReleaseSession(in  s session_id);
+      ActivateSession(in  s session_id);
+      ActivateSessionOnSeat(in  s session_id,
+                            in  s seat_id);
+      LockSession(in  s session_id);
+      UnlockSession(in  s session_id);
+      LockSessions();
+      UnlockSessions();
+      KillSession(in  s session_id,
+                  in  s who,
+                  in  i signal_number);
+      KillUser(in  u uid,
+               in  i signal_number);
+      TerminateSession(in  s session_id);
+      TerminateUser(in  u uid);
+      TerminateSeat(in  s seat_id);
+      SetUserLinger(in  u uid,
+                    in  b enable,
+                    in  b interactive);
+      AttachDevice(in  s seat_id,
+                   in  s sysfs_path,
+                   in  b interactive);
+      FlushDevices(in  b interactive);
+      PowerOff(in  b interactive);
+      PowerOffWithFlags(in  t flags);
+      Reboot(in  b interactive);
+      RebootWithFlags(in  t flags);
+      Halt(in  b interactive);
+      HaltWithFlags(in  t flags);
+      Suspend(in  b interactive);
+      SuspendWithFlags(in  t flags);
+      Hibernate(in  b interactive);
+      HibernateWithFlags(in  t flags);
+      HybridSleep(in  b interactive);
+      HybridSleepWithFlags(in  t flags);
+      SuspendThenHibernate(in  b interactive);
+      SuspendThenHibernateWithFlags(in  t flags);
+      CanPowerOff(out s result);
+      CanReboot(out s result);
+      CanHalt(out s result);
+      CanSuspend(out s result);
+      CanHibernate(out s result);
+      CanHybridSleep(out s result);
+      CanSuspendThenHibernate(out s result);
+      ScheduleShutdown(in  s type,
+                       in  t usec);
+      CancelScheduledShutdown(out b cancelled);
+      Inhibit(in  s what,
+              in  s who,
+              in  s why,
+              in  s mode,
+              out h pipe_fd);
+      CanRebootParameter(out s result);
+      SetRebootParameter(in  s parameter);
+      CanRebootToFirmwareSetup(out s result);
+      SetRebootToFirmwareSetup(in  b enable);
+      CanRebootToBootLoaderMenu(out s result);
+      SetRebootToBootLoaderMenu(in  t timeout);
+      CanRebootToBootLoaderEntry(out s result);
+      SetRebootToBootLoaderEntry(in  s boot_loader_entry);
+      SetWallMessage(in  s wall_message,
+                     in  b enable);
+    signals:
+      SessionNew(s session_id,
+                 o object_path);
+      SessionRemoved(s session_id,
+                     o object_path);
+      UserNew(u uid,
+              o object_path);
+      UserRemoved(u uid,
+                  o object_path);
+      SeatNew(s seat_id,
+              o object_path);
+      SeatRemoved(s seat_id,
+                  o object_path);
+      PrepareForShutdown(b start);
+      PrepareForShutdownWithMetadata(b start,
+                                     a{sv} metadata);
+      PrepareForSleep(b start);
+    properties:
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      @org.freedesktop.systemd1.Privileged("true")
+      readwrite b EnableWallMessages = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      @org.freedesktop.systemd1.Privileged("true")
+      readwrite s WallMessage = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly u NAutoVTs = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as KillOnlyUsers = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as KillExcludeUsers = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b KillUserProcesses = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s RebootParameter = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly b RebootToFirmwareSetup = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t RebootToBootLoaderMenu = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s RebootToBootLoaderEntry = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as BootLoaderEntries = ['...', ...];
+      readonly b IdleHint = ...;
+      readonly t IdleSinceHint = ...;
+      readonly t IdleSinceHintMonotonic = ...;
+      readonly s BlockInhibited = '...';
+      readonly s DelayInhibited = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t InhibitDelayMaxUSec = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t UserStopDelayUSec = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s HandlePowerKey = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s HandlePowerKeyLongPress = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s HandleRebootKey = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s HandleRebootKeyLongPress = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s HandleSuspendKey = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s HandleSuspendKeyLongPress = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s HandleHibernateKey = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s HandleHibernateKeyLongPress = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s HandleLidSwitch = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s HandleLidSwitchExternalPower = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s HandleLidSwitchDocked = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t HoldoffTimeoutUSec = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s IdleAction = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t IdleActionUSec = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly b PreparingForShutdown = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly b PreparingForSleep = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly (st) ScheduledShutdown = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly b Docked = ...;
+      readonly b LidClosed = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly b OnExternalPower = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b RemoveIPC = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t RuntimeDirectorySize = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t RuntimeDirectoryInodesMax = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t InhibitorsMax = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t NCurrentInhibitors = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t SessionsMax = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t NCurrentSessions = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t StopIdleSessionUSec = ...;
+  };
+  interface org.freedesktop.DBus.Peer { ... };
+  interface org.freedesktop.DBus.Introspectable { ... };
+  interface org.freedesktop.DBus.Properties { ... };
+};
+    </programlisting>
+
+    <!--property HandlePowerKeyLongPress is not documented!-->
+
+    <!--property HandleRebootKey is not documented!-->
+
+    <!--property HandleRebootKeyLongPress is not documented!-->
+
+    <!--property HandleSuspendKeyLongPress is not documented!-->
+
+    <!--property HandleHibernateKeyLongPress is not documented!-->
+
+    <!--property StopIdleSessionUSec is not documented!-->
+
+    <!--Autogenerated cross-references for systemd.directives, do not edit-->
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.login1.Manager"/>
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.login1.Manager"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="GetSession()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="GetSessionByPID()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="GetUser()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="GetUserByPID()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="GetSeat()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="ListSessions()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="ListUsers()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="ListSeats()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="ListInhibitors()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="CreateSession()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="CreateSessionWithPIDFD()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="ReleaseSession()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="ActivateSession()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="ActivateSessionOnSeat()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="LockSession()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="UnlockSession()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="LockSessions()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="UnlockSessions()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="KillSession()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="KillUser()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="TerminateSession()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="TerminateUser()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="TerminateSeat()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SetUserLinger()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="AttachDevice()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="FlushDevices()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="PowerOff()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="PowerOffWithFlags()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="Reboot()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="RebootWithFlags()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="Halt()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="HaltWithFlags()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="Suspend()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SuspendWithFlags()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="Hibernate()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="HibernateWithFlags()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="HybridSleep()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="HybridSleepWithFlags()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SuspendThenHibernate()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SuspendThenHibernateWithFlags()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="CanPowerOff()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="CanReboot()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="CanHalt()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="CanSuspend()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="CanHibernate()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="CanHybridSleep()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="CanSuspendThenHibernate()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="ScheduleShutdown()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="CancelScheduledShutdown()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="Inhibit()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="CanRebootParameter()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SetRebootParameter()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="CanRebootToFirmwareSetup()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SetRebootToFirmwareSetup()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="CanRebootToBootLoaderMenu()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SetRebootToBootLoaderMenu()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="CanRebootToBootLoaderEntry()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SetRebootToBootLoaderEntry()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SetWallMessage()"/>
+
+    <variablelist class="dbus-signal" generated="True" extra-ref="SessionNew"/>
+
+    <variablelist class="dbus-signal" generated="True" extra-ref="SessionRemoved"/>
+
+    <variablelist class="dbus-signal" generated="True" extra-ref="UserNew"/>
+
+    <variablelist class="dbus-signal" generated="True" extra-ref="UserRemoved"/>
+
+    <variablelist class="dbus-signal" generated="True" extra-ref="SeatNew"/>
+
+    <variablelist class="dbus-signal" generated="True" extra-ref="SeatRemoved"/>
+
+    <variablelist class="dbus-signal" generated="True" extra-ref="PrepareForShutdown"/>
+
+    <variablelist class="dbus-signal" generated="True" extra-ref="PrepareForShutdownWithMetadata"/>
+
+    <variablelist class="dbus-signal" generated="True" extra-ref="PrepareForSleep"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="EnableWallMessages"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="WallMessage"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="NAutoVTs"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="KillOnlyUsers"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="KillExcludeUsers"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="KillUserProcesses"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RebootParameter"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RebootToFirmwareSetup"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RebootToBootLoaderMenu"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RebootToBootLoaderEntry"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="BootLoaderEntries"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IdleHint"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IdleSinceHint"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IdleSinceHintMonotonic"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="BlockInhibited"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DelayInhibited"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="InhibitDelayMaxUSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="UserStopDelayUSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="HandlePowerKey"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="HandlePowerKeyLongPress"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="HandleRebootKey"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="HandleRebootKeyLongPress"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="HandleSuspendKey"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="HandleSuspendKeyLongPress"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="HandleHibernateKey"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="HandleHibernateKeyLongPress"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="HandleLidSwitch"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="HandleLidSwitchExternalPower"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="HandleLidSwitchDocked"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="HoldoffTimeoutUSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IdleAction"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IdleActionUSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="PreparingForShutdown"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="PreparingForSleep"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ScheduledShutdown"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Docked"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LidClosed"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="OnExternalPower"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RemoveIPC"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RuntimeDirectorySize"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RuntimeDirectoryInodesMax"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="InhibitorsMax"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="NCurrentInhibitors"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SessionsMax"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="NCurrentSessions"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StopIdleSessionUSec"/>
+
+    <!--End of Autogenerated section-->
+
+    <refsect2>
+      <title>Methods</title>
+
+      <para><function>GetSession()</function> may be used to get the session object path for the session with
+      the specified ID. Similarly, <function>GetUser()</function> and <function>GetSeat()</function> get the
+      user and seat objects, respectively. <function>GetSessionByPID()</function> and
+      <function>GetUserByPID()</function> get the session/user object the specified PID belongs to if there
+      is any.</para>
+
+      <para><function>ListSessions()</function> returns an array of all current sessions. The structures in
+      the array consist of the following fields: session id, user id, user name, seat id, session object
+      path. If a session does not have a seat attached, the seat id field will be an empty string.</para>
+
+      <para><function>ListUsers()</function> returns an array of all currently logged in users. The
+      structures in the array consist of the following fields: user id, user name, user object path.</para>
+
+      <para><function>ListSeats()</function> returns an array of all currently available seats. The
+      structure in the array consists of the following fields: seat id, seat object path.</para>
+
+      <para><function>ListInhibitors()</function> lists all currently active inhibitors. It returns an array of
+      structures consisting of <varname>what</varname>, <varname>who</varname>, <varname>why</varname>,
+      <varname>mode</varname>, <varname>uid</varname> (user ID), and <varname>pid</varname> (process ID).</para>
+
+      <para><function>CreateSession()</function>, <function>CreateSessionWithPIDFD()</function>, and
+      <function>ReleaseSession()</function> may be used to open or close login sessions. These calls should
+      <emphasis>never</emphasis> be invoked directly by clients. Creating/closing sessions is exclusively the job
+      of PAM and its <citerefentry><refentrytitle>pam_systemd</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+      module.</para>
+
+      <para><function>ActivateSession()</function> brings the session with the specified ID into the
+      foreground. <function>ActivateSessionOnSeat()</function> does the same, but only if the seat id
+      matches.</para>
+
+      <para><function>LockSession()</function> asks the session with the specified ID to activate the screen
+      lock. <function>UnlockSession()</function> asks the session with the specified ID to remove an active
+      screen lock, if there is any. This is implemented by sending out the Lock() and Unlock() signals from
+      the respective session object which session managers are supposed to listen on.</para>
+
+      <para><function>LockSessions()</function> asks all sessions to activate their screen locks. This may be
+      used to lock access to the entire machine in one action. Similarly, <function>UnlockSessions()</function>
+      asks all sessions to deactivate their screen locks.</para>
+
+      <para><function>KillSession()</function> may be used to send a Unix signal to one or all processes of a
+      session. As arguments it takes the session id, either the string <literal>leader</literal> or
+      <literal>all</literal> and a signal number. If <literal>leader</literal> is passed only the session
+      <literal>leader</literal> is killed. If <literal>all</literal> is passed all processes of the session
+      are killed.</para>
+
+      <para><function>KillUser()</function> may be used to send a Unix signal to all processes of a user. As
+      arguments it takes the user id and a signal number.</para>
+
+      <para><function>TerminateSession()</function>, <function>TerminateUser()</function>,
+      <function>TerminateSeat()</function> may be used to forcibly terminate one specific session, all
+      processes of a user, and all sessions attached to a specific seat, respectively. The session, user,
+      and seat are identified by their respective IDs.</para>
+
+      <para><function>SetUserLinger()</function> enables or disables user lingering. If enabled, the runtime
+      directory of a user is kept around and they may continue to run processes while logged out. If
+      disabled, the runtime directory goes away as soon as they log out. <function>SetUserLinger()</function>
+      expects three arguments: the UID, a boolean whether to enable/disable and a boolean controlling the
+      <ulink url="https://www.freedesktop.org/software/polkit/docs/latest/">polkit</ulink>
+      authorization interactivity (see below). Note that the user linger state is persistently
+      stored on disk.</para>
+
+      <para><function>AttachDevice()</function> may be used to assign a specific device to a specific
+      seat. The device is identified by its <filename>/sys/</filename> path and must be eligible for seat
+      assignments. <function>AttachDevice()</function> takes three arguments: the seat id, the sysfs path,
+      and a boolean for controlling polkit interactivity (see below). Device assignments are persistently
+      stored on disk. To create a new seat, simply specify a previously unused seat id. For more information
+      about the seat assignment logic see
+      <citerefentry><refentrytitle>sd-login</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para>
+
+      <para><function>FlushDevices()</function> removes all explicit seat assignments for devices, resetting
+      all assignments to the automatic defaults. The only argument it takes is the polkit interactivity
+      boolean (see below).</para>
+
+      <para><function>PowerOff()</function>, <function>Reboot()</function>, <function>Halt()</function>,
+      <function>Suspend()</function>, and <function>Hibernate()</function> result in the system being powered
+      off, rebooted, halted (shut down without turning off power), suspended (the system state is saved to
+      RAM and the CPU is turned off), or hibernated (the system state is saved to disk and the machine is
+      powered down). <function>HybridSleep()</function> results in the system entering a hybrid-sleep mode,
+      i.e. the system is both hibernated and suspended.  <function>SuspendThenHibernate()</function> results
+      in the system being suspended, then later woken using an RTC timer and hibernated. The only argument is
+      the polkit interactivity boolean <varname>interactive</varname> (see below). The main purpose of these
+      calls is that they enforce polkit policy and hence allow powering off/rebooting/suspending/hibernating
+      even by unprivileged users. They also enforce inhibition locks for non-privileged users. UIs should
+      expose these calls as the primary mechanism to poweroff/reboot/suspend/hibernate the machine. Methods
+      <function>PowerOffWithFlags()</function>, <function>RebootWithFlags()</function>,
+      <function>HaltWithFlags()</function>, <function>SuspendWithFlags()</function>,
+      <function>HibernateWithFlags()</function>, <function>HybridSleepWithFlags()</function> and
+      <function>SuspendThenHibernateWithFlags()</function> add <varname>flags</varname> to allow for
+      extendability, defined as follows:</para>
+      <programlisting>
+#define SD_LOGIND_ROOT_CHECK_INHIBITORS          (UINT64_C(1) &lt;&lt; 0)
+#define SD_LOGIND_KEXEC_REBOOT                   (UINT64_C(1) &lt;&lt; 1)
+#define SD_LOGIND_SOFT_REBOOT                    (UINT64_C(1) &lt;&lt; 2)
+#define SD_LOGIND_SOFT_REBOOT_IF_NEXTROOT_SET_UP (UINT64_C(1) &lt;&lt; 3)
+      </programlisting>
+      <para>When the <varname>flags</varname> is 0 then these methods behave just like the versions without
+      flags. When <constant>SD_LOGIND_ROOT_CHECK_INHIBITORS</constant> (0x01) is set, active inhibitors are
+      honoured for privileged users too. When <constant>SD_LOGIND_KEXEC_REBOOT</constant> (0x02) is set,
+      then <function>RebootWithFlags()</function> performs a kexec reboot if kexec kernel is loaded. When
+      <constant>SD_LOGIND_SOFT_REBOOT</constant> (0x04) is set, or
+      <constant>SD_LOGIND_SOFT_REBOOT_IF_NEXTROOT_SET_UP</constant> (0x08) is set and a new root file system
+      has been set up on <literal>/run/nextroot/</literal>, then <function>RebootWithFlags()</function>
+      performs a userspace reboot only. <constant>SD_LOGIND_SOFT_REBOOT_IF_NEXTROOT_SET_UP</constant> and
+      <constant>SD_LOGIND_KEXEC_REBOOT</constant> can be combined, with soft-reboot having precedence.</para>
+
+      <para><function>SetRebootParameter()</function> sets a parameter for a subsequent reboot operation.
+      See the description of <command>reboot</command> in
+      <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> and
+      <citerefentry project="man-pages"><refentrytitle>reboot</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+      for more information.</para>
+
+      <para><function>SetRebootToFirmwareSetup()</function>,
+      <function>SetRebootToBootLoaderMenu()</function>, and <function>SetRebootToBootLoaderEntry()</function>
+      configure the action to be taken from the boot loader after a reboot: respectively entering firmware
+      setup mode, the boot loader menu, or a specific boot loader entry. See
+      <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> for the
+      corresponding command line interface.</para>
+
+      <para><function>CanPowerOff()</function>, <function>CanReboot()</function>,
+      <function>CanHalt()</function>, <function>CanSuspend()</function>, <function>CanHibernate()</function>,
+      <function>CanHybridSleep()</function>, <function>CanSuspendThenHibernate()</function>,
+      <function>CanRebootParameter()</function>, <function>CanRebootToFirmwareSetup()</function>,
+      <function>CanRebootToBootLoaderMenu()</function>, and
+      <function>CanRebootToBootLoaderEntry()</function> test whether the system supports the respective
+      operation and whether the calling user is allowed to execute it. Returns one of <literal>na</literal>,
+      <literal>yes</literal>, <literal>no</literal>, and <literal>challenge</literal>. If
+      <literal>na</literal> is returned, the operation is not available because hardware, kernel, or drivers
+      do not support it. If <literal>yes</literal> is returned, the operation is supported and the user may
+      execute the operation without further authentication. If <literal>no</literal> is returned, the
+      operation is available but the user is not allowed to execute the operation. If
+      <literal>challenge</literal> is returned, the operation is available but only after
+      authorization.</para>
+
+      <para><function>ScheduleShutdown()</function> schedules a shutdown operation <varname>type</varname> at
+      time <varname>usec</varname> in microseconds since the UNIX epoch. <varname>type</varname> can be one
+      of <literal>poweroff</literal>, <literal>dry-poweroff</literal>, <literal>reboot</literal>,
+      <literal>dry-reboot</literal>, <literal>halt</literal>, and <literal>dry-halt</literal>. (The
+      <literal>dry-</literal> variants do not actually execute the shutdown action.)
+      <function>CancelScheduledShutdown()</function> cancels a scheduled shutdown. The output parameter
+      <varname>cancelled</varname> is true if a shutdown operation was scheduled.</para>
+
+      <para><function>SetWallMessage()</function> sets the wall message (the message that will be sent out to
+      all terminals and stored in a
+      <citerefentry project="man-pages"><refentrytitle>utmp</refentrytitle><manvolnum>5</manvolnum></citerefentry> record) for a
+      subsequent scheduled shutdown operation. The parameter <varname>wall_message</varname> specifies the
+      shutdown reason (and may be empty) which will be included in the shutdown message. The parameter
+      <varname>enable</varname> specifies whether to print a wall message on shutdown.</para>
+
+      <para><function>Inhibit()</function> creates an inhibition lock. It takes four parameters:
+      <varname>what</varname>, <varname>who</varname>, <varname>why</varname>, and
+      <varname>mode</varname>. <varname>what</varname> is one or more of <literal>shutdown</literal>,
+      <literal>sleep</literal>, <literal>idle</literal>, <literal>handle-power-key</literal>,
+      <literal>handle-suspend-key</literal>, <literal>handle-hibernate-key</literal>,
+      <literal>handle-lid-switch</literal>, separated by colons, for inhibiting poweroff/reboot,
+      suspend/hibernate, the automatic idle logic, or hardware key handling. <varname>who</varname> should be
+      a short human readable string identifying the application taking the lock. <varname>why</varname>
+      should be a short human readable string identifying the reason why the lock is taken. Finally,
+      <varname>mode</varname> is either <literal>block</literal> or <literal>delay</literal> which encodes
+      whether the inhibit shall be consider mandatory or whether it should just delay the operation to a
+      certain maximum time. The method returns a file descriptor. The lock is released the moment this file
+      descriptor and all its duplicates are closed. For more information on the inhibition logic see
+      <ulink url="https://www.freedesktop.org/wiki/Software/systemd/inhibit">Inhibitor Locks</ulink>.
+      </para>
+    </refsect2>
+
+    <refsect2>
+      <title>Signals</title>
+
+      <para>Whenever the inhibition state or idle hint changes, <function>PropertyChanged</function>
+      signals are sent out to which clients can subscribe.</para>
+
+      <para>The <function>SessionNew</function>, <function>SessionRemoved</function>,
+      <function>UserNew</function>, <function>UserRemoved</function>, <function>SeatNew</function>, and
+      <function>SeatRemoved</function> signals are sent each time a session is created or removed, a user
+      logs in or out, or a seat is added or removed. They each contain the ID of the object plus the object
+      path.</para>
+
+      <para>The <function>PrepareForShutdown</function>,
+      <function>PrepareForShutdownWithMetadata</function>, and <function>PrepareForSleep</function>
+      signals are sent right before (with the argument <literal>true</literal>) or after (with the argument
+      <literal>false</literal>) the system goes down for reboot/poweroff and suspend/hibernate,
+      respectively. This may be used by applications to save data on disk, release memory, or do other jobs
+      that should be done shortly before shutdown/sleep, in conjunction with delay inhibitor locks. After
+      completion of this work they should release their inhibition locks in order to not delay the operation
+      any further. For more information see
+      <ulink url="https://www.freedesktop.org/wiki/Software/systemd/inhibit">Inhibitor Locks</ulink>. The
+      <function>PrepareForShutdownWithMetadata()</function> signal additionally sends a list of key/value
+      pair metadata fields. Currently it sends a <varname>type</varname> string which defines the type of
+      shutdown. The type can be one of <literal>power-off</literal>, <literal>reboot</literal>,
+      <literal>halt</literal>, <literal>kexec</literal> or <literal>soft-reboot</literal>. This signal is
+      sent first, followed by <function>PrepareForShutdown</function> (for backward compatibility).</para>
+    </refsect2>
+
+    <refsect2>
+      <title>Properties</title>
+
+      <para>Most properties simply reflect the configuration, see
+      <citerefentry><refentrytitle>logind.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>. This
+      includes: <varname>NAutoVTs</varname>, <varname>KillOnlyUsers</varname>,
+      <varname>KillExcludeUsers</varname>, <varname>KillUserProcesses</varname>, <varname>IdleAction</varname>,
+      <varname>InhibitDelayMaxUSec</varname>,
+      <varname>InhibitorsMax</varname>,
+      <varname>UserStopDelayUSec</varname>,
+      <varname>HandlePowerKey</varname>, <varname>HandleSuspendKey</varname>,
+      <varname>HandleHibernateKey</varname>, <varname>HandleLidSwitch</varname>,
+      <varname>HandleLidSwitchExternalPower</varname>, <varname>HandleLidSwitchDocked</varname>,
+      <varname>IdleActionUSec</varname>, <varname>HoldoffTimeoutUSec</varname>,
+      <varname>RemoveIPC</varname>, <varname>RuntimeDirectorySize</varname>,
+      <varname>RuntimeDirectoryInodesMax</varname>, <varname>InhibitorsMax</varname>, and
+      <varname>SessionsMax</varname>.
+      </para>
+
+      <para>The <varname>IdleHint</varname> property reflects the idle hint state of the system. If the
+      system is idle it might get into automatic suspend or shutdown depending on the configuration.</para>
+
+      <para><varname>IdleSinceHint</varname> and <varname>IdleSinceHintMonotonic</varname> encode the
+      timestamps of the last change of the idle hint boolean, in <constant>CLOCK_REALTIME</constant> and
+      <constant>CLOCK_MONOTONIC</constant> timestamps, respectively, in microseconds since the epoch.</para>
+
+      <para>The <varname>BlockInhibited</varname> and <varname>DelayInhibited</varname> properties encode
+      the currently active locks of the respective modes. They are colon separated lists of
+      <literal>shutdown</literal>, <literal>sleep</literal>, and <literal>idle</literal> (see above).</para>
+
+      <para><varname>NCurrentSessions</varname> and <varname>NCurrentInhibitors</varname> contain the number
+      of currently registered sessions and inhibitors.</para>
+
+      <para>The <varname>BootLoaderEntries</varname> property contains a list of boot loader entries.
+      This includes boot loader entries defined in configuration and any additional loader entries
+      reported by the boot loader. See
+      <citerefentry><refentrytitle>systemd-boot</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+      for more information.</para>
+
+      <para>The <varname>PreparingForShutdown</varname> and <varname>PreparingForSleep</varname> boolean
+      properties are true during the interval between the two <function>PrepareForShutdown</function> and
+      <function>PrepareForSleep</function> signals respectively. Note that these properties do not
+      send out <function>PropertyChanged</function> signals.</para>
+
+      <para>The <varname>RebootParameter</varname> property shows the value set with the
+      <function>SetRebootParameter()</function> method described above.</para>
+
+      <para><varname>ScheduledShutdown</varname> shows the value pair set with the
+      <function>ScheduleShutdown()</function> method described above.</para>
+
+      <para><varname>RebootToFirmwareSetup</varname>, <varname>RebootToBootLoaderMenu</varname>, and
+      <varname>RebootToBootLoaderEntry</varname> are true when the resprective post-reboot operation was
+      selected with <function>SetRebootToFirmwareSetup</function>,
+      <function>SetRebootToBootLoaderMenu</function>, or
+      <function>SetRebootToBootLoaderEntry</function>.</para>
+
+      <para>The <varname>WallMessage</varname> and <varname>EnableWallMessages</varname> properties reflect the
+      shutdown reason and wall message enablement switch which can be set with the
+      <function>SetWallMessage()</function> method described above.</para>
+
+      <para><varname>Docked</varname> is true if the machine is connected to a dock.
+      <varname>LidClosed</varname> is true when the lid (of a laptop) is closed.
+      <varname>OnExternalPower</varname> is true when the machine is connected to an external power supply.
+      </para>
+    </refsect2>
+
+    <refsect2>
+      <title>Security</title>
+
+      <para>A number of operations are protected via the polkit privilege
+      system. <function>SetUserLinger()</function> requires the
+      <interfacename>org.freedesktop.login1.set-user-linger</interfacename>
+      privilege. <function>AttachDevice()</function> requires
+      <interfacename>org.freedesktop.login1.attach-device</interfacename> and
+      <function>FlushDevices()</function> requires
+      <interfacename>org.freedesktop.login1.flush-devices</interfacename>. <function>PowerOff()</function>,
+      <function>Reboot()</function>, <function>Halt()</function>, <function>Suspend()</function>,
+      <function>Hibernate()</function> require
+      <interfacename>org.freedesktop.login1.power-off</interfacename>,
+      <interfacename>org.freedesktop.login1.power-off-multiple-sessions</interfacename>,
+      <interfacename>org.freedesktop.login1.power-off-ignore-inhibit</interfacename>,
+      <interfacename>org.freedesktop.login1.reboot</interfacename>,
+      <interfacename>org.freedesktop.login1.reboot-multiple-sessions</interfacename>,
+      <interfacename>org.freedesktop.login1.reboot-ignore-inhibit</interfacename>,
+      <interfacename>org.freedesktop.login1.halt</interfacename>,
+      <interfacename>org.freedesktop.login1.halt-multiple-sessions</interfacename>,
+      <interfacename>org.freedesktop.login1.halt-ignore-inhibit</interfacename>,
+      <interfacename>org.freedesktop.login1.suspend</interfacename>,
+      <interfacename>org.freedesktop.login1.suspend-multiple-sessions</interfacename>,
+      <interfacename>org.freedesktop.login1.suspend-ignore-inhibit</interfacename>,
+      <interfacename>org.freedesktop.login1.hibernate</interfacename>,
+      <interfacename>org.freedesktop.login1.hibernate-multiple-sessions</interfacename>,
+      <interfacename>org.freedesktop.login1.hibernate-ignore-inhibit</interfacename>,
+      respectively depending on whether there are other sessions around or active inhibits are present.
+      <function>HybridSleep()</function> and <function>SuspendThenHibernate()</function>
+      use the same privileges as <function>Hibernate()</function>.
+      <function>SetRebootParameter()</function> requires
+      <interfacename>org.freedesktop.login1.set-reboot-parameter</interfacename>.</para>
+
+      <para><function>SetRebootToFirmwareSetup</function> requires
+      <interfacename>org.freedesktop.login1.set-reboot-to-firmware-setup</interfacename>.
+      <function>SetRebootToBootLoaderMenu</function> requires
+      <interfacename>org.freedesktop.login1.set-reboot-to-boot-loader-menu</interfacename>.
+      <function>SetRebootToBootLoaderEntry</function> requires
+      <interfacename>org.freedesktop.login1.set-reboot-to-boot-loader-entry</interfacename>.
+      </para>
+
+      <para><function>ScheduleShutdown</function> and <function>CancelScheduledShutdown</function> require
+      the same privileges (listed above) as the immediate poweroff/reboot/halt operations.</para>
+
+      <para><function>Inhibit()</function> is protected via one of
+      <interfacename>org.freedesktop.login1.inhibit-block-shutdown</interfacename>,
+      <interfacename>org.freedesktop.login1.inhibit-delay-shutdown</interfacename>,
+      <interfacename>org.freedesktop.login1.inhibit-block-sleep</interfacename>,
+      <interfacename>org.freedesktop.login1.inhibit-delay-sleep</interfacename>,
+      <interfacename>org.freedesktop.login1.inhibit-block-idle</interfacename>,
+      <interfacename>org.freedesktop.login1.inhibit-handle-power-key</interfacename>,
+      <interfacename>org.freedesktop.login1.inhibit-handle-suspend-key</interfacename>,
+      <interfacename>org.freedesktop.login1.inhibit-handle-hibernate-key</interfacename>,
+      <interfacename>org.freedesktop.login1.inhibit-handle-lid-switch</interfacename> depending on the lock
+      type and mode taken.</para>
+
+      <para>The <varname>interactive</varname> boolean parameters can be used to control whether polkit
+      should interactively ask the user for authentication credentials if required.</para>
+    </refsect2>
+  </refsect1>
+
+  <refsect1>
+    <title>Seat Objects</title>
+
+    <programlisting executable="systemd-logind" node="/org/freedesktop/login1/seat/seat0" interface="org.freedesktop.login1.Seat">
+node /org/freedesktop/login1/seat/seat0 {
+  interface org.freedesktop.login1.Seat {
+    methods:
+      Terminate();
+      ActivateSession(in  s session_id);
+      SwitchTo(in  u vtnr);
+      SwitchToNext();
+      SwitchToPrevious();
+    properties:
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s Id = '...';
+      readonly (so) ActiveSession = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b CanTTY = ...;
+      readonly b CanGraphical = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(so) Sessions = [...];
+      readonly b IdleHint = ...;
+      readonly t IdleSinceHint = ...;
+      readonly t IdleSinceHintMonotonic = ...;
+  };
+  interface org.freedesktop.DBus.Peer { ... };
+  interface org.freedesktop.DBus.Introspectable { ... };
+  interface org.freedesktop.DBus.Properties { ... };
+};
+    </programlisting>
+
+    <!--Autogenerated cross-references for systemd.directives, do not edit-->
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.login1.Seat"/>
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.login1.Seat"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="Terminate()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="ActivateSession()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SwitchTo()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SwitchToNext()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SwitchToPrevious()"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Id"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ActiveSession"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CanTTY"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CanGraphical"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Sessions"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IdleHint"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IdleSinceHint"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IdleSinceHintMonotonic"/>
+
+    <!--End of Autogenerated section-->
+
+    <refsect2>
+      <title>Methods</title>
+
+      <para><function>Terminate()</function> and <function>ActivateSession()</function> work similarly to
+      <function>TerminateSeat()</function> and <function>ActivationSessionOnSeat()</function> on the Manager
+      object.</para>
+
+      <para><function>SwitchTo()</function> switches to the session on the virtual terminal
+      <varname>vtnr</varname>. <function>SwitchToNext()</function> and
+      <function>SwitchToPrevious()</function> switch to, respectively, the next and previous sessions on the
+      seat in the order of virtual terminals. If there is no active session, they switch to, respectively,
+      the first and last session on the seat.</para>
+    </refsect2>
+
+    <refsect2>
+      <title>Signals</title>
+
+      <para>Whenever <function>ActiveSession</function>, <function>Sessions</function>,
+      <function>CanGraphical</function>, <function>CanTTY</function>,
+      or the idle state changes, <function>PropertyChanged</function> signals are sent out to which clients
+      can subscribe.</para>
+    </refsect2>
+
+    <refsect2>
+      <title>Properties</title>
+
+      <para>The <varname>Id</varname> property encodes the ID of the seat.</para>
+
+      <para><varname>ActiveSession</varname> encodes the currently active session if there is one. It is a
+      structure consisting of the session id and the object path.</para>
+
+      <para><varname>CanTTY</varname> encodes whether the session is suitable for text logins, and
+      <varname>CanGraphical</varname> whether it is suitable for graphical sessions.</para>
+
+      <para>The <varname>Sessions</varname> property is an array of all current sessions of this seat, each
+      encoded in a structure consisting of the ID and the object path.</para>
+
+      <para>The <varname>IdleHint</varname>, <varname>IdleSinceHint</varname>, and
+      <varname>IdleSinceHintMonotonic</varname> properties encode the idle state, similarly to the ones
+      exposed on the <interfacename>Manager</interfacename> object, but specific for this seat.</para>
+    </refsect2>
+  </refsect1>
+
+  <refsect1>
+    <title>User Objects</title>
+
+    <programlisting executable="systemd-logind" node="/org/freedesktop/login1/user/_1000" interface="org.freedesktop.login1.User">
+node /org/freedesktop/login1/user/_1000 {
+  interface org.freedesktop.login1.User {
+    methods:
+      Terminate();
+      Kill(in  i signal_number);
+    properties:
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly u UID = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly u GID = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s Name = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t Timestamp = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t TimestampMonotonic = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s RuntimePath = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s Service = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s Slice = '...';
+      readonly (so) Display = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s State = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(so) Sessions = [...];
+      readonly b IdleHint = ...;
+      readonly t IdleSinceHint = ...;
+      readonly t IdleSinceHintMonotonic = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly b Linger = ...;
+  };
+  interface org.freedesktop.DBus.Peer { ... };
+  interface org.freedesktop.DBus.Introspectable { ... };
+  interface org.freedesktop.DBus.Properties { ... };
+};
+    </programlisting>
+
+    <!--Autogenerated cross-references for systemd.directives, do not edit-->
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.login1.User"/>
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.login1.User"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="Terminate()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="Kill()"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="UID"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="GID"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Name"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Timestamp"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TimestampMonotonic"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RuntimePath"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Service"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Slice"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Display"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="State"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Sessions"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IdleHint"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IdleSinceHint"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IdleSinceHintMonotonic"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Linger"/>
+
+    <!--End of Autogenerated section-->
+
+    <refsect2>
+      <title>Methods</title>
+
+      <para><function>Terminate()</function> and <function>Kill()</function> work similarly to the
+      <function>TerminateUser()</function> and <function>KillUser()</function> methods on the manager
+      object.</para>
+    </refsect2>
+
+    <refsect2>
+      <title>Signals</title>
+
+      <para>Whenever <varname>Sessions</varname> or the idle state changes,
+      <function>PropertyChanged</function> signals are sent out to which clients can subscribe.</para>
+    </refsect2>
+
+    <refsect2>
+      <title>Properties</title>
+
+      <para>The <varname>UID</varname> and <varname>GID</varname> properties encode the Unix UID and primary
+      GID of the user.</para>
+
+      <para>The <varname>Name</varname> property encodes the user name.</para>
+
+      <para><varname>Timestamp</varname> and <varname>TimestampMonotonic</varname> encode the login time of
+      the user in microseconds since the epoch, in the <constant>CLOCK_REALTIME</constant> and
+      <constant>CLOCK_MONOTONIC</constant> clocks, respectively.</para>
+
+      <para><varname>RuntimePath</varname> encodes the runtime path of the user,
+      i.e. <varname>$XDG_RUNTIME_DIR</varname>. For details see the
+      <ulink url="https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html">
+        XDG Basedir Specification
+      </ulink>.</para>
+
+      <para><varname>Service</varname> contains the unit name of the user systemd service of this
+      user. Each logged in user is assigned a user service that runs a user systemd instance. This is
+      usually an instance of <filename>user@.service</filename>.</para>
+
+      <para><varname>Slice</varname> contains the unit name of the user systemd slice of this user. Each
+      logged in user gets a private slice.</para>
+
+      <para><varname>Display</varname> encodes which graphical session should be used as the primary UI display
+      for the user. It is a structure encoding the session ID and the object path of the session to use.</para>
+
+      <para><varname>State</varname> encodes the user state and is one of <literal>offline</literal>,
+      <literal>lingering</literal>, <literal>online</literal>, <literal>active</literal>, or
+      <literal>closing</literal>. See
+      <citerefentry><refentrytitle>sd_uid_get_state</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+      for more information about the states.</para>
+
+      <para><varname>Sessions</varname> is an array of structures encoding all current sessions of the
+      user. Each structure consists of the ID and object path.</para>
+
+      <para>The <varname>IdleHint</varname>, <varname>IdleSinceHint</varname>, and
+      <varname>IdleSinceHintMonotonic</varname> properties encode the idle hint state of the user, similarly
+      to the <interfacename>Manager</interfacename>'s properties, but specific for this user.</para>
+
+      <para>The <varname>Linger</varname> property shows whether lingering is enabled for this user.</para>
+    </refsect2>
+  </refsect1>
+
+  <refsect1>
+    <title>Session Objects</title>
+
+    <programlisting executable="systemd-logind" node="/org/freedesktop/login1/session/1" interface="org.freedesktop.login1.Session">
+node /org/freedesktop/login1/session/1 {
+  interface org.freedesktop.login1.Session {
+    methods:
+      Terminate();
+      Activate();
+      Lock();
+      Unlock();
+      SetIdleHint(in  b idle);
+      SetLockedHint(in  b locked);
+      Kill(in  s who,
+           in  i signal_number);
+      TakeControl(in  b force);
+      ReleaseControl();
+      SetType(in  s type);
+      SetDisplay(in  s display);
+      SetTTY(in  h tty_fd);
+      TakeDevice(in  u major,
+                 in  u minor,
+                 out h fd,
+                 out b inactive);
+      ReleaseDevice(in  u major,
+                    in  u minor);
+      PauseDeviceComplete(in  u major,
+                          in  u minor);
+      SetBrightness(in  s subsystem,
+                    in  s name,
+                    in  u brightness);
+    signals:
+      PauseDevice(u major,
+                  u minor,
+                  s type);
+      ResumeDevice(u major,
+                   u minor,
+                   h fd);
+      Lock();
+      Unlock();
+    properties:
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s Id = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly (uo) User = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s Name = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t Timestamp = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t TimestampMonotonic = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly u VTNr = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly (so) Seat = ...;
+      readonly s TTY = '...';
+      readonly s Display = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b Remote = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s RemoteHost = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s RemoteUser = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s Service = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s Desktop = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s Scope = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly u Leader = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly u Audit = ...;
+      readonly s Type = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s Class = '...';
+      readonly b Active = ...;
+      readonly s State = '...';
+      readonly b IdleHint = ...;
+      readonly t IdleSinceHint = ...;
+      readonly t IdleSinceHintMonotonic = ...;
+      readonly b LockedHint = ...;
+  };
+  interface org.freedesktop.DBus.Peer { ... };
+  interface org.freedesktop.DBus.Introspectable { ... };
+  interface org.freedesktop.DBus.Properties { ... };
+};
+    </programlisting>
+
+    <!--Autogenerated cross-references for systemd.directives, do not edit-->
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.login1.Session"/>
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.login1.Session"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="Terminate()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="Activate()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="Lock()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="Unlock()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SetIdleHint()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SetLockedHint()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="Kill()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="TakeControl()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="ReleaseControl()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SetType()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SetDisplay()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SetTTY()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="TakeDevice()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="ReleaseDevice()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="PauseDeviceComplete()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SetBrightness()"/>
+
+    <variablelist class="dbus-signal" generated="True" extra-ref="PauseDevice"/>
+
+    <variablelist class="dbus-signal" generated="True" extra-ref="ResumeDevice"/>
+
+    <variablelist class="dbus-signal" generated="True" extra-ref="Lock"/>
+
+    <variablelist class="dbus-signal" generated="True" extra-ref="Unlock"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Id"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="User"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Name"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Timestamp"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TimestampMonotonic"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="VTNr"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Seat"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TTY"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Display"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Remote"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RemoteHost"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RemoteUser"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Service"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Desktop"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Scope"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Leader"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Audit"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Type"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Class"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Active"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="State"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IdleHint"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IdleSinceHint"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IdleSinceHintMonotonic"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LockedHint"/>
+
+    <!--End of Autogenerated section-->
+
+    <refsect2>
+      <title>Methods</title>
+
+      <para><function>Terminate()</function>, <function>Activate()</function>, <function>Lock()</function>,
+      <function>Unlock()</function>, and <function>Kill()</function> work similarly to the respective calls on
+      the <interfacename>Manager</interfacename> object.</para>
+
+      <para><function>SetIdleHint()</function> is called by the session object to update the idle state
+      of the session whenever it changes.</para>
+
+      <para><function>TakeControl()</function> allows a process to take exclusive managed device
+      access-control for that session. Only one D-Bus connection can be a controller for a given session at any
+      time. If the <varname>force</varname> argument is set (root only), an existing controller is kicked
+      out and replaced. Otherwise, this method fails if there is already a controller. Note that this method is
+      limited to D-Bus users with the effective UID set to the user of the session or root.</para>
+
+      <para><function>ReleaseControl()</function> drops control of a given session. Closing the D-Bus
+      connection implicitly releases control as well. See <function>TakeControl()</function> for more
+      information. This method also releases all devices for which the controller requested ownership via
+      <function>TakeDevice()</function>.</para>
+
+      <para><function>SetType()</function> allows the type of the session to be changed dynamically.  It can
+      only be called by session's current controller. If <function>TakeControl()</function> has not been
+      called, this method will fail. In addition, the session type will be reset to its original value once
+      control is released, either by calling <function>ReleaseControl()</function> or closing the D-Bus
+      connection. This should help prevent a session from entering an inconsistent state, for example if the
+      controller crashes. The only argument <varname>type</varname> is the new session type.</para>
+
+      <para><function>SetDisplay()</function> allows the display name of the graphical session to be changed. This is
+      useful if the display server is started as part of the session. It can only be called by session's current
+      controller. If <function>TakeControl()</function> has not been called, this method will fail. The only argument
+      <varname>display</varname> is the new display name.</para>
+
+      <para><function>SetTTY()</function> allows the device name of the session to be changed. This is
+      useful if the tty device is only known after authentication. It can only be called by session's
+      current controller. If <function>TakeControl()</function> has not been called, this method will fail.
+      The only argument <varname>tty_fd</varname> is a file handle to the new tty device.</para>
+
+      <para><function>TakeDevice()</function> allows a session controller to get a file descriptor for a
+      specific device. Pass in the major and minor numbers of the character device and
+      <filename>systemd-logind</filename> will return a file descriptor for the device. Only a limited set of
+      device-types is currently supported (but may be extended). <filename>systemd-logind</filename>
+      automatically mutes the file descriptor if the session is inactive and resumes it once the session is
+      activated again. This guarantees that a session can only access session devices if the session is
+      active. Note that this revoke/resume mechanism is asynchronous and may happen at any given time.  This
+      only works on devices that are attached to the seat of the given session. A process is not required to
+      have direct access to the device node. <filename>systemd-logind</filename> only requires you to be the
+      active session controller (see <function>TakeControl()</function>). Also note that any device can only
+      be requested once. As long as you don't release it, further <function>TakeDevice()</function> calls
+      will fail.</para>
+
+      <para><function>ReleaseDevice()</function> releases a device again (see
+      <function>TakeDevice()</function>). This is also implicitly done by
+      <function>ReleaseControl()</function> or when closing the D-Bus connection.</para>
+
+      <para><function>PauseDeviceComplete()</function> allows a session controller to synchronously pause a
+      device after receiving a <function>PauseDevice(<literal>pause</literal>)</function> signal. Forced
+      signals (or after an internal timeout) are automatically completed by
+      <filename>systemd-logind</filename> asynchronously.</para>
+
+      <para><function>SetLockedHint()</function> may be used to set the "locked hint" to
+      <varname>locked</varname>, i.e. information whether the session is locked. This is intended to be used
+      by the desktop environment to tell <command>systemd-logind</command> when the session is locked and
+      unlocked.</para>
+
+      <para><function>SetBrightness()</function> may be used to set the display brightness. This is intended
+      to be used by the desktop environment and allows unprivileged programs to access hardware settings in
+      a controlled way. The <varname>subsystem</varname> parameter specifies a kernel subsystem, either
+      <literal>backlight</literal> or <literal>leds</literal>. The <varname>name</varname> parameter
+      specifies a device name under the specified subsystem. The <varname>brightness</varname> parameter
+      specifies the brightness. The range is defined by individual drivers, see
+      <filename>/sys/class/<varname>subsystem</varname>/<varname>name</varname>/max_brightness</filename>.
+      </para>
+    </refsect2>
+
+    <refsect2>
+      <title>Signals</title>
+
+      <para>The active session controller exclusively gets <function>PauseDevice</function> and
+      <function>ResumeDevice</function> events for any device it requested via
+      <function>TakeDevice()</function>. They notify the controller whenever a device is paused or resumed. A
+      device is never resumed if its session is inactive. Also note that <function>PauseDevice</function>
+      signals are sent before the <function>PropertyChanged</function> signal for the
+      <function>Active</function> state. The inverse is true for <function>ResumeDevice</function>. A device
+      may remain paused for unknown reasons even though the <interfacename>Session</interfacename> is active.
+      </para>
+
+      <para>A <function>PauseDevice</function> signal carries the major and minor numbers and a string describing the
+      type as arguments. <function>force</function> means the device was already paused by
+      <filename>systemd-logind</filename> and the signal is only an asynchronous
+      notification. <function>pause</function> means <filename>systemd-logind</filename> grants you a limited amount of time to pause the device. You must respond to this via
+      <function>PauseDeviceComplete()</function>. This synchronous pausing mechanism is used for
+      backwards-compatibility to VTs and <filename>systemd-logind</filename> is free to not make use of
+      it. It is also free to send a forced <function>PauseDevice</function> if you don't respond in a timely
+      manner (or for any other reason). <function>gone</function> means the device was unplugged from the
+      system and you will no longer get any notifications about it. There is no need to call
+      <function>ReleaseDevice()</function>. You may call <function>TakeDevice()</function> again if a new
+      device is assigned the major+minor combination.</para>
+
+      <para><function>ResumeDevice</function> is sent whenever a session is active and a device is
+      resumed. It carries the major/minor numbers as arguments and provides a new open file descriptor. You should
+      switch to the new descriptor and close the old one. They are not guaranteed to have the same underlying
+      open file descriptor in the kernel (except for a limited set of device types).</para>
+
+      <para>Whenever <function>Active</function> or the idle state changes,
+      <function>PropertyChanged</function> signals are sent out to which clients can subscribe.</para>
+
+      <para><function>Lock</function>/<function>Unlock</function> is sent when the session is asked to be
+      screen-locked/unlocked. A session manager of the session should listen to this signal and act
+      accordingly. This signal is sent out as a result of the <function>Lock()</function> and
+      <function>Unlock()</function> methods, respectively.</para>
+    </refsect2>
+
+    <refsect2>
+      <title>Properties</title>
+
+      <para><varname>Id</varname> encodes the session ID.</para>
+
+      <para><varname>User</varname> encodes the user ID of the user this session belongs to. This is a
+      structure consisting of the Unix UID and the object path.</para>
+
+      <para><varname>Name</varname> encodes the user name.</para>
+
+      <para><varname>Timestamp</varname> and <varname>TimestampMonotonic</varname> encode the microseconds
+      since the epoch when the session was created, in <constant>CLOCK_REALTIME</constant> or
+      <constant>CLOCK_MONOTONIC</constant>, respectively.</para>
+
+      <para><varname>VTNr</varname> encodes the virtual terminal number of the session if there is any, 0
+      otherwise.</para>
+
+      <para><varname>Seat</varname> encodes the seat this session belongs to if there is any. This is a
+      structure consisting of the ID and the seat object path.</para>
+
+      <para><varname>TTY</varname> encodes the kernel TTY path of the session if this is a text login. If not
+      this is an empty string.</para>
+
+      <para><varname>Display</varname> encodes the X11 display name if this is a graphical login. If not,
+      this is an empty string.</para>
+
+      <para><varname>Remote</varname> encodes whether the session is local or remote.</para>
+
+      <para><varname>RemoteHost</varname> and <varname>RemoteUser</varname> encode the remote host and user
+      if this is a remote session, or an empty string otherwise.</para>
+
+      <para><varname>Service</varname> encodes the PAM service name that registered the session.</para>
+
+      <para><varname>Desktop</varname> describes the desktop environment running in the session (if
+      known).</para>
+
+      <para><varname>Scope</varname> contains the systemd scope unit name of this session.</para>
+
+      <para><varname>Leader</varname> encodes the PID of the process that registered the session.</para>
+
+      <para><varname>Audit</varname> encodes the Kernel Audit session ID of the session if auditing is
+      available.</para>
+
+      <para><varname>Type</varname> encodes the session type. It's one of <literal>unspecified</literal> (for
+      cron PAM sessions and suchlike), <literal>tty</literal> (for text logins) or
+      <literal>x11</literal>/<literal>mir</literal>/<literal>wayland</literal> (for graphical logins).</para>
+
+      <para><varname>Class</varname> encodes the session class. It's one of <literal>user</literal> (for
+      normal user sessions), <literal>greeter</literal> (for display manager pseudo-sessions), or
+      <literal>lock-screen</literal> (for display lock screens).</para>
+
+      <para><varname>Active</varname> is a boolean that is true if the session is active, i.e. currently in the
+      foreground. This field is semi-redundant due to <varname>State</varname>.</para>
+
+      <para><varname>State</varname> encodes the session state and one of <literal>online</literal>,
+      <literal>active</literal>, or <literal>closing</literal>. See
+      <citerefentry><refentrytitle>sd_session_get_state</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+      for more information about the states.</para>
+
+      <para><varname>IdleHint</varname>, <varname>IdleSinceHint</varname>, and
+      <varname>IdleSinceHintMonotonic</varname> encapsulate the idle hint state of this session, similarly to
+      how the respective properties on the manager object do it for the whole system.</para>
+
+      <para><varname>LockedHint</varname> shows the locked hint state of this session, as set by the
+      <function>SetLockedHint()</function> method described above.</para>
+    </refsect2>
+  </refsect1>
+
+  <refsect1>
+    <title>Examples</title>
+
+    <example>
+      <title>Introspect the logind manager on the bus</title>
+
+      <programlisting>$ gdbus introspect --system --dest org.freedesktop.login1 \
+  --object-path /org/freedesktop/login1
+      </programlisting>
+
+      <para>or</para>
+
+      <programlisting>$ busctl introspect org.freedesktop.login1 /org/freedesktop/login1
+      </programlisting>
+    </example>
+
+    <example>
+      <title>Introspect the default seat on the bus</title>
+
+      <programlisting>$ gdbus introspect --system --dest org.freedesktop.login1 \
+ --object-path /org/freedesktop/login1/seat/seat0
+      </programlisting>
+
+      <para>or</para>
+
+      <programlisting>$ busctl introspect org.freedesktop.login1 /org/freedesktop/login1/seat/seat0
+      </programlisting>
+
+      <para>Seat <literal>seat0</literal> is the default seat, so it'll be present unless local configuration
+      is made to reassign all devices to a different seat. The list of seats and users can be acquired with
+      <command>loginctl list-sessions</command>.</para>
+    </example>
+
+    <example>
+      <title>Introspect a single user on the bus</title>
+
+      <programlisting>$ gdbus introspect --system --dest org.freedesktop.login1 \
+  --object-path /org/freedesktop/login1/user/_1000
+      </programlisting>
+
+      <para>or</para>
+
+      <programlisting>$ busctl introspect org.freedesktop.login1 /org/freedesktop/login1/user/_1000
+      </programlisting>
+    </example>
+
+    <example>
+      <title>Introspect <interfacename>org.freedesktop.login1.Session</interfacename> on the bus</title>
+
+      <programlisting>$ gdbus introspect --system --dest org.freedesktop.login1 \
+  --object-path /org/freedesktop/login1/session/45
+      </programlisting>
+
+      <para>or</para>
+
+      <programlisting>$ busctl introspect org.freedesktop.login1 /org/freedesktop/login1/session/45
+      </programlisting>
+    </example>
+  </refsect1>
+
+  <xi:include href="org.freedesktop.locale1.xml" xpointer="versioning"/>
+
+  <refsect1>
+    <title>History</title>
+    <refsect2>
+      <title>The Manager Object</title>
+      <para><varname>HandlePowerKeyLongPress</varname>,
+      <varname>HandleRebootKey</varname>,
+      <varname>HandleRebootKeyLongPress</varname>,
+      <varname>HandleSuspendKeyLongPress</varname>, and
+      <varname>HandleHibernateKeyLongPress</varname> were added in version 251.</para>
+      <para><varname>StopIdleSessionUSec</varname> was added in version 252.</para>
+      <para><function>PrepareForShutdownWithMetadata</function> and
+      <function>CreateSessionWithPIDFD()</function> were added in version 255.</para>
+    </refsect2>
+    <refsect2>
+      <title>Session Objects</title>
+      <para><function>SetDisplay()</function> was added in version 252.</para>
+      <para><function>SetTTY()</function> was added in version 254.</para>
+    </refsect2>
+  </refsect1>
+</refentry>
diff --git a/man/org.freedesktop.machine1.xml b/man/org.freedesktop.machine1.xml
new file mode 100644
index 0000000..1af77e0
--- /dev/null
+++ b/man/org.freedesktop.machine1.xml
@@ -0,0 +1,687 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" >
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="org.freedesktop.machine1" conditional='ENABLE_MACHINED'
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+  <refentryinfo>
+    <title>org.freedesktop.machine1</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>org.freedesktop.machine1</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>org.freedesktop.machine1</refname>
+    <refpurpose>The D-Bus interface of systemd-machined</refpurpose>
+  </refnamediv>
+
+  <refsect1>
+    <title>Introduction</title>
+
+    <para>
+    <citerefentry><refentrytitle>systemd-machined.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    is a system service that keeps track of locally running virtual machines and containers.
+    This page describes the D-Bus interface.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>The Manager Object</title>
+
+    <para>The service exposes the following interfaces on the Manager object on the bus:</para>
+
+    <programlisting executable="systemd-machined" node="/org/freedesktop/machine1" interface="org.freedesktop.machine1.Manager">
+node /org/freedesktop/machine1 {
+  interface org.freedesktop.machine1.Manager {
+    methods:
+      GetMachine(in  s name,
+                 out o machine);
+      GetImage(in  s name,
+               out o image);
+      GetMachineByPID(in  u pid,
+                      out o machine);
+      ListMachines(out a(ssso) machines);
+      ListImages(out a(ssbttto) images);
+      @org.freedesktop.systemd1.Privileged("true")
+      CreateMachine(in  s name,
+                    in  ay id,
+                    in  s service,
+                    in  s class,
+                    in  u leader,
+                    in  s root_directory,
+                    in  a(sv) scope_properties,
+                    out o path);
+      @org.freedesktop.systemd1.Privileged("true")
+      CreateMachineWithNetwork(in  s name,
+                               in  ay id,
+                               in  s service,
+                               in  s class,
+                               in  u leader,
+                               in  s root_directory,
+                               in  ai ifindices,
+                               in  a(sv) scope_properties,
+                               out o path);
+      @org.freedesktop.systemd1.Privileged("true")
+      RegisterMachine(in  s name,
+                      in  ay id,
+                      in  s service,
+                      in  s class,
+                      in  u leader,
+                      in  s root_directory,
+                      out o path);
+      @org.freedesktop.systemd1.Privileged("true")
+      RegisterMachineWithNetwork(in  s name,
+                                 in  ay id,
+                                 in  s service,
+                                 in  s class,
+                                 in  u leader,
+                                 in  s root_directory,
+                                 in  ai ifindices,
+                                 out o path);
+      UnregisterMachine(in  s name);
+      TerminateMachine(in  s id);
+      KillMachine(in  s name,
+                  in  s who,
+                  in  i signal);
+      GetMachineAddresses(in  s name,
+                          out a(iay) addresses);
+      GetMachineOSRelease(in  s name,
+                          out a{ss} fields);
+      @org.freedesktop.systemd1.Privileged("true")
+      OpenMachinePTY(in  s name,
+                     out h pty,
+                     out s pty_path);
+      OpenMachineLogin(in  s name,
+                       out h pty,
+                       out s pty_path);
+      OpenMachineShell(in  s name,
+                       in  s user,
+                       in  s path,
+                       in  as args,
+                       in  as environment,
+                       out h pty,
+                       out s pty_path);
+      BindMountMachine(in  s name,
+                       in  s source,
+                       in  s destination,
+                       in  b read_only,
+                       in  b mkdir);
+      CopyFromMachine(in  s name,
+                      in  s source,
+                      in  s destination);
+      CopyToMachine(in  s name,
+                    in  s source,
+                    in  s destination);
+      CopyFromMachineWithFlags(in  s name,
+                               in  s source,
+                               in  s destination,
+                               in  t flags);
+      CopyToMachineWithFlags(in  s name,
+                             in  s source,
+                             in  s destination,
+                             in  t flags);
+      OpenMachineRootDirectory(in  s name,
+                               out h fd);
+      GetMachineUIDShift(in  s name,
+                         out u shift);
+      RemoveImage(in  s name);
+      RenameImage(in  s name,
+                  in  s new_name);
+      CloneImage(in  s name,
+                 in  s new_name,
+                 in  b read_only);
+      MarkImageReadOnly(in  s name,
+                        in  b read_only);
+      GetImageHostname(in  s name,
+                       out s hostname);
+      GetImageMachineID(in  s name,
+                        out ay id);
+      GetImageMachineInfo(in  s name,
+                          out a{ss} machine_info);
+      GetImageOSRelease(in  s name,
+                        out a{ss} os_release);
+      SetPoolLimit(in  t size);
+      SetImageLimit(in  s name,
+                    in  t size);
+      CleanPool(in  s mode,
+                out a(st) images);
+      MapFromMachineUser(in  s name,
+                         in  u uid_inner,
+                         out u uid_outer);
+      MapToMachineUser(in  u uid_outer,
+                       out s machine_name,
+                       out o machine_path,
+                       out u uid_inner);
+      MapFromMachineGroup(in  s name,
+                          in  u gid_inner,
+                          out u gid_outer);
+      MapToMachineGroup(in  u gid_outer,
+                        out s machine_name,
+                        out o machine_path,
+                        out u gid_inner);
+    signals:
+      MachineNew(s machine,
+                 o path);
+      MachineRemoved(s machine,
+                     o path);
+    properties:
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s PoolPath = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t PoolUsage = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t PoolLimit = ...;
+  };
+  interface org.freedesktop.DBus.Peer { ... };
+  interface org.freedesktop.DBus.Introspectable { ... };
+  interface org.freedesktop.DBus.Properties { ... };
+};
+    </programlisting>
+
+    <!--method UnregisterMachine is not documented!-->
+
+    <!--method CopyToMachineWithFlags is not documented!-->
+
+    <!--method OpenMachineRootDirectory is not documented!-->
+
+    <!--method GetMachineUIDShift is not documented!-->
+
+    <!--method GetImageHostname is not documented!-->
+
+    <!--method GetImageMachineID is not documented!-->
+
+    <!--method GetImageMachineInfo is not documented!-->
+
+    <!--method GetImageOSRelease is not documented!-->
+
+    <!--method CleanPool is not documented!-->
+
+    <!--Autogenerated cross-references for systemd.directives, do not edit-->
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.machine1.Manager"/>
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.machine1.Manager"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="GetMachine()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="GetImage()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="GetMachineByPID()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="ListMachines()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="ListImages()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="CreateMachine()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="CreateMachineWithNetwork()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="RegisterMachine()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="RegisterMachineWithNetwork()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="UnregisterMachine()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="TerminateMachine()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="KillMachine()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="GetMachineAddresses()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="GetMachineOSRelease()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="OpenMachinePTY()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="OpenMachineLogin()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="OpenMachineShell()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="BindMountMachine()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="CopyFromMachine()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="CopyToMachine()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="CopyFromMachineWithFlags()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="CopyToMachineWithFlags()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="OpenMachineRootDirectory()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="GetMachineUIDShift()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="RemoveImage()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="RenameImage()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="CloneImage()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="MarkImageReadOnly()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="GetImageHostname()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="GetImageMachineID()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="GetImageMachineInfo()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="GetImageOSRelease()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SetPoolLimit()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SetImageLimit()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="CleanPool()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="MapFromMachineUser()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="MapToMachineUser()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="MapFromMachineGroup()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="MapToMachineGroup()"/>
+
+    <variablelist class="dbus-signal" generated="True" extra-ref="MachineNew"/>
+
+    <variablelist class="dbus-signal" generated="True" extra-ref="MachineRemoved"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="PoolPath"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="PoolUsage"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="PoolLimit"/>
+
+    <!--End of Autogenerated section-->
+
+    <refsect2>
+      <title>Methods</title>
+
+      <para><function>GetMachine()</function> may be used to get the machine object path for the machine with
+      the specified name. Similarly, <function>GetMachineByPID()</function> gets the machine object the
+      specified PID belongs to if there is any.</para>
+
+      <para><function>GetImage()</function> may be used to get the image object path of the image with the
+      specified name.</para>
+
+      <para><function>ListMachines()</function> returns an array of all currently registered machines. The
+      structures in the array consist of the following fields: machine name, machine class, an identifier for
+      the service that registered the machine and the machine object path.</para>
+
+      <para><function>ListImages()</function> returns an array of all currently known images. The
+      structures in the array consist of the following fields: image name, type, read-only flag, creation
+      time, modification time, current disk space, and image object path.</para>
+
+      <para><function>CreateMachine()</function> may be used to register a new virtual machine or container
+      with <command>systemd-machined</command>, creating a scope unit for it. It accepts the following arguments: a
+      machine name chosen by the registrar, an optional UUID as a 32 byte array, a string that identifies the
+      service that registers the machine, a class string, the PID of the leader process of the machine, an
+      optional root directory of the container, and an array of additional properties to use for the scope
+      registration. The virtual machine name must be suitable as a hostname, and hence should follow the usual
+      DNS hostname rules, as well as the Linux hostname restrictions. Specifically, only 7 bit ASCII is
+      permitted, a maximum length of 64 characters is enforced, only characters from the set
+      <literal>a-zA-Z0-9-_.</literal> are allowed, the name may not begin with a dot, and it may not contain
+      two dots immediately following each other. Container and VM managers should ideally use the hostname
+      used internally in the machine for this parameter. This recommendation is made in order to make the
+      machine name naturally resolvable using
+      <citerefentry><refentrytitle>nss-mymachines</refentrytitle><manvolnum>8</manvolnum></citerefentry>. If
+      a container manager needs to embed characters outside of the indicated range, escaping is required,
+      possibly using <literal>_</literal> as the escape character. Another (somewhat natural) option would be
+      to utilize Internet IDNA encoding. The UUID is passed as a 32 byte array or, if no suitable UUID is
+      available, an empty array (zero length) or zeroed out array shall be passed. The UUID should identify
+      the virtual machine/container uniquely and should ideally be the same UUID that
+      <filename>/etc/machine-id</filename> in the VM/container is initialized from. The service string can be
+      free-form, but it is recommended to pass a short lowercase identifier like
+      <literal>systemd-nspawn</literal>, <literal>libvirt-lxc</literal> or similar. The class string should
+      be either <literal>container</literal> or <literal>vm</literal> indicating whether the machine to
+      register is of the respective class. The leader PID should be the host PID of the init process of the
+      container or the encapsulating process of the VM. If the root directory of the container is known and
+      available in the host's hierarchy, it should be passed. Otherwise, pass the empty string instead. Finally, the
+      scope properties are passed as array in the same way as to PID1's
+      <function>StartTransientUnit()</function> method. Calling this method will internally register a transient scope
+      unit for the calling client (utilizing the passed scope_properties) and move the leader PID into
+      it. The method returns an object path for the registered machine object that implements the
+      <interfacename>org.freedesktop.machine1.Machine</interfacename> interface (see below). Also see the
+      <ulink url="https://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface">New Control Group
+      Interfaces</ulink> for details about scope units and how to alter resource control settings on the
+      created machine at runtime.</para>
+
+      <para><function>RegisterMachine()</function> is similar to <function>CreateMachine()</function>.
+      However, it only registers a machine and does not create a scope unit for it. Instead, the caller's unit is
+      registered. We recommend to only use this method for container or VM managers that are run
+      multiple times, one instance for each container/VM they manage, and are invoked as system
+      services.</para>
+
+      <para><function>CreateMachineWithNetwork()</function> and
+      <function>RegisterMachineWithNetwork()</function> are similar to <function>CreateMachine()</function>
+      and <function>RegisterMachine()</function> but take an extra argument: an array of network interface
+      indices that point towards the virtual machine or container. The interface indices should reference one
+      or more network interfaces on the host that can be used to communicate with the guest. Commonly, the
+      passed interface index refers to the host side of a "veth" link (in case of containers), a
+      "tun"/"tap" link (in case of VMs), or the host side of a bridge interface that bridges access to the
+      VM/container interfaces. Specifying this information is useful to enable support for link-local IPv6
+      communication to the machines since the scope field of sockaddr_in6 can be initialized by the
+      specified ifindex.
+      <citerefentry><refentrytitle>nss-mymachines</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+      makes use of this information.</para>
+
+      <para><function>KillMachine()</function> sends a UNIX signal to the machine's processes. As its arguments, it takes a
+      machine name (as originally passed to <function>CreateMachine()</function> or returned by
+      <function>ListMachines()</function>), an identifier that specifies what precisely to send the signal to (either
+      <literal>leader</literal> or <literal>all</literal>), and a numeric UNIX signal integer.</para>
+
+      <para><function>TerminateMachine()</function> terminates a virtual machine, killing its processes. It
+      takes a machine name as its only argument.</para>
+
+      <para><function>GetMachineAddresses()</function> retrieves the IP addresses of a container. This method
+      returns an array of pairs consisting of an address family specifier (<constant>AF_INET</constant> or
+      <constant>AF_INET6</constant>) and a byte array containing the addresses. This is only supported for
+      containers that make use of network namespacing.</para>
+
+      <para><function>GetMachineOSRelease()</function> retrieves the OS release information of a
+      container. This method returns an array of key value pairs read from the
+      <citerefentry><refentrytitle>os-release</refentrytitle><manvolnum>5</manvolnum></citerefentry> file in
+      the container and is useful to identify the operating system used in a container.</para>
+
+      <para><function>OpenMachinePTY()</function> allocates a pseudo TTY in the container and returns a file
+      descriptor and its path. This is equivalent to transitioning into the container and invoking
+      <citerefentry project="man-pages"><refentrytitle>posix_openpt</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+      </para>
+
+      <para><function>OpenMachineLogin()</function> allocates a pseudo TTY in the container and ensures that
+      a getty login prompt of the container is running on the other end. It returns the file descriptor of
+      the PTY and the PTY path. This is useful for acquiring a pty with a login prompt from the
+      container.</para>
+
+      <para><function>OpenMachineShell()</function> allocates a pseudo TTY in the container, as the specified
+      user, and invokes the executable at the specified path with a list of arguments (starting from
+      argv[0]) and an environment block. It then returns the file descriptor of the PTY and the PTY
+      path.</para>
+
+      <para><function>BindMountMachine()</function> bind mounts a file or directory from the host into the
+      container. Its arguments consist of a machine name, the source directory on the host, the destination directory in the
+      container, and two booleans, one indicating whether the bind mount shall be
+      read-only, the other indicating whether the destination mount point shall be created first, if it is
+      missing.</para>
+
+      <para><function>CopyFromMachine()</function> copies files or directories from a container into the
+      host. It takes a container name, a source directory in the container and a destination directory on the
+      host as arguments.
+      <function>CopyToMachine()</function> does the opposite and copies files from a source
+      directory on the host into a destination directory in the container.
+      <function>CopyFromMachineWithFlags()</function> and <function>CopyToMachineWithFlags</function> do the same but take an additional flags argument.</para>
+
+      <para><function>RemoveImage()</function> removes the image with the specified name.</para>
+
+      <para><function>RenameImage()</function> renames the specified image.</para>
+
+      <para><function>CloneImage()</function> clones the specified image under a new name. It also takes a
+      boolean argument indicating whether the resulting image shall be read-only or not.</para>
+
+      <para><function>MarkImageReadOnly()</function> toggles the read-only flag of an image.</para>
+
+      <para><function>SetPoolLimit()</function> sets an overall quota limit on the pool of images.</para>
+
+      <para><function>SetImageLimit()</function> sets a per-image quota limit.</para>
+
+      <para><function>MapFromMachineUser()</function>, <function>MapToMachineUser()</function>,
+      <function>MapFromMachineGroup()</function>, and <function>MapToMachineGroup()</function> may be used to map
+      UIDs/GIDs from the host user namespace to a container user namespace or vice versa.</para>
+    </refsect2>
+
+    <refsect2>
+      <title>Signals</title>
+
+      <para><function>MachineNew</function> and <function>MachineRemoved</function> are sent whenever a new
+      machine is registered or removed. These signals carry the machine name and the object path to the corresponding
+      <interfacename>org.freedesktop.machine1.Machine</interfacename> interface (see below).</para>
+    </refsect2>
+
+    <refsect2>
+      <title>Properties</title>
+
+      <para><varname>PoolPath</varname> specifies the file system path where images are written to.</para>
+
+      <para><varname>PoolUsage</varname> specifies the current usage size of the image pool in bytes.</para>
+
+      <para><varname>PoolLimit</varname> specifies the size limit of the image pool in bytes.</para>
+    </refsect2>
+  </refsect1>
+
+  <refsect1>
+    <title>Machine Objects</title>
+
+    <programlisting executable="systemd-machined" node="/org/freedesktop/machine1/machine/rawhide" interface="org.freedesktop.machine1.Machine">
+node /org/freedesktop/machine1/machine/rawhide {
+  interface org.freedesktop.machine1.Machine {
+    methods:
+      Terminate();
+      Kill(in  s who,
+           in  i signal);
+      GetAddresses(out a(iay) addresses);
+      GetOSRelease(out a{ss} fields);
+      GetUIDShift(out u shift);
+      OpenPTY(out h pty,
+              out s pty_path);
+      OpenLogin(out h pty,
+                out s pty_path);
+      OpenShell(in  s user,
+                in  s path,
+                in  as args,
+                in  as environment,
+                out h pty,
+                out s pty_path);
+      BindMount(in  s source,
+                in  s destination,
+                in  b read_only,
+                in  b mkdir);
+      CopyFrom(in  s source,
+               in  s destination);
+      CopyTo(in  s source,
+             in  s destination);
+      CopyFromWithFlags(in  s source,
+                        in  s destination,
+                        in  t flags);
+      CopyToWithFlags(in  s source,
+                      in  s destination,
+                      in  t flags);
+      OpenRootDirectory(out h fd);
+    properties:
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s Name = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly ay Id = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t Timestamp = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t TimestampMonotonic = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s Service = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s Unit = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly u Leader = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s Class = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s RootDirectory = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly ai NetworkInterfaces = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s State = '...';
+  };
+  interface org.freedesktop.DBus.Peer { ... };
+  interface org.freedesktop.DBus.Introspectable { ... };
+  interface org.freedesktop.DBus.Properties { ... };
+};
+    </programlisting>
+
+    <!--method GetUIDShift is not documented!-->
+
+    <!--method OpenPTY is not documented!-->
+
+    <!--method OpenLogin is not documented!-->
+
+    <!--method OpenShell is not documented!-->
+
+    <!--method BindMount is not documented!-->
+
+    <!--method CopyFrom is not documented!-->
+
+    <!--method CopyTo is not documented!-->
+
+    <!--method CopyFromWithFlags is not documented!-->
+
+    <!--method CopyToWithFlags is not documented!-->
+
+    <!--method OpenRootDirectory is not documented!-->
+
+    <!--Autogenerated cross-references for systemd.directives, do not edit-->
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.machine1.Machine"/>
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.machine1.Machine"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="Terminate()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="Kill()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="GetAddresses()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="GetOSRelease()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="GetUIDShift()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="OpenPTY()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="OpenLogin()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="OpenShell()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="BindMount()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="CopyFrom()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="CopyTo()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="CopyFromWithFlags()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="CopyToWithFlags()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="OpenRootDirectory()"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Name"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Id"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Timestamp"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TimestampMonotonic"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Service"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Unit"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Leader"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Class"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RootDirectory"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="NetworkInterfaces"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="State"/>
+
+    <!--End of Autogenerated section-->
+
+    <refsect2>
+      <title>Methods</title>
+
+      <para><function>Terminate()</function> and <function>Kill()</function> terminate/kill the machine. These methods
+      take the same arguments as <function>TerminateMachine()</function> and
+      <function>KillMachine()</function> on the Manager interface, respectively.</para>
+
+      <para><function>GetAddresses()</function> and <function>GetOSRelease()</function> get the IP address and OS
+      release information from the machine. These methods take the same arguments as
+      <function>GetMachineAddresses()</function> and <function>GetMachineOSRelease()</function> of the
+      Manager interface, respectively.</para>
+    </refsect2>
+
+    <refsect2>
+      <title>Properties</title>
+
+      <para><varname>Name</varname> is the machine name as it was passed in during registration with
+      <function>CreateMachine()</function> on the manager object.</para>
+
+      <para><varname>Id</varname> is the machine UUID.</para>
+
+      <para><varname>Timestamp</varname> and <varname>TimestampMonotonic</varname> are the realtime and
+      monotonic timestamps when the virtual machines where created in microseconds since the epoch.</para>
+
+      <para><varname>Service</varname> contains a short string identifying the registering service as passed
+      in during registration of the machine.</para>
+
+      <para><varname>Unit</varname> is the systemd scope or service unit name for the machine.</para>
+
+      <para><varname>Leader</varname> is the PID of the leader process of the machine.</para>
+
+      <para><varname>Class</varname> is the class of the machine and is either the string "vm" (for real VMs
+      based on virtualized hardware) or "container" (for light-weight userspace virtualization sharing the
+      same kernel as the host).</para>
+
+      <para><varname>RootDirectory</varname> is the root directory of the container if it is known and
+      applicable or the empty string.</para>
+
+      <para><varname>NetworkInterfaces</varname> contains an array of network interface indices that point
+      towards the container, the VM or the host. For details about this information see the description of
+      <function>CreateMachineWithNetwork()</function> above.</para>
+
+      <para><varname>State</varname> is the state of the machine and is one of <literal>opening</literal>,
+      <literal>running</literal>, or <literal>closing</literal>. Note that the state machine is not considered
+      part of the API and states might be removed or added without this being considered API breakage.
+      </para>
+    </refsect2>
+  </refsect1>
+
+  <refsect1>
+    <title>Examples</title>
+
+    <example>
+      <title>Introspect <interfacename>org.freedesktop.machine1.Manager</interfacename> on the bus</title>
+
+      <programlisting>
+$ gdbus introspect --system \
+  --dest org.freedesktop.machine1 \
+  --object-path /org/freedesktop/machine1
+      </programlisting>
+    </example>
+
+    <example>
+      <title>Introspect <interfacename>org.freedesktop.machine1.Machine</interfacename> on the bus</title>
+
+      <programlisting>
+$ gdbus introspect --system \
+  --dest org.freedesktop.machine1 \
+  --object-path /org/freedesktop/machine1/machine/rawhide
+      </programlisting>
+    </example>
+  </refsect1>
+
+  <xi:include href="org.freedesktop.locale1.xml" xpointer="versioning"/>
+
+  <refsect1>
+    <title>History</title>
+    <refsect2>
+      <title>The Manager Object</title>
+      <para><function>CopyFromMachineWithFlags()</function> and
+      <function>CopyToMachineWithFlags()</function> were added in version 252.</para>
+    </refsect2>
+    <refsect2>
+      <title>Machine Objects</title>
+      <para><function>CopyFromWithFlags()</function> and
+      <function>CopyToWithFlags()</function> were added in version 252.</para>
+    </refsect2>
+  </refsect1>
+</refentry>
diff --git a/man/org.freedesktop.network1.xml b/man/org.freedesktop.network1.xml
new file mode 100644
index 0000000..02013c5
--- /dev/null
+++ b/man/org.freedesktop.network1.xml
@@ -0,0 +1,588 @@
+<?xml version="1.0"?>
+<!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [
+<!ENTITY % entities SYSTEM "custom-entities.ent" >
+%entities;
+]>
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="org.freedesktop.network1" conditional='ENABLE_NETWORKD'
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+  <refentryinfo>
+    <title>org.freedesktop.network1</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>org.freedesktop.network1</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>org.freedesktop.network1</refname>
+    <refpurpose>The D-Bus interface of systemd-networkd</refpurpose>
+  </refnamediv>
+
+  <refsect1>
+    <title>Introduction</title>
+
+    <para>
+    <citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    is a system service that manages and configures network interfaces. This page describes the D-Bus
+    interface.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>The Manager Object</title>
+
+    <para>The service exposes the following interfaces on the Manager object on the bus:</para>
+
+    <programlisting executable="systemd-networkd" node="/org/freedesktop/network1" interface="org.freedesktop.network1.Manager">
+node /org/freedesktop/network1 {
+  interface org.freedesktop.network1.Manager {
+    methods:
+      ListLinks(out a(iso) links);
+      GetLinkByName(in  s name,
+                    out i ifindex,
+                    out o path);
+      GetLinkByIndex(in  i ifindex,
+                     out s name,
+                     out o path);
+      SetLinkNTP(in  i ifindex,
+                 in  as servers);
+      SetLinkDNS(in  i ifindex,
+                 in  a(iay) addresses);
+      SetLinkDNSEx(in  i ifindex,
+                   in  a(iayqs) addresses);
+      SetLinkDomains(in  i ifindex,
+                     in  a(sb) domains);
+      SetLinkDefaultRoute(in  i ifindex,
+                          in  b enable);
+      SetLinkLLMNR(in  i ifindex,
+                   in  s mode);
+      SetLinkMulticastDNS(in  i ifindex,
+                          in  s mode);
+      SetLinkDNSOverTLS(in  i ifindex,
+                        in  s mode);
+      SetLinkDNSSEC(in  i ifindex,
+                    in  s mode);
+      SetLinkDNSSECNegativeTrustAnchors(in  i ifindex,
+                                        in  as names);
+      RevertLinkNTP(in  i ifindex);
+      RevertLinkDNS(in  i ifindex);
+      RenewLink(in  i ifindex);
+      ForceRenewLink(in  i ifindex);
+      ReconfigureLink(in  i ifindex);
+      Reload();
+      DescribeLink(in  i ifindex,
+                   out s json);
+      Describe(out s json);
+    properties:
+      readonly s OperationalState = '...';
+      readonly s CarrierState = '...';
+      readonly s AddressState = '...';
+      readonly s IPv4AddressState = '...';
+      readonly s IPv6AddressState = '...';
+      readonly s OnlineState = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t NamespaceId = ...;
+  };
+  interface org.freedesktop.DBus.Peer { ... };
+  interface org.freedesktop.DBus.Introspectable { ... };
+  interface org.freedesktop.DBus.Properties { ... };
+};
+    </programlisting>
+
+    <!--method ListLinks is not documented!-->
+
+    <!--method GetLinkByName is not documented!-->
+
+    <!--method GetLinkByIndex is not documented!-->
+
+    <!--method SetLinkNTP is not documented!-->
+
+    <!--method SetLinkDNS is not documented!-->
+
+    <!--method SetLinkDNSEx is not documented!-->
+
+    <!--method SetLinkDomains is not documented!-->
+
+    <!--method SetLinkDefaultRoute is not documented!-->
+
+    <!--method SetLinkLLMNR is not documented!-->
+
+    <!--method SetLinkMulticastDNS is not documented!-->
+
+    <!--method SetLinkDNSOverTLS is not documented!-->
+
+    <!--method SetLinkDNSSEC is not documented!-->
+
+    <!--method SetLinkDNSSECNegativeTrustAnchors is not documented!-->
+
+    <!--method RevertLinkNTP is not documented!-->
+
+    <!--method RevertLinkDNS is not documented!-->
+
+    <!--method RenewLink is not documented!-->
+
+    <!--method ForceRenewLink is not documented!-->
+
+    <!--method ReconfigureLink is not documented!-->
+
+    <!--method Reload is not documented!-->
+
+    <!--method DescribeLink is not documented!-->
+
+    <!--method Describe is not documented!-->
+
+    <!--property OperationalState is not documented!-->
+
+    <!--property CarrierState is not documented!-->
+
+    <!--property AddressState is not documented!-->
+
+    <!--property IPv4AddressState is not documented!-->
+
+    <!--property IPv6AddressState is not documented!-->
+
+    <!--property OnlineState is not documented!-->
+
+    <!--property NamespaceId is not documented!-->
+
+    <!--Autogenerated cross-references for systemd.directives, do not edit-->
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.network1.Manager"/>
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.network1.Manager"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="ListLinks()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="GetLinkByName()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="GetLinkByIndex()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SetLinkNTP()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SetLinkDNS()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SetLinkDNSEx()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SetLinkDomains()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SetLinkDefaultRoute()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SetLinkLLMNR()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SetLinkMulticastDNS()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SetLinkDNSOverTLS()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SetLinkDNSSEC()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SetLinkDNSSECNegativeTrustAnchors()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="RevertLinkNTP()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="RevertLinkDNS()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="RenewLink()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="ForceRenewLink()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="ReconfigureLink()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="Reload()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="DescribeLink()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="Describe()"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="OperationalState"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CarrierState"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="AddressState"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IPv4AddressState"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IPv6AddressState"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="OnlineState"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="NamespaceId"/>
+
+    <!--End of Autogenerated section-->
+
+    <para>
+      Provides information about the manager.
+    </para>
+  </refsect1>
+
+  <refsect1>
+    <title>Link Object</title>
+
+    <programlisting executable="systemd-networkd" node="/org/freedesktop/network1/link/_1" interface="org.freedesktop.network1.Link">
+node /org/freedesktop/network1/link/_1 {
+  interface org.freedesktop.network1.Link {
+    methods:
+      SetNTP(in  as servers);
+      SetDNS(in  a(iay) addresses);
+      SetDNSEx(in  a(iayqs) addresses);
+      SetDomains(in  a(sb) domains);
+      SetDefaultRoute(in  b enable);
+      SetLLMNR(in  s mode);
+      SetMulticastDNS(in  s mode);
+      SetDNSOverTLS(in  s mode);
+      SetDNSSEC(in  s mode);
+      SetDNSSECNegativeTrustAnchors(in  as names);
+      RevertNTP();
+      RevertDNS();
+      Renew();
+      ForceRenew();
+      Reconfigure();
+      Describe(out s json);
+    properties:
+      readonly s OperationalState = '...';
+      readonly s CarrierState = '...';
+      readonly s AddressState = '...';
+      readonly s IPv4AddressState = '...';
+      readonly s IPv6AddressState = '...';
+      readonly s OnlineState = '...';
+      readonly s AdministrativeState = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly (tt) BitRates = ...;
+  };
+  interface org.freedesktop.DBus.Peer { ... };
+  interface org.freedesktop.DBus.Introspectable { ... };
+  interface org.freedesktop.DBus.Properties { ... };
+};
+    </programlisting>
+
+    <!--method SetNTP is not documented!-->
+
+    <!--method SetDNS is not documented!-->
+
+    <!--method SetDNSEx is not documented!-->
+
+    <!--method SetDomains is not documented!-->
+
+    <!--method SetDefaultRoute is not documented!-->
+
+    <!--method SetLLMNR is not documented!-->
+
+    <!--method SetMulticastDNS is not documented!-->
+
+    <!--method SetDNSOverTLS is not documented!-->
+
+    <!--method SetDNSSEC is not documented!-->
+
+    <!--method SetDNSSECNegativeTrustAnchors is not documented!-->
+
+    <!--method RevertNTP is not documented!-->
+
+    <!--method RevertDNS is not documented!-->
+
+    <!--method Renew is not documented!-->
+
+    <!--method ForceRenew is not documented!-->
+
+    <!--method Reconfigure is not documented!-->
+
+    <!--method Describe is not documented!-->
+
+    <!--property OperationalState is not documented!-->
+
+    <!--property CarrierState is not documented!-->
+
+    <!--property AddressState is not documented!-->
+
+    <!--property IPv4AddressState is not documented!-->
+
+    <!--property IPv6AddressState is not documented!-->
+
+    <!--property OnlineState is not documented!-->
+
+    <!--property AdministrativeState is not documented!-->
+
+    <!--property BitRates is not documented!-->
+
+    <!--Autogenerated cross-references for systemd.directives, do not edit-->
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.network1.Link"/>
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.network1.Link"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SetNTP()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SetDNS()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SetDNSEx()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SetDomains()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SetDefaultRoute()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SetLLMNR()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SetMulticastDNS()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SetDNSOverTLS()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SetDNSSEC()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SetDNSSECNegativeTrustAnchors()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="RevertNTP()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="RevertDNS()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="Renew()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="ForceRenew()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="Reconfigure()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="Describe()"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="OperationalState"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CarrierState"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="AddressState"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IPv4AddressState"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IPv6AddressState"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="OnlineState"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="AdministrativeState"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="BitRates"/>
+
+    <!--End of Autogenerated section-->
+
+    <para>
+      Provides information about interfaces.
+    </para>
+  </refsect1>
+
+  <refsect1>
+    <title>Network Object</title>
+
+    <programlisting executable="systemd-networkd" node="/org/freedesktop/network1/network/_1" interface="org.freedesktop.network1.Network">
+node /org/freedesktop/network1/network/_1 {
+  interface org.freedesktop.network1.Network {
+    properties:
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s Description = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s SourcePath = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as MatchMAC = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as MatchPath = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as MatchDriver = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as MatchType = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as MatchName = ['...', ...];
+  };
+  interface org.freedesktop.DBus.Peer { ... };
+  interface org.freedesktop.DBus.Introspectable { ... };
+  interface org.freedesktop.DBus.Properties { ... };
+};
+    </programlisting>
+
+    <!--property Description is not documented!-->
+
+    <!--property SourcePath is not documented!-->
+
+    <!--property MatchMAC is not documented!-->
+
+    <!--property MatchPath is not documented!-->
+
+    <!--property MatchDriver is not documented!-->
+
+    <!--property MatchType is not documented!-->
+
+    <!--property MatchName is not documented!-->
+
+    <!--Autogenerated cross-references for systemd.directives, do not edit-->
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.network1.Network"/>
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.network1.Network"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Description"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SourcePath"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MatchMAC"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MatchPath"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MatchDriver"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MatchType"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MatchName"/>
+
+    <!--End of Autogenerated section-->
+
+    <para>
+      Provides information about .network files.
+    </para>
+  </refsect1>
+
+  <refsect1>
+    <title>DHCP Server Object</title>
+
+    <programlisting executable="systemd-networkd" node="/org/freedesktop/network1/link/_1" interface="org.freedesktop.network1.DHCPServer">
+node /org/freedesktop/network1/link/_1 {
+  interface org.freedesktop.network1.DHCPServer {
+    properties:
+      readonly a(uayayayayt) Leases = [...];
+  };
+  interface org.freedesktop.DBus.Peer { ... };
+  interface org.freedesktop.DBus.Introspectable { ... };
+  interface org.freedesktop.DBus.Properties { ... };
+  interface org.freedesktop.network1.Link { ... };
+};
+    </programlisting>
+
+    <!--property Leases is not documented!-->
+
+    <!--Autogenerated cross-references for systemd.directives, do not edit-->
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.network1.Link"/>
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.network1.DHCPServer"/>
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.network1.Link"/>
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.network1.DHCPServer"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Leases"/>
+
+    <!--End of Autogenerated section-->
+
+    <para>
+      Provides information about leases.
+    </para>
+  </refsect1>
+
+  <refsect1>
+    <title>DHCPv4 Client Object</title>
+
+    <programlisting executable="systemd-networkd" node="/org/freedesktop/network1/link/_1" interface="org.freedesktop.network1.DHCPv4Client">
+node /org/freedesktop/network1/link/_1 {
+  interface org.freedesktop.network1.DHCPv4Client {
+    properties:
+      readonly s State = '...';
+  };
+  interface org.freedesktop.DBus.Peer { ... };
+  interface org.freedesktop.DBus.Introspectable { ... };
+  interface org.freedesktop.DBus.Properties { ... };
+  interface org.freedesktop.network1.Link { ... };
+};
+    </programlisting>
+
+    <!--property State is not documented!-->
+
+    <!--Autogenerated cross-references for systemd.directives, do not edit-->
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.network1.Link"/>
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.network1.DHCPv4Client"/>
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.network1.Link"/>
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.network1.DHCPv4Client"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="State"/>
+
+    <!--End of Autogenerated section-->
+
+    <para>
+      Provides information about DHCPv4 client status.
+    </para>
+  </refsect1>
+
+  <refsect1>
+    <title>DHCPv6 Client Object</title>
+
+    <programlisting executable="systemd-networkd" node="/org/freedesktop/network1/link/_1" interface="org.freedesktop.network1.DHCPv6Client">
+node /org/freedesktop/network1/link/_1 {
+  interface org.freedesktop.network1.DHCPv6Client {
+    properties:
+      readonly s State = '...';
+  };
+  interface org.freedesktop.DBus.Peer { ... };
+  interface org.freedesktop.DBus.Introspectable { ... };
+  interface org.freedesktop.DBus.Properties { ... };
+  interface org.freedesktop.network1.Link { ... };
+};
+    </programlisting>
+
+    <!--property State is not documented!-->
+
+    <!--Autogenerated cross-references for systemd.directives, do not edit-->
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.network1.Link"/>
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.network1.DHCPv6Client"/>
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.network1.Link"/>
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.network1.DHCPv6Client"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="State"/>
+
+    <!--End of Autogenerated section-->
+
+    <para>
+      Provides information about DHCPv6 client status.
+    </para>
+  </refsect1>
+
+  <refsect1>
+    <title>Examples</title>
+
+    <example>
+      <title>Introspect <interfacename>org.freedesktop.network1.Manager</interfacename> on the bus</title>
+
+      <programlisting>
+$ gdbus introspect --system \
+  --dest org.freedesktop.network1 \
+  --object-path /org/freedesktop/network1
+      </programlisting>
+    </example>
+
+    <example>
+      <title>Introspect <interfacename>org.freedesktop.network1.Link</interfacename> on the bus</title>
+
+      <programlisting>
+$ gdbus introspect --system \
+  --dest org.freedesktop.network1 \
+  --object-path /org/freedesktop/network1/link/_11
+      </programlisting>
+    </example>
+  </refsect1>
+
+  <xi:include href="org.freedesktop.locale1.xml" xpointer="versioning"/>
+
+  <refsect1>
+    <title>History</title>
+    <refsect2>
+      <title>DHCPv4 Client Object</title>
+      <para><varname>State</varname> was added in version 255.</para>
+    </refsect2>
+    <refsect2>
+      <title>DHCPv6 Client Object</title>
+      <para><varname>State</varname> was added in version 255.</para>
+    </refsect2>
+  </refsect1>
+</refentry>
diff --git a/man/org.freedesktop.oom1.xml b/man/org.freedesktop.oom1.xml
new file mode 100644
index 0000000..8339e63
--- /dev/null
+++ b/man/org.freedesktop.oom1.xml
@@ -0,0 +1,106 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" >
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="org.freedesktop.oom1" conditional='ENABLE_OOMD'
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+  <refentryinfo>
+    <title>org.freedesktop.oom1</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>org.freedesktop.oom1</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>org.freedesktop.oom1</refname>
+    <refpurpose>The D-Bus interface of systemd-oomd</refpurpose>
+  </refnamediv>
+
+  <refsect1>
+    <title>Introduction</title>
+
+    <para>
+    <citerefentry><refentrytitle>systemd-oomd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    is a system service which implements a userspace out-of-memory (OOM) killer. This page describes the
+    D-Bus interface.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>The Manager Object</title>
+
+    <para>The service exposes the following interfaces on the Manager object on the bus:</para>
+
+    <programlisting executable="systemd-oomd" node="/org/freedesktop/oom1" interface="org.freedesktop.oom1.Manager">
+node /org/freedesktop/oom1 {
+  interface org.freedesktop.oom1.Manager {
+    methods:
+      DumpByFileDescriptor(out h fd);
+    signals:
+      Killed(s cgroup,
+             s reason);
+  };
+  interface org.freedesktop.DBus.Peer { ... };
+  interface org.freedesktop.DBus.Introspectable { ... };
+  interface org.freedesktop.DBus.Properties { ... };
+};
+    </programlisting>
+
+    <!--method DumpByFileDescriptor is not documented!-->
+
+    <!--Autogenerated cross-references for systemd.directives, do not edit-->
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.oom1.Manager"/>
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.oom1.Manager"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="DumpByFileDescriptor()"/>
+
+    <variablelist class="dbus-signal" generated="True" extra-ref="Killed"/>
+
+    <!--End of Autogenerated section-->
+
+    <refsect2>
+      <title>Methods</title>
+
+      <para><function>Killed</function> signal is sent when any cgroup is killed by oomd.</para>
+      <para>Note that more reasons will be added in the future, and the table below will be expanded accordingly.</para>
+      <table>
+        <title>Killing reasons</title>
+        <tgroup cols="2" align="left" colsep="1" rowsep="1">
+        <colspec colname="reason"/>
+        <colspec colname="description"/>
+        <thead>
+          <row>
+            <entry>Reason</entry>
+            <entry>Description</entry>
+          </row>
+        </thead>
+        <tbody>
+          <row>
+            <entry>memory-used</entry>
+            <entry>Application took too much memory and swap.</entry>
+          </row>
+          <row>
+            <entry>memory-pressure</entry>
+            <entry>Application took enough memory and swap to cause sufficient slowdown of other applications.</entry>
+          </row>
+        </tbody>
+        </tgroup>
+      </table>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="org.freedesktop.locale1.xml" xpointer="versioning"/>
+
+  <refsect1>
+    <title>History</title>
+    <refsect2>
+      <title>The Manager Object</title>
+      <para><function>Killed</function> was added in version 252.</para>
+    </refsect2>
+  </refsect1>
+</refentry>
diff --git a/man/org.freedesktop.portable1.xml b/man/org.freedesktop.portable1.xml
new file mode 100644
index 0000000..6da7b0c
--- /dev/null
+++ b/man/org.freedesktop.portable1.xml
@@ -0,0 +1,585 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" >
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="org.freedesktop.portable1" conditional='ENABLE_PORTABLED'
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+  <refentryinfo>
+    <title>org.freedesktop.portable1</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>org.freedesktop.portable1</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>org.freedesktop.portable1</refname>
+    <refpurpose>The D-Bus interface of systemd-portabled</refpurpose>
+  </refnamediv>
+
+  <refsect1>
+    <title>Introduction</title>
+
+    <para>
+    <citerefentry><refentrytitle>systemd-portabled.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    is a system service that may be used to attach, detach and inspect portable services. This page describes the
+    D-Bus interface.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>The Manager Object</title>
+
+    <para>The service exposes the following interfaces on the Manager object on the bus:</para>
+
+    <programlisting executable="systemd-portabled" node="/org/freedesktop/portable1" interface="org.freedesktop.portable1.Manager">
+node /org/freedesktop/portable1 {
+  interface org.freedesktop.portable1.Manager {
+    methods:
+      GetImage(in  s image,
+               out o object);
+      ListImages(out a(ssbtttso) images);
+      GetImageOSRelease(in  s image,
+                        out a{ss} os_release);
+      GetImageMetadata(in  s image,
+                       in  as matches,
+                       out s image,
+                       out ay os_release,
+                       out a{say} units);
+      GetImageMetadataWithExtensions(in  s image,
+                                     in  as extensions,
+                                     in  as matches,
+                                     in  t flags,
+                                     out s image,
+                                     out ay os_release,
+                                     out a{say} extensions,
+                                     out a{say} units);
+      GetImageState(in  s image,
+                    out s state);
+      GetImageStateWithExtensions(in  s image,
+                                  in  as extensions,
+                                  in  t flags,
+                                  out s state);
+      AttachImage(in  s image,
+                  in  as matches,
+                  in  s profile,
+                  in  b runtime,
+                  in  s copy_mode,
+                  out a(sss) changes);
+      AttachImageWithExtensions(in  s image,
+                                in  as extensions,
+                                in  as matches,
+                                in  s profile,
+                                in  s copy_mode,
+                                in  t flags,
+                                out a(sss) changes);
+      DetachImage(in  s image,
+                  in  b runtime,
+                  out a(sss) changes);
+      DetachImageWithExtensions(in  s image,
+                                in  as extensions,
+                                in  t flags,
+                                out a(sss) changes);
+      ReattachImage(in  s image,
+                    in  as matches,
+                    in  s profile,
+                    in  b runtime,
+                    in  s copy_mode,
+                    out a(sss) changes_removed,
+                    out a(sss) changes_updated);
+      ReattachImageWithExtensions(in  s image,
+                                  in  as extensions,
+                                  in  as matches,
+                                  in  s profile,
+                                  in  s copy_mode,
+                                  in  t flags,
+                                  out a(sss) changes_removed,
+                                  out a(sss) changes_updated);
+      RemoveImage(in  s image);
+      MarkImageReadOnly(in  s image,
+                        in  b read_only);
+      SetImageLimit(in  s image,
+                    in  t limit);
+      SetPoolLimit(in  t limit);
+    properties:
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s PoolPath = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t PoolUsage = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t PoolLimit = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly as Profiles = ['...', ...];
+  };
+  interface org.freedesktop.DBus.Peer { ... };
+  interface org.freedesktop.DBus.Introspectable { ... };
+  interface org.freedesktop.DBus.Properties { ... };
+};
+    </programlisting>
+
+    <!--Autogenerated cross-references for systemd.directives, do not edit-->
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.portable1.Manager"/>
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.portable1.Manager"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="GetImage()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="ListImages()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="GetImageOSRelease()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="GetImageMetadata()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="GetImageMetadataWithExtensions()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="GetImageState()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="GetImageStateWithExtensions()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="AttachImage()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="AttachImageWithExtensions()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="DetachImage()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="DetachImageWithExtensions()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="ReattachImage()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="ReattachImageWithExtensions()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="RemoveImage()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="MarkImageReadOnly()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SetImageLimit()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SetPoolLimit()"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="PoolPath"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="PoolUsage"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="PoolLimit"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Profiles"/>
+
+    <!--End of Autogenerated section-->
+
+    <refsect2>
+      <title>Methods</title>
+
+      <para><function>GetImage()</function> may be used to get the image object path of the image with the
+      specified name.</para>
+
+      <para><function>ListImages()</function> returns an array of all currently known images. The
+      structures in the array consist of the following fields: image name, type, read-only flag, creation
+      time, modification time, current disk space, usage and image object path.</para>
+
+      <para><function>GetImageOSRelease()</function> retrieves the OS release information of an image.
+      This method returns an array of key value pairs read from the
+      <citerefentry><refentrytitle>os-release</refentrytitle><manvolnum>5</manvolnum></citerefentry> file in
+      the image and is useful to identify the operating system used in a portable service.</para>
+
+      <para><function>GetImageMetadata()</function> retrieves metadata associated with an image.
+      This method returns the image name, the image's <citerefentry><refentrytitle>os-release</refentrytitle>
+      <manvolnum>5</manvolnum></citerefentry> content in the form of a (streamable) array of bytes,
+      and a list of portable units contained in the image, in the form of a string (unit name) and
+      an array of bytes with the content.</para>
+
+      <para><function>GetImageMetadataWithExtensions()</function> retrieves metadata associated with an
+      image. This method is a superset of <function>GetImageMetadata()</function> with the addition of a list
+      of extensions as input parameter, which were overlaid on top of the main image via
+      <function>AttachImageWithExtensions()</function>. The path of each extension and an array of bytes with
+      the content of the respective extension-release file are returned, one such structure for each
+      extension named in the input arguments.</para>
+
+      <para><function>GetImageState()</function> retrieves the image state as one of the following
+      strings:
+      <itemizedlist>
+        <listitem><para>detached</para></listitem>
+
+        <listitem><para>attached</para></listitem>
+
+        <listitem><para>attached-runtime</para></listitem>
+
+        <listitem><para>enabled</para></listitem>
+
+        <listitem><para>enabled-runtime</para></listitem>
+
+        <listitem><para>running</para></listitem>
+
+        <listitem><para>running-runtime</para></listitem>
+      </itemizedlist></para>
+
+      <para><function>GetImageStateWithExtensions()</function> is a superset of
+      <function>GetImageState()</function>, with additional support for a list of extensions
+      as input parameters, which is necessary to query the state in case the image was attached
+      in that particular way. The <varname>flag</varname> parameter is currently unused and
+      reserved for future purposes.</para>
+
+      <para><function>AttachImage()</function> attaches a portable image to the system.
+      This method takes an image path or name, a list of strings that will be used to search for
+      unit files inside the image (partial or complete matches), a string indicating which
+      portable profile to use for the image (see <varname>Profiles</varname> property for
+      a list of available profiles), a boolean indicating whether to attach the image only
+      for the current boot session, and a string representing the preferred copy mode
+      (whether to copy the image or to just symlink it) with the following possible values:
+      <itemizedlist>
+        <listitem><para>(null)</para></listitem>
+
+        <listitem><para>copy</para></listitem>
+
+        <listitem><para>symlink</para></listitem>
+      </itemizedlist>
+      This method returns the list of changes applied to the system (for example, which unit was
+      added and is now available as a system service). Each change is represented as a triplet of
+      strings: the type of change applied, the path on which it was applied, and the source
+      (if any). The type of change applied will be one of the following possible values:
+      <itemizedlist>
+        <listitem><para>copy</para></listitem>
+
+        <listitem><para>symlink</para></listitem>
+
+        <listitem><para>write</para></listitem>
+
+        <listitem><para>mkdir</para></listitem>
+      </itemizedlist>
+      Note that an image cannot be attached if a unit that it contains is already present
+      on the system. Note that this method returns only after all the listed operations are completed,
+      and due to the I/O involved it might take some time.</para>
+
+      <para><function>AttachImageWithExtensions()</function> attaches a portable image to the system.
+      This method is a superset of <function>AttachImage()</function> with the addition of
+      a list of extensions as input parameter, which will be overlaid on top of the main
+      image. When this method is used, detaching must be done by passing the same arguments via the
+      <function>DetachImageWithExtensions()</function> method. For more details on this functionality,
+      see the <varname>MountImages=</varname> entry on
+      <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+      and <citerefentry><refentrytitle>systemd-sysext</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+      </para>
+
+      <para><function>DetachImage()</function> detaches a portable image from the system.
+      This method takes an image path or name, and a boolean indicating whether the image to
+      detach was attached only for the current boot session or persistently. This method
+      returns the list of changes applied to the system (for example, which unit was removed
+      and is no longer available as a system service). Each change is represented as a triplet of
+      strings: the type of change applied, the path on which it was applied, and the source
+      (if any). The type of change applied will be one of the following possible values:
+      <itemizedlist>
+        <listitem><para>unlink</para></listitem>
+      </itemizedlist>
+      Note that an image cannot be detached if a unit that it contains is running. Note that this method
+      returns only after all the listed operations are completed, and due to the I/O involved it might take
+      some time.</para>
+
+      <para><function>DetachImageWithExtensions()</function> detaches a portable image from the system.
+      This method is a superset of <function>DetachImage()</function> with the addition of
+      a list of extensions as input parameter, which were overlaid on top of the main
+      image via <function>AttachImageWithExtensions()</function>.
+      The <varname>flag</varname> parameter is currently unused and reserved for future purposes.</para>
+
+      <para><function>ReattachImage()</function> combines the effects of the
+      <function>AttachImage()</function> method and the <function>DetachImage()</function> method.
+      The difference is that it is allowed to reattach an image while one or more of its units
+      are running. The reattach operation will fail if no matching image is attached.
+      The input parameters match the <function>AttachImage()</function> method, and the return
+      parameters are the combination of the return parameters of the
+      <function>DetachImage()</function> method (first array, units that were removed) and the
+      <function>AttachImage()</function> method (second array, units that were updated or added).</para>
+
+      <para><function>ReattachImageWithExtensions()</function> reattaches a portable image to the system.
+      This method is a superset of <function>ReattachImage()</function> with the addition of
+      a list of extensions as input parameter, which will be overlaid on top of the main
+      image. For more details on this functionality, see the <varname>MountImages=</varname> entry on
+      <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+      and <citerefentry><refentrytitle>systemd-sysext</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+      The <varname>flag</varname> parameter is currently unused and reserved for future purposes</para>
+
+      <para><function>RemoveImage()</function> removes the image with the specified name.</para>
+
+      <para><function>MarkImageReadOnly()</function> toggles the read-only flag of an image.</para>
+
+      <para><function>SetPoolLimit()</function> sets an overall quota limit on the pool of images.</para>
+
+      <para><function>SetImageLimit()</function> sets a per-image quota limit.</para>
+
+      <para>The <function>AttachImageWithExtensions()</function>,
+      <function>DetachImageWithExtensions()</function> and
+      <function>ReattachImageWithExtensions()</function> methods take in options as flags instead of
+      booleans to allow for extendability. <varname>SD_SYSTEMD_PORTABLE_FORCE_ATTACH</varname> will bypass
+      the safety checks that ensure the units are not running while the image is attached or detached.
+      <varname>SD_SYSTEMD_PORTABLE_FORCE_EXTENSION</varname> will bypass the check that ensures the
+      <filename>extension-release.<replaceable>NAME</replaceable></filename> file in the extension image
+      matches the image name. They are defined as follows:</para>
+
+      <programlisting>
+#define SD_SYSTEMD_PORTABLE_RUNTIME            (UINT64_C(1) &lt;&lt; 0)
+#define SD_SYSTEMD_PORTABLE_FORCE_ATTACH       (UINT64_C(1) &lt;&lt; 1)
+#define SD_SYSTEMD_PORTABLE_FORCE_EXTENSION    (UINT64_C(1) &lt;&lt; 2)
+      </programlisting>
+    </refsect2>
+
+    <refsect2>
+      <title>Properties</title>
+
+      <para><varname>PoolPath</varname> specifies the file system path where images are written to.</para>
+
+      <para><varname>PoolUsage</varname> specifies the current usage size of the image pool in bytes.</para>
+
+      <para><varname>PoolLimit</varname> specifies the size limit of the image pool in bytes.</para>
+
+      <para><varname>Profiles</varname> specifies the available runtime profiles for portable services.</para>
+    </refsect2>
+  </refsect1>
+
+  <refsect1>
+    <title>The Image Object</title>
+
+    <para>The service exposes the following interfaces on the Image object on the bus:</para>
+
+    <programlisting executable="systemd-portabled" node="/org/freedesktop/portable1" interface="org.freedesktop.portable1.Image">
+node /org/freedesktop/portable1 {
+  interface org.freedesktop.portable1.Image {
+    methods:
+      GetOSRelease(out a{ss} os_release);
+      GetMetadata(in  as matches,
+                  out s image,
+                  out ay os_release,
+                  out a{say} units);
+      GetMetadataWithExtensions(in  as extensions,
+                                in  as matches,
+                                in  t flags,
+                                out s image,
+                                out ay os_release,
+                                out a{say} extensions,
+                                out a{say} units);
+      GetState(out s state);
+      GetStateWithExtensions(in  as extensions,
+                             in  t flags,
+                             out s state);
+      Attach(in  as matches,
+             in  s profile,
+             in  b runtime,
+             in  s copy_mode,
+             out a(sss) changes);
+      AttachWithExtensions(in  as extensions,
+                           in  as matches,
+                           in  s profile,
+                           in  s copy_mode,
+                           in  t flags,
+                           out a(sss) changes);
+      Detach(in  b runtime,
+             out a(sss) changes);
+      DetachWithExtensions(in  as extensions,
+                           in  t flags,
+                           out a(sss) changes);
+      Reattach(in  as matches,
+               in  s profile,
+               in  b runtime,
+               in  s copy_mode,
+               out a(sss) changes_removed,
+               out a(sss) changes_updated);
+      ReattachWithExtensions(in  as extensions,
+                             in  as matches,
+                             in  s profile,
+                             in  s copy_mode,
+                             in  t flags,
+                             out a(sss) changes_removed,
+                             out a(sss) changes_updated);
+      Remove();
+      MarkReadOnly(in  b read_only);
+      SetLimit(in  t limit);
+    properties:
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s Name = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s Path = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s Type = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly b ReadOnly = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t CreationTimestamp = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t ModificationTimestamp = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t Usage = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t Limit = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t UsageExclusive = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t LimitExclusive = ...;
+  };
+  interface org.freedesktop.DBus.Peer { ... };
+  interface org.freedesktop.DBus.Introspectable { ... };
+  interface org.freedesktop.DBus.Properties { ... };
+};
+    </programlisting>
+
+    <!--method GetOSRelease is not documented!-->
+
+    <!--method GetMetadata is not documented!-->
+
+    <!--method GetMetadataWithExtensions is not documented!-->
+
+    <!--method GetState is not documented!-->
+
+    <!--method GetStateWithExtensions is not documented!-->
+
+    <!--method Attach is not documented!-->
+
+    <!--method AttachWithExtensions is not documented!-->
+
+    <!--method Detach is not documented!-->
+
+    <!--method DetachWithExtensions is not documented!-->
+
+    <!--method Reattach is not documented!-->
+
+    <!--method ReattachWithExtensions is not documented!-->
+
+    <!--method Remove is not documented!-->
+
+    <!--method MarkReadOnly is not documented!-->
+
+    <!--method SetLimit is not documented!-->
+
+    <!--Autogenerated cross-references for systemd.directives, do not edit-->
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.portable1.Image"/>
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.portable1.Image"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="GetOSRelease()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="GetMetadata()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="GetMetadataWithExtensions()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="GetState()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="GetStateWithExtensions()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="Attach()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="AttachWithExtensions()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="Detach()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="DetachWithExtensions()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="Reattach()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="ReattachWithExtensions()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="Remove()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="MarkReadOnly()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SetLimit()"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Name"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Path"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Type"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ReadOnly"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CreationTimestamp"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ModificationTimestamp"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Usage"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Limit"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="UsageExclusive"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitExclusive"/>
+
+    <!--End of Autogenerated section-->
+
+    <refsect2>
+      <title>Methods</title>
+
+      <para>The following methods implement the same operation as the respective methods on the
+      <interfacename>Manager</interfacename> object (see above). However, these methods operate on the image
+      object and hence does not take an image name parameter. Invoking the methods directly on the Manager
+      object has the advantage of not requiring a <function>GetImage()</function> call to get the image object
+      for a specific image name. Calling the methods on the Manager object is hence a round trip
+      optimization. List of methods:
+      <itemizedlist>
+        <listitem><para>GetOSRelease()</para></listitem>
+
+        <listitem><para>GetMetadata()</para></listitem>
+
+        <listitem><para>GetMetadataWithExtensions()</para></listitem>
+
+        <listitem><para>GetState()</para></listitem>
+
+        <listitem><para>Attach()</para></listitem>
+
+        <listitem><para>AttachWithExtensions()</para></listitem>
+
+        <listitem><para>Detach()</para></listitem>
+
+        <listitem><para>DetachWithExtensions()</para></listitem>
+
+        <listitem><para>Reattach()</para></listitem>
+
+        <listitem><para>ReattachWithExtensions()</para></listitem>
+
+        <listitem><para>Remove()</para></listitem>
+
+        <listitem><para>MarkReadOnly()</para></listitem>
+
+        <listitem><para>SetLimit()</para></listitem>
+      </itemizedlist></para>
+    </refsect2>
+
+    <refsect2>
+      <title>Properties</title>
+
+      <para><varname>Name</varname> specifies the image name.</para>
+
+      <para><varname>Path</varname> specifies the file system path where image is stored.</para>
+
+      <para><varname>Type</varname> specifies the image type.</para>
+
+      <para><varname>ReadOnly</varname> specifies whether the image is read-only.</para>
+
+      <para><varname>CreationTimestamp</varname> specifies the image creation timestamp.</para>
+
+      <para><varname>ModificationTimestamp</varname> specifies the image modification timestamp.</para>
+
+      <para><varname>Usage</varname> specifies the image disk usage.</para>
+
+      <para><varname>Limit</varname> specifies the image disk usage limit.</para>
+
+      <para><varname>UsageExclusive</varname> specifies the image disk usage (exclusive).</para>
+
+      <para><varname>LimitExclusive</varname> specifies the image disk usage limit (exclusive).</para>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="org.freedesktop.locale1.xml" xpointer="versioning"/>
+
+  <refsect1>
+    <title>History</title>
+    <refsect2>
+      <title>The Manager Object</title>
+      <para><function>GetImageStateWithExtensions()</function> was added in version 251.</para>
+    </refsect2>
+    <refsect2>
+      <title>The Image Object</title>
+      <para><function>GetStateWithExtensions()</function> was added in version 251.</para>
+      <para><function>ReattachWithExtensions()</function> was added in version 254.</para>
+    </refsect2>
+  </refsect1>
+</refentry>
diff --git a/man/org.freedesktop.resolve1.xml b/man/org.freedesktop.resolve1.xml
new file mode 100644
index 0000000..f9cba4f
--- /dev/null
+++ b/man/org.freedesktop.resolve1.xml
@@ -0,0 +1,922 @@
+<?xml version="1.0"?>
+<!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [
+<!ENTITY % entities SYSTEM "custom-entities.ent" >
+%entities;
+]>
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="org.freedesktop.resolve1" conditional='ENABLE_RESOLVE'
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+  <refentryinfo>
+    <title>org.freedesktop.resolve1</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>org.freedesktop.resolve1</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>org.freedesktop.resolve1</refname>
+    <refpurpose>The D-Bus interface of systemd-resolved</refpurpose>
+  </refnamediv>
+
+  <refsect1>
+    <title>Introduction</title>
+
+    <para>
+    <citerefentry><refentrytitle>systemd-resolved.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    is a system service that provides hostname resolution and caching using DNS, LLMNR, and mDNS. It also
+    does DNSSEC validation. This page describes the resolve semantics and the D-Bus interface.</para>
+
+    <para>This page contains an API reference only. If you are looking for a longer explanation how to use
+    this API, please consult
+    <ulink url="https://wiki.freedesktop.org/www/Software/systemd/writing-network-configuration-managers">
+    Writing Network Configuration Managers</ulink> and
+    <ulink url="https://wiki.freedesktop.org/www/Software/systemd/writing-resolver-clients">Writing Resolver
+    Clients</ulink>.
+    </para>
+  </refsect1>
+
+  <refsect1>
+    <title>The Manager Object</title>
+
+    <para>The service exposes the following interfaces on the Manager object on the bus:</para>
+
+    <programlisting executable="systemd-resolved" node="/org/freedesktop/resolve1" interface="org.freedesktop.resolve1.Manager">
+node /org/freedesktop/resolve1 {
+  interface org.freedesktop.resolve1.Manager {
+    methods:
+      ResolveHostname(in  i ifindex,
+                      in  s name,
+                      in  i family,
+                      in  t flags,
+                      out a(iiay) addresses,
+                      out s canonical,
+                      out t flags);
+      ResolveAddress(in  i ifindex,
+                     in  i family,
+                     in  ay address,
+                     in  t flags,
+                     out a(is) names,
+                     out t flags);
+      ResolveRecord(in  i ifindex,
+                    in  s name,
+                    in  q class,
+                    in  q type,
+                    in  t flags,
+                    out a(iqqay) records,
+                    out t flags);
+      ResolveService(in  i ifindex,
+                     in  s name,
+                     in  s type,
+                     in  s domain,
+                     in  i family,
+                     in  t flags,
+                     out a(qqqsa(iiay)s) srv_data,
+                     out aay txt_data,
+                     out s canonical_name,
+                     out s canonical_type,
+                     out s canonical_domain,
+                     out t flags);
+      GetLink(in  i ifindex,
+              out o path);
+      SetLinkDNS(in  i ifindex,
+                 in  a(iay) addresses);
+      SetLinkDNSEx(in  i ifindex,
+                   in  a(iayqs) addresses);
+      SetLinkDomains(in  i ifindex,
+                     in  a(sb) domains);
+      SetLinkDefaultRoute(in  i ifindex,
+                          in  b enable);
+      SetLinkLLMNR(in  i ifindex,
+                   in  s mode);
+      SetLinkMulticastDNS(in  i ifindex,
+                          in  s mode);
+      SetLinkDNSOverTLS(in  i ifindex,
+                        in  s mode);
+      SetLinkDNSSEC(in  i ifindex,
+                    in  s mode);
+      SetLinkDNSSECNegativeTrustAnchors(in  i ifindex,
+                                        in  as names);
+      RevertLink(in  i ifindex);
+      RegisterService(in  s name,
+                      in  s name_template,
+                      in  s type,
+                      in  q service_port,
+                      in  q service_priority,
+                      in  q service_weight,
+                      in  aa{say} txt_datas,
+                      out o service_path);
+      UnregisterService(in  o service_path);
+      ResetStatistics();
+      FlushCaches();
+      ResetServerFeatures();
+    properties:
+      readonly s LLMNRHostname = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s LLMNR = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s MulticastDNS = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s DNSOverTLS = '...';
+      readonly a(iiay) DNS = [...];
+      readonly a(iiayqs) DNSEx = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly a(iiay) FallbackDNS = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly a(iiayqs) FallbackDNSEx = [...];
+      readonly (iiay) CurrentDNSServer = ...;
+      readonly (iiayqs) CurrentDNSServerEx = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(isb) Domains = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly (tt) TransactionStatistics = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly (ttt) CacheStatistics = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s DNSSEC = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly (tttt) DNSSECStatistics = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly b DNSSECSupported = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly as DNSSECNegativeTrustAnchors = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s DNSStubListener = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s ResolvConfMode = '...';
+  };
+  interface org.freedesktop.DBus.Peer { ... };
+  interface org.freedesktop.DBus.Introspectable { ... };
+  interface org.freedesktop.DBus.Properties { ... };
+};
+    </programlisting>
+
+    <!--method RegisterService is not documented!-->
+
+    <!--method UnregisterService is not documented!-->
+
+    <!--method FlushCaches is not documented!-->
+
+    <!--method ResetServerFeatures is not documented!-->
+
+    <!--property DNSSECNegativeTrustAnchors is not documented!-->
+
+    <!--Autogenerated cross-references for systemd.directives, do not edit-->
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.resolve1.Manager"/>
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.resolve1.Manager"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="ResolveHostname()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="ResolveAddress()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="ResolveRecord()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="ResolveService()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="GetLink()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SetLinkDNS()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SetLinkDNSEx()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SetLinkDomains()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SetLinkDefaultRoute()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SetLinkLLMNR()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SetLinkMulticastDNS()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SetLinkDNSOverTLS()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SetLinkDNSSEC()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SetLinkDNSSECNegativeTrustAnchors()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="RevertLink()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="RegisterService()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="UnregisterService()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="ResetStatistics()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="FlushCaches()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="ResetServerFeatures()"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LLMNRHostname"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LLMNR"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MulticastDNS"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DNSOverTLS"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DNS"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DNSEx"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="FallbackDNS"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="FallbackDNSEx"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CurrentDNSServer"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CurrentDNSServerEx"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Domains"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TransactionStatistics"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CacheStatistics"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DNSSEC"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DNSSECStatistics"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DNSSECSupported"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DNSSECNegativeTrustAnchors"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DNSStubListener"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ResolvConfMode"/>
+
+    <!--End of Autogenerated section-->
+
+    <refsect2>
+      <title>Methods</title>
+
+      <para><function>ResolveHostname()</function> takes a hostname and resolves it to one or more IP
+      addresses.  As parameters it takes the Linux network interface index to execute the query on, or 0 if
+      it may be done on any suitable interface. The <varname>name</varname> parameter specifies the hostname
+      to resolve. Note that if required, IDNA conversion is applied to this name unless it is resolved via
+      LLMNR or MulticastDNS. The <varname>family</varname> parameter limits the results to a specific address
+      family. It may be <constant>AF_INET</constant>, <constant>AF_INET6</constant> or
+      <constant>AF_UNSPEC</constant>. If <constant>AF_UNSPEC</constant> is specified (recommended), both
+      kinds are retrieved, subject to local network configuration (i.e. if no local, routable IPv6 address is
+      found, no IPv6 address is retrieved; and similarly for IPv4). A 64-bit <varname>flags</varname> field
+      may be used to alter the behaviour of the resolver operation (see below). The method returns an array
+      of address records. Each address record consists of the interface index the address belongs to, an
+      address family as well as a byte array with the actual IP address data (which either has 4 or 16
+      elements, depending on the address family). The returned address family will be one of
+      <constant>AF_INET</constant> or <constant>AF_INET6</constant>. For IPv6, the returned address interface
+      index should be used to initialize the .sin6_scope_id field of a
+      <structname>struct sockaddr_in6</structname> instance to permit support for resolution to link-local IP
+      addresses. The address array is followed by the canonical name of the host, which may or may not be
+      identical to the resolved hostname. Finally, a 64-bit <varname>flags</varname> field is returned that
+      is defined similarly to the <varname>flags</varname> field that was passed in, but contains information
+      about the resolved data (see below). If the hostname passed in is an IPv4 or IPv6 address formatted as
+      string, it is parsed, and the result is returned. In this case, no network communication is
+      done.</para>
+
+      <para><function>ResolveAddress()</function> executes the reverse operation: it takes an IP address and
+      acquires one or more hostnames for it. As parameters it takes the interface index to execute the query
+      on, or <constant>0</constant> if all suitable interfaces are OK. The <varname>family</varname>
+      parameter indicates the address family of the IP address to resolve. It may be either
+      <constant>AF_INET</constant> or <constant>AF_INET6</constant>. The <varname>address</varname> parameter
+      takes the raw IP address data (as either a 4 or 16 byte array). The <varname>flags</varname> input
+      parameter may be used to alter the resolver operation (see below). The method returns an array of name
+      records, each consisting of an interface index and a hostname.  The <varname>flags</varname> output
+      field contains additional information about the resolver operation (see below).</para>
+
+      <para><function>ResolveRecord()</function> takes a DNS resource record (RR) type, class and name, and
+      retrieves the full resource record set (RRset), including the RDATA, for it. As parameter it takes the
+      Linux network interface index to execute the query on, or <constant>0</constant> if it may be done on
+      any suitable interface. The <varname>name</varname> parameter specifies the RR domain name to look up
+      (no IDNA conversion is applied), followed by the 16-bit class and type fields (which may be
+      ANY). Finally, a <varname>flags</varname> field may be passed in to alter behaviour of the look-up (see
+      below). On completion, an array of RR items is returned. Each array entry consists of the network interface
+      index the RR was discovered on, the type and class field of the RR found, and a byte array of the raw
+      RR discovered. The raw RR data starts with the RR's domain name, in the original casing, followed
+      by the RR type, class, TTL and RDATA, in the binary format documented in
+      <ulink url="https://www.ietf.org/rfc/rfc1035.txt">RFC 1035</ulink>. For RRs that support name
+      compression in the payload (such as MX or PTR), the compression is expanded in the returned
+      data.</para>
+
+      <para>Note that currently, the class field has to be specified as IN or ANY. Specifying a different
+      class will return an error indicating that look-ups of this kind are unsupported. Similarly, some
+      special types are not supported either (AXFR, OPT, …). While <filename>systemd-resolved</filename> parses and validates resource
+      records of many types, it is crucial that clients using this API understand that the RR data originates
+      from the network and should be thoroughly validated before use.</para>
+
+      <para><function>ResolveService()</function> may be used to resolve a DNS
+      <constant class="dns">SRV</constant> service record, as well as the hostnames referenced in it, and
+      possibly an accompanying DNS-SD <constant class="dns">TXT</constant> record containing additional
+      service metadata.  The primary benefit of using this method over <function>ResolveRecord()</function>
+      specifying the <constant class="dns">SRV</constant> type is that it will resolve the
+      <constant class="dns">SRV</constant> and <constant class="dns">TXT</constant> RRs as well as the
+      hostnames referenced in the SRV in a single operation. As parameters it takes a Linux network interface
+      index, a service name, a service type and a service domain. This method may be invoked in three
+      different modes:</para>
+
+      <orderedlist>
+        <listitem><para>To resolve a DNS-SD service, specify the service name (e.g. <literal>Lennart's
+        Files</literal>), the service type (e.g. <literal>_webdav._tcp</literal>) and the domain to search in
+        (e.g. <literal>local</literal>) as the three service parameters. The service name must be in UTF-8
+        format, and no IDNA conversion is applied to it in this mode (as mandated by the DNS-SD
+        specifications). However, if necessary, IDNA conversion is applied to the domain parameter.</para>
+        </listitem>
+
+        <listitem><para>To resolve a plain <constant class="dns">SRV</constant> record, set the service name
+        parameter to the empty string and set the service type and domain properly. (IDNA conversion is
+        applied to the domain, if necessary.)</para></listitem>
+
+        <listitem><para>Alternatively, leave both the service name and type empty and specify the full domain
+        name of the <constant class="dns">SRV</constant> record (i.e. prefixed with the service type) in the
+        domain parameter. (No IDNA conversion is applied in this mode.)</para></listitem>
+      </orderedlist>
+
+      <para>The <varname>family</varname> parameter of the <function>ResolveService()</function> method encodes
+      the desired family of the addresses to resolve (use <constant>AF_INET</constant>,
+      <constant>AF_INET6</constant>, or <constant>AF_UNSPEC</constant>). If this is enabled (Use the
+      <constant>NO_ADDRESS</constant> flag to turn address resolution off, see below). The
+      <varname>flags</varname> parameter takes a couple of flags that may be used to alter the resolver
+      operation.</para>
+
+      <para>On completion, <function>ResolveService()</function> returns an array of
+      <constant class="dns">SRV</constant> record structures. Each items consisting of the priority, weight and port
+      fields as well as the hostname to contact, as encoded in the <constant class="dns">SRV</constant>
+      record. Immediately following is an array of the addresses of this hostname, with each item consisting
+      of the interface index, the address family and the address data in a byte array. This address array is
+      followed by the canonicalized hostname. After this array of <constant class="dns">SRV</constant> record
+      structures an array of byte arrays follows that encodes the TXT RR strings, in case DNS-SD look-ups are
+      enabled. The next parameters are the canonical service name, type and domain. This may or may not be
+      identical to the parameters passed in. Finally, a <varname>flags</varname> field is returned that
+      contains information about the resolver operation performed.</para>
+
+      <para>The <function>ResetStatistics()</function> method resets the various statistics counters that
+      <filename>systemd-resolved</filename> maintains to zero. (For details, see the statistics properties below.)</para>
+
+      <para>The <function>GetLink()</function> method takes a network interface index and returns the object
+      path to the <interfacename>org.freedesktop.resolve1.Link</interfacename> object corresponding to it.
+      </para>
+
+      <para>The <function>SetLinkDNS()</function> method sets the DNS servers to use on a specific
+      interface. This method (and the following ones) may be used by network management software to configure
+      per-interface DNS settings. It takes a network interface index as well as an array of DNS server IP
+      address records. Each array item consists of an address family (either <constant>AF_INET</constant> or
+      <constant>AF_INET6</constant>), followed by a 4-byte or 16-byte array with the raw address data. This
+      method is a one-step shortcut for retrieving the Link object for a network interface using
+      <function>GetLink()</function> (see above) and then invoking the <function>SetDNS()</function> method
+      (see below) on it.</para>
+
+      <para><function>SetLinkDNSEx()</function> is similar to <function>SetLinkDNS()</function>, but allows
+      an IP port (instead of the default 53) and DNS name to be specified for each DNS server. The server
+      name is used for Server Name Indication (SNI), which is useful when DNS-over-TLS is
+      used. C.f. <varname>DNS=</varname> in
+      <citerefentry><refentrytitle>resolved.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+      </para>
+
+      <para><function>SetLinkDefaultRoute()</function> specifies whether the link shall be used as the
+      default route for name queries. See the description of name routing in
+      <citerefentry><refentrytitle>systemd-resolved.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+      for details.</para>
+
+      <para>The <function>SetLinkDomains()</function> method sets the search and routing domains to use on a
+      specific network interface for DNS look-ups. It takes a network interface index and an array of domains,
+      each with a boolean parameter indicating whether the specified domain shall be used as a search domain
+      (false), or just as a routing domain (true). Search domains are used for qualifying single-label names into
+      FQDN when looking up hostnames, as well as for making routing decisions on which interface to send
+      queries ending in the domain to. Routing domains are only used for routing decisions and not used for single-label
+      name qualification. Pass the search domains in the order they should be used.</para>
+
+      <para>The <function>SetLinkLLMNR()</function> method enables or disables LLMNR support on a specific
+      network interface. It takes a network interface index as well as a string that may either be empty or one of
+      <literal>yes</literal>, <literal>no</literal> or <literal>resolve</literal>. If empty, the systemd-wide
+      default LLMNR setting is used. If <literal>yes</literal>, LLMNR is used for resolution of single-label
+      names and the local hostname is registered on all local LANs for LLMNR resolution by peers. If
+      <literal>no</literal>, LLMNR is turned off fully on this interface. If <literal>resolve</literal>, LLMNR
+      is only enabled for resolving names, but the local hostname is not registered for other peers to
+      use.</para>
+
+      <para>Similarly, the <function>SetLinkMulticastDNS()</function> method enables or disables MulticastDNS
+      support on a specific interface. It takes the same parameters as <function>SetLinkLLMNR()</function>
+      described above.</para>
+
+      <para>The <function>SetLinkDNSSEC()</function> method enables or disables DNSSEC validation on a
+      specific network interface. It takes a network interface index as well as a string that may either be
+      empty or one of <literal>yes</literal>, <literal>no</literal>, or <literal>allow-downgrade</literal>. When
+      empty, the system-wide default DNSSEC setting is used. If <literal>yes</literal>, full DNSSEC validation
+      is done for all look-ups. If the selected DNS server does not support DNSSEC, look-ups will fail if this
+      mode is used. If <literal>no</literal>, DNSSEC validation is fully disabled. If
+      <literal>allow-downgrade</literal>, DNSSEC validation is enabled, but is turned off automatically if the
+      selected server does not support it (thus opening up behaviour to downgrade attacks). Note that DNSSEC
+      only applies to traditional DNS, not to LLMNR or MulticastDNS.</para>
+
+      <para>The <function>SetLinkDNSSECNegativeTrustAnchors()</function> method may be used to configure DNSSEC
+      Negative Trust Anchors (NTAs) for a specific network interface. It takes a network interface index and a
+      list of domains as arguments.</para>
+
+      <para>The <function>SetLinkDNSOverTLS()</function> method enables or disables DNS-over-TLS.
+      C.f. <varname>DNSOverTLS=</varname> in
+      <citerefentry><refentrytitle>systemd-resolved.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+      for details.</para>
+
+      <para>Network management software integrating with <filename>systemd-resolved</filename> should call
+      <function>SetLinkDNS()</function> or <function>SetLinkDNSEx()</function>,
+      <function>SetLinkDefaultRoute()</function>, <function>SetLinkDomains()</function> and others after the
+      interface appeared in the kernel (and thus after a network interface index has been assigned), but
+      before the network interfaces is activated (<constant>IFF_UP</constant> set) so that all settings take
+      effect during the full time the network interface is up. It is safe to alter settings while the
+      interface is up, however. Use <function>RevertLink()</function> (described below) to reset all
+      per-interface settings.</para>
+
+      <para>The <function>RevertLink()</function> method may be used to revert all per-link settings
+      described above to the defaults.</para>
+
+      <refsect3>
+        <title>The Flags Parameter</title>
+
+        <para>The four methods above accept and return a 64-bit flags value. In most cases passing 0 is sufficient
+        and recommended. However, the following flags are defined to alter the look-up:</para>
+
+        <programlisting>/* Input+Output: Protocol/scope */
+#define SD_RESOLVED_DNS               (UINT64_C(1) &lt;&lt;  0)
+#define SD_RESOLVED_LLMNR_IPV4        (UINT64_C(1) &lt;&lt;  1)
+#define SD_RESOLVED_LLMNR_IPV6        (UINT64_C(1) &lt;&lt;  2)
+#define SD_RESOLVED_MDNS_IPV4         (UINT64_C(1) &lt;&lt;  3)
+#define SD_RESOLVED_MDNS_IPV6         (UINT64_C(1) &lt;&lt;  4)
+
+/* Input: Restrictions */
+#define SD_RESOLVED_NO_CNAME          (UINT64_C(1) &lt;&lt;  5)
+#define SD_RESOLVED_NO_TXT            (UINT64_C(1) &lt;&lt;  6)
+#define SD_RESOLVED_NO_ADDRESS        (UINT64_C(1) &lt;&lt;  7)
+#define SD_RESOLVED_NO_SEARCH         (UINT64_C(1) &lt;&lt;  8)
+#define SD_RESOLVED_NO_VALIDATE       (UINT64_C(1) &lt;&lt; 10)
+#define SD_RESOLVED_NO_SYNTHESIZE     (UINT64_C(1) &lt;&lt; 11)
+#define SD_RESOLVED_NO_CACHE          (UINT64_C(1) &lt;&lt; 12)
+#define SD_RESOLVED_NO_ZONE           (UINT64_C(1) &lt;&lt; 13)
+#define SD_RESOLVED_NO_TRUST_ANCHOR   (UINT64_C(1) &lt;&lt; 14)
+#define SD_RESOLVED_NO_NETWORK        (UINT64_C(1) &lt;&lt; 15)
+#define SD_RESOLVED_NO_STALE          (UINT64_C(1) &lt;&lt; 24)
+
+/* Output: Security */
+#define SD_RESOLVED_AUTHENTICATED     (UINT64_C(1) &lt;&lt;  9)
+#define SD_RESOLVED_CONFIDENTIAL      (UINT64_C(1) &lt;&lt; 18)
+
+/* Output: Origin */
+#define SD_RESOLVED_SYNTHETIC         (UINT64_C(1) &lt;&lt; 19)
+#define SD_RESOLVED_FROM_CACHE        (UINT64_C(1) &lt;&lt; 20)
+#define SD_RESOLVED_FROM_ZONE         (UINT64_C(1) &lt;&lt; 21)
+#define SD_RESOLVED_FROM_TRUST_ANCHOR (UINT64_C(1) &lt;&lt; 22)
+#define SD_RESOLVED_FROM_NETWORK      (UINT64_C(1) &lt;&lt; 23)
+</programlisting>
+
+        <para>On input, the first five flags control the protocols to use for the look-up. They refer to
+        classic unicast DNS, LLMNR via IPv4/UDP and IPv6/UDP respectively, as well as MulticastDNS via
+        IPv4/UDP and IPv6/UDP. If all of these five bits are off on input (which is strongly recommended) the
+        look-up will be done via all suitable protocols for the specific look-up. Note that these flags
+        operate as filter only, but cannot force a look-up to be done via a protocol. Specifically,
+        <filename>systemd-resolved</filename> will only route look-ups within the .local TLD to MulticastDNS
+        (plus some reverse look-up address domains), and single-label names to LLMNR (plus some reverse
+        address lookup domains). It will route neither of these to Unicast DNS servers. Also, it will do
+        LLMNR and Multicast DNS only on interfaces suitable for multicast.</para>
+
+        <para>On output, these five flags indicate which protocol was used to execute the operation, and
+        hence where the data was found.</para>
+
+        <para>The primary use cases for these five flags are follow-up look-ups based on DNS data retrieved
+        earlier. In this case it is often a good idea to limit the follow-up look-up to the protocol that was
+        used to discover the first DNS result.</para>
+
+        <para>The NO_CNAME flag controls whether CNAME/DNAME resource records shall be followed during the
+        look-up. This flag is only available at input, none of the functions will return it on output. If a
+        CNAME/DNAME RR is discovered while resolving a hostname, an error is returned instead. By default,
+        when the flag is off, CNAME/DNAME RRs are followed.</para>
+
+        <para>The NO_TXT and NO_ADDRESS flags only influence operation of the
+        <function>ResolveService()</function> method. They are only defined for input, not output. If NO_TXT
+        is set, the DNS-SD TXT RR look-up is not done in the same operation. If NO_ADDRESS is set, the
+        discovered hostnames are not implicitly translated to their addresses.</para>
+
+        <para>The NO_SEARCH flag turns off the search domain logic. It is only defined for input in
+        <function>ResolveHostname()</function>. When specified, single-label hostnames are not qualified
+        using defined search domains, if any are configured. Note that <function>ResolveRecord()</function>
+        will never qualify single-label domain names using search domains. Also note that multi-label
+        hostnames are never subject to search list expansion.</para>
+
+        <para>NO_VALIDATE can be set to disable validation via DNSSEC even if it would normally be
+        used.</para>
+
+        <para>The next six flags allow disabling certain sources during resolution. NO_SYNTHESIZE disables
+        synthetic records, e.g. the local host name, see section SYNTHETIC RECORDS in
+        <citerefentry><refentrytitle>systemd-resolved.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        for more information. NO_CACHE disables the use of the cache of previously resolved records. NO_ZONE
+        disables answers using locally registered public LLMNR/mDNS resource records. NO_TRUST_ANCHOR
+        disables answers using locally configured trust anchors. NO_NETWORK requires all answers to be
+        provided without using the network, i.e. either from local sources or the cache. NO_STALE flag
+        can be set to disable answering request with stale records.</para>
+
+        <para>The AUTHENTICATED bit is defined only in the output flags of the four functions. If set, the
+        returned data has been fully authenticated. Specifically, this bit is set for all DNSSEC-protected
+        data for which a full trust chain may be established to a trusted domain anchor. It is also set for
+        locally synthesized data, such as <literal>localhost</literal> or data from
+        <filename>/etc/hosts</filename>. Moreover, it is set for all LLMNR or mDNS RRs which originate from
+        the local host. Applications that require authenticated RR data for operation should check this flag
+        before trusting the data. Note that <filename>systemd-resolved</filename> will never return
+        invalidated data, hence this flag simply allows one to discern the cases where data is known to be
+        trusted, or where there is proof that the data is "rightfully" unauthenticated (which includes cases
+        where the underlying protocol or server does not support authenticating data).</para>
+
+        <para>CONFIDENTIAL means the query was resolved via encrypted channels or never left this
+        system.</para>
+
+        <para>The next five bits flags are used in output and provide information about the origin of the
+        answer. FROM_SYNTHETIC means the query was (at least partially) synthesized locally. FROM_CACHE means
+        the query was answered (at least partially) using the cache. FROM_ZONE means the query was answered
+        (at least partially) based on public, locally registered records. FROM_TRUST_ANCHOR means the query
+        was answered (at least partially) using local trust anchors. FROM_NETWORK means the query was
+        answered (at least partially) using the network.</para>
+      </refsect3>
+    </refsect2>
+
+    <refsect2>
+      <title>Properties</title>
+
+      <para>The <varname>LLMNR</varname> and <varname>MulticastDNS</varname> properties report whether LLMNR
+      and MulticastDNS are (globally) enabled. Each may be one of <literal>yes</literal>,
+      <literal>no</literal>, and <literal>resolve</literal>. See <function>SetLinkLLMNR()</function>
+      and <function>SetLinkMulticastDNS()</function> above.</para>
+
+      <para><varname>LLMNRHostname</varname> contains the hostname currently exposed on the network via
+      LLMNR. It usually follows the system hostname as may be queried via
+      <citerefentry project="man-pages"><refentrytitle>gethostname</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      but may differ if a conflict is detected on the network.</para>
+
+      <para><varname>DNS</varname> and <varname>DNSEx</varname> contain arrays of all DNS servers currently
+      used by <filename>systemd-resolved</filename>. <varname>DNS</varname> contains information similar to
+      the DNS server data in <filename>/run/systemd/resolve/resolv.conf</filename>. Each structure in the
+      array consists of a numeric network interface index, an address family, and a byte array containing the
+      DNS server address (either 4 bytes in length for IPv4 or 16 bytes in lengths for IPv6).
+      <varname>DNSEx</varname> is similar, but additionally contains the IP port and server name (used for
+      Server Name Indication, SNI). Both arrays contain DNS servers configured system-wide, including those
+      possibly read from a foreign <filename>/etc/resolv.conf</filename> or the <varname>DNS=</varname>
+      setting in <filename>/etc/systemd/resolved.conf</filename>, as well as per-interface DNS server
+      information either retrieved from
+      <citerefentry><refentrytitle>systemd-networkd</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      or configured by external software via <function>SetLinkDNS()</function> or
+      <function>SetLinkDNSEx()</function> (see above). The network interface index will be 0 for the
+      system-wide configured services and non-zero for the per-link servers.</para>
+
+      <para><varname>FallbackDNS</varname> and <varname>FallbackDNSEx</varname> contain arrays of all DNS
+      servers configured as fallback servers, if any, using the same format as <varname>DNS</varname> and
+      <varname>DNSEx</varname> described above. See the description of <varname>FallbackDNS=</varname> in
+      <citerefentry><refentrytitle>resolved.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
+      the description of when those servers are used.</para>
+
+      <para><varname>CurrentDNSServer</varname> and <varname>CurrentDNSServerEx</varname> specify the server
+      that is currently used for query resolution, in the same format as a single entry in the
+      <varname>DNS</varname> and <varname>DNSEx</varname> arrays described above.</para>
+
+      <para>Similarly, the <varname>Domains</varname> property contains an array of all search and routing
+      domains currently used by <filename>systemd-resolved</filename>. Each entry consists of a network
+      interface index (again, 0 encodes system-wide entries), the actual domain name, and whether the entry
+      is used only for routing (true) or for both routing and searching (false).</para>
+
+      <para>The <varname>TransactionStatistics</varname> property contains information about the number of
+      transactions <filename>systemd-resolved</filename> has processed. It contains a pair of unsigned 64-bit counters, the first
+      containing the number of currently ongoing transactions, the second the number of total transactions
+      <filename>systemd-resolved</filename> is processing or has processed. The latter value may be reset using the
+      <function>ResetStatistics()</function> method described above. Note that the number of transactions does
+      not directly map to the number of issued resolver bus method calls. While simple look-ups usually require a
+      single transaction only, more complex look-ups might result in more, for example when CNAMEs or DNSSEC
+      are in use.</para>
+
+      <para>The <varname>CacheStatistics</varname> property contains information about the executed cache
+      operations so far. It exposes three 64-bit counters: the first being the total number of current cache
+      entries (both positive and negative), the second the number of cache hits, and the third the number of
+      cache misses. The latter counters may be reset using <function>ResetStatistics()</function> (see
+      above).</para>
+
+      <para>The <varname>DNSSEC</varname> property specifies current status of DNSSEC validation. It is one
+      of <literal>yes</literal> (validation is enforced), <literal>no</literal> (no validation is done),
+      <literal>allow-downgrade</literal> (validation is done if the current DNS server supports it). See the
+      description of <varname>DNSSEC=</varname> in
+      <citerefentry><refentrytitle>resolved.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+      </para>
+
+      <para>The <varname>DNSSECStatistics</varname> property contains information about the DNSSEC
+      validations executed so far. It contains four 64-bit counters: the number of secure, insecure, bogus,
+      and indeterminate DNSSEC validations so far. The counters are increased for each validated RRset, and
+      each non-existence proof. The secure counter is increased for each operation that successfully verified
+      a signed reply, the insecure counter is increased for each operation that successfully verified that an
+      unsigned reply is rightfully unsigned. The bogus counter is increased for each operation where the
+      validation did not check out and the data is likely to have been tempered with. Finally the
+      indeterminate counter is increased for each operation which did not complete because the necessary keys
+      could not be acquired or the cryptographic algorithms were unknown.</para>
+
+      <para>The <varname>DNSSECSupported</varname> boolean property reports whether DNSSEC is enabled and
+      the selected DNS servers support it. It combines information about system-wide and per-link DNS
+      settings (see below), and only reports true if DNSSEC is enabled and supported on every interface for
+      which DNS is configured and for the system-wide settings if there are any. Note that <filename>systemd-resolved</filename> assumes
+      DNSSEC is supported by DNS servers until it verifies that this is not the case. Thus, the reported
+      value may initially be true, until the first transactions are executed.</para>
+
+      <para>The <varname>DNSOverTLS</varname> boolean property reports whether DNS-over-TLS is enabled.
+      </para>
+
+      <para>The <varname>ResolvConfMode</varname> property exposes how <filename>/etc/resolv.conf</filename>
+      is managed on the host. Currently, the values <literal>uplink</literal>, <literal>stub</literal>,
+      <literal>static</literal> (these three correspond to the three different files
+      <filename>systemd-resolved.service</filename> provides), <literal>foreign</literal> (the file is
+      managed by admin or another service, <filename>systemd-resolved.service</filename> just consumes it),
+      <literal>missing</literal> (<filename>/etc/resolv.conf</filename> is missing).</para>
+
+      <para>The <varname>DNSStubListener</varname> property reports whether the stub listener on port 53 is
+      enabled. Possible values are <literal>yes</literal> (enabled), <literal>no</literal> (disabled),
+      <literal>udp</literal> (only the UDP listener is enabled), and <literal>tcp</literal> (only the TCP
+      listener is enabled).</para>
+    </refsect2>
+  </refsect1>
+
+  <refsect1>
+    <title>Link Object</title>
+
+    <programlisting executable="systemd-resolved" node="/org/freedesktop/resolve1/link/_1" interface="org.freedesktop.resolve1.Link">
+node /org/freedesktop/resolve1/link/_1 {
+  interface org.freedesktop.resolve1.Link {
+    methods:
+      SetDNS(in  a(iay) addresses);
+      SetDNSEx(in  a(iayqs) addresses);
+      SetDomains(in  a(sb) domains);
+      SetDefaultRoute(in  b enable);
+      SetLLMNR(in  s mode);
+      SetMulticastDNS(in  s mode);
+      SetDNSOverTLS(in  s mode);
+      SetDNSSEC(in  s mode);
+      SetDNSSECNegativeTrustAnchors(in  as names);
+      Revert();
+    properties:
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t ScopesMask = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(iay) DNS = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(iayqs) DNSEx = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly (iay) CurrentDNSServer = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly (iayqs) CurrentDNSServerEx = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(sb) Domains = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly b DefaultRoute = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s LLMNR = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s MulticastDNS = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s DNSOverTLS = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s DNSSEC = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly as DNSSECNegativeTrustAnchors = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly b DNSSECSupported = ...;
+  };
+  interface org.freedesktop.DBus.Peer { ... };
+  interface org.freedesktop.DBus.Introspectable { ... };
+  interface org.freedesktop.DBus.Properties { ... };
+};
+    </programlisting>
+
+    <!--property DNSSECNegativeTrustAnchors is not documented!-->
+
+    <!--Autogenerated cross-references for systemd.directives, do not edit-->
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.resolve1.Link"/>
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.resolve1.Link"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SetDNS()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SetDNSEx()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SetDomains()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SetDefaultRoute()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SetLLMNR()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SetMulticastDNS()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SetDNSOverTLS()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SetDNSSEC()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SetDNSSECNegativeTrustAnchors()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="Revert()"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ScopesMask"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DNS"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DNSEx"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CurrentDNSServer"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CurrentDNSServerEx"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Domains"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DefaultRoute"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LLMNR"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MulticastDNS"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DNSOverTLS"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DNSSEC"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DNSSECNegativeTrustAnchors"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DNSSECSupported"/>
+
+    <!--End of Autogenerated section-->
+
+    <para>For each Linux network interface a "Link" object is created which exposes per-link DNS
+    configuration and state. Use <function>GetLink()</function> on the Manager interface to retrieve the
+    object path for a link object given the network interface index (see above).</para>
+
+    <refsect2>
+      <title>Methods</title>
+
+      <para>The various methods exposed by the Link interface are equivalent to their similarly named
+      counterparts on the Manager interface. e.g. <function>SetDNS()</function> on the Link object maps to
+      <function>SetLinkDNS()</function> on the Manager object, the main difference being that the later
+      expects an interface index to be specified. Invoking the methods on the Manager interface has the
+      benefit of reducing roundtrips, as it is not necessary to first request the Link object path via
+      <function>GetLink()</function> before invoking the methods. The same relationship holds for
+      <function>SetDNSEx()</function>, <function>SetDomains()</function>,
+      <function>SetDefaultRoute()</function>, <function>SetLLMNR()</function>,
+      <function>SetMulticastDNS()</function>, <function>SetDNSOverTLS()</function>,
+      <function>SetDNSSEC()</function>, <function>SetDNSSECNegativeTrustAnchors()</function>, and
+      <function>Revert()</function>. For further details on these methods see the
+      <interfacename>Manager</interfacename> documentation above.</para>
+    </refsect2>
+
+    <refsect2>
+      <title>Properties</title>
+
+      <para><varname>ScopesMask</varname> defines which resolver scopes are currently active on this
+      interface. This 64-bit unsigned integer field is a bit mask consisting of a subset of the bits of the
+      flags parameter describe above. Specifically, it may have the DNS, LLMNR and MDNS bits (the latter in
+      IPv4 and IPv6 flavours) set. Each individual bit is set when the protocol applies to a specific
+      interface and is enabled for it. It is unset otherwise. Specifically, a multicast-capable interface in
+      the "UP" state with an IP address is suitable for LLMNR or MulticastDNS, and any interface that is UP and
+      has an IP address is suitable for DNS. Note the relationship of the bits exposed here with the LLMNR
+      and MulticastDNS properties also exposed on the Link interface. The latter expose what is *configured*
+      to be used on the interface, the former expose what is actually used on the interface, taking into
+      account the abilities of the interface.</para>
+
+      <para><varname>DNSSECSupported</varname> exposes a boolean field that indicates whether DNSSEC is
+      currently configured and in use on the interface. Note that if DNSSEC is enabled on an interface, it is
+      assumed available until it is detected that the configured server does not actually support it. Thus,
+      this property may initially report that DNSSEC is supported on an interface.</para>
+
+      <para><varname>DefaultRoute</varname> exposes a boolean field that indicates whether the interface will
+      be used as default route for name queries. See <function>SetLinkDefaultRoute()</function> above.</para>
+
+      <para>The other properties reflect the state of the various configuration settings for the link which
+      may be set with the various methods calls such as <function>SetDNS()</function> or
+      <function>SetLLMNR()</function>.</para>
+    </refsect2>
+  </refsect1>
+
+  <refsect1>
+    <title>Common Errors</title>
+
+    <para>Many bus methods <filename>systemd-resolved</filename> exposes (in particular the resolver methods such
+    as <function>ResolveHostname()</function> on the <interfacename>Manager</interfacename> interface) may return
+    some of the following errors:</para>
+
+    <variablelist>
+      <varlistentry><term><constant>org.freedesktop.resolve1.NoNameServers</constant></term>
+      <listitem><para>No suitable DNS servers were found to resolve a request.</para>
+
+      <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+      </varlistentry>
+
+      <varlistentry><term><constant>org.freedesktop.resolve1.InvalidReply</constant></term>
+      <listitem><para>A response from the selected DNS server was not understood.</para>
+
+      <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+      </varlistentry>
+
+      <varlistentry><term><constant>org.freedesktop.resolve1.NoSuchRR</constant></term>
+      <listitem><para>The requested name exists, but there is no resource record of the requested type for
+      it. (This is the DNS NODATA case).</para>
+
+      <xi:include href="version-info.xml" xpointer="v246"/></listitem></varlistentry>
+
+      <varlistentry><term><constant>org.freedesktop.resolve1.CNameLoop</constant></term>
+      <listitem><para>The look-up failed because a CNAME or DNAME loop was detected.</para>
+
+      <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+      </varlistentry>
+
+      <varlistentry><term><constant>org.freedesktop.resolve1.Aborted</constant></term>
+      <listitem><para>The look-up was aborted because the selected protocol became unavailable while the
+      operation was ongoing.</para>
+
+      <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+      </varlistentry>
+
+      <varlistentry><term><constant>org.freedesktop.resolve1.NoSuchService</constant></term>
+      <listitem><para>A service look-up was successful, but the <constant class="dns">SRV</constant> record
+      reported that the service is not available.</para>
+
+      <xi:include href="version-info.xml" xpointer="v246"/></listitem></varlistentry>
+
+      <varlistentry><term><constant>org.freedesktop.resolve1.DnssecFailed</constant></term>
+      <listitem><para>The acquired response did not pass DNSSEC validation.</para>
+
+      <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+      </varlistentry>
+
+      <varlistentry><term><constant>org.freedesktop.resolve1.NoTrustAnchor</constant></term>
+      <listitem><para>No chain of trust could be established for the response to a configured DNSSEC trust
+      anchor.</para>
+
+      <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+      </varlistentry>
+
+      <varlistentry><term><constant>org.freedesktop.resolve1.ResourceRecordTypeUnsupported</constant></term>
+      <listitem><para>The requested resource record type is not supported on the selected DNS servers. This
+      error is generated for example when an RRSIG record is requested from a DNS server that does not
+      support DNSSEC.</para>
+
+      <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+
+      </varlistentry>
+
+      <varlistentry><term><constant>org.freedesktop.resolve1.NoSuchLink</constant></term>
+      <listitem><para>No network interface with the specified network interface index exists.
+      </para>
+
+      <xi:include href="version-info.xml" xpointer="v246"/></listitem></varlistentry>
+
+      <varlistentry><term><constant>org.freedesktop.resolve1.LinkBusy</constant></term>
+      <listitem><para>The requested configuration change could not be made because
+      <citerefentry><refentrytitle>systemd-networkd</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      already took possession of the interface and supplied configuration data for it.</para>
+
+      <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+      </varlistentry>
+
+      <varlistentry><term><constant>org.freedesktop.resolve1.NetworkDown</constant></term>
+      <listitem><para>The requested look-up failed because the system is currently not connected to any
+      suitable network.</para>
+
+      <xi:include href="version-info.xml" xpointer="v246"/></listitem></varlistentry>
+
+      <varlistentry><term><constant>org.freedesktop.resolve1.DnsError.NXDOMAIN</constant></term>
+      <term><constant>org.freedesktop.resolve1.DnsError.REFUSED</constant></term>
+      <term>...</term>
+      <listitem><para>The look-up failed with a DNS return code reporting a failure. The error names used as
+      suffixes here are defined in by IANA in
+      <ulink url="https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6">DNS RCODEs</ulink>.
+      </para>
+
+      <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Examples</title>
+
+    <example>
+      <title>Introspect <interfacename>org.freedesktop.resolve1.Manager</interfacename> on the bus</title>
+
+      <programlisting>
+$ gdbus introspect --system \
+  --dest org.freedesktop.resolve1 \
+  --object-path /org/freedesktop/resolve1
+      </programlisting>
+    </example>
+
+    <example>
+      <title>Introspect <interfacename>org.freedesktop.resolve1.Link</interfacename> on the bus</title>
+
+      <programlisting>
+$ gdbus introspect --system \
+  --dest org.freedesktop.resolve1 \
+  --object-path /org/freedesktop/resolve1/link/_11
+      </programlisting>
+    </example>
+  </refsect1>
+
+  <xi:include href="org.freedesktop.locale1.xml" xpointer="versioning"/>
+</refentry>
diff --git a/man/org.freedesktop.systemd1.xml b/man/org.freedesktop.systemd1.xml
new file mode 100644
index 0000000..6008ba0
--- /dev/null
+++ b/man/org.freedesktop.systemd1.xml
@@ -0,0 +1,12011 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" >
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="org.freedesktop.systemd1" xmlns:xi="http://www.w3.org/2001/XInclude">
+  <refentryinfo>
+    <title>org.freedesktop.systemd1</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>org.freedesktop.systemd1</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>org.freedesktop.systemd1</refname>
+    <refpurpose>The D-Bus interface of systemd</refpurpose>
+  </refnamediv>
+
+  <refsect1>
+    <title>Introduction</title>
+
+    <para>
+    <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> and its
+    auxiliary daemons expose a number of APIs over D-Bus. This page only describes the various APIs exposed by the
+    system and service manager itself. It does not cover the auxiliary daemons.
+    </para>
+
+    <para>The service manager exposes a number of objects on the bus: one
+    <interfacename>Manager</interfacename> object as a central entry point for clients along with individual objects
+    for each unit and for each queued job. The unit objects implement a generic
+    <interfacename>Unit</interfacename> interface as well as a type-specific interface. For example, service units
+    implement both <interfacename>org.freedesktop.systemd1.Unit</interfacename> and
+    <interfacename>org.freedesktop.system1.Service</interfacename>. The manager object can list
+    unit and job objects or directly convert a unit name or job identifier to a bus path of the corresponding
+    D-Bus object.</para>
+
+    <para>Properties exposing time values are usually encoded in microseconds (μs) on the bus, even if
+    their corresponding settings in the unit files are in seconds.</para>
+
+    <para>PID 1 uses <ulink url="https://www.freedesktop.org/software/polkit/docs/latest/">polkit</ulink> to
+    allow access to privileged operations for unprivileged processes. Some operations (such as
+    shutdown/reboot/suspend) are also available through the D-Bus API of logind, see
+    <citerefentry><refentrytitle>org.freedesktop.login1</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+    </para>
+  </refsect1>
+
+  <refsect1>
+    <title>The Manager Object</title>
+
+    <para>The main entry point object is available on the fixed
+    <constant>/org/freedesktop/systemd1</constant> object path:</para>
+
+    <programlisting executable="systemd" node="/org/freedesktop/systemd1" interface="org.freedesktop.systemd1.Manager">
+node /org/freedesktop/systemd1 {
+  interface org.freedesktop.systemd1.Manager {
+    methods:
+      GetUnit(in  s name,
+              out o unit);
+      GetUnitByPID(in  u pid,
+                   out o unit);
+      GetUnitByInvocationID(in  ay invocation_id,
+                            out o unit);
+      GetUnitByControlGroup(in  s cgroup,
+                            out o unit);
+      GetUnitByPIDFD(in  h pidfd,
+                     out o unit,
+                     out s unit_id,
+                     out ay invocation_id);
+      LoadUnit(in  s name,
+               out o unit);
+      StartUnit(in  s name,
+                in  s mode,
+                out o job);
+      StartUnitWithFlags(in  s name,
+                         in  s mode,
+                         in  t flags,
+                         out o job);
+      StartUnitReplace(in  s old_unit,
+                       in  s new_unit,
+                       in  s mode,
+                       out o job);
+      StopUnit(in  s name,
+               in  s mode,
+               out o job);
+      ReloadUnit(in  s name,
+                 in  s mode,
+                 out o job);
+      RestartUnit(in  s name,
+                  in  s mode,
+                  out o job);
+      TryRestartUnit(in  s name,
+                     in  s mode,
+                     out o job);
+      ReloadOrRestartUnit(in  s name,
+                          in  s mode,
+                          out o job);
+      ReloadOrTryRestartUnit(in  s name,
+                             in  s mode,
+                             out o job);
+      EnqueueUnitJob(in  s name,
+                     in  s job_type,
+                     in  s job_mode,
+                     out u job_id,
+                     out o job_path,
+                     out s unit_id,
+                     out o unit_path,
+                     out s job_type,
+                     out a(uosos) affected_jobs);
+      KillUnit(in  s name,
+               in  s whom,
+               in  i signal);
+      QueueSignalUnit(in  s name,
+                      in  s whom,
+                      in  i signal,
+                      in  i value);
+      CleanUnit(in  s name,
+                in  as mask);
+      FreezeUnit(in  s name);
+      ThawUnit(in  s name);
+      ResetFailedUnit(in  s name);
+      SetUnitProperties(in  s name,
+                        in  b runtime,
+                        in  a(sv) properties);
+      BindMountUnit(in  s name,
+                    in  s source,
+                    in  s destination,
+                    in  b read_only,
+                    in  b mkdir);
+      MountImageUnit(in  s name,
+                     in  s source,
+                     in  s destination,
+                     in  b read_only,
+                     in  b mkdir,
+                     in  a(ss) options);
+      RefUnit(in  s name);
+      UnrefUnit(in  s name);
+      StartTransientUnit(in  s name,
+                         in  s mode,
+                         in  a(sv) properties,
+                         in  a(sa(sv)) aux,
+                         out o job);
+      GetUnitProcesses(in  s name,
+                       out a(sus) processes);
+      AttachProcessesToUnit(in  s unit_name,
+                            in  s subcgroup,
+                            in  au pids);
+      AbandonScope(in  s name);
+      GetJob(in  u id,
+             out o job);
+      GetJobAfter(in  u id,
+                  out a(usssoo) jobs);
+      GetJobBefore(in  u id,
+                   out a(usssoo) jobs);
+      CancelJob(in  u id);
+      ClearJobs();
+      ResetFailed();
+      SetShowStatus(in  s mode);
+      ListUnits(out a(ssssssouso) units);
+      ListUnitsFiltered(in  as states,
+                        out a(ssssssouso) units);
+      ListUnitsByPatterns(in  as states,
+                          in  as patterns,
+                          out a(ssssssouso) units);
+      ListUnitsByNames(in  as names,
+                       out a(ssssssouso) units);
+      ListJobs(out a(usssoo) jobs);
+      Subscribe();
+      Unsubscribe();
+      Dump(out s output);
+      DumpUnitsMatchingPatterns(in  as patterns,
+                                out s output);
+      DumpByFileDescriptor(out h fd);
+      DumpUnitsMatchingPatternsByFileDescriptor(in  as patterns,
+                                                out h fd);
+      Reload();
+      @org.freedesktop.DBus.Method.NoReply("true")
+      Reexecute();
+      @org.freedesktop.systemd1.Privileged("true")
+      Exit();
+      @org.freedesktop.systemd1.Privileged("true")
+      Reboot();
+      @org.freedesktop.systemd1.Privileged("true")
+      SoftReboot(in  s new_root);
+      @org.freedesktop.systemd1.Privileged("true")
+      PowerOff();
+      @org.freedesktop.systemd1.Privileged("true")
+      Halt();
+      @org.freedesktop.systemd1.Privileged("true")
+      KExec();
+      @org.freedesktop.systemd1.Privileged("true")
+      SwitchRoot(in  s new_root,
+                 in  s init);
+      SetEnvironment(in  as assignments);
+      UnsetEnvironment(in  as names);
+      UnsetAndSetEnvironment(in  as names,
+                             in  as assignments);
+      EnqueueMarkedJobs(out ao jobs);
+      ListUnitFiles(out a(ss) unit_files);
+      ListUnitFilesByPatterns(in  as states,
+                              in  as patterns,
+                              out a(ss) unit_files);
+      GetUnitFileState(in  s file,
+                       out s state);
+      EnableUnitFiles(in  as files,
+                      in  b runtime,
+                      in  b force,
+                      out b carries_install_info,
+                      out a(sss) changes);
+      DisableUnitFiles(in  as files,
+                       in  b runtime,
+                       out a(sss) changes);
+      EnableUnitFilesWithFlags(in  as files,
+                               in  t flags,
+                               out b carries_install_info,
+                               out a(sss) changes);
+      DisableUnitFilesWithFlags(in  as files,
+                                in  t flags,
+                                out a(sss) changes);
+      DisableUnitFilesWithFlagsAndInstallInfo(in  as files,
+                                              in  t flags,
+                                              out b carries_install_info,
+                                              out a(sss) changes);
+      ReenableUnitFiles(in  as files,
+                        in  b runtime,
+                        in  b force,
+                        out b carries_install_info,
+                        out a(sss) changes);
+      LinkUnitFiles(in  as files,
+                    in  b runtime,
+                    in  b force,
+                    out a(sss) changes);
+      PresetUnitFiles(in  as files,
+                      in  b runtime,
+                      in  b force,
+                      out b carries_install_info,
+                      out a(sss) changes);
+      PresetUnitFilesWithMode(in  as files,
+                              in  s mode,
+                              in  b runtime,
+                              in  b force,
+                              out b carries_install_info,
+                              out a(sss) changes);
+      MaskUnitFiles(in  as files,
+                    in  b runtime,
+                    in  b force,
+                    out a(sss) changes);
+      UnmaskUnitFiles(in  as files,
+                      in  b runtime,
+                      out a(sss) changes);
+      RevertUnitFiles(in  as files,
+                      out a(sss) changes);
+      SetDefaultTarget(in  s name,
+                       in  b force,
+                       out a(sss) changes);
+      GetDefaultTarget(out s name);
+      PresetAllUnitFiles(in  s mode,
+                         in  b runtime,
+                         in  b force,
+                         out a(sss) changes);
+      AddDependencyUnitFiles(in  as files,
+                             in  s target,
+                             in  s type,
+                             in  b runtime,
+                             in  b force,
+                             out a(sss) changes);
+      GetUnitFileLinks(in  s name,
+                       in  b runtime,
+                       out as links);
+      SetExitCode(in  y number);
+      LookupDynamicUserByName(in  s name,
+                              out u uid);
+      LookupDynamicUserByUID(in  u uid,
+                             out s name);
+      GetDynamicUsers(out a(us) users);
+      DumpUnitFileDescriptorStore(in  s name,
+                                  out a(suuutuusu) entries);
+    signals:
+      UnitNew(s id,
+              o unit);
+      UnitRemoved(s id,
+                  o unit);
+      JobNew(u id,
+             o job,
+             s unit);
+      JobRemoved(u id,
+                 o job,
+                 s unit,
+                 s result);
+      StartupFinished(t firmware,
+                      t loader,
+                      t kernel,
+                      t initrd,
+                      t userspace,
+                      t total);
+      UnitFilesChanged();
+      Reloading(b active);
+    properties:
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s Version = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s Features = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s Virtualization = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s ConfidentialVirtualization = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s Architecture = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s Tainted = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t FirmwareTimestamp = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t FirmwareTimestampMonotonic = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LoaderTimestamp = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LoaderTimestampMonotonic = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t KernelTimestamp = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t KernelTimestampMonotonic = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t InitRDTimestamp = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t InitRDTimestampMonotonic = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t UserspaceTimestamp = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t UserspaceTimestampMonotonic = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t FinishTimestamp = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t FinishTimestampMonotonic = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t SecurityStartTimestamp = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t SecurityStartTimestampMonotonic = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t SecurityFinishTimestamp = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t SecurityFinishTimestampMonotonic = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t GeneratorsStartTimestamp = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t GeneratorsStartTimestampMonotonic = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t GeneratorsFinishTimestamp = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t GeneratorsFinishTimestampMonotonic = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t UnitsLoadStartTimestamp = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t UnitsLoadStartTimestampMonotonic = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t UnitsLoadFinishTimestamp = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t UnitsLoadFinishTimestampMonotonic = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t UnitsLoadTimestamp = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t UnitsLoadTimestampMonotonic = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t InitRDSecurityStartTimestamp = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t InitRDSecurityStartTimestampMonotonic = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t InitRDSecurityFinishTimestamp = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t InitRDSecurityFinishTimestampMonotonic = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t InitRDGeneratorsStartTimestamp = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t InitRDGeneratorsStartTimestampMonotonic = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t InitRDGeneratorsFinishTimestamp = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t InitRDGeneratorsFinishTimestampMonotonic = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t InitRDUnitsLoadStartTimestamp = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t InitRDUnitsLoadStartTimestampMonotonic = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t InitRDUnitsLoadFinishTimestamp = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t InitRDUnitsLoadFinishTimestampMonotonic = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      @org.freedesktop.systemd1.Privileged("true")
+      readwrite s LogLevel = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      @org.freedesktop.systemd1.Privileged("true")
+      readwrite s LogTarget = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly u NNames = ...;
+      readonly u NFailedUnits = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly u NJobs = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly u NInstalledJobs = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly u NFailedJobs = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly d Progress = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly as Environment = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b ConfirmSpawn = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly b ShowStatus = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as UnitPath = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s DefaultStandardOutput = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s DefaultStandardError = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s WatchdogDevice = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t WatchdogLastPingTimestamp = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t WatchdogLastPingTimestampMonotonic = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      @org.freedesktop.systemd1.Privileged("true")
+      readwrite t RuntimeWatchdogUSec = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      @org.freedesktop.systemd1.Privileged("true")
+      readwrite t RuntimeWatchdogPreUSec = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      @org.freedesktop.systemd1.Privileged("true")
+      readwrite s RuntimeWatchdogPreGovernor = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      @org.freedesktop.systemd1.Privileged("true")
+      readwrite t RebootWatchdogUSec = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      @org.freedesktop.systemd1.Privileged("true")
+      readwrite t KExecWatchdogUSec = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      @org.freedesktop.systemd1.Privileged("true")
+      readwrite b ServiceWatchdogs = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s ControlGroup = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s SystemState = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly y ExitCode = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t DefaultTimerAccuracyUSec = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t DefaultTimeoutStartUSec = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t DefaultTimeoutStopUSec = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t DefaultTimeoutAbortUSec = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t DefaultDeviceTimeoutUSec = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t DefaultRestartUSec = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t DefaultStartLimitIntervalUSec = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly u DefaultStartLimitBurst = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b DefaultCPUAccounting = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b DefaultBlockIOAccounting = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b DefaultIOAccounting = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b DefaultIPAccounting = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b DefaultMemoryAccounting = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b DefaultTasksAccounting = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t DefaultLimitCPU = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t DefaultLimitCPUSoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t DefaultLimitFSIZE = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t DefaultLimitFSIZESoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t DefaultLimitDATA = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t DefaultLimitDATASoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t DefaultLimitSTACK = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t DefaultLimitSTACKSoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t DefaultLimitCORE = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t DefaultLimitCORESoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t DefaultLimitRSS = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t DefaultLimitRSSSoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t DefaultLimitNOFILE = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t DefaultLimitNOFILESoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t DefaultLimitAS = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t DefaultLimitASSoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t DefaultLimitNPROC = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t DefaultLimitNPROCSoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t DefaultLimitMEMLOCK = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t DefaultLimitMEMLOCKSoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t DefaultLimitLOCKS = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t DefaultLimitLOCKSSoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t DefaultLimitSIGPENDING = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t DefaultLimitSIGPENDINGSoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t DefaultLimitMSGQUEUE = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t DefaultLimitMSGQUEUESoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t DefaultLimitNICE = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t DefaultLimitNICESoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t DefaultLimitRTPRIO = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t DefaultLimitRTPRIOSoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t DefaultLimitRTTIME = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t DefaultLimitRTTIMESoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t DefaultTasksMax = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t DefaultMemoryPressureThresholdUSec = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s DefaultMemoryPressureWatch = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t TimerSlackNSec = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s DefaultOOMPolicy = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i DefaultOOMScoreAdjust = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s CtrlAltDelBurstAction = '...';
+  };
+  interface org.freedesktop.DBus.Peer { ... };
+  interface org.freedesktop.DBus.Introspectable { ... };
+  interface org.freedesktop.DBus.Properties { ... };
+};
+    </programlisting>
+
+    <!--method GetUnitByInvocationID is not documented!-->
+
+    <!--method GetUnitByControlGroup is not documented!-->
+
+    <!--method EnqueueUnitJob is not documented!-->
+
+    <!--method CleanUnit is not documented!-->
+
+    <!--method FreezeUnit is not documented!-->
+
+    <!--method ThawUnit is not documented!-->
+
+    <!--method RefUnit is not documented!-->
+
+    <!--method UnrefUnit is not documented!-->
+
+    <!--method GetUnitProcesses is not documented!-->
+
+    <!--method AttachProcessesToUnit is not documented!-->
+
+    <!--method AbandonScope is not documented!-->
+
+    <!--method GetJobAfter is not documented!-->
+
+    <!--method GetJobBefore is not documented!-->
+
+    <!--method SetShowStatus is not documented!-->
+
+    <!--method ListUnitsFiltered is not documented!-->
+
+    <!--method ListUnitsByPatterns is not documented!-->
+
+    <!--method ListUnitsByNames is not documented!-->
+
+    <!--method ListUnitFilesByPatterns is not documented!-->
+
+    <!--method PresetUnitFilesWithMode is not documented!-->
+
+    <!--method RevertUnitFiles is not documented!-->
+
+    <!--method PresetAllUnitFiles is not documented!-->
+
+    <!--method AddDependencyUnitFiles is not documented!-->
+
+    <!--method GetUnitFileLinks is not documented!-->
+
+    <!--method SetExitCode is not documented!-->
+
+    <!--method LookupDynamicUserByName is not documented!-->
+
+    <!--method LookupDynamicUserByUID is not documented!-->
+
+    <!--method GetDynamicUsers is not documented!-->
+
+    <!--signal UnitNew is not documented!-->
+
+    <!--signal UnitRemoved is not documented!-->
+
+    <!--signal JobNew is not documented!-->
+
+    <!--signal JobRemoved is not documented!-->
+
+    <!--signal StartupFinished is not documented!-->
+
+    <!--signal UnitFilesChanged is not documented!-->
+
+    <!--signal Reloading is not documented!-->
+
+    <!--property SecurityStartTimestampMonotonic is not documented!-->
+
+    <!--property SecurityFinishTimestamp is not documented!-->
+
+    <!--property SecurityFinishTimestampMonotonic is not documented!-->
+
+    <!--property GeneratorsStartTimestampMonotonic is not documented!-->
+
+    <!--property GeneratorsFinishTimestamp is not documented!-->
+
+    <!--property GeneratorsFinishTimestampMonotonic is not documented!-->
+
+    <!--property UnitsLoadStartTimestamp is not documented!-->
+
+    <!--property UnitsLoadStartTimestampMonotonic is not documented!-->
+
+    <!--property UnitsLoadFinishTimestamp is not documented!-->
+
+    <!--property UnitsLoadFinishTimestampMonotonic is not documented!-->
+
+    <!--property InitRDSecurityStartTimestamp is not documented!-->
+
+    <!--property InitRDSecurityStartTimestampMonotonic is not documented!-->
+
+    <!--property InitRDSecurityFinishTimestamp is not documented!-->
+
+    <!--property InitRDSecurityFinishTimestampMonotonic is not documented!-->
+
+    <!--property InitRDGeneratorsStartTimestamp is not documented!-->
+
+    <!--property InitRDGeneratorsStartTimestampMonotonic is not documented!-->
+
+    <!--property InitRDGeneratorsFinishTimestamp is not documented!-->
+
+    <!--property InitRDGeneratorsFinishTimestampMonotonic is not documented!-->
+
+    <!--property InitRDUnitsLoadStartTimestamp is not documented!-->
+
+    <!--property InitRDUnitsLoadStartTimestampMonotonic is not documented!-->
+
+    <!--property InitRDUnitsLoadFinishTimestamp is not documented!-->
+
+    <!--property InitRDUnitsLoadFinishTimestampMonotonic is not documented!-->
+
+    <!--property LogLevel is not documented!-->
+
+    <!--property LogTarget is not documented!-->
+
+    <!--property NFailedUnits is not documented!-->
+
+    <!--property ConfirmSpawn is not documented!-->
+
+    <!--property ShowStatus is not documented!-->
+
+    <!--property DefaultStandardOutput is not documented!-->
+
+    <!--property DefaultStandardError is not documented!-->
+
+    <!--property WatchdogDevice is not documented!-->
+
+    <!--property WatchdogLastPingTimestamp is not documented!-->
+
+    <!--property WatchdogLastPingTimestampMonotonic is not documented!-->
+
+    <!--property RuntimeWatchdogUSec is not documented!-->
+
+    <!--property RuntimeWatchdogPreUSec is not documented!-->
+
+    <!--property RuntimeWatchdogPreGovernor is not documented!-->
+
+    <!--property RebootWatchdogUSec is not documented!-->
+
+    <!--property KExecWatchdogUSec is not documented!-->
+
+    <!--property ServiceWatchdogs is not documented!-->
+
+    <!--property ExitCode is not documented!-->
+
+    <!--property DefaultTimerAccuracyUSec is not documented!-->
+
+    <!--property DefaultTimeoutStartUSec is not documented!-->
+
+    <!--property DefaultTimeoutStopUSec is not documented!-->
+
+    <!--property DefaultTimeoutAbortUSec is not documented!-->
+
+    <!--property DefaultDeviceTimeoutUSec is not documented!-->
+
+    <!--property DefaultRestartUSec is not documented!-->
+
+    <!--property DefaultStartLimitIntervalUSec is not documented!-->
+
+    <!--property DefaultStartLimitBurst is not documented!-->
+
+    <!--property DefaultCPUAccounting is not documented!-->
+
+    <!--property DefaultBlockIOAccounting is not documented!-->
+
+    <!--property DefaultIOAccounting is not documented!-->
+
+    <!--property DefaultIPAccounting is not documented!-->
+
+    <!--property DefaultMemoryAccounting is not documented!-->
+
+    <!--property DefaultTasksAccounting is not documented!-->
+
+    <!--property DefaultLimitCPU is not documented!-->
+
+    <!--property DefaultLimitCPUSoft is not documented!-->
+
+    <!--property DefaultLimitFSIZE is not documented!-->
+
+    <!--property DefaultLimitFSIZESoft is not documented!-->
+
+    <!--property DefaultLimitDATA is not documented!-->
+
+    <!--property DefaultLimitDATASoft is not documented!-->
+
+    <!--property DefaultLimitSTACK is not documented!-->
+
+    <!--property DefaultLimitSTACKSoft is not documented!-->
+
+    <!--property DefaultLimitCORE is not documented!-->
+
+    <!--property DefaultLimitCORESoft is not documented!-->
+
+    <!--property DefaultLimitRSS is not documented!-->
+
+    <!--property DefaultLimitRSSSoft is not documented!-->
+
+    <!--property DefaultLimitNOFILE is not documented!-->
+
+    <!--property DefaultLimitNOFILESoft is not documented!-->
+
+    <!--property DefaultLimitAS is not documented!-->
+
+    <!--property DefaultLimitASSoft is not documented!-->
+
+    <!--property DefaultLimitNPROC is not documented!-->
+
+    <!--property DefaultLimitNPROCSoft is not documented!-->
+
+    <!--property DefaultLimitMEMLOCK is not documented!-->
+
+    <!--property DefaultLimitMEMLOCKSoft is not documented!-->
+
+    <!--property DefaultLimitLOCKS is not documented!-->
+
+    <!--property DefaultLimitLOCKSSoft is not documented!-->
+
+    <!--property DefaultLimitSIGPENDING is not documented!-->
+
+    <!--property DefaultLimitSIGPENDINGSoft is not documented!-->
+
+    <!--property DefaultLimitMSGQUEUE is not documented!-->
+
+    <!--property DefaultLimitMSGQUEUESoft is not documented!-->
+
+    <!--property DefaultLimitNICE is not documented!-->
+
+    <!--property DefaultLimitNICESoft is not documented!-->
+
+    <!--property DefaultLimitRTPRIO is not documented!-->
+
+    <!--property DefaultLimitRTPRIOSoft is not documented!-->
+
+    <!--property DefaultLimitRTTIME is not documented!-->
+
+    <!--property DefaultLimitRTTIMESoft is not documented!-->
+
+    <!--property DefaultTasksMax is not documented!-->
+
+    <!--property DefaultMemoryPressureThresholdUSec is not documented!-->
+
+    <!--property DefaultMemoryPressureWatch is not documented!-->
+
+    <!--property TimerSlackNSec is not documented!-->
+
+    <!--property DefaultOOMPolicy is not documented!-->
+
+    <!--property DefaultOOMScoreAdjust is not documented!-->
+
+    <!--property CtrlAltDelBurstAction is not documented!-->
+
+    <!--Autogenerated cross-references for systemd.directives, do not edit-->
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Manager"/>
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Manager"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="GetUnit()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="GetUnitByPID()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="GetUnitByInvocationID()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="GetUnitByControlGroup()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="GetUnitByPIDFD()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="LoadUnit()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="StartUnit()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="StartUnitWithFlags()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="StartUnitReplace()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="StopUnit()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="ReloadUnit()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="RestartUnit()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="TryRestartUnit()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="ReloadOrRestartUnit()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="ReloadOrTryRestartUnit()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="EnqueueUnitJob()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="KillUnit()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="QueueSignalUnit()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="CleanUnit()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="FreezeUnit()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="ThawUnit()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="ResetFailedUnit()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SetUnitProperties()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="BindMountUnit()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="MountImageUnit()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="RefUnit()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="UnrefUnit()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="StartTransientUnit()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="GetUnitProcesses()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="AttachProcessesToUnit()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="AbandonScope()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="GetJob()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="GetJobAfter()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="GetJobBefore()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="CancelJob()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="ClearJobs()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="ResetFailed()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SetShowStatus()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="ListUnits()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="ListUnitsFiltered()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="ListUnitsByPatterns()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="ListUnitsByNames()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="ListJobs()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="Subscribe()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="Unsubscribe()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="Dump()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="DumpUnitsMatchingPatterns()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="DumpByFileDescriptor()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="DumpUnitsMatchingPatternsByFileDescriptor()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="Reload()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="Reexecute()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="Exit()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="Reboot()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SoftReboot()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="PowerOff()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="Halt()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="KExec()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SwitchRoot()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SetEnvironment()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="UnsetEnvironment()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="UnsetAndSetEnvironment()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="EnqueueMarkedJobs()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="ListUnitFiles()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="ListUnitFilesByPatterns()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="GetUnitFileState()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="EnableUnitFiles()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="DisableUnitFiles()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="EnableUnitFilesWithFlags()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="DisableUnitFilesWithFlags()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="DisableUnitFilesWithFlagsAndInstallInfo()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="ReenableUnitFiles()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="LinkUnitFiles()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="PresetUnitFiles()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="PresetUnitFilesWithMode()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="MaskUnitFiles()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="UnmaskUnitFiles()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="RevertUnitFiles()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SetDefaultTarget()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="GetDefaultTarget()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="PresetAllUnitFiles()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="AddDependencyUnitFiles()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="GetUnitFileLinks()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SetExitCode()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="LookupDynamicUserByName()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="LookupDynamicUserByUID()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="GetDynamicUsers()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="DumpUnitFileDescriptorStore()"/>
+
+    <variablelist class="dbus-signal" generated="True" extra-ref="UnitNew"/>
+
+    <variablelist class="dbus-signal" generated="True" extra-ref="UnitRemoved"/>
+
+    <variablelist class="dbus-signal" generated="True" extra-ref="JobNew"/>
+
+    <variablelist class="dbus-signal" generated="True" extra-ref="JobRemoved"/>
+
+    <variablelist class="dbus-signal" generated="True" extra-ref="StartupFinished"/>
+
+    <variablelist class="dbus-signal" generated="True" extra-ref="UnitFilesChanged"/>
+
+    <variablelist class="dbus-signal" generated="True" extra-ref="Reloading"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Version"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Features"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Virtualization"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ConfidentialVirtualization"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Architecture"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Tainted"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="FirmwareTimestamp"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="FirmwareTimestampMonotonic"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LoaderTimestamp"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LoaderTimestampMonotonic"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="KernelTimestamp"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="KernelTimestampMonotonic"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="InitRDTimestamp"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="InitRDTimestampMonotonic"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="UserspaceTimestamp"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="UserspaceTimestampMonotonic"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="FinishTimestamp"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="FinishTimestampMonotonic"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SecurityStartTimestamp"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SecurityStartTimestampMonotonic"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SecurityFinishTimestamp"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SecurityFinishTimestampMonotonic"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="GeneratorsStartTimestamp"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="GeneratorsStartTimestampMonotonic"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="GeneratorsFinishTimestamp"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="GeneratorsFinishTimestampMonotonic"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="UnitsLoadStartTimestamp"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="UnitsLoadStartTimestampMonotonic"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="UnitsLoadFinishTimestamp"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="UnitsLoadFinishTimestampMonotonic"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="UnitsLoadTimestamp"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="UnitsLoadTimestampMonotonic"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="InitRDSecurityStartTimestamp"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="InitRDSecurityStartTimestampMonotonic"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="InitRDSecurityFinishTimestamp"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="InitRDSecurityFinishTimestampMonotonic"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="InitRDGeneratorsStartTimestamp"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="InitRDGeneratorsStartTimestampMonotonic"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="InitRDGeneratorsFinishTimestamp"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="InitRDGeneratorsFinishTimestampMonotonic"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="InitRDUnitsLoadStartTimestamp"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="InitRDUnitsLoadStartTimestampMonotonic"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="InitRDUnitsLoadFinishTimestamp"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="InitRDUnitsLoadFinishTimestampMonotonic"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LogLevel"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LogTarget"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="NNames"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="NFailedUnits"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="NJobs"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="NInstalledJobs"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="NFailedJobs"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Progress"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Environment"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ConfirmSpawn"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ShowStatus"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="UnitPath"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DefaultStandardOutput"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DefaultStandardError"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="WatchdogDevice"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="WatchdogLastPingTimestamp"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="WatchdogLastPingTimestampMonotonic"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RuntimeWatchdogUSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RuntimeWatchdogPreUSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RuntimeWatchdogPreGovernor"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RebootWatchdogUSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="KExecWatchdogUSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ServiceWatchdogs"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ControlGroup"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SystemState"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ExitCode"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DefaultTimerAccuracyUSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DefaultTimeoutStartUSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DefaultTimeoutStopUSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DefaultTimeoutAbortUSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DefaultDeviceTimeoutUSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DefaultRestartUSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DefaultStartLimitIntervalUSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DefaultStartLimitBurst"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DefaultCPUAccounting"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DefaultBlockIOAccounting"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DefaultIOAccounting"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DefaultIPAccounting"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DefaultMemoryAccounting"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DefaultTasksAccounting"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DefaultLimitCPU"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DefaultLimitCPUSoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DefaultLimitFSIZE"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DefaultLimitFSIZESoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DefaultLimitDATA"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DefaultLimitDATASoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DefaultLimitSTACK"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DefaultLimitSTACKSoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DefaultLimitCORE"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DefaultLimitCORESoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DefaultLimitRSS"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DefaultLimitRSSSoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DefaultLimitNOFILE"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DefaultLimitNOFILESoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DefaultLimitAS"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DefaultLimitASSoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DefaultLimitNPROC"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DefaultLimitNPROCSoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DefaultLimitMEMLOCK"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DefaultLimitMEMLOCKSoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DefaultLimitLOCKS"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DefaultLimitLOCKSSoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DefaultLimitSIGPENDING"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DefaultLimitSIGPENDINGSoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DefaultLimitMSGQUEUE"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DefaultLimitMSGQUEUESoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DefaultLimitNICE"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DefaultLimitNICESoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DefaultLimitRTPRIO"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DefaultLimitRTPRIOSoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DefaultLimitRTTIME"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DefaultLimitRTTIMESoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DefaultTasksMax"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DefaultMemoryPressureThresholdUSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DefaultMemoryPressureWatch"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TimerSlackNSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DefaultOOMPolicy"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DefaultOOMScoreAdjust"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CtrlAltDelBurstAction"/>
+
+    <!--End of Autogenerated section-->
+
+    <refsect2>
+      <title>Methods</title>
+
+      <para>Note that many of the methods exist twice: once on the <interfacename>Manager</interfacename>
+      object and once on the respective unit objects. This is to optimize access times so that methods that
+      belong to unit objects do not have to be called with a resolved unit path, but can be called with only
+      the unit id, too.</para>
+
+      <para><function>GetUnit()</function> may be used to get the unit object path for a unit name. It takes
+      the unit name and returns the object path. If a unit has not been loaded yet by this name this method
+      will fail.</para>
+
+      <para><function>GetUnitByPID()</function> may be used to get the unit object path of the unit a process
+      ID belongs to. It takes a UNIX PID and returns the object path. The PID must refer to an existing system process.
+      <function>GetUnitByPIDFD()</function> may be used to query with a Linux PIDFD (see:
+      <citerefentry><refentrytitle>pidfd_open</refentrytitle><manvolnum>2</manvolnum></citerefentry>) instead
+      of a PID, which is safer as UNIX PIDs can be recycled. The latter method returns the unit id and the
+      invocation id together with the unit object path.</para>
+
+      <para><function>LoadUnit()</function> is similar to <function>GetUnit()</function> but will load the
+      unit from disk if possible.</para>
+
+      <para><function>StartUnit()</function> enqueues a start job and possibly depending jobs. It takes the unit
+      to activate and a mode string as arguments. The mode needs to be one of <literal>replace</literal>,
+      <literal>fail</literal>, <literal>isolate</literal>, <literal>ignore-dependencies</literal>, or
+      <literal>ignore-requirements</literal>. If <literal>replace</literal>, the method will start the unit and
+      its dependencies, possibly replacing already queued jobs that conflict with it. If
+      <literal>fail</literal>, the method will start the unit and its dependencies, but will fail if this would
+      change an already queued job. If <literal>isolate</literal>, the method will start the unit in question
+      and terminate all units that aren't dependencies of it. If <literal>ignore-dependencies</literal>, it
+      will start a unit but ignore all its dependencies. If <literal>ignore-requirements</literal>, it will
+      start a unit but only ignore the requirement dependencies. It is not recommended to make use of the
+      latter two options. On reply, if successful, this method returns the newly created job object
+      which has been enqueued for asynchronous activation. Callers that want to track the outcome of the
+      actual start operation need to monitor the result of this job. This can be achieved in a race-free
+      manner by first subscribing to the <function>JobRemoved()</function> signal, then calling
+      <function>StartUnit()</function> and using the returned job object to filter out unrelated
+      <function>JobRemoved()</function> signals, until the desired one is received, which will then carry
+      the result of the start operation.</para>
+
+      <para><function>StartUnitReplace()</function> is similar to <function>StartUnit()</function> but
+      replaces a job that is queued for one unit by a job for another unit.</para>
+
+      <para><function>StartUnitWithFlags()</function> is similar to <function>StartUnit()</function> but
+      allows the caller to pass an extra <varname>flags</varname> parameter, which does not support any
+      flags for now, and is reserved for future extensions.</para>
+
+      <para><function>StopUnit()</function> is similar to <function>StartUnit()</function> but stops the
+      specified unit rather than starting it. Note that the <literal>isolate</literal> mode is invalid for this
+      method.</para>
+
+      <para><function>ReloadUnit()</function>, <function>RestartUnit()</function>,
+      <function>TryRestartUnit()</function>, <function>ReloadOrRestartUnit()</function>, or
+      <function>ReloadOrTryRestartUnit()</function> may be used to restart and/or reload a unit. These methods take
+      similar arguments as <function>StartUnit()</function>. Reloading is done only if the unit is already
+      running and fails otherwise. If a service is restarted that isn't running, it will be started unless
+      the "Try" flavor is used in which case a service that isn't running is not affected by the restart. The
+      "ReloadOrRestart" flavors attempt a reload if the unit supports it and use a restart otherwise.</para>
+
+      <para><function>EnqueueMarkedJobs()</function> creates reload/restart jobs for units which have been
+      appropriately marked, see <varname>Markers</varname> property above. This is equivalent to calling
+      <function>TryRestartUnit()</function> or <function>ReloadOrTryRestartUnit()</function> for the marked
+      units.</para>
+
+      <para><function>BindMountUnit()</function> can be used to bind mount new files or directories into a
+      running service mount namespace. If supported by the kernel, any prior mount on the selected target
+      will be replaced by the new mount. If not supported, any prior mount will be over-mounted, but remain
+      pinned and inaccessible.
+      </para>
+
+      <para><function>MountImageUnit()</function> can be used to mount new images into a running service
+      mount namespace. If supported by the kernel, any prior mount on the selected target will be replaced
+      by the new mount. If not supported, any prior mount will be over-mounted, but remain pinned and
+      inaccessible.</para>
+
+      <para><function>KillUnit()</function> may be used to kill (i.e. send a signal to) all processes of a
+      unit. It takes the unit <varname>name</varname>, an enum <varname>who</varname> and a UNIX
+      <varname>signal</varname> number to send. The <varname>who</varname> enum is one of
+      <literal>main</literal>, <literal>control</literal> or <literal>all</literal>. If
+      <literal>main</literal>, only the main process of the unit is killed. If <literal>control</literal>, only
+      the control process of the unit is killed. If <literal>all</literal>, all processes are killed. A
+      <literal>control</literal> process is for example a process that is configured via
+      <varname>ExecStop=</varname> and is spawned in parallel to the main daemon process in order to shut it
+      down.</para>
+
+      <para><function>QueueSignalUnit()</function> is similar to <function>KillUnit()</function> but may be
+      used to enqueue a POSIX Realtime Signal (i.e. <constant>SIGRTMIN+…</constant> and
+      <constant>SIGRTMAX-…</constant>) to the selected process(es). Takes the same parameters as
+      <function>KillUnit()</function> with one additional argument: an integer that is passed in the
+      <varname>sival_int</varname> value accompanying the queued signal. See
+      <citerefentry project="man-pages"><refentrytitle>sigqueue</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+      for details.</para>
+
+      <para><function>GetJob()</function> returns the job object path for a specific job, identified by its
+      id.</para>
+
+      <para><function>CancelJob()</function> cancels a specific job identified by its numeric ID. This
+      operation is also available in the <function>Cancel()</function> method of Job objects (see below) and
+      exists primarily to reduce the necessary round trips to execute this operation. Note that this will not
+      have any effect on jobs whose execution has already begun.</para>
+
+      <para><function>ClearJobs()</function> flushes the job queue, removing all jobs that are still
+      queued. Note that this does not have any effect on jobs whose execution has already begun. It only
+      flushes jobs that are queued and have not yet begun execution.</para>
+
+      <para><function>ResetFailedUnit()</function> resets the "failed" state of a specific unit.</para>
+
+      <para><function>ResetFailed()</function> resets the "failed" state of all units.</para>
+
+      <para><function>ListUnits()</function> returns an array of all currently loaded units. Note that
+      units may be known by multiple names at the same time, and hence there might be more unit names loaded
+      than actual units behind them. The array consists of structures with the following elements:
+      <itemizedlist>
+        <listitem><para>The primary unit name as string</para></listitem>
+
+        <listitem><para>The human readable description string</para></listitem>
+
+        <listitem><para>The load state (i.e. whether the unit file has been loaded
+        successfully)</para></listitem>
+
+        <listitem><para>The active state (i.e. whether the unit is currently started or
+        not)</para></listitem>
+
+        <listitem><para>The sub state (a more fine-grained version of the active state that is specific to
+        the unit type, which the active state is not)</para></listitem>
+
+        <listitem><para>A unit that is being followed in its state by this unit, if there is any, otherwise
+        the empty string.</para></listitem>
+
+        <listitem><para>The unit object path</para></listitem>
+
+        <listitem><para>If there is a job queued for the job unit, the numeric job id, 0
+        otherwise</para></listitem>
+
+        <listitem><para>The job type as string</para></listitem>
+
+        <listitem><para>The job object path</para></listitem>
+      </itemizedlist></para>
+
+      <para><function>ListJobs()</function> returns an array with all currently queued jobs. Returns an array
+      consisting of structures with the following elements:
+      <itemizedlist>
+        <listitem><para>The numeric job id</para></listitem>
+
+        <listitem><para>The primary unit name for this job</para></listitem>
+
+        <listitem><para>The job type as string</para></listitem>
+
+        <listitem><para>The job state as string</para></listitem>
+
+        <listitem><para>The job object path</para></listitem>
+
+        <listitem><para>The unit object path</para></listitem>
+      </itemizedlist></para>
+
+      <para><function>Subscribe()</function> enables most bus signals to be sent out. Clients which are
+      interested in signals need to call this method. Signals are only sent out if at least one client
+      invoked this method. <function>Unsubscribe()</function> reverts the signal subscription that
+      <function>Subscribe()</function> implements. It is not necessary to invoke
+      <function>Unsubscribe()</function> as clients are tracked. Signals are no longer sent out as soon as
+      all clients which previously asked for <function>Subscribe()</function> either closed their connection
+      to the bus or invoked <function>Unsubscribe()</function>.</para>
+
+      <para><function>Dump()</function> returns a text dump of the internal service manager state. This is a
+      privileged, low-level debugging interface only. The returned string is supposed to be readable
+      exclusively by developers, and not programmatically. There's no interface stability on the returned
+      string guaranteed, and new fields may be added any time, and old fields removed. The general structure
+      may be rearranged drastically between releases. This is exposed by
+      <citerefentry><refentrytitle>systemd-analyze</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s
+      <command>dump</command> command. Similarly, <function>DumpUnitsMatchingPatterns()</function> returns
+      the internal state of units whose names match the glob expressions specified in the
+      <varname>patterns</varname> argument. The
+      <function>DumpByFileDescriptor()</function>/<function>DumpUnitsMatchingPatternsByFileDescriptor()</function>
+      methods are identical to <function>Dump()</function>/<function>DumpUnitsMatchingPatterns()</function>,
+      but return data serialized into a file descriptor (the client should read the text data from it until
+      hitting EOF). Given the size limits on D-Bus messages and the possibly large size of the returned
+      strings,
+      <function>DumpByFileDescriptor()</function>/<function>DumpUnitsMatchingPatternsByFileDescriptor()</function>
+      are usually the preferred interface, since it ensures the data can be passed reliably from the service
+      manager to the client. Note though that they cannot work when communicating with the service manager
+      remotely, as file descriptors are strictly local to a system. All the <function>Dump*()</function>
+      methods are rate limited for unprivileged users.</para>
+
+      <para><function>Reload()</function> may be invoked to reload all unit files.</para>
+
+      <para><function>Reexecute()</function> may be invoked to reexecute the main manager process. It will
+      serialize its state, reexecute, and deserizalize the state again. This is useful for upgrades and is a
+      more comprehensive version of <function>Reload()</function>.</para>
+
+      <para><function>Exit()</function> may be invoked to ask the manager to exit. This is not available for
+      the system manager and is useful only for user session managers.</para>
+
+      <para><function>Reboot()</function>, <function>PowerOff()</function>, <function>Halt()</function>,
+      <function>KExec()</function> and <function>SoftReboot()</function> may be used to ask for immediate
+      reboot, powering down, halt, kexec based reboot, or soft reboot of the system. Note that this does not
+      shut down any services and immediately transitions into the later shutdown operation. These functions
+      are normally only called as the last step of shutdown and should not be called directly. To shut down
+      the machine, it is generally a better idea to invoke <function>Reboot()</function>,
+      <function>RebootWithFlags()</function> or <function>PowerOff()</function> on the
+      <filename>systemd-logind</filename> manager object; see
+      <citerefentry><refentrytitle>org.freedesktop.login1</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+      for more information. <function>SoftReboot()</function> accepts an argument indicating the path for the
+      root file system to activate for the next boot cycle. If an empty string is specified the
+      <filename>/run/nextroot/</filename> path is used if it exists.</para>
+
+      <para><function>SwitchRoot()</function> may be used to transition to a new root directory. This is
+      intended to be used in the initrd, and also to transition from the host system into a shutdown initrd.
+      The method takes two arguments: the new root directory (which needs to be specified) and an init binary
+      path (which may be left empty, in which case it is automatically searched for). The state of the system
+      manager will be serialized before the transition. After the transition, the manager binary on the main
+      system is invoked and replaces the old PID 1. All state will then be deserialized.</para>
+
+      <para><function>SetEnvironment()</function> may be used to alter the environment block that is passed
+      to all spawned processes. It takes a string array of environment variable assignments. Any previously set
+      environment variables will be overridden.</para>
+
+      <para><function>UnsetEnvironment()</function> may be used to unset environment variables. It takes a
+      string array of environment variable names. All variables specified will be unset (if they have been
+      set previously) and no longer be passed to all spawned processes. This method has no effect for variables
+      that were previously not set, but will not fail in that case.</para>
+
+      <para><function>UnsetAndSetEnvironment()</function> is a combination of
+      <function>UnsetEnvironment()</function> and <function>SetEnvironment()</function>. It takes two
+      lists. The first list contains variables to unset, the second one contains assignments to set. If a
+      variable is listed in both, the variable is set after this method returns, i.e. the set list overrides the
+      unset list.</para>
+
+      <para><function>ListUnitFiles()</function> returns an array of unit names and their enablement
+      status. Note that <function>ListUnit()</function> returns a list of units currently loaded into memory,
+      while <function>ListUnitFiles()</function> returns a list of unit <emphasis>files</emphasis> that were
+      found on disk. Note that while most units are read directly from a unit file with the same name, some
+      units are not backed by files and some files (templates) cannot directly be loaded as units but need
+      to be instantiated instead.</para>
+
+      <para><function>GetUnitFileState()</function> returns the current enablement status of a specific unit
+      file.</para>
+
+      <para><function>EnableUnitFiles()</function> may be used to enable one or more units in the system (by
+      creating symlinks to them in <filename>/etc/</filename> or <filename>/run/</filename>). It takes a list
+      of unit files to enable (either just file names or full absolute paths if the unit files are residing
+      outside the usual unit search paths) and two booleans: the first controls whether the unit shall be
+      enabled for runtime only (true, <filename>/run/</filename>), or persistently (false,
+      <filename>/etc/</filename>). The second one controls whether symlinks pointing to other units shall be
+      replaced if necessary. This method returns one boolean and an array of the changes made. The boolean
+      signals whether the unit files contained any enablement information (i.e. an [Install] section). The
+      changes array consists of structures with three strings: the type of the change (one of
+      <literal>symlink</literal> or <literal>unlink</literal>), the file name of the symlink and the
+      destination of the symlink. Note that most of the following calls return a changes list in the same
+      format.</para>
+
+      <para>Similarly, <function>DisableUnitFiles()</function> disables one or more units in the system,
+      i.e. removes all symlinks to them in <filename>/etc/</filename> and <filename>/run/</filename>.</para>
+
+      <para>The <function>EnableUnitFilesWithFlags()</function> and <function>DisableUnitFilesWithFlags()</function>
+      take in options as flags instead of booleans to allow for extendability, defined as follows:</para>
+
+      <programlisting>
+#define SD_SYSTEMD_UNIT_RUNTIME  (UINT64_C(1) &lt;&lt; 0)
+#define SD_SYSTEMD_UNIT_FORCE    (UINT64_C(1) &lt;&lt; 1)
+#define SD_SYSTEMD_UNIT_PORTABLE (UINT64_C(1) &lt;&lt; 2)
+      </programlisting>
+
+      <para><varname>SD_SYSTEMD_UNIT_RUNTIME</varname> will enable or disable the unit for runtime only,
+      <varname>SD_SYSTEMD_UNIT_FORCE</varname> controls whether symlinks pointing to other units shall be
+      replaced if necessary. <varname>SD_SYSTEMD_UNIT_PORTABLE</varname> will add or remove the symlinks in
+      <filename>/etc/systemd/system.attached</filename> and <filename>/run/systemd/system.attached</filename>.</para>
+
+      <para><function>DisableUnitFilesWithFlagsAndInstallInfo()</function> is similar to
+      <function>DisableUnitFilesWithFlags()</function> and takes the same arguments, but returns
+      a boolean to indicate whether the unit files contain any enablement information, like
+      <function>EnableUnitFiles()</function>. The changes made are still returned in an array.</para>
+
+      <para>Similarly, <function>ReenableUnitFiles()</function> applies the changes to one or more units that
+      would result from disabling and enabling the unit quickly one after the other in an atomic
+      fashion. This is useful to apply updated [Install] information contained in unit files.</para>
+
+      <para>Similarly, <function>LinkUnitFiles()</function> links unit files (that are located outside of the
+      usual unit search paths) into the unit search path.</para>
+
+      <para>Similarly, <function>PresetUnitFiles()</function> enables/disables one or more unit files
+      according to the preset policy. See
+      <citerefentry><refentrytitle>systemd.preset</refentrytitle><manvolnum>7</manvolnum></citerefentry> for more
+      information.</para>
+
+      <para>Similarly, <function>MaskUnitFiles()</function> masks unit files and
+      <function>UnmaskUnitFiles()</function> unmasks them again.</para>
+
+      <para><function>SetDefaultTarget()</function> changes the <filename>default.target</filename> link. See
+      <citerefentry><refentrytitle>bootup</refentrytitle><manvolnum>7</manvolnum></citerefentry> for more
+      information.</para>
+
+      <para><function>GetDefaultTarget()</function> retrieves the name of the unit to which
+      <filename>default.target</filename> is aliased.</para>
+
+      <para><function>SetUnitProperties()</function> may be used to modify certain unit properties at
+      runtime. Not all properties may be changed at runtime, but many resource management settings (primarily
+      those listed in
+      <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>)
+      may. The changes are applied instantly and stored on disk for future boots, unless
+      <varname>runtime</varname> is true, in which case the settings only apply until the next
+      reboot. <varname>name</varname> is the name of the unit to modify. <varname>properties</varname> are
+      the settings to set, encoded as an array of property name and value pairs. Note that this is not a
+      dictionary! Also note that when setting array properties with this method usually results in appending to
+      the pre-configured array. To reset the configured arrays, set the property to an empty array first and
+      then append to it.</para>
+
+      <para><function>StartTransientUnit()</function> may be used to create and start a transient unit which
+      will be released as soon as it is not running or referenced anymore or the system is
+      rebooted. <varname>name</varname> is the unit name including its suffix and must be
+      unique. <varname>mode</varname> is the same as in <function>StartUnit()</function>,
+      <varname>properties</varname> contains properties of the unit, specified like in
+      <function>SetUnitProperties()</function>. <varname>aux</varname> is currently unused and should be
+      passed as an empty array. See the
+      <ulink url="https://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface">New Control Group
+      Interface</ulink> for more information how to make use of this functionality for resource control
+      purposes.</para>
+
+      <para><function>DumpUnitFileDescriptorStore()</function> returns an array with information about the
+      file descriptors currently in the file descriptor store of the specified unit. This call is equivalent
+      to <function>DumpFileDescriptorStore()</function> on the
+      <interfacename>org.freedesktop.systemd1.Service</interfacename>. For further details, see below.</para>
+    </refsect2>
+
+    <refsect2>
+      <title>Signals</title>
+
+      <para>Note that most signals are sent out only after <function>Subscribe()</function> has been invoked
+      by at least one client. Make sure to invoke this method when subscribing to these signals!</para>
+
+      <para><function>UnitNew()</function> and <function>UnitRemoved()</function> are sent out each time a
+      new unit is loaded or unloaded. Note that this has little to do with whether a unit is available on
+      disk or not, and simply reflects the units that are currently loaded into memory. The signals take two
+      parameters: the primary unit name and the object path.</para>
+
+      <para><function>JobNew()</function> and <function>JobRemoved()</function> are sent out each time a new
+      job is queued or dequeued. Both signals take the numeric job ID, the bus path and the primary unit name
+      for this job as arguments. <function>JobRemoved()</function> also includes a result string which is one
+      of <literal>done</literal>, <literal>canceled</literal>, <literal>timeout</literal>,
+      <literal>failed</literal>, <literal>dependency</literal>, or
+      <literal>skipped</literal>. <literal>done</literal> indicates successful execution of a
+      job. <literal>canceled</literal> indicates that a job has been canceled (via
+      <function>CancelJob()</function> above) before it finished execution (this doesn't necessarily mean
+      though that the job operation is actually cancelled too, see above). <literal>timeout</literal>
+      indicates that the job timeout was reached. <literal>failed</literal> indicates that the job
+      failed. <literal>dependency</literal> indicates that a job this job depended on failed and the job hence
+      was removed as well. <literal>skipped</literal> indicates that a job was skipped because
+      it didn't apply to the unit's current state.</para>
+
+      <para><function>StartupFinished()</function> is sent out when startup finishes. It carries six
+      microsecond timespan values, each indicating how much boot time has been spent in the firmware (if
+      known), in the boot loader (if known), in the kernel initialization phase, in the initrd (if known), in
+      userspace and in total. These values may also be calculated from the
+      <varname>FirmwareTimestampMonotonic</varname>, <varname>LoaderTimestampMonotonic</varname>,
+      <varname>InitRDTimestampMonotonic</varname>, <varname>UserspaceTimestampMonotonic</varname>, and
+      <varname>FinishTimestampMonotonic</varname> properties (see below).</para>
+
+      <para><function>UnitFilesChanged()</function> is sent out each time the list of enabled or masked unit
+      files on disk have changed.</para>
+
+      <para><function>Reloading()</function> is sent out immediately before a daemon reload is done (with the
+      boolean parameter set to True) and after a daemon reload is completed (with the boolean parameter set
+      to False). This may be used by UIs to optimize UI updates.</para>
+    </refsect2>
+
+    <refsect2>
+      <title>Properties</title>
+
+      <para>Most properties simply reflect the respective options in
+      <filename>/etc/systemd/system.conf</filename> and the kernel command line.</para>
+
+      <para>The others:</para>
+
+      <para><varname>Version</varname> encodes the version string of the running systemd instance. Note that
+      the version string is purely informational. It should not be parsed and one may not assume the version to
+      be formatted in any particular way. We take the liberty to change the versioning scheme at any time and
+      it is not part of the public API.</para>
+
+      <para><varname>Features</varname> encodes the features that have been enabled and disabled for this
+      build. Enabled options are prefixed with <literal>+</literal>, disabled options with
+      <literal>-</literal>.</para>
+
+      <para><varname>Tainted</varname> encodes taint flags as a colon-separated list. When systemd detects it
+      is running on a system with a certain problem, it will set an appropriate taint flag. Taints may be
+      used to lower the chance of bogus bug reports. The following taints are currently known:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><literal>unmerged-usr</literal></term>
+
+          <listitem><para><filename>/bin</filename>, <filename>/sbin</filename> and
+          <filename>/lib*</filename> are not symlinks to their counterparts under <filename>/usr/</filename>.
+          For more information on this issue consult
+          <ulink url="https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge">
+            The Case for the /usr Merge
+          </ulink>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+
+        </varlistentry>
+
+        <varlistentry>
+          <term><literal>cgroups-missing</literal></term>
+
+          <listitem><para>Support for cgroups is unavailable.</para>
+
+          <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><literal>cgroupsv1</literal></term>
+
+          <listitem><para>The system is using the old cgroup hierarchy.</para>
+
+          <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><literal>local-hwclock</literal></term>
+
+          <listitem><para>The local hardware clock (RTC) is configured to be in local time rather than
+          UTC.</para>
+
+          <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><literal>support-ended</literal></term>
+
+          <listitem><para>The system is running past the end of support declared by the vendor. See the
+          description of <varname>SUPPORT_END=</varname> in
+          <citerefentry><refentrytitle>os-release</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><literal>old-kernel</literal></term>
+
+          <listitem><para>The system is running a kernel version that is older than the minimum supported by
+          this version of systemd.</para>
+
+          <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><literal>var-run-bad</literal></term>
+
+          <listitem><para><filename>/run/</filename> does not exist or <filename>/var/run</filename> is not a
+          symlink to <filename>/run/</filename>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><literal>overflowuid-not-65534</literal></term>
+          <term><literal>overflowgid-not-65534</literal></term>
+
+          <listitem><para>The kernel overflow UID or GID have a value other than 65534.</para>
+
+          <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><literal>short-uid-range</literal></term>
+          <term><literal>short-gid-range</literal></term>
+
+          <listitem><para>The UID or GID range assigned to the running systemd instance covers less than
+          0…65534.</para>
+
+          <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+        </varlistentry>
+
+        <!-- mtab-not-symlink was removed in b492ce8a22d4527c1372b2d3fbd580627d70c917 -->
+      </variablelist>
+
+      <para><varname>FirmwareTimestamp</varname>, <varname>FirmwareTimestampMonotonic</varname>,
+      <varname>LoaderTimestamp</varname>, <varname>LoaderTimestampMonotonic</varname>,
+      <varname>KernelTimestamp</varname>, <varname>KernelTimestampMonotonic</varname>,
+      <varname>InitRDTimestamp</varname>, <varname>InitRDTimestampMonotonic</varname>,
+      <varname>UserspaceTimestamp</varname>, <varname>UserspaceTimestampMonotonic</varname>,
+      <varname>FinishTimestamp</varname>, and <varname>FinishTimestampMonotonic</varname> encode
+      <constant>CLOCK_REALTIME</constant> and <constant>CLOCK_MONOTONIC</constant> microsecond timestamps
+      taken when the firmware first began execution, when the boot loader first began execution, when the
+      kernel first began execution, when the initrd first began execution, when the main systemd instance
+      began execution and finally, when all queued startup jobs finished execution. These values are useful
+      for determining boot-time performance. Note that as monotonic time begins with the kernel startup, the
+      <varname>KernelTimestampMonotonic</varname> timestamp will always be 0 and
+      <varname>FirmwareTimestampMonotonic</varname> and <varname>LoaderTimestampMonotonic</varname> are to
+      be read as negative values. Also, not all fields are always available, depending on the used firmware,
+      boot loader or initrd implementation. In these cases the respective pairs of timestamps are both 0,
+      indicating that no data is available.</para>
+
+      <para><varname>UnitsLoadTimestamp</varname> and <varname>UnitsLoadTimestampMonotonic</varname> encode
+      <constant>CLOCK_REALTIME</constant> and <constant>CLOCK_MONOTONIC</constant> microseconds timestamps
+      (as described above). The timestamps are taken every time when the manager starts loading unit files.
+      </para>
+
+      <para>Similarly, the <varname>SecurityStartTimestamp</varname>,
+      <varname>GeneratorsStartTimestamp</varname> and <varname>LoadUnitTimestamp</varname> (as well as their
+      monotonic and stop counterparts) expose performance data for uploading the security policies to the
+      kernel (such as the SELinux, IMA, or SMACK policies), for running the generator tools and for loading
+      the unit files.</para>
+
+      <para><varname>NNames</varname> encodes how many unit names are currently known. This only includes
+      names of units that are currently loaded and can be more than the amount of actually loaded units since
+      units may have more than one name.</para>
+
+      <para><varname>NJobs</varname> encodes how many jobs are currently queued.</para>
+
+      <para><varname>NInstalledJobs</varname> encodes how many jobs have ever been queued in total.</para>
+
+      <para><varname>NFailedJobs</varname> encodes how many jobs have ever failed in total.</para>
+
+      <para><varname>Progress</varname> encodes boot progress as a floating point value between 0.0 and
+      1.0. This value begins at 0.0 at early-boot and ends at 1.0 when boot is finished and is based on the
+      number of executed and queued jobs. After startup, this field is always 1.0 indicating a finished
+      boot.</para>
+
+      <para><varname>Environment</varname> encodes the environment block passed to all executed services. It
+      may be altered with bus calls such as <function>SetEnvironment()</function> (see above).</para>
+
+      <para><varname>UnitPath</varname> encodes the currently active unit file search path. It is an array of
+      file system paths encoded as strings.</para>
+
+      <para><varname>Virtualization</varname> contains a short ID string describing the virtualization
+      technology the system runs in. On bare-metal hardware this is the empty string. Otherwise, it contains
+      an identifier such as <literal>kvm</literal>, <literal>vmware</literal> and so on. For a full list of
+      IDs see
+      <citerefentry><refentrytitle>systemd-detect-virt</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
+      Note that only the "innermost" virtualization technology is exported here. This detects both
+      full-machine virtualizations (VMs) and shared-kernel virtualization (containers).</para>
+
+      <para><varname>ConfidentialVirtualization</varname> contains a short ID string describing the confidential
+      virtualization technology the system runs in. On bare-metal hardware this is the empty string. Otherwise,
+      it contains an identifier such as <literal>sev</literal>, <literal>sev-es</literal>, <literal>sev-snp</literal>,
+      <literal>tdx</literal> and so on. For a full list of IDs see
+      <citerefentry><refentrytitle>systemd-detect-virt</refentrytitle><manvolnum>1</manvolnum></citerefentry></para>.
+
+      <para><varname>Architecture</varname> contains a short ID string describing the architecture the
+      systemd instance is running on. This follows the same vocabulary as
+      <varname>ConditionArchitectures=</varname>.</para>
+
+      <para><varname>ControlGroup</varname> contains the root control group path of this system manager. Note
+      that the root path is encoded as the empty string here (not as <literal>/</literal>!), so that it can be
+      appended to <filename>/sys/fs/cgroup/systemd</filename> easily. This value will be set to the empty
+      string for the host instance and some other string for container instances.</para>
+
+      <para><varname>AccessSELinuxContext</varname> contains the SELinux context that is used to control
+      access to the unit. It's read from the unit file when it is loaded and cached until the service manager
+      is reloaded. This property contains an empty string if SELinux is not used or if no label could be read
+      (for example because the unit is not backed by a file on disk).</para>
+
+      <para><varname>SystemState</varname> contains the current state of the system manager. The possible
+      values are:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><literal>initializing</literal></term>
+
+          <listitem><para>The system is booting, and <filename>basic.target</filename> has not been reached
+          yet.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><literal>starting</literal></term>
+
+          <listitem><para>The system is booting, and <filename>basic.target</filename> has been reached.
+          </para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><literal>running</literal></term>
+
+          <listitem><para>The system has finished booting, and no units are in the failed state.</para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><literal>degraded</literal></term>
+
+          <listitem><para>The system has finished booting, but some units are in the failed state.</para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><literal>maintenance</literal></term>
+
+          <listitem><para>The system has finished booting, but it has been put in rescue or maintenance
+          mode.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><literal>stopping</literal></term>
+
+          <listitem><para>The system is shutting down.</para></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+
+    <refsect2>
+      <title>Security</title>
+
+      <para>Read access is generally granted to all clients. Additionally, for unprivileged clients, some
+      operations are allowed through the polkit privilege system. Operations which modify unit state
+      (<function>StartUnit()</function>, <function>StopUnit()</function>, <function>KillUnit()</function>,
+      <function>QueueSignalUnit()</function>, <function>RestartUnit()</function> and similar,
+      <function>SetProperty()</function>) require
+      <interfacename>org.freedesktop.systemd1.manage-units</interfacename>. Operations which modify unit file
+      enablement state (<function>EnableUnitFiles()</function>, <function>DisableUnitFiles()</function>,
+      <function>EnableUnitFilesWithFlags()</function>, <function>DisableUnitFilesWithFlags()</function>,
+      <function>ReenableUnitFiles()</function>, <function>LinkUnitFiles()</function>,
+      <function>PresetUnitFiles</function>, <function>MaskUnitFiles</function>, and similar) require
+      <interfacename>org.freedesktop.systemd1.manage-unit-files</interfacename>. Operations which modify the
+      exported environment (<function>SetEnvironment()</function>, <function>UnsetEnvironment()</function>,
+      <function>UnsetAndSetEnvironment()</function>) require
+      <interfacename>org.freedesktop.systemd1.set-environment</interfacename>. <function>Reload()</function>
+      and <function>Reexecute()</function> require
+      <interfacename>org.freedesktop.systemd1.reload-daemon</interfacename>. Operations which dump internal
+      state require <interfacename>org.freedesktop.systemd1.bypass-dump-ratelimit</interfacename> to avoid
+      rate limits.
+      </para>
+    </refsect2>
+  </refsect1>
+
+  <refsect1>
+    <title>Unit Objects</title>
+
+    <programlisting executable="systemd" node="/org/freedesktop/systemd1/unit/avahi_2ddaemon_2eservice" interface="org.freedesktop.systemd1.Unit">
+node /org/freedesktop/systemd1/unit/avahi_2ddaemon_2eservice {
+  interface org.freedesktop.systemd1.Unit {
+    methods:
+      Start(in  s mode,
+            out o job);
+      Stop(in  s mode,
+           out o job);
+      Reload(in  s mode,
+             out o job);
+      Restart(in  s mode,
+              out o job);
+      TryRestart(in  s mode,
+                 out o job);
+      ReloadOrRestart(in  s mode,
+                      out o job);
+      ReloadOrTryRestart(in  s mode,
+                         out o job);
+      EnqueueJob(in  s job_type,
+                 in  s job_mode,
+                 out u job_id,
+                 out o job_path,
+                 out s unit_id,
+                 out o unit_path,
+                 out s job_type,
+                 out a(uosos) affected_jobs);
+      Kill(in  s whom,
+           in  i signal);
+      QueueSignal(in  s whom,
+                  in  i signal,
+                  in  i value);
+      ResetFailed();
+      SetProperties(in  b runtime,
+                    in  a(sv) properties);
+      Ref();
+      Unref();
+      Clean(in  as mask);
+      Freeze();
+      Thaw();
+    properties:
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s Id = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as Names = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s Following = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as Requires = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as Requisite = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as Wants = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as BindsTo = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as PartOf = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as Upholds = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as RequiredBy = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as RequisiteOf = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as WantedBy = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as BoundBy = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as UpheldBy = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as ConsistsOf = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as Conflicts = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as ConflictedBy = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as Before = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as After = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as OnSuccess = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as OnSuccessOf = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as OnFailure = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as OnFailureOf = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as Triggers = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as TriggeredBy = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as PropagatesReloadTo = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as ReloadPropagatedFrom = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as PropagatesStopTo = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as StopPropagatedFrom = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as JoinsNamespaceOf = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as SliceOf = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as RequiresMountsFor = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as Documentation = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s Description = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s AccessSELinuxContext = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s LoadState = '...';
+      readonly s ActiveState = '...';
+      readonly s FreezerState = '...';
+      readonly s SubState = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s FragmentPath = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s SourcePath = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as DropInPaths = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s UnitFileState = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s UnitFilePreset = '...';
+      readonly t StateChangeTimestamp = ...;
+      readonly t StateChangeTimestampMonotonic = ...;
+      readonly t InactiveExitTimestamp = ...;
+      readonly t InactiveExitTimestampMonotonic = ...;
+      readonly t ActiveEnterTimestamp = ...;
+      readonly t ActiveEnterTimestampMonotonic = ...;
+      readonly t ActiveExitTimestamp = ...;
+      readonly t ActiveExitTimestampMonotonic = ...;
+      readonly t InactiveEnterTimestamp = ...;
+      readonly t InactiveEnterTimestampMonotonic = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b CanStart = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b CanStop = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b CanReload = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b CanIsolate = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as CanClean = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b CanFreeze = ...;
+      readonly (uo) Job = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b StopWhenUnneeded = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b RefuseManualStart = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b RefuseManualStop = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b AllowIsolate = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b DefaultDependencies = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b SurviveFinalKillSignal = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s OnSuccessJobMode = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s OnFailureJobMode = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b IgnoreOnIsolate = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly b NeedDaemonReload = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly as Markers = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t JobTimeoutUSec = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t JobRunningTimeoutUSec = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s JobTimeoutAction = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s JobTimeoutRebootArgument = '...';
+      readonly b ConditionResult = ...;
+      readonly b AssertResult = ...;
+      readonly t ConditionTimestamp = ...;
+      readonly t ConditionTimestampMonotonic = ...;
+      readonly t AssertTimestamp = ...;
+      readonly t AssertTimestampMonotonic = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates")
+      readonly a(sbbsi) Conditions = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates")
+      readonly a(sbbsi) Asserts = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly (ss) LoadError = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b Transient = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b Perpetual = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t StartLimitIntervalUSec = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly u StartLimitBurst = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s StartLimitAction = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s FailureAction = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i FailureActionExitStatus = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s SuccessAction = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i SuccessActionExitStatus = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s RebootArgument = '...';
+      readonly ay InvocationID = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s CollectMode = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly as Refs = ['...', ...];
+      readonly a(ss) ActivationDetails = [...];
+  };
+  interface org.freedesktop.DBus.Peer { ... };
+  interface org.freedesktop.DBus.Introspectable { ... };
+  interface org.freedesktop.DBus.Properties { ... };
+};
+    </programlisting>
+
+    <!--method EnqueueJob is not documented!-->
+
+    <!--method Ref is not documented!-->
+
+    <!--method Unref is not documented!-->
+
+    <!--method Clean is not documented!-->
+
+    <!--method Freeze is not documented!-->
+
+    <!--method Thaw is not documented!-->
+
+    <!--property PartOf is not documented!-->
+
+    <!--property Upholds is not documented!-->
+
+    <!--property RequisiteOf is not documented!-->
+
+    <!--property UpheldBy is not documented!-->
+
+    <!--property ConsistsOf is not documented!-->
+
+    <!--property OnSuccess is not documented!-->
+
+    <!--property OnSuccessOf is not documented!-->
+
+    <!--property OnFailureOf is not documented!-->
+
+    <!--property ReloadPropagatedFrom is not documented!-->
+
+    <!--property PropagatesStopTo is not documented!-->
+
+    <!--property StopPropagatedFrom is not documented!-->
+
+    <!--property JoinsNamespaceOf is not documented!-->
+
+    <!--property SliceOf is not documented!-->
+
+    <!--property FreezerState is not documented!-->
+
+    <!--property DropInPaths is not documented!-->
+
+    <!--property UnitFilePreset is not documented!-->
+
+    <!--property StateChangeTimestamp is not documented!-->
+
+    <!--property StateChangeTimestampMonotonic is not documented!-->
+
+    <!--property CanClean is not documented!-->
+
+    <!--property CanFreeze is not documented!-->
+
+    <!--property SurviveFinalKillSignal is not documented!-->
+
+    <!--property OnSuccessJobMode is not documented!-->
+
+    <!--property OnFailureJobMode is not documented!-->
+
+    <!--property JobRunningTimeoutUSec is not documented!-->
+
+    <!--property JobTimeoutAction is not documented!-->
+
+    <!--property JobTimeoutRebootArgument is not documented!-->
+
+    <!--property AssertResult is not documented!-->
+
+    <!--property AssertTimestamp is not documented!-->
+
+    <!--property AssertTimestampMonotonic is not documented!-->
+
+    <!--property Asserts is not documented!-->
+
+    <!--property Perpetual is not documented!-->
+
+    <!--property StartLimitIntervalUSec is not documented!-->
+
+    <!--property StartLimitAction is not documented!-->
+
+    <!--property FailureAction is not documented!-->
+
+    <!--property FailureActionExitStatus is not documented!-->
+
+    <!--property SuccessAction is not documented!-->
+
+    <!--property SuccessActionExitStatus is not documented!-->
+
+    <!--property RebootArgument is not documented!-->
+
+    <!--property InvocationID is not documented!-->
+
+    <!--property CollectMode is not documented!-->
+
+    <!--property Refs is not documented!-->
+
+    <!--Autogenerated cross-references for systemd.directives, do not edit-->
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Unit"/>
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Unit"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="Start()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="Stop()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="Reload()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="Restart()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="TryRestart()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="ReloadOrRestart()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="ReloadOrTryRestart()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="EnqueueJob()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="Kill()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="QueueSignal()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="ResetFailed()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SetProperties()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="Ref()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="Unref()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="Clean()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="Freeze()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="Thaw()"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Id"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Names"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Following"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Requires"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Requisite"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Wants"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="BindsTo"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="PartOf"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Upholds"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RequiredBy"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RequisiteOf"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="WantedBy"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="BoundBy"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="UpheldBy"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ConsistsOf"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Conflicts"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ConflictedBy"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Before"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="After"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="OnSuccess"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="OnSuccessOf"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="OnFailure"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="OnFailureOf"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Triggers"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TriggeredBy"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="PropagatesReloadTo"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ReloadPropagatedFrom"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="PropagatesStopTo"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StopPropagatedFrom"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="JoinsNamespaceOf"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SliceOf"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RequiresMountsFor"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Documentation"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Description"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="AccessSELinuxContext"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LoadState"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ActiveState"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="FreezerState"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SubState"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="FragmentPath"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SourcePath"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DropInPaths"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="UnitFileState"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="UnitFilePreset"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StateChangeTimestamp"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StateChangeTimestampMonotonic"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="InactiveExitTimestamp"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="InactiveExitTimestampMonotonic"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ActiveEnterTimestamp"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ActiveEnterTimestampMonotonic"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ActiveExitTimestamp"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ActiveExitTimestampMonotonic"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="InactiveEnterTimestamp"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="InactiveEnterTimestampMonotonic"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CanStart"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CanStop"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CanReload"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CanIsolate"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CanClean"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CanFreeze"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Job"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StopWhenUnneeded"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RefuseManualStart"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RefuseManualStop"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="AllowIsolate"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DefaultDependencies"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SurviveFinalKillSignal"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="OnSuccessJobMode"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="OnFailureJobMode"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IgnoreOnIsolate"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="NeedDaemonReload"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Markers"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="JobTimeoutUSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="JobRunningTimeoutUSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="JobTimeoutAction"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="JobTimeoutRebootArgument"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ConditionResult"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="AssertResult"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ConditionTimestamp"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ConditionTimestampMonotonic"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="AssertTimestamp"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="AssertTimestampMonotonic"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Conditions"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Asserts"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LoadError"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Transient"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Perpetual"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StartLimitIntervalUSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StartLimitBurst"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StartLimitAction"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="FailureAction"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="FailureActionExitStatus"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SuccessAction"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SuccessActionExitStatus"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RebootArgument"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="InvocationID"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CollectMode"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Refs"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ActivationDetails"/>
+
+    <!--End of Autogenerated section-->
+
+    <refsect2>
+      <title>Methods</title>
+
+      <para><function>Start()</function>, <function>Stop()</function>, <function>Reload()</function>,
+      <function>Restart()</function>, <function>TryRestart()</function>,
+      <function>ReloadOrRestart()</function>, <function>ReloadOrTryRestart()</function>,
+      <function>Kill()</function>, <function>QueueSignal()</function>, <function>ResetFailed()</function>,
+      and <function>SetProperties()</function> implement the same operation as the respective methods on the
+      <interfacename>Manager</interfacename> object (see above). However, these methods operate on the unit
+      object and hence do not take a unit name parameter. Invoking the methods directly on the Manager object
+      has the advantage of not requiring a <function>GetUnit()</function> call to get the unit object for a
+      specific unit name. Calling the methods on the Manager object is hence a round trip
+      optimization.</para>
+    </refsect2>
+
+    <refsect2>
+      <title>Properties</title>
+
+      <para><varname>Id</varname> contains the primary name of the unit.</para>
+
+      <para><varname>Names</varname> contains all names of the unit, including the primary name that is also
+      exposed in <varname>Id</varname>.</para>
+
+      <para><varname>Following</varname> either contains the empty string or contains the name of another
+      unit that this unit follows in state. This is used for some device units which reflect the unit state
+      machine of another unit, and which other unit this is might possibly change.</para>
+
+      <para><varname>Requires</varname>, <varname>RequiresOverridable</varname>,
+      <varname>Requisite</varname>, <varname>RequisiteOverridable</varname>, <varname>Wants</varname>,
+      <varname>BindsTo</varname>, <varname>RequiredBy</varname>, <varname>RequiredByOverridable</varname>,
+      <varname>WantedBy</varname>, <varname>BoundBy</varname>, <varname>Conflicts</varname>,
+      <varname>ConflictedBy</varname>, <varname>Before</varname>, <varname>After</varname>,
+      <varname>OnFailure</varname>, <varname>Triggers</varname>, <varname>TriggeredBy</varname>,
+      <varname>PropagatesReloadTo</varname>, and <varname>RequiresMountsFor</varname> contain arrays which encode
+      the dependencies and their inverse dependencies (where this applies) as configured in the unit file or
+      determined automatically.</para>
+
+      <para><varname>Description</varname> contains the human readable description string for the
+      unit.</para>
+
+      <para><varname>SourcePath</varname> contains the path to a configuration file this unit is
+      automatically generated from in case it is not a native unit (in which case it contains the empty
+      string). For example, all mount units generated from <filename>/etc/fstab</filename> have this field
+      set to <filename>/etc/fstab</filename>.</para>
+
+      <para><varname>Documentation</varname> contains a string array with URLs of documentation for this
+      unit.</para>
+
+      <para><varname>LoadState</varname> contains a state value that reflects whether the configuration file
+      of this unit has been loaded. The following states are currently defined: <literal>loaded</literal>,
+      <literal>error</literal>, and <literal>masked</literal>. <literal>loaded</literal> indicates that the
+      configuration was successfully loaded. <literal>error</literal> indicates that the configuration failed
+      to load. The <varname>LoadError</varname> field (see below) contains information about the cause of
+      this failure. <literal>masked</literal> indicates that the unit is currently masked out (i.e. symlinked
+      to <filename>/dev/null</filename> or empty). Note that the <varname>LoadState</varname> is fully
+      orthogonal to the <varname>ActiveState</varname> (see below) as units without valid loaded
+      configuration might be active (because configuration might have been reloaded at a time where a unit
+      was already active).</para>
+
+      <para><varname>ActiveState</varname> contains a state value that reflects whether the unit is currently
+      active or not. The following states are currently defined: <literal>active</literal>,
+      <literal>reloading</literal>, <literal>inactive</literal>, <literal>failed</literal>,
+      <literal>activating</literal>, and <literal>deactivating</literal>. <literal>active</literal> indicates
+      that unit is active (obviously...). <literal>reloading</literal> indicates that the unit is active and
+      currently reloading its configuration. <literal>inactive</literal> indicates that it is inactive and
+      the previous run was successful or no previous run has taken place yet. <literal>failed</literal>
+      indicates that it is inactive and the previous run was not successful (more information about the
+      reason for this is available on the unit type specific interfaces, for example for services in the
+      <varname>Result</varname> property, see below). <literal>activating</literal> indicates that the unit
+      has previously been inactive but is currently in the process of entering an active state. Conversely
+      <literal>deactivating</literal> indicates that the unit is currently in the process of
+      deactivation.</para>
+
+      <para><varname>SubState</varname> encodes states of the same state machine that
+      <varname>ActiveState</varname> covers, but knows more fine-grained states that are
+      unit-type-specific. Where <varname>ActiveState</varname> only covers six high-level states,
+      <varname>SubState</varname> covers possibly many more low-level unit-type-specific states that are
+      mapped to the six high-level states. Note that multiple low-level states might map to the same
+      high-level state, but not vice versa. Not all high-level states have low-level counterparts on all unit
+      types. At this point the low-level states are not documented here, and are more likely to be extended
+      later on than the common high-level states explained above.</para>
+
+      <para><varname>FragmentPath</varname> contains the unit file path this unit was read from, if there is
+      one (if not, it contains the empty string).</para>
+
+      <para><varname>UnitFileState</varname> encodes the install state of the unit file of
+      <varname>FragmentPath</varname>. It currently knows the following states: <literal>enabled</literal>,
+      <literal>enabled-runtime</literal>, <literal>linked</literal>, <literal>linked-runtime</literal>,
+      <literal>masked</literal>, <literal>masked-runtime</literal>, <literal>static</literal>,
+      <literal>disabled</literal>, and <literal>invalid</literal>. <literal>enabled</literal> indicates that a
+      unit file is permanently enabled. <literal>enable-runtime</literal> indicates the unit file is only
+      temporarily enabled and will no longer be enabled after a reboot (that means, it is enabled via
+      <filename>/run/</filename> symlinks, rather than <filename>/etc/</filename>). <literal>linked</literal>
+      indicates that a unit is linked into <filename>/etc/</filename> permanently. <literal>linked-runtime</literal>
+      indicates that a unit is linked into <filename>/run/</filename> temporarily (until the next
+      reboot). <literal>masked</literal> indicates that the unit file is masked permanently.
+      <literal>masked-runtime</literal> indicates that it is masked in <filename>/run/</filename> temporarily
+      (until the next reboot). <literal>static</literal> indicates that the unit is statically enabled, i.e.
+      always enabled and doesn't need to be enabled explicitly. <literal>invalid</literal> indicates that it
+      could not be determined whether the unit file is enabled.</para>
+
+      <para><varname>InactiveExitTimestamp</varname>, <varname>InactiveExitTimestampMonotonic</varname>,
+      <varname>ActiveEnterTimestamp</varname>, <varname>ActiveEnterTimestampMonotonic</varname>,
+      <varname>ActiveExitTimestamp</varname>, <varname>ActiveExitTimestampMonotonic</varname>,
+      <varname>InactiveEnterTimestamp</varname>, and <varname>InactiveEnterTimestampMonotonic</varname>
+      contain <constant>CLOCK_REALTIME</constant> and <constant>CLOCK_MONOTONIC</constant> 64-bit microsecond
+      timestamps of the last time a unit left the inactive state, entered the active state, exited the active
+      state, or entered an inactive state. These are the points in time where the unit transitioned
+      <literal>inactive</literal>/<literal>failed</literal> → <literal>activating</literal>,
+      <literal>activating</literal> → <literal>active</literal>, <literal>active</literal> →
+      <literal>deactivating</literal>, and finally <literal>deactivating</literal> →
+      <literal>inactive</literal>/<literal>failed</literal>. The fields are 0 in case such a transition has
+      not yet been recorded on this boot.</para>
+
+      <para><varname>CanStart</varname>, <varname>CanStop</varname>, and <varname>CanReload</varname> encode
+      as booleans whether the unit supports the start, stop or reload operations. Even if a unit supports
+      such an operation, the client might not necessary have the necessary privileges to execute them.</para>
+
+      <para><varname>CanIsolate</varname> encodes as a boolean whether the unit may be started in isolation
+      mode.</para>
+
+      <para><varname>Job</varname> encodes the job ID and job object path of the job currently scheduled or
+      executed for this unit, if there is any. If no job is scheduled or executed, the job id field will be
+      0.</para>
+
+      <para><varname>StopWhenUnneeded</varname>, <varname>RefuseManualStart</varname>,
+      <varname>RefuseManualStop</varname>, <varname>AllowIsolate</varname>,
+      <varname>DefaultDependencies</varname>, <varname>OnFailureIsolate</varname>,
+      <varname>IgnoreOnIsolate</varname>, <varname>IgnoreOnSnapshot</varname> map directly to the
+      corresponding configuration booleans in the unit file.</para>
+
+      <para><varname>NeedDaemonReload</varname> is a boolean that indicates whether the configuration file
+      this unit is loaded from (i.e. <varname>FragmentPath</varname> or <varname>SourcePath</varname>) has
+      changed since the configuration was read and hence whether a configuration reload is recommended.
+      </para>
+
+      <para><varname>Markers</varname> is an array of string flags that can be set using
+      <function>SetUnitProperties()</function> to indicate that the service should be reloaded or
+      restarted. Currently known values are <literal>needs-restart</literal> and
+      <literal>needs-reload</literal>. Package scripts may use the first to mark units for later restart when
+      a new version of the package is installed. Configuration management scripts may use the second to mark
+      units for a later reload when the configuration is adjusted. Those flags are not set by the manager,
+      except to unset as appropriate when the unit is stopped, restarted, or reloaded.</para>
+
+      <para><varname>JobTimeoutUSec</varname> maps directly to the corresponding configuration setting in the
+      unit file.</para>
+
+      <para><varname>ConditionTimestamp</varname> and <varname>ConditionTimestampMonotonic</varname> contain
+      the <constant>CLOCK_REALTIME</constant>/<constant>CLOCK_MONOTONIC</constant> microsecond timestamps of
+      the last time the configured conditions of the unit have been checked or 0 if they have never been
+      checked. Conditions are checked when a unit is requested to start.</para>
+
+      <para><varname>ConditionResult</varname> contains the condition result of the last time the configured
+      conditions of this unit were checked. </para>
+
+      <para><varname>Conditions</varname> contains all configured conditions of the unit. For each condition,
+      five fields are given: condition type (e.g. <varname>ConditionPathExists</varname>), whether the
+      condition is a trigger condition, whether the condition is reversed, the right hand side of the
+      condition (e.g. the path in case of <varname>ConditionPathExists</varname>), and the status. The status
+      can be 0, in which case the condition hasn't been checked yet, a positive value, in which case the
+      condition passed, or a negative value, in which case the condition is not met. Currently only 0, +1, and -1
+      are used, but additional values may be used in the future, retaining the meaning of
+      zero/positive/negative values.</para>
+
+      <para><varname>LoadError</varname> contains a pair of strings. If the unit failed to load (as encoded
+      in <varname>LoadState</varname>, see above), then this will include a D-Bus error pair consisting of
+      the error ID and an explanatory human readable string of what happened. If it loaded successfully, this
+      will be a pair of empty strings.</para>
+
+      <para><varname>Transient</varname> contains a boolean that indicates whether the unit was created as a
+      transient unit (i.e. via <function>StartTransientUnit()</function> on the manager object).</para>
+
+      <para><varname>ActivationDetails</varname> contains a list of string pairs, key and value, that
+      describe the event that caused the unit to be activated, if any. The key describes the information
+      (e.g.: <varname>trigger_unit</varname>, with value <varname>foo.service</varname>). This is only filled
+      in if the unit was triggered by a <varname>Path</varname> or <varname>Timer</varname> unit, and it is
+      only provided in a best effort fashion: it is not guaranteed to be set, and it is not guaranteed to be
+      the only trigger. It is only guaranteed to be a valid trigger that caused the activation job to be
+      enqueued and complete successfully. The key value pairs correspond (in lowercase) to the environment
+      variables described in the <literal>Environment Variables Set or Propagated by the Service
+      Manager</literal> section in
+      <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>. Note
+      that new key value pair may be added at any time in future versions. Existing entries will not be
+      removed.</para>
+    </refsect2>
+
+    <refsect2>
+      <title>Security</title>
+
+      <para>Similarly to methods on the <interfacename>Manager</interfacename> object, read-only access is
+      allowed for everyone. All operations are allowed for clients with the
+      <constant>CAP_SYS_ADMIN</constant> capability or when the
+      <interfacename>org.freedesktop.systemd1.manage-units</interfacename> privilege is granted by
+      polkit.</para>
+    </refsect2>
+  </refsect1>
+
+  <refsect1>
+    <title>Service Unit Objects</title>
+
+    <para>All service unit objects implement the
+    <interfacename>org.freedesktop.systemd1.Service</interfacename> interface (described here) in addition to
+    the generic <interfacename>org.freedesktop.systemd1.Unit</interfacename> interface (see above).</para>
+
+    <programlisting executable="systemd" node="/org/freedesktop/systemd1/unit/avahi_2ddaemon_2eservice" interface="org.freedesktop.systemd1.Service">
+node /org/freedesktop/systemd1/unit/avahi_2ddaemon_2eservice {
+  interface org.freedesktop.systemd1.Service {
+    methods:
+      BindMount(in  s source,
+                in  s destination,
+                in  b read_only,
+                in  b mkdir);
+      MountImage(in  s source,
+                 in  s destination,
+                 in  b read_only,
+                 in  b mkdir,
+                 in  a(ss) options);
+      DumpFileDescriptorStore(out a(suuutuusu) entries);
+      GetProcesses(out a(sus) processes);
+      AttachProcesses(in  s subcgroup,
+                      in  au pids);
+    properties:
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s Type = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s ExitType = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s Restart = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s RestartMode = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s PIDFile = '...';
+      readonly s NotifyAccess = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t RestartUSec = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly u RestartSteps = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t RestartMaxDelayUSec = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t RestartUSecNext = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t TimeoutStartUSec = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t TimeoutStopUSec = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t TimeoutAbortUSec = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s TimeoutStartFailureMode = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s TimeoutStopFailureMode = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t RuntimeMaxUSec = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t RuntimeRandomizedExtraUSec = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t WatchdogUSec = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t WatchdogTimestamp = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t WatchdogTimestampMonotonic = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b RootDirectoryStartOnly = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b RemainAfterExit = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b GuessMainPID = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly (aiai) RestartPreventExitStatus = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly (aiai) RestartForceExitStatus = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly (aiai) SuccessExitStatus = ...;
+      readonly u MainPID = ...;
+      readonly u ControlPID = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s BusName = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly u FileDescriptorStoreMax = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly u NFileDescriptorStore = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s FileDescriptorStorePreserve = '...';
+      readonly s StatusText = '...';
+      readonly i StatusErrno = ...;
+      readonly s Result = '...';
+      readonly s ReloadResult = '...';
+      readonly s CleanResult = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s USBFunctionDescriptors = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s USBFunctionStrings = '...';
+      readonly u UID = ...;
+      readonly u GID = ...;
+      readonly u NRestarts = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s OOMPolicy = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly a(sst) OpenFile = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i ReloadSignal = ...;
+      readonly t ExecMainStartTimestamp = ...;
+      readonly t ExecMainStartTimestampMonotonic = ...;
+      readonly t ExecMainExitTimestamp = ...;
+      readonly t ExecMainExitTimestampMonotonic = ...;
+      readonly u ExecMainPID = ...;
+      readonly i ExecMainCode = ...;
+      readonly i ExecMainStatus = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates")
+      readonly a(sasbttttuii) ExecCondition = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates")
+      readonly a(sasasttttuii) ExecConditionEx = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates")
+      readonly a(sasbttttuii) ExecStartPre = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates")
+      readonly a(sasasttttuii) ExecStartPreEx = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates")
+      readonly a(sasbttttuii) ExecStart = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates")
+      readonly a(sasasttttuii) ExecStartEx = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates")
+      readonly a(sasbttttuii) ExecStartPost = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates")
+      readonly a(sasasttttuii) ExecStartPostEx = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates")
+      readonly a(sasbttttuii) ExecReload = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates")
+      readonly a(sasasttttuii) ExecReloadEx = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates")
+      readonly a(sasbttttuii) ExecStop = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates")
+      readonly a(sasasttttuii) ExecStopEx = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates")
+      readonly a(sasbttttuii) ExecStopPost = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates")
+      readonly a(sasasttttuii) ExecStopPostEx = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s Slice = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s ControlGroup = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t ControlGroupId = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemoryCurrent = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemoryPeak = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemorySwapCurrent = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemorySwapPeak = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemoryZSwapCurrent = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemoryAvailable = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t CPUUsageNSec = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly ay EffectiveCPUs = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly ay EffectiveMemoryNodes = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t TasksCurrent = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t IPIngressBytes = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t IPIngressPackets = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t IPEgressBytes = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t IPEgressPackets = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t IOReadBytes = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t IOReadOperations = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t IOWriteBytes = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t IOWriteOperations = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly b Delegate = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly as DelegateControllers = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s DelegateSubgroup = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly b CPUAccounting = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t CPUWeight = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t StartupCPUWeight = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t CPUShares = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t StartupCPUShares = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t CPUQuotaPerSecUSec = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t CPUQuotaPeriodUSec = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly ay AllowedCPUs = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly ay StartupAllowedCPUs = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly ay AllowedMemoryNodes = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly ay StartupAllowedMemoryNodes = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly b IOAccounting = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t IOWeight = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t StartupIOWeight = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(st) IODeviceWeight = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(st) IOReadBandwidthMax = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(st) IOWriteBandwidthMax = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(st) IOReadIOPSMax = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(st) IOWriteIOPSMax = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(st) IODeviceLatencyTargetUSec = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly b BlockIOAccounting = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t BlockIOWeight = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t StartupBlockIOWeight = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(st) BlockIODeviceWeight = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(st) BlockIOReadBandwidth = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(st) BlockIOWriteBandwidth = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly b MemoryAccounting = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t DefaultMemoryLow = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t DefaultStartupMemoryLow = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t DefaultMemoryMin = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemoryMin = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemoryLow = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t StartupMemoryLow = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemoryHigh = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t StartupMemoryHigh = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemoryMax = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t StartupMemoryMax = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemorySwapMax = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t StartupMemorySwapMax = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemoryZSwapMax = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t StartupMemoryZSwapMax = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemoryLimit = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s DevicePolicy = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(ss) DeviceAllow = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly b TasksAccounting = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t TasksMax = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly b IPAccounting = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(iayu) IPAddressAllow = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(iayu) IPAddressDeny = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly as IPIngressFilterPath = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly as IPEgressFilterPath = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly as DisableControllers = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s ManagedOOMSwap = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s ManagedOOMMemoryPressure = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly u ManagedOOMMemoryPressureLimit = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s ManagedOOMPreference = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(ss) BPFProgram = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(iiqq) SocketBindAllow = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(iiqq) SocketBindDeny = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly (bas) RestrictNetworkInterfaces = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s MemoryPressureWatch = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemoryPressureThresholdUSec = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(iiss) NFTSet = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly b CoredumpReceive = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as Environment = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly a(sb) EnvironmentFiles = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as PassEnvironment = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as UnsetEnvironment = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly u UMask = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitCPU = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitCPUSoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitFSIZE = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitFSIZESoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitDATA = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitDATASoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitSTACK = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitSTACKSoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitCORE = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitCORESoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitRSS = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitRSSSoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitNOFILE = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitNOFILESoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitAS = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitASSoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitNPROC = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitNPROCSoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitMEMLOCK = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitMEMLOCKSoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitLOCKS = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitLOCKSSoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitSIGPENDING = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitSIGPENDINGSoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitMSGQUEUE = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitMSGQUEUESoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitNICE = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitNICESoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitRTPRIO = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitRTPRIOSoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitRTTIME = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitRTTIMESoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s WorkingDirectory = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s RootDirectory = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s RootImage = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly a(ss) RootImageOptions = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly ay RootHash = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s RootHashPath = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly ay RootHashSignature = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s RootHashSignaturePath = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s RootVerity = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b RootEphemeral = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as ExtensionDirectories = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly a(sba(ss)) ExtensionImages = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly a(ssba(ss)) MountImages = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i OOMScoreAdjust = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t CoredumpFilter = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i Nice = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i IOSchedulingClass = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i IOSchedulingPriority = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i CPUSchedulingPolicy = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i CPUSchedulingPriority = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly ay CPUAffinity = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b CPUAffinityFromNUMA = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i NUMAPolicy = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly ay NUMAMask = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t TimerSlackNSec = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b CPUSchedulingResetOnFork = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b NonBlocking = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s StandardInput = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s StandardInputFileDescriptorName = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly ay StandardInputData = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s StandardOutput = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s StandardOutputFileDescriptorName = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s StandardError = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s StandardErrorFileDescriptorName = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s TTYPath = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b TTYReset = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b TTYVHangup = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b TTYVTDisallocate = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly q TTYRows = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly q TTYColumns = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i SyslogPriority = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s SyslogIdentifier = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b SyslogLevelPrefix = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i SyslogLevel = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i SyslogFacility = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i LogLevelMax = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LogRateLimitIntervalUSec = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly u LogRateLimitBurst = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly aay LogExtraFields = [[...], ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly a(bs) LogFilterPatterns = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s LogNamespace = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i SecureBits = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t CapabilityBoundingSet = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t AmbientCapabilities = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s User = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s Group = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b DynamicUser = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b SetLoginEnvironment = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b RemoveIPC = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly a(say) SetCredential = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly a(say) SetCredentialEncrypted = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly a(ss) LoadCredential = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly a(ss) LoadCredentialEncrypted = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as ImportCredential = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as SupplementaryGroups = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s PAMName = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as ReadWritePaths = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as ReadOnlyPaths = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as InaccessiblePaths = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as ExecPaths = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as NoExecPaths = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as ExecSearchPath = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t MountFlags = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b PrivateTmp = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b PrivateDevices = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b ProtectClock = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b ProtectKernelTunables = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b ProtectKernelModules = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b ProtectKernelLogs = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b ProtectControlGroups = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b PrivateNetwork = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b PrivateUsers = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b PrivateMounts = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b PrivateIPC = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s ProtectHome = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s ProtectSystem = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b SameProcessGroup = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s UtmpIdentifier = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s UtmpMode = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly (bs) SELinuxContext = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly (bs) AppArmorProfile = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly (bs) SmackProcessLabel = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b IgnoreSIGPIPE = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b NoNewPrivileges = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly (bas) SystemCallFilter = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as SystemCallArchitectures = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i SystemCallErrorNumber = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly (bas) SystemCallLog = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s Personality = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b LockPersonality = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly (bas) RestrictAddressFamilies = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly a(sst) RuntimeDirectorySymlink = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s RuntimeDirectoryPreserve = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly u RuntimeDirectoryMode = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as RuntimeDirectory = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly a(sst) StateDirectorySymlink = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly u StateDirectoryMode = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as StateDirectory = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly a(sst) CacheDirectorySymlink = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly u CacheDirectoryMode = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as CacheDirectory = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly a(sst) LogsDirectorySymlink = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly u LogsDirectoryMode = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as LogsDirectory = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly u ConfigurationDirectoryMode = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as ConfigurationDirectory = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t TimeoutCleanUSec = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b MemoryDenyWriteExecute = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b RestrictRealtime = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b RestrictSUIDSGID = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t RestrictNamespaces = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly (bas) RestrictFileSystems = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly a(ssbt) BindPaths = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly a(ssbt) BindReadOnlyPaths = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly a(ss) TemporaryFileSystem = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b MountAPIVFS = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s KeyringMode = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s ProtectProc = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s ProcSubset = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b ProtectHostname = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b MemoryKSM = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s NetworkNamespacePath = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s IPCNamespacePath = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s RootImagePolicy = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s MountImagePolicy = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s ExtensionImagePolicy = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s KillMode = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i KillSignal = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i RestartKillSignal = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i FinalKillSignal = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b SendSIGKILL = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b SendSIGHUP = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i WatchdogSignal = ...;
+  };
+  interface org.freedesktop.DBus.Peer { ... };
+  interface org.freedesktop.DBus.Introspectable { ... };
+  interface org.freedesktop.DBus.Properties { ... };
+  interface org.freedesktop.systemd1.Unit { ... };
+};
+    </programlisting>
+
+    <!--method GetProcesses is not documented!-->
+
+    <!--method AttachProcesses is not documented!-->
+
+    <!--property Type is not documented!-->
+
+    <!--property ExitType is not documented!-->
+
+    <!--property Restart is not documented!-->
+
+    <!--property RestartMode is not documented!-->
+
+    <!--property PIDFile is not documented!-->
+
+    <!--property NotifyAccess is not documented!-->
+
+    <!--property RestartUSec is not documented!-->
+
+    <!--property RestartSteps is not documented!-->
+
+    <!--property RestartMaxDelayUSec is not documented!-->
+
+    <!--property RestartUSecNext is not documented!-->
+
+    <!--property TimeoutStartFailureMode is not documented!-->
+
+    <!--property TimeoutStopFailureMode is not documented!-->
+
+    <!--property RuntimeMaxUSec is not documented!-->
+
+    <!--property RuntimeRandomizedExtraUSec is not documented!-->
+
+    <!--property WatchdogUSec is not documented!-->
+
+    <!--property RootDirectoryStartOnly is not documented!-->
+
+    <!--property RemainAfterExit is not documented!-->
+
+    <!--property GuessMainPID is not documented!-->
+
+    <!--property RestartPreventExitStatus is not documented!-->
+
+    <!--property RestartForceExitStatus is not documented!-->
+
+    <!--property SuccessExitStatus is not documented!-->
+
+    <!--property BusName is not documented!-->
+
+    <!--property FileDescriptorStoreMax is not documented!-->
+
+    <!--property NFileDescriptorStore is not documented!-->
+
+    <!--property FileDescriptorStorePreserve is not documented!-->
+
+    <!--property StatusErrno is not documented!-->
+
+    <!--property ReloadResult is not documented!-->
+
+    <!--property CleanResult is not documented!-->
+
+    <!--property USBFunctionDescriptors is not documented!-->
+
+    <!--property USBFunctionStrings is not documented!-->
+
+    <!--property UID is not documented!-->
+
+    <!--property GID is not documented!-->
+
+    <!--property NRestarts is not documented!-->
+
+    <!--property OOMPolicy is not documented!-->
+
+    <!--property OpenFile is not documented!-->
+
+    <!--property ReloadSignal is not documented!-->
+
+    <!--property ExecCondition is not documented!-->
+
+    <!--property ExecConditionEx is not documented!-->
+
+    <!--property ExecStartPreEx is not documented!-->
+
+    <!--property ExecStartEx is not documented!-->
+
+    <!--property ExecStartPostEx is not documented!-->
+
+    <!--property ExecReloadEx is not documented!-->
+
+    <!--property ExecStopEx is not documented!-->
+
+    <!--property ExecStopPost is not documented!-->
+
+    <!--property ExecStopPostEx is not documented!-->
+
+    <!--property Slice is not documented!-->
+
+    <!--property ControlGroupId is not documented!-->
+
+    <!--property MemoryCurrent is not documented!-->
+
+    <!--property MemoryPeak is not documented!-->
+
+    <!--property MemorySwapCurrent is not documented!-->
+
+    <!--property MemorySwapPeak is not documented!-->
+
+    <!--property MemoryZSwapCurrent is not documented!-->
+
+    <!--property CPUUsageNSec is not documented!-->
+
+    <!--property EffectiveCPUs is not documented!-->
+
+    <!--property EffectiveMemoryNodes is not documented!-->
+
+    <!--property TasksCurrent is not documented!-->
+
+    <!--property IPIngressBytes is not documented!-->
+
+    <!--property IPIngressPackets is not documented!-->
+
+    <!--property IPEgressBytes is not documented!-->
+
+    <!--property IPEgressPackets is not documented!-->
+
+    <!--property IOReadBytes is not documented!-->
+
+    <!--property IOReadOperations is not documented!-->
+
+    <!--property IOWriteBytes is not documented!-->
+
+    <!--property IOWriteOperations is not documented!-->
+
+    <!--property Delegate is not documented!-->
+
+    <!--property DelegateControllers is not documented!-->
+
+    <!--property CPUAccounting is not documented!-->
+
+    <!--property CPUWeight is not documented!-->
+
+    <!--property StartupCPUWeight is not documented!-->
+
+    <!--property CPUShares is not documented!-->
+
+    <!--property StartupCPUShares is not documented!-->
+
+    <!--property CPUQuotaPerSecUSec is not documented!-->
+
+    <!--property CPUQuotaPeriodUSec is not documented!-->
+
+    <!--property AllowedCPUs is not documented!-->
+
+    <!--property StartupAllowedCPUs is not documented!-->
+
+    <!--property AllowedMemoryNodes is not documented!-->
+
+    <!--property StartupAllowedMemoryNodes is not documented!-->
+
+    <!--property IOAccounting is not documented!-->
+
+    <!--property IOWeight is not documented!-->
+
+    <!--property StartupIOWeight is not documented!-->
+
+    <!--property IODeviceWeight is not documented!-->
+
+    <!--property IOReadBandwidthMax is not documented!-->
+
+    <!--property IOWriteBandwidthMax is not documented!-->
+
+    <!--property IOReadIOPSMax is not documented!-->
+
+    <!--property IOWriteIOPSMax is not documented!-->
+
+    <!--property IODeviceLatencyTargetUSec is not documented!-->
+
+    <!--property BlockIOAccounting is not documented!-->
+
+    <!--property BlockIOWeight is not documented!-->
+
+    <!--property StartupBlockIOWeight is not documented!-->
+
+    <!--property BlockIODeviceWeight is not documented!-->
+
+    <!--property BlockIOReadBandwidth is not documented!-->
+
+    <!--property BlockIOWriteBandwidth is not documented!-->
+
+    <!--property MemoryAccounting is not documented!-->
+
+    <!--property DefaultMemoryLow is not documented!-->
+
+    <!--property DefaultStartupMemoryLow is not documented!-->
+
+    <!--property DefaultMemoryMin is not documented!-->
+
+    <!--property MemoryMin is not documented!-->
+
+    <!--property MemoryLow is not documented!-->
+
+    <!--property StartupMemoryLow is not documented!-->
+
+    <!--property MemoryHigh is not documented!-->
+
+    <!--property StartupMemoryHigh is not documented!-->
+
+    <!--property MemoryMax is not documented!-->
+
+    <!--property StartupMemoryMax is not documented!-->
+
+    <!--property MemorySwapMax is not documented!-->
+
+    <!--property StartupMemorySwapMax is not documented!-->
+
+    <!--property MemoryZSwapMax is not documented!-->
+
+    <!--property StartupMemoryZSwapMax is not documented!-->
+
+    <!--property MemoryLimit is not documented!-->
+
+    <!--property DevicePolicy is not documented!-->
+
+    <!--property DeviceAllow is not documented!-->
+
+    <!--property TasksAccounting is not documented!-->
+
+    <!--property TasksMax is not documented!-->
+
+    <!--property IPAccounting is not documented!-->
+
+    <!--property IPAddressAllow is not documented!-->
+
+    <!--property IPAddressDeny is not documented!-->
+
+    <!--property IPIngressFilterPath is not documented!-->
+
+    <!--property IPEgressFilterPath is not documented!-->
+
+    <!--property DisableControllers is not documented!-->
+
+    <!--property ManagedOOMSwap is not documented!-->
+
+    <!--property ManagedOOMMemoryPressure is not documented!-->
+
+    <!--property ManagedOOMMemoryPressureLimit is not documented!-->
+
+    <!--property ManagedOOMPreference is not documented!-->
+
+    <!--property BPFProgram is not documented!-->
+
+    <!--property SocketBindAllow is not documented!-->
+
+    <!--property SocketBindDeny is not documented!-->
+
+    <!--property RestrictNetworkInterfaces is not documented!-->
+
+    <!--property MemoryPressureWatch is not documented!-->
+
+    <!--property MemoryPressureThresholdUSec is not documented!-->
+
+    <!--property NFTSet is not documented!-->
+
+    <!--property CoredumpReceive is not documented!-->
+
+    <!--property EnvironmentFiles is not documented!-->
+
+    <!--property PassEnvironment is not documented!-->
+
+    <!--property UnsetEnvironment is not documented!-->
+
+    <!--property UMask is not documented!-->
+
+    <!--property LimitCPUSoft is not documented!-->
+
+    <!--property LimitFSIZE is not documented!-->
+
+    <!--property LimitFSIZESoft is not documented!-->
+
+    <!--property LimitDATA is not documented!-->
+
+    <!--property LimitDATASoft is not documented!-->
+
+    <!--property LimitSTACK is not documented!-->
+
+    <!--property LimitSTACKSoft is not documented!-->
+
+    <!--property LimitCORE is not documented!-->
+
+    <!--property LimitCORESoft is not documented!-->
+
+    <!--property LimitRSS is not documented!-->
+
+    <!--property LimitRSSSoft is not documented!-->
+
+    <!--property LimitNOFILE is not documented!-->
+
+    <!--property LimitNOFILESoft is not documented!-->
+
+    <!--property LimitAS is not documented!-->
+
+    <!--property LimitASSoft is not documented!-->
+
+    <!--property LimitNPROC is not documented!-->
+
+    <!--property LimitNPROCSoft is not documented!-->
+
+    <!--property LimitMEMLOCK is not documented!-->
+
+    <!--property LimitMEMLOCKSoft is not documented!-->
+
+    <!--property LimitLOCKS is not documented!-->
+
+    <!--property LimitLOCKSSoft is not documented!-->
+
+    <!--property LimitSIGPENDING is not documented!-->
+
+    <!--property LimitSIGPENDINGSoft is not documented!-->
+
+    <!--property LimitMSGQUEUE is not documented!-->
+
+    <!--property LimitMSGQUEUESoft is not documented!-->
+
+    <!--property LimitNICE is not documented!-->
+
+    <!--property LimitNICESoft is not documented!-->
+
+    <!--property LimitRTPRIO is not documented!-->
+
+    <!--property LimitRTPRIOSoft is not documented!-->
+
+    <!--property LimitRTTIME is not documented!-->
+
+    <!--property LimitRTTIMESoft is not documented!-->
+
+    <!--property WorkingDirectory is not documented!-->
+
+    <!--property RootHashPath is not documented!-->
+
+    <!--property RootHashSignaturePath is not documented!-->
+
+    <!--property RootEphemeral is not documented!-->
+
+    <!--property OOMScoreAdjust is not documented!-->
+
+    <!--property CoredumpFilter is not documented!-->
+
+    <!--property Nice is not documented!-->
+
+    <!--property IOSchedulingClass is not documented!-->
+
+    <!--property IOSchedulingPriority is not documented!-->
+
+    <!--property CPUSchedulingPolicy is not documented!-->
+
+    <!--property CPUSchedulingPriority is not documented!-->
+
+    <!--property CPUAffinity is not documented!-->
+
+    <!--property CPUAffinityFromNUMA is not documented!-->
+
+    <!--property NUMAPolicy is not documented!-->
+
+    <!--property NUMAMask is not documented!-->
+
+    <!--property TimerSlackNSec is not documented!-->
+
+    <!--property CPUSchedulingResetOnFork is not documented!-->
+
+    <!--property NonBlocking is not documented!-->
+
+    <!--property StandardInput is not documented!-->
+
+    <!--property StandardInputFileDescriptorName is not documented!-->
+
+    <!--property StandardInputData is not documented!-->
+
+    <!--property StandardOutput is not documented!-->
+
+    <!--property StandardOutputFileDescriptorName is not documented!-->
+
+    <!--property StandardError is not documented!-->
+
+    <!--property StandardErrorFileDescriptorName is not documented!-->
+
+    <!--property TTYPath is not documented!-->
+
+    <!--property TTYReset is not documented!-->
+
+    <!--property TTYVHangup is not documented!-->
+
+    <!--property TTYVTDisallocate is not documented!-->
+
+    <!--property TTYRows is not documented!-->
+
+    <!--property TTYColumns is not documented!-->
+
+    <!--property SyslogPriority is not documented!-->
+
+    <!--property SyslogIdentifier is not documented!-->
+
+    <!--property SyslogLevelPrefix is not documented!-->
+
+    <!--property SyslogLevel is not documented!-->
+
+    <!--property SyslogFacility is not documented!-->
+
+    <!--property LogLevelMax is not documented!-->
+
+    <!--property LogRateLimitIntervalUSec is not documented!-->
+
+    <!--property LogRateLimitBurst is not documented!-->
+
+    <!--property LogExtraFields is not documented!-->
+
+    <!--property LogFilterPatterns is not documented!-->
+
+    <!--property LogNamespace is not documented!-->
+
+    <!--property AmbientCapabilities is not documented!-->
+
+    <!--property User is not documented!-->
+
+    <!--property Group is not documented!-->
+
+    <!--property DynamicUser is not documented!-->
+
+    <!--property SetLoginEnvironment is not documented!-->
+
+    <!--property RemoveIPC is not documented!-->
+
+    <!--property SetCredential is not documented!-->
+
+    <!--property SetCredentialEncrypted is not documented!-->
+
+    <!--property LoadCredential is not documented!-->
+
+    <!--property LoadCredentialEncrypted is not documented!-->
+
+    <!--property ImportCredential is not documented!-->
+
+    <!--property SupplementaryGroups is not documented!-->
+
+    <!--property PAMName is not documented!-->
+
+    <!--property ReadWritePaths is not documented!-->
+
+    <!--property ReadOnlyPaths is not documented!-->
+
+    <!--property InaccessiblePaths is not documented!-->
+
+    <!--property ExecPaths is not documented!-->
+
+    <!--property NoExecPaths is not documented!-->
+
+    <!--property ExecSearchPath is not documented!-->
+
+    <!--property PrivateTmp is not documented!-->
+
+    <!--property PrivateDevices is not documented!-->
+
+    <!--property ProtectClock is not documented!-->
+
+    <!--property ProtectKernelTunables is not documented!-->
+
+    <!--property ProtectKernelModules is not documented!-->
+
+    <!--property ProtectKernelLogs is not documented!-->
+
+    <!--property ProtectControlGroups is not documented!-->
+
+    <!--property PrivateNetwork is not documented!-->
+
+    <!--property PrivateUsers is not documented!-->
+
+    <!--property PrivateMounts is not documented!-->
+
+    <!--property PrivateIPC is not documented!-->
+
+    <!--property ProtectHome is not documented!-->
+
+    <!--property ProtectSystem is not documented!-->
+
+    <!--property SameProcessGroup is not documented!-->
+
+    <!--property UtmpIdentifier is not documented!-->
+
+    <!--property UtmpMode is not documented!-->
+
+    <!--property SELinuxContext is not documented!-->
+
+    <!--property AppArmorProfile is not documented!-->
+
+    <!--property SmackProcessLabel is not documented!-->
+
+    <!--property IgnoreSIGPIPE is not documented!-->
+
+    <!--property NoNewPrivileges is not documented!-->
+
+    <!--property SystemCallFilter is not documented!-->
+
+    <!--property SystemCallArchitectures is not documented!-->
+
+    <!--property SystemCallErrorNumber is not documented!-->
+
+    <!--property SystemCallLog is not documented!-->
+
+    <!--property Personality is not documented!-->
+
+    <!--property LockPersonality is not documented!-->
+
+    <!--property RestrictAddressFamilies is not documented!-->
+
+    <!--property RuntimeDirectoryPreserve is not documented!-->
+
+    <!--property RuntimeDirectoryMode is not documented!-->
+
+    <!--property StateDirectoryMode is not documented!-->
+
+    <!--property CacheDirectoryMode is not documented!-->
+
+    <!--property LogsDirectoryMode is not documented!-->
+
+    <!--property ConfigurationDirectoryMode is not documented!-->
+
+    <!--property ConfigurationDirectory is not documented!-->
+
+    <!--property TimeoutCleanUSec is not documented!-->
+
+    <!--property MemoryDenyWriteExecute is not documented!-->
+
+    <!--property RestrictRealtime is not documented!-->
+
+    <!--property RestrictSUIDSGID is not documented!-->
+
+    <!--property RestrictNamespaces is not documented!-->
+
+    <!--property RestrictFileSystems is not documented!-->
+
+    <!--property BindPaths is not documented!-->
+
+    <!--property BindReadOnlyPaths is not documented!-->
+
+    <!--property TemporaryFileSystem is not documented!-->
+
+    <!--property MountAPIVFS is not documented!-->
+
+    <!--property KeyringMode is not documented!-->
+
+    <!--property ProtectProc is not documented!-->
+
+    <!--property ProcSubset is not documented!-->
+
+    <!--property ProtectHostname is not documented!-->
+
+    <!--property MemoryKSM is not documented!-->
+
+    <!--property NetworkNamespacePath is not documented!-->
+
+    <!--property IPCNamespacePath is not documented!-->
+
+    <!--property RootImagePolicy is not documented!-->
+
+    <!--property MountImagePolicy is not documented!-->
+
+    <!--property ExtensionImagePolicy is not documented!-->
+
+    <!--property KillMode is not documented!-->
+
+    <!--property KillSignal is not documented!-->
+
+    <!--property RestartKillSignal is not documented!-->
+
+    <!--property FinalKillSignal is not documented!-->
+
+    <!--property SendSIGKILL is not documented!-->
+
+    <!--property SendSIGHUP is not documented!-->
+
+    <!--property WatchdogSignal is not documented!-->
+
+    <!--Autogenerated cross-references for systemd.directives, do not edit-->
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Unit"/>
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Service"/>
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Unit"/>
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Service"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="BindMount()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="MountImage()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="DumpFileDescriptorStore()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="GetProcesses()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="AttachProcesses()"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Type"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ExitType"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Restart"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RestartMode"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="PIDFile"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="NotifyAccess"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RestartUSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RestartSteps"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RestartMaxDelayUSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RestartUSecNext"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TimeoutStartUSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TimeoutStopUSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TimeoutAbortUSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TimeoutStartFailureMode"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TimeoutStopFailureMode"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RuntimeMaxUSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RuntimeRandomizedExtraUSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="WatchdogUSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="WatchdogTimestamp"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="WatchdogTimestampMonotonic"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RootDirectoryStartOnly"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RemainAfterExit"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="GuessMainPID"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RestartPreventExitStatus"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RestartForceExitStatus"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SuccessExitStatus"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MainPID"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ControlPID"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="BusName"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="FileDescriptorStoreMax"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="NFileDescriptorStore"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="FileDescriptorStorePreserve"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StatusText"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StatusErrno"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Result"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ReloadResult"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CleanResult"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="USBFunctionDescriptors"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="USBFunctionStrings"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="UID"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="GID"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="NRestarts"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="OOMPolicy"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="OpenFile"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ReloadSignal"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ExecMainStartTimestamp"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ExecMainStartTimestampMonotonic"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ExecMainExitTimestamp"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ExecMainExitTimestampMonotonic"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ExecMainPID"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ExecMainCode"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ExecMainStatus"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ExecCondition"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ExecConditionEx"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ExecStartPre"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ExecStartPreEx"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ExecStart"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ExecStartEx"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ExecStartPost"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ExecStartPostEx"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ExecReload"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ExecReloadEx"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ExecStop"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ExecStopEx"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ExecStopPost"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ExecStopPostEx"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Slice"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ControlGroup"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ControlGroupId"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryCurrent"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryPeak"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemorySwapCurrent"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemorySwapPeak"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryZSwapCurrent"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryAvailable"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CPUUsageNSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="EffectiveCPUs"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="EffectiveMemoryNodes"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TasksCurrent"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IPIngressBytes"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IPIngressPackets"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IPEgressBytes"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IPEgressPackets"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IOReadBytes"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IOReadOperations"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IOWriteBytes"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IOWriteOperations"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Delegate"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DelegateControllers"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DelegateSubgroup"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CPUAccounting"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CPUWeight"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StartupCPUWeight"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CPUShares"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StartupCPUShares"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CPUQuotaPerSecUSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CPUQuotaPeriodUSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="AllowedCPUs"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StartupAllowedCPUs"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="AllowedMemoryNodes"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StartupAllowedMemoryNodes"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IOAccounting"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IOWeight"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StartupIOWeight"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IODeviceWeight"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IOReadBandwidthMax"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IOWriteBandwidthMax"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IOReadIOPSMax"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IOWriteIOPSMax"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IODeviceLatencyTargetUSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="BlockIOAccounting"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="BlockIOWeight"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StartupBlockIOWeight"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="BlockIODeviceWeight"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="BlockIOReadBandwidth"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="BlockIOWriteBandwidth"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryAccounting"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DefaultMemoryLow"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DefaultStartupMemoryLow"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DefaultMemoryMin"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryMin"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryLow"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StartupMemoryLow"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryHigh"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StartupMemoryHigh"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryMax"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StartupMemoryMax"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemorySwapMax"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StartupMemorySwapMax"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryZSwapMax"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StartupMemoryZSwapMax"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryLimit"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DevicePolicy"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DeviceAllow"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TasksAccounting"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TasksMax"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IPAccounting"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IPAddressAllow"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IPAddressDeny"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IPIngressFilterPath"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IPEgressFilterPath"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DisableControllers"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ManagedOOMSwap"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ManagedOOMMemoryPressure"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ManagedOOMMemoryPressureLimit"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ManagedOOMPreference"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="BPFProgram"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SocketBindAllow"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SocketBindDeny"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RestrictNetworkInterfaces"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryPressureWatch"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryPressureThresholdUSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="NFTSet"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CoredumpReceive"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Environment"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="EnvironmentFiles"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="PassEnvironment"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="UnsetEnvironment"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="UMask"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitCPU"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitCPUSoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitFSIZE"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitFSIZESoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitDATA"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitDATASoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitSTACK"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitSTACKSoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitCORE"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitCORESoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitRSS"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitRSSSoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitNOFILE"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitNOFILESoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitAS"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitASSoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitNPROC"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitNPROCSoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitMEMLOCK"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitMEMLOCKSoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitLOCKS"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitLOCKSSoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitSIGPENDING"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitSIGPENDINGSoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitMSGQUEUE"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitMSGQUEUESoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitNICE"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitNICESoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitRTPRIO"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitRTPRIOSoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitRTTIME"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitRTTIMESoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="WorkingDirectory"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RootDirectory"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RootImage"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RootImageOptions"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RootHash"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RootHashPath"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RootHashSignature"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RootHashSignaturePath"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RootVerity"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RootEphemeral"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ExtensionDirectories"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ExtensionImages"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MountImages"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="OOMScoreAdjust"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CoredumpFilter"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Nice"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IOSchedulingClass"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IOSchedulingPriority"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CPUSchedulingPolicy"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CPUSchedulingPriority"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CPUAffinity"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CPUAffinityFromNUMA"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="NUMAPolicy"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="NUMAMask"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TimerSlackNSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CPUSchedulingResetOnFork"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="NonBlocking"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StandardInput"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StandardInputFileDescriptorName"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StandardInputData"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StandardOutput"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StandardOutputFileDescriptorName"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StandardError"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StandardErrorFileDescriptorName"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TTYPath"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TTYReset"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TTYVHangup"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TTYVTDisallocate"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TTYRows"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TTYColumns"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SyslogPriority"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SyslogIdentifier"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SyslogLevelPrefix"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SyslogLevel"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SyslogFacility"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LogLevelMax"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LogRateLimitIntervalUSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LogRateLimitBurst"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LogExtraFields"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LogFilterPatterns"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LogNamespace"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SecureBits"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CapabilityBoundingSet"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="AmbientCapabilities"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="User"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Group"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DynamicUser"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SetLoginEnvironment"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RemoveIPC"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SetCredential"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SetCredentialEncrypted"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LoadCredential"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LoadCredentialEncrypted"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ImportCredential"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SupplementaryGroups"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="PAMName"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ReadWritePaths"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ReadOnlyPaths"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="InaccessiblePaths"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ExecPaths"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="NoExecPaths"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ExecSearchPath"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MountFlags"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="PrivateTmp"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="PrivateDevices"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ProtectClock"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ProtectKernelTunables"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ProtectKernelModules"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ProtectKernelLogs"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ProtectControlGroups"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="PrivateNetwork"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="PrivateUsers"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="PrivateMounts"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="PrivateIPC"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ProtectHome"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ProtectSystem"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SameProcessGroup"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="UtmpIdentifier"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="UtmpMode"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SELinuxContext"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="AppArmorProfile"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SmackProcessLabel"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IgnoreSIGPIPE"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="NoNewPrivileges"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SystemCallFilter"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SystemCallArchitectures"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SystemCallErrorNumber"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SystemCallLog"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Personality"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LockPersonality"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RestrictAddressFamilies"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RuntimeDirectorySymlink"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RuntimeDirectoryPreserve"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RuntimeDirectoryMode"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RuntimeDirectory"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StateDirectorySymlink"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StateDirectoryMode"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StateDirectory"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CacheDirectorySymlink"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CacheDirectoryMode"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CacheDirectory"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LogsDirectorySymlink"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LogsDirectoryMode"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LogsDirectory"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ConfigurationDirectoryMode"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ConfigurationDirectory"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TimeoutCleanUSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryDenyWriteExecute"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RestrictRealtime"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RestrictSUIDSGID"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RestrictNamespaces"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RestrictFileSystems"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="BindPaths"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="BindReadOnlyPaths"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TemporaryFileSystem"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MountAPIVFS"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="KeyringMode"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ProtectProc"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ProcSubset"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ProtectHostname"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryKSM"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="NetworkNamespacePath"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IPCNamespacePath"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RootImagePolicy"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MountImagePolicy"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ExtensionImagePolicy"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="KillMode"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="KillSignal"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RestartKillSignal"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="FinalKillSignal"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SendSIGKILL"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SendSIGHUP"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="WatchdogSignal"/>
+
+    <!--End of Autogenerated section-->
+
+    <refsect2>
+      <title>Methods</title>
+
+      <para><function>BindMount()</function> and <function>MountImage()</function> implement the same operations
+      as the respective methods on the <interfacename>Manager</interfacename> object (see above). However, these
+      methods operate on the service object and hence do not take a unit name parameter. Invoking the methods
+      directly on the Manager object has the advantage of not requiring a <function>GetUnit()</function> call
+      to get the unit object for a specific unit name. Calling the methods on the Manager object is hence a round
+      trip optimization.</para>
+
+      <para><function>DumpFileDescriptorStore()</function> returns an array with information about the file
+      descriptors currently in the file descriptor store of the service. Each entry consists of a file
+      descriptor name (i.e. the <varname>FDNAME=</varname> field), the file descriptor inode type and access
+      mode as integer (i.e. a <type>mode_t</type> value, flags such as <constant>S_IFREG</constant>,
+      <constant>S_IRUSR</constant>, …), the major and minor numbers of the device number of the file system
+      backing the inode of the file descriptor, the inode number, the major and minor numbers of the device
+      number if this refers to a character or block device node, a file system path pointing to the inode,
+      and the file descriptor flags (i.e. <constant>O_RDWR</constant>, <constant>O_RDONLY</constant>,
+      …).</para>
+    </refsect2>
+
+    <refsect2>
+      <title>Properties</title>
+
+      <para>Most properties of the Service interface map directly to the corresponding settings in service
+      unit files. For the sake of brevity, here's a list of all exceptions only:</para>
+
+      <para><varname>TimeoutStartUSec</varname>, <varname>TimeoutStopUSec</varname> and
+      <varname>TimeoutAbortUSec</varname> contain the start, stop and abort timeouts, in microseconds. Note
+      the slight difference in naming when compared to the matching unit file settings (see
+      <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>7</manvolnum></citerefentry>):
+      these bus properties strictly use microseconds (and thus are suffixed <varname>…USec</varname>) while
+      the unit file settings default to a time unit of seconds (and thus are suffixed
+      <varname>…Sec</varname>), unless a different unit is explicitly specified. This reflects that fact that
+      internally the service manager deals in microsecond units only, and the bus properties are a relatively
+      low-level (binary) concept exposing this. The unit file settings on the other hand are relatively
+      high-level (string-based) concepts and thus support more user friendly time specifications which
+      default to second time units but allow other units too, if specified.</para>
+
+      <para><varname>WatchdogTimestamp</varname> and <varname>WatchdogTimestampMonotonic</varname> contain
+      <constant>CLOCK_REALTIME</constant>/<constant>CLOCK_MONOTONIC</constant> microsecond timestamps of the
+      last watchdog ping received from the service, or 0 if none was ever received.</para>
+
+      <para><varname>ExecStartPre</varname>, <varname>ExecStart</varname>, <varname>ExecStartPost</varname>,
+      <varname>ExecReload</varname>, <varname>ExecStop</varname>, and <varname>ExecStop</varname> are arrays
+      of structures where each struct contains: the binary path to execute; an array with all arguments to
+      pass to the executed command, starting with argument 0; a boolean whether it should be considered a
+      failure if the process exits uncleanly; two pairs of
+      <constant>CLOCK_REALTIME</constant>/<constant>CLOCK_MONOTONIC</constant> microsecond timestamps when
+      the process began and finished running the last time, or 0 if it never ran or never finished running;
+      the PID of the process, or 0 if it has not run yet; the exit code and status of the last run. This
+      field hence maps more or less to the corresponding setting in the service unit file but is augmented
+      with runtime data.</para>
+
+      <para><varname>LimitCPU</varname> (and related properties) map more or less directly to the
+      corresponding settings in the service unit files except that if they aren't set, their value is
+      18446744073709551615 (i.e. -1).</para>
+
+      <para><varname>Capabilities</varname> contains the configured capabilities, as formatted with
+      <citerefentry project="man-pages"><refentrytitle>cap_to_text</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+      </para>
+
+      <para><varname>SecureBits</varname>, <varname>CapabilityBoundingSet</varname>,
+      <varname>MountFlags</varname> also correspond to the configured settings of the unit files, but
+      instead of being formatted as strings, they are encoded as the actual binary flags they are.
+      </para>
+
+      <para><varname>ExecMainStartTimestamp</varname>, <varname>ExecMainStartTimestampMonotonic</varname>,
+      <varname>ExecMainExitTimestamp</varname>, <varname>ExecMainExitTimestampMonotonic</varname>,
+      <varname>ExecMainPID</varname>, <varname>ExecMainCode</varname>, <varname>ExecMainStatus</varname>
+      contain information about the main process of the service as far as it is known. This is often the same
+      runtime information that is stored in <varname>ExecStart</varname>. However, it deviates for
+      <varname>Type=forking</varname> services where the main process of the service is not forked off
+      systemd directly. These fields either contain information of the last run of the process or of the
+      current running process.</para>
+
+      <para><varname>MainPID</varname> and <varname>ControlPID</varname> contain the main and control PID of
+      the service. The main PID is the current main PID of the service and is 0 when the service currently
+      has no main PID. The control PID is the PID of the current start/stop/reload process running and is 0
+      if no such process is currently running. That means that <varname>ExecMainPID</varname> and
+      <varname>MainPID</varname> differ in the way that the latter immediately reflects whether a main
+      process is currently running while the latter possible contains information collected from the last run
+      even if the process is no longer around.</para>
+
+      <para><varname>StatusText</varname> contains the status text passed to the service manager via a call
+      to
+      <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+      This may be used by services to inform the service manager about its internal state with a nice
+      explanatory string.</para>
+
+      <para><varname>Result</varname> encodes the execution result of the last run of the service. It is
+      useful to determine the reason a service failed if it is in the <literal>failed</literal> state (see
+      <varname>ActiveState</varname> above). The following values are currently known:
+      <literal>success</literal> is set if the unit didn't fail. <literal>resources</literal> indicates that
+      not enough resources were available to fork off and execute the service
+      processes. <literal>timeout</literal> indicates that a timeout occurred while executing a service
+      operation. <literal>exit-code</literal> indicates that a service process exited with an unclean exit
+      code. <literal>signal</literal> indicates that a service process exited with an uncaught
+      signal. <literal>core-dump</literal> indicates that a service process exited uncleanly and dumped
+      core. <literal>watchdog</literal> indicates that a service did not send out watchdog ping messages
+      often enough. <literal>start-limit</literal> indicates that a service has been started too frequently
+      in a specific time frame (as configured in <varname>StartLimitInterval</varname>,
+      <varname>StartLimitBurst</varname>).</para>
+
+      <para><varname>ControlGroup</varname> indicates the control group path the processes of this service
+      unit are placed in.</para>
+
+      <para>The following properties map 1:1 to corresponding settings in the unit file:
+      <varname>RootDirectory</varname>
+      <varname>RootImage</varname>
+      <varname>RootImageOptions</varname>
+      <varname>RootVerity</varname>
+      <varname>RootHash</varname>
+      <varname>RootHashSignature</varname>
+      <varname>MountImages</varname>
+      <varname>ExtensionImages</varname>
+      <varname>ExtensionDirectories</varname>
+      see systemd.exec(5) for their meaning.</para>
+
+      <para><varname>MemoryAvailable</varname> takes into account unit's and parents' <literal>MemoryMax</literal>
+      or <literal>MemoryHigh</literal> or physically available RAM versus given level's memory consumption
+      and takes minimum. Beware that other units below the tightest parent slice may consume the memory quicker
+      and less than reported value would remain for own allocation.
+      It works better in conjunction with <varname>MemoryAccounting=yes</varname> on involved units.</para>
+
+      <para><varname>DelegateSubgroup</varname> contains the cgroup subgroup to place invoked unit processes
+      in. As configured by the option of the same name in unit files. This is set to the empty string when it
+      does not apply or no subgroup has been configured.</para>
+
+      <para><varname>RuntimeDirectorySymlink</varname>, <varname>StateDirectorySymlink</varname>,
+      <varname>CacheDirectorySymlink</varname> and  <varname>LogsDirectorySymlink</varname> respectively
+      implement the destination parameter of the unit files settings <varname>RuntimeDirectory</varname>,
+      <varname>StateDirectory</varname>, <varname>CacheDirectory</varname> and <varname>LogsDirectory</varname>,
+      which will create a symlink of the given name to the respective directory. The messages take an unused
+      <varname>flags</varname> parameter, reserved for future backward-compatible changes.</para>
+    </refsect2>
+  </refsect1>
+
+  <refsect1>
+    <title>Socket Unit Objects</title>
+
+    <programlisting executable="systemd" node="/org/freedesktop/systemd1/unit/avahi_2ddaemon_2esocket" interface="org.freedesktop.systemd1.Socket">
+node /org/freedesktop/systemd1/unit/avahi_2ddaemon_2esocket {
+  interface org.freedesktop.systemd1.Socket {
+    methods:
+      GetProcesses(out a(sus) processes);
+      AttachProcesses(in  s subcgroup,
+                      in  au pids);
+    properties:
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s BindIPv6Only = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly u Backlog = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t TimeoutUSec = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s BindToDevice = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s SocketUser = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s SocketGroup = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly u SocketMode = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly u DirectoryMode = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b Accept = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b FlushPending = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b Writable = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b KeepAlive = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t KeepAliveTimeUSec = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t KeepAliveIntervalUSec = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly u KeepAliveProbes = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t DeferAcceptUSec = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b NoDelay = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i Priority = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t ReceiveBuffer = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t SendBuffer = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i IPTOS = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i IPTTL = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t PipeSize = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b FreeBind = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b Transparent = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b Broadcast = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b PassCredentials = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b PassSecurity = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b PassPacketInfo = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s Timestamping = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b RemoveOnStop = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly a(ss) Listen = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as Symlinks = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i Mark = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly u MaxConnections = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly u MaxConnectionsPerSource = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly x MessageQueueMaxMessages = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly x MessageQueueMessageSize = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s TCPCongestion = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b ReusePort = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s SmackLabel = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s SmackLabelIPIn = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s SmackLabelIPOut = '...';
+      readonly u ControlPID = ...;
+      readonly s Result = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly u NConnections = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly u NAccepted = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly u NRefused = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s FileDescriptorName = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i SocketProtocol = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t TriggerLimitIntervalUSec = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly u TriggerLimitBurst = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t PollLimitIntervalUSec = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly u PollLimitBurst = ...;
+      readonly u UID = ...;
+      readonly u GID = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates")
+      readonly a(sasbttttuii) ExecStartPre = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates")
+      readonly a(sasbttttuii) ExecStartPost = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates")
+      readonly a(sasbttttuii) ExecStopPre = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates")
+      readonly a(sasbttttuii) ExecStopPost = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s Slice = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s ControlGroup = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t ControlGroupId = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemoryCurrent = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemoryPeak = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemorySwapCurrent = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemorySwapPeak = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemoryZSwapCurrent = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemoryAvailable = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t CPUUsageNSec = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly ay EffectiveCPUs = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly ay EffectiveMemoryNodes = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t TasksCurrent = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t IPIngressBytes = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t IPIngressPackets = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t IPEgressBytes = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t IPEgressPackets = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t IOReadBytes = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t IOReadOperations = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t IOWriteBytes = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t IOWriteOperations = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly b Delegate = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly as DelegateControllers = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s DelegateSubgroup = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly b CPUAccounting = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t CPUWeight = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t StartupCPUWeight = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t CPUShares = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t StartupCPUShares = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t CPUQuotaPerSecUSec = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t CPUQuotaPeriodUSec = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly ay AllowedCPUs = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly ay StartupAllowedCPUs = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly ay AllowedMemoryNodes = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly ay StartupAllowedMemoryNodes = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly b IOAccounting = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t IOWeight = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t StartupIOWeight = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(st) IODeviceWeight = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(st) IOReadBandwidthMax = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(st) IOWriteBandwidthMax = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(st) IOReadIOPSMax = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(st) IOWriteIOPSMax = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(st) IODeviceLatencyTargetUSec = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly b BlockIOAccounting = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t BlockIOWeight = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t StartupBlockIOWeight = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(st) BlockIODeviceWeight = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(st) BlockIOReadBandwidth = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(st) BlockIOWriteBandwidth = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly b MemoryAccounting = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t DefaultMemoryLow = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t DefaultStartupMemoryLow = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t DefaultMemoryMin = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemoryMin = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemoryLow = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t StartupMemoryLow = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemoryHigh = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t StartupMemoryHigh = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemoryMax = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t StartupMemoryMax = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemorySwapMax = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t StartupMemorySwapMax = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemoryZSwapMax = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t StartupMemoryZSwapMax = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemoryLimit = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s DevicePolicy = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(ss) DeviceAllow = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly b TasksAccounting = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t TasksMax = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly b IPAccounting = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(iayu) IPAddressAllow = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(iayu) IPAddressDeny = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly as IPIngressFilterPath = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly as IPEgressFilterPath = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly as DisableControllers = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s ManagedOOMSwap = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s ManagedOOMMemoryPressure = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly u ManagedOOMMemoryPressureLimit = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s ManagedOOMPreference = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(ss) BPFProgram = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(iiqq) SocketBindAllow = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(iiqq) SocketBindDeny = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly (bas) RestrictNetworkInterfaces = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s MemoryPressureWatch = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemoryPressureThresholdUSec = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(iiss) NFTSet = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly b CoredumpReceive = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as Environment = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly a(sb) EnvironmentFiles = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as PassEnvironment = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as UnsetEnvironment = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly u UMask = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitCPU = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitCPUSoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitFSIZE = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitFSIZESoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitDATA = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitDATASoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitSTACK = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitSTACKSoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitCORE = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitCORESoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitRSS = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitRSSSoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitNOFILE = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitNOFILESoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitAS = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitASSoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitNPROC = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitNPROCSoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitMEMLOCK = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitMEMLOCKSoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitLOCKS = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitLOCKSSoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitSIGPENDING = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitSIGPENDINGSoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitMSGQUEUE = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitMSGQUEUESoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitNICE = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitNICESoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitRTPRIO = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitRTPRIOSoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitRTTIME = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitRTTIMESoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s WorkingDirectory = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s RootDirectory = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s RootImage = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly a(ss) RootImageOptions = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly ay RootHash = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s RootHashPath = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly ay RootHashSignature = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s RootHashSignaturePath = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s RootVerity = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b RootEphemeral = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as ExtensionDirectories = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly a(sba(ss)) ExtensionImages = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly a(ssba(ss)) MountImages = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i OOMScoreAdjust = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t CoredumpFilter = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i Nice = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i IOSchedulingClass = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i IOSchedulingPriority = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i CPUSchedulingPolicy = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i CPUSchedulingPriority = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly ay CPUAffinity = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b CPUAffinityFromNUMA = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i NUMAPolicy = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly ay NUMAMask = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t TimerSlackNSec = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b CPUSchedulingResetOnFork = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b NonBlocking = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s StandardInput = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s StandardInputFileDescriptorName = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly ay StandardInputData = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s StandardOutput = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s StandardOutputFileDescriptorName = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s StandardError = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s StandardErrorFileDescriptorName = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s TTYPath = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b TTYReset = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b TTYVHangup = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b TTYVTDisallocate = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly q TTYRows = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly q TTYColumns = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i SyslogPriority = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s SyslogIdentifier = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b SyslogLevelPrefix = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i SyslogLevel = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i SyslogFacility = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i LogLevelMax = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LogRateLimitIntervalUSec = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly u LogRateLimitBurst = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly aay LogExtraFields = [[...], ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly a(bs) LogFilterPatterns = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s LogNamespace = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i SecureBits = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t CapabilityBoundingSet = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t AmbientCapabilities = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s User = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s Group = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b DynamicUser = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b SetLoginEnvironment = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b RemoveIPC = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly a(say) SetCredential = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly a(say) SetCredentialEncrypted = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly a(ss) LoadCredential = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly a(ss) LoadCredentialEncrypted = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as ImportCredential = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as SupplementaryGroups = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s PAMName = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as ReadWritePaths = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as ReadOnlyPaths = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as InaccessiblePaths = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as ExecPaths = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as NoExecPaths = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as ExecSearchPath = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t MountFlags = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b PrivateTmp = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b PrivateDevices = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b ProtectClock = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b ProtectKernelTunables = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b ProtectKernelModules = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b ProtectKernelLogs = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b ProtectControlGroups = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b PrivateNetwork = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b PrivateUsers = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b PrivateMounts = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b PrivateIPC = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s ProtectHome = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s ProtectSystem = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b SameProcessGroup = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s UtmpIdentifier = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s UtmpMode = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly (bs) SELinuxContext = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly (bs) AppArmorProfile = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly (bs) SmackProcessLabel = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b IgnoreSIGPIPE = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b NoNewPrivileges = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly (bas) SystemCallFilter = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as SystemCallArchitectures = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i SystemCallErrorNumber = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly (bas) SystemCallLog = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s Personality = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b LockPersonality = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly (bas) RestrictAddressFamilies = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly a(sst) RuntimeDirectorySymlink = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s RuntimeDirectoryPreserve = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly u RuntimeDirectoryMode = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as RuntimeDirectory = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly a(sst) StateDirectorySymlink = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly u StateDirectoryMode = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as StateDirectory = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly a(sst) CacheDirectorySymlink = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly u CacheDirectoryMode = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as CacheDirectory = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly a(sst) LogsDirectorySymlink = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly u LogsDirectoryMode = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as LogsDirectory = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly u ConfigurationDirectoryMode = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as ConfigurationDirectory = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t TimeoutCleanUSec = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b MemoryDenyWriteExecute = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b RestrictRealtime = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b RestrictSUIDSGID = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t RestrictNamespaces = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly (bas) RestrictFileSystems = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly a(ssbt) BindPaths = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly a(ssbt) BindReadOnlyPaths = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly a(ss) TemporaryFileSystem = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b MountAPIVFS = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s KeyringMode = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s ProtectProc = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s ProcSubset = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b ProtectHostname = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b MemoryKSM = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s NetworkNamespacePath = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s IPCNamespacePath = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s RootImagePolicy = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s MountImagePolicy = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s ExtensionImagePolicy = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s KillMode = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i KillSignal = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i RestartKillSignal = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i FinalKillSignal = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b SendSIGKILL = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b SendSIGHUP = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i WatchdogSignal = ...;
+  };
+  interface org.freedesktop.DBus.Peer { ... };
+  interface org.freedesktop.DBus.Introspectable { ... };
+  interface org.freedesktop.DBus.Properties { ... };
+  interface org.freedesktop.systemd1.Unit { ... };
+};
+    </programlisting>
+
+    <!--method GetProcesses is not documented!-->
+
+    <!--method AttachProcesses is not documented!-->
+
+    <!--property BindIPv6Only is not documented!-->
+
+    <!--property Backlog is not documented!-->
+
+    <!--property TimeoutUSec is not documented!-->
+
+    <!--property BindToDevice is not documented!-->
+
+    <!--property SocketUser is not documented!-->
+
+    <!--property SocketGroup is not documented!-->
+
+    <!--property SocketMode is not documented!-->
+
+    <!--property DirectoryMode is not documented!-->
+
+    <!--property Writable is not documented!-->
+
+    <!--property KeepAlive is not documented!-->
+
+    <!--property KeepAliveTimeUSec is not documented!-->
+
+    <!--property KeepAliveIntervalUSec is not documented!-->
+
+    <!--property KeepAliveProbes is not documented!-->
+
+    <!--property DeferAcceptUSec is not documented!-->
+
+    <!--property NoDelay is not documented!-->
+
+    <!--property Priority is not documented!-->
+
+    <!--property ReceiveBuffer is not documented!-->
+
+    <!--property SendBuffer is not documented!-->
+
+    <!--property IPTOS is not documented!-->
+
+    <!--property IPTTL is not documented!-->
+
+    <!--property PipeSize is not documented!-->
+
+    <!--property FreeBind is not documented!-->
+
+    <!--property Transparent is not documented!-->
+
+    <!--property Broadcast is not documented!-->
+
+    <!--property PassCredentials is not documented!-->
+
+    <!--property PassSecurity is not documented!-->
+
+    <!--property PassPacketInfo is not documented!-->
+
+    <!--property Timestamping is not documented!-->
+
+    <!--property RemoveOnStop is not documented!-->
+
+    <!--property Listen is not documented!-->
+
+    <!--property Symlinks is not documented!-->
+
+    <!--property Mark is not documented!-->
+
+    <!--property MaxConnections is not documented!-->
+
+    <!--property MaxConnectionsPerSource is not documented!-->
+
+    <!--property MessageQueueMaxMessages is not documented!-->
+
+    <!--property MessageQueueMessageSize is not documented!-->
+
+    <!--property TCPCongestion is not documented!-->
+
+    <!--property ReusePort is not documented!-->
+
+    <!--property SmackLabel is not documented!-->
+
+    <!--property SmackLabelIPIn is not documented!-->
+
+    <!--property SmackLabelIPOut is not documented!-->
+
+    <!--property NRefused is not documented!-->
+
+    <!--property FileDescriptorName is not documented!-->
+
+    <!--property SocketProtocol is not documented!-->
+
+    <!--property TriggerLimitIntervalUSec is not documented!-->
+
+    <!--property TriggerLimitBurst is not documented!-->
+
+    <!--property UID is not documented!-->
+
+    <!--property GID is not documented!-->
+
+    <!--property ExecStopPre is not documented!-->
+
+    <!--property ExecStopPost is not documented!-->
+
+    <!--property Slice is not documented!-->
+
+    <!--property ControlGroupId is not documented!-->
+
+    <!--property MemoryCurrent is not documented!-->
+
+    <!--property MemoryPeak is not documented!-->
+
+    <!--property MemorySwapCurrent is not documented!-->
+
+    <!--property MemorySwapPeak is not documented!-->
+
+    <!--property MemoryZSwapCurrent is not documented!-->
+
+    <!--property CPUUsageNSec is not documented!-->
+
+    <!--property EffectiveCPUs is not documented!-->
+
+    <!--property EffectiveMemoryNodes is not documented!-->
+
+    <!--property TasksCurrent is not documented!-->
+
+    <!--property IPIngressBytes is not documented!-->
+
+    <!--property IPIngressPackets is not documented!-->
+
+    <!--property IPEgressBytes is not documented!-->
+
+    <!--property IPEgressPackets is not documented!-->
+
+    <!--property IOReadBytes is not documented!-->
+
+    <!--property IOReadOperations is not documented!-->
+
+    <!--property IOWriteBytes is not documented!-->
+
+    <!--property IOWriteOperations is not documented!-->
+
+    <!--property Delegate is not documented!-->
+
+    <!--property DelegateControllers is not documented!-->
+
+    <!--property CPUAccounting is not documented!-->
+
+    <!--property CPUWeight is not documented!-->
+
+    <!--property StartupCPUWeight is not documented!-->
+
+    <!--property CPUShares is not documented!-->
+
+    <!--property StartupCPUShares is not documented!-->
+
+    <!--property CPUQuotaPerSecUSec is not documented!-->
+
+    <!--property CPUQuotaPeriodUSec is not documented!-->
+
+    <!--property AllowedCPUs is not documented!-->
+
+    <!--property StartupAllowedCPUs is not documented!-->
+
+    <!--property AllowedMemoryNodes is not documented!-->
+
+    <!--property StartupAllowedMemoryNodes is not documented!-->
+
+    <!--property IOAccounting is not documented!-->
+
+    <!--property IOWeight is not documented!-->
+
+    <!--property StartupIOWeight is not documented!-->
+
+    <!--property IODeviceWeight is not documented!-->
+
+    <!--property IOReadBandwidthMax is not documented!-->
+
+    <!--property IOWriteBandwidthMax is not documented!-->
+
+    <!--property IOReadIOPSMax is not documented!-->
+
+    <!--property IOWriteIOPSMax is not documented!-->
+
+    <!--property IODeviceLatencyTargetUSec is not documented!-->
+
+    <!--property BlockIOAccounting is not documented!-->
+
+    <!--property BlockIOWeight is not documented!-->
+
+    <!--property StartupBlockIOWeight is not documented!-->
+
+    <!--property BlockIODeviceWeight is not documented!-->
+
+    <!--property BlockIOReadBandwidth is not documented!-->
+
+    <!--property BlockIOWriteBandwidth is not documented!-->
+
+    <!--property MemoryAccounting is not documented!-->
+
+    <!--property DefaultMemoryLow is not documented!-->
+
+    <!--property DefaultStartupMemoryLow is not documented!-->
+
+    <!--property DefaultMemoryMin is not documented!-->
+
+    <!--property MemoryMin is not documented!-->
+
+    <!--property MemoryLow is not documented!-->
+
+    <!--property StartupMemoryLow is not documented!-->
+
+    <!--property MemoryHigh is not documented!-->
+
+    <!--property StartupMemoryHigh is not documented!-->
+
+    <!--property MemoryMax is not documented!-->
+
+    <!--property StartupMemoryMax is not documented!-->
+
+    <!--property MemorySwapMax is not documented!-->
+
+    <!--property StartupMemorySwapMax is not documented!-->
+
+    <!--property MemoryZSwapMax is not documented!-->
+
+    <!--property StartupMemoryZSwapMax is not documented!-->
+
+    <!--property MemoryLimit is not documented!-->
+
+    <!--property DevicePolicy is not documented!-->
+
+    <!--property DeviceAllow is not documented!-->
+
+    <!--property TasksAccounting is not documented!-->
+
+    <!--property TasksMax is not documented!-->
+
+    <!--property IPAccounting is not documented!-->
+
+    <!--property IPAddressAllow is not documented!-->
+
+    <!--property IPAddressDeny is not documented!-->
+
+    <!--property IPIngressFilterPath is not documented!-->
+
+    <!--property IPEgressFilterPath is not documented!-->
+
+    <!--property DisableControllers is not documented!-->
+
+    <!--property ManagedOOMSwap is not documented!-->
+
+    <!--property ManagedOOMMemoryPressure is not documented!-->
+
+    <!--property ManagedOOMMemoryPressureLimit is not documented!-->
+
+    <!--property ManagedOOMPreference is not documented!-->
+
+    <!--property BPFProgram is not documented!-->
+
+    <!--property SocketBindAllow is not documented!-->
+
+    <!--property SocketBindDeny is not documented!-->
+
+    <!--property RestrictNetworkInterfaces is not documented!-->
+
+    <!--property MemoryPressureWatch is not documented!-->
+
+    <!--property MemoryPressureThresholdUSec is not documented!-->
+
+    <!--property NFTSet is not documented!-->
+
+    <!--property CoredumpReceive is not documented!-->
+
+    <!--property EnvironmentFiles is not documented!-->
+
+    <!--property PassEnvironment is not documented!-->
+
+    <!--property UnsetEnvironment is not documented!-->
+
+    <!--property UMask is not documented!-->
+
+    <!--property LimitCPUSoft is not documented!-->
+
+    <!--property LimitFSIZE is not documented!-->
+
+    <!--property LimitFSIZESoft is not documented!-->
+
+    <!--property LimitDATA is not documented!-->
+
+    <!--property LimitDATASoft is not documented!-->
+
+    <!--property LimitSTACK is not documented!-->
+
+    <!--property LimitSTACKSoft is not documented!-->
+
+    <!--property LimitCORE is not documented!-->
+
+    <!--property LimitCORESoft is not documented!-->
+
+    <!--property LimitRSS is not documented!-->
+
+    <!--property LimitRSSSoft is not documented!-->
+
+    <!--property LimitNOFILE is not documented!-->
+
+    <!--property LimitNOFILESoft is not documented!-->
+
+    <!--property LimitAS is not documented!-->
+
+    <!--property LimitASSoft is not documented!-->
+
+    <!--property LimitNPROC is not documented!-->
+
+    <!--property LimitNPROCSoft is not documented!-->
+
+    <!--property LimitMEMLOCK is not documented!-->
+
+    <!--property LimitMEMLOCKSoft is not documented!-->
+
+    <!--property LimitLOCKS is not documented!-->
+
+    <!--property LimitLOCKSSoft is not documented!-->
+
+    <!--property LimitSIGPENDING is not documented!-->
+
+    <!--property LimitSIGPENDINGSoft is not documented!-->
+
+    <!--property LimitMSGQUEUE is not documented!-->
+
+    <!--property LimitMSGQUEUESoft is not documented!-->
+
+    <!--property LimitNICE is not documented!-->
+
+    <!--property LimitNICESoft is not documented!-->
+
+    <!--property LimitRTPRIO is not documented!-->
+
+    <!--property LimitRTPRIOSoft is not documented!-->
+
+    <!--property LimitRTTIME is not documented!-->
+
+    <!--property LimitRTTIMESoft is not documented!-->
+
+    <!--property WorkingDirectory is not documented!-->
+
+    <!--property RootHashPath is not documented!-->
+
+    <!--property RootHashSignaturePath is not documented!-->
+
+    <!--property RootEphemeral is not documented!-->
+
+    <!--property OOMScoreAdjust is not documented!-->
+
+    <!--property CoredumpFilter is not documented!-->
+
+    <!--property Nice is not documented!-->
+
+    <!--property IOSchedulingClass is not documented!-->
+
+    <!--property IOSchedulingPriority is not documented!-->
+
+    <!--property CPUSchedulingPolicy is not documented!-->
+
+    <!--property CPUSchedulingPriority is not documented!-->
+
+    <!--property CPUAffinity is not documented!-->
+
+    <!--property CPUAffinityFromNUMA is not documented!-->
+
+    <!--property NUMAPolicy is not documented!-->
+
+    <!--property NUMAMask is not documented!-->
+
+    <!--property TimerSlackNSec is not documented!-->
+
+    <!--property CPUSchedulingResetOnFork is not documented!-->
+
+    <!--property NonBlocking is not documented!-->
+
+    <!--property StandardInput is not documented!-->
+
+    <!--property StandardInputFileDescriptorName is not documented!-->
+
+    <!--property StandardInputData is not documented!-->
+
+    <!--property StandardOutput is not documented!-->
+
+    <!--property StandardOutputFileDescriptorName is not documented!-->
+
+    <!--property StandardError is not documented!-->
+
+    <!--property StandardErrorFileDescriptorName is not documented!-->
+
+    <!--property TTYPath is not documented!-->
+
+    <!--property TTYReset is not documented!-->
+
+    <!--property TTYVHangup is not documented!-->
+
+    <!--property TTYVTDisallocate is not documented!-->
+
+    <!--property TTYRows is not documented!-->
+
+    <!--property TTYColumns is not documented!-->
+
+    <!--property SyslogPriority is not documented!-->
+
+    <!--property SyslogIdentifier is not documented!-->
+
+    <!--property SyslogLevelPrefix is not documented!-->
+
+    <!--property SyslogLevel is not documented!-->
+
+    <!--property SyslogFacility is not documented!-->
+
+    <!--property LogLevelMax is not documented!-->
+
+    <!--property LogRateLimitIntervalUSec is not documented!-->
+
+    <!--property LogRateLimitBurst is not documented!-->
+
+    <!--property LogExtraFields is not documented!-->
+
+    <!--property LogFilterPatterns is not documented!-->
+
+    <!--property LogNamespace is not documented!-->
+
+    <!--property AmbientCapabilities is not documented!-->
+
+    <!--property User is not documented!-->
+
+    <!--property Group is not documented!-->
+
+    <!--property DynamicUser is not documented!-->
+
+    <!--property SetLoginEnvironment is not documented!-->
+
+    <!--property RemoveIPC is not documented!-->
+
+    <!--property SetCredential is not documented!-->
+
+    <!--property SetCredentialEncrypted is not documented!-->
+
+    <!--property LoadCredential is not documented!-->
+
+    <!--property LoadCredentialEncrypted is not documented!-->
+
+    <!--property ImportCredential is not documented!-->
+
+    <!--property SupplementaryGroups is not documented!-->
+
+    <!--property PAMName is not documented!-->
+
+    <!--property ReadWritePaths is not documented!-->
+
+    <!--property ReadOnlyPaths is not documented!-->
+
+    <!--property InaccessiblePaths is not documented!-->
+
+    <!--property ExecPaths is not documented!-->
+
+    <!--property NoExecPaths is not documented!-->
+
+    <!--property ExecSearchPath is not documented!-->
+
+    <!--property PrivateTmp is not documented!-->
+
+    <!--property PrivateDevices is not documented!-->
+
+    <!--property ProtectClock is not documented!-->
+
+    <!--property ProtectKernelTunables is not documented!-->
+
+    <!--property ProtectKernelModules is not documented!-->
+
+    <!--property ProtectKernelLogs is not documented!-->
+
+    <!--property ProtectControlGroups is not documented!-->
+
+    <!--property PrivateNetwork is not documented!-->
+
+    <!--property PrivateUsers is not documented!-->
+
+    <!--property PrivateMounts is not documented!-->
+
+    <!--property PrivateIPC is not documented!-->
+
+    <!--property ProtectHome is not documented!-->
+
+    <!--property ProtectSystem is not documented!-->
+
+    <!--property SameProcessGroup is not documented!-->
+
+    <!--property UtmpIdentifier is not documented!-->
+
+    <!--property UtmpMode is not documented!-->
+
+    <!--property SELinuxContext is not documented!-->
+
+    <!--property AppArmorProfile is not documented!-->
+
+    <!--property SmackProcessLabel is not documented!-->
+
+    <!--property IgnoreSIGPIPE is not documented!-->
+
+    <!--property NoNewPrivileges is not documented!-->
+
+    <!--property SystemCallFilter is not documented!-->
+
+    <!--property SystemCallArchitectures is not documented!-->
+
+    <!--property SystemCallErrorNumber is not documented!-->
+
+    <!--property SystemCallLog is not documented!-->
+
+    <!--property Personality is not documented!-->
+
+    <!--property LockPersonality is not documented!-->
+
+    <!--property RestrictAddressFamilies is not documented!-->
+
+    <!--property RuntimeDirectoryPreserve is not documented!-->
+
+    <!--property RuntimeDirectoryMode is not documented!-->
+
+    <!--property StateDirectoryMode is not documented!-->
+
+    <!--property CacheDirectoryMode is not documented!-->
+
+    <!--property LogsDirectoryMode is not documented!-->
+
+    <!--property ConfigurationDirectoryMode is not documented!-->
+
+    <!--property ConfigurationDirectory is not documented!-->
+
+    <!--property TimeoutCleanUSec is not documented!-->
+
+    <!--property MemoryDenyWriteExecute is not documented!-->
+
+    <!--property RestrictRealtime is not documented!-->
+
+    <!--property RestrictSUIDSGID is not documented!-->
+
+    <!--property RestrictNamespaces is not documented!-->
+
+    <!--property RestrictFileSystems is not documented!-->
+
+    <!--property BindPaths is not documented!-->
+
+    <!--property BindReadOnlyPaths is not documented!-->
+
+    <!--property TemporaryFileSystem is not documented!-->
+
+    <!--property MountAPIVFS is not documented!-->
+
+    <!--property KeyringMode is not documented!-->
+
+    <!--property ProtectProc is not documented!-->
+
+    <!--property ProcSubset is not documented!-->
+
+    <!--property ProtectHostname is not documented!-->
+
+    <!--property MemoryKSM is not documented!-->
+
+    <!--property NetworkNamespacePath is not documented!-->
+
+    <!--property IPCNamespacePath is not documented!-->
+
+    <!--property RootImagePolicy is not documented!-->
+
+    <!--property MountImagePolicy is not documented!-->
+
+    <!--property ExtensionImagePolicy is not documented!-->
+
+    <!--property KillMode is not documented!-->
+
+    <!--property KillSignal is not documented!-->
+
+    <!--property RestartKillSignal is not documented!-->
+
+    <!--property FinalKillSignal is not documented!-->
+
+    <!--property SendSIGKILL is not documented!-->
+
+    <!--property SendSIGHUP is not documented!-->
+
+    <!--property WatchdogSignal is not documented!-->
+
+    <!--Autogenerated cross-references for systemd.directives, do not edit-->
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Unit"/>
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Socket"/>
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Unit"/>
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Socket"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="GetProcesses()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="AttachProcesses()"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="BindIPv6Only"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Backlog"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TimeoutUSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="BindToDevice"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SocketUser"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SocketGroup"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SocketMode"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DirectoryMode"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Accept"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="FlushPending"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Writable"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="KeepAlive"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="KeepAliveTimeUSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="KeepAliveIntervalUSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="KeepAliveProbes"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DeferAcceptUSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="NoDelay"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Priority"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ReceiveBuffer"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SendBuffer"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IPTOS"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IPTTL"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="PipeSize"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="FreeBind"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Transparent"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Broadcast"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="PassCredentials"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="PassSecurity"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="PassPacketInfo"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Timestamping"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RemoveOnStop"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Listen"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Symlinks"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Mark"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MaxConnections"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MaxConnectionsPerSource"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MessageQueueMaxMessages"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MessageQueueMessageSize"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TCPCongestion"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ReusePort"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SmackLabel"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SmackLabelIPIn"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SmackLabelIPOut"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ControlPID"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Result"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="NConnections"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="NAccepted"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="NRefused"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="FileDescriptorName"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SocketProtocol"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TriggerLimitIntervalUSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TriggerLimitBurst"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="PollLimitIntervalUSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="PollLimitBurst"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="UID"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="GID"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ExecStartPre"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ExecStartPost"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ExecStopPre"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ExecStopPost"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Slice"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ControlGroup"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ControlGroupId"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryCurrent"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryPeak"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemorySwapCurrent"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemorySwapPeak"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryZSwapCurrent"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryAvailable"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CPUUsageNSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="EffectiveCPUs"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="EffectiveMemoryNodes"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TasksCurrent"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IPIngressBytes"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IPIngressPackets"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IPEgressBytes"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IPEgressPackets"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IOReadBytes"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IOReadOperations"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IOWriteBytes"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IOWriteOperations"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Delegate"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DelegateControllers"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DelegateSubgroup"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CPUAccounting"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CPUWeight"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StartupCPUWeight"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CPUShares"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StartupCPUShares"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CPUQuotaPerSecUSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CPUQuotaPeriodUSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="AllowedCPUs"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StartupAllowedCPUs"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="AllowedMemoryNodes"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StartupAllowedMemoryNodes"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IOAccounting"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IOWeight"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StartupIOWeight"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IODeviceWeight"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IOReadBandwidthMax"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IOWriteBandwidthMax"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IOReadIOPSMax"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IOWriteIOPSMax"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IODeviceLatencyTargetUSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="BlockIOAccounting"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="BlockIOWeight"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StartupBlockIOWeight"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="BlockIODeviceWeight"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="BlockIOReadBandwidth"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="BlockIOWriteBandwidth"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryAccounting"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DefaultMemoryLow"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DefaultStartupMemoryLow"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DefaultMemoryMin"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryMin"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryLow"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StartupMemoryLow"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryHigh"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StartupMemoryHigh"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryMax"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StartupMemoryMax"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemorySwapMax"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StartupMemorySwapMax"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryZSwapMax"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StartupMemoryZSwapMax"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryLimit"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DevicePolicy"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DeviceAllow"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TasksAccounting"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TasksMax"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IPAccounting"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IPAddressAllow"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IPAddressDeny"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IPIngressFilterPath"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IPEgressFilterPath"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DisableControllers"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ManagedOOMSwap"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ManagedOOMMemoryPressure"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ManagedOOMMemoryPressureLimit"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ManagedOOMPreference"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="BPFProgram"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SocketBindAllow"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SocketBindDeny"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RestrictNetworkInterfaces"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryPressureWatch"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryPressureThresholdUSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="NFTSet"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CoredumpReceive"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Environment"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="EnvironmentFiles"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="PassEnvironment"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="UnsetEnvironment"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="UMask"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitCPU"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitCPUSoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitFSIZE"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitFSIZESoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitDATA"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitDATASoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitSTACK"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitSTACKSoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitCORE"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitCORESoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitRSS"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitRSSSoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitNOFILE"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitNOFILESoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitAS"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitASSoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitNPROC"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitNPROCSoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitMEMLOCK"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitMEMLOCKSoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitLOCKS"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitLOCKSSoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitSIGPENDING"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitSIGPENDINGSoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitMSGQUEUE"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitMSGQUEUESoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitNICE"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitNICESoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitRTPRIO"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitRTPRIOSoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitRTTIME"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitRTTIMESoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="WorkingDirectory"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RootDirectory"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RootImage"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RootImageOptions"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RootHash"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RootHashPath"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RootHashSignature"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RootHashSignaturePath"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RootVerity"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RootEphemeral"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ExtensionDirectories"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ExtensionImages"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MountImages"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="OOMScoreAdjust"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CoredumpFilter"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Nice"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IOSchedulingClass"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IOSchedulingPriority"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CPUSchedulingPolicy"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CPUSchedulingPriority"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CPUAffinity"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CPUAffinityFromNUMA"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="NUMAPolicy"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="NUMAMask"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TimerSlackNSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CPUSchedulingResetOnFork"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="NonBlocking"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StandardInput"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StandardInputFileDescriptorName"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StandardInputData"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StandardOutput"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StandardOutputFileDescriptorName"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StandardError"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StandardErrorFileDescriptorName"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TTYPath"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TTYReset"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TTYVHangup"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TTYVTDisallocate"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TTYRows"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TTYColumns"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SyslogPriority"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SyslogIdentifier"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SyslogLevelPrefix"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SyslogLevel"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SyslogFacility"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LogLevelMax"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LogRateLimitIntervalUSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LogRateLimitBurst"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LogExtraFields"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LogFilterPatterns"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LogNamespace"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SecureBits"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CapabilityBoundingSet"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="AmbientCapabilities"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="User"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Group"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DynamicUser"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SetLoginEnvironment"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RemoveIPC"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SetCredential"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SetCredentialEncrypted"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LoadCredential"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LoadCredentialEncrypted"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ImportCredential"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SupplementaryGroups"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="PAMName"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ReadWritePaths"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ReadOnlyPaths"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="InaccessiblePaths"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ExecPaths"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="NoExecPaths"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ExecSearchPath"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MountFlags"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="PrivateTmp"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="PrivateDevices"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ProtectClock"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ProtectKernelTunables"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ProtectKernelModules"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ProtectKernelLogs"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ProtectControlGroups"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="PrivateNetwork"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="PrivateUsers"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="PrivateMounts"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="PrivateIPC"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ProtectHome"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ProtectSystem"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SameProcessGroup"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="UtmpIdentifier"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="UtmpMode"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SELinuxContext"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="AppArmorProfile"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SmackProcessLabel"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IgnoreSIGPIPE"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="NoNewPrivileges"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SystemCallFilter"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SystemCallArchitectures"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SystemCallErrorNumber"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SystemCallLog"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Personality"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LockPersonality"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RestrictAddressFamilies"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RuntimeDirectorySymlink"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RuntimeDirectoryPreserve"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RuntimeDirectoryMode"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RuntimeDirectory"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StateDirectorySymlink"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StateDirectoryMode"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StateDirectory"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CacheDirectorySymlink"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CacheDirectoryMode"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CacheDirectory"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LogsDirectorySymlink"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LogsDirectoryMode"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LogsDirectory"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ConfigurationDirectoryMode"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ConfigurationDirectory"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TimeoutCleanUSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryDenyWriteExecute"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RestrictRealtime"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RestrictSUIDSGID"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RestrictNamespaces"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RestrictFileSystems"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="BindPaths"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="BindReadOnlyPaths"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TemporaryFileSystem"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MountAPIVFS"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="KeyringMode"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ProtectProc"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ProcSubset"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ProtectHostname"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryKSM"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="NetworkNamespacePath"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IPCNamespacePath"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RootImagePolicy"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MountImagePolicy"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ExtensionImagePolicy"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="KillMode"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="KillSignal"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RestartKillSignal"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="FinalKillSignal"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SendSIGKILL"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SendSIGHUP"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="WatchdogSignal"/>
+
+    <!--End of Autogenerated section-->
+
+    <para><varname>PollLimitIntervalUSec</varname>/<varname>PollLimitBurst</varname> properties configure the
+    polling limit for the socket unit. Expects a time in µs, resp. an unsigned integer. If either is set to
+    zero the limiting feature is turned off.</para>
+
+    <refsect2>
+      <title>Properties</title>
+
+      <para>Most of the properties map directly to the corresponding settings in socket unit files. As socket
+      units can include <varname>ExecStartPre</varname> (and similar) fields which contain information about
+      processes to execute. They also share most of the fields related to the execution context that Service
+      objects expose (see above).</para>
+
+      <para>In addition to these properties there are the following:</para>
+
+      <para><varname>NAccepted</varname> contains the accumulated number of connections ever accepted on this
+      socket. This only applies to sockets with <varname>Accept</varname> set to <literal>yes</literal>,
+      i.e. those where systemd is responsible for accepted connections. </para>
+
+      <para>Similarly <varname>NConnections</varname> contains the number of currently open connections on
+      this socket. It only applies only to socket units with <varname>Accept</varname> set to
+      <literal>yes</literal>.</para>
+
+      <para><varname>Result</varname> encodes the reason why a socket unit failed if it is in the
+      <literal>failed</literal> state (see <varname>ActiveState</varname> above). The values
+      <literal>success</literal>, <literal>resources</literal>, <literal>timeout</literal>,
+      <literal>exit-code</literal>, <literal>signal</literal> and <literal>core-dump</literal> have the same
+      meaning as they have for the corresponding field of service units (see above). In addition to that,
+      the value <literal>service-failed-permanent</literal> indicates that the service of this socket failed
+      continuously.</para>
+
+      <para><varname>FlushPending</varname> specifies whether to flush the socket
+      just before entering the listening state. This setting only applies to sockets with
+      <varname>Accept=</varname> set to <literal>no</literal>.</para>
+    </refsect2>
+  </refsect1>
+
+  <refsect1>
+    <title>Target Unit Objects</title>
+
+    <programlisting executable="systemd" node="/org/freedesktop/systemd1/unit/basic_2etarget" interface="org.freedesktop.systemd1.Target">
+node /org/freedesktop/systemd1/unit/basic_2etarget {
+  interface org.freedesktop.systemd1.Target {
+  };
+  interface org.freedesktop.DBus.Peer { ... };
+  interface org.freedesktop.DBus.Introspectable { ... };
+  interface org.freedesktop.DBus.Properties { ... };
+  interface org.freedesktop.systemd1.Unit { ... };
+};
+    </programlisting>
+
+    <para>Target units have neither type-specific methods nor properties.</para>
+  </refsect1>
+
+
+  <refsect1>
+    <title>Device Unit Objects</title>
+
+    <para>All device unit objects implement the <interfacename>org.freedesktop.systemd1.Device</interfacename> interface (described here)
+    in addition to the generic <interfacename>org.freedesktop.systemd1.Unit</interfacename> interface (see above).</para>
+
+    <programlisting executable="systemd" node="/org/freedesktop/systemd1/unit/dev_2dttyS0_2edevice" interface="org.freedesktop.systemd1.Device">
+node /org/freedesktop/systemd1/unit/dev_2dttyS0_2edevice {
+  interface org.freedesktop.systemd1.Device {
+    properties:
+      readonly s SysFSPath = '...';
+  };
+  interface org.freedesktop.DBus.Peer { ... };
+  interface org.freedesktop.DBus.Introspectable { ... };
+  interface org.freedesktop.DBus.Properties { ... };
+  interface org.freedesktop.systemd1.Unit { ... };
+};
+    </programlisting>
+
+    <!--Autogenerated cross-references for systemd.directives, do not edit-->
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Unit"/>
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Device"/>
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Unit"/>
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Device"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SysFSPath"/>
+
+    <!--End of Autogenerated section-->
+
+    <refsect2>
+      <title>Properties</title>
+
+      <para>Device units only expose a single type-specific property:</para>
+
+      <para><varname>SysFSPath</varname> contains the sysfs path of the kernel device this object corresponds
+      to.</para>
+    </refsect2>
+  </refsect1>
+
+  <refsect1>
+    <title>Mount Unit Objects</title>
+
+    <para>All mount unit objects implement the <interfacename>org.freedesktop.systemd1.Mount</interfacename>
+    interface (described here) in addition to the generic
+    <interfacename>org.freedesktop.systemd1.Unit</interfacename> interface (see above).</para>
+
+    <programlisting executable="systemd" node="/org/freedesktop/systemd1/unit/home_2emount" interface="org.freedesktop.systemd1.Mount">
+node /org/freedesktop/systemd1/unit/home_2emount {
+  interface org.freedesktop.systemd1.Mount {
+    methods:
+      GetProcesses(out a(sus) processes);
+      AttachProcesses(in  s subcgroup,
+                      in  au pids);
+    properties:
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s Where = '...';
+      readonly s What = '...';
+      readonly s Options = '...';
+      readonly s Type = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t TimeoutUSec = ...;
+      readonly u ControlPID = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly u DirectoryMode = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b SloppyOptions = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b LazyUnmount = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b ForceUnmount = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b ReadWriteOnly = ...;
+      readonly s Result = '...';
+      readonly u UID = ...;
+      readonly u GID = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates")
+      readonly a(sasbttttuii) ExecMount = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates")
+      readonly a(sasbttttuii) ExecUnmount = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates")
+      readonly a(sasbttttuii) ExecRemount = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s Slice = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s ControlGroup = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t ControlGroupId = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemoryCurrent = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemoryPeak = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemorySwapCurrent = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemorySwapPeak = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemoryZSwapCurrent = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemoryAvailable = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t CPUUsageNSec = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly ay EffectiveCPUs = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly ay EffectiveMemoryNodes = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t TasksCurrent = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t IPIngressBytes = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t IPIngressPackets = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t IPEgressBytes = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t IPEgressPackets = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t IOReadBytes = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t IOReadOperations = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t IOWriteBytes = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t IOWriteOperations = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly b Delegate = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly as DelegateControllers = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s DelegateSubgroup = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly b CPUAccounting = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t CPUWeight = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t StartupCPUWeight = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t CPUShares = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t StartupCPUShares = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t CPUQuotaPerSecUSec = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t CPUQuotaPeriodUSec = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly ay AllowedCPUs = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly ay StartupAllowedCPUs = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly ay AllowedMemoryNodes = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly ay StartupAllowedMemoryNodes = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly b IOAccounting = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t IOWeight = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t StartupIOWeight = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(st) IODeviceWeight = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(st) IOReadBandwidthMax = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(st) IOWriteBandwidthMax = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(st) IOReadIOPSMax = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(st) IOWriteIOPSMax = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(st) IODeviceLatencyTargetUSec = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly b BlockIOAccounting = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t BlockIOWeight = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t StartupBlockIOWeight = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(st) BlockIODeviceWeight = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(st) BlockIOReadBandwidth = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(st) BlockIOWriteBandwidth = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly b MemoryAccounting = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t DefaultMemoryLow = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t DefaultStartupMemoryLow = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t DefaultMemoryMin = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemoryMin = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemoryLow = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t StartupMemoryLow = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemoryHigh = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t StartupMemoryHigh = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemoryMax = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t StartupMemoryMax = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemorySwapMax = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t StartupMemorySwapMax = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemoryZSwapMax = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t StartupMemoryZSwapMax = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemoryLimit = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s DevicePolicy = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(ss) DeviceAllow = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly b TasksAccounting = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t TasksMax = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly b IPAccounting = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(iayu) IPAddressAllow = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(iayu) IPAddressDeny = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly as IPIngressFilterPath = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly as IPEgressFilterPath = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly as DisableControllers = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s ManagedOOMSwap = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s ManagedOOMMemoryPressure = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly u ManagedOOMMemoryPressureLimit = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s ManagedOOMPreference = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(ss) BPFProgram = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(iiqq) SocketBindAllow = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(iiqq) SocketBindDeny = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly (bas) RestrictNetworkInterfaces = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s MemoryPressureWatch = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemoryPressureThresholdUSec = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(iiss) NFTSet = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly b CoredumpReceive = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as Environment = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly a(sb) EnvironmentFiles = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as PassEnvironment = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as UnsetEnvironment = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly u UMask = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitCPU = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitCPUSoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitFSIZE = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitFSIZESoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitDATA = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitDATASoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitSTACK = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitSTACKSoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitCORE = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitCORESoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitRSS = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitRSSSoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitNOFILE = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitNOFILESoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitAS = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitASSoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitNPROC = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitNPROCSoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitMEMLOCK = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitMEMLOCKSoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitLOCKS = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitLOCKSSoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitSIGPENDING = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitSIGPENDINGSoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitMSGQUEUE = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitMSGQUEUESoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitNICE = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitNICESoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitRTPRIO = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitRTPRIOSoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitRTTIME = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitRTTIMESoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s WorkingDirectory = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s RootDirectory = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s RootImage = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly a(ss) RootImageOptions = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly ay RootHash = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s RootHashPath = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly ay RootHashSignature = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s RootHashSignaturePath = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s RootVerity = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b RootEphemeral = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as ExtensionDirectories = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly a(sba(ss)) ExtensionImages = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly a(ssba(ss)) MountImages = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i OOMScoreAdjust = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t CoredumpFilter = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i Nice = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i IOSchedulingClass = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i IOSchedulingPriority = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i CPUSchedulingPolicy = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i CPUSchedulingPriority = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly ay CPUAffinity = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b CPUAffinityFromNUMA = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i NUMAPolicy = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly ay NUMAMask = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t TimerSlackNSec = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b CPUSchedulingResetOnFork = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b NonBlocking = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s StandardInput = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s StandardInputFileDescriptorName = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly ay StandardInputData = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s StandardOutput = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s StandardOutputFileDescriptorName = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s StandardError = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s StandardErrorFileDescriptorName = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s TTYPath = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b TTYReset = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b TTYVHangup = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b TTYVTDisallocate = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly q TTYRows = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly q TTYColumns = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i SyslogPriority = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s SyslogIdentifier = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b SyslogLevelPrefix = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i SyslogLevel = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i SyslogFacility = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i LogLevelMax = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LogRateLimitIntervalUSec = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly u LogRateLimitBurst = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly aay LogExtraFields = [[...], ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly a(bs) LogFilterPatterns = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s LogNamespace = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i SecureBits = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t CapabilityBoundingSet = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t AmbientCapabilities = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s User = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s Group = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b DynamicUser = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b SetLoginEnvironment = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b RemoveIPC = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly a(say) SetCredential = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly a(say) SetCredentialEncrypted = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly a(ss) LoadCredential = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly a(ss) LoadCredentialEncrypted = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as ImportCredential = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as SupplementaryGroups = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s PAMName = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as ReadWritePaths = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as ReadOnlyPaths = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as InaccessiblePaths = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as ExecPaths = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as NoExecPaths = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as ExecSearchPath = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t MountFlags = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b PrivateTmp = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b PrivateDevices = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b ProtectClock = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b ProtectKernelTunables = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b ProtectKernelModules = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b ProtectKernelLogs = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b ProtectControlGroups = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b PrivateNetwork = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b PrivateUsers = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b PrivateMounts = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b PrivateIPC = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s ProtectHome = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s ProtectSystem = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b SameProcessGroup = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s UtmpIdentifier = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s UtmpMode = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly (bs) SELinuxContext = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly (bs) AppArmorProfile = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly (bs) SmackProcessLabel = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b IgnoreSIGPIPE = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b NoNewPrivileges = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly (bas) SystemCallFilter = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as SystemCallArchitectures = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i SystemCallErrorNumber = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly (bas) SystemCallLog = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s Personality = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b LockPersonality = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly (bas) RestrictAddressFamilies = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly a(sst) RuntimeDirectorySymlink = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s RuntimeDirectoryPreserve = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly u RuntimeDirectoryMode = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as RuntimeDirectory = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly a(sst) StateDirectorySymlink = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly u StateDirectoryMode = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as StateDirectory = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly a(sst) CacheDirectorySymlink = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly u CacheDirectoryMode = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as CacheDirectory = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly a(sst) LogsDirectorySymlink = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly u LogsDirectoryMode = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as LogsDirectory = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly u ConfigurationDirectoryMode = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as ConfigurationDirectory = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t TimeoutCleanUSec = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b MemoryDenyWriteExecute = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b RestrictRealtime = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b RestrictSUIDSGID = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t RestrictNamespaces = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly (bas) RestrictFileSystems = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly a(ssbt) BindPaths = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly a(ssbt) BindReadOnlyPaths = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly a(ss) TemporaryFileSystem = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b MountAPIVFS = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s KeyringMode = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s ProtectProc = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s ProcSubset = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b ProtectHostname = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b MemoryKSM = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s NetworkNamespacePath = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s IPCNamespacePath = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s RootImagePolicy = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s MountImagePolicy = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s ExtensionImagePolicy = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s KillMode = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i KillSignal = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i RestartKillSignal = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i FinalKillSignal = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b SendSIGKILL = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b SendSIGHUP = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i WatchdogSignal = ...;
+  };
+  interface org.freedesktop.DBus.Peer { ... };
+  interface org.freedesktop.DBus.Introspectable { ... };
+  interface org.freedesktop.DBus.Properties { ... };
+  interface org.freedesktop.systemd1.Unit { ... };
+};
+    </programlisting>
+
+    <!--method GetProcesses is not documented!-->
+
+    <!--method AttachProcesses is not documented!-->
+
+    <!--property Where is not documented!-->
+
+    <!--property What is not documented!-->
+
+    <!--property Options is not documented!-->
+
+    <!--property Type is not documented!-->
+
+    <!--property TimeoutUSec is not documented!-->
+
+    <!--property DirectoryMode is not documented!-->
+
+    <!--property SloppyOptions is not documented!-->
+
+    <!--property LazyUnmount is not documented!-->
+
+    <!--property ForceUnmount is not documented!-->
+
+    <!--property ReadWriteOnly is not documented!-->
+
+    <!--property UID is not documented!-->
+
+    <!--property GID is not documented!-->
+
+    <!--property ExecUnmount is not documented!-->
+
+    <!--property ExecRemount is not documented!-->
+
+    <!--property Slice is not documented!-->
+
+    <!--property ControlGroupId is not documented!-->
+
+    <!--property MemoryCurrent is not documented!-->
+
+    <!--property MemoryPeak is not documented!-->
+
+    <!--property MemorySwapCurrent is not documented!-->
+
+    <!--property MemorySwapPeak is not documented!-->
+
+    <!--property MemoryZSwapCurrent is not documented!-->
+
+    <!--property CPUUsageNSec is not documented!-->
+
+    <!--property EffectiveCPUs is not documented!-->
+
+    <!--property EffectiveMemoryNodes is not documented!-->
+
+    <!--property TasksCurrent is not documented!-->
+
+    <!--property IPIngressBytes is not documented!-->
+
+    <!--property IPIngressPackets is not documented!-->
+
+    <!--property IPEgressBytes is not documented!-->
+
+    <!--property IPEgressPackets is not documented!-->
+
+    <!--property IOReadBytes is not documented!-->
+
+    <!--property IOReadOperations is not documented!-->
+
+    <!--property IOWriteBytes is not documented!-->
+
+    <!--property IOWriteOperations is not documented!-->
+
+    <!--property Delegate is not documented!-->
+
+    <!--property DelegateControllers is not documented!-->
+
+    <!--property CPUAccounting is not documented!-->
+
+    <!--property CPUWeight is not documented!-->
+
+    <!--property StartupCPUWeight is not documented!-->
+
+    <!--property CPUShares is not documented!-->
+
+    <!--property StartupCPUShares is not documented!-->
+
+    <!--property CPUQuotaPerSecUSec is not documented!-->
+
+    <!--property CPUQuotaPeriodUSec is not documented!-->
+
+    <!--property AllowedCPUs is not documented!-->
+
+    <!--property StartupAllowedCPUs is not documented!-->
+
+    <!--property AllowedMemoryNodes is not documented!-->
+
+    <!--property StartupAllowedMemoryNodes is not documented!-->
+
+    <!--property IOAccounting is not documented!-->
+
+    <!--property IOWeight is not documented!-->
+
+    <!--property StartupIOWeight is not documented!-->
+
+    <!--property IODeviceWeight is not documented!-->
+
+    <!--property IOReadBandwidthMax is not documented!-->
+
+    <!--property IOWriteBandwidthMax is not documented!-->
+
+    <!--property IOReadIOPSMax is not documented!-->
+
+    <!--property IOWriteIOPSMax is not documented!-->
+
+    <!--property IODeviceLatencyTargetUSec is not documented!-->
+
+    <!--property BlockIOAccounting is not documented!-->
+
+    <!--property BlockIOWeight is not documented!-->
+
+    <!--property StartupBlockIOWeight is not documented!-->
+
+    <!--property BlockIODeviceWeight is not documented!-->
+
+    <!--property BlockIOReadBandwidth is not documented!-->
+
+    <!--property BlockIOWriteBandwidth is not documented!-->
+
+    <!--property MemoryAccounting is not documented!-->
+
+    <!--property DefaultMemoryLow is not documented!-->
+
+    <!--property DefaultStartupMemoryLow is not documented!-->
+
+    <!--property DefaultMemoryMin is not documented!-->
+
+    <!--property MemoryMin is not documented!-->
+
+    <!--property MemoryLow is not documented!-->
+
+    <!--property StartupMemoryLow is not documented!-->
+
+    <!--property MemoryHigh is not documented!-->
+
+    <!--property StartupMemoryHigh is not documented!-->
+
+    <!--property MemoryMax is not documented!-->
+
+    <!--property StartupMemoryMax is not documented!-->
+
+    <!--property MemorySwapMax is not documented!-->
+
+    <!--property StartupMemorySwapMax is not documented!-->
+
+    <!--property MemoryZSwapMax is not documented!-->
+
+    <!--property StartupMemoryZSwapMax is not documented!-->
+
+    <!--property MemoryLimit is not documented!-->
+
+    <!--property DevicePolicy is not documented!-->
+
+    <!--property DeviceAllow is not documented!-->
+
+    <!--property TasksAccounting is not documented!-->
+
+    <!--property TasksMax is not documented!-->
+
+    <!--property IPAccounting is not documented!-->
+
+    <!--property IPAddressAllow is not documented!-->
+
+    <!--property IPAddressDeny is not documented!-->
+
+    <!--property IPIngressFilterPath is not documented!-->
+
+    <!--property IPEgressFilterPath is not documented!-->
+
+    <!--property DisableControllers is not documented!-->
+
+    <!--property ManagedOOMSwap is not documented!-->
+
+    <!--property ManagedOOMMemoryPressure is not documented!-->
+
+    <!--property ManagedOOMMemoryPressureLimit is not documented!-->
+
+    <!--property ManagedOOMPreference is not documented!-->
+
+    <!--property BPFProgram is not documented!-->
+
+    <!--property SocketBindAllow is not documented!-->
+
+    <!--property SocketBindDeny is not documented!-->
+
+    <!--property RestrictNetworkInterfaces is not documented!-->
+
+    <!--property MemoryPressureWatch is not documented!-->
+
+    <!--property MemoryPressureThresholdUSec is not documented!-->
+
+    <!--property NFTSet is not documented!-->
+
+    <!--property CoredumpReceive is not documented!-->
+
+    <!--property EnvironmentFiles is not documented!-->
+
+    <!--property PassEnvironment is not documented!-->
+
+    <!--property UnsetEnvironment is not documented!-->
+
+    <!--property UMask is not documented!-->
+
+    <!--property LimitCPUSoft is not documented!-->
+
+    <!--property LimitFSIZE is not documented!-->
+
+    <!--property LimitFSIZESoft is not documented!-->
+
+    <!--property LimitDATA is not documented!-->
+
+    <!--property LimitDATASoft is not documented!-->
+
+    <!--property LimitSTACK is not documented!-->
+
+    <!--property LimitSTACKSoft is not documented!-->
+
+    <!--property LimitCORE is not documented!-->
+
+    <!--property LimitCORESoft is not documented!-->
+
+    <!--property LimitRSS is not documented!-->
+
+    <!--property LimitRSSSoft is not documented!-->
+
+    <!--property LimitNOFILE is not documented!-->
+
+    <!--property LimitNOFILESoft is not documented!-->
+
+    <!--property LimitAS is not documented!-->
+
+    <!--property LimitASSoft is not documented!-->
+
+    <!--property LimitNPROC is not documented!-->
+
+    <!--property LimitNPROCSoft is not documented!-->
+
+    <!--property LimitMEMLOCK is not documented!-->
+
+    <!--property LimitMEMLOCKSoft is not documented!-->
+
+    <!--property LimitLOCKS is not documented!-->
+
+    <!--property LimitLOCKSSoft is not documented!-->
+
+    <!--property LimitSIGPENDING is not documented!-->
+
+    <!--property LimitSIGPENDINGSoft is not documented!-->
+
+    <!--property LimitMSGQUEUE is not documented!-->
+
+    <!--property LimitMSGQUEUESoft is not documented!-->
+
+    <!--property LimitNICE is not documented!-->
+
+    <!--property LimitNICESoft is not documented!-->
+
+    <!--property LimitRTPRIO is not documented!-->
+
+    <!--property LimitRTPRIOSoft is not documented!-->
+
+    <!--property LimitRTTIME is not documented!-->
+
+    <!--property LimitRTTIMESoft is not documented!-->
+
+    <!--property WorkingDirectory is not documented!-->
+
+    <!--property RootHashPath is not documented!-->
+
+    <!--property RootHashSignaturePath is not documented!-->
+
+    <!--property RootEphemeral is not documented!-->
+
+    <!--property OOMScoreAdjust is not documented!-->
+
+    <!--property CoredumpFilter is not documented!-->
+
+    <!--property Nice is not documented!-->
+
+    <!--property IOSchedulingClass is not documented!-->
+
+    <!--property IOSchedulingPriority is not documented!-->
+
+    <!--property CPUSchedulingPolicy is not documented!-->
+
+    <!--property CPUSchedulingPriority is not documented!-->
+
+    <!--property CPUAffinity is not documented!-->
+
+    <!--property CPUAffinityFromNUMA is not documented!-->
+
+    <!--property NUMAPolicy is not documented!-->
+
+    <!--property NUMAMask is not documented!-->
+
+    <!--property TimerSlackNSec is not documented!-->
+
+    <!--property CPUSchedulingResetOnFork is not documented!-->
+
+    <!--property NonBlocking is not documented!-->
+
+    <!--property StandardInput is not documented!-->
+
+    <!--property StandardInputFileDescriptorName is not documented!-->
+
+    <!--property StandardInputData is not documented!-->
+
+    <!--property StandardOutput is not documented!-->
+
+    <!--property StandardOutputFileDescriptorName is not documented!-->
+
+    <!--property StandardError is not documented!-->
+
+    <!--property StandardErrorFileDescriptorName is not documented!-->
+
+    <!--property TTYPath is not documented!-->
+
+    <!--property TTYReset is not documented!-->
+
+    <!--property TTYVHangup is not documented!-->
+
+    <!--property TTYVTDisallocate is not documented!-->
+
+    <!--property TTYRows is not documented!-->
+
+    <!--property TTYColumns is not documented!-->
+
+    <!--property SyslogPriority is not documented!-->
+
+    <!--property SyslogIdentifier is not documented!-->
+
+    <!--property SyslogLevelPrefix is not documented!-->
+
+    <!--property SyslogLevel is not documented!-->
+
+    <!--property SyslogFacility is not documented!-->
+
+    <!--property LogLevelMax is not documented!-->
+
+    <!--property LogRateLimitIntervalUSec is not documented!-->
+
+    <!--property LogRateLimitBurst is not documented!-->
+
+    <!--property LogExtraFields is not documented!-->
+
+    <!--property LogFilterPatterns is not documented!-->
+
+    <!--property LogNamespace is not documented!-->
+
+    <!--property AmbientCapabilities is not documented!-->
+
+    <!--property User is not documented!-->
+
+    <!--property Group is not documented!-->
+
+    <!--property DynamicUser is not documented!-->
+
+    <!--property SetLoginEnvironment is not documented!-->
+
+    <!--property RemoveIPC is not documented!-->
+
+    <!--property SetCredential is not documented!-->
+
+    <!--property SetCredentialEncrypted is not documented!-->
+
+    <!--property LoadCredential is not documented!-->
+
+    <!--property LoadCredentialEncrypted is not documented!-->
+
+    <!--property ImportCredential is not documented!-->
+
+    <!--property SupplementaryGroups is not documented!-->
+
+    <!--property PAMName is not documented!-->
+
+    <!--property ReadWritePaths is not documented!-->
+
+    <!--property ReadOnlyPaths is not documented!-->
+
+    <!--property InaccessiblePaths is not documented!-->
+
+    <!--property ExecPaths is not documented!-->
+
+    <!--property NoExecPaths is not documented!-->
+
+    <!--property ExecSearchPath is not documented!-->
+
+    <!--property PrivateTmp is not documented!-->
+
+    <!--property PrivateDevices is not documented!-->
+
+    <!--property ProtectClock is not documented!-->
+
+    <!--property ProtectKernelTunables is not documented!-->
+
+    <!--property ProtectKernelModules is not documented!-->
+
+    <!--property ProtectKernelLogs is not documented!-->
+
+    <!--property ProtectControlGroups is not documented!-->
+
+    <!--property PrivateNetwork is not documented!-->
+
+    <!--property PrivateUsers is not documented!-->
+
+    <!--property PrivateMounts is not documented!-->
+
+    <!--property PrivateIPC is not documented!-->
+
+    <!--property ProtectHome is not documented!-->
+
+    <!--property ProtectSystem is not documented!-->
+
+    <!--property SameProcessGroup is not documented!-->
+
+    <!--property UtmpIdentifier is not documented!-->
+
+    <!--property UtmpMode is not documented!-->
+
+    <!--property SELinuxContext is not documented!-->
+
+    <!--property AppArmorProfile is not documented!-->
+
+    <!--property SmackProcessLabel is not documented!-->
+
+    <!--property IgnoreSIGPIPE is not documented!-->
+
+    <!--property NoNewPrivileges is not documented!-->
+
+    <!--property SystemCallFilter is not documented!-->
+
+    <!--property SystemCallArchitectures is not documented!-->
+
+    <!--property SystemCallErrorNumber is not documented!-->
+
+    <!--property SystemCallLog is not documented!-->
+
+    <!--property Personality is not documented!-->
+
+    <!--property LockPersonality is not documented!-->
+
+    <!--property RestrictAddressFamilies is not documented!-->
+
+    <!--property RuntimeDirectoryPreserve is not documented!-->
+
+    <!--property RuntimeDirectoryMode is not documented!-->
+
+    <!--property StateDirectoryMode is not documented!-->
+
+    <!--property CacheDirectoryMode is not documented!-->
+
+    <!--property LogsDirectoryMode is not documented!-->
+
+    <!--property ConfigurationDirectoryMode is not documented!-->
+
+    <!--property ConfigurationDirectory is not documented!-->
+
+    <!--property TimeoutCleanUSec is not documented!-->
+
+    <!--property MemoryDenyWriteExecute is not documented!-->
+
+    <!--property RestrictRealtime is not documented!-->
+
+    <!--property RestrictSUIDSGID is not documented!-->
+
+    <!--property RestrictNamespaces is not documented!-->
+
+    <!--property RestrictFileSystems is not documented!-->
+
+    <!--property BindPaths is not documented!-->
+
+    <!--property BindReadOnlyPaths is not documented!-->
+
+    <!--property TemporaryFileSystem is not documented!-->
+
+    <!--property MountAPIVFS is not documented!-->
+
+    <!--property KeyringMode is not documented!-->
+
+    <!--property ProtectProc is not documented!-->
+
+    <!--property ProcSubset is not documented!-->
+
+    <!--property ProtectHostname is not documented!-->
+
+    <!--property MemoryKSM is not documented!-->
+
+    <!--property NetworkNamespacePath is not documented!-->
+
+    <!--property IPCNamespacePath is not documented!-->
+
+    <!--property RootImagePolicy is not documented!-->
+
+    <!--property MountImagePolicy is not documented!-->
+
+    <!--property ExtensionImagePolicy is not documented!-->
+
+    <!--property KillMode is not documented!-->
+
+    <!--property KillSignal is not documented!-->
+
+    <!--property RestartKillSignal is not documented!-->
+
+    <!--property FinalKillSignal is not documented!-->
+
+    <!--property SendSIGKILL is not documented!-->
+
+    <!--property SendSIGHUP is not documented!-->
+
+    <!--property WatchdogSignal is not documented!-->
+
+    <!--Autogenerated cross-references for systemd.directives, do not edit-->
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Unit"/>
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Mount"/>
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Unit"/>
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Mount"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="GetProcesses()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="AttachProcesses()"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Where"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="What"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Options"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Type"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TimeoutUSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ControlPID"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DirectoryMode"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SloppyOptions"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LazyUnmount"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ForceUnmount"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ReadWriteOnly"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Result"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="UID"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="GID"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ExecMount"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ExecUnmount"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ExecRemount"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Slice"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ControlGroup"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ControlGroupId"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryCurrent"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryPeak"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemorySwapCurrent"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemorySwapPeak"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryZSwapCurrent"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryAvailable"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CPUUsageNSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="EffectiveCPUs"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="EffectiveMemoryNodes"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TasksCurrent"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IPIngressBytes"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IPIngressPackets"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IPEgressBytes"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IPEgressPackets"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IOReadBytes"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IOReadOperations"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IOWriteBytes"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IOWriteOperations"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Delegate"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DelegateControllers"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DelegateSubgroup"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CPUAccounting"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CPUWeight"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StartupCPUWeight"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CPUShares"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StartupCPUShares"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CPUQuotaPerSecUSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CPUQuotaPeriodUSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="AllowedCPUs"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StartupAllowedCPUs"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="AllowedMemoryNodes"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StartupAllowedMemoryNodes"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IOAccounting"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IOWeight"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StartupIOWeight"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IODeviceWeight"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IOReadBandwidthMax"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IOWriteBandwidthMax"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IOReadIOPSMax"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IOWriteIOPSMax"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IODeviceLatencyTargetUSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="BlockIOAccounting"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="BlockIOWeight"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StartupBlockIOWeight"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="BlockIODeviceWeight"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="BlockIOReadBandwidth"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="BlockIOWriteBandwidth"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryAccounting"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DefaultMemoryLow"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DefaultStartupMemoryLow"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DefaultMemoryMin"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryMin"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryLow"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StartupMemoryLow"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryHigh"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StartupMemoryHigh"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryMax"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StartupMemoryMax"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemorySwapMax"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StartupMemorySwapMax"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryZSwapMax"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StartupMemoryZSwapMax"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryLimit"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DevicePolicy"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DeviceAllow"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TasksAccounting"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TasksMax"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IPAccounting"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IPAddressAllow"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IPAddressDeny"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IPIngressFilterPath"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IPEgressFilterPath"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DisableControllers"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ManagedOOMSwap"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ManagedOOMMemoryPressure"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ManagedOOMMemoryPressureLimit"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ManagedOOMPreference"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="BPFProgram"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SocketBindAllow"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SocketBindDeny"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RestrictNetworkInterfaces"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryPressureWatch"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryPressureThresholdUSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="NFTSet"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CoredumpReceive"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Environment"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="EnvironmentFiles"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="PassEnvironment"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="UnsetEnvironment"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="UMask"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitCPU"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitCPUSoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitFSIZE"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitFSIZESoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitDATA"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitDATASoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitSTACK"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitSTACKSoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitCORE"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitCORESoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitRSS"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitRSSSoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitNOFILE"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitNOFILESoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitAS"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitASSoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitNPROC"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitNPROCSoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitMEMLOCK"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitMEMLOCKSoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitLOCKS"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitLOCKSSoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitSIGPENDING"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitSIGPENDINGSoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitMSGQUEUE"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitMSGQUEUESoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitNICE"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitNICESoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitRTPRIO"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitRTPRIOSoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitRTTIME"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitRTTIMESoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="WorkingDirectory"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RootDirectory"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RootImage"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RootImageOptions"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RootHash"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RootHashPath"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RootHashSignature"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RootHashSignaturePath"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RootVerity"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RootEphemeral"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ExtensionDirectories"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ExtensionImages"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MountImages"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="OOMScoreAdjust"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CoredumpFilter"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Nice"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IOSchedulingClass"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IOSchedulingPriority"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CPUSchedulingPolicy"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CPUSchedulingPriority"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CPUAffinity"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CPUAffinityFromNUMA"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="NUMAPolicy"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="NUMAMask"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TimerSlackNSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CPUSchedulingResetOnFork"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="NonBlocking"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StandardInput"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StandardInputFileDescriptorName"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StandardInputData"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StandardOutput"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StandardOutputFileDescriptorName"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StandardError"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StandardErrorFileDescriptorName"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TTYPath"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TTYReset"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TTYVHangup"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TTYVTDisallocate"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TTYRows"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TTYColumns"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SyslogPriority"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SyslogIdentifier"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SyslogLevelPrefix"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SyslogLevel"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SyslogFacility"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LogLevelMax"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LogRateLimitIntervalUSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LogRateLimitBurst"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LogExtraFields"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LogFilterPatterns"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LogNamespace"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SecureBits"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CapabilityBoundingSet"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="AmbientCapabilities"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="User"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Group"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DynamicUser"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SetLoginEnvironment"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RemoveIPC"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SetCredential"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SetCredentialEncrypted"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LoadCredential"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LoadCredentialEncrypted"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ImportCredential"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SupplementaryGroups"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="PAMName"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ReadWritePaths"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ReadOnlyPaths"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="InaccessiblePaths"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ExecPaths"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="NoExecPaths"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ExecSearchPath"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MountFlags"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="PrivateTmp"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="PrivateDevices"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ProtectClock"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ProtectKernelTunables"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ProtectKernelModules"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ProtectKernelLogs"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ProtectControlGroups"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="PrivateNetwork"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="PrivateUsers"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="PrivateMounts"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="PrivateIPC"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ProtectHome"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ProtectSystem"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SameProcessGroup"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="UtmpIdentifier"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="UtmpMode"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SELinuxContext"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="AppArmorProfile"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SmackProcessLabel"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IgnoreSIGPIPE"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="NoNewPrivileges"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SystemCallFilter"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SystemCallArchitectures"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SystemCallErrorNumber"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SystemCallLog"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Personality"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LockPersonality"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RestrictAddressFamilies"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RuntimeDirectorySymlink"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RuntimeDirectoryPreserve"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RuntimeDirectoryMode"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RuntimeDirectory"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StateDirectorySymlink"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StateDirectoryMode"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StateDirectory"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CacheDirectorySymlink"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CacheDirectoryMode"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CacheDirectory"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LogsDirectorySymlink"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LogsDirectoryMode"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LogsDirectory"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ConfigurationDirectoryMode"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ConfigurationDirectory"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TimeoutCleanUSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryDenyWriteExecute"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RestrictRealtime"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RestrictSUIDSGID"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RestrictNamespaces"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RestrictFileSystems"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="BindPaths"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="BindReadOnlyPaths"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TemporaryFileSystem"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MountAPIVFS"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="KeyringMode"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ProtectProc"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ProcSubset"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ProtectHostname"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryKSM"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="NetworkNamespacePath"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IPCNamespacePath"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RootImagePolicy"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MountImagePolicy"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ExtensionImagePolicy"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="KillMode"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="KillSignal"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RestartKillSignal"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="FinalKillSignal"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SendSIGKILL"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SendSIGHUP"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="WatchdogSignal"/>
+
+    <!--End of Autogenerated section-->
+
+    <refsect2>
+      <title>Properties</title>
+
+      <para>Most of the properties map directly to the corresponding settings in mount unit files. As mount
+      units invoke the <filename>/usr/bin/mount</filename> command, their bus objects include implicit
+      <varname>ExecMount</varname> (and similar) fields which contain information about processes to
+      execute. They also share most of the fields related to the execution context that Service objects
+      expose (see above). In addition to these properties there are the following:</para>
+
+      <para><varname>ControlPID</varname> contains the PID of the currently running
+      <filename>/usr/bin/mount</filename> or <filename>/usr/bin/umount</filename> command if there is one
+      running, otherwise 0.</para>
+
+      <para><varname>Result</varname> contains a value explaining why a mount unit failed if it failed. It
+      can take the values <literal>success</literal>, <literal>resources</literal>,
+      <literal>timeout</literal>, <literal>exit-code</literal>, <literal>signal</literal>, or
+      <literal>core-dump</literal> which have the identical meaning as the corresponding values of the
+      corresponding field of service unit objects (see above).</para>
+    </refsect2>
+  </refsect1>
+
+  <refsect1>
+    <title>Automount Unit Objects</title>
+
+    <para>All automount unit objects implement the
+    <interfacename>org.freedesktop.systemd1.Automount</interfacename> interface (described here) in addition
+    to the generic <interfacename>org.freedesktop.systemd1.Unit</interfacename> interface (see above).</para>
+
+    <programlisting executable="systemd" node="/org/freedesktop/systemd1/unit/proc_2dsys_2dfs_2dbinfmt_5fmisc_2eautomount" interface="org.freedesktop.systemd1.Automount">
+node /org/freedesktop/systemd1/unit/proc_2dsys_2dfs_2dbinfmt_5fmisc_2eautomount {
+  interface org.freedesktop.systemd1.Automount {
+    properties:
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s Where = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s ExtraOptions = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly u DirectoryMode = ...;
+      readonly s Result = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t TimeoutIdleUSec = ...;
+  };
+  interface org.freedesktop.DBus.Peer { ... };
+  interface org.freedesktop.DBus.Introspectable { ... };
+  interface org.freedesktop.DBus.Properties { ... };
+  interface org.freedesktop.systemd1.Unit { ... };
+};
+    </programlisting>
+
+    <!--property Where is not documented!-->
+
+    <!--property ExtraOptions is not documented!-->
+
+    <!--property DirectoryMode is not documented!-->
+
+    <!--property TimeoutIdleUSec is not documented!-->
+
+    <!--Autogenerated cross-references for systemd.directives, do not edit-->
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Unit"/>
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Automount"/>
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Unit"/>
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Automount"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Where"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ExtraOptions"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DirectoryMode"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Result"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TimeoutIdleUSec"/>
+
+    <!--End of Autogenerated section-->
+
+    <refsect2>
+      <title>Properties</title>
+
+      <para>Most of the properties map directly to the corresponding settings in the automount unit
+      files.</para>
+
+      <para><varname>Result</varname> knows the values <literal>success</literal> and
+      <literal>resources</literal> at this time. They have the same meanings as the corresponding values of
+      the corresponding field of the Service object.</para>
+    </refsect2>
+  </refsect1>
+
+
+  <refsect1>
+    <title>Timer Unit Objects</title>
+
+    <para>All timer unit objects implement the <interfacename>org.freedesktop.systemd1.Timer</interfacename>
+    interface (described here) in addition to the generic
+    <interfacename>org.freedesktop.systemd1.Unit</interfacename> interface (see above).</para>
+
+    <programlisting executable="systemd" node="/org/freedesktop/systemd1/unit/systemd_2dtmpfiles_2dclean_2etimer" interface="org.freedesktop.systemd1.Timer">
+node /org/freedesktop/systemd1/unit/systemd_2dtmpfiles_2dclean_2etimer {
+  interface org.freedesktop.systemd1.Timer {
+    properties:
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s Unit = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates")
+      readonly a(stt) TimersMonotonic = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates")
+      readonly a(sst) TimersCalendar = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b OnClockChange = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b OnTimezoneChange = ...;
+      readonly t NextElapseUSecRealtime = ...;
+      readonly t NextElapseUSecMonotonic = ...;
+      readonly t LastTriggerUSec = ...;
+      readonly t LastTriggerUSecMonotonic = ...;
+      readonly s Result = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t AccuracyUSec = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t RandomizedDelayUSec = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b FixedRandomDelay = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b Persistent = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b WakeSystem = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b RemainAfterElapse = ...;
+  };
+  interface org.freedesktop.DBus.Peer { ... };
+  interface org.freedesktop.DBus.Introspectable { ... };
+  interface org.freedesktop.DBus.Properties { ... };
+  interface org.freedesktop.systemd1.Unit { ... };
+};
+    </programlisting>
+
+    <!--property OnClockChange is not documented!-->
+
+    <!--property OnTimezoneChange is not documented!-->
+
+    <!--property LastTriggerUSec is not documented!-->
+
+    <!--property LastTriggerUSecMonotonic is not documented!-->
+
+    <!--property AccuracyUSec is not documented!-->
+
+    <!--property RandomizedDelayUSec is not documented!-->
+
+    <!--property FixedRandomDelay is not documented!-->
+
+    <!--property Persistent is not documented!-->
+
+    <!--property WakeSystem is not documented!-->
+
+    <!--property RemainAfterElapse is not documented!-->
+
+    <!--Autogenerated cross-references for systemd.directives, do not edit-->
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Unit"/>
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Timer"/>
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Unit"/>
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Timer"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Unit"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TimersMonotonic"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TimersCalendar"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="OnClockChange"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="OnTimezoneChange"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="NextElapseUSecRealtime"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="NextElapseUSecMonotonic"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LastTriggerUSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LastTriggerUSecMonotonic"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Result"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="AccuracyUSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RandomizedDelayUSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="FixedRandomDelay"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Persistent"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="WakeSystem"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RemainAfterElapse"/>
+
+    <!--End of Autogenerated section-->
+
+    <refsect2>
+      <title>Properties</title>
+
+      <para><varname>Unit</varname> contains the name of the unit to activate when the timer elapses.</para>
+
+      <para><varname>TimersMonotonic</varname> contains an array of structs that contain information about
+      all monotonic timers of this timer unit. The structs contain a string identifying the timer base, which
+      is one of <literal>OnActiveUSec</literal>, <literal>OnBootUSec</literal>,
+      <literal>OnStartupUSec</literal>, <literal>OnUnitActiveUSec</literal>, or
+      <literal>OnUnitInactiveUSec</literal> which correspond to the settings of the same names in the timer
+      unit files; the microsecond offset from this timer base in monotonic time; the next elapsation point on
+      the <constant>CLOCK_MONOTONIC</constant> clock, relative to its epoch.</para>
+
+      <para><varname>TimersCalendar</varname> contains an array of structs that contain information about all
+      realtime/calendar timers of this timer unit. The structs contain a string identifying the timer base,
+      which may only be <literal>OnCalendar</literal> for now; the calendar specification string; the next
+      elapsation point on the <constant>CLOCK_REALTIME</constant> clock, relative to its epoch.</para>
+
+      <para><varname>NextElapseUSecRealtime</varname> contains the next elapsation point on the
+      <constant>CLOCK_REALTIME</constant> clock in miscroseconds since the epoch, or 0 if this timer event
+      does not include at least one calendar event.</para>
+
+      <para>Similarly, <varname>NextElapseUSecMonotonic</varname> contains the next elapsation point on the
+      <constant>CLOCK_MONOTONIC</constant> clock in microseconds since the epoch, or 0 if this timer event
+      does not include at least one monotonic event.</para>
+
+      <para><varname>Result</varname> knows the values <literal>success</literal> and
+      <literal>resources</literal> with the same meanings as the matching values of the corresponding
+      property of the service interface.</para>
+    </refsect2>
+  </refsect1>
+
+  <refsect1>
+    <title>Swap Unit Objects</title>
+
+    <para>All swap unit objects implement the <interfacename>org.freedesktop.systemd1.Swap</interfacename>
+    interface (described here) in addition to the generic
+    <interfacename>org.freedesktop.systemd1.Unit</interfacename> interface (see above).</para>
+
+    <programlisting executable="systemd" node="/org/freedesktop/systemd1/unit/dev_2dsda3_2eswap" interface="org.freedesktop.systemd1.Swap">
+node /org/freedesktop/systemd1/unit/dev_2dsda3_2eswap {
+  interface org.freedesktop.systemd1.Swap {
+    methods:
+      GetProcesses(out a(sus) processes);
+      AttachProcesses(in  s subcgroup,
+                      in  au pids);
+    properties:
+      readonly s What = '...';
+      readonly i Priority = ...;
+      readonly s Options = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t TimeoutUSec = ...;
+      readonly u ControlPID = ...;
+      readonly s Result = '...';
+      readonly u UID = ...;
+      readonly u GID = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates")
+      readonly a(sasbttttuii) ExecActivate = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("invalidates")
+      readonly a(sasbttttuii) ExecDeactivate = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s Slice = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s ControlGroup = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t ControlGroupId = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemoryCurrent = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemoryPeak = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemorySwapCurrent = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemorySwapPeak = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemoryZSwapCurrent = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemoryAvailable = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t CPUUsageNSec = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly ay EffectiveCPUs = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly ay EffectiveMemoryNodes = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t TasksCurrent = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t IPIngressBytes = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t IPIngressPackets = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t IPEgressBytes = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t IPEgressPackets = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t IOReadBytes = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t IOReadOperations = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t IOWriteBytes = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t IOWriteOperations = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly b Delegate = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly as DelegateControllers = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s DelegateSubgroup = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly b CPUAccounting = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t CPUWeight = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t StartupCPUWeight = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t CPUShares = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t StartupCPUShares = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t CPUQuotaPerSecUSec = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t CPUQuotaPeriodUSec = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly ay AllowedCPUs = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly ay StartupAllowedCPUs = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly ay AllowedMemoryNodes = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly ay StartupAllowedMemoryNodes = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly b IOAccounting = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t IOWeight = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t StartupIOWeight = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(st) IODeviceWeight = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(st) IOReadBandwidthMax = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(st) IOWriteBandwidthMax = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(st) IOReadIOPSMax = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(st) IOWriteIOPSMax = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(st) IODeviceLatencyTargetUSec = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly b BlockIOAccounting = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t BlockIOWeight = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t StartupBlockIOWeight = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(st) BlockIODeviceWeight = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(st) BlockIOReadBandwidth = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(st) BlockIOWriteBandwidth = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly b MemoryAccounting = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t DefaultMemoryLow = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t DefaultStartupMemoryLow = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t DefaultMemoryMin = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemoryMin = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemoryLow = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t StartupMemoryLow = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemoryHigh = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t StartupMemoryHigh = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemoryMax = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t StartupMemoryMax = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemorySwapMax = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t StartupMemorySwapMax = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemoryZSwapMax = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t StartupMemoryZSwapMax = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemoryLimit = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s DevicePolicy = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(ss) DeviceAllow = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly b TasksAccounting = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t TasksMax = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly b IPAccounting = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(iayu) IPAddressAllow = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(iayu) IPAddressDeny = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly as IPIngressFilterPath = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly as IPEgressFilterPath = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly as DisableControllers = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s ManagedOOMSwap = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s ManagedOOMMemoryPressure = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly u ManagedOOMMemoryPressureLimit = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s ManagedOOMPreference = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(ss) BPFProgram = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(iiqq) SocketBindAllow = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(iiqq) SocketBindDeny = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly (bas) RestrictNetworkInterfaces = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s MemoryPressureWatch = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemoryPressureThresholdUSec = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(iiss) NFTSet = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly b CoredumpReceive = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as Environment = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly a(sb) EnvironmentFiles = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as PassEnvironment = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as UnsetEnvironment = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly u UMask = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitCPU = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitCPUSoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitFSIZE = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitFSIZESoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitDATA = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitDATASoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitSTACK = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitSTACKSoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitCORE = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitCORESoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitRSS = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitRSSSoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitNOFILE = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitNOFILESoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitAS = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitASSoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitNPROC = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitNPROCSoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitMEMLOCK = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitMEMLOCKSoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitLOCKS = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitLOCKSSoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitSIGPENDING = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitSIGPENDINGSoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitMSGQUEUE = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitMSGQUEUESoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitNICE = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitNICESoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitRTPRIO = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitRTPRIOSoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitRTTIME = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LimitRTTIMESoft = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s WorkingDirectory = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s RootDirectory = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s RootImage = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly a(ss) RootImageOptions = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly ay RootHash = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s RootHashPath = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly ay RootHashSignature = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s RootHashSignaturePath = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s RootVerity = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b RootEphemeral = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as ExtensionDirectories = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly a(sba(ss)) ExtensionImages = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly a(ssba(ss)) MountImages = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i OOMScoreAdjust = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t CoredumpFilter = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i Nice = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i IOSchedulingClass = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i IOSchedulingPriority = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i CPUSchedulingPolicy = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i CPUSchedulingPriority = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly ay CPUAffinity = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b CPUAffinityFromNUMA = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i NUMAPolicy = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly ay NUMAMask = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t TimerSlackNSec = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b CPUSchedulingResetOnFork = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b NonBlocking = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s StandardInput = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s StandardInputFileDescriptorName = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly ay StandardInputData = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s StandardOutput = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s StandardOutputFileDescriptorName = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s StandardError = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s StandardErrorFileDescriptorName = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s TTYPath = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b TTYReset = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b TTYVHangup = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b TTYVTDisallocate = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly q TTYRows = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly q TTYColumns = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i SyslogPriority = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s SyslogIdentifier = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b SyslogLevelPrefix = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i SyslogLevel = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i SyslogFacility = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i LogLevelMax = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t LogRateLimitIntervalUSec = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly u LogRateLimitBurst = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly aay LogExtraFields = [[...], ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly a(bs) LogFilterPatterns = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s LogNamespace = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i SecureBits = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t CapabilityBoundingSet = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t AmbientCapabilities = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s User = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s Group = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b DynamicUser = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b SetLoginEnvironment = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b RemoveIPC = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly a(say) SetCredential = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly a(say) SetCredentialEncrypted = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly a(ss) LoadCredential = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly a(ss) LoadCredentialEncrypted = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as ImportCredential = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as SupplementaryGroups = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s PAMName = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as ReadWritePaths = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as ReadOnlyPaths = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as InaccessiblePaths = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as ExecPaths = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as NoExecPaths = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as ExecSearchPath = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t MountFlags = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b PrivateTmp = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b PrivateDevices = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b ProtectClock = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b ProtectKernelTunables = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b ProtectKernelModules = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b ProtectKernelLogs = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b ProtectControlGroups = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b PrivateNetwork = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b PrivateUsers = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b PrivateMounts = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b PrivateIPC = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s ProtectHome = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s ProtectSystem = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b SameProcessGroup = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s UtmpIdentifier = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s UtmpMode = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly (bs) SELinuxContext = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly (bs) AppArmorProfile = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly (bs) SmackProcessLabel = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b IgnoreSIGPIPE = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b NoNewPrivileges = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly (bas) SystemCallFilter = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as SystemCallArchitectures = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i SystemCallErrorNumber = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly (bas) SystemCallLog = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s Personality = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b LockPersonality = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly (bas) RestrictAddressFamilies = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly a(sst) RuntimeDirectorySymlink = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s RuntimeDirectoryPreserve = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly u RuntimeDirectoryMode = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as RuntimeDirectory = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly a(sst) StateDirectorySymlink = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly u StateDirectoryMode = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as StateDirectory = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly a(sst) CacheDirectorySymlink = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly u CacheDirectoryMode = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as CacheDirectory = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly a(sst) LogsDirectorySymlink = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly u LogsDirectoryMode = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as LogsDirectory = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly u ConfigurationDirectoryMode = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly as ConfigurationDirectory = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t TimeoutCleanUSec = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b MemoryDenyWriteExecute = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b RestrictRealtime = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b RestrictSUIDSGID = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t RestrictNamespaces = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly (bas) RestrictFileSystems = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly a(ssbt) BindPaths = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly a(ssbt) BindReadOnlyPaths = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly a(ss) TemporaryFileSystem = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b MountAPIVFS = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s KeyringMode = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s ProtectProc = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s ProcSubset = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b ProtectHostname = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b MemoryKSM = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s NetworkNamespacePath = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s IPCNamespacePath = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s RootImagePolicy = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s MountImagePolicy = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s ExtensionImagePolicy = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s KillMode = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i KillSignal = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i RestartKillSignal = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i FinalKillSignal = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b SendSIGKILL = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b SendSIGHUP = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i WatchdogSignal = ...;
+  };
+  interface org.freedesktop.DBus.Peer { ... };
+  interface org.freedesktop.DBus.Introspectable { ... };
+  interface org.freedesktop.DBus.Properties { ... };
+  interface org.freedesktop.systemd1.Unit { ... };
+};
+    </programlisting>
+
+    <!--method GetProcesses is not documented!-->
+
+    <!--method AttachProcesses is not documented!-->
+
+    <!--property What is not documented!-->
+
+    <!--property Priority is not documented!-->
+
+    <!--property Options is not documented!-->
+
+    <!--property TimeoutUSec is not documented!-->
+
+    <!--property UID is not documented!-->
+
+    <!--property GID is not documented!-->
+
+    <!--property ExecDeactivate is not documented!-->
+
+    <!--property Slice is not documented!-->
+
+    <!--property ControlGroupId is not documented!-->
+
+    <!--property MemoryCurrent is not documented!-->
+
+    <!--property MemoryPeak is not documented!-->
+
+    <!--property MemorySwapCurrent is not documented!-->
+
+    <!--property MemorySwapPeak is not documented!-->
+
+    <!--property MemoryZSwapCurrent is not documented!-->
+
+    <!--property CPUUsageNSec is not documented!-->
+
+    <!--property EffectiveCPUs is not documented!-->
+
+    <!--property EffectiveMemoryNodes is not documented!-->
+
+    <!--property TasksCurrent is not documented!-->
+
+    <!--property IPIngressBytes is not documented!-->
+
+    <!--property IPIngressPackets is not documented!-->
+
+    <!--property IPEgressBytes is not documented!-->
+
+    <!--property IPEgressPackets is not documented!-->
+
+    <!--property IOReadBytes is not documented!-->
+
+    <!--property IOReadOperations is not documented!-->
+
+    <!--property IOWriteBytes is not documented!-->
+
+    <!--property IOWriteOperations is not documented!-->
+
+    <!--property Delegate is not documented!-->
+
+    <!--property DelegateControllers is not documented!-->
+
+    <!--property CPUAccounting is not documented!-->
+
+    <!--property CPUWeight is not documented!-->
+
+    <!--property StartupCPUWeight is not documented!-->
+
+    <!--property CPUShares is not documented!-->
+
+    <!--property StartupCPUShares is not documented!-->
+
+    <!--property CPUQuotaPerSecUSec is not documented!-->
+
+    <!--property CPUQuotaPeriodUSec is not documented!-->
+
+    <!--property AllowedCPUs is not documented!-->
+
+    <!--property StartupAllowedCPUs is not documented!-->
+
+    <!--property AllowedMemoryNodes is not documented!-->
+
+    <!--property StartupAllowedMemoryNodes is not documented!-->
+
+    <!--property IOAccounting is not documented!-->
+
+    <!--property IOWeight is not documented!-->
+
+    <!--property StartupIOWeight is not documented!-->
+
+    <!--property IODeviceWeight is not documented!-->
+
+    <!--property IOReadBandwidthMax is not documented!-->
+
+    <!--property IOWriteBandwidthMax is not documented!-->
+
+    <!--property IOReadIOPSMax is not documented!-->
+
+    <!--property IOWriteIOPSMax is not documented!-->
+
+    <!--property IODeviceLatencyTargetUSec is not documented!-->
+
+    <!--property BlockIOAccounting is not documented!-->
+
+    <!--property BlockIOWeight is not documented!-->
+
+    <!--property StartupBlockIOWeight is not documented!-->
+
+    <!--property BlockIODeviceWeight is not documented!-->
+
+    <!--property BlockIOReadBandwidth is not documented!-->
+
+    <!--property BlockIOWriteBandwidth is not documented!-->
+
+    <!--property MemoryAccounting is not documented!-->
+
+    <!--property DefaultMemoryLow is not documented!-->
+
+    <!--property DefaultStartupMemoryLow is not documented!-->
+
+    <!--property DefaultMemoryMin is not documented!-->
+
+    <!--property MemoryMin is not documented!-->
+
+    <!--property MemoryLow is not documented!-->
+
+    <!--property StartupMemoryLow is not documented!-->
+
+    <!--property MemoryHigh is not documented!-->
+
+    <!--property StartupMemoryHigh is not documented!-->
+
+    <!--property MemoryMax is not documented!-->
+
+    <!--property StartupMemoryMax is not documented!-->
+
+    <!--property MemorySwapMax is not documented!-->
+
+    <!--property StartupMemorySwapMax is not documented!-->
+
+    <!--property MemoryZSwapMax is not documented!-->
+
+    <!--property StartupMemoryZSwapMax is not documented!-->
+
+    <!--property MemoryLimit is not documented!-->
+
+    <!--property DevicePolicy is not documented!-->
+
+    <!--property DeviceAllow is not documented!-->
+
+    <!--property TasksAccounting is not documented!-->
+
+    <!--property TasksMax is not documented!-->
+
+    <!--property IPAccounting is not documented!-->
+
+    <!--property IPAddressAllow is not documented!-->
+
+    <!--property IPAddressDeny is not documented!-->
+
+    <!--property IPIngressFilterPath is not documented!-->
+
+    <!--property IPEgressFilterPath is not documented!-->
+
+    <!--property DisableControllers is not documented!-->
+
+    <!--property ManagedOOMSwap is not documented!-->
+
+    <!--property ManagedOOMMemoryPressure is not documented!-->
+
+    <!--property ManagedOOMMemoryPressureLimit is not documented!-->
+
+    <!--property ManagedOOMPreference is not documented!-->
+
+    <!--property BPFProgram is not documented!-->
+
+    <!--property SocketBindAllow is not documented!-->
+
+    <!--property SocketBindDeny is not documented!-->
+
+    <!--property RestrictNetworkInterfaces is not documented!-->
+
+    <!--property MemoryPressureWatch is not documented!-->
+
+    <!--property MemoryPressureThresholdUSec is not documented!-->
+
+    <!--property NFTSet is not documented!-->
+
+    <!--property CoredumpReceive is not documented!-->
+
+    <!--property EnvironmentFiles is not documented!-->
+
+    <!--property PassEnvironment is not documented!-->
+
+    <!--property UnsetEnvironment is not documented!-->
+
+    <!--property UMask is not documented!-->
+
+    <!--property LimitCPUSoft is not documented!-->
+
+    <!--property LimitFSIZE is not documented!-->
+
+    <!--property LimitFSIZESoft is not documented!-->
+
+    <!--property LimitDATA is not documented!-->
+
+    <!--property LimitDATASoft is not documented!-->
+
+    <!--property LimitSTACK is not documented!-->
+
+    <!--property LimitSTACKSoft is not documented!-->
+
+    <!--property LimitCORE is not documented!-->
+
+    <!--property LimitCORESoft is not documented!-->
+
+    <!--property LimitRSS is not documented!-->
+
+    <!--property LimitRSSSoft is not documented!-->
+
+    <!--property LimitNOFILE is not documented!-->
+
+    <!--property LimitNOFILESoft is not documented!-->
+
+    <!--property LimitAS is not documented!-->
+
+    <!--property LimitASSoft is not documented!-->
+
+    <!--property LimitNPROC is not documented!-->
+
+    <!--property LimitNPROCSoft is not documented!-->
+
+    <!--property LimitMEMLOCK is not documented!-->
+
+    <!--property LimitMEMLOCKSoft is not documented!-->
+
+    <!--property LimitLOCKS is not documented!-->
+
+    <!--property LimitLOCKSSoft is not documented!-->
+
+    <!--property LimitSIGPENDING is not documented!-->
+
+    <!--property LimitSIGPENDINGSoft is not documented!-->
+
+    <!--property LimitMSGQUEUE is not documented!-->
+
+    <!--property LimitMSGQUEUESoft is not documented!-->
+
+    <!--property LimitNICE is not documented!-->
+
+    <!--property LimitNICESoft is not documented!-->
+
+    <!--property LimitRTPRIO is not documented!-->
+
+    <!--property LimitRTPRIOSoft is not documented!-->
+
+    <!--property LimitRTTIME is not documented!-->
+
+    <!--property LimitRTTIMESoft is not documented!-->
+
+    <!--property WorkingDirectory is not documented!-->
+
+    <!--property RootHashPath is not documented!-->
+
+    <!--property RootHashSignaturePath is not documented!-->
+
+    <!--property RootEphemeral is not documented!-->
+
+    <!--property OOMScoreAdjust is not documented!-->
+
+    <!--property CoredumpFilter is not documented!-->
+
+    <!--property Nice is not documented!-->
+
+    <!--property IOSchedulingClass is not documented!-->
+
+    <!--property IOSchedulingPriority is not documented!-->
+
+    <!--property CPUSchedulingPolicy is not documented!-->
+
+    <!--property CPUSchedulingPriority is not documented!-->
+
+    <!--property CPUAffinity is not documented!-->
+
+    <!--property CPUAffinityFromNUMA is not documented!-->
+
+    <!--property NUMAPolicy is not documented!-->
+
+    <!--property NUMAMask is not documented!-->
+
+    <!--property TimerSlackNSec is not documented!-->
+
+    <!--property CPUSchedulingResetOnFork is not documented!-->
+
+    <!--property NonBlocking is not documented!-->
+
+    <!--property StandardInput is not documented!-->
+
+    <!--property StandardInputFileDescriptorName is not documented!-->
+
+    <!--property StandardInputData is not documented!-->
+
+    <!--property StandardOutput is not documented!-->
+
+    <!--property StandardOutputFileDescriptorName is not documented!-->
+
+    <!--property StandardError is not documented!-->
+
+    <!--property StandardErrorFileDescriptorName is not documented!-->
+
+    <!--property TTYPath is not documented!-->
+
+    <!--property TTYReset is not documented!-->
+
+    <!--property TTYVHangup is not documented!-->
+
+    <!--property TTYVTDisallocate is not documented!-->
+
+    <!--property TTYRows is not documented!-->
+
+    <!--property TTYColumns is not documented!-->
+
+    <!--property SyslogPriority is not documented!-->
+
+    <!--property SyslogIdentifier is not documented!-->
+
+    <!--property SyslogLevelPrefix is not documented!-->
+
+    <!--property SyslogLevel is not documented!-->
+
+    <!--property SyslogFacility is not documented!-->
+
+    <!--property LogLevelMax is not documented!-->
+
+    <!--property LogRateLimitIntervalUSec is not documented!-->
+
+    <!--property LogRateLimitBurst is not documented!-->
+
+    <!--property LogExtraFields is not documented!-->
+
+    <!--property LogFilterPatterns is not documented!-->
+
+    <!--property LogNamespace is not documented!-->
+
+    <!--property AmbientCapabilities is not documented!-->
+
+    <!--property User is not documented!-->
+
+    <!--property Group is not documented!-->
+
+    <!--property DynamicUser is not documented!-->
+
+    <!--property SetLoginEnvironment is not documented!-->
+
+    <!--property RemoveIPC is not documented!-->
+
+    <!--property SetCredential is not documented!-->
+
+    <!--property SetCredentialEncrypted is not documented!-->
+
+    <!--property LoadCredential is not documented!-->
+
+    <!--property LoadCredentialEncrypted is not documented!-->
+
+    <!--property ImportCredential is not documented!-->
+
+    <!--property SupplementaryGroups is not documented!-->
+
+    <!--property PAMName is not documented!-->
+
+    <!--property ReadWritePaths is not documented!-->
+
+    <!--property ReadOnlyPaths is not documented!-->
+
+    <!--property InaccessiblePaths is not documented!-->
+
+    <!--property ExecPaths is not documented!-->
+
+    <!--property NoExecPaths is not documented!-->
+
+    <!--property ExecSearchPath is not documented!-->
+
+    <!--property PrivateTmp is not documented!-->
+
+    <!--property PrivateDevices is not documented!-->
+
+    <!--property ProtectClock is not documented!-->
+
+    <!--property ProtectKernelTunables is not documented!-->
+
+    <!--property ProtectKernelModules is not documented!-->
+
+    <!--property ProtectKernelLogs is not documented!-->
+
+    <!--property ProtectControlGroups is not documented!-->
+
+    <!--property PrivateNetwork is not documented!-->
+
+    <!--property PrivateUsers is not documented!-->
+
+    <!--property PrivateMounts is not documented!-->
+
+    <!--property PrivateIPC is not documented!-->
+
+    <!--property ProtectHome is not documented!-->
+
+    <!--property ProtectSystem is not documented!-->
+
+    <!--property SameProcessGroup is not documented!-->
+
+    <!--property UtmpIdentifier is not documented!-->
+
+    <!--property UtmpMode is not documented!-->
+
+    <!--property SELinuxContext is not documented!-->
+
+    <!--property AppArmorProfile is not documented!-->
+
+    <!--property SmackProcessLabel is not documented!-->
+
+    <!--property IgnoreSIGPIPE is not documented!-->
+
+    <!--property NoNewPrivileges is not documented!-->
+
+    <!--property SystemCallFilter is not documented!-->
+
+    <!--property SystemCallArchitectures is not documented!-->
+
+    <!--property SystemCallErrorNumber is not documented!-->
+
+    <!--property SystemCallLog is not documented!-->
+
+    <!--property Personality is not documented!-->
+
+    <!--property LockPersonality is not documented!-->
+
+    <!--property RestrictAddressFamilies is not documented!-->
+
+    <!--property RuntimeDirectoryPreserve is not documented!-->
+
+    <!--property RuntimeDirectoryMode is not documented!-->
+
+    <!--property StateDirectoryMode is not documented!-->
+
+    <!--property CacheDirectoryMode is not documented!-->
+
+    <!--property LogsDirectoryMode is not documented!-->
+
+    <!--property ConfigurationDirectoryMode is not documented!-->
+
+    <!--property ConfigurationDirectory is not documented!-->
+
+    <!--property TimeoutCleanUSec is not documented!-->
+
+    <!--property MemoryDenyWriteExecute is not documented!-->
+
+    <!--property RestrictRealtime is not documented!-->
+
+    <!--property RestrictSUIDSGID is not documented!-->
+
+    <!--property RestrictNamespaces is not documented!-->
+
+    <!--property RestrictFileSystems is not documented!-->
+
+    <!--property BindPaths is not documented!-->
+
+    <!--property BindReadOnlyPaths is not documented!-->
+
+    <!--property TemporaryFileSystem is not documented!-->
+
+    <!--property MountAPIVFS is not documented!-->
+
+    <!--property KeyringMode is not documented!-->
+
+    <!--property ProtectProc is not documented!-->
+
+    <!--property ProcSubset is not documented!-->
+
+    <!--property ProtectHostname is not documented!-->
+
+    <!--property MemoryKSM is not documented!-->
+
+    <!--property NetworkNamespacePath is not documented!-->
+
+    <!--property IPCNamespacePath is not documented!-->
+
+    <!--property RootImagePolicy is not documented!-->
+
+    <!--property MountImagePolicy is not documented!-->
+
+    <!--property ExtensionImagePolicy is not documented!-->
+
+    <!--property KillMode is not documented!-->
+
+    <!--property KillSignal is not documented!-->
+
+    <!--property RestartKillSignal is not documented!-->
+
+    <!--property FinalKillSignal is not documented!-->
+
+    <!--property SendSIGKILL is not documented!-->
+
+    <!--property SendSIGHUP is not documented!-->
+
+    <!--property WatchdogSignal is not documented!-->
+
+    <!--Autogenerated cross-references for systemd.directives, do not edit-->
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Unit"/>
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Swap"/>
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Unit"/>
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Swap"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="GetProcesses()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="AttachProcesses()"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="What"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Priority"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Options"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TimeoutUSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ControlPID"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Result"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="UID"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="GID"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ExecActivate"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ExecDeactivate"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Slice"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ControlGroup"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ControlGroupId"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryCurrent"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryPeak"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemorySwapCurrent"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemorySwapPeak"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryZSwapCurrent"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryAvailable"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CPUUsageNSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="EffectiveCPUs"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="EffectiveMemoryNodes"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TasksCurrent"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IPIngressBytes"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IPIngressPackets"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IPEgressBytes"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IPEgressPackets"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IOReadBytes"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IOReadOperations"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IOWriteBytes"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IOWriteOperations"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Delegate"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DelegateControllers"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DelegateSubgroup"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CPUAccounting"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CPUWeight"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StartupCPUWeight"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CPUShares"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StartupCPUShares"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CPUQuotaPerSecUSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CPUQuotaPeriodUSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="AllowedCPUs"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StartupAllowedCPUs"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="AllowedMemoryNodes"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StartupAllowedMemoryNodes"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IOAccounting"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IOWeight"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StartupIOWeight"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IODeviceWeight"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IOReadBandwidthMax"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IOWriteBandwidthMax"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IOReadIOPSMax"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IOWriteIOPSMax"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IODeviceLatencyTargetUSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="BlockIOAccounting"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="BlockIOWeight"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StartupBlockIOWeight"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="BlockIODeviceWeight"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="BlockIOReadBandwidth"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="BlockIOWriteBandwidth"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryAccounting"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DefaultMemoryLow"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DefaultStartupMemoryLow"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DefaultMemoryMin"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryMin"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryLow"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StartupMemoryLow"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryHigh"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StartupMemoryHigh"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryMax"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StartupMemoryMax"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemorySwapMax"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StartupMemorySwapMax"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryZSwapMax"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StartupMemoryZSwapMax"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryLimit"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DevicePolicy"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DeviceAllow"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TasksAccounting"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TasksMax"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IPAccounting"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IPAddressAllow"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IPAddressDeny"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IPIngressFilterPath"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IPEgressFilterPath"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DisableControllers"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ManagedOOMSwap"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ManagedOOMMemoryPressure"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ManagedOOMMemoryPressureLimit"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ManagedOOMPreference"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="BPFProgram"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SocketBindAllow"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SocketBindDeny"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RestrictNetworkInterfaces"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryPressureWatch"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryPressureThresholdUSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="NFTSet"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CoredumpReceive"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Environment"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="EnvironmentFiles"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="PassEnvironment"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="UnsetEnvironment"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="UMask"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitCPU"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitCPUSoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitFSIZE"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitFSIZESoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitDATA"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitDATASoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitSTACK"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitSTACKSoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitCORE"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitCORESoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitRSS"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitRSSSoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitNOFILE"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitNOFILESoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitAS"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitASSoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitNPROC"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitNPROCSoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitMEMLOCK"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitMEMLOCKSoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitLOCKS"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitLOCKSSoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitSIGPENDING"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitSIGPENDINGSoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitMSGQUEUE"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitMSGQUEUESoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitNICE"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitNICESoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitRTPRIO"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitRTPRIOSoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitRTTIME"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LimitRTTIMESoft"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="WorkingDirectory"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RootDirectory"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RootImage"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RootImageOptions"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RootHash"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RootHashPath"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RootHashSignature"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RootHashSignaturePath"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RootVerity"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RootEphemeral"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ExtensionDirectories"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ExtensionImages"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MountImages"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="OOMScoreAdjust"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CoredumpFilter"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Nice"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IOSchedulingClass"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IOSchedulingPriority"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CPUSchedulingPolicy"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CPUSchedulingPriority"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CPUAffinity"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CPUAffinityFromNUMA"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="NUMAPolicy"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="NUMAMask"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TimerSlackNSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CPUSchedulingResetOnFork"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="NonBlocking"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StandardInput"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StandardInputFileDescriptorName"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StandardInputData"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StandardOutput"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StandardOutputFileDescriptorName"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StandardError"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StandardErrorFileDescriptorName"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TTYPath"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TTYReset"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TTYVHangup"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TTYVTDisallocate"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TTYRows"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TTYColumns"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SyslogPriority"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SyslogIdentifier"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SyslogLevelPrefix"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SyslogLevel"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SyslogFacility"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LogLevelMax"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LogRateLimitIntervalUSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LogRateLimitBurst"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LogExtraFields"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LogFilterPatterns"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LogNamespace"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SecureBits"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CapabilityBoundingSet"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="AmbientCapabilities"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="User"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Group"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DynamicUser"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SetLoginEnvironment"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RemoveIPC"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SetCredential"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SetCredentialEncrypted"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LoadCredential"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LoadCredentialEncrypted"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ImportCredential"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SupplementaryGroups"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="PAMName"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ReadWritePaths"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ReadOnlyPaths"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="InaccessiblePaths"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ExecPaths"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="NoExecPaths"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ExecSearchPath"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MountFlags"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="PrivateTmp"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="PrivateDevices"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ProtectClock"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ProtectKernelTunables"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ProtectKernelModules"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ProtectKernelLogs"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ProtectControlGroups"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="PrivateNetwork"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="PrivateUsers"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="PrivateMounts"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="PrivateIPC"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ProtectHome"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ProtectSystem"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SameProcessGroup"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="UtmpIdentifier"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="UtmpMode"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SELinuxContext"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="AppArmorProfile"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SmackProcessLabel"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IgnoreSIGPIPE"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="NoNewPrivileges"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SystemCallFilter"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SystemCallArchitectures"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SystemCallErrorNumber"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SystemCallLog"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Personality"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LockPersonality"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RestrictAddressFamilies"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RuntimeDirectorySymlink"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RuntimeDirectoryPreserve"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RuntimeDirectoryMode"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RuntimeDirectory"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StateDirectorySymlink"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StateDirectoryMode"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StateDirectory"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CacheDirectorySymlink"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CacheDirectoryMode"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CacheDirectory"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LogsDirectorySymlink"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LogsDirectoryMode"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LogsDirectory"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ConfigurationDirectoryMode"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ConfigurationDirectory"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TimeoutCleanUSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryDenyWriteExecute"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RestrictRealtime"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RestrictSUIDSGID"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RestrictNamespaces"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RestrictFileSystems"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="BindPaths"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="BindReadOnlyPaths"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TemporaryFileSystem"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MountAPIVFS"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="KeyringMode"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ProtectProc"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ProcSubset"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ProtectHostname"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryKSM"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="NetworkNamespacePath"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IPCNamespacePath"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RootImagePolicy"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MountImagePolicy"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ExtensionImagePolicy"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="KillMode"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="KillSignal"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RestartKillSignal"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="FinalKillSignal"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SendSIGKILL"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SendSIGHUP"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="WatchdogSignal"/>
+
+    <!--End of Autogenerated section-->
+
+    <refsect2>
+      <title>Properties</title>
+
+      <para>Most of the properties map directly to the corresponding settings in swap unit files. As mount
+      units invoke the
+      <citerefentry project="man-pages"><refentrytitle>swapon</refentrytitle><manvolnum>8</manvolnum></citerefentry> command,
+      their bus objects include implicit <varname>ExecActivate</varname> (and similar) fields which contain
+      information about processes to execute. They also share most of the fields related to the execution
+      context that Service objects expose (see above). In addition to these properties there are the
+      following:</para>
+
+      <para><varname>ControlPID</varname> contains the PID of the currently running
+      <citerefentry project="man-pages"><refentrytitle>swapon</refentrytitle><manvolnum>8</manvolnum></citerefentry> or
+      <citerefentry project="man-pages"><refentrytitle>swapoff</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+      command if there is one running, otherwise 0.</para>
+
+      <para><varname>Result</varname> contains a value explaining why a mount unit failed if it failed. It
+      can take the values <literal>success</literal>, <literal>resources</literal>,
+      <literal>timeout</literal>, <literal>exit-code</literal>, <literal>signal</literal>, or
+      <literal>core-dump</literal> which have the identical meanings as the corresponding values of the
+      corresponding field of service unit objects (see above).</para>
+    </refsect2>
+  </refsect1>
+
+
+  <refsect1>
+    <title>Path Unit Objects</title>
+
+    <programlisting executable="systemd" node="/org/freedesktop/systemd1/unit/cups_2epath" interface="org.freedesktop.systemd1.Path">
+node /org/freedesktop/systemd1/unit/cups_2epath {
+  interface org.freedesktop.systemd1.Path {
+    properties:
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s Unit = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly a(ss) Paths = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b MakeDirectory = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly u DirectoryMode = ...;
+      readonly s Result = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t TriggerLimitIntervalUSec = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly u TriggerLimitBurst = ...;
+  };
+  interface org.freedesktop.DBus.Peer { ... };
+  interface org.freedesktop.DBus.Introspectable { ... };
+  interface org.freedesktop.DBus.Properties { ... };
+  interface org.freedesktop.systemd1.Unit { ... };
+};
+    </programlisting>
+
+    <!--property MakeDirectory is not documented!-->
+
+    <!--property DirectoryMode is not documented!-->
+
+    <!--property TriggerLimitIntervalUSec is not documented!-->
+
+    <!--property TriggerLimitBurst is not documented!-->
+
+    <!--Autogenerated cross-references for systemd.directives, do not edit-->
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Unit"/>
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Path"/>
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Unit"/>
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Path"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Unit"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Paths"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MakeDirectory"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DirectoryMode"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Result"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TriggerLimitIntervalUSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TriggerLimitBurst"/>
+
+    <!--End of Autogenerated section-->
+
+    <refsect2>
+      <title>Properties</title>
+
+      <para>Most properties correspond directly with the matching settings in path unit files.</para>
+
+      <para>The others:</para>
+
+      <para><varname>Paths</varname> contains an array of structs. Each struct contains the condition to
+      watch, which can be one of <literal>PathExists</literal>, <literal>PathExistsGlob</literal>,
+      <literal>PathChanged</literal>, <literal>PathModified</literal>, or <literal>DirectoryNotEmpty</literal>
+      which correspond directly to the matching settings in the path unit files; and the path to watch,
+      possibly including glob expressions.</para>
+
+      <para><varname>Result</varname> contains a result value which can be <literal>success</literal> or
+      <literal>resources</literal> which have the same meaning as the corresponding field of the Service
+      interface.</para>
+    </refsect2>
+  </refsect1>
+
+  <refsect1>
+    <title>Slice Unit Objects</title>
+
+    <para>All slice unit objects implement the <interfacename>org.freedesktop.systemd1.Slice</interfacename>
+    interface (described here) in addition to the generic
+    <interfacename>org.freedesktop.systemd1.Unit</interfacename> interface (see above).</para>
+
+    <programlisting executable="systemd" node="/org/freedesktop/systemd1/unit/system_2eslice" interface="org.freedesktop.systemd1.Slice">
+node /org/freedesktop/systemd1/unit/system_2eslice {
+  interface org.freedesktop.systemd1.Slice {
+    methods:
+      GetProcesses(out a(sus) processes);
+      AttachProcesses(in  s subcgroup,
+                      in  au pids);
+    properties:
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s Slice = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s ControlGroup = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t ControlGroupId = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemoryCurrent = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemoryPeak = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemorySwapCurrent = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemorySwapPeak = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemoryZSwapCurrent = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemoryAvailable = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t CPUUsageNSec = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly ay EffectiveCPUs = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly ay EffectiveMemoryNodes = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t TasksCurrent = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t IPIngressBytes = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t IPIngressPackets = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t IPEgressBytes = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t IPEgressPackets = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t IOReadBytes = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t IOReadOperations = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t IOWriteBytes = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t IOWriteOperations = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly b Delegate = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly as DelegateControllers = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s DelegateSubgroup = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly b CPUAccounting = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t CPUWeight = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t StartupCPUWeight = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t CPUShares = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t StartupCPUShares = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t CPUQuotaPerSecUSec = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t CPUQuotaPeriodUSec = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly ay AllowedCPUs = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly ay StartupAllowedCPUs = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly ay AllowedMemoryNodes = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly ay StartupAllowedMemoryNodes = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly b IOAccounting = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t IOWeight = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t StartupIOWeight = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(st) IODeviceWeight = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(st) IOReadBandwidthMax = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(st) IOWriteBandwidthMax = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(st) IOReadIOPSMax = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(st) IOWriteIOPSMax = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(st) IODeviceLatencyTargetUSec = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly b BlockIOAccounting = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t BlockIOWeight = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t StartupBlockIOWeight = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(st) BlockIODeviceWeight = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(st) BlockIOReadBandwidth = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(st) BlockIOWriteBandwidth = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly b MemoryAccounting = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t DefaultMemoryLow = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t DefaultStartupMemoryLow = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t DefaultMemoryMin = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemoryMin = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemoryLow = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t StartupMemoryLow = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemoryHigh = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t StartupMemoryHigh = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemoryMax = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t StartupMemoryMax = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemorySwapMax = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t StartupMemorySwapMax = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemoryZSwapMax = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t StartupMemoryZSwapMax = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemoryLimit = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s DevicePolicy = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(ss) DeviceAllow = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly b TasksAccounting = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t TasksMax = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly b IPAccounting = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(iayu) IPAddressAllow = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(iayu) IPAddressDeny = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly as IPIngressFilterPath = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly as IPEgressFilterPath = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly as DisableControllers = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s ManagedOOMSwap = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s ManagedOOMMemoryPressure = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly u ManagedOOMMemoryPressureLimit = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s ManagedOOMPreference = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(ss) BPFProgram = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(iiqq) SocketBindAllow = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(iiqq) SocketBindDeny = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly (bas) RestrictNetworkInterfaces = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s MemoryPressureWatch = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemoryPressureThresholdUSec = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(iiss) NFTSet = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly b CoredumpReceive = ...;
+  };
+  interface org.freedesktop.DBus.Peer { ... };
+  interface org.freedesktop.DBus.Introspectable { ... };
+  interface org.freedesktop.DBus.Properties { ... };
+  interface org.freedesktop.systemd1.Unit { ... };
+};
+    </programlisting>
+
+    <!--method GetProcesses is not documented!-->
+
+    <!--method AttachProcesses is not documented!-->
+
+    <!--property Slice is not documented!-->
+
+    <!--property ControlGroupId is not documented!-->
+
+    <!--property MemoryCurrent is not documented!-->
+
+    <!--property MemoryPeak is not documented!-->
+
+    <!--property MemorySwapCurrent is not documented!-->
+
+    <!--property MemorySwapPeak is not documented!-->
+
+    <!--property MemoryZSwapCurrent is not documented!-->
+
+    <!--property CPUUsageNSec is not documented!-->
+
+    <!--property EffectiveCPUs is not documented!-->
+
+    <!--property EffectiveMemoryNodes is not documented!-->
+
+    <!--property TasksCurrent is not documented!-->
+
+    <!--property IPIngressBytes is not documented!-->
+
+    <!--property IPIngressPackets is not documented!-->
+
+    <!--property IPEgressBytes is not documented!-->
+
+    <!--property IPEgressPackets is not documented!-->
+
+    <!--property IOReadBytes is not documented!-->
+
+    <!--property IOReadOperations is not documented!-->
+
+    <!--property IOWriteBytes is not documented!-->
+
+    <!--property IOWriteOperations is not documented!-->
+
+    <!--property Delegate is not documented!-->
+
+    <!--property DelegateControllers is not documented!-->
+
+    <!--property CPUAccounting is not documented!-->
+
+    <!--property CPUWeight is not documented!-->
+
+    <!--property StartupCPUWeight is not documented!-->
+
+    <!--property CPUShares is not documented!-->
+
+    <!--property StartupCPUShares is not documented!-->
+
+    <!--property CPUQuotaPerSecUSec is not documented!-->
+
+    <!--property CPUQuotaPeriodUSec is not documented!-->
+
+    <!--property AllowedCPUs is not documented!-->
+
+    <!--property StartupAllowedCPUs is not documented!-->
+
+    <!--property AllowedMemoryNodes is not documented!-->
+
+    <!--property StartupAllowedMemoryNodes is not documented!-->
+
+    <!--property IOAccounting is not documented!-->
+
+    <!--property IOWeight is not documented!-->
+
+    <!--property StartupIOWeight is not documented!-->
+
+    <!--property IODeviceWeight is not documented!-->
+
+    <!--property IOReadBandwidthMax is not documented!-->
+
+    <!--property IOWriteBandwidthMax is not documented!-->
+
+    <!--property IOReadIOPSMax is not documented!-->
+
+    <!--property IOWriteIOPSMax is not documented!-->
+
+    <!--property IODeviceLatencyTargetUSec is not documented!-->
+
+    <!--property BlockIOAccounting is not documented!-->
+
+    <!--property BlockIOWeight is not documented!-->
+
+    <!--property StartupBlockIOWeight is not documented!-->
+
+    <!--property BlockIODeviceWeight is not documented!-->
+
+    <!--property BlockIOReadBandwidth is not documented!-->
+
+    <!--property BlockIOWriteBandwidth is not documented!-->
+
+    <!--property MemoryAccounting is not documented!-->
+
+    <!--property DefaultMemoryLow is not documented!-->
+
+    <!--property DefaultStartupMemoryLow is not documented!-->
+
+    <!--property DefaultMemoryMin is not documented!-->
+
+    <!--property MemoryMin is not documented!-->
+
+    <!--property MemoryLow is not documented!-->
+
+    <!--property StartupMemoryLow is not documented!-->
+
+    <!--property MemoryHigh is not documented!-->
+
+    <!--property StartupMemoryHigh is not documented!-->
+
+    <!--property MemoryMax is not documented!-->
+
+    <!--property StartupMemoryMax is not documented!-->
+
+    <!--property MemorySwapMax is not documented!-->
+
+    <!--property StartupMemorySwapMax is not documented!-->
+
+    <!--property MemoryZSwapMax is not documented!-->
+
+    <!--property StartupMemoryZSwapMax is not documented!-->
+
+    <!--property MemoryLimit is not documented!-->
+
+    <!--property DevicePolicy is not documented!-->
+
+    <!--property DeviceAllow is not documented!-->
+
+    <!--property TasksAccounting is not documented!-->
+
+    <!--property TasksMax is not documented!-->
+
+    <!--property IPAccounting is not documented!-->
+
+    <!--property IPAddressAllow is not documented!-->
+
+    <!--property IPAddressDeny is not documented!-->
+
+    <!--property IPIngressFilterPath is not documented!-->
+
+    <!--property IPEgressFilterPath is not documented!-->
+
+    <!--property DisableControllers is not documented!-->
+
+    <!--property ManagedOOMSwap is not documented!-->
+
+    <!--property ManagedOOMMemoryPressure is not documented!-->
+
+    <!--property ManagedOOMMemoryPressureLimit is not documented!-->
+
+    <!--property ManagedOOMPreference is not documented!-->
+
+    <!--property BPFProgram is not documented!-->
+
+    <!--property SocketBindAllow is not documented!-->
+
+    <!--property SocketBindDeny is not documented!-->
+
+    <!--property RestrictNetworkInterfaces is not documented!-->
+
+    <!--property MemoryPressureWatch is not documented!-->
+
+    <!--property MemoryPressureThresholdUSec is not documented!-->
+
+    <!--property NFTSet is not documented!-->
+
+    <!--property CoredumpReceive is not documented!-->
+
+    <!--Autogenerated cross-references for systemd.directives, do not edit-->
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Unit"/>
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Slice"/>
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Unit"/>
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Slice"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="GetProcesses()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="AttachProcesses()"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Slice"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ControlGroup"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ControlGroupId"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryCurrent"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryPeak"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemorySwapCurrent"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemorySwapPeak"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryZSwapCurrent"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryAvailable"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CPUUsageNSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="EffectiveCPUs"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="EffectiveMemoryNodes"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TasksCurrent"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IPIngressBytes"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IPIngressPackets"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IPEgressBytes"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IPEgressPackets"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IOReadBytes"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IOReadOperations"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IOWriteBytes"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IOWriteOperations"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Delegate"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DelegateControllers"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DelegateSubgroup"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CPUAccounting"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CPUWeight"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StartupCPUWeight"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CPUShares"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StartupCPUShares"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CPUQuotaPerSecUSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CPUQuotaPeriodUSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="AllowedCPUs"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StartupAllowedCPUs"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="AllowedMemoryNodes"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StartupAllowedMemoryNodes"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IOAccounting"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IOWeight"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StartupIOWeight"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IODeviceWeight"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IOReadBandwidthMax"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IOWriteBandwidthMax"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IOReadIOPSMax"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IOWriteIOPSMax"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IODeviceLatencyTargetUSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="BlockIOAccounting"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="BlockIOWeight"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StartupBlockIOWeight"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="BlockIODeviceWeight"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="BlockIOReadBandwidth"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="BlockIOWriteBandwidth"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryAccounting"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DefaultMemoryLow"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DefaultStartupMemoryLow"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DefaultMemoryMin"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryMin"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryLow"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StartupMemoryLow"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryHigh"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StartupMemoryHigh"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryMax"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StartupMemoryMax"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemorySwapMax"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StartupMemorySwapMax"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryZSwapMax"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StartupMemoryZSwapMax"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryLimit"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DevicePolicy"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DeviceAllow"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TasksAccounting"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TasksMax"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IPAccounting"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IPAddressAllow"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IPAddressDeny"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IPIngressFilterPath"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IPEgressFilterPath"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DisableControllers"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ManagedOOMSwap"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ManagedOOMMemoryPressure"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ManagedOOMMemoryPressureLimit"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ManagedOOMPreference"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="BPFProgram"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SocketBindAllow"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SocketBindDeny"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RestrictNetworkInterfaces"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryPressureWatch"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryPressureThresholdUSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="NFTSet"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CoredumpReceive"/>
+
+    <!--End of Autogenerated section-->
+
+    <refsect2>
+      <title>Properties</title>
+
+      <para>Most properties correspond directly with the matching settings in slice unit files.</para>
+    </refsect2>
+  </refsect1>
+
+  <refsect1>
+    <title>Scope Unit Objects</title>
+
+    <para>All scope unit objects implement the <interfacename>org.freedesktop.systemd1.Scope</interfacename>
+    interface (described here) in addition to the generic
+    <interfacename>org.freedesktop.systemd1.Unit</interfacename> interface (see above).</para>
+
+    <programlisting executable="systemd" node="/org/freedesktop/systemd1/unit/session_2d1_2escope" interface="org.freedesktop.systemd1.Scope">
+node /org/freedesktop/systemd1/unit/session_2d1_2escope {
+  interface org.freedesktop.systemd1.Scope {
+    methods:
+      Abandon();
+      GetProcesses(out a(sus) processes);
+      AttachProcesses(in  s subcgroup,
+                      in  au pids);
+    signals:
+      RequestStop();
+    properties:
+      readonly s Controller = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t TimeoutStopUSec = ...;
+      readonly s Result = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t RuntimeMaxUSec = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly t RuntimeRandomizedExtraUSec = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s OOMPolicy = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s Slice = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s ControlGroup = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t ControlGroupId = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemoryCurrent = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemoryPeak = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemorySwapCurrent = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemorySwapPeak = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemoryZSwapCurrent = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemoryAvailable = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t CPUUsageNSec = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly ay EffectiveCPUs = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly ay EffectiveMemoryNodes = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t TasksCurrent = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t IPIngressBytes = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t IPIngressPackets = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t IPEgressBytes = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t IPEgressPackets = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t IOReadBytes = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t IOReadOperations = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t IOWriteBytes = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t IOWriteOperations = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly b Delegate = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly as DelegateControllers = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s DelegateSubgroup = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly b CPUAccounting = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t CPUWeight = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t StartupCPUWeight = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t CPUShares = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t StartupCPUShares = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t CPUQuotaPerSecUSec = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t CPUQuotaPeriodUSec = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly ay AllowedCPUs = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly ay StartupAllowedCPUs = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly ay AllowedMemoryNodes = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly ay StartupAllowedMemoryNodes = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly b IOAccounting = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t IOWeight = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t StartupIOWeight = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(st) IODeviceWeight = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(st) IOReadBandwidthMax = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(st) IOWriteBandwidthMax = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(st) IOReadIOPSMax = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(st) IOWriteIOPSMax = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(st) IODeviceLatencyTargetUSec = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly b BlockIOAccounting = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t BlockIOWeight = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t StartupBlockIOWeight = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(st) BlockIODeviceWeight = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(st) BlockIOReadBandwidth = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(st) BlockIOWriteBandwidth = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly b MemoryAccounting = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t DefaultMemoryLow = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t DefaultStartupMemoryLow = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t DefaultMemoryMin = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemoryMin = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemoryLow = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t StartupMemoryLow = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemoryHigh = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t StartupMemoryHigh = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemoryMax = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t StartupMemoryMax = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemorySwapMax = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t StartupMemorySwapMax = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemoryZSwapMax = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t StartupMemoryZSwapMax = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemoryLimit = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s DevicePolicy = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(ss) DeviceAllow = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly b TasksAccounting = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t TasksMax = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly b IPAccounting = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(iayu) IPAddressAllow = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(iayu) IPAddressDeny = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly as IPIngressFilterPath = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly as IPEgressFilterPath = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly as DisableControllers = ['...', ...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s ManagedOOMSwap = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s ManagedOOMMemoryPressure = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly u ManagedOOMMemoryPressureLimit = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s ManagedOOMPreference = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(ss) BPFProgram = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(iiqq) SocketBindAllow = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(iiqq) SocketBindDeny = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly (bas) RestrictNetworkInterfaces = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly s MemoryPressureWatch = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t MemoryPressureThresholdUSec = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly a(iiss) NFTSet = [...];
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly b CoredumpReceive = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s KillMode = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i KillSignal = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i RestartKillSignal = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i FinalKillSignal = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b SendSIGKILL = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly b SendSIGHUP = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly i WatchdogSignal = ...;
+  };
+  interface org.freedesktop.DBus.Peer { ... };
+  interface org.freedesktop.DBus.Introspectable { ... };
+  interface org.freedesktop.DBus.Properties { ... };
+  interface org.freedesktop.systemd1.Unit { ... };
+};
+    </programlisting>
+
+    <!--method GetProcesses is not documented!-->
+
+    <!--method AttachProcesses is not documented!-->
+
+    <!--property RuntimeMaxUSec is not documented!-->
+
+    <!--property RuntimeRandomizedExtraUSec is not documented!-->
+
+    <!--property OOMPolicy is not documented!-->
+
+    <!--property Slice is not documented!-->
+
+    <!--property ControlGroupId is not documented!-->
+
+    <!--property MemoryCurrent is not documented!-->
+
+    <!--property MemoryPeak is not documented!-->
+
+    <!--property MemorySwapCurrent is not documented!-->
+
+    <!--property MemorySwapPeak is not documented!-->
+
+    <!--property MemoryZSwapCurrent is not documented!-->
+
+    <!--property CPUUsageNSec is not documented!-->
+
+    <!--property EffectiveCPUs is not documented!-->
+
+    <!--property EffectiveMemoryNodes is not documented!-->
+
+    <!--property TasksCurrent is not documented!-->
+
+    <!--property IPIngressBytes is not documented!-->
+
+    <!--property IPIngressPackets is not documented!-->
+
+    <!--property IPEgressBytes is not documented!-->
+
+    <!--property IPEgressPackets is not documented!-->
+
+    <!--property IOReadBytes is not documented!-->
+
+    <!--property IOReadOperations is not documented!-->
+
+    <!--property IOWriteBytes is not documented!-->
+
+    <!--property IOWriteOperations is not documented!-->
+
+    <!--property Delegate is not documented!-->
+
+    <!--property DelegateControllers is not documented!-->
+
+    <!--property CPUAccounting is not documented!-->
+
+    <!--property CPUWeight is not documented!-->
+
+    <!--property StartupCPUWeight is not documented!-->
+
+    <!--property CPUShares is not documented!-->
+
+    <!--property StartupCPUShares is not documented!-->
+
+    <!--property CPUQuotaPerSecUSec is not documented!-->
+
+    <!--property CPUQuotaPeriodUSec is not documented!-->
+
+    <!--property AllowedCPUs is not documented!-->
+
+    <!--property StartupAllowedCPUs is not documented!-->
+
+    <!--property AllowedMemoryNodes is not documented!-->
+
+    <!--property StartupAllowedMemoryNodes is not documented!-->
+
+    <!--property IOAccounting is not documented!-->
+
+    <!--property IOWeight is not documented!-->
+
+    <!--property StartupIOWeight is not documented!-->
+
+    <!--property IODeviceWeight is not documented!-->
+
+    <!--property IOReadBandwidthMax is not documented!-->
+
+    <!--property IOWriteBandwidthMax is not documented!-->
+
+    <!--property IOReadIOPSMax is not documented!-->
+
+    <!--property IOWriteIOPSMax is not documented!-->
+
+    <!--property IODeviceLatencyTargetUSec is not documented!-->
+
+    <!--property BlockIOAccounting is not documented!-->
+
+    <!--property BlockIOWeight is not documented!-->
+
+    <!--property StartupBlockIOWeight is not documented!-->
+
+    <!--property BlockIODeviceWeight is not documented!-->
+
+    <!--property BlockIOReadBandwidth is not documented!-->
+
+    <!--property BlockIOWriteBandwidth is not documented!-->
+
+    <!--property MemoryAccounting is not documented!-->
+
+    <!--property DefaultMemoryLow is not documented!-->
+
+    <!--property DefaultStartupMemoryLow is not documented!-->
+
+    <!--property DefaultMemoryMin is not documented!-->
+
+    <!--property MemoryMin is not documented!-->
+
+    <!--property MemoryLow is not documented!-->
+
+    <!--property StartupMemoryLow is not documented!-->
+
+    <!--property MemoryHigh is not documented!-->
+
+    <!--property StartupMemoryHigh is not documented!-->
+
+    <!--property MemoryMax is not documented!-->
+
+    <!--property StartupMemoryMax is not documented!-->
+
+    <!--property MemorySwapMax is not documented!-->
+
+    <!--property StartupMemorySwapMax is not documented!-->
+
+    <!--property MemoryZSwapMax is not documented!-->
+
+    <!--property StartupMemoryZSwapMax is not documented!-->
+
+    <!--property MemoryLimit is not documented!-->
+
+    <!--property DevicePolicy is not documented!-->
+
+    <!--property DeviceAllow is not documented!-->
+
+    <!--property TasksAccounting is not documented!-->
+
+    <!--property TasksMax is not documented!-->
+
+    <!--property IPAccounting is not documented!-->
+
+    <!--property IPAddressAllow is not documented!-->
+
+    <!--property IPAddressDeny is not documented!-->
+
+    <!--property IPIngressFilterPath is not documented!-->
+
+    <!--property IPEgressFilterPath is not documented!-->
+
+    <!--property DisableControllers is not documented!-->
+
+    <!--property ManagedOOMSwap is not documented!-->
+
+    <!--property ManagedOOMMemoryPressure is not documented!-->
+
+    <!--property ManagedOOMMemoryPressureLimit is not documented!-->
+
+    <!--property ManagedOOMPreference is not documented!-->
+
+    <!--property BPFProgram is not documented!-->
+
+    <!--property SocketBindAllow is not documented!-->
+
+    <!--property SocketBindDeny is not documented!-->
+
+    <!--property RestrictNetworkInterfaces is not documented!-->
+
+    <!--property MemoryPressureWatch is not documented!-->
+
+    <!--property MemoryPressureThresholdUSec is not documented!-->
+
+    <!--property NFTSet is not documented!-->
+
+    <!--property CoredumpReceive is not documented!-->
+
+    <!--property KillMode is not documented!-->
+
+    <!--property KillSignal is not documented!-->
+
+    <!--property RestartKillSignal is not documented!-->
+
+    <!--property FinalKillSignal is not documented!-->
+
+    <!--property SendSIGKILL is not documented!-->
+
+    <!--property SendSIGHUP is not documented!-->
+
+    <!--property WatchdogSignal is not documented!-->
+
+    <!--Autogenerated cross-references for systemd.directives, do not edit-->
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Unit"/>
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Scope"/>
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Unit"/>
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Scope"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="Abandon()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="GetProcesses()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="AttachProcesses()"/>
+
+    <variablelist class="dbus-signal" generated="True" extra-ref="RequestStop"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Controller"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TimeoutStopUSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Result"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RuntimeMaxUSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RuntimeRandomizedExtraUSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="OOMPolicy"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Slice"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ControlGroup"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ControlGroupId"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryCurrent"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryPeak"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemorySwapCurrent"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemorySwapPeak"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryZSwapCurrent"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryAvailable"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CPUUsageNSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="EffectiveCPUs"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="EffectiveMemoryNodes"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TasksCurrent"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IPIngressBytes"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IPIngressPackets"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IPEgressBytes"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IPEgressPackets"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IOReadBytes"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IOReadOperations"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IOWriteBytes"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IOWriteOperations"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Delegate"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DelegateControllers"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DelegateSubgroup"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CPUAccounting"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CPUWeight"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StartupCPUWeight"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CPUShares"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StartupCPUShares"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CPUQuotaPerSecUSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CPUQuotaPeriodUSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="AllowedCPUs"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StartupAllowedCPUs"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="AllowedMemoryNodes"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StartupAllowedMemoryNodes"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IOAccounting"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IOWeight"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StartupIOWeight"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IODeviceWeight"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IOReadBandwidthMax"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IOWriteBandwidthMax"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IOReadIOPSMax"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IOWriteIOPSMax"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IODeviceLatencyTargetUSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="BlockIOAccounting"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="BlockIOWeight"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StartupBlockIOWeight"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="BlockIODeviceWeight"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="BlockIOReadBandwidth"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="BlockIOWriteBandwidth"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryAccounting"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DefaultMemoryLow"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DefaultStartupMemoryLow"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DefaultMemoryMin"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryMin"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryLow"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StartupMemoryLow"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryHigh"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StartupMemoryHigh"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryMax"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StartupMemoryMax"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemorySwapMax"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StartupMemorySwapMax"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryZSwapMax"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="StartupMemoryZSwapMax"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryLimit"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DevicePolicy"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DeviceAllow"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TasksAccounting"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TasksMax"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IPAccounting"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IPAddressAllow"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IPAddressDeny"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IPIngressFilterPath"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="IPEgressFilterPath"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="DisableControllers"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ManagedOOMSwap"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ManagedOOMMemoryPressure"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ManagedOOMMemoryPressureLimit"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ManagedOOMPreference"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="BPFProgram"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SocketBindAllow"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SocketBindDeny"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RestrictNetworkInterfaces"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryPressureWatch"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="MemoryPressureThresholdUSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="NFTSet"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CoredumpReceive"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="KillMode"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="KillSignal"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RestartKillSignal"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="FinalKillSignal"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SendSIGKILL"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="SendSIGHUP"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="WatchdogSignal"/>
+
+    <!--End of Autogenerated section-->
+
+    <refsect2>
+      <title>Methods</title>
+
+      <para><function>Abandon()</function> may be used to place a scope unit in the "abandoned" state. This
+      may be used to inform the system manager that the manager that created the scope lost interest in the
+      scope (for example, because it is terminating), without wanting to shut down the scope entirely.</para>
+    </refsect2>
+
+    <refsect2>
+      <title>Signals</title>
+
+      <para><function>RequestStop</function> is sent to the peer that is configured in the
+      <varname>Controller</varname> property when systemd is requested to terminate the scope unit. A program
+      registering a scope can use this to cleanly shut down the processes it added to the scope instead of
+      letting systemd do it with the usual <constant>SIGTERM</constant> logic.</para>
+    </refsect2>
+
+    <refsect2>
+      <title>Properties</title>
+
+      <para>All properties correspond directly with the matching properties of service units.</para>
+
+      <para><varname>Controller</varname> contains the bus name (unique or well-known) that is notified when
+      the scope unit is to be shut down via a <function>RequestStop</function> signal (see below). This is
+      set when the scope is created. If not set, the scope's processes will terminated with
+      <constant>SIGTERM</constant> directly.</para>
+    </refsect2>
+  </refsect1>
+
+
+  <refsect1>
+    <title>Job Objects</title>
+
+    <para>Job objects encapsulate scheduled or running jobs. Each unit can have none or one jobs in the
+    execution queue. Each job is attached to exactly one unit.</para>
+
+    <programlisting executable="systemd" node="/org/freedesktop/systemd1/job/666" interface="org.freedesktop.systemd1.Job">
+node /org/freedesktop/systemd1/job/666 {
+  interface org.freedesktop.systemd1.Job {
+    methods:
+      Cancel();
+      GetAfter(out a(usssoo) jobs);
+      GetBefore(out a(usssoo) jobs);
+    properties:
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly u Id = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly (so) Unit = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly s JobType = '...';
+      readonly s State = '...';
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("const")
+      readonly a(ss) ActivationDetails = [...];
+  };
+  interface org.freedesktop.DBus.Peer { ... };
+  interface org.freedesktop.DBus.Introspectable { ... };
+  interface org.freedesktop.DBus.Properties { ... };
+};
+    </programlisting>
+
+    <!--method GetAfter is not documented!-->
+
+    <!--method GetBefore is not documented!-->
+
+    <!--Autogenerated cross-references for systemd.directives, do not edit-->
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Job"/>
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.systemd1.Job"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="Cancel()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="GetAfter()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="GetBefore()"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Id"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Unit"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="JobType"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="State"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="ActivationDetails"/>
+
+    <!--End of Autogenerated section-->
+
+    <refsect2>
+      <title>Methods</title>
+
+      <para><function>Cancel()</function> cancels the job. Note that this will remove a job from the queue if
+      it is not yet executed but generally will not cause a job that is already in the process of being
+      executed to be aborted. This operation may also be requested via the <function>CancelJob()</function>
+      method of the Manager object (see above), which is sometimes useful to reduce roundtrips.</para>
+    </refsect2>
+
+    <refsect2>
+      <title>Properties</title>
+
+      <para><varname>Id</varname> is the numeric Id of the job. During the runtime of a systemd instance each
+      numeric ID is only assigned once.</para>
+
+      <para><varname>Unit</varname> refers to the unit this job belongs to. It is a structure consisting of
+      the name of the unit and a bus path to the unit's object.</para>
+
+      <para><varname>JobType</varname> refers to the job's type and is one of <literal>start</literal>,
+      <literal>verify-active</literal>, <literal>stop</literal>, <literal>reload</literal>,
+      <literal>restart</literal>, <literal>try-restart</literal>, or <literal>reload-or-start</literal>. Note
+      that later versions might define additional values.</para>
+
+      <para><varname>State</varname> refers to the job's state and is one of <literal>waiting</literal> and
+      <literal>running</literal>. The former indicates that a job is currently queued but has not begun to
+      execute yet. The latter indicates that a job is currently being executed.</para>
+
+      <para><varname>ActivationDetails</varname> has the same content as the property of the same name under
+      the <varname>org.freedesktop.systemd1.Unit</varname> interface.</para>
+    </refsect2>
+  </refsect1>
+
+  <refsect1>
+    <title>Examples</title>
+
+    <example>
+      <title>Introspect <interfacename>org.freedesktop.systemd1.Manager</interfacename> on the bus</title>
+
+      <programlisting>
+$ gdbus introspect --system \
+        --dest org.freedesktop.systemd1 \
+        --object-path /org/freedesktop/systemd1
+      </programlisting>
+    </example>
+
+    <example>
+      <title>Introspect a unit on the bus</title>
+
+      <programlisting>
+$ busctl introspect org.freedesktop.systemd1 \
+  $(busctl call org.freedesktop.systemd1 \
+     /org/freedesktop/systemd1 \
+     org.freedesktop.systemd1.Manager \
+     GetUnit s systemd-resolved.service | cut -d'"' -f2)
+      </programlisting>
+    </example>
+
+    <example>
+      <title>Introspect <interfacename>org.freedesktop.systemd1.Job</interfacename> on the bus</title>
+
+      <programlisting>
+$ gdbus introspect --system --dest org.freedesktop.systemd1 \
+  --object-path /org/freedesktop/systemd1/job/1292
+      </programlisting>
+    </example>
+  </refsect1>
+
+  <xi:include href="org.freedesktop.locale1.xml" xpointer="versioning"/>
+
+  <refsect1>
+    <title>History</title>
+    <refsect2>
+      <title>The Manager Object</title>
+      <para><varname>RuntimeWatchdogPreUSec</varname> and
+      <varname>RuntimeWatchdogPreGovernor</varname> were added in version 251.</para>
+      <para><varname>WatchdogDevice</varname>,
+      <varname>WatchdogLastPingTimestamp</varname>,
+      <varname>WatchdogLastPingTimestampMonotonic</varname>,
+      <varname>DefaultDeviceTimeoutUSec</varname>,
+      <function>DumpUnitsMatchingPatterns()</function>, and
+      <function>DumpUnitsMatchingPatternsByFileDescriptor()</function> were added in version 252.</para>
+      <para><function>GetUnitByPIDFD()</function> and
+      <function>DisableUnitFilesWithFlagsAndInstallInfo()</function> were added in version 253.</para>
+      <para><varname>ConfidentialVirtualization</varname>,
+      <varname>DefaultIOAccounting</varname>,
+      <varname>DefaultIPAccounting</varname>,
+      <varname>DefaultMemoryPressureThresholdUSec</varname>,
+      <varname>DefaultMemoryPressureWatch</varname>,
+      <function>QueueSignalUnit()</function>,
+      <function>SoftReboot()</function>, and
+      <function>DumpUnitFileDescriptorStore()</function> were added in version 254.</para>
+    </refsect2>
+    <refsect2>
+      <title>Unit Objects</title>
+      <para><varname>Upholds</varname> and
+      <varname>UpheldBy</varname> were added in version 251.</para>
+      <para><varname>AccessSELinuxContext</varname> and
+      <varname>ActivationDetails</varname> were added in version 252.</para>
+      <para><function>QueueSignal()</function> was added in version 254.</para>
+      <para><varname>SurviveFinalKillSignal</varname> was added in version 255.</para>
+    </refsect2>
+    <refsect2>
+      <title>Service Unit Objects</title>
+      <para><varname>ControlGroupId</varname> and
+      <varname>ExtensionDirectories</varname> were added in version 251.</para>
+      <para><varname>OpenFile</varname>,
+      <varname>ReloadSignal</varname>,
+      <varname>MemoryZSwapMax</varname>, and
+      <varname>LogFilterPatterns</varname> were added in version 253.</para>
+      <para><varname>RestartMode</varname>,
+      <varname>RestartSteps</varname>,
+      <varname>RestartMaxDelayUSec</varname>,
+      <varname>RestartUSecNext</varname>,
+      <varname>FileDescriptorStorePreserve</varname>,
+      <function>DumpFileDescriptorStore()</function>,
+      <varname>DelegateSubgroup</varname>,
+      <varname>DefaultStartupMemoryLow</varname>,
+      <varname>StartupMemoryLow</varname>,
+      <varname>StartupMemoryHigh</varname>,
+      <varname>StartupMemoryMax</varname>,
+      <varname>StartupMemorySwapMax</varname>,
+      <varname>StartupMemoryZSwapMax</varname>,
+      <varname>MemoryPressureWatch</varname>,
+      <varname>MemoryPressureThresholdUSec</varname>,
+      <varname>RootEphemeral</varname>,
+      <varname>ImportCredential</varname>,
+      <varname>MemoryKSM</varname>,
+      <varname>RootImagePolicy</varname>,
+      <varname>MountImagePolicy</varname>, and
+      <varname>ExtensionImagePolicy</varname> were added in version 254.</para>
+      <para><varname>NFTSet</varname>,
+      <varname>SetLoginEnvironment</varname>,
+      <varname>CoredumpReceive</varname>,
+      <varname>MemoryPeak</varname>,
+      <varname>MemorySwapCurrent</varname>,
+      <varname>MemorySwapPeak</varname>, and
+      <varname>MemoryZSwapCurrent</varname> were added in version 255.</para>
+    </refsect2>
+    <refsect2>
+      <title>Socket Unit Objects</title>
+      <para><varname>ControlGroupId</varname> and
+      <varname>ExtensionDirectories</varname> were added in version 251.</para>
+      <para><varname>MemoryZSwapMax</varname> and
+      <varname>LogFilterPatterns</varname> were added in version 253.</para>
+      <para><varname>DelegateSubgroup</varname>,
+      <varname>DefaultStartupMemoryLow</varname>,
+      <varname>StartupMemoryLow</varname>,
+      <varname>StartupMemoryHigh</varname>,
+      <varname>StartupMemoryMax</varname>,
+      <varname>StartupMemorySwapMax</varname>,
+      <varname>StartupMemoryZSwapMax</varname>,
+      <varname>MemoryPressureWatch</varname>,
+      <varname>MemoryPressureThresholdUSec</varname>,
+      <varname>RootEphemeral</varname>,
+      <varname>ImportCredential</varname>,
+      <varname>MemoryKSM</varname>,
+      <varname>RootImagePolicy</varname>,
+      <varname>MountImagePolicy</varname>, and
+      <varname>ExtensionImagePolicy</varname> were added in version 254.</para>
+      <para><varname>PollLimitIntervalUSec</varname>,
+      <varname>PollLimitBurst</varname>,
+      <varname>NFTSet</varname>,
+      <varname>SetLoginEnvironment</varname>,
+      <varname>CoredumpReceive</varname>,
+      <varname>MemoryPeak</varname>,
+      <varname>MemorySwapCurrent</varname>,
+      <varname>MemorySwapPeak</varname>, and
+      <varname>MemoryZSwapCurrent</varname> were added in version 255.</para>
+    </refsect2>
+    <refsect2>
+      <title>Mount Unit Objects</title>
+      <para><varname>ControlGroupId</varname> and
+      <varname>ExtensionDirectories</varname> were added in version 251.</para>
+      <para><varname>MemoryZSwapMax</varname> and
+      <varname>LogFilterPatterns</varname> were added in version 253.</para>
+      <para><varname>DelegateSubgroup</varname>,
+      <varname>DefaultStartupMemoryLow</varname>,
+      <varname>StartupMemoryLow</varname>,
+      <varname>StartupMemoryHigh</varname>,
+      <varname>StartupMemoryMax</varname>,
+      <varname>StartupMemorySwapMax</varname>,
+      <varname>StartupMemoryZSwapMax</varname>,
+      <varname>MemoryPressureWatch</varname>,
+      <varname>MemoryPressureThresholdUSec</varname>,
+      <varname>RootEphemeral</varname>,
+      <varname>ImportCredential</varname>,
+      <varname>MemoryKSM</varname>,
+      <varname>RootImagePolicy</varname>,
+      <varname>MountImagePolicy</varname>, and
+      <varname>ExtensionImagePolicy</varname> were added in version 254.</para>
+      <para><varname>NFTSet</varname>,
+      <varname>SetLoginEnvironment</varname>,
+      <varname>CoredumpReceive</varname>,
+      <varname>MemoryPeak</varname>,
+      <varname>MemorySwapCurrent</varname>,
+      <varname>MemorySwapPeak</varname>, and
+      <varname>MemoryZSwapCurrent</varname> were added in version 255.</para>
+    </refsect2>
+    <refsect2>
+      <title>Swap Unit Objects</title>
+      <para><varname>ControlGroupId</varname> and
+      <varname>ExtensionDirectories</varname> were added in version 251.</para>
+      <para><varname>MemoryZSwapMax</varname> and
+      <varname>LogFilterPatterns</varname> were added in version 253.</para>
+      <para><varname>DelegateSubgroup</varname>,
+      <varname>DefaultStartupMemoryLow</varname>,
+      <varname>StartupMemoryLow</varname>,
+      <varname>StartupMemoryHigh</varname>,
+      <varname>StartupMemoryMax</varname>,
+      <varname>StartupMemorySwapMax</varname>,
+      <varname>StartupMemoryZSwapMax</varname>,
+      <varname>MemoryPressureWatch</varname>,
+      <varname>MemoryPressureThresholdUSec</varname>,
+      <varname>RootEphemeral</varname>,
+      <varname>ImportCredential</varname>,
+      <varname>MemoryKSM</varname>,
+      <varname>RootImagePolicy</varname>,
+      <varname>MountImagePolicy</varname>, and
+      <varname>ExtensionImagePolicy</varname> were added in version 254.</para>
+      <para><varname>NFTSet</varname>,
+      <varname>SetLoginEnvironment</varname>,
+      <varname>CoredumpReceive</varname>,
+      <varname>MemoryPeak</varname>,
+      <varname>MemorySwapCurrent</varname>,
+      <varname>MemorySwapPeak</varname>, and
+      <varname>MemoryZSwapCurrent</varname> were added in version 255.</para>
+    </refsect2>
+    <refsect2>
+      <title>Slice Unit Objects</title>
+      <para><varname>ControlGroupId</varname> was added in version 251.</para>
+      <para><varname>MemoryZSwapMax</varname> was added in version 253.</para>
+      <para><varname>DelegateSubgroup</varname>,
+      <varname>DefaultStartupMemoryLow</varname>,
+      <varname>StartupMemoryLow</varname>,
+      <varname>StartupMemoryHigh</varname>,
+      <varname>StartupMemoryMax</varname>,
+      <varname>StartupMemorySwapMax</varname>,
+      <varname>StartupMemoryZSwapMax</varname>,
+      <varname>MemoryPressureWatch</varname>, and
+      <varname>MemoryPressureThresholdUSec</varname> were added in version 254.</para>
+      <para><varname>NFTSet</varname>,
+      <varname>CoredumpReceive</varname>,
+      <varname>MemoryPeak</varname>,
+      <varname>MemorySwapCurrent</varname>,
+      <varname>MemorySwapPeak</varname>, and
+      <varname>MemoryZSwapCurrent</varname> were added in version 255.</para>
+    </refsect2>
+    <refsect2>
+      <title>Scope Unit Objects</title>
+      <para><varname>ControlGroupId</varname> was added in version 251.</para>
+      <para><varname>OOMPolicy</varname> and
+      <varname>MemoryZSwapMax</varname> were added in version 253.</para>
+      <para><varname>DelegateSubgroup</varname>,
+      <varname>DefaultStartupMemoryLow</varname>,
+      <varname>StartupMemoryLow</varname>,
+      <varname>StartupMemoryHigh</varname>,
+      <varname>StartupMemoryMax</varname>,
+      <varname>StartupMemorySwapMax</varname>,
+      <varname>StartupMemoryZSwapMax</varname>,
+      <varname>MemoryPressureWatch</varname>, and
+      <varname>MemoryPressureThresholdUSec</varname> were added in version 254.</para>
+      <para><varname>NFTSet</varname>,
+      <varname>CoredumpReceive</varname>,
+      <varname>MemoryPeak</varname>,
+      <varname>MemorySwapCurrent</varname>,
+      <varname>MemorySwapPeak</varname>, and
+      <varname>MemoryZSwapCurrent</varname> were added in version 255.</para>
+    </refsect2>
+    <refsect2>
+      <title>Job Objects</title>
+      <para><varname>ActivationDetails</varname> was added in version 252.</para>
+    </refsect2>
+  </refsect1>
+</refentry>
diff --git a/man/org.freedesktop.timedate1.xml b/man/org.freedesktop.timedate1.xml
new file mode 100644
index 0000000..54f4018
--- /dev/null
+++ b/man/org.freedesktop.timedate1.xml
@@ -0,0 +1,200 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" >
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="org.freedesktop.timedate1" conditional='ENABLE_TIMEDATED'
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+  <refentryinfo>
+    <title>org.freedesktop.timedate1</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>org.freedesktop.timedate1</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>org.freedesktop.timedate1</refname>
+    <refpurpose>The D-Bus interface of systemd-timedated</refpurpose>
+  </refnamediv>
+
+  <refsect1>
+    <title>Introduction</title>
+
+    <para>
+    <citerefentry><refentrytitle>systemd-timedated.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    is a system service that can be used to control the system time and related settings. This page
+    describes the D-Bus interface.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>The D-Bus API</title>
+
+    <para>The service exposes the following interfaces on the bus:</para>
+
+    <programlisting executable="systemd-timedated" node="/org/freedesktop/timedate1" interface="org.freedesktop.timedate1">
+node /org/freedesktop/timedate1 {
+  interface org.freedesktop.timedate1 {
+    methods:
+      SetTime(in  x usec_utc,
+              in  b relative,
+              in  b interactive);
+      SetTimezone(in  s timezone,
+                  in  b interactive);
+      SetLocalRTC(in  b local_rtc,
+                  in  b fix_system,
+                  in  b interactive);
+      SetNTP(in  b use_ntp,
+             in  b interactive);
+      ListTimezones(out as timezones);
+    properties:
+      readonly s Timezone = '...';
+      readonly b LocalRTC = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly b CanNTP = ...;
+      readonly b NTP = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly b NTPSynchronized = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t TimeUSec = ...;
+      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
+      readonly t RTCTimeUSec = ...;
+  };
+  interface org.freedesktop.DBus.Peer { ... };
+  interface org.freedesktop.DBus.Introspectable { ... };
+  interface org.freedesktop.DBus.Properties { ... };
+};
+    </programlisting>
+
+    <!--Autogenerated cross-references for systemd.directives, do not edit-->
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.timedate1"/>
+
+    <variablelist class="dbus-interface" generated="True" extra-ref="org.freedesktop.timedate1"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SetTime()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SetTimezone()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SetLocalRTC()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="SetNTP()"/>
+
+    <variablelist class="dbus-method" generated="True" extra-ref="ListTimezones()"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="Timezone"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="LocalRTC"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="CanNTP"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="NTP"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="NTPSynchronized"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="TimeUSec"/>
+
+    <variablelist class="dbus-property" generated="True" extra-ref="RTCTimeUSec"/>
+
+    <!--End of Autogenerated section-->
+
+    <refsect2>
+      <title>Methods</title>
+
+      <para>Use <function>SetTime()</function> to change the system clock. Pass a value of microseconds since
+      the UNIX epoch (1 Jan 1970 UTC). If <varname>relative</varname> is true, the passed usec value will be
+      added to the current system time. If it is false, the current system time will be set to the passed usec
+      value. If the system time is set with this method, the RTC will be updated as well.</para>
+
+      <para>Use <function>SetTimezone()</function> to set the system timezone. Pass a value like
+      <literal>Europe/Berlin</literal> to set the timezone. Valid timezones are listed in
+      <filename>/usr/share/zoneinfo/zone.tab</filename>. If the RTC is configured to be maintained in local
+      time, it will be updated accordingly.</para>
+
+      <para>Use <function>SetLocalRTC()</function> to control whether the RTC is in local time or UTC. It is
+      strongly recommended to maintain the RTC in UTC. However, some OSes (Windows) maintain the RTC in local
+      time, which might make it necessary to enable this feature. Note that this might create various problems as
+      daylight changes could be missed. If <varname>fix_system</varname> is <literal>true</literal>,
+      the time from the RTC is read again and the system clock is adjusted according to the new setting. If
+      <varname>fix_system</varname> is <literal>false</literal>, the system time is written to the RTC
+      taking the new setting into account. Use <varname>fix_system=true</varname> in installers and livecds
+      where the RTC is probably more reliable than the system time. Use <varname>fix_system=false</varname>
+      in configuration UIs that are run during normal operation and where the system clock is probably more
+      reliable than the RTC.</para>
+
+      <para>Use <function>SetNTP()</function> to control whether the system clock is synchronized with the
+      network using <filename>systemd-timesyncd</filename>. This will enable and start or disable and stop
+      the chosen time synchronization service.</para>
+
+      <para><function>ListTimezones()</function> returns a list of time zones known on the local system as an
+      array of names (<literal>["Africa/Abidjan", "Africa/Accra", ..., "UTC"]</literal>).</para>
+    </refsect2>
+
+    <refsect2>
+      <title>Properties</title>
+
+      <para><varname>Timezone</varname> shows the currently configured time zone.
+      <varname>LocalRTC</varname> shows whether the RTC is configured to use UTC (false), or the local time
+      zone (true). <varname>CanNTP</varname> shows whether a service to perform time synchronization over the
+      network is available, and <varname>NTP</varname> shows whether such a service is enabled.</para>
+
+      <para><varname>NTPSynchronized</varname> shows whether the kernel reports the time as synchronized
+      (c.f.
+      <citerefentry project="man-pages"><refentrytitle>adjtimex</refentrytitle><manvolnum>3</manvolnum></citerefentry>).
+      <varname>TimeUSec</varname> and <varname>RTCTimeUSec</varname> show the current time on the system and
+      in the RTC. The purpose of those three properties is to allow remote clients to access this information
+      over D-Bus. Local clients can access the information directly.</para>
+
+      <para>Whenever the <varname>Timezone</varname> and <varname>LocalRTC</varname> settings are changed via
+      the daemon, <function>PropertyChanged</function> signals are sent out to which clients can subscribe.
+      </para>
+
+      <para>Note that this service will not inform you about system time changes. Use
+      <citerefentry project="man-pages"><refentrytitle>timerfd</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+      with <constant>CLOCK_REALTIME</constant> and <constant>TFD_TIMER_CANCEL_ON_SET</constant> for that.
+      </para>
+    </refsect2>
+
+    <refsect2>
+      <title>Security</title>
+
+      <para>The <varname>interactive</varname> boolean parameters can be used to control whether
+      <ulink url="https://www.freedesktop.org/software/polkit/docs/latest/">polkit</ulink>
+      should interactively ask the user for authentication credentials if required.</para>
+
+      <para>The polkit action for <function>SetTimezone()</function> is
+      <interfacename>org.freedesktop.timedate1.set-timezone</interfacename>. For
+      <function>SetLocalRTC()</function> it is
+      <interfacename>org.freedesktop.timedate1.set-local-rtc</interfacename>, for
+      <function>SetTime()</function> it is <interfacename>org.freedesktop.timedate1.set-time</interfacename>
+      and for <function>SetNTP()</function> it is
+      <interfacename>org.freedesktop.timedate1.set-ntp</interfacename>.
+      <function>ListTimezones()</function> does not require any privileges.
+      </para>
+    </refsect2>
+  </refsect1>
+
+  <refsect1>
+    <title>Examples</title>
+
+    <example>
+      <title>Introspect <interfacename>org.freedesktop.timedate1</interfacename> on the bus</title>
+
+      <programlisting>
+$ gdbus introspect --system \
+  --dest org.freedesktop.timedate1 \
+  --object-path /org/freedesktop/timedate1
+      </programlisting>
+    </example>
+  </refsect1>
+
+  <xi:include href="org.freedesktop.locale1.xml" xpointer="versioning"/>
+
+  <refsect1>
+    <title>See also</title>
+
+      <para><ulink url="https://lists.freedesktop.org/archives/systemd-devel/2011-May/002526.html">More information on how the system clock and RTC interact</ulink></para>
+  </refsect1>
+</refentry>
diff --git a/man/os-release.xml b/man/os-release.xml
new file mode 100644
index 0000000..f2e0f3e
--- /dev/null
+++ b/man/os-release.xml
@@ -0,0 +1,650 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="os-release" xmlns:xi="http://www.w3.org/2001/XInclude">
+  <refentryinfo>
+    <title>os-release</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>os-release</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>os-release</refname>
+    <refname>initrd-release</refname>
+    <refname>extension-release</refname>
+    <refpurpose>Operating system identification</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>/etc/os-release</filename></para>
+    <para><filename>/usr/lib/os-release</filename></para>
+    <para><filename>/etc/initrd-release</filename></para>
+    <para><filename>/usr/lib/extension-release.d/extension-release.<replaceable>IMAGE</replaceable></filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>The <filename>/etc/os-release</filename> and
+    <filename>/usr/lib/os-release</filename> files contain operating
+    system identification data.</para>
+
+    <para>The format of <filename>os-release</filename> is a newline-separated list of
+    environment-like shell-compatible variable assignments. It is possible to source the configuration from
+    Bourne shell scripts, however, beyond mere variable assignments, no shell features are supported (this
+    means variable expansion is explicitly not supported), allowing applications to read the file without
+    implementing a shell compatible execution engine. Variable assignment values must be enclosed in double
+    or single quotes if they include spaces, semicolons or other special characters outside of A–Z, a–z,
+    0–9. (Assignments that do not include these special characters may be enclosed in quotes too, but this is
+    optional.) Shell special characters ("$", quotes, backslash, backtick) must be escaped with backslashes,
+    following shell style. All strings should be in UTF-8 encoding, and non-printable characters should not
+    be used. Concatenation of multiple individually quoted strings is not supported. Lines beginning with "#"
+    are treated as comments. Blank lines are permitted and ignored.</para>
+
+    <para>The file <filename>/etc/os-release</filename> takes
+    precedence over <filename>/usr/lib/os-release</filename>.
+    Applications should check for the former, and exclusively use its
+    data if it exists, and only fall back to
+    <filename>/usr/lib/os-release</filename> if it is missing.
+    Applications should not read data from both files at the same
+    time. <filename>/usr/lib/os-release</filename> is the recommended
+    place to store OS release information as part of vendor trees.
+    <filename>/etc/os-release</filename> should be a relative symlink
+    to <filename>/usr/lib/os-release</filename>, to provide
+    compatibility with applications only looking at
+    <filename>/etc/</filename>. A relative symlink instead of an
+    absolute symlink is necessary to avoid breaking the link in a
+    chroot or initrd environment such as dracut.</para>
+
+    <para><filename>os-release</filename> contains data that is
+    defined by the operating system vendor and should generally not be
+    changed by the administrator.</para>
+
+    <para>As this file only encodes names and identifiers it should
+    not be localized.</para>
+
+    <para>The <filename>/etc/os-release</filename> and
+    <filename>/usr/lib/os-release</filename> files might be symlinks
+    to other files, but it is important that the file is available
+    from earliest boot on, and hence must be located on the root file
+    system.</para>
+
+    <para><filename>os-release</filename> must not contain repeating keys. Nevertheless, readers should pick
+    the entries later in the file in case of repeats, similarly to how a shell sourcing the file would. A
+    reader may warn about repeating entries.</para>
+
+    <para>For a longer rationale for <filename>os-release</filename>
+    please refer to the <ulink
+    url="https://0pointer.de/blog/projects/os-release">Announcement of <filename>/etc/os-release</filename></ulink>.</para>
+
+    <refsect2>
+      <title><filename>/etc/initrd-release</filename></title>
+
+      <para>In the <ulink
+      url="https://docs.kernel.org/admin-guide/initrd.html">initrd</ulink>,
+      <filename>/etc/initrd-release</filename> plays the same role as <filename>os-release</filename> in the
+      main system. Additionally, the presence of that file means that the system is in the initrd phase.
+      <filename>/etc/os-release</filename> should be symlinked to <filename>/etc/initrd-release</filename>
+      (or vice versa), so programs that only look for <filename>/etc/os-release</filename> (as described
+      above) work correctly.</para>
+
+      <para>The rest of this document that talks about <filename>os-release</filename> should be understood
+      to apply to <filename>initrd-release</filename> too.</para>
+    </refsect2>
+
+    <refsect2>
+      <title><filename>/usr/lib/extension-release.d/extension-release.<replaceable>IMAGE</replaceable></filename></title>
+
+      <para><filename>/usr/lib/extension-release.d/extension-release.<replaceable>IMAGE</replaceable></filename>
+      plays the same role for extension images as <filename>os-release</filename> for the main system, and
+      follows the syntax and rules as described in the <ulink
+      url="https://systemd.io/PORTABLE_SERVICES">Portable Services</ulink> page. The purpose of this
+      file is to identify the extension and to allow the operating system to verify that the extension image
+      matches the base OS. This is typically implemented by checking that the <varname>ID=</varname> options
+      match, and either <varname>SYSEXT_LEVEL=</varname> exists and matches too, or if it is not present,
+      <varname>VERSION_ID=</varname> exists and matches. This ensures ABI/API compatibility between the
+      layers and prevents merging of an incompatible image in an overlay.</para>
+
+      <para>In order to identify the extension image itself, the same fields defined below can be added to the
+      <filename>extension-release</filename> file with a <varname>SYSEXT_</varname> prefix (to disambiguate
+      from fields used to match on the base image). E.g.: <varname>SYSEXT_ID=myext</varname>,
+      <varname>SYSEXT_VERSION_ID=1.2.3</varname>.</para>
+
+      <para>In the <filename>extension-release.<replaceable>IMAGE</replaceable></filename> filename, the
+      <replaceable>IMAGE</replaceable> part must exactly match the file name of the containing image with the
+      suffix removed. In case it is not possible to guarantee that an image file name is stable and doesn't
+      change between the build and the deployment phases, it is possible to relax this check: if exactly one
+      file whose name matches <literal><filename>extension-release.*</filename></literal> is present in this
+      directory, and the file is tagged with a <varname>user.extension-release.strict</varname>
+      <citerefentry project='man-pages'><refentrytitle>xattr</refentrytitle><manvolnum>7</manvolnum></citerefentry> set to the
+      string <literal>0</literal>, it will be used instead.</para>
+
+      <para>The rest of this document that talks about <filename>os-release</filename> should be understood
+      to apply to <filename>extension-release</filename> too.</para>
+    </refsect2>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>The following OS identifications parameters may be set using
+    <filename>os-release</filename>:</para>
+
+    <refsect2>
+      <title>General information identifying the operating system</title>
+
+      <variablelist class='environment-variables'>
+        <varlistentry>
+          <term><varname>NAME=</varname></term>
+
+          <listitem><para>A string identifying the operating system, without a version component, and
+          suitable for presentation to the user. If not set, a default of <literal>NAME=Linux</literal> may
+          be used.</para>
+
+          <para>Examples: <literal>NAME=Fedora</literal>, <literal>NAME="Debian GNU/Linux"</literal>.
+          </para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>ID=</varname></term>
+
+          <listitem><para>A lower-case string (no spaces or other characters outside of 0–9, a–z, ".", "_"
+          and "-") identifying the operating system, excluding any version information and suitable for
+          processing by scripts or usage in generated filenames. If not set, a default of
+          <literal>ID=linux</literal> may be used. Note that even though this string may not include
+          characters that require shell quoting, quoting may nevertheless be used.</para>
+
+          <para>Examples: <literal>ID=fedora</literal>, <literal>ID=debian</literal>.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>ID_LIKE=</varname></term>
+
+          <listitem><para>A space-separated list of operating system identifiers in the same syntax as the
+          <varname>ID=</varname> setting. It should list identifiers of operating systems that are closely
+          related to the local operating system in regards to packaging and programming interfaces, for
+          example listing one or more OS identifiers the local OS is a derivative from.  An OS should
+          generally only list other OS identifiers it itself is a derivative of, and not any OSes that are
+          derived from it, though symmetric relationships are possible. Build scripts and similar should
+          check this variable if they need to identify the local operating system and the value of
+          <varname>ID=</varname> is not recognized. Operating systems should be listed in order of how
+          closely the local operating system relates to the listed ones, starting with the closest. This
+          field is optional.</para>
+
+          <para>Examples: for an operating system with <literal>ID=centos</literal>, an assignment of
+          <literal>ID_LIKE="rhel fedora"</literal> would be appropriate. For an operating system with
+          <literal>ID=ubuntu</literal>, an assignment of <literal>ID_LIKE=debian</literal> is appropriate.
+          </para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>PRETTY_NAME=</varname></term>
+
+          <listitem><para>A pretty operating system name in a format suitable for presentation to the
+          user. May or may not contain a release code name or OS version of some kind, as suitable. If not
+          set, a default of <literal>PRETTY_NAME="Linux"</literal> may be used</para>
+
+          <para>Example: <literal>PRETTY_NAME="Fedora 17 (Beefy Miracle)"</literal>.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>CPE_NAME=</varname></term>
+
+          <listitem><para>A CPE name for the operating system, in URI binding syntax, following the <ulink
+          url="http://scap.nist.gov/specifications/cpe/">Common Platform Enumeration Specification</ulink> as
+          proposed by the NIST. This field is optional.</para>
+
+          <para>Example: <literal>CPE_NAME="cpe:/o:fedoraproject:fedora:17"</literal></para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>VARIANT=</varname></term>
+
+          <listitem><para>A string identifying a specific variant or edition of the operating system suitable
+          for presentation to the user. This field may be used to inform the user that the configuration of
+          this system is subject to a specific divergent set of rules or default configuration settings. This
+          field is optional and may not be implemented on all systems.</para>
+
+          <para>Examples: <literal>VARIANT="Server Edition"</literal>, <literal>VARIANT="Smart Refrigerator
+          Edition"</literal>.</para>
+
+          <para>Note: this field is for display purposes only. The <varname>VARIANT_ID</varname> field should
+          be used for making programmatic decisions.</para>
+
+          <xi:include href="version-info.xml" xpointer="v220"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>VARIANT_ID=</varname></term>
+
+          <listitem><para>A lower-case string (no spaces or other characters outside of 0–9, a–z, ".", "_" and
+          "-"), identifying a specific variant or edition of the operating system. This may be interpreted by
+          other packages in order to determine a divergent default configuration. This field is optional and
+          may not be implemented on all systems.</para>
+
+          <para>Examples: <literal>VARIANT_ID=server</literal>, <literal>VARIANT_ID=embedded</literal>.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v220"/></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+
+    <refsect2>
+      <title>Information about the version of the operating system</title>
+
+      <variablelist class='environment-variables'>
+        <varlistentry>
+          <term><varname>VERSION=</varname></term>
+
+          <listitem><para>A string identifying the operating system version, excluding any OS name
+          information, possibly including a release code name, and suitable for presentation to the
+          user. This field is optional.</para>
+
+          <para>Examples: <literal>VERSION=17</literal>, <literal>VERSION="17 (Beefy Miracle)"</literal>.
+          </para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>VERSION_ID=</varname></term>
+
+          <listitem><para>A lower-case string (mostly numeric, no spaces or other characters outside of 0–9,
+          a–z, ".", "_" and "-") identifying the operating system version, excluding any OS name information
+          or release code name, and suitable for processing by scripts or usage in generated filenames. This
+          field is optional.</para>
+
+          <para>Examples: <literal>VERSION_ID=17</literal>, <literal>VERSION_ID=11.04</literal>.
+          </para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>VERSION_CODENAME=</varname></term>
+
+          <listitem><para>A lower-case string (no spaces or other characters outside of 0–9, a–z, ".", "_"
+          and "-") identifying the operating system release code name, excluding any OS name information or
+          release version, and suitable for processing by scripts or usage in generated filenames. This field
+          is optional and may not be implemented on all systems.</para>
+
+          <para>Examples: <literal>VERSION_CODENAME=buster</literal>,
+          <literal>VERSION_CODENAME=xenial</literal>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v231"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>BUILD_ID=</varname></term>
+
+          <listitem><para>A string uniquely identifying the system image originally used as the installation
+          base. In most cases, <varname>VERSION_ID</varname> or
+          <varname>IMAGE_ID</varname>+<varname>IMAGE_VERSION</varname> are updated when the entire system
+          image is replaced during an update. <varname>BUILD_ID</varname> may be used in distributions where
+          the original installation image version is important: <varname>VERSION_ID</varname> would change
+          during incremental system updates, but <varname>BUILD_ID</varname> would not. This field is
+          optional.</para>
+
+          <para>Examples: <literal>BUILD_ID="2013-03-20.3"</literal>, <literal>BUILD_ID=201303203</literal>.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v200"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>IMAGE_ID=</varname></term>
+
+          <listitem><para> A lower-case string (no spaces or other characters outside of 0–9, a–z, ".", "_"
+          and "-"), identifying a specific image of the operating system. This is supposed to be used for
+          environments where OS images are prepared, built, shipped and updated as comprehensive, consistent
+          OS images. This field is optional and may not be implemented on all systems, in particularly not on
+          those that are not managed via images but put together and updated from individual packages and on
+          the local system.</para>
+
+          <para>Examples: <literal>IMAGE_ID=vendorx-cashier-system</literal>,
+          <literal>IMAGE_ID=netbook-image</literal>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v249"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>IMAGE_VERSION=</varname></term>
+
+          <listitem><para>A lower-case string (mostly numeric, no spaces or other characters outside of 0–9,
+          a–z, ".", "_" and "-") identifying the OS image version. This is supposed to be used together with
+          <varname>IMAGE_ID</varname> described above, to discern different versions of the same image.
+          </para>
+
+          <para>Examples: <literal>IMAGE_VERSION=33</literal>, <literal>IMAGE_VERSION=47.1rc1</literal>.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v249"/></listitem>
+        </varlistentry>
+      </variablelist>
+
+      <para>To summarize: if the image updates are built and shipped as comprehensive units,
+      <varname>IMAGE_ID</varname>+<varname>IMAGE_VERSION</varname> is the best fit. Otherwise, if updates
+      eventually completely replace previously installed contents, as in a typical binary distribution,
+      <varname>VERSION_ID</varname> should be used to identify major releases of the operating system.
+      <varname>BUILD_ID</varname> may be used instead or in addition to <varname>VERSION_ID</varname> when
+      the original system image version is important.</para>
+    </refsect2>
+
+    <refsect2>
+      <title>Presentation information and links</title>
+
+      <variablelist class='environment-variables'>
+        <varlistentry>
+          <term><varname>HOME_URL=</varname></term>
+          <term><varname>DOCUMENTATION_URL=</varname></term>
+          <term><varname>SUPPORT_URL=</varname></term>
+          <term><varname>BUG_REPORT_URL=</varname></term>
+          <term><varname>PRIVACY_POLICY_URL=</varname></term>
+
+          <listitem><para>Links to resources on the Internet related to the operating system.
+          <varname>HOME_URL=</varname> should refer to the homepage of the operating system, or alternatively
+          some homepage of the specific version of the operating system.
+          <varname>DOCUMENTATION_URL=</varname> should refer to the main documentation page for this
+          operating system.  <varname>SUPPORT_URL=</varname> should refer to the main support page for the
+          operating system, if there is any. This is primarily intended for operating systems which vendors
+          provide support for. <varname>BUG_REPORT_URL=</varname> should refer to the main bug reporting page
+          for the operating system, if there is any. This is primarily intended for operating systems that
+          rely on community QA. <varname>PRIVACY_POLICY_URL=</varname> should refer to the main privacy
+          policy page for the operating system, if there is any. These settings are optional, and providing
+          only some of these settings is common. These URLs are intended to be exposed in "About this system"
+          UIs behind links with captions such as "About this Operating System", "Obtain Support", "Report a
+          Bug", or "Privacy Policy". The values should be in <ulink
+          url="https://tools.ietf.org/html/rfc3986">RFC3986 format</ulink>, and should be
+          <literal>http:</literal> or <literal>https:</literal> URLs, and possibly <literal>mailto:</literal>
+          or <literal>tel:</literal>. Only one URL shall be listed in each setting. If multiple resources
+          need to be referenced, it is recommended to provide an online landing page linking all available
+          resources.</para>
+
+          <para>Examples: <literal>HOME_URL="https://fedoraproject.org/"</literal>,
+          <literal>BUG_REPORT_URL="https://bugzilla.redhat.com/"</literal>.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>SUPPORT_END=</varname></term>
+
+          <listitem><para>The date at which support for this version of the OS ends. (What exactly "lack of
+          support" means varies between vendors, but generally users should assume that updates, including
+          security fixes, will not be provided.) The value is a date in the ISO 8601 format
+          <literal>YYYY-MM-DD</literal>, and specifies the first day on which support <emphasis>is
+          not</emphasis> provided.</para>
+
+          <para>For example, <literal>SUPPORT_END=2001-01-01</literal> means that the system was supported
+          until the end of the last day of the previous millennium.</para>
+
+          <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>LOGO=</varname></term>
+
+          <listitem><para>A string, specifying the name of an icon as defined by <ulink
+          url="https://standards.freedesktop.org/icon-theme-spec/latest">freedesktop.org Icon Theme
+          Specification</ulink>. This can be used by graphical applications to display an operating system's
+          or distributor's logo. This field is optional and may not necessarily be implemented on all
+          systems.</para>
+
+          <para>Examples: <literal>LOGO=fedora-logo</literal>, <literal>LOGO=distributor-logo-opensuse</literal>
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v240"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>ANSI_COLOR=</varname></term>
+
+          <listitem><para>A suggested presentation color when showing the OS name on the console. This should
+          be specified as string suitable for inclusion in the ESC [ m ANSI/ECMA-48 escape code for setting
+          graphical rendition. This field is optional.</para>
+
+          <para>Examples: <literal>ANSI_COLOR="0;31"</literal> for red, <literal>ANSI_COLOR="1;34"</literal>
+          for light blue, or <literal>ANSI_COLOR="0;38;2;60;110;180"</literal> for Fedora blue.
+          </para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>VENDOR_NAME=</varname></term>
+
+          <listitem><para>The name of the OS vendor. This is the name of the organization or company which
+          produces the OS. This field is optional.</para>
+
+          <para>This name is intended to be exposed in "About this system" UIs or software update UIs when
+          needed to distinguish the OS vendor from the OS itself. It is intended to be human readable.</para>
+
+          <para>Examples: <literal>VENDOR_NAME="Fedora Project"</literal> for Fedora Linux,
+          <literal>VENDOR_NAME="Canonical"</literal> for Ubuntu.</para>
+
+          <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>VENDOR_URL=</varname></term>
+
+          <listitem><para>The homepage of the OS vendor. This field is optional. The
+          <varname>VENDOR_NAME=</varname> field should be set if this one is, although clients must be
+          robust against either field not being set.</para>
+
+          <para>The value should be in <ulink
+          url="https://tools.ietf.org/html/rfc3986">RFC3986 format</ulink>, and should be
+          <literal>http:</literal> or <literal>https:</literal> URLs. Only one URL shall be listed in the
+          setting.</para>
+
+          <para>Examples: <literal>VENDOR_URL="https://fedoraproject.org/"</literal>,
+          <literal>VENDOR_URL="https://canonical.com/"</literal>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+
+    <refsect2>
+      <title>Distribution-level defaults and metadata</title>
+
+      <variablelist class='environment-variables'>
+        <varlistentry>
+          <term><varname>DEFAULT_HOSTNAME=</varname></term>
+
+          <listitem><para>A string specifying the hostname if
+          <citerefentry><refentrytitle>hostname</refentrytitle><manvolnum>5</manvolnum></citerefentry> is not
+          present and no other configuration source specifies the hostname. Must be either a single DNS label
+          (a string composed of 7-bit ASCII lower-case characters and no spaces or dots, limited to the
+          format allowed for DNS domain name labels), or a sequence of such labels separated by single dots
+          that forms a valid DNS FQDN. The hostname must be at most 64 characters, which is a Linux
+          limitation (DNS allows longer names).</para>
+
+          <para>See <citerefentry><refentrytitle>org.freedesktop.hostname1</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+          for a description of how
+          <citerefentry><refentrytitle>systemd-hostnamed.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+          determines the fallback hostname.</para>
+
+          <xi:include href="version-info.xml" xpointer="v248"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>ARCHITECTURE=</varname></term>
+          <listitem><para>A string that specifies which CPU architecture the userspace binaries require.
+          The architecture identifiers are the same as for <varname>ConditionArchitecture=</varname>
+          described in <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+          The field is optional and should only be used when just single architecture is supported.
+          It may provide redundant information when used in a GPT partition with a GUID type that already
+          encodes the architecture. If this is not the case, the architecture should be specified in
+          e.g., an extension image, to prevent an incompatible host from loading it.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>SYSEXT_LEVEL=</varname></term>
+
+          <listitem><para>A lower-case string (mostly numeric, no spaces or other characters outside of 0–9,
+          a–z, ".", "_" and "-") identifying the operating system extensions support level, to indicate which
+          extension images are supported. See <filename>/usr/lib/extension-release.d/extension-release.<replaceable>IMAGE</replaceable></filename>,
+          <ulink url="https://docs.kernel.org/admin-guide/initrd.html">initrd</ulink> and
+          <citerefentry><refentrytitle>systemd-sysext</refentrytitle><manvolnum>8</manvolnum></citerefentry>)
+          for more information.</para>
+
+          <para>Examples: <literal>SYSEXT_LEVEL=2</literal>, <literal>SYSEXT_LEVEL=15.14</literal>.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v248"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>CONFEXT_LEVEL=</varname></term>
+
+          <listitem><para>Semantically the same as <varname>SYSEXT_LEVEL=</varname> but for confext images.
+          See <filename>/etc/extension-release.d/extension-release.<replaceable>IMAGE</replaceable></filename>
+          for more information.</para>
+
+          <para>Examples: <literal>CONFEXT_LEVEL=2</literal>, <literal>CONFEXT_LEVEL=15.14</literal>.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>SYSEXT_SCOPE=</varname></term>
+          <listitem><para>Takes a space-separated list of one or more of the strings
+          <literal>system</literal>, <literal>initrd</literal> and <literal>portable</literal>. This field is
+          only supported in <filename>extension-release.d/</filename> files and indicates what environments
+          the system extension is applicable to: i.e. to regular systems, to initrds, or to portable service
+          images. If unspecified, <literal>SYSEXT_SCOPE=system portable</literal> is implied, i.e. any system
+          extension without this field is applicable to regular systems and to portable service environments,
+          but not to initrd environments.</para>
+
+          <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>CONFEXT_SCOPE=</varname></term>
+
+          <listitem><para>Semantically the same as <varname>SYSEXT_SCOPE=</varname> but for confext images.</para>
+
+          <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>PORTABLE_PREFIXES=</varname></term>
+          <listitem><para>Takes a space-separated list of one or more valid prefix match strings for the
+          <ulink url="https://systemd.io/PORTABLE_SERVICES">Portable Services</ulink> logic.
+          This field serves two purposes: it is informational, identifying portable service images as such
+          (and thus allowing them to be distinguished from other OS images, such as bootable system images).
+          It is also used when a portable service image is attached: the specified or implied portable
+          service prefix is checked against the list specified here, to enforce restrictions how images may
+          be attached to a system.</para>
+
+          <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+
+    <refsect2>
+      <title>Notes</title>
+
+      <para>If you are using this file to determine the OS or a specific version of it, use the
+      <varname>ID</varname> and <varname>VERSION_ID</varname> fields, possibly with
+      <varname>ID_LIKE</varname> as fallback for <varname>ID</varname>. When looking for an OS identification
+      string for presentation to the user use the <varname>PRETTY_NAME</varname> field.</para>
+
+      <para>Note that operating system vendors may choose not to provide version information, for example to
+      accommodate for rolling releases. In this case, <varname>VERSION</varname> and
+      <varname>VERSION_ID</varname> may be unset. Applications should not rely on these fields to be
+      set.</para>
+
+      <para>Operating system vendors may extend the file format and introduce new fields. It is highly
+      recommended to prefix new fields with an OS specific name in order to avoid name clashes. Applications
+      reading this file must ignore unknown fields.</para>
+
+      <para>Example: <literal>DEBIAN_BTS="debbugs://bugs.debian.org/"</literal>.</para>
+
+      <para>Container and sandbox runtime managers may make the host's identification data available to
+      applications by providing the host's <filename>/etc/os-release</filename> (if available, otherwise
+      <filename>/usr/lib/os-release</filename> as a fallback) as
+      <filename>/run/host/os-release</filename>.</para>
+    </refsect2>
+  </refsect1>
+
+  <refsect1>
+    <title>Examples</title>
+
+    <example>
+      <title><filename>os-release</filename> file for Fedora Workstation</title>
+
+      <programlisting>NAME=Fedora
+VERSION="32 (Workstation Edition)"
+ID=fedora
+VERSION_ID=32
+PRETTY_NAME="Fedora 32 (Workstation Edition)"
+ANSI_COLOR="0;38;2;60;110;180"
+LOGO=fedora-logo-icon
+CPE_NAME="cpe:/o:fedoraproject:fedora:32"
+HOME_URL="https://fedoraproject.org/"
+DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/f32/system-administrators-guide/"
+SUPPORT_URL="https://fedoraproject.org/wiki/Communicating_and_getting_help"
+BUG_REPORT_URL="https://bugzilla.redhat.com/"
+REDHAT_BUGZILLA_PRODUCT="Fedora"
+REDHAT_BUGZILLA_PRODUCT_VERSION=32
+REDHAT_SUPPORT_PRODUCT="Fedora"
+REDHAT_SUPPORT_PRODUCT_VERSION=32
+PRIVACY_POLICY_URL="https://fedoraproject.org/wiki/Legal:PrivacyPolicy"
+VARIANT="Workstation Edition"
+VARIANT_ID=workstation</programlisting>
+    </example>
+
+    <example>
+      <title><filename>extension-release</filename> file for an extension for Fedora Workstation 32</title>
+
+      <programlisting>ID=fedora
+VERSION_ID=32</programlisting>
+    </example>
+
+    <example>
+      <title>Reading <filename>os-release</filename> in
+      <citerefentry project='man-pages'><refentrytitle>sh</refentrytitle><manvolnum>1</manvolnum></citerefentry></title>
+
+      <programlisting><xi:include href="check-os-release.sh" parse="text" /></programlisting>
+    </example>
+
+    <example>
+      <title>Reading <filename>os-release</filename> in
+      <citerefentry project='die-net'><refentrytitle>python</refentrytitle><manvolnum>1</manvolnum></citerefentry> (versions &gt;= 3.10)</title>
+
+      <programlisting><xi:include href="check-os-release-simple.py" parse="text" /></programlisting>
+
+      <para>See docs for <ulink url="https://docs.python.org/3/library/platform.html#platform.freedesktop_os_release">
+      <function>platform.freedesktop_os_release</function></ulink> for more details.
+      </para>
+    </example>
+
+    <example>
+      <title>Reading <filename>os-release</filename> in
+      <citerefentry project='die-net'><refentrytitle>python</refentrytitle><manvolnum>1</manvolnum></citerefentry> (any version)</title>
+
+      <programlisting><xi:include href="check-os-release.py" parse="text" /></programlisting>
+
+      <para>Note that the above version that uses the built-in implementation is preferred
+      in most cases, and the open-coded version here is provided for reference.</para>
+    </example>
+
+  </refsect1>
+
+  <refsect1>
+      <title>See Also</title>
+      <para>
+        <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+        <citerefentry project='die-net'><refentrytitle>lsb_release</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>hostname</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>machine-info</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+      </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/pam_systemd.xml b/man/pam_systemd.xml
new file mode 100644
index 0000000..50f44f0
--- /dev/null
+++ b/man/pam_systemd.xml
@@ -0,0 +1,395 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="pam_systemd" conditional='HAVE_PAM' xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>pam_systemd</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>pam_systemd</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>pam_systemd</refname>
+    <refpurpose>Register user sessions in the systemd login manager</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>pam_systemd.so</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>pam_systemd</command> registers user sessions with
+    the systemd login manager
+    <citerefentry><refentrytitle>systemd-logind.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+    and hence the systemd control group hierarchy.</para>
+
+    <para>The module also applies various resource management and runtime parameters to the new session, as
+    configured in the <ulink url="https://systemd.io/USER_RECORD">JSON User Records</ulink> of the user, when
+    one is defined.</para>
+
+    <para>On login, this module — in conjunction with <filename>systemd-logind.service</filename> — ensures the
+    following:</para>
+
+    <orderedlist>
+      <listitem><para>If it does not exist yet, the user runtime directory <filename>/run/user/$UID</filename> is
+      either created or mounted as new <literal>tmpfs</literal> file system with quota applied, and its ownership
+      changed to the user that is logging in.</para></listitem>
+
+      <listitem><para>The <varname>$XDG_SESSION_ID</varname> environment variable is initialized. If auditing is
+      available and <command>pam_loginuid.so</command> was run before this module (which is highly recommended), the
+      variable is initialized from the auditing session id (<filename>/proc/self/sessionid</filename>). Otherwise, an
+      independent session counter is used.</para></listitem>
+
+      <listitem><para>A new systemd scope unit is created for the session. If this is the first concurrent session of
+      the user, an implicit per-user slice unit below <filename>user.slice</filename> is automatically created and the
+      scope placed into it. An instance of the system service <filename>user@.service</filename>, which runs the
+      systemd user manager instance, is started.</para></listitem>
+
+      <listitem><para>The <literal>$TZ</literal>, <literal>$EMAIL</literal> and <literal>$LANG</literal>
+      environment variables are configured for the user, based on the respective data from the user's JSON
+      record (if it is defined). Moreover, any environment variables explicitly configured in the user record
+      are imported, and the umask, nice level, and resource limits initialized.</para></listitem>
+    </orderedlist>
+
+    <para>On logout, this module ensures the following:</para>
+
+    <orderedlist>
+      <listitem><para>If enabled in
+      <citerefentry><refentrytitle>logind.conf</refentrytitle>
+      <manvolnum>5</manvolnum></citerefentry> (<varname>KillUserProcesses=</varname>), all processes of the session are
+      terminated. If the last concurrent session of a user ends, the user's systemd instance will be terminated too,
+      and so will the user's slice unit.</para></listitem>
+
+      <listitem><para>If the last concurrent session of a user ends,
+      the user runtime directory <filename>/run/user/$UID</filename> and all its
+      contents are removed, too.</para></listitem>
+    </orderedlist>
+
+    <para>If the system was not booted up with systemd as init system,
+    this module does nothing and immediately returns
+    <constant>PAM_SUCCESS</constant>.</para>
+
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>The following options are understood:</para>
+
+    <variablelist class='pam-directives'>
+
+      <varlistentry>
+        <term><varname>class=</varname></term>
+
+        <listitem><para>Takes a string argument which sets the session class. The <varname>XDG_SESSION_CLASS</varname>
+        environment variable (see below) takes precedence. One of <literal>user</literal>, <literal>greeter</literal>,
+        <literal>lock-screen</literal> or <literal>background</literal>. See
+        <citerefentry><refentrytitle>sd_session_get_class</refentrytitle><manvolnum>3</manvolnum></citerefentry> for
+        details about the session class.</para>
+
+        <xi:include href="version-info.xml" xpointer="v197"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>type=</varname></term>
+
+        <listitem><para>Takes a string argument which sets the session type. The <varname>XDG_SESSION_TYPE</varname>
+        environment variable (see below) takes precedence. One of <literal>unspecified</literal>,
+        <literal>tty</literal>, <literal>x11</literal>, <literal>wayland</literal> or <literal>mir</literal>. See
+        <citerefentry><refentrytitle>sd_session_get_type</refentrytitle><manvolnum>3</manvolnum></citerefentry> for
+        details about the session type.</para>
+
+        <xi:include href="version-info.xml" xpointer="v209"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>desktop=</varname></term>
+
+        <listitem><para>Takes a single, short identifier string for the desktop environment. The
+        <varname>XDG_SESSION_DESKTOP</varname> environment variable (see below) takes precedence. This may be used to
+        indicate the session desktop used, where this applies and if this information is available. For example:
+        <literal>GNOME</literal>, or <literal>KDE</literal>. It is recommended to use the same identifiers and
+        capitalization as for <varname>$XDG_CURRENT_DESKTOP</varname>, as defined by the <ulink
+        url="https://standards.freedesktop.org/desktop-entry-spec/latest/">Desktop Entry
+        Specification</ulink>. (However, note that the option only takes a single item, and not a colon-separated list
+        like <varname>$XDG_CURRENT_DESKTOP</varname>.) See
+        <citerefentry><refentrytitle>sd_session_get_desktop</refentrytitle><manvolnum>3</manvolnum></citerefentry> for
+        further details.</para>
+
+        <xi:include href="version-info.xml" xpointer="v240"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>default-capability-bounding-set=</varname></term>
+        <term><varname>default-capability-ambient-set=</varname></term>
+
+        <listitem><para>Takes a comma-separated list of process capabilities
+        (e.g. <constant>CAP_WAKE_ALARM</constant>, <constant>CAP_BLOCK_SUSPEND</constant>, …) to set for the
+        invoked session's processes, if the user record does not encode appropriate sets of capabilities
+        directly. See <citerefentry
+        project='man-pages'><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+        for details on the capabilities concept. If not specified, the default bounding set is left as is
+        (i.e. usually contains the full set of capabilities). The default ambient set is set to
+        <constant>CAP_WAKE_ALARM</constant> for regular users if the PAM session is associated with a local
+        seat or if it is invoked for the <literal>systemd-user</literal> service. Otherwise defaults to the
+        empty set.</para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>debug</varname><optional>=</optional></term>
+
+        <listitem><para>Takes an optional boolean argument. If yes or without the argument, the module will log
+        debugging information as it operates.</para></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Module Types Provided</title>
+
+    <para>Only <option>session</option> is provided.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Environment</title>
+
+    <para>The following environment variables are initialized by the module and available to the processes of the
+    user's session:</para>
+
+    <variablelist class='environment-variables'>
+      <varlistentry>
+        <term><varname>$XDG_SESSION_ID</varname></term>
+
+        <listitem><para>A short session identifier, suitable to be used in filenames. The string itself should be
+        considered opaque, although often it is just the audit session ID as reported by
+        <filename>/proc/self/sessionid</filename>. Each ID will be assigned only once during machine uptime. It may
+        hence be used to uniquely label files or other resources of this session. Combine this ID with the boot
+        identifier, as returned by
+        <citerefentry><refentrytitle>sd_id128_get_boot</refentrytitle><manvolnum>3</manvolnum></citerefentry>, for a
+        globally unique identifier.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>$XDG_RUNTIME_DIR</varname></term>
+
+        <listitem><para>Path to a user-private user-writable directory
+        that is bound to the user login time on the machine. It is
+        automatically created the first time a user logs in and
+        removed on the user's final logout. If a user logs in twice at
+        the same time, both sessions will see the same
+        <varname>$XDG_RUNTIME_DIR</varname> and the same contents. If
+        a user logs in once, then logs out again, and logs in again,
+        the directory contents will have been lost in between, but
+        applications should not rely on this behavior and must be able
+        to deal with stale files. To store session-private data in
+        this directory, the user should include the value of
+        <varname>$XDG_SESSION_ID</varname> in the filename. This
+        directory shall be used for runtime file system objects such
+        as <constant>AF_UNIX</constant> sockets, FIFOs, PID files and
+        similar. It is guaranteed that this directory is local and
+        offers the greatest possible file system feature set the
+        operating system provides. For further details, see the <ulink
+        url="https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html">XDG
+        Base Directory Specification</ulink>. <varname>$XDG_RUNTIME_DIR</varname>
+        is not set if the current user is not the original user of the session.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>$TZ</varname></term>
+        <term><varname>$EMAIL</varname></term>
+        <term><varname>$LANG</varname></term>
+
+        <listitem><para>If a JSON user record is known for the user logging in these variables are
+        initialized from the respective data in the record.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+    </variablelist>
+
+    <para>The following environment variables are read by the module and may be used by the PAM service to pass
+    metadata to the module. If these variables are not set when the PAM module is invoked but can be determined
+    otherwise they are set by the module, so that these variables are initialized for the session and applications if
+    known at all.</para>
+
+    <variablelist class='environment-variables'>
+      <varlistentry>
+        <term><varname>$XDG_SESSION_TYPE</varname></term>
+
+        <listitem><para>The session type. This may be used instead of <varname>type=</varname> on the module parameter
+        line, and is usually preferred.</para>
+
+        <xi:include href="version-info.xml" xpointer="v209"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>$XDG_SESSION_CLASS</varname></term>
+
+        <listitem><para>The session class. This may be used instead of <varname>class=</varname> on the module parameter
+        line, and is usually preferred.</para>
+
+        <xi:include href="version-info.xml" xpointer="v209"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>$XDG_SESSION_DESKTOP</varname></term>
+
+        <listitem><para>The desktop identifier. This may be used instead of <varname>desktop=</varname> on the module
+        parameter line, and is usually preferred.</para>
+
+        <xi:include href="version-info.xml" xpointer="v209"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>$XDG_SEAT</varname></term>
+
+        <listitem><para>The seat name the session shall be registered
+        for, if any.</para>
+
+        <xi:include href="version-info.xml" xpointer="v209"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>$XDG_VTNR</varname></term>
+
+        <listitem><para>The VT number the session shall be registered
+        for, if any. (Only applies to seats with a VT available, such
+        as <literal>seat0</literal>)</para>
+
+        <xi:include href="version-info.xml" xpointer="v209"/></listitem>
+      </varlistentry>
+    </variablelist>
+
+    <para>If not set, <command>pam_systemd</command> will initialize
+    <varname>$XDG_SEAT</varname> and <varname>$XDG_VTNR</varname>
+    based on the <varname>$DISPLAY</varname> variable (if the latter is set).</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Session limits</title>
+
+    <para>PAM modules earlier in the stack, that is those that come before <command>pam_systemd.so</command>,
+    can set session scope limits using the PAM context objects. The data for these objects is provided as <constant>NUL</constant>-terminated C strings
+    and maps directly to the respective unit resource control directives. Note that these limits apply to individual sessions of the user,
+    they do not apply to all user processes as a combined whole. In particular, the per-user <command>user@.service</command> unit instance,
+    which runs the <command>systemd --user</command> manager process and its children, and is tracked outside of any session, being shared
+    by all the user's sessions, is not covered by these limits.
+    </para>
+
+    <para> See
+    <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry> for more information about the resources.
+    Also, see <citerefentry project='man-pages'><refentrytitle>pam_set_data</refentrytitle><manvolnum>3</manvolnum></citerefentry> for additional information about how to set
+    the context objects.
+    </para>
+
+    <variablelist class='pam-directives'>
+      <varlistentry>
+        <term><varname>systemd.memory_max=</varname></term>
+
+        <listitem><para>Sets unit <varname>MemoryMax=</varname>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>systemd.tasks_max=</varname></term>
+
+        <listitem><para>Sets unit <varname>TasksMax=</varname>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>systemd.cpu_weight=</varname></term>
+
+        <listitem><para>Sets unit <varname>CPUWeight=</varname>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>systemd.io_weight=</varname></term>
+
+        <listitem><para>Sets unit <varname>IOWeight=</varname>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>systemd.runtime_max_sec=</varname></term>
+
+        <listitem><para>Sets unit <varname>RuntimeMaxSec=</varname>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v244"/></listitem>
+      </varlistentry>
+    </variablelist>
+
+    <para>Example data as can be provided from an another PAM module:
+      <programlisting>
+pam_set_data(handle, "systemd.memory_max", (void *)"200M", cleanup);
+pam_set_data(handle, "systemd.tasks_max",  (void *)"50",   cleanup);
+pam_set_data(handle, "systemd.cpu_weight", (void *)"100",  cleanup);
+pam_set_data(handle, "systemd.io_weight",  (void *)"340",  cleanup);
+pam_set_data(handle, "systemd.runtime_max_sec", (void *)"3600", cleanup);
+      </programlisting>
+    </para>
+
+  </refsect1>
+
+  <refsect1>
+    <title>Example</title>
+
+    <para>Here's an example PAM configuration fragment that allows users sessions to be managed by
+    <filename>systemd-logind.service</filename>:</para>
+
+    <programlisting>#%PAM-1.0
+auth      sufficient pam_unix.so
+-auth     sufficient pam_systemd_home.so
+auth      required   pam_deny.so
+
+account   required   pam_nologin.so
+-account  sufficient pam_systemd_home.so
+account   sufficient pam_unix.so
+account   required   pam_permit.so
+
+-password sufficient pam_systemd_home.so
+password  sufficient pam_unix.so sha512 shadow try_first_pass
+password  required   pam_deny.so
+
+-session  optional   pam_keyinit.so revoke
+-session  optional   pam_loginuid.so
+-session  optional   pam_systemd_home.so
+<command>-session  optional   pam_systemd.so</command>
+session   required   pam_unix.so</programlisting>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-logind.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>logind.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>loginctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>pam_systemd_home</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>pam.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>pam.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>pam</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>pam_loginuid</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.scope</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/pam_systemd_home.xml b/man/pam_systemd_home.xml
new file mode 100644
index 0000000..dd28de1
--- /dev/null
+++ b/man/pam_systemd_home.xml
@@ -0,0 +1,185 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="pam_systemd_home" conditional='ENABLE_PAM_HOME'
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>pam_systemd_home</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>pam_systemd_home</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>pam_systemd_home</refname>
+    <refpurpose>Authenticate users and mount home directories via <filename>systemd-homed.service</filename>
+    </refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>pam_systemd_home.so</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>pam_systemd_home</command> ensures that home directories managed by
+    <citerefentry><refentrytitle>systemd-homed.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    are automatically activated (mounted) on user login, and are deactivated (unmounted) when the last
+    session of the user ends. For such users, it also provides authentication (when per-user disk encryption
+    is used, the disk encryption key is derived from the authentication credential supplied at login time),
+    account management (the <ulink url="https://systemd.io/USER_RECORD/">JSON user record</ulink> embedded in
+    the home store contains account details), and implements the updating of the encryption password (which
+    is also used for user authentication).</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>The following options are understood:</para>
+
+    <variablelist class='pam-directives'>
+
+      <varlistentry>
+        <term><varname>suspend=</varname></term>
+
+        <listitem><para>Takes a boolean argument. If true, the home directory of the user will be suspended
+        automatically during system suspend; if false it will remain active. Automatic suspending of the home
+        directory improves security substantially as secret key material is automatically removed from memory
+        before the system is put to sleep and must be re-acquired (through user re-authentication) when
+        coming back from suspend. It is recommended to set this parameter for all PAM applications that have
+        support for automatically re-authenticating via PAM on system resume. If multiple sessions of the
+        same user are open in parallel the user's home directory will be left unsuspended on system suspend
+        as long as at least one of the sessions does not set this parameter to on. Defaults to
+        off.</para>
+
+        <para>Note that TTY logins generally do not support re-authentication on system resume.
+        Re-authentication on system resume is primarily a concept implementable in graphical environments, in
+        the form of lock screens brought up automatically when the system goes to sleep. This means that if a
+        user concurrently uses graphical login sessions that implement the required re-authentication
+        mechanism and console logins that do not, the home directory is not locked during suspend, due to the
+        logic explained above. That said, it is possible to set this field for TTY logins too, ignoring the
+        fact that TTY logins actually don't support the re-authentication mechanism. In that case the TTY
+        sessions will appear hung until the user logs in on another virtual terminal (regardless if via
+        another TTY session or graphically) which will resume the home directory and unblock the original TTY
+        session. (Do note that lack of screen locking on TTY sessions means even though the TTY session
+        appears hung, keypresses can still be queued into it, and the existing screen contents be read
+        without re-authentication; this limitation is unrelated to the home directory management
+        <command>pam_systemd_home</command> and <filename>systemd-homed.service</filename> implement.)</para>
+
+        <para>Turning this option on by default is highly recommended for all sessions, but only if the
+        service managing these sessions correctly implements the aforementioned re-authentication. Note that
+        the re-authentication must take place from a component running outside of the user's context, so that
+        it does not require access to the user's home directory for operation. Traditionally, most desktop
+        environments do not implement screen locking this way, and need to be updated
+        accordingly.</para>
+
+        <para>This setting may also be controlled via the <varname>$SYSTEMD_HOME_SUSPEND</varname>
+        environment variable (see below), which <command>pam_systemd_home</command> reads during initialization and sets
+        for sessions. If both the environment variable is set and the module parameter specified the latter
+        takes precedence.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>debug</varname><optional>=</optional></term>
+
+        <listitem><para>Takes an optional boolean argument. If yes or without the argument, the module will log
+        debugging information as it operates.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Module Types Provided</title>
+
+    <para>The module implements all four PAM operations: <option>auth</option> (to allow authentication using
+    the encrypted data), <option>account</option> (because users with
+    <filename>systemd-homed.service</filename> user accounts are described in a <ulink
+    url="https://systemd.io/USER_RECORD/">JSON user record</ulink> and may be configured in more detail than
+    in the traditional Linux user database), <option>session</option> (because user sessions must be tracked
+    in order to implement automatic release when the last session of the user is gone),
+    <option>password</option> (to change the encryption password — also used for user authentication —
+    through PAM).</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Environment</title>
+
+    <para>The following environment variables are initialized by the module and available to the processes of the
+    user's session:</para>
+
+    <variablelist class='environment-variables'>
+      <varlistentry>
+        <term><varname>$SYSTEMD_HOME=1</varname></term>
+
+        <listitem><para>Indicates that the user's home directory is managed by <filename>systemd-homed.service</filename>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>$SYSTEMD_HOME_SUSPEND=</varname></term>
+
+        <listitem><para>Indicates whether the session has been registered with the suspend mechanism enabled
+        or disabled (see above). The variable's value is either <literal>0</literal> or
+        <literal>1</literal>. Note that the module both reads the variable when initializing, and sets it for
+        sessions.</para>
+
+        <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+      </varlistentry>
+
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Example</title>
+
+    <para>Here's an example PAM configuration fragment that permits users managed by
+    <filename>systemd-homed.service</filename> to log in:</para>
+
+    <programlisting>#%PAM-1.0
+auth      sufficient pam_unix.so
+<command>-auth     sufficient pam_systemd_home.so</command>
+auth      required   pam_deny.so
+
+account   required   pam_nologin.so
+<command>-account  sufficient pam_systemd_home.so</command>
+account   sufficient pam_unix.so
+account   required   pam_permit.so
+
+<command>-password sufficient pam_systemd_home.so</command>
+password  sufficient pam_unix.so sha512 shadow try_first_pass
+password  required   pam_deny.so
+
+-session  optional   pam_keyinit.so revoke
+-session  optional   pam_loginuid.so
+<command>-session  optional   pam_systemd_home.so</command>
+-session  optional   pam_systemd.so
+session   required   pam_unix.so</programlisting>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-homed.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>homed.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>homectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>pam_systemd</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>pam.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>pam.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>pam</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/pam_systemd_loadkey.xml b/man/pam_systemd_loadkey.xml
new file mode 100644
index 0000000..afb41f3
--- /dev/null
+++ b/man/pam_systemd_loadkey.xml
@@ -0,0 +1,99 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="pam_systemd_loadkey" conditional='HAVE_PAM' xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>pam_systemd_loadkey</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>pam_systemd_loadkey</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>pam_systemd_loadkey</refname>
+    <refpurpose>Read password from kernel keyring and set it as PAM authtok</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>pam_systemd_loadkey.so</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>pam_systemd_loadkey</command> reads a NUL-separated password list from the kernel keyring,
+    and sets the last password in the list as the PAM authtok.</para>
+
+    <para>The password list is supposed to be stored in the "user" keyring of the root user,
+    by an earlier call to
+    <citerefentry><refentrytitle>systemd-ask-password</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    with <option>--keyname=</option>.
+    You can pass the keyname to <command>pam_systemd_loadkey</command> via the <option>keyname=</option> option.</para>
+
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>The following options are understood:</para>
+
+    <variablelist class='pam-directives'>
+
+      <varlistentry>
+        <term><varname>keyname=</varname></term>
+
+        <listitem><para>Takes a string argument which sets the keyname to read.
+        The default is <literal>cryptsetup</literal>, which is used by
+        <citerefentry><refentrytitle>systemd-cryptsetup@.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        to store LUKS passphrase during boot.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>debug</varname></term>
+
+        <listitem><para>The module will log debugging information as it operates.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Example</title>
+
+    <para>This module is intended to be used when you use LUKS with a passphrase, enable autologin in the display
+    manager, and want to unlock Gnome Keyring / KDE KWallet automatically. So in total, you only enter one password
+    during boot.</para>
+
+    <para>You need to set the password of your Gnome Keyring/KWallet to the same as your LUKS passphrase.
+    Then add the following lines to your display manager's PAM config under <filename>/etc/pam.d/</filename> (e.g. <filename>sddm-autologin</filename>):</para>
+
+    <programlisting>
+-auth       optional    pam_systemd_loadkey.so
+-session    optional    pam_gnome_keyring.so auto_start
+-session    optional    pam_kwallet5.so auto_start
+    </programlisting>
+
+    <para>And add the following lines to your display manager's systemd service file, so it can access root's keyring:</para>
+
+    <programlisting>
+[Service]
+KeyringMode=inherit
+    </programlisting>
+
+    <para>In this setup, early during the boot process,
+    <citerefentry><refentrytitle>systemd-cryptsetup@.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    will ask for the passphrase and store it in the kernel keyring with the keyname <literal>cryptsetup</literal>.
+    Then when the display manager does the autologin, pam_systemd_loadkey will read the passphrase from the kernel keyring,
+    set it as the PAM authtok, and then pam_gnome_keyring and pam_kwallet5 will unlock with the same passphrase.</para>
+  </refsect1>
+
+</refentry>
diff --git a/man/path-documents.c b/man/path-documents.c
new file mode 100644
index 0000000..a357dd6
--- /dev/null
+++ b/man/path-documents.c
@@ -0,0 +1,19 @@
+/* SPDX-License-Identifier: MIT-0 */
+
+#include <stdio.h>
+#include <stdlib.h>
+#include <sd-path.h>
+
+int main(void) {
+  int r;
+  char *t;
+
+  r = sd_path_lookup(SD_PATH_USER_DOCUMENTS, NULL, &t);
+  if (r < 0)
+    return EXIT_FAILURE;
+
+  printf("~/Documents: %s\n", t);
+  free(t);
+
+  return EXIT_SUCCESS;
+}
diff --git a/man/portablectl.xml b/man/portablectl.xml
new file mode 100644
index 0000000..03ca65e
--- /dev/null
+++ b/man/portablectl.xml
@@ -0,0 +1,515 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="portablectl" conditional='ENABLE_PORTABLED'
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>portablectl</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>portablectl</refentrytitle>
+    <manvolnum>1</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>portablectl</refname>
+    <refpurpose>Attach, detach or inspect portable service images</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <cmdsynopsis>
+      <command>portablectl</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="req">COMMAND</arg>
+      <arg choice="opt" rep="repeat">NAME</arg>
+    </cmdsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>portablectl</command> may be used to attach, detach or inspect portable service images. It's
+    primarily a command interfacing with
+    <citerefentry><refentrytitle>systemd-portabled.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
+
+    <para>Portable service images contain an OS file system tree along with
+    <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> unit file
+    information. A service image may be "attached" to the local system. If attached, a set of unit files are copied
+    from the image to the host, and extended with <varname>RootDirectory=</varname> or <varname>RootImage=</varname>
+    assignments (in case of service units) pointing to the image file or directory, ensuring the services will run
+    within the file system context of the image.</para>
+
+    <para>Portable service images are an efficient way to bundle multiple related services and other units together,
+    and transfer them as a whole between systems. When these images are attached the local system the contained units
+    may run in most ways like regular system-provided units, either with full privileges or inside strict sandboxing,
+    depending on the selected configuration. For more details, see
+    <ulink url="https://systemd.io/PORTABLE_SERVICES">Portable Services Documentation</ulink>.</para>
+
+    <para>Specifically portable service images may be of the following kind:</para>
+
+    <itemizedlist>
+      <listitem><para>Directory trees containing an OS, including the top-level directories <filename>/usr/</filename>,
+      <filename>/etc/</filename>, and so on.</para></listitem>
+
+      <listitem><para>btrfs subvolumes containing OS trees, similar to normal directory trees.</para></listitem>
+
+      <listitem><para>Binary "raw" disk images containing MBR or GPT partition tables and Linux file system
+      partitions. (These must be regular files, with the <filename>.raw</filename> suffix.)</para></listitem>
+    </itemizedlist>
+
+  </refsect1>
+
+  <refsect1>
+    <title>Commands</title>
+
+    <para>The following commands are understood:</para>
+
+    <variablelist>
+
+      <varlistentry>
+        <term><command>list</command></term>
+
+        <listitem><para>List available portable service images. This will list all portable service images discovered
+        in the portable image search paths (see below), along with brief metadata and state information. Note that many
+        of the commands below may both operate on images inside and outside of the search paths. This command is hence
+        mostly a convenience option, the commands are generally not restricted to what this list
+        shows.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>attach</command> <replaceable>IMAGE</replaceable> [<replaceable>PREFIX…</replaceable>]</term>
+
+        <listitem><para>Attach a portable service image to the host system. Expects a file system path to a portable
+        service image file or directory as first argument. If the specified path contains no slash character
+        (<literal>/</literal>) it is understood as image filename that is searched for in the portable service image
+        search paths (see below). To reference a file in the current working directory prefix the filename with
+        <literal>./</literal> to avoid this search path logic.</para>
+
+        <para>When a portable service is attached four operations are executed:</para>
+
+        <orderedlist>
+
+          <listitem><para>All unit files of types <filename>.service</filename>, <filename>.socket</filename>,
+          <filename>.target</filename>, <filename>.timer</filename> and <filename>.path</filename> which match the
+          indicated unit file name prefix are copied from the image to the host's
+          <filename>/etc/systemd/system.attached/</filename> directory (or
+          <filename>/run/systemd/system.attached/</filename> — depending whether <option>--runtime</option> is
+          specified, see below), which is included in the built-in unit search path of the system service
+          manager.</para></listitem>
+
+          <listitem><para>For unit files of type <filename>.service</filename> a drop-in is added to these copies that
+          adds <varname>RootDirectory=</varname> or <varname>RootImage=</varname> settings (see
+          <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
+          details), that ensures these services are run within the file system of the originating portable service
+          image.</para></listitem>
+
+          <listitem><para>A second drop-in is created: the "profile" drop-in, that may contain additional security
+          settings (and other settings). A number of profiles are available by default but administrators may define
+          their own ones. See below.</para></listitem>
+
+          <listitem><para>If the portable service image file is not already in the search path (see below), a symbolic
+          link to it is created in <filename>/etc/portables/</filename> or
+          <filename>/run/portables/</filename>, to make sure it is included in it.</para></listitem>
+        </orderedlist>
+
+        <para>By default all unit files whose names start with a prefix generated from the image's file name are copied
+        out. Specifically, the prefix is determined from the image file name with any suffix such as
+        <filename>.raw</filename> removed, truncated at the first occurrence of an underscore character
+        (<literal>_</literal>), if there is one. The underscore logic is supposed to be used to versioning so that the
+        an image file <filename>foobar_47.11.raw</filename> will result in a unit file matching prefix of
+        <filename>foobar</filename>. This prefix is then compared with all unit files names contained in the image in
+        the usual directories, but only unit file names where the prefix is followed by <literal>-</literal>,
+        <literal>.</literal> or <literal>@</literal> are considered. Example: if a portable service image file is named
+        <filename>foobar_47.11.raw</filename> then by default all its unit files with names such as
+        <filename>foobar-quux-waldi.service</filename>, <filename>foobar.service</filename> or
+        <filename>foobar@.service</filename> will be considered. It's possible to override the matching prefix: all
+        strings listed on the command line after the image file name are considered prefixes, overriding the implicit
+        logic where the prefix is derived from the image file name.</para>
+
+        <para>By default, after the unit files are attached the service manager's configuration is reloaded, except
+        when <option>--no-reload</option> is specified (see below). This ensures that the new units made available to
+        the service manager are seen by it.</para>
+
+        <para>If <option>--now</option> and/or <option>--enable</option> are passed, the portable services are
+        immediately started (blocking operation unless <option>--no-block</option> is passed) and/or enabled after
+        attaching the image.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>detach</command> <replaceable>IMAGE</replaceable> [<replaceable>PREFIX…</replaceable>]</term>
+
+        <listitem><para>Detaches a portable service image from the host. This undoes the operations executed by the
+        <command>attach</command> command above, and removes the unit file copies, drop-ins and image symlink
+        again. This command expects an image name or path as parameter. Note that if a path is specified only the last
+        component of it (i.e. the file or directory name itself, not the path to it) is used for finding matching unit
+        files. This is a convenience feature to allow all arguments passed as <command>attach</command> also to
+        <command>detach</command>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+
+        <para>If <option>--now</option> and/or <option>--enable</option> are passed, the portable services are
+        immediately stopped (blocking operation) and/or disabled before detaching the image. Prefix(es) are also accepted,
+        to be used in case the unit names do not match the image name as described in the <command>attach</command>.</para>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>reattach</command> <replaceable>IMAGE</replaceable> [<replaceable>PREFIX…</replaceable>]</term>
+
+        <listitem><para>Detaches an existing portable service image from the host, and immediately attaches it again.
+        This is useful in case the image was replaced. Running units are not stopped during the process. Partial matching,
+        to allow for different versions in the image name, is allowed: only the part before the first <literal>_</literal>
+        character has to match. If the new image doesn't exist, the existing one will not be detached. The parameters
+        follow the same syntax as the <command>attach</command> command.</para>
+
+        <xi:include href="version-info.xml" xpointer="v248"/></listitem>
+
+        <para>If <option>--now</option> and/or <option>--enable</option> are passed, the portable services are
+        immediately stopped if removed, started and/or enabled if added, or restarted if updated. Prefixes are also
+        accepted, in the same way as described in the <command>attach</command> case.</para>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>inspect</command> <replaceable>IMAGE</replaceable> [<replaceable>PREFIX…</replaceable>]</term>
+
+        <listitem><para>Extracts various metadata from a portable service image and presents it to the
+        caller. Specifically, the
+        <citerefentry><refentrytitle>os-release</refentrytitle><manvolnum>5</manvolnum></citerefentry> file of the
+        image is retrieved as well as all matching unit files. By default a short summary showing the most relevant
+        metadata in combination with a list of matching unit files is shown (that is the unit files
+        <command>attach</command> would install to the host system). If combined with <option>--cat</option> (see
+        above), the <filename>os-release</filename> data and the units files' contents is displayed unprocessed. This
+        command is useful to determine whether an image qualifies as portable service image, and which unit files are
+        included. This command expects the path to the image as parameter, optionally followed by a list of unit file
+        prefixes to consider, similar to the <command>attach</command> command described above.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>is-attached</command> <replaceable>IMAGE</replaceable></term>
+
+        <listitem><para>Determines whether the specified image is currently attached or not. Unless combined with the
+        <option>--quiet</option> switch this will show a short state identifier for the image. Specifically:</para>
+
+        <table>
+          <title>Image attachment states</title>
+          <tgroup cols='2'>
+            <colspec colname='state'/>
+            <colspec colname='description'/>
+            <thead>
+              <row>
+                <entry>State</entry>
+                <entry>Description</entry>
+              </row>
+            </thead>
+            <tbody>
+              <row>
+                <entry><option>detached</option></entry>
+                <entry>The image is currently not attached.</entry>
+              </row>
+              <row>
+                <entry><option>attached</option></entry>
+                <entry>The image is currently attached, i.e. its unit files have been made available to the host system.</entry>
+              </row>
+              <row>
+                <entry><option>attached-runtime</option></entry>
+                <entry>Like <option>attached</option>, but the unit files have been made available transiently only, i.e. the <command>attach</command> command has been invoked with the <option>--runtime</option> option.</entry>
+              </row>
+              <row>
+                <entry><option>enabled</option></entry>
+                <entry>The image is currently attached, and at least one unit file associated with it has been enabled.</entry>
+              </row>
+              <row>
+                <entry><option>enabled-runtime</option></entry>
+                <entry>Like <option>enabled</option>, but the unit files have been made available transiently only, i.e. the <command>attach</command> command has been invoked with the <option>--runtime</option> option.</entry>
+              </row>
+              <row>
+                <entry><option>running</option></entry>
+                <entry>The image is currently attached, and at least one unit file associated with it is running.</entry>
+              </row>
+              <row>
+                <entry><option>running-runtime</option></entry>
+                <entry>The image is currently attached transiently, and at least one unit file associated with it is running.</entry>
+              </row>
+            </tbody>
+          </tgroup>
+        </table>
+
+          <xi:include href="version-info.xml" xpointer="v239"/>
+
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>read-only</command> <replaceable>IMAGE</replaceable> [<replaceable>BOOL</replaceable>]</term>
+
+        <listitem><para>Marks or (unmarks) a portable service image read-only. Takes an image name, followed by a
+        boolean as arguments. If the boolean is omitted, positive is implied, i.e. the image is marked
+        read-only.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>remove</command> <replaceable>IMAGE</replaceable>…</term>
+
+        <listitem><para>Removes one or more portable service images. Note that this command will only remove the
+        specified image path itself — it refers to a symbolic link then the symbolic link is removed and not the
+        image it points to.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>set-limit</command> [<replaceable>IMAGE</replaceable>] <replaceable>BYTES</replaceable></term>
+
+        <listitem><para>Sets the maximum size in bytes that a specific portable service image, or all images, may grow
+        up to on disk (disk quota). Takes either one or two parameters. The first, optional parameter refers to a
+        portable service image name. If specified, the size limit of the specified image is changed. If omitted, the
+        overall size limit of the sum of all images stored locally is changed. The final argument specifies the size
+        limit in bytes, possibly suffixed by the usual K, M, G, T units. If the size limit shall be disabled, specify
+        <literal>-</literal> as size.</para>
+
+        <para>Note that per-image size limits are only supported on btrfs file systems. Also, depending on
+        <varname>BindPaths=</varname> settings in the portable service's unit files directories from the host might be
+        visible in the image environment during runtime which are not affected by this setting, as only the image
+        itself is counted against this limit.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+    </variablelist>
+
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>The following options are understood:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><option>-q</option></term>
+        <term><option>--quiet</option></term>
+
+        <listitem><para>Suppresses additional informational output while running.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-p</option> <replaceable>PROFILE</replaceable></term>
+        <term><option>--profile=</option><replaceable>PROFILE</replaceable></term>
+
+        <listitem><para>When attaching an image, select the profile to use. By default the <literal>default</literal>
+        profile is used. For details about profiles, see below.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--copy=</option></term>
+
+        <listitem><para>When attaching an image, select whether to prefer copying or symlinking of files installed into
+        the host system. Takes one of <literal>copy</literal> (to prefer copying of files), <literal>symlink</literal>
+        (to prefer creation of symbolic links) or <literal>auto</literal> for an intermediary mode where security
+        profile drop-ins are symlinked while unit files are copied. Note that this option expresses a preference only,
+        in cases where symbolic links cannot be created — for example when the image operated on is a raw disk image,
+        and hence not directly referentiable from the host file system — copying of files is used
+        unconditionally.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--runtime</option></term>
+
+        <listitem><para>When specified the unit and drop-in files are placed in
+        <filename>/run/systemd/system.attached/</filename> instead of
+        <filename>/etc/systemd/system.attached/</filename>. Images attached with this option set hence remain attached
+        only until the next reboot, while they are normally attached persistently.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--no-reload</option></term>
+
+        <listitem><para>Don't reload the service manager after attaching or detaching a portable service
+        image. Normally the service manager is reloaded to ensure it is aware of added or removed unit
+        files.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--cat</option></term>
+
+        <listitem><para>When inspecting portable service images, show the (unprocessed) contents of the metadata files
+        pulled from the image, instead of brief summaries. Specifically, this will show the
+        <citerefentry><refentrytitle>os-release</refentrytitle><manvolnum>5</manvolnum></citerefentry> and unit file
+        contents of the image.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--enable</option></term>
+
+        <listitem><para>Immediately enable/disable the portable service after attaching/detaching.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--now</option></term>
+
+        <listitem><para>Immediately start/stop/restart the portable service after attaching/before
+        detaching/after upgrading.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--no-block</option></term>
+
+        <listitem><para>Don't block waiting for attach --now to complete.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--extension=</option><replaceable>PATH</replaceable></term>
+
+        <listitem><para>Add an additional image <replaceable>PATH</replaceable> as an overlay on
+        top of <replaceable>IMAGE</replaceable> when attaching/detaching. This argument can be specified
+        multiple times, in which case the order in which images are laid down follows the rules specified in
+        <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for the <varname>ExtensionImages=</varname> directive and for the
+        <citerefentry><refentrytitle>systemd-sysext</refentrytitle><manvolnum>8</manvolnum></citerefentry> and.
+        <citerefentry><refentrytitle>systemd-confext</refentrytitle><manvolnum>8</manvolnum></citerefentry> tools.
+        The images must contain an <filename>extension-release</filename> file with metadata that matches
+        what is defined in the <filename>os-release</filename> of <replaceable>IMAGE</replaceable>. See:
+        <citerefentry><refentrytitle>os-release</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+        Images can be block images, btrfs subvolumes or directories. For more information on portable
+        services with extensions, see the <literal>Extension Images</literal> paragraph on
+        <ulink url="https://systemd.io/PORTABLE_SERVICES">Portable Services Documentation</ulink>.
+        </para>
+
+        <para>Note that the same extensions have to be specified, in the same order, when attaching
+        and detaching.</para>
+
+        <xi:include href="version-info.xml" xpointer="v249"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--force</option></term>
+
+        <listitem><para>Skip safety checks and attach or detach images (with extensions) without first ensuring
+        that the units are not running, and do not insist that the
+        <filename>extension-release.<replaceable>NAME</replaceable></filename> file in the extension image has
+        to match the image filename.</para>
+
+        <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+      </varlistentry>
+
+      <xi:include href="user-system-options.xml" xpointer="host" />
+      <xi:include href="user-system-options.xml" xpointer="machine" />
+
+      <xi:include href="standard-options.xml" xpointer="no-pager" />
+      <xi:include href="standard-options.xml" xpointer="no-legend" />
+      <xi:include href="standard-options.xml" xpointer="no-ask-password" />
+      <xi:include href="standard-options.xml" xpointer="help" />
+      <xi:include href="standard-options.xml" xpointer="version" />
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Files and Directories</title>
+
+    <para>Portable service images are preferably stored in <filename>/var/lib/portables/</filename>, but are also
+    searched for in <filename>/etc/portables/</filename>, <filename>/run/systemd/portables/</filename>,
+    <filename>/usr/local/lib/portables/</filename> and <filename>/usr/lib/portables/</filename>. It's recommended not
+    to place image files directly in <filename>/etc/portables/</filename> or
+    <filename>/run/systemd/portables/</filename> (as these are generally not suitable for storing large or non-textual
+    data), but use these directories only for linking images located elsewhere into the image search path.</para>
+
+    <para>When a portable service image is attached, matching unit files are copied onto the host into the
+    <filename>/etc/systemd/system.attached/</filename> and <filename>/run/systemd/system.attached/</filename>
+    directories. When an image is detached, the unit files are removed again from these directories.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Profiles</title>
+
+    <para>When portable service images are attached a "profile" drop-in is linked in, which may be used to enforce
+    additional security (and other) restrictions locally. Four profile drop-ins are defined by default, and shipped in
+    <filename>/usr/lib/systemd/portable/profile/</filename>. Additional, local profiles may be defined by placing them
+    in <filename>/etc/systemd/portable/profile/</filename>. The default profiles are:</para>
+
+    <table>
+      <title>Profiles</title>
+      <tgroup cols='2'>
+        <colspec colname='state'/>
+        <colspec colname='description'/>
+        <thead>
+          <row>
+            <entry>Name</entry>
+            <entry>Description</entry>
+          </row>
+        </thead>
+        <tbody>
+          <row>
+            <entry><filename>default</filename></entry>
+            <entry>This is the default profile if no other profile name is set via the <option>--profile=</option> (see above). It's fairly restrictive, but should be useful for common, unprivileged system workloads. This includes write access to the logging framework, as well as IPC access to the D-Bus system.</entry>
+          </row>
+          <row>
+            <entry><filename>nonetwork</filename></entry>
+            <entry>Very similar to <filename>default</filename>, but networking is turned off for any services of the portable service image.</entry>
+          </row>
+          <row>
+            <entry><filename>strict</filename></entry>
+            <entry>A profile with very strict settings. This profile excludes IPC (D-Bus) and network access.</entry>
+          </row>
+          <row>
+            <entry><filename>trusted</filename></entry>
+            <entry>A profile with very relaxed settings. In this profile the services run with full privileges.</entry>
+          </row>
+        </tbody>
+      </tgroup>
+    </table>
+
+    <para>For details on these profiles and their effects see their precise definitions,
+    e.g. <filename>/usr/lib/systemd/portable/profile/default/service.conf</filename> and similar.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Exit status</title>
+
+    <para>On success, 0 is returned, a non-zero failure code otherwise.</para>
+  </refsect1>
+
+  <xi:include href="common-variables.xml" />
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-sysext</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>org.freedesktop.portable1</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-portabled.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/poweroff.xml b/man/poweroff.xml
new file mode 100644
index 0000000..4abfa18
--- /dev/null
+++ b/man/poweroff.xml
@@ -0,0 +1,176 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="poweroff"
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>poweroff</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>poweroff</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>poweroff</refname>
+    <refname>reboot</refname>
+    <refname>halt</refname>
+    <refpurpose>Power off, reboot, or halt the machine</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <cmdsynopsis>
+      <command>poweroff</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+    </cmdsynopsis>
+    <cmdsynopsis>
+      <command>reboot</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+    </cmdsynopsis>
+    <cmdsynopsis>
+      <command>halt</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+    </cmdsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>poweroff</command>, <command>reboot</command>, and <command>halt</command> may be used to
+    power off, reboot, or halt the machine. All three commands take the same options.</para>
+
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>The following options are understood:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><option>--help</option></term>
+
+        <xi:include href="standard-options.xml" xpointer="help-text" />
+
+        <xi:include href="version-info.xml" xpointer="v253"/>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--halt</option></term>
+
+        <listitem><para>Halt the machine, regardless of which one of
+        the three commands is invoked.</para>
+
+        <xi:include href="version-info.xml" xpointer="v253"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-p</option></term>
+        <term><option>--poweroff</option></term>
+
+        <listitem><para>Power off the machine, when either <command>halt</command>
+        or <command>poweroff</command> is invoked. This option is ignored when
+        <command>reboot</command> is invoked.</para>
+
+        <xi:include href="version-info.xml" xpointer="v253"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--reboot</option></term>
+
+        <listitem><para>Reboot the machine, regardless of which one of
+        the three commands is invoked.</para>
+
+        <xi:include href="version-info.xml" xpointer="v253"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-f</option></term>
+        <term><option>--force</option></term>
+
+        <listitem>
+          <para>Force immediate power-off, halt, or reboot. If specified, the command does not contact the
+          init system. In most cases, filesystems are not properly unmounted before shutdown. For example,
+          the command <command>reboot -f</command> is mostly equivalent to
+          <command>systemctl reboot -ff</command>, instead of <command>systemctl reboot -f</command>.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v253"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-w</option></term>
+        <term><option>--wtmp-only</option></term>
+
+        <listitem><para>Only write wtmp shutdown entry, do not actually power off, reboot, or halt.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v253"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-d</option></term>
+        <term><option>--no-wtmp</option></term>
+
+        <listitem><para>Do not write wtmp shutdown entry.</para>
+
+        <xi:include href="version-info.xml" xpointer="v253"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-n</option></term>
+        <term><option>--no-sync</option></term>
+
+        <listitem><para>Don't sync hard disks/storage media before power-off, reboot, or halt.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v253"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--no-wall</option></term>
+
+        <listitem><para>Do not send wall message before power-off, reboot, or halt.</para>
+
+        <xi:include href="version-info.xml" xpointer="v253"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Exit status</title>
+
+    <para>On success, 0 is returned, a non-zero failure code otherwise.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Notes</title>
+
+    <para>These commands are implemented in a way that preserves basic compatibility with the original SysV
+    commands. <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    verbs <command>poweroff</command>, <command>reboot</command>, <command>halt</command> provide the same
+    functionality with some additional features.</para>
+
+    <para>Note that on many SysV systems <command>halt</command> used to be synonymous to
+    <command>poweroff</command>, i.e. both commands would equally result in powering the machine off. systemd
+    is more accurate here, and <command>halt</command> results in halting the machine only (leaving power
+    on), and <command>poweroff</command> is required to actually power it off.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>shutdown</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>wall</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/print-unit-path-call-method.c b/man/print-unit-path-call-method.c
new file mode 100644
index 0000000..f73dd07
--- /dev/null
+++ b/man/print-unit-path-call-method.c
@@ -0,0 +1,51 @@
+/* SPDX-License-Identifier: MIT-0 */
+
+/* This is equivalent to:
+ * busctl call org.freedesktop.systemd1 /org/freedesktop/systemd1 \
+ *       org.freedesktop.systemd1.Manager GetUnitByPID $$
+ *
+ * Compile with 'cc print-unit-path-call-method.c -lsystemd'
+ */
+
+#include <errno.h>
+#include <stdio.h>
+#include <sys/types.h>
+#include <unistd.h>
+
+#include <systemd/sd-bus.h>
+
+#define _cleanup_(f) __attribute__((cleanup(f)))
+#define DESTINATION "org.freedesktop.systemd1"
+#define PATH        "/org/freedesktop/systemd1"
+#define INTERFACE   "org.freedesktop.systemd1.Manager"
+#define MEMBER      "GetUnitByPID"
+
+static int log_error(int error, const char *message) {
+  errno = -error;
+  fprintf(stderr, "%s: %m\n", message);
+  return error;
+}
+
+int main(int argc, char **argv) {
+  _cleanup_(sd_bus_flush_close_unrefp) sd_bus *bus = NULL;
+  _cleanup_(sd_bus_error_free) sd_bus_error error = SD_BUS_ERROR_NULL;
+  _cleanup_(sd_bus_message_unrefp) sd_bus_message *reply = NULL;
+  int r;
+
+  r = sd_bus_open_system(&bus);
+  if (r < 0)
+    return log_error(r, "Failed to acquire bus");
+
+  r = sd_bus_call_method(bus, DESTINATION, PATH, INTERFACE, MEMBER, &error, &reply, "u", (unsigned) getpid());
+  if (r < 0)
+    return log_error(r, MEMBER " call failed");
+
+  const char *ans;
+  r = sd_bus_message_read(reply, "o", &ans);
+  if (r < 0)
+    return log_error(r, "Failed to read reply");
+
+  printf("Unit path is \"%s\".\n", ans);
+
+  return 0;
+}
diff --git a/man/print-unit-path.c b/man/print-unit-path.c
new file mode 100644
index 0000000..0b89318
--- /dev/null
+++ b/man/print-unit-path.c
@@ -0,0 +1,60 @@
+/* SPDX-License-Identifier: MIT-0 */
+
+/* This is equivalent to:
+ * busctl call org.freedesktop.systemd1 /org/freedesktop/systemd1 \
+ *       org.freedesktop.systemd1.Manager GetUnitByPID $$
+ *
+ * Compile with 'cc print-unit-path.c -lsystemd'
+ */
+
+#include <errno.h>
+#include <stdio.h>
+#include <sys/types.h>
+#include <unistd.h>
+
+#include <systemd/sd-bus.h>
+
+#define _cleanup_(f) __attribute__((cleanup(f)))
+#define DESTINATION "org.freedesktop.systemd1"
+#define PATH        "/org/freedesktop/systemd1"
+#define INTERFACE   "org.freedesktop.systemd1.Manager"
+#define MEMBER      "GetUnitByPID"
+
+static int log_error(int error, const char *message) {
+  errno = -error;
+  fprintf(stderr, "%s: %m\n", message);
+  return error;
+}
+
+int main(int argc, char **argv) {
+  _cleanup_(sd_bus_flush_close_unrefp) sd_bus *bus = NULL;
+  _cleanup_(sd_bus_error_free) sd_bus_error error = SD_BUS_ERROR_NULL;
+  _cleanup_(sd_bus_message_unrefp) sd_bus_message *reply = NULL, *m = NULL;
+  int r;
+
+  r = sd_bus_open_system(&bus);
+  if (r < 0)
+    return log_error(r, "Failed to acquire bus");
+
+  r = sd_bus_message_new_method_call(bus, &m,
+                                     DESTINATION, PATH, INTERFACE, MEMBER);
+  if (r < 0)
+    return log_error(r, "Failed to create bus message");
+
+  r = sd_bus_message_append(m, "u", (unsigned) getpid());
+  if (r < 0)
+    return log_error(r, "Failed to append to bus message");
+
+  r = sd_bus_call(bus, m, -1, &error, &reply);
+  if (r < 0)
+    return log_error(r, MEMBER " call failed");
+
+  const char *ans;
+  r = sd_bus_message_read(reply, "o", &ans);
+  if (r < 0)
+    return log_error(r, "Failed to read reply");
+
+  printf("Unit path is \"%s\".\n", ans);
+
+  return 0;
+}
diff --git a/man/pstore.conf.xml b/man/pstore.conf.xml
new file mode 100644
index 0000000..f54cef9
--- /dev/null
+++ b/man/pstore.conf.xml
@@ -0,0 +1,93 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="pstore.conf" conditional="ENABLE_PSTORE"
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+  <refentryinfo>
+    <title>pstore.conf</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>pstore.conf</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>pstore.conf</refname>
+    <refname>pstore.conf.d</refname>
+    <refpurpose>PStore configuration file</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para>
+    <filename>/etc/systemd/pstore.conf</filename>
+    <filename>/etc/systemd/pstore.conf.d/*</filename>
+    </para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>This file configures the behavior of
+    <citerefentry><refentrytitle>systemd-pstore</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+    a tool for archiving the contents of the persistent storage filesystem,
+    <ulink url="https://docs.kernel.org/admin-guide/abi-testing.html#abi-sys-fs-pstore">pstore</ulink>.
+    </para>
+  </refsect1>
+
+  <xi:include href="standard-conf.xml" xpointer="main-conf" />
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>All options are configured in the
+    [PStore] section:</para>
+
+    <variablelist class='config-directives'>
+
+      <varlistentry>
+        <term><varname>Storage=</varname></term>
+
+        <listitem><para>Controls where to archive (i.e. copy) files from the pstore filesystem. One of <literal>none</literal>,
+        <literal>external</literal>, and <literal>journal</literal>. When
+        <literal>none</literal>, the tool exits without processing files in the pstore filesystem.
+        When <literal>external</literal> (the default), files are archived into <filename>/var/lib/systemd/pstore/</filename>,
+        and logged into the journal.
+        When <literal>journal</literal>, pstore file contents are logged only in the journal.</para>
+
+        <xi:include href="version-info.xml" xpointer="v243"/>
+        </listitem>
+
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Unlink=</varname></term>
+
+        <listitem><para>Controls whether or not files are removed from pstore after processing.
+        Takes a boolean value. When true, a pstore file is removed from the pstore once it has been
+        archived (either to disk or into the journal). When false, processing of pstore files occurs
+        normally, but the files remain in the pstore.
+        The default is true in order to maintain the pstore in a nearly empty state, so that the pstore
+        has storage available for the next kernel error event.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v243"/></listitem>
+      </varlistentry>
+    </variablelist>
+
+    <para>The defaults for all values are listed as comments in the
+    template <filename>/etc/systemd/pstore.conf</filename> file that
+    is installed by default.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/repart.d.xml b/man/repart.d.xml
new file mode 100644
index 0000000..79908a0
--- /dev/null
+++ b/man/repart.d.xml
@@ -0,0 +1,936 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="repart.d" conditional='ENABLE_REPART'
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>repart.d</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>repart.d</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>repart.d</refname>
+    <refpurpose>Partition Definition Files for Automatic Boot-Time Repartitioning</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><literallayout><filename>/etc/repart.d/*.conf</filename>
+<filename>/run/repart.d/*.conf</filename>
+<filename>/usr/lib/repart.d/*.conf</filename>
+    </literallayout></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><filename>repart.d/*.conf</filename> files describe basic properties of partitions of block
+    devices of the local system. They may be used to declare types, names and sizes of partitions that shall
+    exist. The
+    <citerefentry><refentrytitle>systemd-repart</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    service reads these files and attempts to add new partitions currently missing and enlarge existing
+    partitions according to these definitions. Operation is generally incremental, i.e. when applied, what
+    exists already is left intact, and partitions are never shrunk, moved or deleted.</para>
+
+    <para>These definition files are useful for implementing operating system images that are prepared and
+    delivered with minimally sized images (for example lacking any state or swap partitions), and which on
+    first boot automatically take possession of any remaining disk space following a few basic rules.</para>
+
+    <para>Currently, support for partition definition files is only implemented for GPT partition
+    tables.</para>
+
+    <para>Partition files are generally matched against any partitions already existing on disk in a simple
+    algorithm: the partition files are sorted by their filename (ignoring the directory prefix), and then
+    compared in order against existing partitions matching the same partition type UUID. Specifically, the
+    first existing partition with a specific partition type UUID is assigned the first definition file with
+    the same partition type UUID, and the second existing partition with a specific type UUID the second
+    partition file with the same type UUID, and so on. Any left-over partition files that have no matching
+    existing partition are assumed to define new partition that shall be created. Such partitions are
+    appended to the end of the partition table, in the order defined by their names utilizing the first
+    partition slot greater than the highest slot number currently in use. Any existing partitions that have
+    no matching partition file are left as they are.</para>
+
+    <para>Note that these definitions may only be used to create and initialize new partitions or to grow
+    existing ones. In the latter case it will not grow the contained files systems however; separate
+    mechanisms, such as
+    <citerefentry><refentrytitle>systemd-growfs</refentrytitle><manvolnum>8</manvolnum></citerefentry> may be
+    used to grow the file systems inside of these partitions. Partitions may also be marked for automatic
+    growing via the <varname>GrowFileSystem=</varname> setting, in which case the file system is grown on
+    first mount by tools that respect this flag. See below for details.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>[Partition] Section Options</title>
+
+    <variablelist>
+      <varlistentry>
+        <term><varname>Type=</varname></term>
+
+        <listitem><para>The GPT partition type UUID to match. This may be a GPT partition type UUID such as
+        <constant>4f68bce3-e8cd-4db1-96e7-fbcaf984b709</constant>, or an identifier.
+        Architecture specific partition types can use one of these architecture identifiers:
+        <constant>alpha</constant>, <constant>arc</constant>, <constant>arm</constant> (32-bit),
+        <constant>arm64</constant> (64-bit, aka aarch64), <constant>ia64</constant>,
+        <constant>loongarch64</constant>, <constant>mips-le</constant>, <constant>mips64-le</constant>,
+        <constant>parisc</constant>, <constant>ppc</constant>, <constant>ppc64</constant>,
+        <constant>ppc64-le</constant>, <constant>riscv32</constant>, <constant>riscv64</constant>,
+        <constant>s390</constant>, <constant>s390x</constant>, <constant>tilegx</constant>,
+        <constant>x86</constant> (32-bit, aka i386) and <constant>x86-64</constant> (64-bit, aka amd64).
+        </para>
+
+        <para>The supported identifiers are:</para>
+
+        <table>
+          <title>GPT partition type identifiers</title>
+
+          <tgroup cols='2' align='left' colsep='1' rowsep='1'>
+            <colspec colname="name" />
+            <colspec colname="explanation" />
+
+            <thead>
+              <row>
+                <entry>Identifier</entry>
+                <entry>Explanation</entry>
+              </row>
+            </thead>
+
+            <tbody>
+              <row>
+                <entry><constant>esp</constant></entry>
+                <entry>EFI System Partition</entry>
+              </row>
+
+              <row>
+                <entry><constant>xbootldr</constant></entry>
+                <entry>Extended Boot Loader Partition</entry>
+              </row>
+
+              <row>
+                <entry><constant>swap</constant></entry>
+                <entry>Swap partition</entry>
+              </row>
+
+              <row>
+                <entry><constant>home</constant></entry>
+                <entry>Home (<filename>/home/</filename>) partition</entry>
+              </row>
+
+              <row>
+                <entry><constant>srv</constant></entry>
+                <entry>Server data (<filename>/srv/</filename>) partition</entry>
+              </row>
+
+              <row>
+                <entry><constant>var</constant></entry>
+                <entry>Variable data (<filename>/var/</filename>) partition</entry>
+              </row>
+
+              <row>
+                <entry><constant>tmp</constant></entry>
+                <entry>Temporary data (<filename>/var/tmp/</filename>) partition</entry>
+              </row>
+
+              <row>
+                <entry><constant>linux-generic</constant></entry>
+                <entry>Generic Linux file system partition</entry>
+              </row>
+
+              <row>
+                <entry><constant>root</constant></entry>
+                <entry>Root file system partition type appropriate for the local architecture (an alias for an architecture root file system partition type listed below, e.g. <constant>root-x86-64</constant>)</entry>
+              </row>
+
+              <row>
+                <entry><constant>root-verity</constant></entry>
+                <entry>Verity data for the root file system partition for the local architecture</entry>
+              </row>
+
+              <row>
+                <entry><constant>root-verity-sig</constant></entry>
+                <entry>Verity signature data for the root file system partition for the local architecture</entry>
+              </row>
+
+              <row>
+                <entry><constant>root-secondary</constant></entry>
+                <entry>Root file system partition of the secondary architecture of the local architecture (usually the matching 32-bit architecture for the local 64-bit architecture)</entry>
+              </row>
+
+              <row>
+                <entry><constant>root-secondary-verity</constant></entry>
+                <entry>Verity data for the root file system partition of the secondary architecture</entry>
+              </row>
+
+              <row>
+                <entry><constant>root-secondary-verity-sig</constant></entry>
+                <entry>Verity signature data for the root file system partition of the secondary architecture</entry>
+              </row>
+
+              <row>
+                <entry><constant>root-{arch}</constant></entry>
+                <entry>Root file system partition of the given architecture (such as <constant>root-x86-64</constant> or <constant>root-riscv64</constant>)</entry>
+              </row>
+
+              <row>
+                <entry><constant>root-{arch}-verity</constant></entry>
+                <entry>Verity data for the root file system partition of the given architecture</entry>
+              </row>
+
+              <row>
+                <entry><constant>root-{arch}-verity-sig</constant></entry>
+                <entry>Verity signature data for the root file system partition of the given architecture</entry>
+              </row>
+
+              <row>
+                <entry><constant>usr</constant></entry>
+                <entry><filename>/usr/</filename> file system partition type appropriate for the local architecture (an alias for an architecture <filename>/usr/</filename> file system partition type listed below, e.g. <constant>usr-x86-64</constant>)</entry>
+              </row>
+
+              <row>
+                <entry><constant>usr-verity</constant></entry>
+                <entry>Verity data for the <filename>/usr/</filename> file system partition for the local architecture</entry>
+              </row>
+
+              <row>
+                <entry><constant>usr-verity-sig</constant></entry>
+                <entry>Verity signature data for the <filename>/usr/</filename> file system partition for the local architecture</entry>
+              </row>
+
+              <row>
+                <entry><constant>usr-secondary</constant></entry>
+                <entry><filename>/usr/</filename> file system partition of the secondary architecture of the local architecture (usually the matching 32-bit architecture for the local 64-bit architecture)</entry>
+              </row>
+
+              <row>
+                <entry><constant>usr-secondary-verity</constant></entry>
+                <entry>Verity data for the <filename>/usr/</filename> file system partition of the secondary architecture</entry>
+              </row>
+
+              <row>
+                <entry><constant>usr-secondary-verity-sig</constant></entry>
+                <entry>Verity signature data for the <filename>/usr/</filename> file system partition of the secondary architecture</entry>
+              </row>
+
+              <row>
+                <entry><constant>usr-{arch}</constant></entry>
+                <entry><filename>/usr/</filename> file system partition of the given architecture</entry>
+              </row>
+
+              <row>
+                <entry><constant>usr-{arch}-verity</constant></entry>
+                <entry>Verity data for the <filename>/usr/</filename> file system partition of the given architecture</entry>
+              </row>
+
+              <row>
+                <entry><constant>usr-{arch}-verity-sig</constant></entry>
+                <entry>Verity signature data for the <filename>/usr/</filename> file system partition of the given architecture</entry>
+              </row>
+            </tbody>
+          </tgroup>
+        </table>
+
+        <para>This setting defaults to <constant>linux-generic</constant>.</para>
+
+        <para>Most of the partition type UUIDs listed above are defined in the <ulink
+        url="https://uapi-group.org/specifications/specs/discoverable_partitions_specification">Discoverable Partitions
+        Specification</ulink>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Label=</varname></term>
+
+        <listitem><para>The textual label to assign to the partition if none is assigned yet. Note that this
+        setting is not used for matching. It is also not used when a label is already set for an existing
+        partition. It is thus only used when a partition is newly created or when an existing one had a no
+        label set (that is: an empty label). If not specified a label derived from the partition type is
+        automatically used. Simple specifier expansion is supported, see below.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>UUID=</varname></term>
+
+        <listitem><para>The UUID to assign to the partition if none is assigned yet. Note that this
+        setting is not used for matching. It is also not used when a UUID is already set for an existing
+        partition. It is thus only used when a partition is newly created or when an existing one had a
+        all-zero UUID set. If set to <literal>null</literal>, the UUID is set to all zeroes. If not specified
+        a UUID derived from the partition type is automatically used.</para>
+
+        <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Priority=</varname></term>
+
+        <listitem><para>A numeric priority to assign to this partition, in the range -2147483648…2147483647,
+        with smaller values indicating higher priority, and higher values indicating smaller priority. This
+        priority is used in case the configured size constraints on the defined partitions do not permit
+        fitting all partitions onto the available disk space. If the partitions do not fit, the highest
+        numeric partition priority of all defined partitions is determined, and all defined partitions with
+        this priority are removed from the list of new partitions to create (which may be multiple, if the
+        same priority is used for multiple partitions). The fitting algorithm is then tried again. If the
+        partitions still do not fit, the now highest numeric partition priority is determined, and the
+        matching partitions removed too, and so on. Partitions of a priority of 0 or lower are never
+        removed. If all partitions with a priority above 0 are removed and the partitions still do not fit on
+        the device the operation fails. Note that this priority has no effect on ordering partitions, for
+        that use the alphabetical order of the filenames of the partition definition files. Defaults to
+        0.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Weight=</varname></term>
+
+        <listitem><para>A numeric weight to assign to this partition in the range 0…1000000. Available disk
+        space is assigned the defined partitions according to their relative weights (subject to the size
+        constraints configured with <varname>SizeMinBytes=</varname>, <varname>SizeMaxBytes=</varname>), so
+        that a partition with weight 2000 gets double the space as one with weight 1000, and a partition with
+        weight 333 a third of that. Defaults to 1000.</para>
+
+        <para>The <varname>Weight=</varname> setting is used to distribute available disk space in an
+        "elastic" fashion, based on the disk size and existing partitions. If a partition shall have a fixed
+        size use both <varname>SizeMinBytes=</varname> and <varname>SizeMaxBytes=</varname> with the same
+        value in order to fixate the size to one value, in which case the weight has no
+        effect.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>PaddingWeight=</varname></term>
+
+        <listitem><para>Similar to <varname>Weight=</varname>, but sets a weight for the free space after the
+        partition (the "padding"). When distributing available space the weights of all partitions and all
+        defined padding is summed, and then each partition and padding gets the fraction defined by its
+        weight. Defaults to 0, i.e. by default no padding is applied.</para>
+
+        <para>Padding is useful if empty space shall be left for later additions or a safety margin at the
+        end of the device or between partitions.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SizeMinBytes=</varname></term>
+        <term><varname>SizeMaxBytes=</varname></term>
+
+        <listitem><para>Specifies minimum and maximum size constraints in bytes. Takes the usual K, M, G, T,
+        …  suffixes (to the base of 1024). If <varname>SizeMinBytes=</varname> is specified the partition is
+        created at or grown to at least the specified size. If <varname>SizeMaxBytes=</varname> is specified
+        the partition is created at or grown to at most the specified size. The precise size is determined
+        through the weight value configured with <varname>Weight=</varname>, see above. When
+        <varname>SizeMinBytes=</varname> is set equal to <varname>SizeMaxBytes=</varname> the configured
+        weight has no effect as the partition is explicitly sized to the specified fixed value. Note that
+        partitions are never created smaller than 4096 bytes, and since partitions are never shrunk the
+        previous size of the partition (in case the partition already exists) is also enforced as lower bound
+        for the new size. The values should be specified as multiples of 4096 bytes, and are rounded upwards
+        (in case of <varname>SizeMinBytes=</varname>) or downwards (in case of
+        <varname>SizeMaxBytes=</varname>) otherwise. If the backing device does not provide enough space to
+        fulfill the constraints placing the partition will fail. For partitions that shall be created,
+        depending on the setting of <varname>Priority=</varname> (see above) the partition might be dropped
+        and the placing algorithm restarted. By default a minimum size constraint of 10M and no maximum size
+        constraint is set.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>PaddingMinBytes=</varname></term>
+        <term><varname>PaddingMaxBytes=</varname></term>
+
+        <listitem><para>Specifies minimum and maximum size constraints in bytes for the free space after the
+        partition (the "padding"). Semantics are similar to <varname>SizeMinBytes=</varname> and
+        <varname>SizeMaxBytes=</varname>, except that unlike partition sizes free space can be shrunk and can
+        be as small as zero. By default no size constraints on padding are set, so that only
+        <varname>PaddingWeight=</varname> determines the size of the padding applied.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>CopyBlocks=</varname></term>
+
+        <listitem><para>Takes a path to a regular file, block device node or directory, or the special value
+        <literal>auto</literal>. If specified and the partition is newly created, the data from the specified
+        path is written to the newly created partition, on the block level. If a directory is specified, the
+        backing block device of the file system the directory is on is determined, and the data read directly
+        from that. This option is useful to efficiently replicate existing file systems onto new partitions
+        on the block level — for example to build a simple OS installer or an OS image builder.</para>
+
+        <para>If the special value <literal>auto</literal> is specified, the source to copy from is
+        automatically picked up from the running system (or the image specified with
+        <option>--image=</option> — if used). A partition that matches both the configured partition type (as
+        declared with <varname>Type=</varname> described above), and the currently mounted directory
+        appropriate for that partition type is determined. For example, if the partition type is set to
+        <literal>root</literal> the partition backing the root directory (<filename>/</filename>) is used as
+        source to copy from — if its partition type is set to <literal>root</literal> as well. If the
+        declared type is <literal>usr</literal> the partition backing <filename>/usr/</filename> is used as
+        source to copy blocks from — if its partition type is set to <literal>usr</literal> too. The logic is
+        capable of automatically tracking down the backing partitions for encrypted and Verity-enabled
+        volumes. <literal>CopyBlocks=auto</literal> is useful for implementing "self-replicating" systems,
+        i.e. systems that are their own installer.</para>
+
+        <para>The file specified here must have a size that is a multiple of the basic block size 512 and not
+        be empty. If this option is used, the size allocation algorithm is slightly altered: the partition is
+        created as least as big as required to fit the data in, i.e. the data size is an additional minimum
+        size value taken into consideration for the allocation algorithm, similar to and in addition to the
+        <varname>SizeMin=</varname> value configured above.</para>
+
+        <para>This option has no effect if the partition it is declared for already exists, i.e. existing
+        data is never overwritten. Note that the data is copied in before the partition table is updated,
+        i.e. before the partition actually is persistently created. This provides robustness: it is
+        guaranteed that the partition either doesn't exist or exists fully populated; it is not possible that
+        the partition exists but is not or only partially populated.</para>
+
+        <para>This option cannot be combined with <varname>Format=</varname> or
+        <varname>CopyFiles=</varname>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Format=</varname></term>
+
+        <listitem><para>Takes a file system name, such as <literal>ext4</literal>, <literal>btrfs</literal>,
+        <literal>xfs</literal>, <literal>vfat</literal>, <literal>erofs</literal>,
+        <literal>squashfs</literal> or the special value <literal>swap</literal>. If specified and the partition
+        is newly created it is formatted with the specified file system (or as swap device). The file system
+        UUID and label are automatically derived from the partition UUID and label. If this option is used,
+        the size allocation algorithm is slightly altered: the partition is created as least as big as
+        required for the minimal file system of the specified type (or 4KiB if the minimal size is not
+        known).</para>
+
+        <para>This option has no effect if the partition already exists.</para>
+
+        <para>Similarly to the behaviour of <varname>CopyBlocks=</varname>, the file system is formatted
+        before the partition is created, ensuring that the partition only ever exists with a fully
+        initialized file system.</para>
+
+        <para>This option cannot be combined with <varname>CopyBlocks=</varname>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v247"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>CopyFiles=</varname></term>
+
+        <listitem><para>Takes a pair of colon separated absolute file system paths. The first path refers to
+        a source file or directory on the host, the second path refers to a target in the file system of the
+        newly created partition and formatted file system. This setting may be used to copy files or
+        directories from the host into the file system that is created due to the <varname>Format=</varname>
+        option. If <varname>CopyFiles=</varname> is used without <varname>Format=</varname> specified
+        explicitly, <literal>Format=</literal> with a suitable default is implied (currently
+        <literal>vfat</literal> for <literal>ESP</literal> and <literal>XBOOTLDR</literal> partitions, and
+        <literal>ext4</literal> otherwise, but this may change in the future). This option may be used
+        multiple times to copy multiple files or directories from host into the newly formatted file system.
+        The colon and second path may be omitted in which case the source path is also used as the target
+        path (relative to the root of the newly created file system). If the source path refers to a
+        directory it is copied recursively.</para>
+
+        <para>This option has no effect if the partition already exists: it cannot be used to copy additional
+        files into an existing partition, it may only be used to populate a file system created anew.</para>
+
+        <para>The copy operation is executed before the file system is registered in the partition table,
+        thus ensuring that a file system populated this way only ever exists fully initialized.</para>
+
+        <para>Note that <varname>CopyFiles=</varname> will skip copying files that aren't supported by the
+        target filesystem (e.g symlinks, fifos, sockets and devices on vfat). When an unsupported file type
+        is encountered, <command>systemd-repart</command> will skip copying this file and write a log message
+        about it.</para>
+
+        <para>Note that <command>systemd-repart</command> does not change the UIDs/GIDs of any copied files
+        and directories. When running <command>systemd-repart</command> as an unprivileged user to build an
+        image of files and directories owned by the same user, you can run <command>systemd-repart</command>
+        in a user namespace with the current user mapped to the root user to make sure the files and
+        directories in the image are owned by the root user.</para>
+
+        <para>Note that when populating XFS filesystems with <command>systemd-repart</command> and loop
+        devices are not available, populating XFS filesystems with files containing spaces, tabs or newlines
+        might fail on old versions of
+        <citerefentry project='man-pages'><refentrytitle>mkfs.xfs</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        due to limitations of its protofile format.</para>
+
+        <para>Note that when populating XFS filesystems with <command>systemd-repart</command> and loop
+        devices are not available, extended attributes will not be copied into generated XFS filesystems
+        due to limitations <citerefentry project='man-pages'><refentrytitle>mkfs.xfs</refentrytitle><manvolnum>8</manvolnum></citerefentry>'s
+        protofile format.</para>
+
+        <para>This option cannot be combined with <varname>CopyBlocks=</varname>.</para>
+
+        <para>When
+        <citerefentry><refentrytitle>systemd-repart</refentrytitle><manvolnum>8</manvolnum></citerefentry> is
+        invoked with the <option>--copy-source=</option> command line switch the file paths are taken
+        relative to the specified directory. If <option>--copy-source=</option> is not used, but the
+        <option>--image=</option> or <option>--root=</option> switches are used, the source paths are taken
+        relative to the specified root directory or disk image root.</para>
+
+        <xi:include href="version-info.xml" xpointer="v247"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ExcludeFiles=</varname></term>
+        <term><varname>ExcludeFilesTarget=</varname></term>
+
+        <listitem><para>Takes an absolute file system path referring to a source file or directory on the
+        host. This setting may be used to exclude files or directories from the host from being copied into
+        the file system when <varname>CopyFiles=</varname> is used. This option may be used multiple times to
+        exclude multiple files or directories from host from being copied into the newly formatted file
+        system.</para>
+
+        <para>If the path is a directory and ends with <literal>/</literal>, only the directory's
+        contents are excluded but not the directory itself. If the path is a directory and does not end with
+        <literal>/</literal>, both the directory and its contents are excluded.</para>
+
+        <para><varname>ExcludeFilesTarget=</varname> is like <varname>ExcludeFiles=</varname> except that
+        instead of excluding the path on the host from being copied into the partition, we exclude any files
+        and directories from being copied into the given path in the partition.</para>
+
+        <para>When
+        <citerefentry><refentrytitle>systemd-repart</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        is invoked with the <option>--image=</option> or <option>--root=</option> command line switches the
+        paths specified are taken relative to the specified root directory or disk image root.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>MakeDirectories=</varname></term>
+
+        <listitem><para>Takes one or more absolute paths, separated by whitespace, each declaring a directory
+        to create within the new file system. Behaviour is similar to <varname>CopyFiles=</varname>, but
+        instead of copying in a set of files this just creates the specified directories with the default
+        mode of 0755 owned by the root user and group, plus all their parent directories (with the same
+        ownership and access mode). To configure directories with different ownership or access mode, use
+        <varname>CopyFiles=</varname> and specify a source tree to copy containing appropriately
+        owned/configured directories. This option may be used more than once to create multiple
+        directories. When <varname>CopyFiles=</varname> and <varname>MakeDirectories=</varname> are used
+        together the former is applied first. If a directory listed already exists no operation is executed
+        (in particular, the ownership/access mode of the directories is left as is).</para>
+
+        <para>The primary use case for this option is to create a minimal set of directories that may be
+        mounted over by other partitions contained in the same disk image. For example, a disk image where
+        the root file system is formatted at first boot might want to automatically pre-create
+        <filename>/usr/</filename> in it this way, so that the <literal>usr</literal> partition may
+        over-mount it.</para>
+
+        <para>Consider using
+        <citerefentry><refentrytitle>systemd-tmpfiles</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        with its <option>--image=</option> option to pre-create other, more complex directory hierarchies (as
+        well as other inodes) with fine-grained control of ownership, access modes and other file
+        attributes.</para>
+
+        <xi:include href="version-info.xml" xpointer="v249"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Subvolumes=</varname></term>
+
+        <listitem><para>Takes one or more absolute paths, separated by whitespace, each declaring a directory
+        that should be a subvolume within the new file system. This option may be used more than once to
+        specify multiple directories. Note that this setting does not create the directories themselves, that
+        can be configured with <varname>MakeDirectories=</varname> and <varname>CopyFiles=</varname>.</para>
+
+        <para>Note that this option only takes effect if the target filesystem supports subvolumes, such as
+        <literal>btrfs</literal>.</para>
+
+        <para>Note that due to limitations of <literal>mkfs.btrfs</literal>, this option is only supported
+        when running with <option>--offline=no</option>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Encrypt=</varname></term>
+
+        <listitem><para>Takes one of <literal>off</literal>, <literal>key-file</literal>,
+        <literal>tpm2</literal> and <literal>key-file+tpm2</literal> (alternatively, also accepts a boolean
+        value, which is mapped to <literal>off</literal> when false, and <literal>key-file</literal> when
+        true). Defaults to <literal>off</literal>. If not <literal>off</literal> the partition will be
+        formatted with a LUKS2 superblock, before the blocks configured with <varname>CopyBlocks=</varname>
+        are copied in or the file system configured with <varname>Format=</varname> is created.</para>
+
+        <para>The LUKS2 UUID is automatically derived from the partition UUID in a stable fashion. If
+        <literal>key-file</literal> or <literal>key-file+tpm2</literal> is used, a key is added to the LUKS2
+        superblock, configurable with the <option>--key-file=</option> option to
+        <command>systemd-repart</command>. If <literal>tpm2</literal> or <literal>key-file+tpm2</literal> is
+        used, a key is added to the LUKS2 superblock that is enrolled to the local TPM2 chip, as configured
+        with the <option>--tpm2-device=</option> and <option>--tpm2-pcrs=</option> options to
+        <command>systemd-repart</command>.</para>
+
+        <para>When used this slightly alters the size allocation logic as the implicit, minimal size limits
+        of <varname>Format=</varname> and <varname>CopyBlocks=</varname> are increased by the space necessary
+        for the LUKS2 superblock (see above).</para>
+
+        <para>This option has no effect if the partition already exists.</para>
+
+        <xi:include href="version-info.xml" xpointer="v247"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Verity=</varname></term>
+
+        <listitem><para>Takes one of <literal>off</literal>, <literal>data</literal>,
+        <literal>hash</literal> or <literal>signature</literal>. Defaults to <literal>off</literal>. If set
+        to <literal>off</literal> or <literal>data</literal>, the partition is populated with content as
+        specified by <varname>CopyBlocks=</varname> or <varname>CopyFiles=</varname>. If set to
+        <literal>hash</literal>, the partition will be populated with verity hashes from the matching verity
+        data partition. If set to <literal>signature</literal>, the partition will be populated with a JSON
+        object containing a signature of the verity root hash of the matching verity hash partition.</para>
+
+        <para>A matching verity partition is a partition with the same verity match key (as configured with
+        <varname>VerityMatchKey=</varname>).</para>
+
+        <para>If not explicitly configured, the data partition's UUID will be set to the first 128
+        bits of the verity root hash. Similarly, if not configured, the hash partition's UUID will be set to
+        the final 128 bits of the verity root hash. The verity root hash itself will be included in the
+        output of <command>systemd-repart</command>.</para>
+
+        <para>This option has no effect if the partition already exists.</para>
+
+        <para>Usage of this option in combination with <varname>Encrypt=</varname> is not supported.</para>
+
+        <para>For each unique <varname>VerityMatchKey=</varname> value, a single verity data partition
+        (<literal>Verity=data</literal>) and a single verity hash partition (<literal>Verity=hash</literal>)
+        must be defined.</para>
+
+        <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>VerityMatchKey=</varname></term>
+
+        <listitem><para>Takes a short, user-chosen identifier string. This setting is used to find sibling
+        verity partitions for the current verity partition. See the description for
+        <varname>Verity=</varname>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>VerityDataBlockSizeBytes=</varname></term>
+
+        <listitem><para>Configures the data block size of the generated verity hash partition. Must be between 512 and
+        4096 bytes and must be a power of 2. Defaults to the sector size if configured explicitly, or the underlying
+        block device sector size, or 4K if systemd-repart is not operating on a block device.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>VerityHashBlockSizeBytes=</varname></term>
+
+        <listitem><para>Configures the hash block size of the generated verity hash partition. Must be between 512 and
+        4096 bytes and must be a power of 2. Defaults to the sector size if configured explicitly, or the underlying
+        block device sector size, or 4K if systemd-repart is not operating on a block device.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>FactoryReset=</varname></term>
+
+        <listitem><para>Takes a boolean argument. If specified the partition is marked for removal during a
+        factory reset operation. This functionality is useful to implement schemes where images can be reset
+        into their original state by removing partitions and creating them anew. Defaults to off.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Flags=</varname></term>
+
+        <listitem><para>Configures the 64-bit GPT partition flags field to set for the partition when creating
+        it. This option has no effect if the partition already exists. If not specified the flags values is
+        set to all zeroes, except for the three bits that can also be configured via
+        <varname>NoAuto=</varname>, <varname>ReadOnly=</varname> and <varname>GrowFileSystem=</varname>; see
+        below for details on the defaults for these three flags. Specify the flags value in hexadecimal (by
+        prefixing it with <literal>0x</literal>), binary (prefix <literal>0b</literal>) or decimal (no
+        prefix).</para>
+
+        <xi:include href="version-info.xml" xpointer="v249"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>NoAuto=</varname></term>
+        <term><varname>ReadOnly=</varname></term>
+        <term><varname>GrowFileSystem=</varname></term>
+
+        <listitem><para>Configures the No-Auto, Read-Only and Grow-File-System partition flags (bit 63, 60
+        and 59) of the partition table entry, as defined by the <ulink
+        url="https://uapi-group.org/specifications/specs/discoverable_partitions_specification">Discoverable Partitions Specification</ulink>. Only
+        available for partition types supported by the specification. This option is a friendly way to set
+        bits 63, 60 and 59 of the partition flags value without setting any of the other bits, and may be set
+        via <varname>Flags=</varname> too, see above.</para>
+
+        <para>If <varname>Flags=</varname> is used in conjunction with one or more of
+        <varname>NoAuto=</varname>/<varname>ReadOnly=</varname>/<varname>GrowFileSystem=</varname> the latter
+        control the value of the relevant flags, i.e. the high-level settings
+        <varname>NoAuto=</varname>/<varname>ReadOnly=</varname>/<varname>GrowFileSystem=</varname> override
+        the relevant bits of the low-level setting <varname>Flags=</varname>.</para>
+
+        <para>Note that the three flags affect only automatic partition mounting, as implemented by
+        <citerefentry><refentrytitle>systemd-gpt-auto-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        or the <option>--image=</option> option of various commands (such as
+        <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>). It
+        has no effect on explicit mounts, such as those done via <citerefentry
+        project='man-pages'><refentrytitle>mount</refentrytitle><manvolnum>8</manvolnum></citerefentry> or
+        <citerefentry
+        project='man-pages'><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+
+        <para>If both bit 50 and 59 are set for a partition (i.e. the partition is marked both read-only and
+        marked for file system growing) the latter is typically without effect: the read-only flag takes
+        precedence in most tools reading these flags, and since growing the file system involves writing to
+        the partition it is consequently ignored.</para>
+
+        <para><varname>NoAuto=</varname> defaults to off. <varname>ReadOnly=</varname> defaults to on for
+        Verity partition types, and off for all others. <varname>GrowFileSystem=</varname> defaults to on for
+        all partition types that support it, except if the partition is marked read-only (and thus
+        effectively, defaults to off for Verity partitions).</para>
+
+        <xi:include href="version-info.xml" xpointer="v249"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SplitName=</varname></term>
+
+        <listitem><para>Configures the suffix to append to split artifacts when the <option>--split</option>
+        option of
+        <citerefentry><refentrytitle>systemd-repart</refentrytitle><manvolnum>8</manvolnum></citerefentry> is
+        used. Simple specifier expansion is supported, see below. Defaults to <literal>%t</literal>. To
+        disable split artifact generation for a partition, set <varname>SplitName=</varname> to
+        <literal>-</literal>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Minimize=</varname></term>
+
+        <listitem><para>Takes one of <literal>off</literal>, <literal>best</literal>, and
+        <literal>guess</literal> (alternatively, also accepts a boolean value, which is mapped to
+        <literal>off</literal> when false, and <literal>best</literal> when true). Defaults to
+        <literal>off</literal>. If set to <literal>best</literal>, the partition will have the minimal size
+        required to store the sources configured with <varname>CopyFiles=</varname>. <literal>best</literal>
+        is currently only supported for read-only filesystems. If set to <literal>guess</literal>, the
+        partition is created at least as big as required to store the sources configured with
+        <varname>CopyFiles=</varname>. Note that unless the filesystem is a read-only filesystem,
+        <command>systemd-repart</command> will have to populate the filesystem twice to guess the minimal
+        required size, so enabling this option might slow down repart when populating large partitions.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v253"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Specifiers</title>
+
+    <para>Specifiers may be used in the <varname>Label=</varname>, <varname>CopyBlocks=</varname>,
+    <varname>CopyFiles=</varname>, <varname>MakeDirectories=</varname>, <varname>SplitName=</varname>
+    settings. The following expansions are understood:</para>
+      <table class='specifiers'>
+        <title>Specifiers available</title>
+        <tgroup cols='3' align='left' colsep='1' rowsep='1'>
+          <colspec colname="spec" />
+          <colspec colname="mean" />
+          <colspec colname="detail" />
+          <thead>
+            <row>
+              <entry>Specifier</entry>
+              <entry>Meaning</entry>
+              <entry>Details</entry>
+            </row>
+          </thead>
+          <tbody>
+            <xi:include href="standard-specifiers.xml" xpointer="a"/>
+            <xi:include href="standard-specifiers.xml" xpointer="A"/>
+            <xi:include href="standard-specifiers.xml" xpointer="b"/>
+            <xi:include href="standard-specifiers.xml" xpointer="B"/>
+            <xi:include href="standard-specifiers.xml" xpointer="H"/>
+            <xi:include href="standard-specifiers.xml" xpointer="l"/>
+            <xi:include href="standard-specifiers.xml" xpointer="m"/>
+            <xi:include href="standard-specifiers.xml" xpointer="M"/>
+            <xi:include href="standard-specifiers.xml" xpointer="o"/>
+            <xi:include href="standard-specifiers.xml" xpointer="v"/>
+            <xi:include href="standard-specifiers.xml" xpointer="w"/>
+            <xi:include href="standard-specifiers.xml" xpointer="W"/>
+            <xi:include href="standard-specifiers.xml" xpointer="T"/>
+            <xi:include href="standard-specifiers.xml" xpointer="V"/>
+            <xi:include href="standard-specifiers.xml" xpointer="percent"/>
+          </tbody>
+        </tgroup>
+      </table>
+
+    <para>Additionally, for the <varname>SplitName=</varname> setting, the following specifiers are also
+    understood:</para>
+      <table class='specifiers'>
+        <title>Specifiers available</title>
+        <tgroup cols='3' align='left' colsep='1' rowsep='1'>
+          <colspec colname="spec" />
+          <colspec colname="mean" />
+          <colspec colname="detail" />
+          <thead>
+            <row>
+              <entry>Specifier</entry>
+              <entry>Meaning</entry>
+              <entry>Details</entry>
+            </row>
+          </thead>
+          <tbody>
+            <row id='T'>
+              <entry><literal>%T</literal></entry>
+              <entry>Partition Type UUID</entry>
+              <entry>The partition type UUID, as configured with <varname>Type=</varname></entry>
+            </row>
+            <row id='t'>
+              <entry><literal>%t</literal></entry>
+              <entry>Partition Type Identifier</entry>
+              <entry>The partition type identifier corresponding to the partition type UUID</entry>
+            </row>
+            <row id='U'>
+              <entry><literal>%U</literal></entry>
+              <entry>Partition UUID</entry>
+              <entry>The partition UUID, as configured with <varname>UUID=</varname></entry>
+            </row>
+            <row id='n'>
+              <entry><literal>%n</literal></entry>
+              <entry>Partition Number</entry>
+              <entry>The partition number assigned to the partition</entry>
+            </row>
+          </tbody>
+        </tgroup>
+      </table>
+  </refsect1>
+
+  <refsect1>
+    <title>Examples</title>
+
+    <example>
+      <title>Grow the root partition to the full disk size at first boot</title>
+
+      <para>With the following file the root partition is automatically grown to the full disk if possible
+      during boot.</para>
+
+      <para><programlisting># /usr/lib/repart.d/50-root.conf
+[Partition]
+Type=root
+</programlisting></para>
+    </example>
+
+    <example>
+      <title>Create a swap and home partition automatically on boot, if missing</title>
+
+      <para>The home partition gets all available disk space while the swap partition gets 1G at most and 64M
+      at least. We set a priority > 0 on the swap partition to ensure the swap partition is not used if not
+      enough space is available. For every three bytes assigned to the home partition the swap partition gets
+      assigned one.</para>
+
+      <para><programlisting># /usr/lib/repart.d/60-home.conf
+[Partition]
+Type=home
+</programlisting></para>
+
+      <para><programlisting># /usr/lib/repart.d/70-swap.conf
+[Partition]
+Type=swap
+SizeMinBytes=64M
+SizeMaxBytes=1G
+Priority=1
+Weight=333
+</programlisting></para>
+    </example>
+
+    <example>
+      <title>Create B partitions in an A/B Verity setup, if missing</title>
+
+      <para>Let's say the vendor intends to update OS images in an A/B setup, i.e. with two root partitions
+      (and two matching Verity partitions) that shall be used alternatingly during upgrades. To minimize
+      image sizes the original image is shipped only with one root and one Verity partition (the "A" set),
+      and the second root and Verity partitions (the "B" set) shall be created on first boot on the free
+      space on the medium.</para>
+
+      <para><programlisting># /usr/lib/repart.d/50-root.conf
+[Partition]
+Type=root
+SizeMinBytes=512M
+SizeMaxBytes=512M
+</programlisting></para>
+
+      <para><programlisting># /usr/lib/repart.d/60-root-verity.conf
+[Partition]
+Type=root-verity
+SizeMinBytes=64M
+SizeMaxBytes=64M
+</programlisting></para>
+
+      <para>The definitions above cover the "A" set of root partition (of a fixed 512M size) and Verity
+      partition for the root partition (of a fixed 64M size). Let's use symlinks to create the "B" set of
+      partitions, since after all they shall have the same properties and sizes as the "A" set.</para>
+
+<para><programlisting># ln -s 50-root.conf /usr/lib/repart.d/70-root-b.conf
+# ln -s 60-root-verity.conf /usr/lib/repart.d/80-root-verity-b.conf
+</programlisting></para>
+    </example>
+
+     <example>
+      <title>Create a data partition and corresponding verity partitions from a OS tree</title>
+
+      <para>Assuming we have an OS tree at <filename index='false'>/var/tmp/os-tree</filename> that we want
+      to package in a root partition together with matching verity partitions, we can do so as follows:
+      </para>
+
+      <para><programlisting># 50-root.conf
+[Partition]
+Type=root
+CopyFiles=/var/tmp/os-tree
+Verity=data
+VerityMatchKey=root
+Minimize=guess
+</programlisting></para>
+
+      <para><programlisting># 60-root-verity.conf
+[Partition]
+Type=root-verity
+Verity=hash
+VerityMatchKey=root
+# Explicitly set the hash and data block size to 4K
+VerityDataBlockSizeBytes=4096
+VerityHashBlockSizeBytes=4096
+Minimize=best
+</programlisting></para>
+
+<para><programlisting># 70-root-verity-sig.conf
+[Partition]
+Type=root-verity-sig
+Verity=signature
+VerityMatchKey=root
+</programlisting></para>
+    </example>
+
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-repart</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>sfdisk</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-cryptenroll</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/resolvectl.xml b/man/resolvectl.xml
new file mode 100644
index 0000000..4498732
--- /dev/null
+++ b/man/resolvectl.xml
@@ -0,0 +1,680 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="resolvectl" conditional='ENABLE_RESOLVE'
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>resolvectl</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>resolvectl</refentrytitle>
+    <manvolnum>1</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>resolvectl</refname>
+    <refname>resolvconf</refname>
+    <refpurpose>Resolve domain names, IPV4 and IPv6 addresses, DNS resource records, and services; introspect and reconfigure the DNS resolver</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <cmdsynopsis>
+      <command>resolvectl</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="req">COMMAND</arg>
+      <arg choice="opt" rep="repeat">NAME</arg>
+    </cmdsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>resolvectl</command> may be used to resolve domain names, IPv4 and IPv6 addresses, DNS resource
+    records and services with the
+    <citerefentry><refentrytitle>systemd-resolved.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    resolver service. By default, the specified list of parameters will be resolved as hostnames, retrieving their IPv4
+    and IPv6 addresses. If the parameters specified are formatted as IPv4 or IPv6 addresses the reverse operation is
+    done, and a hostname is retrieved for the specified addresses.</para>
+
+    <para>The program's output contains information about the protocol used for the look-up and on which network
+    interface the data was discovered. It also contains information on whether the information could be
+    authenticated. All data for which local DNSSEC validation succeeds is considered authenticated. Moreover all data
+    originating from local, trusted sources is also reported authenticated, including resolution of the local host
+    name, the <literal>localhost</literal> hostname or all data from <filename>/etc/hosts</filename>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Commands</title>
+    <variablelist>
+
+      <varlistentry>
+        <term><command>query</command> <replaceable>HOSTNAME|ADDRESS</replaceable>…</term>
+
+        <listitem><para>Resolve domain names, as well as IPv4 and IPv6 addresses. When used in conjunction
+        with <option>--type=</option> or <option>--class=</option> (see below), resolves low-level DNS
+        resource records.</para>
+
+        <para>If a single-label domain name is specified it is searched for according to the configured
+        search domains — unless <option>--search=no</option> or
+        <option>--type=</option>/<option>--class=</option> are specified, both of which turn this logic
+        off.</para>
+
+        <para>If an international domain name is specified, it is automatically translated according to IDNA
+        rules when resolved via classic DNS — but not for look-ups via MulticastDNS or LLMNR. If
+        <option>--type=</option>/<option>--class=</option> is used IDNA translation is turned off and domain
+        names are processed as specified.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>service</command>
+        [[<replaceable>NAME</replaceable>] <replaceable>TYPE</replaceable>]
+        <replaceable>DOMAIN</replaceable></term>
+
+        <listitem><para>Resolve <ulink url="https://tools.ietf.org/html/rfc6763">RFC 6763 DNS-SD</ulink> and
+        <ulink url="https://tools.ietf.org/html/rfc2782">RFC 2782 SRV</ulink> services, depending on the
+        specified list of parameters. If three parameters are passed the first is assumed to be the DNS-SD
+        service name, the second the <constant class='dns'>SRV</constant> service type, and the third the
+        domain to search in. In this case a full DNS-SD style <constant class='dns'>SRV</constant> and
+        <constant class='dns'>TXT</constant> lookup is executed. If only two parameters are specified, the
+        first is assumed to be the <constant class='dns'>SRV</constant> service type, and the second the
+        domain to look in. In this case no <constant class='dns'>TXT</constant> resource record is requested.
+        Finally, if only one parameter is specified, it is assumed to be a domain name, that is already
+        prefixed with an <constant class='dns'>SRV</constant> type, and an <constant
+        class='dns'>SRV</constant> lookup is done (no <constant class='dns'>TXT</constant>).</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>openpgp</command> <replaceable>EMAIL@DOMAIN</replaceable>…</term>
+
+        <listitem><para>Query PGP keys stored as <constant class='dns'>OPENPGPKEY</constant> resource records,
+        see <ulink url="https://tools.ietf.org/html/rfc7929">RFC 7929</ulink>. Specified e-mail addresses
+        are converted to the corresponding DNS domain name, and any <constant class='dns'>OPENPGPKEY</constant>
+        keys are printed.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>tlsa</command>
+        [<replaceable>FAMILY</replaceable>]
+        <replaceable>DOMAIN</replaceable>[:<replaceable>PORT</replaceable>]…</term>
+
+        <listitem><para>Query TLS public keys stored as <constant class='dns'>TLSA</constant> resource
+        records, see <ulink url="https://tools.ietf.org/html/rfc6698">RFC 6698</ulink>. A query will be
+        performed for each of the specified names prefixed with the port and family
+        (<literal>_<replaceable>port</replaceable>._<replaceable>family</replaceable>.<replaceable>domain</replaceable></literal>).
+        The port number may be specified after a colon (<literal>:</literal>), otherwise
+        <constant>443</constant> will be used by default. The family may be specified as the first argument,
+        otherwise <constant>tcp</constant> will be used.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>status</command> [<replaceable>LINK</replaceable>…]</term>
+
+        <listitem><para>Shows the global and per-link DNS settings currently in effect. If no command is specified,
+        this is the implied default.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>statistics</command></term>
+
+        <listitem><para>Shows general resolver statistics, including information whether DNSSEC is
+        enabled and available, as well as resolution and validation statistics.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>reset-statistics</command></term>
+
+        <listitem><para>Resets the statistics counters shown in <command>statistics</command> to zero.
+        This operation requires root privileges.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>flush-caches</command></term>
+
+        <listitem><para>Flushes all DNS resource record caches the service maintains locally. This is mostly
+        equivalent to sending the <constant>SIGUSR2</constant> to the <command>systemd-resolved</command>
+        service.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>reset-server-features</command></term>
+
+        <listitem><para>Flushes all feature level information the resolver learnt about specific servers, and ensures
+        that the server feature probing logic is started from the beginning with the next look-up request. This is
+        mostly equivalent to sending the <constant>SIGRTMIN+1</constant> to the <command>systemd-resolved</command>
+        service.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>dns</command> [<replaceable>LINK</replaceable> [<replaceable>SERVER</replaceable>…]]</term>
+        <term><command>domain</command> [<replaceable>LINK</replaceable> [<replaceable>DOMAIN</replaceable>…]]</term>
+        <term><command>default-route</command> [<replaceable>LINK</replaceable> [<replaceable>BOOL</replaceable>…]]</term>
+        <term><command>llmnr</command> [<replaceable>LINK</replaceable> [<replaceable>MODE</replaceable>]]</term>
+        <term><command>mdns</command> [<replaceable>LINK</replaceable> [<replaceable>MODE</replaceable>]]</term>
+        <term><command>dnssec</command> [<replaceable>LINK</replaceable> [<replaceable>MODE</replaceable>]]</term>
+        <term><command>dnsovertls</command> [<replaceable>LINK</replaceable> [<replaceable>MODE</replaceable>]]</term>
+        <term><command>nta</command> [<replaceable>LINK</replaceable> [<replaceable>DOMAIN</replaceable>…]]</term>
+
+        <listitem>
+          <para>Get/set per-interface DNS configuration. These commands may be used to configure various DNS
+          settings for network interfaces. These commands may be used to inform
+          <command>systemd-resolved</command> or <command>systemd-networkd</command> about per-interface DNS
+          configuration determined through external means. The <command>dns</command> command expects IPv4 or
+          IPv6 address specifications of DNS servers to use. Each address can optionally take a port number
+          separated with <literal>:</literal>, a network interface name or index separated with
+          <literal>%</literal>, and a Server Name Indication (SNI) separated with <literal>#</literal>. When
+          IPv6 address is specified with a port number, then the address must be in the square brackets. That
+          is, the acceptable full formats are <literal>111.222.333.444:9953%ifname#example.com</literal> for
+          IPv4 and <literal>[1111:2222::3333]:9953%ifname#example.com</literal> for IPv6. The
+          <command>domain</command> command expects valid DNS domains, possibly prefixed with
+          <literal>~</literal>, and configures a per-interface search or route-only domain. The
+          <command>default-route</command> command expects a boolean parameter, and configures whether the
+          link may be used as default route for DNS lookups, i.e. if it is suitable for lookups on domains no
+          other link explicitly is configured for. The <command>llmnr</command>, <command>mdns</command>,
+          <command>dnssec</command> and <command>dnsovertls</command> commands may be used to configure the
+          per-interface LLMNR, MulticastDNS, DNSSEC and DNSOverTLS settings. Finally, <command>nta</command>
+          command may be used to configure additional per-interface DNSSEC NTA domains.</para>
+
+          <para>Commands <command>dns</command>, <command>domain</command> and <command>nta</command> can take
+          a single empty string argument to clear their respective value lists.</para>
+
+          <para>For details about these settings, their possible values and their effect, see the
+          corresponding settings in
+          <citerefentry><refentrytitle>systemd.network</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v239"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>revert <replaceable>LINK</replaceable></command></term>
+
+        <listitem><para>Revert the per-interface DNS configuration. If the DNS configuration is reverted all
+        per-interface DNS setting are reset to their defaults, undoing all effects of <command>dns</command>,
+        <command>domain</command>, <command>default-route</command>, <command>llmnr</command>,
+        <command>mdns</command>, <command>dnssec</command>, <command>dnsovertls</command>,
+        <command>nta</command>. Note that when a network interface disappears all configuration is lost
+        automatically, an explicit reverting is not necessary in that case.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>monitor</command></term>
+
+        <listitem><para>Show a continuous stream of local client resolution queries and their
+        responses. Whenever a local query is completed the query's DNS resource lookup key and resource
+        records are shown. Note that this displays queries issued locally only, and does not immediately
+        relate to DNS requests submitted to configured DNS servers or the LLMNR or MulticastDNS zones, as
+        lookups may be answered from the local cache, or might result in multiple DNS transactions (for
+        example to validate DNSSEC information). If CNAME/CNAME redirection chains are followed, a separate
+        query will be displayed for each element of the chain. Use <option>--json=</option> to enable JSON
+        output.</para>
+
+        <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>show-cache</command></term>
+
+        <listitem><para>Show current cache content, per scope. Use <option>--json=</option> to enable JSON
+        output.</para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>show-server-state</command></term>
+
+        <listitem><para>Show detailed server state information, per DNS Server. Use <option>--json=</option>
+        to enable JSON output.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+
+      <xi:include href="systemctl.xml" xpointer="log-level" />
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+    <variablelist>
+      <varlistentry>
+        <term><option>-4</option></term>
+        <term><option>-6</option></term>
+
+        <listitem><para>By default, when resolving a hostname, both IPv4 and IPv6
+        addresses are acquired. By specifying <option>-4</option> only IPv4 addresses are requested, by specifying
+        <option>-6</option> only IPv6 addresses are requested.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-i</option> <replaceable>INTERFACE</replaceable></term>
+        <term><option>--interface=</option><replaceable>INTERFACE</replaceable></term>
+
+        <listitem><para>Specifies the network interface to execute the query on. This may either be specified as numeric
+        interface index or as network interface string (e.g. <literal>en0</literal>). Note that this option has no
+        effect if system-wide DNS configuration (as configured in <filename>/etc/resolv.conf</filename> or
+        <filename>/etc/systemd/resolved.conf</filename>) in place of per-link configuration is used.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-p</option> <replaceable>PROTOCOL</replaceable></term>
+        <term><option>--protocol=</option><replaceable>PROTOCOL</replaceable></term>
+
+        <listitem><para>Specifies the network protocol for the query. May be one of <literal>dns</literal>
+        (i.e. classic unicast DNS), <literal>llmnr</literal> (<ulink
+        url="https://tools.ietf.org/html/rfc4795">Link-Local Multicast Name Resolution</ulink>),
+        <literal>llmnr-ipv4</literal>, <literal>llmnr-ipv6</literal> (LLMNR via the indicated underlying IP
+        protocols), <literal>mdns</literal> (<ulink url="https://www.ietf.org/rfc/rfc6762.txt">Multicast DNS</ulink>),
+        <literal>mdns-ipv4</literal>, <literal>mdns-ipv6</literal> (MDNS via the indicated underlying IP protocols).
+        By default the lookup is done via all protocols suitable for the lookup. If used, limits the set of
+        protocols that may be used. Use this option multiple times to enable resolving via multiple protocols at the
+        same time. The setting <literal>llmnr</literal> is identical to specifying this switch once with
+        <literal>llmnr-ipv4</literal> and once via <literal>llmnr-ipv6</literal>. Note that this option does not force
+        the service to resolve the operation with the specified protocol, as that might require a suitable network
+        interface and configuration.
+        The special value <literal>help</literal> may be used to list known values.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-t</option> <replaceable>TYPE</replaceable></term>
+        <term><option>--type=</option><replaceable>TYPE</replaceable></term>
+        <term><option>-c</option> <replaceable>CLASS</replaceable></term>
+        <term><option>--class=</option><replaceable>CLASS</replaceable></term>
+
+        <listitem><para>When used in conjunction with the <command>query</command> command, specifies the DNS
+        resource record type (e.g. <constant class='dns'>A</constant>, <constant class='dns'>AAAA</constant>,
+        <constant class='dns'>MX</constant>, …) and class (e.g. <constant>IN</constant>,
+        <constant>ANY</constant>, …) to look up. If these options are used a DNS resource record set matching
+        the specified class and type is requested. The class defaults to <constant>IN</constant> if only a
+        type is specified. The special value <literal>help</literal> may be used to list known values.</para>
+
+        <para>Without these options <command>resolvectl query</command> provides high-level domain name to
+        address and address to domain name resolution. With these options it provides low-level DNS resource
+        record resolution. The search domain logic is automatically turned off when these options are used,
+        i.e. specified domain names need to be fully qualified domain names. Moreover, IDNA internal domain
+        name translation is turned off as well, i.e. international domain names should be specified in
+        <literal>xn--…</literal> notation, unless look-up in MulticastDNS/LLMNR is desired, in which case
+        UTF-8 characters should be used.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--service-address=</option><replaceable>BOOL</replaceable></term>
+
+        <listitem><para>Takes a boolean parameter. If true (the default), when doing a service lookup with
+        <option>--service</option> the hostnames contained in the <constant class='dns'>SRV</constant>
+        resource records are resolved as well.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--service-txt=</option><replaceable>BOOL</replaceable></term>
+
+        <listitem><para>Takes a boolean parameter. If true (the default), when doing a DNS-SD service lookup
+        with <option>--service</option> the <constant class='dns'>TXT</constant> service metadata record is
+        resolved as well.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--cname=</option><replaceable>BOOL</replaceable></term>
+
+        <listitem><para>Takes a boolean parameter. If true (the default), DNS <constant
+        class='dns'>CNAME</constant> or <constant class='dns'>DNAME</constant> redirections are
+        followed. Otherwise, if a CNAME or DNAME record is encountered while resolving, an error is
+        returned.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--validate=</option><replaceable>BOOL</replaceable></term>
+
+        <listitem><para>Takes a boolean parameter; used in conjunction with <command>query</command>. If true
+        (the default), DNSSEC validation is applied as usual — under the condition that it is enabled for the
+        network and for <filename>systemd-resolved.service</filename> as a whole. If false, DNSSEC validation
+        is disabled for the specific query, regardless of whether it is enabled for the network or in the
+        service. Note that setting this option to true does not force DNSSEC validation on systems/networks
+        where DNSSEC is turned off. This option is only suitable to turn off such validation where otherwise
+        enabled, not enable validation where otherwise disabled.</para>
+
+        <xi:include href="version-info.xml" xpointer="v248"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--synthesize=</option><replaceable>BOOL</replaceable></term>
+
+        <listitem><para>Takes a boolean parameter; used in conjunction with <command>query</command>. If true
+        (the default), select domains are resolved on the local system, among them
+        <literal>localhost</literal>, <literal>_gateway</literal>, <literal>_outbound</literal>,
+        <literal>_localdnsstub</literal> and <literal>_localdnsproxy</literal> or entries from
+        <filename>/etc/hosts</filename>. If false these domains are not resolved locally, and either fail (in
+        case of <literal>localhost</literal>, <literal>_gateway</literal> or <literal>_outbound</literal> and
+        suchlike) or go to the network via regular DNS/mDNS/LLMNR lookups (in case of
+        <filename>/etc/hosts</filename> entries).</para>
+
+        <xi:include href="version-info.xml" xpointer="v248"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--cache=</option><replaceable>BOOL</replaceable></term>
+
+        <listitem><para>Takes a boolean parameter; used in conjunction with <command>query</command>. If true
+        (the default), lookups use the local DNS resource record cache. If false, lookups are routed to the
+        network instead, regardless if already available in the local cache.</para>
+
+        <xi:include href="version-info.xml" xpointer="v248"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--zone=</option><replaceable>BOOL</replaceable></term>
+
+        <listitem><para>Takes a boolean parameter; used in conjunction with <command>query</command>. If true
+        (the default), lookups are answered from locally registered LLMNR or mDNS resource records, if
+        defined. If false, locally registered LLMNR/mDNS records are not considered for the lookup
+        request.</para>
+
+        <xi:include href="version-info.xml" xpointer="v248"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--trust-anchor=</option><replaceable>BOOL</replaceable></term>
+
+        <listitem><para>Takes a boolean parameter; used in conjunction with <command>query</command>. If true
+        (the default), lookups for DS and DNSKEY are answered from the local DNSSEC trust anchors if
+        possible. If false, the local trust store is not considered for the lookup request.</para>
+
+        <xi:include href="version-info.xml" xpointer="v248"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--network=</option><replaceable>BOOL</replaceable></term>
+
+        <listitem><para>Takes a boolean parameter; used in conjunction with <command>query</command>. If true
+        (the default), lookups are answered via DNS, LLMNR or mDNS network requests if they cannot be
+        synthesized locally, or be answered from the local cache, zone or trust anchors (see above). If false,
+        the request is not answered from the network and will thus fail if none of the indicated sources can
+        answer them.</para>
+
+        <xi:include href="version-info.xml" xpointer="v248"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--search=</option><replaceable>BOOL</replaceable></term>
+
+        <listitem><para>Takes a boolean parameter. If true (the default), any specified single-label
+        hostnames will be searched in the domains configured in the search domain list, if it is
+        non-empty. Otherwise, the search domain logic is disabled. Note that this option has no effect if
+        <option>--type=</option> is used (see above), in which case the search domain logic is
+        unconditionally turned off.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--raw</option><optional>=payload|packet</optional></term>
+
+        <listitem><para>Dump the answer as binary data. If there is no argument or if the argument is
+        <literal>payload</literal>, the payload of the packet is exported. If the argument is
+        <literal>packet</literal>, the whole packet is dumped in wire format, prefixed by
+        length specified as a little-endian 64-bit number. This format allows multiple packets
+        to be dumped and unambiguously parsed.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--legend=</option><replaceable>BOOL</replaceable></term>
+
+        <listitem><para>Takes a boolean parameter. If true (the default), column headers and meta information about the
+        query response are shown. Otherwise, this output is suppressed.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--stale-data=</option><replaceable>BOOL</replaceable></term>
+
+        <listitem><para>Takes a boolean parameter; used in conjunction with <command>query</command>. If true
+        (the default), lookups are answered with stale data (expired resource records) if
+        possible. If false, the stale data is not considered for the lookup request.</para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+      </varlistentry>
+
+      <xi:include href="standard-options.xml" xpointer="json" />
+
+      <varlistentry>
+        <term><option>-j</option></term>
+
+        <listitem><para>Short for <option>--json=auto</option></para>
+
+        <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+      </varlistentry>
+
+      <xi:include href="standard-options.xml" xpointer="no-pager" />
+      <xi:include href="standard-options.xml" xpointer="help" />
+      <xi:include href="standard-options.xml" xpointer="version" />
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Compatibility with
+    <citerefentry project="debian"><refentrytitle>resolvconf</refentrytitle><manvolnum>8</manvolnum></citerefentry></title>
+
+    <para><command>resolvectl</command> is a multi-call binary. When invoked as <literal>resolvconf</literal>
+    (generally achieved by means of a symbolic link of this name to the <command>resolvectl</command> binary) it
+    is run in a limited
+    <citerefentry project="debian"><refentrytitle>resolvconf</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    compatibility mode. It accepts mostly the same arguments and pushes all data into
+    <citerefentry><refentrytitle>systemd-resolved.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+    similar to how <option>dns</option> and <option>domain</option> commands operate. Note that
+    <command>systemd-resolved.service</command> is the only supported backend, which is different from other
+    implementations of this command.</para>
+
+    <para><filename>/etc/resolv.conf</filename> will only be updated with servers added with this command
+    when <filename>/etc/resolv.conf</filename> is a symlink to
+    <filename>/run/systemd/resolve/resolv.conf</filename>, and not a static file. See the discussion of
+    <filename>/etc/resolv.conf</filename> handling in
+    <citerefentry><refentrytitle>systemd-resolved.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+    </para>
+
+    <para>Not all operations supported by other implementations are supported natively. Specifically:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><option>-a</option></term>
+        <listitem><para>Registers per-interface DNS configuration data with
+        <command>systemd-resolved</command>. Expects a network interface name as only command line argument. Reads
+        <citerefentry project='man-pages'><refentrytitle>resolv.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>-compatible
+        DNS configuration data from its standard input. Relevant fields are <literal>nameserver</literal> and
+        <literal>domain</literal>/<literal>search</literal>. This command is mostly identical to invoking
+        <command>resolvectl</command> with a combination of <option>dns</option> and <option>domain</option>
+        commands.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-d</option></term>
+        <listitem><para>Unregisters per-interface DNS configuration data with <command>systemd-resolved</command>. This
+        command is mostly identical to invoking <command>resolvectl revert</command>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-f</option></term>
+
+        <listitem><para>When specified <option>-a</option> and <option>-d</option> will not complain about missing
+        network interfaces and will silently execute no operation in that case.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-x</option></term>
+
+        <listitem><para>This switch for "exclusive" operation is supported only partially. It is mapped to an
+        additional configured search domain of <literal>~.</literal> — i.e. ensures that DNS traffic is preferably
+        routed to the DNS servers on this interface, unless there are other, more specific domains configured on other
+        interfaces.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-m</option></term>
+        <term><option>-p</option></term>
+
+        <listitem><para>These switches are not supported and are silently ignored.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-u</option></term>
+        <term><option>-I</option></term>
+        <term><option>-i</option></term>
+        <term><option>-l</option></term>
+        <term><option>-R</option></term>
+        <term><option>-r</option></term>
+        <term><option>-v</option></term>
+        <term><option>-V</option></term>
+        <term><option>--enable-updates</option></term>
+        <term><option>--disable-updates</option></term>
+        <term><option>--are-updates-enabled</option></term>
+
+        <listitem><para>These switches are not supported and the command will fail if used.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+    </variablelist>
+
+    <para>See
+    <citerefentry project="debian"><refentrytitle>resolvconf</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    for details on those command line options.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Examples</title>
+
+    <example>
+      <title>Retrieve the addresses of the <literal>www.0pointer.net</literal> domain (<constant class='dns'>A</constant> and <constant class='dns'>AAAA</constant> resource records)</title>
+
+      <programlisting>$ resolvectl query www.0pointer.net
+www.0pointer.net: 2a01:238:43ed:c300:10c3:bcf3:3266:da74
+                  85.214.157.71
+
+-- Information acquired via protocol DNS in 611.6ms.
+-- Data is authenticated: no
+</programlisting>
+    </example>
+
+    <example>
+      <title>Retrieve the domain of the <literal>85.214.157.71</literal> IP address
+      (<constant class='dns'>PTR</constant> resource record)</title>
+
+      <programlisting>$ resolvectl query 85.214.157.71
+85.214.157.71: gardel.0pointer.net
+
+-- Information acquired via protocol DNS in 1.2997s.
+-- Data is authenticated: no
+</programlisting>
+    </example>
+
+    <example>
+      <title>Retrieve the <constant class='dns'>MX</constant> record of the <literal>yahoo.com</literal>
+      domain</title>
+
+      <programlisting>$ resolvectl --legend=no -t MX query yahoo.com
+yahoo.com. IN MX    1 mta7.am0.yahoodns.net
+yahoo.com. IN MX    1 mta6.am0.yahoodns.net
+yahoo.com. IN MX    1 mta5.am0.yahoodns.net
+</programlisting>
+    </example>
+
+    <example>
+      <title>Resolve an <constant class='dns'>SRV</constant> service</title>
+
+      <programlisting>$ resolvectl service _xmpp-server._tcp gmail.com
+_xmpp-server._tcp/gmail.com: alt1.xmpp-server.l.google.com:5269 [priority=20, weight=0]
+                             173.194.210.125
+                             alt4.xmpp-server.l.google.com:5269 [priority=20, weight=0]
+                             173.194.65.125
+                             …
+</programlisting>
+    </example>
+
+    <example>
+      <title>Retrieve a PGP key (<constant class='dns'>OPENPGP</constant> resource record)</title>
+
+      <programlisting>$ resolvectl openpgp zbyszek@fedoraproject.org
+d08ee310438ca124a6149ea5cc21b6313b390dce485576eff96f8722._openpgpkey.fedoraproject.org. IN OPENPGPKEY
+        mQINBFBHPMsBEACeInGYJCb+7TurKfb6wGyTottCDtiSJB310i37/6ZYoeIay/5soJjlMyf
+        MFQ9T2XNT/0LM6gTa0MpC1st9LnzYTMsT6tzRly1D1UbVI6xw0g0vE5y2Cjk3xUwAynCsSs
+        …
+</programlisting>
+    </example>
+
+    <example>
+      <title>Retrieve a TLS key (<constant class='dns'>TLSA</constant> resource record)</title>
+
+      <programlisting>$ resolvectl tlsa tcp fedoraproject.org:443
+_443._tcp.fedoraproject.org IN TLSA 0 0 1 19400be5b7a31fb733917700789d2f0a2471c0c9d506c0e504c06c16d7cb17c0
+        -- Cert. usage: CA constraint
+        -- Selector: Full Certificate
+        -- Matching type: SHA-256
+</programlisting>
+
+      <para><literal>tcp</literal> and <literal>:443</literal> are optional and could be skipped.</para>
+    </example>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-resolved.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.dnssd</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>resolvconf</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+</refentry>
diff --git a/man/resolved.conf.xml b/man/resolved.conf.xml
new file mode 100644
index 0000000..d153865
--- /dev/null
+++ b/man/resolved.conf.xml
@@ -0,0 +1,406 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [
+<!ENTITY % entities SYSTEM "custom-entities.ent" >
+%entities;
+]>
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="resolved.conf" conditional='ENABLE_RESOLVE'
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+  <refentryinfo>
+    <title>resolved.conf</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>resolved.conf</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>resolved.conf</refname>
+    <refname>resolved.conf.d</refname>
+    <refpurpose>Network Name Resolution configuration files</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>/etc/systemd/resolved.conf</filename></para>
+    <para><filename>/etc/systemd/resolved.conf.d/*.conf</filename></para>
+    <para><filename>/run/systemd/resolved.conf.d/*.conf</filename></para>
+    <para><filename>/usr/lib/systemd/resolved.conf.d/*.conf</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>These configuration files control local DNS and LLMNR
+    name resolution.</para>
+
+  </refsect1>
+
+  <xi:include href="standard-conf.xml" xpointer="main-conf" />
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>The following options are available in the [Resolve] section:</para>
+
+    <variablelist class='network-directives'>
+
+      <varlistentry>
+        <term><varname>DNS=</varname></term>
+        <listitem><para>A space-separated list of IPv4 and IPv6 addresses to use as system DNS servers. Each address can
+        optionally take a port number separated with <literal>:</literal>, a network interface name or index separated with
+        <literal>%</literal>, and a Server Name Indication (SNI) separated with <literal>#</literal>. When IPv6 address is
+        specified with a port number, then the address must be in the square brackets. That is, the acceptable full formats
+        are <literal>111.222.333.444:9953%ifname#example.com</literal> for IPv4 and
+        <literal>[1111:2222::3333]:9953%ifname#example.com</literal> for IPv6. DNS requests are sent to one of the listed
+        DNS servers in parallel to suitable per-link DNS servers acquired from
+        <citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> or
+        set at runtime by external applications.  For compatibility reasons, if this setting is not specified, the DNS
+        servers listed in <filename>/etc/resolv.conf</filename> are used instead, if that file exists and any servers
+        are configured in it. This setting defaults to the empty list.</para>
+
+        <xi:include href="version-info.xml" xpointer="v213"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>FallbackDNS=</varname></term>
+        <listitem><para>A space-separated list of IPv4 and IPv6 addresses to use as the fallback DNS servers. Please see
+        <varname>DNS=</varname> for acceptable format of addresses. Any per-link DNS servers obtained from
+        <citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        take precedence over this setting, as do any servers set via <varname>DNS=</varname> above or
+        <filename>/etc/resolv.conf</filename>. This setting is hence only used if no other DNS server information is
+        known. If this option is not given, a compiled-in list of DNS servers is used instead.</para>
+
+        <xi:include href="version-info.xml" xpointer="v216"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Domains=</varname></term>
+        <listitem><para>A space-separated list of domains, optionally prefixed with <literal>~</literal>,
+        used for two distinct purposes described below. Defaults to the empty list.</para>
+
+        <para>Any domains <emphasis>not</emphasis> prefixed with <literal>~</literal> are used as search
+        suffixes when resolving single-label hostnames (domain names which contain no dot), in order to
+        qualify them into fully-qualified domain names (FQDNs). These "search domains" are strictly processed
+        in the order they are specified in, until the name with the suffix appended is found. For
+        compatibility reasons, if this setting is not specified, the search domains listed in
+        <filename>/etc/resolv.conf</filename> with the <varname>search</varname> keyword are used instead, if
+        that file exists and any domains are configured in it.</para>
+
+        <para>The domains prefixed with <literal>~</literal> are called "route-only domains". All domains
+        listed here (<emphasis>both search domains and route-only domains</emphasis> after removing the
+        <literal>~</literal> prefix) define a search path that preferably directs DNS queries to this
+        interface. This search path has an effect only when suitable per-link DNS servers are known. Such
+        servers may be defined through the <varname>DNS=</varname> setting (see above) and dynamically at run
+        time, for example from DHCP leases. If no per-link DNS servers are known, route-only domains have no
+        effect.</para>
+
+        <para>Use the construct <literal>~.</literal> (which is composed from <literal>~</literal> to
+        indicate a route-only domain and <literal>.</literal> to indicate the DNS root domain that is the
+        implied suffix of all DNS domains) to use the DNS servers defined for this link preferably for all
+        domains.</para>
+
+        <para>See "Protocols and Routing" in
+        <citerefentry><refentrytitle>systemd-resolved.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        for details of how search and route-only domains are used.</para>
+
+        <para>Note that configuring the MulticastDNS domain <literal>local</literal> as search or routing
+        domain has the effect of routing lookups for this domain to classic unicast DNS. This may be used to
+        provide compatibility with legacy installations that use this domain in a unicast DNS context,
+        against the IANA assignment of this domain to pure MulticastDNS purposes. Search and routing domains
+        are a unicast DNS concept, they <emphasis>cannot</emphasis> be used to resolve single-label lookups
+        via MulticastDNS.</para>
+
+        <xi:include href="version-info.xml" xpointer="v229"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>LLMNR=</varname></term>
+        <listitem><para>Takes a boolean argument or
+        <literal>resolve</literal>. Controls Link-Local Multicast Name
+        Resolution support (<ulink
+        url="https://tools.ietf.org/html/rfc4795">RFC 4795</ulink>) on
+        the local host. If true, enables full LLMNR responder and
+        resolver support. If false, disables both. If set to
+        <literal>resolve</literal>, only resolution support is enabled,
+        but responding is disabled. Note that
+        <citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        also maintains per-link LLMNR settings. LLMNR will be
+        enabled on a link only if the per-link and the
+        global setting is on.</para>
+
+        <xi:include href="version-info.xml" xpointer="v216"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>MulticastDNS=</varname></term>
+        <listitem><para>Takes a boolean argument or
+        <literal>resolve</literal>. Controls Multicast DNS support (<ulink
+        url="https://tools.ietf.org/html/rfc6762">RFC 6762</ulink>) on
+        the local host. If true, enables full Multicast DNS responder and
+        resolver support. If false, disables both. If set to
+        <literal>resolve</literal>, only resolution support is enabled,
+        but responding is disabled. Note that
+        <citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        also maintains per-link Multicast DNS settings. Multicast DNS will be
+        enabled on a link only if the per-link and the
+        global setting is on.</para>
+
+        <xi:include href="version-info.xml" xpointer="v234"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>DNSSEC=</varname></term>
+        <listitem><para>Takes a boolean argument or <literal>allow-downgrade</literal>.</para>
+
+        <para>If set to true, all DNS lookups are DNSSEC-validated locally (excluding LLMNR and Multicast
+        DNS). If the response to a lookup request is detected to be invalid a lookup failure is returned to
+        applications. Note that this mode requires a DNS server that supports DNSSEC. If the DNS server does
+        not properly support DNSSEC all validations will fail.</para>
+
+        <para>If set to <literal>allow-downgrade</literal>, DNSSEC validation is attempted, but if the server
+        does not support DNSSEC properly, DNSSEC mode is automatically disabled. Note that this mode makes
+        DNSSEC validation vulnerable to "downgrade" attacks, where an attacker might be able to trigger a
+        downgrade to non-DNSSEC mode by synthesizing a DNS response that suggests DNSSEC was not
+        supported.</para>
+
+        <para>If set to false, DNS lookups are not DNSSEC validated. In this mode, or when set to
+        <literal>allow-downgrade</literal> and the downgrade has happened, the resolver becomes
+        security-unaware and all forwarded queries have DNSSEC OK (DO) bit unset.</para>
+
+        <para>Note that DNSSEC validation requires retrieval of additional DNS data, and thus results in a
+        small DNS lookup time penalty.</para>
+
+        <para>DNSSEC requires knowledge of "trust anchors" to prove
+        data integrity. The trust anchor for the Internet root domain
+        is built into the resolver, additional trust anchors may be
+        defined with
+        <citerefentry><refentrytitle>dnssec-trust-anchors.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+        Trust anchors may change at regular intervals, and old trust
+        anchors may be revoked. In such a case DNSSEC validation is
+        not possible until new trust anchors are configured locally or
+        the resolver software package is updated with the new root
+        trust anchor. In effect, when the built-in trust anchor is
+        revoked and <varname>DNSSEC=</varname> is true, all further
+        lookups will fail, as it cannot be proved anymore whether
+        lookups are correctly signed, or validly unsigned. If
+        <varname>DNSSEC=</varname> is set to
+        <literal>allow-downgrade</literal> the resolver will
+        automatically turn off DNSSEC validation in such a case.</para>
+
+        <para>Client programs looking up DNS data will be informed
+        whether lookups could be verified using DNSSEC, or whether the
+        returned data could not be verified (either because the data
+        was found unsigned in the DNS, or the DNS server did not
+        support DNSSEC or no appropriate trust anchors were known). In
+        the latter case it is assumed that client programs employ a
+        secondary scheme to validate the returned DNS data, should
+        this be required.</para>
+
+        <para>It is recommended to set <varname>DNSSEC=</varname> to
+        true on systems where it is known that the DNS server supports
+        DNSSEC correctly, and where software or trust anchor updates
+        happen regularly. On other systems it is recommended to set
+        <varname>DNSSEC=</varname> to
+        <literal>allow-downgrade</literal>.</para>
+
+        <para>In addition to this global DNSSEC setting
+        <citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        also maintains per-link DNSSEC settings. For system DNS
+        servers (see above), only the global DNSSEC setting is in
+        effect. For per-link DNS servers the per-link
+        setting is in effect, unless it is unset in which case the
+        global setting is used instead.</para>
+
+        <para>Site-private DNS zones generally conflict with DNSSEC
+        operation, unless a negative (if the private zone is not
+        signed) or positive (if the private zone is signed) trust
+        anchor is configured for them. If
+        <literal>allow-downgrade</literal> mode is selected, it is
+        attempted to detect site-private DNS zones using top-level
+        domains (TLDs) that are not known by the DNS root server. This
+        logic does not work in all private zone setups.</para>
+
+        <para>Defaults to <literal>&DEFAULT_DNSSEC_MODE;</literal>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v229"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>DNSOverTLS=</varname></term>
+        <listitem>
+        <para>Takes a boolean argument or <literal>opportunistic</literal>. If
+        true all connections to the server will be encrypted. Note that this
+        mode requires a DNS server that supports DNS-over-TLS and has a valid
+        certificate. If the hostname was specified in <varname>DNS=</varname>
+        by using the format <literal>address#server_name</literal> it
+        is used to validate its certificate and also to enable Server Name
+        Indication (SNI) when opening a TLS connection. Otherwise
+        the certificate is checked against the server's IP.
+        If the DNS server does not support DNS-over-TLS all DNS requests will fail.</para>
+
+        <para>When set to <literal>opportunistic</literal>
+        DNS request are attempted to send encrypted with DNS-over-TLS.
+        If the DNS server does not support TLS, DNS-over-TLS is disabled.
+        Note that this mode makes DNS-over-TLS vulnerable to "downgrade"
+        attacks, where an attacker might be able to trigger a downgrade
+        to non-encrypted mode by synthesizing a response that suggests
+        DNS-over-TLS was not supported. If set to false, DNS lookups
+        are send over UDP.</para>
+
+        <para>Note that DNS-over-TLS requires additional data to be
+        send for setting up an encrypted connection, and thus results
+        in a small DNS look-up time penalty.</para>
+
+        <para>Note that in <literal>opportunistic</literal> mode the
+        resolver is not capable of authenticating the server, so it is
+        vulnerable to "man-in-the-middle" attacks.</para>
+
+        <para>In addition to this global <varname>DNSOverTLS=</varname> setting
+        <citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        also maintains per-link <varname>DNSOverTLS=</varname> settings. For system DNS servers (see above), only the global
+        <varname>DNSOverTLS=</varname> setting is in effect. For per-link DNS servers the per-link setting is in effect, unless
+        it is unset in which case the global setting is used instead.</para>
+
+        <para>Defaults to <literal>&DEFAULT_DNS_OVER_TLS_MODE;</literal>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Cache=</varname></term>
+        <listitem><para>Takes a boolean or <literal>no-negative</literal> as argument. If
+        <literal>yes</literal> (the default), resolving a domain name which already got queried earlier will
+        return the previous result as long as it is still valid, and thus does not result in a new network
+        request. Be aware that turning off caching comes at a performance penalty, which is particularly high
+        when DNSSEC is used. If <literal>no-negative</literal>, only positive answers are cached.</para>
+
+        <para>Note that caching is turned off by default for host-local DNS servers.
+        See <varname>CacheFromLocalhost=</varname> for details.</para>
+
+        <xi:include href="version-info.xml" xpointer="v231"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>CacheFromLocalhost=</varname></term>
+        <listitem><para>Takes a boolean as argument. If <literal>no</literal> (the default), and response cames from
+        host-local IP address (such as 127.0.0.1 or ::1), the result wouldn't be cached in order to avoid
+        potential duplicate local caching.</para>
+
+        <xi:include href="version-info.xml" xpointer="v248"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>DNSStubListener=</varname></term>
+        <listitem><para>Takes a boolean argument or one of <literal>udp</literal> and
+        <literal>tcp</literal>. If <literal>udp</literal>, a DNS stub resolver will listen for UDP requests
+        on addresses 127.0.0.53 and 127.0.0.54, port 53. If <literal>tcp</literal>, the stub will listen for
+        TCP requests on the same addresses and port. If <literal>yes</literal> (the default), the stub listens
+        for both UDP and TCP requests. If <literal>no</literal>, the stub listener is disabled.</para>
+
+        <xi:include href="systemd-resolved.service.xml" xpointer="proxy-stub" />
+
+        <para>Note that the DNS stub listener is turned off implicitly when its listening address and port are already
+        in use.</para>
+
+        <xi:include href="version-info.xml" xpointer="v232"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>DNSStubListenerExtra=</varname></term>
+        <listitem><para>Takes an IPv4 or IPv6 address to listen on. The address may be optionally
+        prefixed with a protocol name (<literal>udp</literal> or <literal>tcp</literal>) separated with
+        <literal>:</literal>. If the protocol is not specified, the service will listen on both UDP and
+        TCP. It may be also optionally suffixed by a numeric port number with separator
+        <literal>:</literal>. When an IPv6 address is specified with a port number, then the address
+        must be in the square brackets. If the port is not specified, then the service uses port 53.
+        Note that this is independent of the primary DNS stub configured with
+        <varname>DNSStubListener=</varname>, and only configures <emphasis>additional</emphasis>
+        sockets to listen on. This option can be specified multiple times. If an empty string is
+        assigned, then the all previous assignments are cleared. Defaults to unset.</para>
+
+        <para>Examples:
+        <programlisting>DNSStubListenerExtra=192.168.10.10
+DNSStubListenerExtra=2001:db8:0:f102::10
+DNSStubListenerExtra=192.168.10.11:9953
+DNSStubListenerExtra=[2001:db8:0:f102::11]:9953
+DNSStubListenerExtra=tcp:192.168.10.12
+DNSStubListenerExtra=udp:2001:db8:0:f102::12
+DNSStubListenerExtra=tcp:192.168.10.13:9953
+DNSStubListenerExtra=udp:[2001:db8:0:f102::13]:9953</programlisting>
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v247"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ReadEtcHosts=</varname></term>
+        <listitem><para>Takes a boolean argument. If <literal>yes</literal> (the default),
+        <command>systemd-resolved</command> will read <filename>/etc/hosts</filename>, and try to resolve
+        hosts or address by using the entries in the file before sending query to DNS servers.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v240"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ResolveUnicastSingleLabel=</varname></term>
+        <listitem><para>Takes a boolean argument. When false (the default),
+        <command>systemd-resolved</command> will not resolve A and AAAA queries for single-label names over
+        classic DNS. Note that such names may still be resolved if search domains are specified (see
+        <varname>Domains=</varname> above), or using other mechanisms, in particular via LLMNR or from
+        <filename>/etc/hosts</filename>. When true, queries for single-label names will be forwarded to
+        global DNS servers even if no search domains are defined.
+        </para>
+
+        <para>This option is provided for compatibility with configurations where <emphasis>public DNS
+        servers are not used</emphasis>. Forwarding single-label names to servers not under your control is
+        not standard-conformant, see <ulink
+        url="https://www.iab.org/documents/correspondence-reports-documents/2013-2/iab-statement-dotless-domains-considered-harmful/">IAB
+        Statement</ulink>, and may create a privacy and security risk.</para>
+
+        <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+      </varlistentry>
+      <varlistentry>
+        <term>StaleRetentionSec=<replaceable>SECONDS</replaceable></term>
+        <listitem><para>Takes a duration value, which determines the length of time DNS resource records can
+        be retained in the cache beyond their Time To Live (TTL). This allows these records to be returned as
+        stale records. By default, this value is set to zero, meaning that DNS resource records are not
+        stored in the cache after their TTL expires.</para>
+
+        <para>This is useful when a DNS server failure occurs or becomes unreachable. In such cases,
+        <citerefentry><refentrytitle>systemd-resolved</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        continues to use the stale records to answer DNS queries, particularly when no valid response can be
+        obtained from the upstream DNS servers. However, this doesn't apply to NXDOMAIN responses, as those
+        are still perfectly valid responses. This feature enhances resilience against DNS infrastructure
+        failures and outages.</para>
+
+        <para><command>systemd-resolved</command> always attempts to reach the upstream DNS servers first,
+        before providing the client application with any stale data. If this feature is enabled, cache will
+        not be flushed when changing servers.</para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+      <title>See Also</title>
+      <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-resolved.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>dnssec-trust-anchors.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>resolv.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+      </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/rules/meson.build b/man/rules/meson.build
new file mode 100644
index 0000000..5dc3e08
--- /dev/null
+++ b/man/rules/meson.build
@@ -0,0 +1,1270 @@
+# SPDX-License-Identifier: LGPL-2.1-or-later
+
+# Do not edit. Generated by update-man-rules.py.
+# Update with:
+#     ninja -C build update-man-rules
+manpages = [
+['binfmt.d', '5', [], 'ENABLE_BINFMT'],
+ ['bootctl', '1', [], 'ENABLE_BOOTLOADER'],
+ ['bootup', '7', [], ''],
+ ['busctl', '1', [], ''],
+ ['coredump.conf', '5', ['coredump.conf.d'], 'ENABLE_COREDUMP'],
+ ['coredumpctl', '1', [], 'ENABLE_COREDUMP'],
+ ['crypttab', '5', [], 'HAVE_LIBCRYPTSETUP'],
+ ['daemon', '7', [], ''],
+ ['dnssec-trust-anchors.d',
+  '5',
+  ['systemd.negative', 'systemd.positive'],
+  'ENABLE_RESOLVE'],
+ ['environment.d', '5', [], 'ENABLE_ENVIRONMENT_D'],
+ ['file-hierarchy', '7', [], ''],
+ ['homectl', '1', [], 'ENABLE_HOMED'],
+ ['homed.conf', '5', ['homed.conf.d'], 'ENABLE_HOMED'],
+ ['hostname', '5', [], ''],
+ ['hostnamectl', '1', [], 'ENABLE_HOSTNAMED'],
+ ['hwdb', '7', [], 'ENABLE_HWDB'],
+ ['integritytab', '5', [], 'HAVE_LIBCRYPTSETUP'],
+ ['iocost.conf', '5', [], ''],
+ ['journal-remote.conf', '5', ['journal-remote.conf.d'], 'HAVE_MICROHTTPD'],
+ ['journal-upload.conf', '5', ['journal-upload.conf.d'], 'HAVE_MICROHTTPD'],
+ ['journalctl', '1', [], ''],
+ ['journald.conf', '5', ['journald.conf.d', 'journald@.conf'], ''],
+ ['kernel-command-line', '7', [], ''],
+ ['kernel-install', '8', [], 'ENABLE_KERNEL_INSTALL'],
+ ['libsystemd', '3', [], ''],
+ ['libudev', '3', [], ''],
+ ['loader.conf', '5', [], 'ENABLE_BOOTLOADER'],
+ ['locale.conf', '5', [], ''],
+ ['localectl', '1', [], 'ENABLE_LOCALED'],
+ ['localtime', '5', [], ''],
+ ['loginctl', '1', [], 'ENABLE_LOGIND'],
+ ['logind.conf', '5', ['logind.conf.d'], 'ENABLE_LOGIND'],
+ ['machine-id', '5', [], ''],
+ ['machine-info', '5', [], ''],
+ ['machinectl', '1', [], 'ENABLE_MACHINED'],
+ ['modules-load.d', '5', [], 'HAVE_KMOD'],
+ ['networkctl', '1', [], 'ENABLE_NETWORKD'],
+ ['networkd.conf', '5', ['networkd.conf.d'], 'ENABLE_NETWORKD'],
+ ['nss-myhostname', '8', ['libnss_myhostname.so.2'], 'ENABLE_NSS_MYHOSTNAME'],
+ ['nss-mymachines', '8', ['libnss_mymachines.so.2'], 'ENABLE_NSS_MYMACHINES'],
+ ['nss-resolve', '8', ['libnss_resolve.so.2'], 'ENABLE_NSS_RESOLVE'],
+ ['nss-systemd', '8', ['libnss_systemd.so.2'], 'ENABLE_NSS_SYSTEMD'],
+ ['oomctl', '1', [], 'ENABLE_OOMD'],
+ ['oomd.conf', '5', ['oomd.conf.d'], 'ENABLE_OOMD'],
+ ['org.freedesktop.LogControl1', '5', [], ''],
+ ['org.freedesktop.home1', '5', [], 'ENABLE_HOMED'],
+ ['org.freedesktop.hostname1', '5', [], 'ENABLE_HOSTNAMED'],
+ ['org.freedesktop.import1', '5', [], 'ENABLE_IMPORTD'],
+ ['org.freedesktop.locale1', '5', [], 'ENABLE_LOCALED'],
+ ['org.freedesktop.login1', '5', [], 'ENABLE_LOGIND'],
+ ['org.freedesktop.machine1', '5', [], 'ENABLE_MACHINED'],
+ ['org.freedesktop.network1', '5', [], 'ENABLE_NETWORKD'],
+ ['org.freedesktop.oom1', '5', [], 'ENABLE_OOMD'],
+ ['org.freedesktop.portable1', '5', [], 'ENABLE_PORTABLED'],
+ ['org.freedesktop.resolve1', '5', [], 'ENABLE_RESOLVE'],
+ ['org.freedesktop.systemd1', '5', [], ''],
+ ['org.freedesktop.timedate1', '5', [], 'ENABLE_TIMEDATED'],
+ ['os-release', '5', ['extension-release', 'initrd-release'], ''],
+ ['pam_systemd', '8', [], 'HAVE_PAM'],
+ ['pam_systemd_home', '8', [], 'ENABLE_PAM_HOME'],
+ ['pam_systemd_loadkey', '8', [], 'HAVE_PAM'],
+ ['portablectl', '1', [], 'ENABLE_PORTABLED'],
+ ['poweroff', '8', ['halt', 'reboot'], ''],
+ ['pstore.conf', '5', ['pstore.conf.d'], 'ENABLE_PSTORE'],
+ ['repart.d', '5', [], 'ENABLE_REPART'],
+ ['resolvectl', '1', ['resolvconf'], 'ENABLE_RESOLVE'],
+ ['resolved.conf', '5', ['resolved.conf.d'], 'ENABLE_RESOLVE'],
+ ['runlevel', '8', [], 'HAVE_SYSV_COMPAT'],
+ ['sd-bus-errors',
+  '3',
+  ['SD_BUS_ERROR_ACCESS_DENIED',
+   'SD_BUS_ERROR_ADDRESS_IN_USE',
+   'SD_BUS_ERROR_AUTH_FAILED',
+   'SD_BUS_ERROR_BAD_ADDRESS',
+   'SD_BUS_ERROR_DISCONNECTED',
+   'SD_BUS_ERROR_FAILED',
+   'SD_BUS_ERROR_FILE_EXISTS',
+   'SD_BUS_ERROR_FILE_NOT_FOUND',
+   'SD_BUS_ERROR_INCONSISTENT_MESSAGE',
+   'SD_BUS_ERROR_INTERACTIVE_AUTHORIZATION_REQUIRED',
+   'SD_BUS_ERROR_INVALID_ARGS',
+   'SD_BUS_ERROR_INVALID_FILE_CONTENT',
+   'SD_BUS_ERROR_INVALID_SIGNATURE',
+   'SD_BUS_ERROR_IO_ERROR',
+   'SD_BUS_ERROR_LIMITS_EXCEEDED',
+   'SD_BUS_ERROR_MATCH_RULE_INVALID',
+   'SD_BUS_ERROR_MATCH_RULE_NOT_FOUND',
+   'SD_BUS_ERROR_NAME_HAS_NO_OWNER',
+   'SD_BUS_ERROR_NOT_SUPPORTED',
+   'SD_BUS_ERROR_NO_MEMORY',
+   'SD_BUS_ERROR_NO_NETWORK',
+   'SD_BUS_ERROR_NO_REPLY',
+   'SD_BUS_ERROR_NO_SERVER',
+   'SD_BUS_ERROR_OBJECT_PATH_IN_USE',
+   'SD_BUS_ERROR_PROPERTY_READ_ONLY',
+   'SD_BUS_ERROR_SELINUX_SECURITY_CONTEXT_UNKNOWN',
+   'SD_BUS_ERROR_SERVICE_UNKNOWN',
+   'SD_BUS_ERROR_TIMED_OUT',
+   'SD_BUS_ERROR_TIMEOUT',
+   'SD_BUS_ERROR_UNIX_PROCESS_ID_UNKNOWN',
+   'SD_BUS_ERROR_UNKNOWN_INTERFACE',
+   'SD_BUS_ERROR_UNKNOWN_METHOD',
+   'SD_BUS_ERROR_UNKNOWN_OBJECT',
+   'SD_BUS_ERROR_UNKNOWN_PROPERTY'],
+  ''],
+ ['sd-bus', '3', [], ''],
+ ['sd-daemon',
+  '3',
+  ['SD_ALERT',
+   'SD_CRIT',
+   'SD_DEBUG',
+   'SD_EMERG',
+   'SD_ERR',
+   'SD_INFO',
+   'SD_NOTICE',
+   'SD_WARNING'],
+  ''],
+ ['sd-device', '3', [], ''],
+ ['sd-event', '3', [], ''],
+ ['sd-hwdb', '3', [], ''],
+ ['sd-id128',
+  '3',
+  ['SD_ID128_ALLF',
+   'SD_ID128_CONST_STR',
+   'SD_ID128_FORMAT_STR',
+   'SD_ID128_FORMAT_VAL',
+   'SD_ID128_MAKE',
+   'SD_ID128_MAKE_STR',
+   'SD_ID128_MAKE_UUID_STR',
+   'SD_ID128_NULL',
+   'SD_ID128_UUID_FORMAT_STR',
+   'sd_id128_equal',
+   'sd_id128_in_set',
+   'sd_id128_in_set_sentinel',
+   'sd_id128_in_setv',
+   'sd_id128_is_allf',
+   'sd_id128_is_null',
+   'sd_id128_string_equal',
+   'sd_id128_t'],
+  ''],
+ ['sd-journal', '3', [], ''],
+ ['sd-login', '3', [], 'HAVE_PAM'],
+ ['sd_booted', '3', [], ''],
+ ['sd_bus_add_match',
+  '3',
+  ['sd_bus_add_match_async',
+   'sd_bus_match_signal',
+   'sd_bus_match_signal_async'],
+  ''],
+ ['sd_bus_add_node_enumerator', '3', [], ''],
+ ['sd_bus_add_object',
+  '3',
+  ['SD_BUS_METHOD',
+   'SD_BUS_METHOD_WITH_NAMES',
+   'SD_BUS_METHOD_WITH_NAMES_OFFSET',
+   'SD_BUS_METHOD_WITH_OFFSET',
+   'SD_BUS_PARAM',
+   'SD_BUS_PROPERTY',
+   'SD_BUS_SIGNAL',
+   'SD_BUS_SIGNAL_WITH_NAMES',
+   'SD_BUS_VTABLE_CAPABILITY',
+   'SD_BUS_VTABLE_END',
+   'SD_BUS_VTABLE_START',
+   'SD_BUS_WRITABLE_PROPERTY',
+   'sd_bus_add_fallback',
+   'sd_bus_add_fallback_vtable',
+   'sd_bus_add_filter',
+   'sd_bus_add_object_vtable'],
+  ''],
+ ['sd_bus_add_object_manager', '3', [], ''],
+ ['sd_bus_attach_event', '3', ['sd_bus_detach_event', 'sd_bus_get_event'], ''],
+ ['sd_bus_call', '3', ['sd_bus_call_async'], ''],
+ ['sd_bus_call_method',
+  '3',
+  ['sd_bus_call_method_async',
+   'sd_bus_call_method_asyncv',
+   'sd_bus_call_methodv'],
+  ''],
+ ['sd_bus_can_send', '3', [], ''],
+ ['sd_bus_close', '3', ['sd_bus_default_flush_close', 'sd_bus_flush'], ''],
+ ['sd_bus_creds_get_pid',
+  '3',
+  ['sd_bus_creds_get_audit_login_uid',
+   'sd_bus_creds_get_audit_session_id',
+   'sd_bus_creds_get_cgroup',
+   'sd_bus_creds_get_cmdline',
+   'sd_bus_creds_get_comm',
+   'sd_bus_creds_get_description',
+   'sd_bus_creds_get_egid',
+   'sd_bus_creds_get_euid',
+   'sd_bus_creds_get_exe',
+   'sd_bus_creds_get_fsgid',
+   'sd_bus_creds_get_fsuid',
+   'sd_bus_creds_get_gid',
+   'sd_bus_creds_get_owner_uid',
+   'sd_bus_creds_get_ppid',
+   'sd_bus_creds_get_selinux_context',
+   'sd_bus_creds_get_session',
+   'sd_bus_creds_get_sgid',
+   'sd_bus_creds_get_slice',
+   'sd_bus_creds_get_suid',
+   'sd_bus_creds_get_supplementary_gids',
+   'sd_bus_creds_get_tid',
+   'sd_bus_creds_get_tid_comm',
+   'sd_bus_creds_get_tty',
+   'sd_bus_creds_get_uid',
+   'sd_bus_creds_get_unique_name',
+   'sd_bus_creds_get_unit',
+   'sd_bus_creds_get_user_slice',
+   'sd_bus_creds_get_user_unit',
+   'sd_bus_creds_get_well_known_names',
+   'sd_bus_creds_has_bounding_cap',
+   'sd_bus_creds_has_effective_cap',
+   'sd_bus_creds_has_inheritable_cap',
+   'sd_bus_creds_has_permitted_cap'],
+  ''],
+ ['sd_bus_creds_new_from_pid',
+  '3',
+  ['sd_bus_creds_get_augmented_mask',
+   'sd_bus_creds_get_mask',
+   'sd_bus_creds_ref',
+   'sd_bus_creds_unref',
+   'sd_bus_creds_unrefp'],
+  ''],
+ ['sd_bus_default',
+  '3',
+  ['sd_bus_default_system',
+   'sd_bus_default_user',
+   'sd_bus_open',
+   'sd_bus_open_system',
+   'sd_bus_open_system_machine',
+   'sd_bus_open_system_remote',
+   'sd_bus_open_system_with_description',
+   'sd_bus_open_user',
+   'sd_bus_open_user_machine',
+   'sd_bus_open_user_with_description',
+   'sd_bus_open_with_description'],
+  ''],
+ ['sd_bus_emit_signal',
+  '3',
+  ['sd_bus_emit_interfaces_added',
+   'sd_bus_emit_interfaces_added_strv',
+   'sd_bus_emit_interfaces_removed',
+   'sd_bus_emit_interfaces_removed_strv',
+   'sd_bus_emit_object_added',
+   'sd_bus_emit_object_removed',
+   'sd_bus_emit_properties_changed',
+   'sd_bus_emit_properties_changed_strv',
+   'sd_bus_emit_signal_to',
+   'sd_bus_emit_signal_tov',
+   'sd_bus_emit_signalv'],
+  ''],
+ ['sd_bus_enqueue_for_read', '3', [], ''],
+ ['sd_bus_error',
+  '3',
+  ['SD_BUS_ERROR_MAKE_CONST',
+   'SD_BUS_ERROR_NULL',
+   'sd_bus_error_copy',
+   'sd_bus_error_free',
+   'sd_bus_error_get_errno',
+   'sd_bus_error_has_name',
+   'sd_bus_error_has_names',
+   'sd_bus_error_has_names_sentinel',
+   'sd_bus_error_is_set',
+   'sd_bus_error_move',
+   'sd_bus_error_set',
+   'sd_bus_error_set_const',
+   'sd_bus_error_set_errno',
+   'sd_bus_error_set_errnof',
+   'sd_bus_error_set_errnofv',
+   'sd_bus_error_setf',
+   'sd_bus_error_setfv'],
+  ''],
+ ['sd_bus_error_add_map',
+  '3',
+  ['SD_BUS_ERROR_END', 'SD_BUS_ERROR_MAP', 'sd_bus_error_map'],
+  ''],
+ ['sd_bus_get_current_handler',
+  '3',
+  ['sd_bus_get_current_message',
+   'sd_bus_get_current_slot',
+   'sd_bus_get_current_userdata'],
+  ''],
+ ['sd_bus_get_fd', '3', ['sd_bus_get_events', 'sd_bus_get_timeout'], ''],
+ ['sd_bus_get_n_queued_read', '3', ['sd_bus_get_n_queued_write'], ''],
+ ['sd_bus_get_name_creds', '3', ['sd_bus_get_owner_creds'], ''],
+ ['sd_bus_get_name_machine_id', '3', [], ''],
+ ['sd_bus_interface_name_is_valid',
+  '3',
+  ['sd_bus_member_name_is_valid',
+   'sd_bus_object_path_is_valid',
+   'sd_bus_service_name_is_valid'],
+  ''],
+ ['sd_bus_is_open', '3', ['sd_bus_is_ready'], ''],
+ ['sd_bus_list_names', '3', [], ''],
+ ['sd_bus_message_append', '3', ['sd_bus_message_appendv'], ''],
+ ['sd_bus_message_append_array',
+  '3',
+  ['sd_bus_message_append_array_iovec',
+   'sd_bus_message_append_array_memfd',
+   'sd_bus_message_append_array_space'],
+  ''],
+ ['sd_bus_message_append_basic', '3', [], ''],
+ ['sd_bus_message_append_string_memfd',
+  '3',
+  ['sd_bus_message_append_string_iovec', 'sd_bus_message_append_string_space'],
+  ''],
+ ['sd_bus_message_append_strv', '3', [], ''],
+ ['sd_bus_message_at_end', '3', [], ''],
+ ['sd_bus_message_copy', '3', [], ''],
+ ['sd_bus_message_dump', '3', [], ''],
+ ['sd_bus_message_get_cookie', '3', ['sd_bus_message_get_reply_cookie'], ''],
+ ['sd_bus_message_get_monotonic_usec',
+  '3',
+  ['sd_bus_message_get_realtime_usec', 'sd_bus_message_get_seqnum'],
+  ''],
+ ['sd_bus_message_get_signature',
+  '3',
+  ['sd_bus_message_has_signature', 'sd_bus_message_is_empty'],
+  ''],
+ ['sd_bus_message_get_type',
+  '3',
+  ['sd_bus_message_get_creds',
+   'sd_bus_message_get_errno',
+   'sd_bus_message_get_error',
+   'sd_bus_message_is_method_call',
+   'sd_bus_message_is_method_error',
+   'sd_bus_message_is_signal'],
+  ''],
+ ['sd_bus_message_new',
+  '3',
+  ['SD_BUS_MESSAGE_METHOD_CALL',
+   'SD_BUS_MESSAGE_METHOD_ERROR',
+   'SD_BUS_MESSAGE_METHOD_RETURN',
+   'SD_BUS_MESSAGE_SIGNAL',
+   'sd_bus_message_get_bus',
+   'sd_bus_message_ref',
+   'sd_bus_message_unref',
+   'sd_bus_message_unrefp'],
+  ''],
+ ['sd_bus_message_new_method_call',
+  '3',
+  ['sd_bus_message_new_method_return'],
+  ''],
+ ['sd_bus_message_new_method_error',
+  '3',
+  ['sd_bus_message_new_method_errno',
+   'sd_bus_message_new_method_errnof',
+   'sd_bus_message_new_method_errorf'],
+  ''],
+ ['sd_bus_message_new_signal', '3', ['sd_bus_message_new_signal_to'], ''],
+ ['sd_bus_message_open_container',
+  '3',
+  ['sd_bus_message_close_container',
+   'sd_bus_message_enter_container',
+   'sd_bus_message_exit_container'],
+  ''],
+ ['sd_bus_message_read',
+  '3',
+  ['sd_bus_message_peek_type', 'sd_bus_message_readv'],
+  ''],
+ ['sd_bus_message_read_array', '3', [], ''],
+ ['sd_bus_message_read_basic', '3', [], ''],
+ ['sd_bus_message_read_strv', '3', ['sd_bus_message_read_strv_extend'], ''],
+ ['sd_bus_message_rewind', '3', [], ''],
+ ['sd_bus_message_seal', '3', [], ''],
+ ['sd_bus_message_sensitive', '3', [], ''],
+ ['sd_bus_message_set_destination',
+  '3',
+  ['sd_bus_message_get_destination',
+   'sd_bus_message_get_interface',
+   'sd_bus_message_get_member',
+   'sd_bus_message_get_path',
+   'sd_bus_message_get_sender',
+   'sd_bus_message_set_sender'],
+  ''],
+ ['sd_bus_message_set_expect_reply',
+  '3',
+  ['sd_bus_message_get_allow_interactive_authorization',
+   'sd_bus_message_get_auto_start',
+   'sd_bus_message_get_expect_reply',
+   'sd_bus_message_set_allow_interactive_authorization',
+   'sd_bus_message_set_auto_start'],
+  ''],
+ ['sd_bus_message_skip', '3', [], ''],
+ ['sd_bus_message_verify_type', '3', [], ''],
+ ['sd_bus_negotiate_fds',
+  '3',
+  ['sd_bus_get_creds_mask',
+   'sd_bus_negotiate_creds',
+   'sd_bus_negotiate_timestamp'],
+  ''],
+ ['sd_bus_new',
+  '3',
+  ['sd_bus_close_unref',
+   'sd_bus_close_unrefp',
+   'sd_bus_flush_close_unref',
+   'sd_bus_flush_close_unrefp',
+   'sd_bus_ref',
+   'sd_bus_unref',
+   'sd_bus_unrefp'],
+  ''],
+ ['sd_bus_path_encode',
+  '3',
+  ['sd_bus_path_decode', 'sd_bus_path_decode_many', 'sd_bus_path_encode_many'],
+  ''],
+ ['sd_bus_process', '3', [], ''],
+ ['sd_bus_query_sender_creds', '3', ['sd_bus_query_sender_privilege'], ''],
+ ['sd_bus_reply_method_error',
+  '3',
+  ['sd_bus_reply_method_errno',
+   'sd_bus_reply_method_errnof',
+   'sd_bus_reply_method_errnofv',
+   'sd_bus_reply_method_errorf',
+   'sd_bus_reply_method_errorfv'],
+  ''],
+ ['sd_bus_reply_method_return', '3', ['sd_bus_reply_method_returnv'], ''],
+ ['sd_bus_request_name',
+  '3',
+  ['sd_bus_release_name',
+   'sd_bus_release_name_async',
+   'sd_bus_request_name_async'],
+  ''],
+ ['sd_bus_send', '3', ['sd_bus_message_send', 'sd_bus_send_to'], ''],
+ ['sd_bus_set_address', '3', ['sd_bus_get_address', 'sd_bus_set_exec'], ''],
+ ['sd_bus_set_close_on_exit', '3', ['sd_bus_get_close_on_exit'], ''],
+ ['sd_bus_set_connected_signal', '3', ['sd_bus_get_connected_signal'], ''],
+ ['sd_bus_set_description',
+  '3',
+  ['sd_bus_get_allow_interactive_authorization',
+   'sd_bus_get_description',
+   'sd_bus_get_scope',
+   'sd_bus_get_tid',
+   'sd_bus_get_unique_name',
+   'sd_bus_is_anonymous',
+   'sd_bus_is_trusted',
+   'sd_bus_set_allow_interactive_authorization',
+   'sd_bus_set_anonymous',
+   'sd_bus_set_trusted'],
+  ''],
+ ['sd_bus_set_exit_on_disconnect', '3', ['sd_bus_get_exit_on_disconnect'], ''],
+ ['sd_bus_set_fd', '3', [], ''],
+ ['sd_bus_set_method_call_timeout',
+  '3',
+  ['sd_bus_get_method_call_timeout'],
+  ''],
+ ['sd_bus_set_property',
+  '3',
+  ['sd_bus_get_property',
+   'sd_bus_get_property_string',
+   'sd_bus_get_property_strv',
+   'sd_bus_get_property_trivial',
+   'sd_bus_set_propertyv'],
+  ''],
+ ['sd_bus_set_sender', '3', ['sd_bus_get_sender'], ''],
+ ['sd_bus_set_server',
+  '3',
+  ['sd_bus_get_bus_id',
+   'sd_bus_is_bus_client',
+   'sd_bus_is_monitor',
+   'sd_bus_is_server',
+   'sd_bus_set_bus_client',
+   'sd_bus_set_monitor'],
+  ''],
+ ['sd_bus_set_watch_bind', '3', ['sd_bus_get_watch_bind'], ''],
+ ['sd_bus_slot_get_bus',
+  '3',
+  ['sd_bus_slot_get_current_handler',
+   'sd_bus_slot_get_current_message',
+   'sd_bus_slot_get_current_userdata'],
+  ''],
+ ['sd_bus_slot_ref', '3', ['sd_bus_slot_unref', 'sd_bus_slot_unrefp'], ''],
+ ['sd_bus_slot_set_description', '3', ['sd_bus_slot_get_description'], ''],
+ ['sd_bus_slot_set_destroy_callback',
+  '3',
+  ['sd_bus_destroy_t',
+   'sd_bus_slot_get_destroy_callback',
+   'sd_bus_track_get_destroy_callback',
+   'sd_bus_track_set_destroy_callback'],
+  ''],
+ ['sd_bus_slot_set_floating', '3', ['sd_bus_slot_get_floating'], ''],
+ ['sd_bus_slot_set_userdata', '3', ['sd_bus_slot_get_userdata'], ''],
+ ['sd_bus_start', '3', [], ''],
+ ['sd_bus_track_add_name',
+  '3',
+  ['sd_bus_track_add_sender',
+   'sd_bus_track_contains',
+   'sd_bus_track_count',
+   'sd_bus_track_count_name',
+   'sd_bus_track_count_sender',
+   'sd_bus_track_first',
+   'sd_bus_track_next',
+   'sd_bus_track_remove_name',
+   'sd_bus_track_remove_sender'],
+  ''],
+ ['sd_bus_track_new',
+  '3',
+  ['sd_bus_track_get_bus',
+   'sd_bus_track_get_recursive',
+   'sd_bus_track_get_userdata',
+   'sd_bus_track_ref',
+   'sd_bus_track_set_recursive',
+   'sd_bus_track_set_userdata',
+   'sd_bus_track_unref',
+   'sd_bus_track_unrefp'],
+  ''],
+ ['sd_bus_wait', '3', [], ''],
+ ['sd_device_get_syspath',
+  '3',
+  ['sd_device_get_devname',
+   'sd_device_get_devnum',
+   'sd_device_get_devpath',
+   'sd_device_get_devtype',
+   'sd_device_get_diskseq',
+   'sd_device_get_driver',
+   'sd_device_get_ifindex',
+   'sd_device_get_subsystem',
+   'sd_device_get_sysname',
+   'sd_device_get_sysnum'],
+  ''],
+ ['sd_device_ref', '3', ['sd_device_unref', 'sd_device_unrefp'], ''],
+ ['sd_event_add_child',
+  '3',
+  ['sd_event_add_child_pidfd',
+   'sd_event_child_handler_t',
+   'sd_event_source_get_child_pid',
+   'sd_event_source_get_child_pidfd',
+   'sd_event_source_get_child_pidfd_own',
+   'sd_event_source_get_child_process_own',
+   'sd_event_source_send_child_signal',
+   'sd_event_source_set_child_pidfd_own',
+   'sd_event_source_set_child_process_own'],
+  ''],
+ ['sd_event_add_defer',
+  '3',
+  ['sd_event_add_exit', 'sd_event_add_post', 'sd_event_handler_t'],
+  ''],
+ ['sd_event_add_inotify',
+  '3',
+  ['sd_event_add_inotify_fd',
+   'sd_event_inotify_handler_t',
+   'sd_event_source_get_inotify_mask'],
+  ''],
+ ['sd_event_add_io',
+  '3',
+  ['sd_event_io_handler_t',
+   'sd_event_source',
+   'sd_event_source_get_io_events',
+   'sd_event_source_get_io_fd',
+   'sd_event_source_get_io_fd_own',
+   'sd_event_source_get_io_revents',
+   'sd_event_source_set_io_events',
+   'sd_event_source_set_io_fd',
+   'sd_event_source_set_io_fd_own'],
+  ''],
+ ['sd_event_add_memory_pressure',
+  '3',
+  ['sd_event_source_set_memory_pressure_period',
+   'sd_event_source_set_memory_pressure_type',
+   'sd_event_trim_memory'],
+  ''],
+ ['sd_event_add_signal',
+  '3',
+  ['SD_EVENT_SIGNAL_PROCMASK',
+   'sd_event_signal_handler_t',
+   'sd_event_source_get_signal'],
+  ''],
+ ['sd_event_add_time',
+  '3',
+  ['sd_event_add_time_relative',
+   'sd_event_source_get_time',
+   'sd_event_source_get_time_accuracy',
+   'sd_event_source_get_time_clock',
+   'sd_event_source_set_time',
+   'sd_event_source_set_time_accuracy',
+   'sd_event_source_set_time_relative',
+   'sd_event_time_handler_t'],
+  ''],
+ ['sd_event_exit', '3', ['sd_event_get_exit_code'], ''],
+ ['sd_event_get_fd', '3', [], ''],
+ ['sd_event_new',
+  '3',
+  ['sd_event',
+   'sd_event_default',
+   'sd_event_get_tid',
+   'sd_event_ref',
+   'sd_event_unref',
+   'sd_event_unrefp'],
+  ''],
+ ['sd_event_now', '3', [], ''],
+ ['sd_event_run', '3', ['sd_event_loop'], ''],
+ ['sd_event_set_signal_exit', '3', [], ''],
+ ['sd_event_set_watchdog', '3', ['sd_event_get_watchdog'], ''],
+ ['sd_event_source_get_event', '3', [], ''],
+ ['sd_event_source_get_pending', '3', [], ''],
+ ['sd_event_source_set_description',
+  '3',
+  ['sd_event_source_get_description'],
+  ''],
+ ['sd_event_source_set_destroy_callback',
+  '3',
+  ['sd_event_destroy_t', 'sd_event_source_get_destroy_callback'],
+  ''],
+ ['sd_event_source_set_enabled',
+  '3',
+  ['SD_EVENT_OFF',
+   'SD_EVENT_ON',
+   'SD_EVENT_ONESHOT',
+   'sd_event_source_get_enabled'],
+  ''],
+ ['sd_event_source_set_exit_on_failure',
+  '3',
+  ['sd_event_source_get_exit_on_failure'],
+  ''],
+ ['sd_event_source_set_floating', '3', ['sd_event_source_get_floating'], ''],
+ ['sd_event_source_set_prepare', '3', [], ''],
+ ['sd_event_source_set_priority',
+  '3',
+  ['SD_EVENT_PRIORITY_IDLE',
+   'SD_EVENT_PRIORITY_IMPORTANT',
+   'SD_EVENT_PRIORITY_NORMAL',
+   'sd_event_source_get_priority'],
+  ''],
+ ['sd_event_source_set_ratelimit',
+  '3',
+  ['sd_event_source_get_ratelimit',
+   'sd_event_source_is_ratelimited',
+   'sd_event_source_leave_ratelimit',
+   'sd_event_source_set_ratelimit_expire_callback'],
+  ''],
+ ['sd_event_source_set_userdata', '3', ['sd_event_source_get_userdata'], ''],
+ ['sd_event_source_unref',
+  '3',
+  ['sd_event_source_disable_unref',
+   'sd_event_source_disable_unrefp',
+   'sd_event_source_ref',
+   'sd_event_source_unrefp'],
+  ''],
+ ['sd_event_wait',
+  '3',
+  ['SD_EVENT_ARMED',
+   'SD_EVENT_EXITING',
+   'SD_EVENT_FINISHED',
+   'SD_EVENT_INITIAL',
+   'SD_EVENT_PENDING',
+   'SD_EVENT_PREPARING',
+   'SD_EVENT_RUNNING',
+   'sd_event_dispatch',
+   'sd_event_get_iteration',
+   'sd_event_get_state',
+   'sd_event_prepare'],
+  ''],
+ ['sd_get_seats',
+  '3',
+  ['sd_get_machine_names', 'sd_get_sessions', 'sd_get_uids'],
+  'HAVE_PAM'],
+ ['sd_hwdb_get',
+  '3',
+  ['SD_HWDB_FOREACH_PROPERTY', 'sd_hwdb_enumerate', 'sd_hwdb_seek'],
+  ''],
+ ['sd_hwdb_new',
+  '3',
+  ['sd_hwdb_new_from_path', 'sd_hwdb_ref', 'sd_hwdb_unref'],
+  ''],
+ ['sd_id128_get_machine',
+  '3',
+  ['sd_id128_get_app_specific',
+   'sd_id128_get_boot',
+   'sd_id128_get_boot_app_specific',
+   'sd_id128_get_invocation',
+   'sd_id128_get_machine_app_specific'],
+  ''],
+ ['sd_id128_randomize', '3', [], ''],
+ ['sd_id128_to_string',
+  '3',
+  ['SD_ID128_STRING_MAX',
+   'SD_ID128_TO_STRING',
+   'SD_ID128_TO_UUID_STRING',
+   'SD_ID128_UUID_STRING_MAX',
+   'sd_id128_from_string',
+   'sd_id128_to_uuid_string'],
+  ''],
+ ['sd_is_fifo',
+  '3',
+  ['sd_is_mq',
+   'sd_is_socket',
+   'sd_is_socket_inet',
+   'sd_is_socket_sockaddr',
+   'sd_is_socket_unix',
+   'sd_is_special'],
+  ''],
+ ['sd_journal_add_match',
+  '3',
+  ['sd_journal_add_conjunction',
+   'sd_journal_add_disjunction',
+   'sd_journal_flush_matches'],
+  ''],
+ ['sd_journal_enumerate_fields',
+  '3',
+  ['SD_JOURNAL_FOREACH_FIELD', 'sd_journal_restart_fields'],
+  ''],
+ ['sd_journal_get_catalog', '3', ['sd_journal_get_catalog_for_message_id'], ''],
+ ['sd_journal_get_cursor', '3', ['sd_journal_test_cursor'], ''],
+ ['sd_journal_get_cutoff_realtime_usec',
+  '3',
+  ['sd_journal_get_cutoff_monotonic_usec'],
+  ''],
+ ['sd_journal_get_data',
+  '3',
+  ['SD_JOURNAL_FOREACH_DATA',
+   'sd_journal_enumerate_available_data',
+   'sd_journal_enumerate_data',
+   'sd_journal_get_data_threshold',
+   'sd_journal_restart_data',
+   'sd_journal_set_data_threshold'],
+  ''],
+ ['sd_journal_get_fd',
+  '3',
+  ['SD_JOURNAL_APPEND',
+   'SD_JOURNAL_INVALIDATE',
+   'SD_JOURNAL_NOP',
+   'sd_journal_get_events',
+   'sd_journal_get_timeout',
+   'sd_journal_process',
+   'sd_journal_reliable_fd',
+   'sd_journal_wait'],
+  ''],
+ ['sd_journal_get_realtime_usec', '3', ['sd_journal_get_monotonic_usec'], ''],
+ ['sd_journal_get_seqnum', '3', [], ''],
+ ['sd_journal_get_usage', '3', [], ''],
+ ['sd_journal_has_runtime_files', '3', ['sd_journal_has_persistent_files'], ''],
+ ['sd_journal_next',
+  '3',
+  ['SD_JOURNAL_FOREACH',
+   'SD_JOURNAL_FOREACH_BACKWARDS',
+   'sd_journal_next_skip',
+   'sd_journal_previous',
+   'sd_journal_previous_skip',
+   'sd_journal_step_one'],
+  ''],
+ ['sd_journal_open',
+  '3',
+  ['SD_JOURNAL_ALL_NAMESPACES',
+   'SD_JOURNAL_CURRENT_USER',
+   'SD_JOURNAL_INCLUDE_DEFAULT_NAMESPACE',
+   'SD_JOURNAL_LOCAL_ONLY',
+   'SD_JOURNAL_OS_ROOT',
+   'SD_JOURNAL_RUNTIME_ONLY',
+   'SD_JOURNAL_SYSTEM',
+   'SD_JOURNAL_TAKE_DIRECTORY_FD',
+   'sd_journal',
+   'sd_journal_close',
+   'sd_journal_open_directory',
+   'sd_journal_open_directory_fd',
+   'sd_journal_open_files',
+   'sd_journal_open_files_fd',
+   'sd_journal_open_namespace'],
+  ''],
+ ['sd_journal_print',
+  '3',
+  ['SD_JOURNAL_SUPPRESS_LOCATION',
+   'sd_journal_perror',
+   'sd_journal_perror_with_location',
+   'sd_journal_print_with_location',
+   'sd_journal_printv',
+   'sd_journal_printv_with_location',
+   'sd_journal_send',
+   'sd_journal_send_with_location',
+   'sd_journal_sendv',
+   'sd_journal_sendv_with_location'],
+  ''],
+ ['sd_journal_query_unique',
+  '3',
+  ['SD_JOURNAL_FOREACH_UNIQUE',
+   'sd_journal_enumerate_available_unique',
+   'sd_journal_enumerate_unique',
+   'sd_journal_restart_unique'],
+  ''],
+ ['sd_journal_seek_head',
+  '3',
+  ['sd_journal_seek_cursor',
+   'sd_journal_seek_monotonic_usec',
+   'sd_journal_seek_realtime_usec',
+   'sd_journal_seek_tail'],
+  ''],
+ ['sd_journal_stream_fd', '3', [], ''],
+ ['sd_listen_fds',
+  '3',
+  ['SD_LISTEN_FDS_START', 'sd_listen_fds_with_names'],
+  ''],
+ ['sd_login_monitor_new',
+  '3',
+  ['sd_login_monitor',
+   'sd_login_monitor_flush',
+   'sd_login_monitor_get_events',
+   'sd_login_monitor_get_fd',
+   'sd_login_monitor_get_timeout',
+   'sd_login_monitor_unref',
+   'sd_login_monitor_unrefp'],
+  'HAVE_PAM'],
+ ['sd_machine_get_class', '3', ['sd_machine_get_ifindices'], ''],
+ ['sd_notify',
+  '3',
+  ['sd_notify_barrier',
+   'sd_notifyf',
+   'sd_pid_notify',
+   'sd_pid_notify_barrier',
+   'sd_pid_notify_with_fds',
+   'sd_pid_notifyf',
+   'sd_pid_notifyf_with_fds'],
+  ''],
+ ['sd_path_lookup', '3', ['sd_path_lookup_strv'], ''],
+ ['sd_pid_get_owner_uid',
+  '3',
+  ['sd_peer_get_cgroup',
+   'sd_peer_get_machine_name',
+   'sd_peer_get_owner_uid',
+   'sd_peer_get_session',
+   'sd_peer_get_slice',
+   'sd_peer_get_unit',
+   'sd_peer_get_user_slice',
+   'sd_peer_get_user_unit',
+   'sd_pid_get_cgroup',
+   'sd_pid_get_machine_name',
+   'sd_pid_get_session',
+   'sd_pid_get_slice',
+   'sd_pid_get_unit',
+   'sd_pid_get_user_slice',
+   'sd_pid_get_user_unit',
+   'sd_pidfd_get_cgroup',
+   'sd_pidfd_get_machine_name',
+   'sd_pidfd_get_owner_uid',
+   'sd_pidfd_get_session',
+   'sd_pidfd_get_slice',
+   'sd_pidfd_get_unit',
+   'sd_pidfd_get_user_slice',
+   'sd_pidfd_get_user_unit'],
+  'HAVE_PAM'],
+ ['sd_seat_get_active',
+  '3',
+  ['sd_seat_can_graphical', 'sd_seat_can_tty', 'sd_seat_get_sessions'],
+  'HAVE_PAM'],
+ ['sd_session_is_active',
+  '3',
+  ['sd_session_get_class',
+   'sd_session_get_desktop',
+   'sd_session_get_display',
+   'sd_session_get_leader',
+   'sd_session_get_remote_host',
+   'sd_session_get_remote_user',
+   'sd_session_get_seat',
+   'sd_session_get_service',
+   'sd_session_get_start_time',
+   'sd_session_get_state',
+   'sd_session_get_tty',
+   'sd_session_get_type',
+   'sd_session_get_uid',
+   'sd_session_get_username',
+   'sd_session_get_vt',
+   'sd_session_is_remote'],
+  'HAVE_PAM'],
+ ['sd_uid_get_state',
+  '3',
+  ['sd_uid_get_display',
+   'sd_uid_get_login_time',
+   'sd_uid_get_seats',
+   'sd_uid_get_sessions',
+   'sd_uid_is_on_seat'],
+  'HAVE_PAM'],
+ ['sd_watchdog_enabled', '3', [], ''],
+ ['shutdown', '8', [], ''],
+ ['smbios-type-11', '7', [], ''],
+ ['sysctl.d', '5', [], ''],
+ ['systemctl', '1', [], ''],
+ ['systemd-ac-power', '1', [], ''],
+ ['systemd-analyze', '1', [], 'ENABLE_ANALYZE'],
+ ['systemd-ask-password-console.service',
+  '8',
+  ['systemd-ask-password-console.path',
+   'systemd-ask-password-wall.path',
+   'systemd-ask-password-wall.service'],
+  ''],
+ ['systemd-ask-password', '1', [], ''],
+ ['systemd-backlight@.service', '8', ['systemd-backlight'], 'ENABLE_BACKLIGHT'],
+ ['systemd-battery-check.service', '8', ['systemd-battery-check'], ''],
+ ['systemd-binfmt.service', '8', ['systemd-binfmt'], 'ENABLE_BINFMT'],
+ ['systemd-bless-boot-generator', '8', [], 'ENABLE_BOOTLOADER'],
+ ['systemd-bless-boot.service',
+  '8',
+  ['systemd-bless-boot'],
+  'ENABLE_BOOTLOADER'],
+ ['systemd-boot-check-no-failures.service',
+  '8',
+  ['systemd-boot-check-no-failures'],
+  ''],
+ ['systemd-boot-random-seed.service', '8', [], 'ENABLE_BOOTLOADER'],
+ ['systemd-boot', '7', ['sd-boot'], 'ENABLE_BOOTLOADER'],
+ ['systemd-bsod.service', '8', ['systemd-bsod'], 'HAVE_QRENCODE'],
+ ['systemd-cat', '1', [], ''],
+ ['systemd-cgls', '1', [], ''],
+ ['systemd-cgtop', '1', [], ''],
+ ['systemd-coredump',
+  '8',
+  ['systemd-coredump.socket', 'systemd-coredump@.service'],
+  'ENABLE_COREDUMP'],
+ ['systemd-creds', '1', [], ''],
+ ['systemd-cryptenroll', '1', [], 'HAVE_LIBCRYPTSETUP'],
+ ['systemd-cryptsetup-generator', '8', [], 'HAVE_LIBCRYPTSETUP'],
+ ['systemd-cryptsetup',
+  '8',
+  ['systemd-cryptsetup@.service'],
+  'HAVE_LIBCRYPTSETUP'],
+ ['systemd-debug-generator', '8', [], ''],
+ ['systemd-delta', '1', [], ''],
+ ['systemd-detect-virt', '1', [], ''],
+ ['systemd-dissect', '1', ['mount.ddi'], 'HAVE_BLKID'],
+ ['systemd-environment-d-generator',
+  '8',
+  ['30-systemd-environment-d-generator'],
+  'ENABLE_ENVIRONMENT_D'],
+ ['systemd-escape', '1', [], ''],
+ ['systemd-firstboot', '1', ['systemd-firstboot.service'], 'ENABLE_FIRSTBOOT'],
+ ['systemd-fsck@.service',
+  '8',
+  ['systemd-fsck', 'systemd-fsck-root.service', 'systemd-fsck-usr.service'],
+  ''],
+ ['systemd-fstab-generator', '8', [], ''],
+ ['systemd-getty-generator', '8', [], ''],
+ ['systemd-gpt-auto-generator', '8', [], 'HAVE_BLKID'],
+ ['systemd-hibernate-resume-generator', '8', [], 'ENABLE_HIBERNATE'],
+ ['systemd-hibernate-resume.service',
+  '8',
+  ['systemd-hibernate-resume'],
+  'ENABLE_HIBERNATE'],
+ ['systemd-homed.service', '8', ['systemd-homed'], 'ENABLE_HOMED'],
+ ['systemd-hostnamed.service', '8', ['systemd-hostnamed'], 'ENABLE_HOSTNAMED'],
+ ['systemd-hwdb', '8', [], 'ENABLE_HWDB'],
+ ['systemd-id128', '1', [], ''],
+ ['systemd-importd.service', '8', ['systemd-importd'], 'ENABLE_IMPORTD'],
+ ['systemd-inhibit', '1', [], ''],
+ ['systemd-initctl.service',
+  '8',
+  ['systemd-initctl', 'systemd-initctl.socket'],
+  'HAVE_SYSV_COMPAT'],
+ ['systemd-integritysetup-generator', '8', [], 'HAVE_LIBCRYPTSETUP'],
+ ['systemd-integritysetup@.service',
+  '8',
+  ['systemd-integritysetup'],
+  'HAVE_LIBCRYPTSETUP'],
+ ['systemd-journal-gatewayd.service',
+  '8',
+  ['systemd-journal-gatewayd', 'systemd-journal-gatewayd.socket'],
+  'HAVE_MICROHTTPD'],
+ ['systemd-journal-remote.service',
+  '8',
+  ['systemd-journal-remote', 'systemd-journal-remote.socket'],
+  'HAVE_MICROHTTPD'],
+ ['systemd-journal-upload.service',
+  '8',
+  ['systemd-journal-upload'],
+  'HAVE_MICROHTTPD'],
+ ['systemd-journald.service',
+  '8',
+  ['systemd-journald',
+   'systemd-journald-audit.socket',
+   'systemd-journald-dev-log.socket',
+   'systemd-journald-varlink@.socket',
+   'systemd-journald.socket',
+   'systemd-journald@.service',
+   'systemd-journald@.socket'],
+  ''],
+ ['systemd-localed.service', '8', ['systemd-localed'], 'ENABLE_LOCALED'],
+ ['systemd-logind.service', '8', ['systemd-logind'], 'ENABLE_LOGIND'],
+ ['systemd-machine-id-commit.service', '8', [], ''],
+ ['systemd-machine-id-setup', '1', [], ''],
+ ['systemd-machined.service', '8', ['systemd-machined'], 'ENABLE_MACHINED'],
+ ['systemd-makefs@.service',
+  '8',
+  ['systemd-growfs',
+   'systemd-growfs-root.service',
+   'systemd-growfs@.service',
+   'systemd-makefs',
+   'systemd-mkswap@.service'],
+  ''],
+ ['systemd-measure', '1', [], 'ENABLE_BOOTLOADER'],
+ ['systemd-modules-load.service', '8', ['systemd-modules-load'], 'HAVE_KMOD'],
+ ['systemd-mount', '1', ['systemd-umount'], ''],
+ ['systemd-network-generator.service', '8', ['systemd-network-generator'], ''],
+ ['systemd-networkd-wait-online.service',
+  '8',
+  ['systemd-networkd-wait-online', 'systemd-networkd-wait-online@.service'],
+  'ENABLE_NETWORKD'],
+ ['systemd-networkd.service', '8', ['systemd-networkd'], 'ENABLE_NETWORKD'],
+ ['systemd-notify', '1', [], ''],
+ ['systemd-nspawn', '1', [], ''],
+ ['systemd-oomd.service', '8', ['systemd-oomd'], 'ENABLE_OOMD'],
+ ['systemd-path', '1', [], ''],
+ ['systemd-pcrlock',
+  '8',
+  ['systemd-pcrlock-file-system.service',
+   'systemd-pcrlock-firmware-code.service',
+   'systemd-pcrlock-firmware-config.service',
+   'systemd-pcrlock-machine-id.service',
+   'systemd-pcrlock-make-policy.service',
+   'systemd-pcrlock-secureboot-authority.service',
+   'systemd-pcrlock-secureboot-policy.service'],
+  'ENABLE_BOOTLOADER'],
+ ['systemd-pcrphase.service',
+  '8',
+  ['systemd-pcrextend',
+   'systemd-pcrfs-root.service',
+   'systemd-pcrfs@.service',
+   'systemd-pcrmachine.service',
+   'systemd-pcrphase-initrd.service',
+   'systemd-pcrphase-sysinit.service'],
+  'ENABLE_BOOTLOADER'],
+ ['systemd-portabled.service', '8', ['systemd-portabled'], 'ENABLE_PORTABLED'],
+ ['systemd-poweroff.service',
+  '8',
+  ['systemd-halt.service',
+   'systemd-kexec.service',
+   'systemd-reboot.service',
+   'systemd-shutdown'],
+  ''],
+ ['systemd-pstore.service', '8', ['systemd-pstore'], 'ENABLE_PSTORE'],
+ ['systemd-quotacheck.service',
+  '8',
+  ['systemd-quotacheck'],
+  'ENABLE_QUOTACHECK'],
+ ['systemd-random-seed.service',
+  '8',
+  ['systemd-random-seed'],
+  'ENABLE_RANDOMSEED'],
+ ['systemd-rc-local-generator', '8', ['rc-local.service'], 'HAVE_SYSV_COMPAT'],
+ ['systemd-remount-fs.service', '8', ['systemd-remount-fs'], ''],
+ ['systemd-repart', '8', ['systemd-repart.service'], 'ENABLE_REPART'],
+ ['systemd-resolved.service', '8', ['systemd-resolved'], 'ENABLE_RESOLVE'],
+ ['systemd-rfkill.service',
+  '8',
+  ['systemd-rfkill', 'systemd-rfkill.socket'],
+  'ENABLE_RFKILL'],
+ ['systemd-run-generator', '8', [], ''],
+ ['systemd-run', '1', [], ''],
+ ['systemd-sleep.conf', '5', ['sleep.conf.d'], ''],
+ ['systemd-socket-activate', '1', [], ''],
+ ['systemd-socket-proxyd', '8', [], ''],
+ ['systemd-soft-reboot.service', '8', [], ''],
+ ['systemd-stdio-bridge', '1', [], ''],
+ ['systemd-storagetm.service', '8', ['systemd-storagetm'], 'ENABLE_STORAGETM'],
+ ['systemd-stub',
+  '7',
+  ['linuxaa64.efi.stub', 'linuxia32.efi.stub', 'linuxx64.efi.stub', 'sd-stub'],
+  'ENABLE_BOOTLOADER'],
+ ['systemd-suspend.service',
+  '8',
+  ['systemd-hibernate.service',
+   'systemd-hybrid-sleep.service',
+   'systemd-sleep',
+   'systemd-suspend-then-hibernate.service'],
+  ''],
+ ['systemd-sysctl.service', '8', ['systemd-sysctl'], ''],
+ ['systemd-sysext',
+  '8',
+  ['systemd-confext', 'systemd-confext.service', 'systemd-sysext.service'],
+  ''],
+ ['systemd-system-update-generator', '8', [], ''],
+ ['systemd-system.conf',
+  '5',
+  ['system.conf.d', 'systemd-user.conf', 'user.conf.d'],
+  ''],
+ ['systemd-sysupdate',
+  '8',
+  ['systemd-sysupdate-reboot.service',
+   'systemd-sysupdate-reboot.timer',
+   'systemd-sysupdate.service',
+   'systemd-sysupdate.timer'],
+  'ENABLE_SYSUPDATE'],
+ ['systemd-sysusers', '8', ['systemd-sysusers.service'], ''],
+ ['systemd-sysv-generator', '8', [], 'HAVE_SYSV_COMPAT'],
+ ['systemd-time-wait-sync.service',
+  '8',
+  ['systemd-time-wait-sync'],
+  'ENABLE_TIMESYNCD'],
+ ['systemd-timedated.service', '8', ['systemd-timedated'], 'ENABLE_TIMEDATED'],
+ ['systemd-timesyncd.service', '8', ['systemd-timesyncd'], 'ENABLE_TIMESYNCD'],
+ ['systemd-tmpfiles',
+  '8',
+  ['systemd-tmpfiles-clean.service',
+   'systemd-tmpfiles-clean.timer',
+   'systemd-tmpfiles-setup-dev-early.service',
+   'systemd-tmpfiles-setup-dev.service',
+   'systemd-tmpfiles-setup.service'],
+  ''],
+ ['systemd-tpm2-setup.service',
+  '8',
+  ['systemd-tpm2-setup', 'systemd-tpm2-setup-early.service'],
+  'ENABLE_BOOTLOADER'],
+ ['systemd-tty-ask-password-agent', '1', [], ''],
+ ['systemd-udev-settle.service', '8', [], ''],
+ ['systemd-udevd.service',
+  '8',
+  ['systemd-udevd',
+   'systemd-udevd-control.socket',
+   'systemd-udevd-kernel.socket'],
+  ''],
+ ['systemd-update-done.service', '8', ['systemd-update-done'], ''],
+ ['systemd-update-utmp.service',
+  '8',
+  ['systemd-update-utmp', 'systemd-update-utmp-runlevel.service'],
+  'ENABLE_UTMP'],
+ ['systemd-user-sessions.service', '8', ['systemd-user-sessions'], 'HAVE_PAM'],
+ ['systemd-userdbd.service', '8', ['systemd-userdbd'], 'ENABLE_USERDB'],
+ ['systemd-vconsole-setup.service',
+  '8',
+  ['systemd-vconsole-setup'],
+  'ENABLE_VCONSOLE'],
+ ['systemd-veritysetup-generator', '8', [], 'HAVE_LIBCRYPTSETUP'],
+ ['systemd-veritysetup@.service',
+  '8',
+  ['systemd-veritysetup'],
+  'HAVE_LIBCRYPTSETUP'],
+ ['systemd-vmspawn', '1', [], 'ENABLE_VMSPAWN'],
+ ['systemd-volatile-root.service', '8', ['systemd-volatile-root'], ''],
+ ['systemd-xdg-autostart-generator', '8', [], 'ENABLE_XDG_AUTOSTART'],
+ ['systemd', '1', ['init'], ''],
+ ['systemd.automount', '5', [], ''],
+ ['systemd.device', '5', [], ''],
+ ['systemd.dnssd', '5', [], 'ENABLE_RESOLVE'],
+ ['systemd.environment-generator', '7', [], 'ENABLE_ENVIRONMENT_D'],
+ ['systemd.exec', '5', [], ''],
+ ['systemd.generator', '7', [], ''],
+ ['systemd.image-policy', '7', [], ''],
+ ['systemd.journal-fields', '7', [], ''],
+ ['systemd.kill', '5', [], ''],
+ ['systemd.link', '5', [], ''],
+ ['systemd.mount', '5', [], ''],
+ ['systemd.net-naming-scheme', '7', [], ''],
+ ['systemd.netdev', '5', [], 'ENABLE_NETWORKD'],
+ ['systemd.network', '5', [], 'ENABLE_NETWORKD'],
+ ['systemd.nspawn', '5', [], ''],
+ ['systemd.offline-updates', '7', [], ''],
+ ['systemd.path', '5', [], ''],
+ ['systemd.pcrlock', '5', ['systemd.pcrlock.d'], ''],
+ ['systemd.preset', '5', [], ''],
+ ['systemd.resource-control', '5', [], ''],
+ ['systemd.scope', '5', [], ''],
+ ['systemd.service', '5', [], ''],
+ ['systemd.slice', '5', [], ''],
+ ['systemd.socket', '5', [], ''],
+ ['systemd.special', '7', [], ''],
+ ['systemd.swap', '5', [], ''],
+ ['systemd.syntax', '7', [], ''],
+ ['systemd.system-credentials', '7', [], ''],
+ ['systemd.target', '5', [], ''],
+ ['systemd.time', '7', [], ''],
+ ['systemd.timer', '5', [], ''],
+ ['systemd.unit', '5', [], ''],
+ ['sysupdate.d', '5', [], 'ENABLE_SYSUPDATE'],
+ ['sysusers.d', '5', [], 'ENABLE_SYSUSERS'],
+ ['telinit', '8', [], 'HAVE_SYSV_COMPAT'],
+ ['timedatectl', '1', [], 'ENABLE_TIMEDATECTL'],
+ ['timesyncd.conf', '5', ['timesyncd.conf.d'], 'ENABLE_TIMESYNCD'],
+ ['tmpfiles.d', '5', [], ''],
+ ['udev', '7', [], ''],
+ ['udev.conf', '5', [], ''],
+ ['udev_device_get_syspath',
+  '3',
+  ['udev_device_get_action',
+   'udev_device_get_devnode',
+   'udev_device_get_devnum',
+   'udev_device_get_devpath',
+   'udev_device_get_devtype',
+   'udev_device_get_driver',
+   'udev_device_get_is_initialized',
+   'udev_device_get_parent',
+   'udev_device_get_parent_with_subsystem_devtype',
+   'udev_device_get_subsystem',
+   'udev_device_get_sysname',
+   'udev_device_get_sysnum',
+   'udev_device_get_udev'],
+  ''],
+ ['udev_device_has_tag',
+  '3',
+  ['udev_device_get_current_tags_list_entry',
+   'udev_device_get_devlinks_list_entry',
+   'udev_device_get_properties_list_entry',
+   'udev_device_get_property_value',
+   'udev_device_get_sysattr_list_entry',
+   'udev_device_get_sysattr_value',
+   'udev_device_get_tags_list_entry',
+   'udev_device_has_current_tag',
+   'udev_device_set_sysattr_value'],
+  ''],
+ ['udev_device_new_from_syspath',
+  '3',
+  ['udev_device_new_from_device_id',
+   'udev_device_new_from_devnum',
+   'udev_device_new_from_environment',
+   'udev_device_new_from_subsystem_sysname',
+   'udev_device_ref',
+   'udev_device_unref'],
+  ''],
+ ['udev_enumerate_add_match_subsystem',
+  '3',
+  ['udev_enumerate_add_match_is_initialized',
+   'udev_enumerate_add_match_parent',
+   'udev_enumerate_add_match_property',
+   'udev_enumerate_add_match_sysattr',
+   'udev_enumerate_add_match_sysname',
+   'udev_enumerate_add_match_tag',
+   'udev_enumerate_add_nomatch_subsystem',
+   'udev_enumerate_add_nomatch_sysattr'],
+  ''],
+ ['udev_enumerate_new',
+  '3',
+  ['udev_enumerate_ref', 'udev_enumerate_unref'],
+  ''],
+ ['udev_enumerate_scan_devices',
+  '3',
+  ['udev_enumerate_add_syspath',
+   'udev_enumerate_get_list_entry',
+   'udev_enumerate_get_udev',
+   'udev_enumerate_scan_subsystems'],
+  ''],
+ ['udev_list_entry',
+  '3',
+  ['udev_list_entry_get_by_name',
+   'udev_list_entry_get_name',
+   'udev_list_entry_get_next',
+   'udev_list_entry_get_value'],
+  ''],
+ ['udev_monitor_filter_update',
+  '3',
+  ['udev_monitor_filter_add_match_subsystem_devtype',
+   'udev_monitor_filter_add_match_tag',
+   'udev_monitor_filter_remove'],
+  ''],
+ ['udev_monitor_new_from_netlink',
+  '3',
+  ['udev_monitor_ref', 'udev_monitor_unref'],
+  ''],
+ ['udev_monitor_receive_device',
+  '3',
+  ['udev_monitor_enable_receiving',
+   'udev_monitor_get_fd',
+   'udev_monitor_get_udev',
+   'udev_monitor_set_receive_buffer_size'],
+  ''],
+ ['udev_new', '3', ['udev_ref', 'udev_unref'], ''],
+ ['udevadm', '8', [], ''],
+ ['ukify', '1', [], 'ENABLE_UKIFY'],
+ ['user@.service',
+  '5',
+  ['systemd-user-runtime-dir', 'user-runtime-dir@.service'],
+  ''],
+ ['userdbctl', '1', [], 'ENABLE_USERDB'],
+ ['varlinkctl', '1', [], ''],
+ ['vconsole.conf', '5', [], 'ENABLE_VCONSOLE'],
+ ['veritytab', '5', [], 'HAVE_LIBCRYPTSETUP']
+]
+# Really, do not edit.
diff --git a/man/runlevel.xml b/man/runlevel.xml
new file mode 100644
index 0000000..08447e6
--- /dev/null
+++ b/man/runlevel.xml
@@ -0,0 +1,164 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="runlevel" conditional='HAVE_SYSV_COMPAT'
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>runlevel</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>runlevel</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>runlevel</refname>
+    <refpurpose>Print previous and current SysV runlevel</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <cmdsynopsis>
+      <command>runlevel</command>
+      <arg choice="opt" rep="repeat">options</arg>
+    </cmdsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Overview</title>
+
+    <para>"Runlevels" are an obsolete way to start and stop groups of
+    services used in SysV init. systemd provides a compatibility layer
+    that maps runlevels to targets, and associated binaries like
+    <command>runlevel</command>. Nevertheless, only one runlevel can
+    be "active" at a given time, while systemd can activate multiple
+    targets concurrently, so the mapping to runlevels is confusing
+    and only approximate. Runlevels should not be used in new code,
+    and are mostly useful as a shorthand way to refer the matching
+    systemd targets in kernel boot parameters.</para>
+
+    <table>
+      <title>Mapping between runlevels and systemd targets</title>
+      <tgroup cols='2' align='left' colsep='1' rowsep='1'>
+        <colspec colname="runlevel" />
+        <colspec colname="target" />
+        <thead>
+          <row>
+            <entry>Runlevel</entry>
+            <entry>Target</entry>
+          </row>
+        </thead>
+        <tbody>
+          <row>
+            <entry>0</entry>
+            <entry><filename>poweroff.target</filename></entry>
+          </row>
+          <row>
+            <entry>1</entry>
+            <entry><filename>rescue.target</filename></entry>
+          </row>
+          <row>
+            <entry>2, 3, 4</entry>
+            <entry><filename>multi-user.target</filename></entry>
+          </row>
+          <row>
+            <entry>5</entry>
+            <entry><filename>graphical.target</filename></entry>
+          </row>
+          <row>
+            <entry>6</entry>
+            <entry><filename>reboot.target</filename></entry>
+          </row>
+        </tbody>
+      </tgroup>
+    </table>
+  </refsect1>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>runlevel</command> prints the previous and current
+    SysV runlevel if they are known.</para>
+
+    <para>The two runlevel characters are separated by a single space
+    character. If a runlevel cannot be determined, N is printed
+    instead. If neither can be determined, the word "unknown" is
+    printed.</para>
+
+    <para>Unless overridden in the environment, this will check the
+    utmp database for recent runlevel changes.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>The following option is understood:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><option>--help</option></term>
+
+        <xi:include href="standard-options.xml" xpointer="help-text" />
+      </varlistentry>
+    </variablelist>
+
+  </refsect1>
+
+  <refsect1>
+    <title>Exit status</title>
+
+    <para>If one or both runlevels could be determined, 0 is returned,
+    a non-zero failure code otherwise.</para>
+
+  </refsect1>
+
+  <refsect1>
+    <title>Environment</title>
+
+    <variablelist class='environment-variables'>
+      <varlistentry>
+        <term><varname>$RUNLEVEL</varname></term>
+
+        <listitem><para>If <varname>$RUNLEVEL</varname> is set,
+        <command>runlevel</command> will print this value as current
+        runlevel and ignore utmp.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>$PREVLEVEL</varname></term>
+
+        <listitem><para>If <varname>$PREVLEVEL</varname> is set,
+        <command>runlevel</command> will print this value as previous
+        runlevel and ignore utmp.</para></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Files</title>
+
+    <variablelist>
+      <varlistentry>
+        <term><filename>/run/utmp</filename></term>
+
+        <listitem><para>The utmp database <command>runlevel</command> reads the previous and current runlevel
+        from.</para>
+
+        <xi:include href="version-info.xml" xpointer="v237"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+</refentry>
diff --git a/man/sd-bus-container-append.c b/man/sd-bus-container-append.c
new file mode 100644
index 0000000..8bb4f33
--- /dev/null
+++ b/man/sd-bus-container-append.c
@@ -0,0 +1,19 @@
+/* SPDX-License-Identifier: MIT-0 */
+
+#include <systemd/sd-bus.h>
+
+int append_strings_to_message(sd_bus_message *m, const char *const *arr) {
+  int r;
+
+  r = sd_bus_message_open_container(m, 'a', "s");
+  if (r < 0)
+    return r;
+
+  for (const char *s = *arr; *s; s++) {
+    r = sd_bus_message_append(m, "s", s);
+    if (r < 0)
+      return r;
+  }
+
+  return sd_bus_message_close_container(m);
+}
diff --git a/man/sd-bus-container-read.c b/man/sd-bus-container-read.c
new file mode 100644
index 0000000..5ede316
--- /dev/null
+++ b/man/sd-bus-container-read.c
@@ -0,0 +1,27 @@
+/* SPDX-License-Identifier: MIT-0 */
+
+#include <stdio.h>
+
+#include <systemd/sd-bus.h>
+
+int read_strings_from_message(sd_bus_message *m) {
+  int r;
+
+  r = sd_bus_message_enter_container(m, 'a', "s");
+  if (r < 0)
+    return r;
+
+  for (;;) {
+    const char *s;
+
+    r = sd_bus_message_read(m, "s", &s);
+    if (r < 0)
+      return r;
+    if (r == 0)
+      break;
+
+    printf("%s\n", s);
+  }
+
+  return sd_bus_message_exit_container(m);
+}
diff --git a/man/sd-bus-errors.xml b/man/sd-bus-errors.xml
new file mode 100644
index 0000000..25e3913
--- /dev/null
+++ b/man/sd-bus-errors.xml
@@ -0,0 +1,346 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd-bus-errors"
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd-bus-errors</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd-bus-errors</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd-bus-errors</refname>
+    <refname>SD_BUS_ERROR_FAILED</refname>
+    <refname>SD_BUS_ERROR_NO_MEMORY</refname>
+    <refname>SD_BUS_ERROR_SERVICE_UNKNOWN</refname>
+    <refname>SD_BUS_ERROR_NAME_HAS_NO_OWNER</refname>
+    <refname>SD_BUS_ERROR_NO_REPLY</refname>
+    <refname>SD_BUS_ERROR_IO_ERROR</refname>
+    <refname>SD_BUS_ERROR_BAD_ADDRESS</refname>
+    <refname>SD_BUS_ERROR_NOT_SUPPORTED</refname>
+    <refname>SD_BUS_ERROR_LIMITS_EXCEEDED</refname>
+    <refname>SD_BUS_ERROR_ACCESS_DENIED</refname>
+    <refname>SD_BUS_ERROR_AUTH_FAILED</refname>
+    <refname>SD_BUS_ERROR_NO_SERVER</refname>
+    <refname>SD_BUS_ERROR_TIMEOUT</refname>
+    <refname>SD_BUS_ERROR_NO_NETWORK</refname>
+    <refname>SD_BUS_ERROR_ADDRESS_IN_USE</refname>
+    <refname>SD_BUS_ERROR_DISCONNECTED</refname>
+    <refname>SD_BUS_ERROR_INVALID_ARGS</refname>
+    <refname>SD_BUS_ERROR_FILE_NOT_FOUND</refname>
+    <refname>SD_BUS_ERROR_FILE_EXISTS</refname>
+    <refname>SD_BUS_ERROR_UNKNOWN_METHOD</refname>
+    <refname>SD_BUS_ERROR_UNKNOWN_OBJECT</refname>
+    <refname>SD_BUS_ERROR_UNKNOWN_INTERFACE</refname>
+    <refname>SD_BUS_ERROR_UNKNOWN_PROPERTY</refname>
+    <refname>SD_BUS_ERROR_PROPERTY_READ_ONLY</refname>
+    <refname>SD_BUS_ERROR_UNIX_PROCESS_ID_UNKNOWN</refname>
+    <refname>SD_BUS_ERROR_INVALID_SIGNATURE</refname>
+    <refname>SD_BUS_ERROR_INCONSISTENT_MESSAGE</refname>
+    <refname>SD_BUS_ERROR_TIMED_OUT</refname>
+    <refname>SD_BUS_ERROR_MATCH_RULE_NOT_FOUND</refname>
+    <refname>SD_BUS_ERROR_MATCH_RULE_INVALID</refname>
+    <refname>SD_BUS_ERROR_INTERACTIVE_AUTHORIZATION_REQUIRED</refname>
+    <refname>SD_BUS_ERROR_INVALID_FILE_CONTENT</refname>
+    <refname>SD_BUS_ERROR_SELINUX_SECURITY_CONTEXT_UNKNOWN</refname>
+    <refname>SD_BUS_ERROR_OBJECT_PATH_IN_USE</refname>
+
+    <refpurpose>Standard D-Bus error names</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <funcsynopsisinfo>
+#define SD_BUS_ERROR_FAILED                  "org.freedesktop.DBus.Error.Failed"
+#define SD_BUS_ERROR_NO_MEMORY               "org.freedesktop.DBus.Error.NoMemory"
+#define SD_BUS_ERROR_SERVICE_UNKNOWN         "org.freedesktop.DBus.Error.ServiceUnknown"
+#define SD_BUS_ERROR_NAME_HAS_NO_OWNER       "org.freedesktop.DBus.Error.NameHasNoOwner"
+#define SD_BUS_ERROR_NO_REPLY                "org.freedesktop.DBus.Error.NoReply"
+#define SD_BUS_ERROR_IO_ERROR                "org.freedesktop.DBus.Error.IOError"
+#define SD_BUS_ERROR_BAD_ADDRESS             "org.freedesktop.DBus.Error.BadAddress"
+#define SD_BUS_ERROR_NOT_SUPPORTED           "org.freedesktop.DBus.Error.NotSupported"
+#define SD_BUS_ERROR_LIMITS_EXCEEDED         "org.freedesktop.DBus.Error.LimitsExceeded"
+#define SD_BUS_ERROR_ACCESS_DENIED           "org.freedesktop.DBus.Error.AccessDenied"
+#define SD_BUS_ERROR_AUTH_FAILED             "org.freedesktop.DBus.Error.AuthFailed"
+#define SD_BUS_ERROR_NO_SERVER               "org.freedesktop.DBus.Error.NoServer"
+#define SD_BUS_ERROR_TIMEOUT                 "org.freedesktop.DBus.Error.Timeout"
+#define SD_BUS_ERROR_NO_NETWORK              "org.freedesktop.DBus.Error.NoNetwork"
+#define SD_BUS_ERROR_ADDRESS_IN_USE          "org.freedesktop.DBus.Error.AddressInUse"
+#define SD_BUS_ERROR_DISCONNECTED            "org.freedesktop.DBus.Error.Disconnected"
+#define SD_BUS_ERROR_INVALID_ARGS            "org.freedesktop.DBus.Error.InvalidArgs"
+#define SD_BUS_ERROR_FILE_NOT_FOUND          "org.freedesktop.DBus.Error.FileNotFound"
+#define SD_BUS_ERROR_FILE_EXISTS             "org.freedesktop.DBus.Error.FileExists"
+#define SD_BUS_ERROR_UNKNOWN_METHOD          "org.freedesktop.DBus.Error.UnknownMethod"
+#define SD_BUS_ERROR_UNKNOWN_OBJECT          "org.freedesktop.DBus.Error.UnknownObject"
+#define SD_BUS_ERROR_UNKNOWN_INTERFACE       "org.freedesktop.DBus.Error.UnknownInterface"
+#define SD_BUS_ERROR_UNKNOWN_PROPERTY        "org.freedesktop.DBus.Error.UnknownProperty"
+#define SD_BUS_ERROR_PROPERTY_READ_ONLY      "org.freedesktop.DBus.Error.PropertyReadOnly"
+#define SD_BUS_ERROR_UNIX_PROCESS_ID_UNKNOWN "org.freedesktop.DBus.Error.UnixProcessIdUnknown"
+#define SD_BUS_ERROR_INVALID_SIGNATURE       "org.freedesktop.DBus.Error.InvalidSignature"
+#define SD_BUS_ERROR_INCONSISTENT_MESSAGE    "org.freedesktop.DBus.Error.InconsistentMessage"
+#define SD_BUS_ERROR_TIMED_OUT               "org.freedesktop.DBus.Error.TimedOut"
+#define SD_BUS_ERROR_MATCH_RULE_NOT_FOUND    "org.freedesktop.DBus.Error.MatchRuleNotFound"
+#define SD_BUS_ERROR_MATCH_RULE_INVALID      "org.freedesktop.DBus.Error.MatchRuleInvalid"
+#define SD_BUS_ERROR_INTERACTIVE_AUTHORIZATION_REQUIRED \
+                                             "org.freedesktop.DBus.Error.InteractiveAuthorizationRequired"
+#define SD_BUS_ERROR_INVALID_FILE_CONTENT    "org.freedesktop.DBus.Error.InvalidFileContent"
+#define SD_BUS_ERROR_SELINUX_SECURITY_CONTEXT_UNKNOWN \
+                                             "org.freedesktop.DBus.Error.SELinuxSecurityContextUnknown"
+#define SD_BUS_ERROR_OBJECT_PATH_IN_USE      "org.freedesktop.DBus.Error.ObjectPathInUse"
+      </funcsynopsisinfo>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>In addition to the error names user programs define, D-Bus
+    knows a number of generic, standardized error names that are
+    listed below.</para>
+
+    <para>In addition to this list, in sd-bus, the special error
+    namespace <literal>System.Error.</literal> is used to map
+    arbitrary Linux system errors (as defined by <citerefentry
+    project='man-pages'><refentrytitle>errno</refentrytitle><manvolnum>3</manvolnum></citerefentry>)
+    to D-Bus errors and back. For example, the error
+    <constant>EUCLEAN</constant> is mapped to
+    <literal>System.Error.EUCLEAN</literal> and back.</para>
+
+    <variablelist>
+
+      <varlistentry>
+         <term><constant>SD_BUS_ERROR_FAILED</constant></term>
+         <listitem><para>A generic error indication. See the error
+         message for further details. This error name should be
+         avoided, in favor of a more expressive error
+         name.</para>
+
+         <xi:include href="version-info.xml" xpointer="v223"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><constant>SD_BUS_ERROR_NO_MEMORY</constant></term>
+        <listitem><para>A memory allocation failed, and the requested
+        operation could not be completed.</para>
+
+        <xi:include href="version-info.xml" xpointer="v223"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><constant>SD_BUS_ERROR_SERVICE_UNKNOWN</constant></term>
+        <listitem><para>The contacted bus service is unknown and
+        cannot be activated.</para>
+
+        <xi:include href="version-info.xml" xpointer="v223"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><constant>SD_BUS_ERROR_NAME_HAS_NO_OWNER</constant></term>
+        <listitem><para>The specified bus service name currently has
+        no owner.</para>
+
+        <xi:include href="version-info.xml" xpointer="v223"/></listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><constant>SD_BUS_ERROR_NO_REPLY</constant></term>
+        <listitem><para>A message did not receive a reply. This error
+        is usually generated after a timeout.</para>
+
+        <xi:include href="version-info.xml" xpointer="v223"/></listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><constant>SD_BUS_ERROR_IO_ERROR</constant></term>
+        <listitem><para>Generic input/output error, for example when
+        accessing a socket or other I/O context.</para>
+
+        <xi:include href="version-info.xml" xpointer="v223"/></listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><constant>SD_BUS_ERROR_BAD_ADDRESS</constant></term>
+        <listitem><para>The specified D-Bus bus address string is
+        malformed.</para>
+
+        <xi:include href="version-info.xml" xpointer="v223"/></listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><constant>SD_BUS_ERROR_NOT_SUPPORTED</constant></term>
+        <listitem><para>The requested operation is not supported on
+        the local system.</para>
+
+        <xi:include href="version-info.xml" xpointer="v223"/></listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><constant>SD_BUS_ERROR_LIMITS_EXCEEDED</constant></term>
+        <listitem><para>Some limited resource has been
+        exhausted.</para>
+
+        <xi:include href="version-info.xml" xpointer="v223"/></listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><constant>SD_BUS_ERROR_ACCESS_DENIED</constant></term>
+        <listitem><para>Access to a resource has been denied due to security restrictions.</para>
+
+        <xi:include href="version-info.xml" xpointer="v223"/></listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><constant>SD_BUS_ERROR_AUTH_FAILED</constant></term>
+        <listitem><para>Authentication did not complete successfully.</para>
+
+        <xi:include href="version-info.xml" xpointer="v223"/></listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><constant>SD_BUS_ERROR_NO_SERVER</constant></term>
+        <listitem><para>Unable to connect to the specified server.</para>
+
+        <xi:include href="version-info.xml" xpointer="v223"/></listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><constant>SD_BUS_ERROR_TIMEOUT</constant></term>
+        <listitem><para>An operation timed out. Note that method calls
+        which timeout generate a
+        <constant>SD_BUS_ERROR_NO_REPLY</constant>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v223"/></listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><constant>SD_BUS_ERROR_NO_NETWORK</constant></term>
+        <listitem><para>No network available to execute requested network operation on.</para>
+
+        <xi:include href="version-info.xml" xpointer="v223"/></listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><constant>SD_BUS_ERROR_ADDRESS_IN_USE</constant></term>
+        <listitem><para>The specified network address is already being listened on.</para>
+
+        <xi:include href="version-info.xml" xpointer="v223"/></listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><constant>SD_BUS_ERROR_DISCONNECTED</constant></term>
+        <listitem><para>The connection has been terminated.</para>
+
+        <xi:include href="version-info.xml" xpointer="v223"/></listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><constant>SD_BUS_ERROR_INVALID_ARGS</constant></term>
+        <listitem><para>One or more invalid arguments have been passed.</para>
+
+        <xi:include href="version-info.xml" xpointer="v223"/></listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><constant>SD_BUS_ERROR_FILE_NOT_FOUND</constant></term>
+        <listitem><para>The requested file could not be found.</para>
+
+        <xi:include href="version-info.xml" xpointer="v223"/></listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><constant>SD_BUS_ERROR_FILE_EXISTS</constant></term>
+        <listitem><para>The requested file already exists.</para>
+
+        <xi:include href="version-info.xml" xpointer="v223"/></listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><constant>SD_BUS_ERROR_UNKNOWN_METHOD</constant></term>
+        <listitem><para>The requested method does not exist in the selected interface.</para>
+
+        <xi:include href="version-info.xml" xpointer="v223"/></listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><constant>SD_BUS_ERROR_UNKNOWN_OBJECT</constant></term>
+        <listitem><para>The requested object does not exist in the selected service.</para>
+
+        <xi:include href="version-info.xml" xpointer="v223"/></listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><constant>SD_BUS_ERROR_UNKNOWN_INTERFACE</constant></term>
+        <listitem><para>The requested interface does not exist on the selected object.</para>
+
+        <xi:include href="version-info.xml" xpointer="v223"/></listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><constant>SD_BUS_ERROR_UNKNOWN_PROPERTY</constant></term>
+        <listitem><para>The requested property does not exist in the selected interface.</para>
+
+        <xi:include href="version-info.xml" xpointer="v223"/></listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><constant>SD_BUS_ERROR_PROPERTY_READ_ONLY</constant></term>
+        <listitem><para>A write operation was requested on a read-only property.</para>
+
+        <xi:include href="version-info.xml" xpointer="v223"/></listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><constant>SD_BUS_ERROR_UNIX_PROCESS_ID_UNKNOWN</constant></term>
+        <listitem><para>The requested PID is not known.</para>
+
+        <xi:include href="version-info.xml" xpointer="v223"/></listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><constant>SD_BUS_ERROR_INVALID_SIGNATURE</constant></term>
+        <listitem><para>The specified message signature is not
+        valid.</para>
+
+        <xi:include href="version-info.xml" xpointer="v223"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><constant>SD_BUS_ERROR_INCONSISTENT_MESSAGE</constant></term>
+        <listitem><para>The passed message does not validate
+        correctly.</para>
+
+        <xi:include href="version-info.xml" xpointer="v223"/></listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><constant>SD_BUS_ERROR_MATCH_RULE_NOT_FOUND</constant></term>
+        <listitem><para>The specified match rule does not exist.</para>
+
+        <xi:include href="version-info.xml" xpointer="v223"/></listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><constant>SD_BUS_ERROR_MATCH_RULE_INVALID</constant></term>
+        <listitem><para>The specified match rule is invalid.</para>
+
+        <xi:include href="version-info.xml" xpointer="v223"/></listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><constant>SD_BUS_ERROR_INTERACTIVE_AUTHORIZATION_REQUIRED</constant></term>
+        <listitem><para>Access to the requested operation is not
+        permitted. However, it might be available after interactive
+        authentication. This is usually returned by method calls
+        supporting a framework for additional interactive
+        authorization, when interactive authorization was not enabled
+        with the
+        <citerefentry><refentrytitle>sd_bus_message_set_allow_interactive_authorization</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+        for the method call message.</para>
+
+        <xi:include href="version-info.xml" xpointer="v223"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>libsystemd</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_error</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_message_set_allow_interactive_authorization</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>errno</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>strerror_r</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd-bus.xml b/man/sd-bus.xml
new file mode 100644
index 0000000..4c9c009
--- /dev/null
+++ b/man/sd-bus.xml
@@ -0,0 +1,196 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd-bus" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd-bus</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd-bus</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd-bus</refname>
+    <refpurpose>A lightweight D-Bus IPC client library</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+    </funcsynopsis>
+
+    <cmdsynopsis>
+      <command>pkg-config --cflags --libs libsystemd</command>
+    </cmdsynopsis>
+
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><filename>sd-bus.h</filename> is part of
+    <citerefentry><refentrytitle>libsystemd</refentrytitle><manvolnum>3</manvolnum></citerefentry> and
+    provides an implementation of a D-Bus IPC client. See
+    <ulink url="https://www.freedesktop.org/software/dbus/" />
+    for more information about D-Bus IPC.</para>
+
+    <para>See
+    <literallayout><citerefentry><refentrytitle>sd_bus_add_match</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_add_object</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_add_object_manager</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_add_object_vtable</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_add_fallback</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_add_fallback_vtable</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_add_filter</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_add_node_enumerator</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_attach_event</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_call</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_call_async</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_call_method</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_call_method_async</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_can_send</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_close</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_creds_get_pid</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_creds_new_from_pid</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_default</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_emit_interfaces_added</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_emit_interfaces_added_strv</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_emit_interfaces_removed</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_emit_interfaces_removed_strv</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_emit_object_added</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_emit_object_removed</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_emit_properties_changed</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_emit_properties_changed_strv</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_emit_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_emit_signalv</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_emit_signal_to</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_emit_signal_tov</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd-bus-errors</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_error</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_error_add_map</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_get_address</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_get_allow_interactive_authorization</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_get_bus_id</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_get_creds_mask</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_get_current_handler</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_get_current_message</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_get_current_slot</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_get_current_userdata</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_get_exit_on_disconnect</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_get_fd</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_get_method_call_timeout</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_get_n_queued_read</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_get_name_creds</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_get_name_machine_id</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_get_owner_creds</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_get_property</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_get_property_string</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_get_property_strv</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_get_property_trivial</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_get_scope</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_get_tid</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_get_unique_name</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_interface_name_is_valid</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_is_bus_client</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_is_monitor</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_is_server</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_list_names</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_message_append</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_message_append_array</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_message_append_basic</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_message_append_string_memfd</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_message_append_strv</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_message_at_end</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_message_close_container</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_message_copy</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_message_dump</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_message_enter_container</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_message_exit_container</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_message_get_allow_interactive_authorization</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_message_get_cookie</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_message_get_creds</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_message_get_errno</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_message_get_error</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_message_get_monotonic_usec</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_message_get_sender</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_message_get_signature</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_message_get_type</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_message_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_message_new_method_call</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_message_new_method_error</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_message_new_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_message_new_signal_to</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_message_open_container</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_message_peek_type</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_message_read</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_message_read_array</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_message_read_basic</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_message_read_strv</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_message_rewind</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_message_seal</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_message_send</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_message_set_allow_interactive_authorization</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_message_set_destination</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_message_set_expect_reply</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_message_set_sender</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_message_skip</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_message_verify_type</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_negotiate_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_path_encode</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_process</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_query_sender_creds</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_query_sender_privilege</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_reply_method_error</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_reply_method_return</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_request_name</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_send</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_send_to</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_set_address</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_set_allow_interactive_authorization</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_set_bus_client</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_set_close_on_exit</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_set_connected_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_set_description</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_set_exit_on_disconnect</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_set_method_call_timeout</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_set_monitor</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_set_property</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_set_propertyv</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_set_sender</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_set_server</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_set_watch_bind</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+<citerefentry><refentrytitle>sd_bus_slot_get_current_handler</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_slot_get_current_message</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_slot_get_current_userdata</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_slot_set_description</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_slot_set_destroy_callback</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_slot_set_floating</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_slot_set_userdata</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_start</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_track_add_name</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_bus_track_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+</literallayout>
+    for more information about the functions available.</para>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>busctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>dbus-daemon</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>dbus-send</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd-daemon.xml b/man/sd-daemon.xml
new file mode 100644
index 0000000..6cd06a8
--- /dev/null
+++ b/man/sd-daemon.xml
@@ -0,0 +1,115 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd-daemon"
+  xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd-daemon</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd-daemon</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd-daemon</refname>
+    <refname>SD_EMERG</refname>
+    <refname>SD_ALERT</refname>
+    <refname>SD_CRIT</refname>
+    <refname>SD_ERR</refname>
+    <refname>SD_WARNING</refname>
+    <refname>SD_NOTICE</refname>
+    <refname>SD_INFO</refname>
+    <refname>SD_DEBUG</refname>
+    <refpurpose>APIs for
+    new-style daemons</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-daemon.h&gt;</funcsynopsisinfo>
+    </funcsynopsis>
+
+    <cmdsynopsis>
+      <command>pkg-config --cflags --libs libsystemd</command>
+    </cmdsynopsis>
+
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><filename>sd-daemon.h</filename> is part of
+    <citerefentry><refentrytitle>libsystemd</refentrytitle><manvolnum>3</manvolnum></citerefentry> and
+    provides APIs for new-style daemons, as implemented by the
+    <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> service
+    manager.</para>
+
+    <para>See
+    <citerefentry><refentrytitle>sd_listen_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_booted</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_is_fifo</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_watchdog_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    for more information about the functions implemented. In addition
+    to these functions, a couple of logging prefixes are defined as
+    macros:</para>
+
+    <programlisting>#define SD_EMERG   "&lt;0&gt;"  /* system is unusable */
+#define SD_ALERT   "&lt;1&gt;"  /* action must be taken immediately */
+#define SD_CRIT    "&lt;2&gt;"  /* critical conditions */
+#define SD_ERR     "&lt;3&gt;"  /* error conditions */
+#define SD_WARNING "&lt;4&gt;"  /* warning conditions */
+#define SD_NOTICE  "&lt;5&gt;"  /* normal but significant condition */
+#define SD_INFO    "&lt;6&gt;"  /* informational */
+#define SD_DEBUG   "&lt;7&gt;"  /* debug-level messages */</programlisting>
+
+    <para>These prefixes are intended to be used in conjunction with stderr-based logging (or stdout-based
+    logging) as implemented by systemd. If a systemd service definition file is configured with
+    <varname>StandardError=journal</varname> or <varname>StandardError=kmsg</varname> (and similar with
+    <varname>StandardOutput=</varname>), these prefixes can be used to encode a log level in lines
+    printed. This is similar to the kernel <function>printk()</function>-style logging. See
+    <citerefentry><refentrytitle>klogctl</refentrytitle><manvolnum>2</manvolnum></citerefentry> for more
+    information.</para>
+
+    <para>The log levels are identical to
+    <citerefentry project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>'s
+    log level system. To use these prefixes simply prefix every line
+    with one of these strings. A line that is not prefixed will be
+    logged at the default log level SD_INFO.</para>
+
+    <example>
+      <title>Hello World</title>
+
+      <para>A daemon may log with the log level NOTICE by issuing this
+      call:</para>
+
+      <programlisting>fprintf(stderr, SD_NOTICE "Hello World!\n");</programlisting>
+    </example>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_listen_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_booted</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_is_fifo</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_watchdog_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>daemon</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>fprintf</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry project='die-net'><refentrytitle>pkg-config</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd-device.xml b/man/sd-device.xml
new file mode 100644
index 0000000..4950781
--- /dev/null
+++ b/man/sd-device.xml
@@ -0,0 +1,64 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd-device" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd-device</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd-device</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd-device</refname>
+    <refpurpose>API for enumerating and introspecting local devices</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-device.h&gt;</funcsynopsisinfo>
+    </funcsynopsis>
+
+    <cmdsynopsis>
+      <command>pkg-config --cflags --libs libsystemd</command>
+    </cmdsynopsis>
+
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><filename>sd-device.h</filename> is part of
+    <citerefentry><refentrytitle>libsystemd</refentrytitle><manvolnum>3</manvolnum></citerefentry> and
+    provides an API to introspect and enumerate devices on the local system. It provides a programmatic
+    interface to the database of devices and their properties mananaged by
+    <citerefentry><refentrytitle>systemd-udevd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+    This API is a replacement for
+    <citerefentry><refentrytitle>libudev</refentrytitle><manvolnum>3</manvolnum></citerefentry> and
+    <filename>libudev.h</filename>.</para>
+
+    <para>See
+    <literallayout><citerefentry><refentrytitle>sd_device_get_syspath</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+<citerefentry><refentrytitle>sd_device_ref</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+</literallayout>
+    for more information about the functions available.</para>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>udevadm</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd-event.xml b/man/sd-event.xml
new file mode 100644
index 0000000..276770f
--- /dev/null
+++ b/man/sd-event.xml
@@ -0,0 +1,167 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd-event" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd-event</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd-event</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd-event</refname>
+    <refpurpose>A generic event loop implementation</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-event.h&gt;</funcsynopsisinfo>
+    </funcsynopsis>
+
+    <cmdsynopsis>
+      <command>pkg-config --cflags --libs libsystemd</command>
+    </cmdsynopsis>
+
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><filename>sd-event.h</filename> is part of
+    <citerefentry><refentrytitle>libsystemd</refentrytitle><manvolnum>3</manvolnum></citerefentry> and
+    provides a generic event loop implementation, based on Linux <citerefentry
+    project='man-pages'><refentrytitle>epoll</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
+    </para>
+
+    <para>See
+    <citerefentry><refentrytitle>sd_event_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_event_run</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_event_add_io</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_event_add_time</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_event_add_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_event_add_child</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_event_add_inotify</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_event_add_defer</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_event_add_memory_pressure</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_event_source_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_event_source_set_priority</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_event_source_set_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_event_source_set_userdata</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_event_source_get_event</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_event_source_get_pending</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_event_source_set_description</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_event_source_set_prepare</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_event_source_set_ratelimit</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_event_wait</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_event_get_fd</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_event_set_watchdog</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_event_exit</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_event_now</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    for more information about the functions available.</para>
+
+    <para>The event loop design is targeted on running a separate
+    instance of the event loop in each thread; it has no concept of
+    distributing events from a single event loop instance onto
+    multiple worker threads. Dispatching events is strictly ordered
+    and subject to configurable priorities. In each event loop
+    iteration a single event source is dispatched. Each time an event
+    source is dispatched the kernel is polled for new events, before
+    the next event source is dispatched. The event loop is designed to
+    honor priorities and provide fairness within each priority. It is
+    not designed to provide optimal throughput, as this contradicts
+    these goals due the limitations of the underlying <citerefentry
+    project='man-pages'><refentrytitle>epoll</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+    primitives.</para>
+
+    <para>The event loop implementation provides the following features:</para>
+
+    <orderedlist>
+      <listitem><para>I/O event sources, based on <citerefentry
+      project='man-pages'><refentrytitle>epoll</refentrytitle><manvolnum>7</manvolnum></citerefentry>'s
+      file descriptor watching, including edge triggered events (<constant>EPOLLET</constant>). See <citerefentry><refentrytitle>sd_event_add_io</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para></listitem>
+
+      <listitem><para>Timer event sources, based on <citerefentry
+      project='man-pages'><refentrytitle>timerfd_create</refentrytitle><manvolnum>2</manvolnum></citerefentry>,
+      supporting the <constant>CLOCK_MONOTONIC</constant>,
+      <constant>CLOCK_REALTIME</constant>,
+      <constant>CLOCK_BOOTTIME</constant> clocks, as well as the
+      <constant>CLOCK_REALTIME_ALARM</constant> and
+      <constant>CLOCK_BOOTTIME_ALARM</constant> clocks that can resume
+      the system from suspend. When creating timer events a required
+      accuracy parameter may be specified which allows coalescing of
+      timer events to minimize power consumption. See <citerefentry><refentrytitle>sd_event_add_time</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para></listitem>
+
+      <listitem><para>UNIX process signal events, based on
+      <citerefentry
+      project='man-pages'><refentrytitle>signalfd</refentrytitle><manvolnum>2</manvolnum></citerefentry>,
+      including full support for real-time signals, and queued parameters. See <citerefentry><refentrytitle>sd_event_add_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para></listitem>
+
+      <listitem><para>Child process state change events, based on
+      <citerefentry project='man-pages'><refentrytitle>waitid</refentrytitle><manvolnum>2</manvolnum></citerefentry>. See <citerefentry><refentrytitle>sd_event_add_child</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para></listitem>
+
+      <listitem><para>Static event sources, of three types: defer,
+      post and exit, for invoking calls in each event loop, after
+      other event sources or at event loop termination. See
+      <citerefentry><refentrytitle>sd_event_add_defer</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para></listitem>
+
+      <listitem><para>Event sources may be assigned a 64-bit priority
+      value, that controls the order in which event sources are
+      dispatched if multiple are pending simultaneously. See
+      <citerefentry><refentrytitle>sd_event_source_set_priority</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para></listitem>
+
+      <listitem><para>The event loop may automatically send watchdog
+      notification messages to the service manager. See
+      <citerefentry><refentrytitle>sd_event_set_watchdog</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para></listitem>
+
+      <listitem><para>The event loop may be integrated into foreign
+      event loops, such as the GLib one. See
+      <citerefentry><refentrytitle>sd_event_get_fd</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+      for an example.</para></listitem>
+    </orderedlist>
+
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_run</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_io</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_time</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_child</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_inotify</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_defer</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_memory_pressure</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_source_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_source_set_priority</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_source_set_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_source_set_userdata</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_source_get_event</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_source_get_pending</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_source_set_description</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_source_set_prepare</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_source_set_ratelimit</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_wait</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_get_fd</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_set_watchdog</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_exit</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_now</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>epoll</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>timerfd_create</refentrytitle><manvolnum>2</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>signalfd</refentrytitle><manvolnum>2</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>waitid</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd-hwdb.xml b/man/sd-hwdb.xml
new file mode 100644
index 0000000..189fcd6
--- /dev/null
+++ b/man/sd-hwdb.xml
@@ -0,0 +1,59 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd-hwdb" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd-hwdb</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd-hwdb</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd-hwdb</refname>
+    <refpurpose>Read-only access to the hardware description database</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-hwdb.h&gt;</funcsynopsisinfo>
+    </funcsynopsis>
+
+    <cmdsynopsis>
+      <command>pkg-config --cflags --libs libsystemd</command>
+    </cmdsynopsis>
+
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><filename>sd-hwdb.h</filename> is part of
+    <citerefentry><refentrytitle>libsystemd</refentrytitle><manvolnum>3</manvolnum></citerefentry> and allows
+    read-only access the systemd database of hardware properties. See
+    <citerefentry><refentrytitle>hwdb</refentrytitle><manvolnum>7</manvolnum></citerefentry> and
+    <citerefentry><refentrytitle>systemd-hwdb</refentrytitle><manvolnum>8</manvolnum></citerefentry> for more
+    information about the database.</para>
+
+    <para>See <citerefentry><refentrytitle>sd_hwdb_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    and <citerefentry><refentrytitle>sd_hwdb_get</refentrytitle><manvolnum>3</manvolnum></citerefentry> for
+    information about the functions available.</para>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-udevd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd-id128.xml b/man/sd-id128.xml
new file mode 100644
index 0000000..d264220
--- /dev/null
+++ b/man/sd-id128.xml
@@ -0,0 +1,296 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd-id128"
+  xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd-id128</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd-id128</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd-id128</refname>
+    <refname>SD_ID128_ALLF</refname>
+    <refname>SD_ID128_CONST_STR</refname>
+    <refname>SD_ID128_FORMAT_STR</refname>
+    <refname>SD_ID128_FORMAT_VAL</refname>
+    <refname>SD_ID128_MAKE</refname>
+    <refname>SD_ID128_MAKE_STR</refname>
+    <refname>SD_ID128_MAKE_UUID_STR</refname>
+    <refname>SD_ID128_NULL</refname>
+    <refname>SD_ID128_UUID_FORMAT_STR</refname>
+    <refname>sd_id128_equal</refname>
+    <refname>sd_id128_string_equal</refname>
+    <refname>sd_id128_in_set</refname>
+    <refname>sd_id128_in_set_sentinel</refname>
+    <refname>sd_id128_in_setv</refname>
+    <refname>sd_id128_is_allf</refname>
+    <refname>sd_id128_is_null</refname>
+    <refname>sd_id128_t</refname>
+    <refpurpose>APIs for processing 128-bit IDs</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-id128.h&gt;</funcsynopsisinfo>
+
+      <para>
+        <constant>SD_ID128_ALLF</constant>
+      </para>
+      <para>
+        <constant>SD_ID128_NULL</constant>
+      </para>
+      <para>
+        <constant>SD_ID128_CONST_STR(<replaceable>id</replaceable>)</constant>
+      </para>
+      <para>
+        <constant>SD_ID128_FORMAT_STR</constant>
+      </para>
+      <para>
+        <constant>SD_ID128_FORMAT_VAL(<replaceable>id</replaceable>)</constant>
+      </para>
+      <para>
+        <constant>SD_ID128_MAKE(<replaceable>v0</replaceable>, <replaceable>v1</replaceable>, <replaceable>v2</replaceable>, <replaceable>v3</replaceable>, <replaceable>v4</replaceable>, <replaceable>v5</replaceable>, <replaceable>v6</replaceable>, <replaceable>v7</replaceable>, <replaceable>v8</replaceable>, <replaceable>v9</replaceable>, <replaceable>vA</replaceable>, <replaceable>vB</replaceable>, <replaceable>vC</replaceable>, <replaceable>vD</replaceable>, <replaceable>vE</replaceable>, <replaceable>vF</replaceable>)</constant>
+      </para>
+      <para>
+        <constant>SD_ID128_MAKE_STR(<replaceable>v0</replaceable>, <replaceable>v1</replaceable>, <replaceable>v2</replaceable>, <replaceable>v3</replaceable>, <replaceable>v4</replaceable>, <replaceable>v5</replaceable>, <replaceable>v6</replaceable>, <replaceable>v7</replaceable>, <replaceable>v8</replaceable>, <replaceable>v9</replaceable>, <replaceable>vA</replaceable>, <replaceable>vB</replaceable>, <replaceable>vC</replaceable>, <replaceable>vD</replaceable>, <replaceable>vE</replaceable>, <replaceable>vF</replaceable>)</constant>
+      </para>
+      <para>
+        <constant>SD_ID128_MAKE_UUID_STR(<replaceable>v0</replaceable>, <replaceable>v1</replaceable>, <replaceable>v2</replaceable>, <replaceable>v3</replaceable>, <replaceable>v4</replaceable>, <replaceable>v5</replaceable>, <replaceable>v6</replaceable>, <replaceable>v7</replaceable>, <replaceable>v8</replaceable>, <replaceable>v9</replaceable>, <replaceable>vA</replaceable>, <replaceable>vB</replaceable>, <replaceable>vC</replaceable>, <replaceable>vD</replaceable>, <replaceable>vE</replaceable>, <replaceable>vF</replaceable>)</constant>
+      </para>
+      <para>
+        <constant>SD_ID128_UUID_FORMAT_STR</constant>
+      </para>
+
+      <funcprototype>
+        <funcdef>int <function>sd_id128_equal</function></funcdef>
+        <paramdef>sd_id128_t <parameter>a</parameter></paramdef>
+        <paramdef>sd_id128_t <parameter>b</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_id128_string_equal</function></funcdef>
+        <paramdef>const char *<parameter>a</parameter></paramdef>
+        <paramdef>sd_id128_t <parameter>b</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_id128_is_null</function></funcdef>
+        <paramdef>sd_id128_t <parameter>id</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_id128_is_allf</function></funcdef>
+        <paramdef>sd_id128_t <parameter>id</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_id128_in_setv</function></funcdef>
+        <paramdef>sd_id128_t <parameter>id</parameter></paramdef>
+        <paramdef>va_list <parameter>ap</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_id128_in_set_sentinel</function></funcdef>
+        <paramdef>sd_id128_t <parameter>id</parameter></paramdef>
+        <paramdef>…</paramdef>
+        <paramdef><constant>SD_ID128_NULL</constant></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_id128_in_set</function></funcdef>
+        <paramdef>sd_id128_t <parameter>id</parameter></paramdef>
+        <paramdef>…</paramdef>
+      </funcprototype>
+    </funcsynopsis>
+
+    <cmdsynopsis>
+      <command>pkg-config --cflags --libs libsystemd</command>
+    </cmdsynopsis>
+
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><filename>sd-id128.h</filename> is part of
+    <citerefentry><refentrytitle>libsystemd</refentrytitle><manvolnum>3</manvolnum></citerefentry> and
+    provides APIs to generate, convert, and compare 128-bit ID values. The 128-bit ID values processed and
+    generated by these APIs are a generalization of OSF UUIDs as defined by <ulink
+    url="https://tools.ietf.org/html/rfc4122">RFC 4122</ulink> but use a simpler string format. These
+    functions impose no structure on the used IDs, much unlike OSF UUIDs or Microsoft GUIDs, but are mostly
+    compatible with those types of IDs.
+    </para>
+
+    <para>A 128-bit ID is implemented as the following
+    union type:</para>
+
+    <programlisting>typedef union sd_id128 {
+  uint8_t bytes[16];
+  uint64_t qwords[2];
+} sd_id128_t;</programlisting>
+
+    <para>This union type allows accessing the 128-bit ID as 16 separate bytes or two 64-bit words. It is
+    generally safer to access the ID components by their 8-bit array to avoid endianness issues. This union
+    is intended to be passed by value (as opposed to pass-by-reference) and may be directly manipulated by
+    clients.</para>
+
+    <para>A couple of macros are defined to denote and decode 128-bit
+    IDs:</para>
+
+    <para><function>SD_ID128_MAKE()</function> is used to write a constant ID in source code. A commonly used
+    idiom is to assign a name to an ID using this macro:</para>
+
+    <programlisting>#define SD_MESSAGE_COREDUMP SD_ID128_MAKE(fc,2e,22,bc,6e,e6,47,b6,b9,07,29,ab,34,a2,50,b1)</programlisting>
+
+    <para><constant>SD_ID128_NULL</constant> defines an ID consisting of only <constant>NUL</constant> bytes
+    (i.e. all bits off).</para>
+
+    <para><constant>SD_ID128_ALLF</constant> defines an ID consisting of only <constant>0xFF</constant> bytes
+    (i.e. all bits on).</para>
+
+    <para><function>SD_ID128_MAKE_STR()</function> is similar to <function>SD_ID128_MAKE()</function>, but
+    creates a <type>const char*</type> expression that can be conveniently used in message formats and
+    such:</para>
+
+    <programlisting>#include &lt;stdio.h&gt;
+#define SD_MESSAGE_COREDUMP_STR SD_ID128_MAKE_STR(fc,2e,22,bc,6e,e6,47,b6,b9,07,29,ab,34,a2,50,b1)
+
+int main(int argc, char **argv) {
+  puts("Match for coredumps: MESSAGE_ID=" SD_MESSAGE_COREDUMP_STR);
+}</programlisting>
+
+    <para><function>SD_ID128_CONST_STR()</function> converts constant IDs into constant strings for
+    output. The following example code will output the string "fc2e22bc6ee647b6b90729ab34a250b1":</para>
+    <programlisting>int main(int argc, char *argv[]) {
+  puts("Match for coredumps: %s", SD_ID128_CONST_STR(SD_MESSAGE_COREDUMP));
+}</programlisting>
+
+    <para><constant>SD_ID128_FORMAT_STR</constant> and <function>SD_ID128_FORMAT_VAL()</function> is used to
+    format an ID in a <citerefentry
+    project='man-pages'><refentrytitle>printf</refentrytitle><manvolnum>3</manvolnum></citerefentry> format
+    string, as shown in the following example:</para>
+
+    <programlisting>int main(int argc, char *argv[]) {
+  sd_id128_t id;
+  id = SD_ID128_MAKE(ee,89,be,71,bd,6e,43,d6,91,e6,c5,5d,eb,03,02,07);
+  printf("The ID encoded in this C file is " SD_ID128_FORMAT_STR ".\n", SD_ID128_FORMAT_VAL(id));
+  return 0;
+}</programlisting>
+
+    <para><constant>SD_ID128_UUID_FORMAT_STR</constant> and <function>SD_ID128_MAKE_UUID_STR()</function>
+    are similar to
+    <constant>SD_ID128_FORMAT_STR</constant> and <function>SD_ID128_MAKE_STR()</function>,
+    but include separating hyphens to conform to the
+    "<ulink url="https://en.wikipedia.org/wiki/Universally_unique_identifier#Format">UUID canonical representation</ulink>".
+    They format the string based on <ulink
+    url="https://tools.ietf.org/html/rfc4122">RFC4122</ulink> Variant 1 rules, i.e. converting from Big
+    Endian byte order. This matches behaviour of most other Linux userspace infrastructure. It's probably
+    best to avoid UUIDs of other variants, in order to avoid unnecessary ambiguities. All 128-bit IDs
+    generated by the sd-id128 APIs strictly conform to Variant 1 Version 4 UUIDs, as per RFC 4122.</para>
+
+    <para><function>sd_id128_equal()</function> compares two 128-bit IDs:</para>
+
+    <programlisting>int main(int argc, char *argv[]) {
+  sd_id128_t a, b, c;
+  a = SD_ID128_MAKE(ee,89,be,71,bd,6e,43,d6,91,e6,c5,5d,eb,03,02,07);
+  b = SD_ID128_MAKE(f2,28,88,9c,5f,09,44,15,9d,d7,04,77,58,cb,e7,3e);
+  c = a;
+  assert(sd_id128_equal(a, c));
+  assert(!sd_id128_equal(a, b));
+  return 0;
+}</programlisting>
+
+    <para><function>sd_id128_string_equal()</function> is similar to <function>sd_id128_equal()</function>,
+    but the first ID is formatted as <type>const char*</type>. The same restrictions apply as to the first
+    argument of <function>sd_id128_from_string()</function>.</para>
+
+    <para><function>sd_id128_is_null()</function> checks if an ID consists of only <constant>NUL</constant>
+    bytes:</para>
+
+    <programlisting>assert(sd_id128_is_null(SD_ID128_NULL));</programlisting>
+
+    <para>Similarly, <function>sd_id128_is_allf()</function> checks if an ID consists of only
+    <constant>0xFF</constant> bytes (all bits on):</para>
+
+    <programlisting>assert(sd_id128_is_allf(SD_ID128_ALLF));</programlisting>
+
+    <para><function>sd_id128_in_set_sentinel()</function> takes a list of IDs and returns true if the first
+    argument is equal to any of the subsequent arguments. The argument list is terminated by an
+    <constant>SD_ID128_NULL</constant> sentinel, which must be present.</para>
+
+    <para><function>sd_id128_in_set()</function> is a convenience function that takes a list of IDs and
+    returns true if the first argument is equal to any of the subsequent arguments:</para>
+
+    <programlisting>int main(int argc, char *argv[]) {
+  sd_id12_t a = SD_ID128_MAKE(ee,89,be,71,bd,6e,43,d6,91,e6,c5,5d,eb,03,02,07);
+  assert(sd_id128_in_set(a, a));
+  assert(sd_id128_in_set(a, a, a));
+  assert(!sd_id128_in_set(a));
+  assert(!sd_id128_in_set(a,
+                          SD_ID128_MAKE(f2,28,88,9c,5f,09,44,15,9d,d7,04,77,58,cb,e7,3e)
+                          SD_ID128_MAKE(2f,88,28,5f,9c,44,09,9d,d7,15,77,04,bc,85,7e,e3)
+                          SD_ID128_ALLF));
+  return 0;
+}
+</programlisting>
+
+    <para><function>sd_id128_in_set()</function> is defined as a macro over
+    <function>sd_id128_in_set_sentinel()</function>, adding the <constant>SD_ID128_NULL</constant> sentinel
+    automatically. Since <function>sd_id128_in_set_sentinel()</function> uses
+    <constant>SD_ID128_NULL</constant> as the sentinel, <constant>SD_ID128_NULL</constant> cannot be
+    otherwise placed in the argument list.</para>
+
+    <para><function>sd_id128_in_setv()</function> is similar to
+    <function>sd_id128_in_set_sentinel()</function>, but takes a <structname>struct varargs</structname>
+    argument.</para>
+
+    <para>New randomized IDs may be generated with
+    <citerefentry><refentrytitle>systemd-id128</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s
+    <command>new</command> command.</para>
+
+    <para>See
+    <citerefentry><refentrytitle>sd_id128_to_string</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_id128_randomize</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    and
+    <citerefentry><refentrytitle>sd_id128_get_machine</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    for information about other implemented functions.</para>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_id128_equal()</function>,
+    <function>sd_id128_string_equal()</function>,
+    <function>sd_id128_is_null()</function>,
+    <function>sd_id128_is_allf()</function>,
+    <function>sd_id128_in_setv()</function>,
+    <function>sd_id128_in_set_sentinel()</function>, and
+    <function>sd_id128_in_set()</function> were added in version 252.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_id128_to_string</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_id128_randomize</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_id128_get_machine</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>printf</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-journal</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry project='die-net'><refentrytitle>pkg-config</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd-journal.xml b/man/sd-journal.xml
new file mode 100644
index 0000000..34debb4
--- /dev/null
+++ b/man/sd-journal.xml
@@ -0,0 +1,119 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd-journal"
+  xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd-journal</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd-journal</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd-journal</refname>
+    <refpurpose>APIs for submitting and querying log entries to and
+    from the journal</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-journal.h&gt;</funcsynopsisinfo>
+    </funcsynopsis>
+
+    <cmdsynopsis>
+      <command>pkg-config --cflags --libs libsystemd</command>
+    </cmdsynopsis>
+
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><filename>sd-journal.h</filename> is part of
+    <citerefentry><refentrytitle>libsystemd</refentrytitle><manvolnum>3</manvolnum></citerefentry> and
+    provides APIs to submit and query log entries. The APIs exposed act both as client for the
+    <citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    journal service and as parser for the journal files on disk.
+    </para>
+
+    <para>See
+    <citerefentry><refentrytitle>sd_journal_print</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_journal_stream_fd</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_journal_open</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_journal_next</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_journal_get_realtime_usec</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_journal_add_match</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_journal_seek_head</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_journal_enumerate_fields</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_journal_get_cursor</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_journal_get_cutoff_realtime_usec</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_journal_get_cutoff_monotonic_usec</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_journal_get_usage</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_journal_get_catalog</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_journal_get_fd</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_journal_has_runtime_files</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    and
+    <citerefentry><refentrytitle>sd_journal_has_persistent_files</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    for more information about the functions implemented.</para>
+
+    <para>Command line access for submitting entries to the journal is
+    available with the
+    <citerefentry><refentrytitle>systemd-cat</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    tool. Command line access for querying entries from the journal is
+    available with the
+    <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    tool.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Thread safety</title>
+
+    <para>Functions that operate on <structname>sd_journal</structname> objects are thread agnostic — given
+    <structname>sd_journal</structname> pointer may only be used from one specific thread at all times (and it has to
+    be the very same one during the entire lifetime of the object), but multiple, independent threads may use multiple,
+    independent objects safely. Other functions — those that are used to send entries to the journal, like
+    <citerefentry><refentrytitle>sd_journal_print</refentrytitle><manvolnum>3</manvolnum></citerefentry> and similar,
+    or those that are used to retrieve global information like
+    <citerefentry><refentrytitle>sd_journal_stream_fd</refentrytitle><manvolnum>3</manvolnum></citerefentry> and
+    <citerefentry><refentrytitle>sd_journal_get_catalog_for_message_id</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    — are fully thread-safe and may be called from multiple threads in parallel.</para>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_journal_print</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_journal_stream_fd</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_journal_open</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_journal_next</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_journal_get_data</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_journal_get_realtime_usec</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_journal_add_match</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_journal_seek_head</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_journal_enumerate_fields</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_journal_get_cursor</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_journal_get_cutoff_realtime_usec</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_journal_get_cutoff_monotonic_usec</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_journal_get_usage</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_journal_get_fd</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_journal_query_unique</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_journal_get_catalog</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_journal_has_runtime_files</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_journal_has_persistent_files</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-id128</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry project='die-net'><refentrytitle>pkg-config</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd-login.xml b/man/sd-login.xml
new file mode 100644
index 0000000..13035df
--- /dev/null
+++ b/man/sd-login.xml
@@ -0,0 +1,262 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd-login" conditional='HAVE_PAM'
+  xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd-login</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd-login</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd-login</refname>
+    <refpurpose>APIs for
+    tracking logins</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-login.h&gt;</funcsynopsisinfo>
+    </funcsynopsis>
+
+    <cmdsynopsis>
+      <command>pkg-config --cflags --libs libsystemd</command>
+    </cmdsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><filename>sd-login.h</filename> is part of
+    <citerefentry><refentrytitle>libsystemd</refentrytitle><manvolnum>3</manvolnum></citerefentry> and
+    provides APIs to introspect and monitor seat, login session, and user status information on the local
+    system.</para>
+
+    <para>Note that these APIs only allow purely passive access and
+    monitoring of seats, sessions and users. To actively make changes
+    to the seat configuration, terminate login sessions, or switch
+    session on a seat you need to utilize the D-Bus API of
+    systemd-logind, instead.</para>
+
+    <para>These functions synchronously access data in
+    <filename>/proc/</filename>, <filename>/sys/fs/cgroup/</filename>
+    and <filename>/run/</filename>. All of these are virtual file
+    systems, hence the runtime cost of the accesses is relatively
+    cheap.</para>
+
+    <para>It is possible (and often a very good choice) to mix calls
+    to the synchronous interface of <filename>sd-login.h</filename>
+    with the asynchronous D-Bus interface of systemd-logind. However,
+    if this is done you need to think a bit about possible races since
+    the stream of events from D-Bus and from
+    <filename>sd-login.h</filename> interfaces such as the login
+    monitor are asynchronous and not ordered against each
+    other.</para>
+
+    <para>If the functions return string arrays, these are generally
+    <constant>NULL</constant> terminated and need to be freed by the
+    caller with the libc
+    <citerefentry project='man-pages'><refentrytitle>free</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    call after use, including the strings referenced therein.
+    Similarly, individual strings returned need to be freed, as
+    well.</para>
+
+    <para>As a special exception, instead of an empty string array
+    <constant>NULL</constant> may be returned, which should be treated
+    equivalent to an empty string array.</para>
+
+    <para>See
+    <citerefentry><refentrytitle>sd_pid_get_session</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_uid_get_state</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_session_is_active</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_seat_get_active</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_get_seats</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_login_monitor_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    for more information about the functions
+    implemented.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Definition of Terms</title>
+
+    <variablelist>
+      <varlistentry>
+        <term>seat</term>
+
+        <listitem><para>A seat consists of all hardware devices assigned to a specific
+        workplace. It consists of at least one graphics device, and usually also includes
+        keyboard, mouse. It can also include video cameras, sound cards and more. Seats
+        are identified by seat names, which are strings (&lt;= 255 characters), that start
+        with the four characters <literal>seat</literal> followed by at least one
+        character from the range [a-zA-Z0-9], <literal>_</literal> and
+        <literal>-</literal>. They are suitable for use as file names. Seat names may or
+        may not be stable and may be reused if a seat becomes available again.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v235"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term>session</term>
+
+        <listitem><para>A session is defined by the time a user is logged in until they
+        log out. A session is bound to one or no seats (the latter for 'virtual' ssh
+        logins). Multiple sessions can be attached to the same seat, but only one of them
+        can be active, the others are in the background. A session is identified by a
+        short string.</para>
+
+        <para>
+        <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+        ensures that audit sessions are identical to systemd sessions, and uses the audit
+        session ID as session ID in systemd (if auditing is enabled). In general the
+        session identifier is a short string consisting only of [a-zA-Z0-9],
+        <literal>_</literal> and <literal>-</literal>, suitable for use as a file name.
+        Session IDs are unique on the local machine and are
+        never reused as long as the machine is online. A user (the way we know it on UNIX)
+        corresponds to the person using a computer. A single user can have multiple
+        sessions open at the same time. A user is identified by a numeric user id (UID) or
+        a user name (a string). A multi-session system allows multiple user sessions on
+        the same seat at the same time. A multi-seat system allows multiple independent
+        seats that can be individually and simultaneously used by different users.</para>
+
+        <xi:include href="version-info.xml" xpointer="v235"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+
+    <para>All hardware devices that are eligible to being assigned to a seat, are assigned
+    to one. A device can be assigned to only one seat at a time. If a device is not
+    assigned to any particular other seat it is implicitly assigned to the special default
+    seat called <literal>seat0</literal>.</para>
+
+    <para>Note that hardware like printers, hard disks or network cards is generally not
+    assigned to a specific seat. They are available to all seats equally. (Well, with one
+    exception: USB sticks can be assigned to a seat.)</para>
+
+    <para><literal>seat0</literal> always exists.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>udev Rules</title>
+
+    <para>Assignment of hardware devices to seats is managed inside the udev database, via
+    settings on the devices:</para>
+
+    <variablelist class='udev-directives'>
+      <varlistentry>
+        <term>Tag <literal>seat</literal></term>
+
+        <listitem><para>When set, a device is eligible to be assigned to a seat. This tag
+        is set for graphics devices, mice, keyboards, video cards, sound cards and
+        more. Note that some devices like sound cards consist of multiple subdevices
+        (i.e. a PCM for input and another one for output). This tag will be set only for
+        the originating device, not for the individual subdevices. A UI for configuring
+        assignment of devices to seats should enumerate and subscribe to all devices with
+        this tag set and show them in the UI. Note that USB hubs can be assigned to a seat
+        as well, in which case all (current and future) devices plugged into it will also
+        be assigned to the same seat (unless they are explicitly assigned to another
+        seat).
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v235"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term>Tag <literal>master-of-seat</literal></term>
+
+        <listitem><para>When set, this device is enough for a seat to be considered
+        existent. This tag is usually set for the framebuffer device of graphics cards. A
+        seat hence consists of an arbitrary number of devices marked with the
+        <literal>seat</literal> tag, but (at least) one of these devices needs to be
+        tagged with <literal>master-of-seat</literal> before the seat is actually
+        considered to be around.</para>
+
+        <xi:include href="version-info.xml" xpointer="v235"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term>Property <varname>ID_SEAT</varname></term>
+
+        <listitem><para>This property specifies the name of the seat a specific device is
+        assigned to. If not set the device is assigned to <literal>seat0</literal>. Also,
+        to speed up enumeration of hardware belonging to a specific seat, the seat is also
+        set as tag on the device. I.e. if the property
+        <varname>ID_SEAT=seat-waldo</varname> is set for a device, the tag
+        <literal>seat-waldo</literal> will be set as well. Note that if a device is
+        assigned to <literal>seat0</literal>, it will usually not carry such a tag and you
+        need to enumerate all devices and check the <varname>ID_SEAT</varname> property
+        manually. Again, if a device is assigned to seat0 this is visible on the device in
+        two ways: with a property <varname>ID_SEAT=seat0</varname> and with no property
+        <varname>ID_SEAT</varname> set for it at all.</para>
+
+        <xi:include href="version-info.xml" xpointer="v235"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term>Property <varname>ID_AUTOSEAT</varname></term>
+
+        <listitem><para>When set to <literal>1</literal>, this device automatically
+        generates a new and independent seat, which is named after the path of the
+        device. This is set for specialized USB hubs like the Pluggable devices, which when
+        plugged in should create a hotplug seat without further configuration.</para>
+
+        <xi:include href="version-info.xml" xpointer="v235"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term>Property <varname>ID_FOR_SEAT</varname></term>
+
+        <listitem><para>When creating additional (manual) seats starting from a graphics
+        device this is a good choice to name the seat after. It is created from the path
+        of the device. This is useful in UIs for configuring seats: as soon as you create
+        a new seat from a graphics device, read this property and prefix it with
+        <literal>seat-</literal> and use it as name for the seat.</para>
+
+        <xi:include href="version-info.xml" xpointer="v235"/></listitem>
+      </varlistentry>
+    </variablelist>
+
+    <para>A seat exists only and exclusively because a properly tagged device with the
+    right <varname>ID_SEAT</varname> property exists. Besides udev rules there is no
+    persistent data about seats stored on disk.</para>
+
+    <para>Note that
+    <citerefentry><refentrytitle>systemd-logind</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    manages ACLs on a number of device classes, to allow user code to access the device
+    nodes attached to a seat as long as the user has an active session on it. This is
+    mostly transparent to applications. As mentioned above, for certain user software it
+    might be a good idea to watch whether they can access device nodes instead of thinking
+    about seats.</para>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_pid_get_session</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_uid_get_state</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_session_is_active</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_seat_get_active</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_get_seats</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_login_monitor_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-daemon</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry project='die-net'><refentrytitle>pkg-config</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    </para>
+
+    <para>
+      <ulink url="https://www.freedesktop.org/wiki/Software/systemd/multiseat">Multi-Seat on Linux</ulink>
+      may also be of historical interest.
+    </para>
+  </refsect1>
+</refentry>
diff --git a/man/sd_booted.xml b/man/sd_booted.xml
new file mode 100644
index 0000000..d9b3ddc
--- /dev/null
+++ b/man/sd_booted.xml
@@ -0,0 +1,68 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_booted"
+  xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_booted</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_booted</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_booted</refname>
+    <refpurpose>Test whether the system is running the systemd init system</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-daemon.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_booted</function></funcdef>
+        <paramdef>void</paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+    <para><function>sd_booted()</function> checks whether the system
+    was booted up using the systemd init system.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On failure, this call returns a negative errno-style error
+    code. If the system was booted up with systemd as init system,
+    this call returns a positive return value, zero otherwise.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Notes</title>
+
+    <xi:include href="libsystemd-pkgconfig.xml" xpointer="pkgconfig-text"/>
+
+    <para>Internally, this function checks whether the directory
+    <filename>/run/systemd/system/</filename> exists. A simple check
+    like this can also be implemented trivially in shell or any other
+    language.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-daemon</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_bus_add_match.xml b/man/sd_bus_add_match.xml
new file mode 100644
index 0000000..15376d4
--- /dev/null
+++ b/man/sd_bus_add_match.xml
@@ -0,0 +1,178 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+
+<!--
+  SPDX-License-Identifier: LGPL-2.1-or-later
+
+  Copyright © 2016 Julian Orth
+-->
+
+<refentry id="sd_bus_add_match" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_bus_add_match</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_add_match</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_add_match</refname>
+    <refname>sd_bus_add_match_async</refname>
+    <refname>sd_bus_match_signal</refname>
+    <refname>sd_bus_match_signal_async</refname>
+
+    <refpurpose>Add a match rule for incoming message dispatching</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <funcprototype id="sd_bus_message_handler_t">
+        <funcdef>typedef int (*<function>sd_bus_message_handler_t</function>)</funcdef>
+        <paramdef>sd_bus_message *<parameter>m</parameter></paramdef>
+        <paramdef>void *<parameter>userdata</parameter></paramdef>
+        <paramdef>sd_bus_error *<parameter>ret_error</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_add_match</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>sd_bus_slot **<parameter>slot</parameter></paramdef>
+        <paramdef>const char *<parameter>match</parameter></paramdef>
+        <paramdef>sd_bus_message_handler_t <parameter>callback</parameter></paramdef>
+        <paramdef>void *<parameter>userdata</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_add_match_async</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>sd_bus_slot **<parameter>slot</parameter></paramdef>
+        <paramdef>const char *<parameter>match</parameter></paramdef>
+        <paramdef>sd_bus_message_handler_t <parameter>callback</parameter></paramdef>
+        <paramdef>sd_bus_message_handler_t <parameter>install_callback</parameter></paramdef>
+        <paramdef>void *<parameter>userdata</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_match_signal</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>sd_bus_slot **<parameter>slot</parameter></paramdef>
+        <paramdef>const char *<parameter>sender</parameter></paramdef>
+        <paramdef>const char *<parameter>path</parameter></paramdef>
+        <paramdef>const char *<parameter>interface</parameter></paramdef>
+        <paramdef>const char *<parameter>member</parameter></paramdef>
+        <paramdef>sd_bus_message_handler_t <parameter>callback</parameter></paramdef>
+        <paramdef>void *<parameter>userdata</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_match_signal_async</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>sd_bus_slot **<parameter>slot</parameter></paramdef>
+        <paramdef>const char *<parameter>sender</parameter></paramdef>
+        <paramdef>const char *<parameter>path</parameter></paramdef>
+        <paramdef>const char *<parameter>interface</parameter></paramdef>
+        <paramdef>const char *<parameter>member</parameter></paramdef>
+        <paramdef>sd_bus_message_handler_t <parameter>callback</parameter></paramdef>
+        <paramdef>sd_bus_message_handler_t <parameter>install_callback</parameter></paramdef>
+        <paramdef>void *<parameter>userdata</parameter></paramdef>
+      </funcprototype>
+
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_bus_add_match()</function> installs a match rule for messages received on the specified bus
+    connection object <parameter>bus</parameter>. The syntax of the match rule expression passed in
+    <parameter>match</parameter> is described in the <ulink
+    url="https://dbus.freedesktop.org/doc/dbus-specification.html">D-Bus Specification</ulink>. The specified handler
+    function <parameter>callback</parameter> is called for each incoming message matching the specified expression,
+    the <parameter>userdata</parameter> parameter is passed as-is to the callback function. The match is installed
+    synchronously when connected to a bus broker, i.e. the call sends a control message requested the match to be added
+    to the broker and waits until the broker confirms the match has been installed successfully.</para>
+
+    <para><function>sd_bus_add_match_async()</function> operates very similarly to
+    <function>sd_bus_add_match()</function>, however it installs the match asynchronously, in a non-blocking
+    fashion: a request is sent to the broker, but the call does not wait for a response. The
+    <parameter>install_callback</parameter> function is called when the response is later received, with the response
+    message from the broker as parameter. If this function is specified as <constant>NULL</constant> a default
+    implementation is used that terminates the bus connection should installing the match fail.</para>
+
+    <para><function>sd_bus_match_signal()</function> is very similar to <function>sd_bus_add_match()</function>, but
+    only matches signals, and instead of a match expression accepts four parameters: <parameter>sender</parameter> (the
+    service name of the sender), <parameter>path</parameter> (the object path of the emitting object),
+    <parameter>interface</parameter> (the interface the signal belongs to), <parameter>member</parameter> (the signal
+    name), from which the match string is internally generated. Optionally, these parameters may be specified as
+    <constant>NULL</constant> in which case the relevant field of incoming signals is not tested.</para>
+
+    <para><function>sd_bus_match_signal_async()</function> combines the signal matching logic of
+    <function>sd_bus_match_signal()</function> with the asynchronous behaviour of
+    <function>sd_bus_add_match_async()</function>.</para>
+
+    <para>On success, and if non-<constant>NULL</constant>, the <parameter>slot</parameter> return parameter will be
+    set to a slot object that may be used as a reference to the installed match, and may be utilized to remove it again
+    at a later time with
+    <citerefentry><refentrytitle>sd_bus_slot_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry>. If specified
+    as <constant>NULL</constant> the lifetime of the match is bound to the lifetime of the bus object itself, and the
+    match is generally not removed independently. See
+    <citerefentry><refentrytitle>sd_bus_slot_set_floating</refentrytitle><manvolnum>3</manvolnum></citerefentry> for
+    details.</para>
+
+    <para>The message <parameter>m</parameter> passed to the callback is only borrowed, that is, the callback should
+    not call <citerefentry><refentrytitle>sd_bus_message_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    on it. If the callback wants to hold on to the message beyond the lifetime of the callback, it needs to call
+    <citerefentry><refentrytitle>sd_bus_message_ref</refentrytitle><manvolnum>3</manvolnum></citerefentry> to create a
+    new reference.</para>
+
+    <para>If an error occurs during the callback invocation, the callback should return a negative error number
+    (optionally, a more precise error may be returned in <parameter>ret_error</parameter>, as well). If it wants other
+    callbacks that match the same rule to be called, it should return 0. Otherwise it should return a positive integer.
+    </para>
+
+    <para>If the <parameter>bus</parameter> refers to a direct connection (i.e. not a bus connection, as set with
+    <citerefentry><refentrytitle>sd_bus_set_bus_client</refentrytitle><manvolnum>3</manvolnum></citerefentry>) the
+    match is only installed on the client side, and the synchronous and asynchronous functions operate the same.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>
+      On success, <function>sd_bus_add_match()</function> and the other calls return 0 or a positive integer. On
+      failure, they return a negative errno-style error code.
+    </para>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_bus_add_match()</function> and
+    <function>sd_bus_message_handler_t()</function> were added in version 231.</para>
+    <para><function>sd_bus_add_match_async()</function>,
+    <function>sd_bus_match_signal()</function>, and
+    <function>sd_bus_match_signal_async()</function> were added in version 237.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_slot_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_message_ref</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_set_bus_client</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_slot_set_floating</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_bus_add_node_enumerator.xml b/man/sd_bus_add_node_enumerator.xml
new file mode 100644
index 0000000..f97746c
--- /dev/null
+++ b/man/sd_bus_add_node_enumerator.xml
@@ -0,0 +1,152 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_bus_add_node_enumerator"
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_bus_add_node_enumerator</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_add_node_enumerator</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_add_node_enumerator</refname>
+
+    <refpurpose>Add a node enumerator for a D-Bus object path prefix</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>typedef int (*<function>sd_bus_node_enumerator_t</function>)</funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>const char *<parameter>prefix</parameter></paramdef>
+        <paramdef>void *<parameter>userdata</parameter></paramdef>
+        <paramdef>char ***<parameter>ret_nodes</parameter></paramdef>
+        <paramdef>sd_bus_error *<parameter>ret_error</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_add_node_enumerator</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>sd_bus_slot **<parameter>slot</parameter></paramdef>
+        <paramdef>const char *<parameter>path</parameter></paramdef>
+        <paramdef>sd_bus_node_enumerator_t <parameter>callback</parameter></paramdef>
+        <paramdef>void *<parameter>userdata</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_bus_add_node_enumerator()</function> adds a D-Bus node enumerator for the
+    given path prefix. The given callback is called to enumerate all the available objects with
+    the given path prefix when required (e.g. when
+    <constant>org.freedesktop.DBus.Introspectable.Introspect</constant> or
+    <constant>org.freedesktop.DBus.ObjectManager.GetManagedObjects</constant> are called on a
+    D-Bus service managed by sd-bus).</para>
+
+    <para><parameter>callback</parameter> is called with the path and userdata pointer registered
+    with <function>sd_bus_add_node_enumerator()</function>. When called, it should store all the
+    child object paths of the given path prefix in <parameter>ret_nodes</parameter> with a NULL
+    terminator item. The callback should return a non-negative value on success.
+    If an error occurs, it can either return a
+    negative integer, set <parameter>ret_error</parameter> to a non-empty error or do both. Any
+    errors returned by the callback are encoded as D-Bus errors and sent back to the caller. Errors
+    in <parameter>ret_error</parameter> take priority over negative return values.</para>
+
+    <para>Note that a node enumerator callback will only ever be called for a single  path prefix
+    and hence, for normal operation, <parameter>prefix</parameter> can be ignored. Also, a node
+    enumerator is only used to enumerate the available child objects under a given prefix. To
+    install a handler for a set of dynamic child objects, use
+    <citerefentry><refentrytitle>sd_bus_add_fallback_vtable</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+    </para>
+
+    <para>When <function>sd_bus_add_node_enumerator()</function> succeeds, a slot is created
+    internally. If the output parameter <replaceable>slot</replaceable> is <constant>NULL</constant>,
+    a "floating" slot object is created, see
+    <citerefentry><refentrytitle>sd_bus_slot_set_floating</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+    Otherwise, a pointer to the slot object is returned. In that case, the reference to the slot
+    object should be dropped when the node enumerator is not needed anymore, see
+    <citerefentry><refentrytitle>sd_bus_slot_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+    </para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, <function>sd_bus_add_node_enumerator()</function> returns a non-negative
+    integer. On failure, it returns a negative errno-style error code.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>One of the required parameters is <constant>NULL</constant> or
+          <parameter>path</parameter> is not a valid object path.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOPKG</constant></term>
+
+          <listitem><para>The bus cannot be resolved.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ECHILD</constant></term>
+
+          <listitem><para>The bus was created in a different process, library or module instance.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOMEM</constant></term>
+
+          <listitem><para>Memory allocation failed.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_bus_node_enumerator_t()</function> and
+    <function>sd_bus_add_node_enumerator()</function> were added in version 246.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>busctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_add_fallback_vtable</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_slot_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+</refentry>
diff --git a/man/sd_bus_add_object.xml b/man/sd_bus_add_object.xml
new file mode 100644
index 0000000..db667e3
--- /dev/null
+++ b/man/sd_bus_add_object.xml
@@ -0,0 +1,746 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_bus_add_object"
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_bus_add_object</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_add_object</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_add_object</refname>
+    <refname>sd_bus_add_fallback</refname>
+    <refname>sd_bus_add_object_vtable</refname>
+    <refname>sd_bus_add_fallback_vtable</refname>
+    <refname>sd_bus_add_filter</refname>
+    <refname>SD_BUS_VTABLE_CAPABILITY</refname>
+    <refname>SD_BUS_VTABLE_START</refname>
+    <refname>SD_BUS_VTABLE_END</refname>
+    <refname>SD_BUS_METHOD_WITH_NAMES_OFFSET</refname>
+    <refname>SD_BUS_METHOD_WITH_NAMES</refname>
+    <refname>SD_BUS_METHOD_WITH_OFFSET</refname>
+    <refname>SD_BUS_METHOD</refname>
+    <refname>SD_BUS_SIGNAL_WITH_NAMES</refname>
+    <refname>SD_BUS_SIGNAL</refname>
+    <refname>SD_BUS_WRITABLE_PROPERTY</refname>
+    <refname>SD_BUS_PROPERTY</refname>
+    <refname>SD_BUS_PARAM</refname>
+
+    <refpurpose>Declare properties and methods for a D-Bus path</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus-vtable.h&gt;</funcsynopsisinfo>
+
+      <xi:include href="sd_bus_add_match.xml" xpointer="sd_bus_message_handler_t"/>
+
+      <funcprototype>
+        <funcdef>typedef int (*<function>sd_bus_property_get_t</function>)</funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>const char *<parameter>path</parameter></paramdef>
+        <paramdef>const char *<parameter>interface</parameter></paramdef>
+        <paramdef>const char *<parameter>property</parameter></paramdef>
+        <paramdef>sd_bus_message *<parameter>reply</parameter></paramdef>
+        <paramdef>void *<parameter>userdata</parameter></paramdef>
+        <paramdef>sd_bus_error *<parameter>ret_error</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>typedef int (*<function>sd_bus_property_set_t</function>)</funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>const char *<parameter>path</parameter></paramdef>
+        <paramdef>const char *<parameter>interface</parameter></paramdef>
+        <paramdef>const char *<parameter>property</parameter></paramdef>
+        <paramdef>sd_bus_message *<parameter>value</parameter></paramdef>
+        <paramdef>void *<parameter>userdata</parameter></paramdef>
+        <paramdef>sd_bus_error *<parameter>ret_error</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>typedef int (*<function>sd_bus_object_find_t</function>)</funcdef>
+        <paramdef>const char *<parameter>path</parameter></paramdef>
+        <paramdef>const char *<parameter>interface</parameter></paramdef>
+        <paramdef>void *<parameter>userdata</parameter></paramdef>
+        <paramdef>void **<parameter>ret_found</parameter></paramdef>
+        <paramdef>sd_bus_error *<parameter>ret_error</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_add_object</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>sd_bus_slot **<parameter>slot</parameter></paramdef>
+        <paramdef>const char *<parameter>path</parameter></paramdef>
+        <paramdef>sd_bus_message_handler_t <parameter>callback</parameter></paramdef>
+        <paramdef>void *<parameter>userdata</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_add_fallback</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>sd_bus_slot **<parameter>slot</parameter></paramdef>
+        <paramdef>const char *<parameter>path</parameter></paramdef>
+        <paramdef>sd_bus_message_handler_t <parameter>callback</parameter></paramdef>
+        <paramdef>void *<parameter>userdata</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_add_object_vtable</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>sd_bus_slot **<parameter>slot</parameter></paramdef>
+        <paramdef>const char *<parameter>path</parameter></paramdef>
+        <paramdef>const char *<parameter>interface</parameter></paramdef>
+        <paramdef>const sd_bus_vtable *<parameter>vtable</parameter></paramdef>
+        <paramdef>void *<parameter>userdata</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_add_fallback_vtable</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>sd_bus_slot **<parameter>slot</parameter></paramdef>
+        <paramdef>const char *<parameter>prefix</parameter></paramdef>
+        <paramdef>const char *<parameter>interface</parameter></paramdef>
+        <paramdef>const sd_bus_vtable *<parameter>vtable</parameter></paramdef>
+        <paramdef>sd_bus_object_find_t <parameter>find</parameter></paramdef>
+        <paramdef>void *<parameter>userdata</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_add_filter</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>sd_bus_slot **<parameter>slot</parameter></paramdef>
+        <paramdef>sd_bus_message_handler_t <parameter>callback</parameter></paramdef>
+        <paramdef>void *<parameter>userdata</parameter></paramdef>
+      </funcprototype>
+
+      <para>
+        <constant>SD_BUS_VTABLE_CAPABILITY(<replaceable>capability</replaceable>)</constant>
+      </para>
+
+      <para>
+        <constant>SD_BUS_VTABLE_START(<replaceable>flags</replaceable>)</constant>
+      </para>
+      <para>
+        <constant>SD_BUS_VTABLE_END</constant>
+      </para>
+      <para>
+        <constant>SD_BUS_METHOD_WITH_ARGS_OFFSET(<replaceable>member</replaceable>,
+        <replaceable>args</replaceable>,
+        <replaceable>result</replaceable>,
+        <replaceable>handler</replaceable>,
+        <replaceable>offset</replaceable>,
+        <replaceable>flags</replaceable>)
+        </constant>
+      </para>
+      <para>
+        <constant>SD_BUS_METHOD_WITH_ARGS(<replaceable>member</replaceable>,
+        <replaceable>args</replaceable>,
+        <replaceable>result</replaceable>,
+        <replaceable>handler</replaceable>,
+        <replaceable>flags</replaceable>)
+        </constant>
+      </para>
+      <para>
+        <constant>SD_BUS_METHOD_WITH_NAMES_OFFSET(<replaceable>member</replaceable>,
+        <replaceable>signature</replaceable>,
+        <replaceable>in_names</replaceable>,
+        <replaceable>result</replaceable>,
+        <replaceable>out_names</replaceable>,
+        <replaceable>handler</replaceable>,
+        <replaceable>offset</replaceable>,
+        <replaceable>flags</replaceable>)
+        </constant>
+      </para>
+      <para>
+        <constant>SD_BUS_METHOD_WITH_NAMES(<replaceable>member</replaceable>,
+        <replaceable>signature</replaceable>,
+        <replaceable>in_names</replaceable>,
+        <replaceable>result</replaceable>,
+        <replaceable>out_names</replaceable>,
+        <replaceable>handler</replaceable>,
+        <replaceable>flags</replaceable>)
+        </constant>
+      </para>
+      <para>
+        <constant>SD_BUS_METHOD_WITH_OFFSET(<replaceable>member</replaceable>,
+        <replaceable>signature</replaceable>,
+        <replaceable>result</replaceable>,
+        <replaceable>handler</replaceable>,
+        <replaceable>offset</replaceable>,
+        <replaceable>flags</replaceable>)
+        </constant>
+      </para>
+      <para>
+        <constant>SD_BUS_METHOD(<replaceable>member</replaceable>,
+        <replaceable>signature</replaceable>,
+        <replaceable>result</replaceable>,
+        <replaceable>handler</replaceable>,
+        <replaceable>flags</replaceable>)
+        </constant>
+      </para>
+      <para>
+        <constant>SD_BUS_SIGNAL_WITH_ARGS(<replaceable>member</replaceable>,
+        <replaceable>args</replaceable>,
+        <replaceable>flags</replaceable>)
+        </constant>
+      </para>
+      <para>
+        <constant>SD_BUS_SIGNAL_WITH_NAMES(<replaceable>member</replaceable>,
+        <replaceable>signature</replaceable>,
+        <replaceable>names</replaceable>,
+        <replaceable>flags</replaceable>)
+        </constant>
+      </para>
+      <para>
+        <constant>SD_BUS_SIGNAL(<replaceable>member</replaceable>,
+        <replaceable>signature</replaceable>,
+        <replaceable>flags</replaceable>)
+        </constant>
+      </para>
+      <para>
+        <constant>SD_BUS_WRITABLE_PROPERTY(<replaceable>member</replaceable>,
+        <replaceable>signature</replaceable>,
+        <replaceable>get</replaceable>,
+        <replaceable>set</replaceable>,
+        <replaceable>offset</replaceable>,
+        <replaceable>flags</replaceable>)
+        </constant>
+      </para>
+      <para>
+        <constant>SD_BUS_PROPERTY(<replaceable>member</replaceable>,
+        <replaceable>signature</replaceable>,
+        <replaceable>get</replaceable>,
+        <replaceable>offset</replaceable>,
+        <replaceable>flags</replaceable>)
+        </constant>
+      </para>
+      <para>
+        <constant>SD_BUS_PARAM(<replaceable>name</replaceable>)</constant>
+      </para>
+      <para>
+        <constant>SD_BUS_ARGS(<replaceable>...</replaceable>)</constant>
+      </para>
+      <para>
+        <constant>SD_BUS_RESULT(<replaceable>...</replaceable>)</constant>
+      </para>
+      <para>
+        <constant>SD_BUS_NO_ARGS</constant>
+      </para>
+      <para>
+        <constant>SD_BUS_NO_RESULT</constant>
+      </para>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_bus_add_object_vtable()</function> is used to declare attributes for the
+    object path <parameter>path</parameter> connected to the bus connection
+    <parameter>bus</parameter> under the interface <parameter>interface</parameter>. The table
+    <parameter>vtable</parameter> may contain property declarations using
+    <constant>SD_BUS_PROPERTY()</constant> or <constant>SD_BUS_WRITABLE_PROPERTY()</constant>,
+    method declarations using <constant>SD_BUS_METHOD()</constant>,
+    <constant>SD_BUS_METHOD_WITH_NAMES()</constant>,
+    <constant>SD_BUS_METHOD_WITH_OFFSET()</constant>, or
+    <constant>SD_BUS_METHOD_WITH_NAMES_OFFSET()</constant>, and signal declarations using
+    <constant>SD_BUS_SIGNAL_WITH_NAMES()</constant> or <constant>SD_BUS_SIGNAL()</constant>, see
+    below. The <replaceable>userdata</replaceable> parameter contains a pointer that will be passed
+    to various callback functions. It may be specified as <constant>NULL</constant> if no value is
+    necessary. An interface can have any number of vtables attached to it.</para>
+
+    <para><function>sd_bus_add_fallback_vtable()</function> is similar to
+    <function>sd_bus_add_object_vtable()</function>, but is used to register "fallback" attributes.
+    When looking for an attribute declaration, bus object paths registered with
+    <function>sd_bus_add_object_vtable()</function> are checked first. If no match is found, the
+    fallback vtables are checked for each prefix of the bus object path, i.e. with the last
+    slash-separated components successively removed. This allows the vtable to be used for an
+    arbitrary number of dynamically created objects.</para>
+
+    <para>Parameter <replaceable>find</replaceable> is a function which is used to locate the target
+    object based on the bus object path <replaceable>path</replaceable>. It must return
+    <constant>1</constant> and set the <parameter>ret_found</parameter> output parameter if the
+    object is found, return <constant>0</constant> if the object was not found, and return a
+    negative errno-style error code or initialize the error structure
+    <replaceable>ret_error</replaceable> on error. The pointer passed in
+    <parameter>ret_found</parameter> will be used as the <parameter>userdata</parameter> parameter
+    for the callback functions (offset by the <parameter>offset</parameter> offsets as specified in
+    the vtable entries).</para>
+
+    <para><function>sd_bus_add_object()</function> attaches a callback directly to the object path
+    <parameter>path</parameter>. An object path can have any number of callbacks attached to it.
+    Each callback is prepended to the list of callbacks which are always called in order.
+    <function>sd_bus_add_fallback()</function> is similar to
+    <function>sd_bus_add_object()</function> but applies to fallback paths instead.</para>
+
+    <para><function>sd_bus_add_filter()</function> installs a callback that is invoked for each
+    incoming D-Bus message. Filters can be used to handle logic common to all messages received by
+    a service (e.g. authentication or authorization).</para>
+
+    <para>When a request is received, any associated callbacks are called sequentially until a
+    callback returns a non-zero integer. Return zero from a callback to give other callbacks the
+    chance to process the request. Callbacks are called in the following order: first, global
+    callbacks installed with <function>sd_bus_add_filter()</function> are called. Second, callbacks
+    attached directly to the request object path are called, followed by any D-Bus method callbacks
+    attached to the request object path, interface and member. Finally, the property callbacks
+    attached to the request object path, interface and member are called. If the final callback
+    returns zero, an error reply is sent back to the caller indicating no matching object for the
+    request was found.</para>
+
+    <para>Note that you can return a positive integer from a <parameter>method</parameter> callback without
+    immediately sending a reply. This informs sd-bus this callback will take responsibility for
+    replying to the request without forcing the callback to produce a reply immediately. This allows
+    a callback to perform any number of asynchronous operations required to construct a reply.
+    However, if producing a reply takes too long, the method call will time out at the caller. This is
+    only available to methods and not properties.</para>
+
+    <para>If a callback was invoked to handle a request that expects a reply and the callback
+    returns a negative value, the value is interpreted as a negative errno-style error code and sent
+    back to the caller as a D-Bus error as if
+    <citerefentry><refentrytitle>sd_bus_reply_method_errno</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    was called. Additionally, all callbacks take a <structname>sd_bus_error</structname> output
+    parameter that can be used to provide more detailed error information. If
+    <parameter>ret_error</parameter> is set when the callback finishes, the corresponding D-Bus
+    error is sent back to the caller as if
+    <citerefentry><refentrytitle>sd_bus_reply_method_error</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    was called. Any error stored in <parameter>ret_error</parameter> takes priority over any
+    negative values returned by the same callback when determining which error to send back to
+    the caller. Use
+    <citerefentry><refentrytitle>sd_bus_error_set</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    or one of its variants to set <parameter>ret_error</parameter> and return a negative integer
+    from a callback with a single function call. To send an error reply after a callback has already
+    finished, use
+    <citerefentry><refentrytitle>sd_bus_reply_method_errno</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    or one of its variants.</para>
+
+    <para>For all functions, a match slot is created internally. If the output parameter
+    <replaceable>slot</replaceable> is <constant>NULL</constant>, a "floating" slot object is
+    created, see
+    <citerefentry><refentrytitle>sd_bus_slot_set_floating</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+    Otherwise, a pointer to the slot object is returned. In that case, the reference to the slot
+    object should be dropped when the vtable is not needed anymore, see
+    <citerefentry><refentrytitle>sd_bus_slot_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+    </para>
+
+    <refsect2>
+      <title>The <structname>sd_bus_vtable</structname> array</title>
+
+      <para>The array consists of the structures of type <structname>sd_bus_vtable</structname>, but it
+      should never be filled in manually, but through one of the following macros:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>SD_BUS_VTABLE_START(<replaceable>flags</replaceable>)</constant></term>
+          <term><constant>SD_BUS_VTABLE_END</constant></term>
+
+          <listitem><para>Those must always be the first and last element. The
+          <replaceable>flags</replaceable> parameter can be used to set attributes that apply to the whole
+          array; see the "Flags" section below.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>SD_BUS_METHOD_WITH_ARGS_OFFSET()</constant></term>
+          <term><constant>SD_BUS_METHOD_WITH_ARGS()</constant></term>
+
+          <listitem><para>Declare a D-Bus method with the name <replaceable>member</replaceable>,
+          arguments <replaceable>args</replaceable> and result <replaceable>result</replaceable>.
+          <replaceable>args</replaceable> expects a sequence of argument type/name pairs wrapped in the
+          <constant>SD_BUS_ARGS()</constant> macro. The elements at even indices in this list describe the
+          types of the method's arguments. The method's parameter signature is the concatenation of all the
+          string literals at even indices in <replaceable>args</replaceable>. If a method has no parameters,
+          pass <constant>SD_BUS_NO_ARGS</constant> to <replaceable>args</replaceable>. The elements at uneven
+          indices describe the names of the method's arguments. <replaceable>result</replaceable> expects a
+          sequence of type/name pairs wrapped in the <constant>SD_BUS_RESULT()</constant> macro in the same
+          format as <constant>SD_BUS_ARGS()</constant>. The method's result signature is the concatenation of
+          all the string literals at even indices in <replaceable>result</replaceable>. If a method has no
+          result, pass <constant>SD_BUS_NO_RESULT</constant> to <replaceable>result</replaceable>. Note that
+          argument types are expected to be quoted string literals and argument names are expected to be
+          unquoted string literals. See below for a complete example.</para>
+
+          <para>The handler function <replaceable>handler</replaceable> must be of type
+          <function>sd_bus_message_handler_t</function>. It will be called to handle the incoming messages
+          that call this method. It receives a pointer that is the <replaceable>userdata</replaceable>
+          parameter passed to the registration function offset by <replaceable>offset</replaceable> bytes.
+          This may be used to pass pointers to different fields in the same data structure to different
+          methods in the same vtable. To send a reply from <parameter>handler</parameter>, call
+          <citerefentry><refentrytitle>sd_bus_reply_method_return</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+          with the message the callback was invoked with. Parameter <replaceable>flags</replaceable> is a
+          combination of flags, see below.</para>
+
+          <para><constant>SD_BUS_METHOD_WITH_ARGS()</constant> is a shorthand for calling
+          <constant>SD_BUS_METHOD_WITH_ARGS_OFFSET()</constant> with an offset of zero.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>SD_BUS_METHOD_WITH_NAMES_OFFSET()</constant></term>
+          <term><constant>SD_BUS_METHOD_WITH_NAMES()</constant></term>
+          <term><constant>SD_BUS_METHOD_WITH_OFFSET()</constant></term>
+          <term><constant>SD_BUS_METHOD()</constant></term>
+
+          <listitem><para>Declare a D-Bus method with the name <replaceable>member</replaceable>,
+          parameter signature <replaceable>signature</replaceable>, result signature
+          <replaceable>result</replaceable>. Parameters <replaceable>in_names</replaceable> and
+          <replaceable>out_names</replaceable> specify the argument names of the input and output
+          arguments in the function signature. <replaceable>in_names</replaceable> and
+          <replaceable>out_names</replaceable> should be created using the
+          <constant>SD_BUS_PARAM()</constant> macro, see below. In all other regards, this macro behaves
+          exactly the same as <constant>SD_BUS_METHOD_WITH_ARGS_OFFSET()</constant>.</para>
+
+          <para><constant>SD_BUS_METHOD_WITH_NAMES()</constant>,
+          <constant>SD_BUS_METHOD_WITH_OFFSET()</constant>, and <constant>SD_BUS_METHOD()</constant>
+          are variants which specify zero offset (<replaceable>userdata</replaceable> parameter is
+          passed with no change), leave the names unset (i.e. no parameter names), or both.</para>
+
+          <para>Prefer using <constant>SD_BUS_METHOD_WITH_ARGS_OFFSET()</constant> and
+          <constant>SD_BUS_METHOD_WITH_ARGS()</constant> over these macros as they allow specifying argument
+          types and names next to each other which is less error-prone than first specifying all argument
+          types followed by specifying all argument names.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>SD_BUS_SIGNAL_WITH_ARGS()</constant></term>
+
+          <listitem><para>Declare a D-Bus signal with the name <replaceable>member</replaceable> and
+          arguments <replaceable>args</replaceable>. <replaceable>args</replaceable> expects a sequence of
+          argument type/name pairs wrapped in the <constant>SD_BUS_ARGS()</constant> macro. The elements at
+          even indices in this list describe the types of the signal's arguments. The signal's parameter
+          signature is the concatenation of all the string literals at even indices in
+          <replaceable>args</replaceable>. If a signal has no parameters, pass
+          <constant>SD_BUS_NO_ARGS</constant> to <replaceable>args</replaceable>. The elements at uneven
+          indices describe the names of the signal's arguments. Parameter <replaceable>flags</replaceable> is
+          a combination of flags. See below for a complete example.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>SD_BUS_SIGNAL_WITH_NAMES()</constant></term>
+          <term><constant>SD_BUS_SIGNAL()</constant></term>
+
+          <listitem><para>Declare a D-Bus signal with the name <replaceable>member</replaceable>,
+          parameter signature <replaceable>signature</replaceable>, and argument names
+          <replaceable>names</replaceable>. <replaceable>names</replaceable> should be
+          created using the <constant>SD_BUS_PARAM()</constant> macro, see below.
+          Parameter <replaceable>flags</replaceable> is a combination of flags, see below.
+          </para>
+
+          <para><constant>SD_BUS_SIGNAL()</constant> is equivalent to
+          <constant>SD_BUS_SIGNAL_WITH_NAMES()</constant> with the <replaceable>names</replaceable> parameter
+          unset (i.e. no parameter names).</para>
+
+          <para>Prefer using <constant>SD_BUS_SIGNAL_WITH_ARGS()</constant> over these macros as it allows
+          specifying argument types and names next to each other which is less error-prone than first
+          specifying all argument types followed by specifying all argument names.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>SD_BUS_WRITABLE_PROPERTY()</constant></term>
+          <term><constant>SD_BUS_PROPERTY()</constant></term>
+
+          <listitem><para>Declare a D-Bus property with the name <replaceable>member</replaceable>
+          and value signature <replaceable>signature</replaceable>. Parameters
+          <replaceable>get</replaceable> and <replaceable>set</replaceable> are the getter and
+          setter methods. They are called with a pointer that is the
+          <replaceable>userdata</replaceable> parameter passed to the registration function offset
+          by <replaceable>offset</replaceable> bytes. This may be used pass pointers to different
+          fields in the same data structure to different setters and getters in the same vtable.
+          Parameter <replaceable>flags</replaceable> is a combination of flags, see below.</para>
+
+          <para>The setter and getter methods may be omitted (specified as
+          <constant>NULL</constant>), if the property is one of the basic types or
+          <literal>as</literal> in case of read-only properties. In those cases, the
+          <replaceable>userdata</replaceable> and <replaceable>offset</replaceable> parameters must
+          together point to a valid variable of the corresponding type. A default setter and getter
+          will be provided, which simply copy the argument between this variable and the message.
+          </para>
+
+          <para><constant>SD_BUS_PROPERTY()</constant> is used to define a read-only property.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>SD_BUS_PARAM()</constant></term>
+          <listitem><para>Parameter names should be wrapped in this macro, see the example below.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+
+    <refsect2>
+      <title>Flags</title>
+
+      <para>The <replaceable>flags</replaceable> parameter is used to specify a combination of
+      <ulink url="https://dbus.freedesktop.org/doc/dbus-specification.html#introspection-format">D-Bus annotations</ulink>.
+      </para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>SD_BUS_VTABLE_DEPRECATED</constant></term>
+
+          <listitem><para>Mark this vtable entry as deprecated using the
+          <constant>org.freedesktop.DBus.Deprecated</constant> annotation in introspection data. If
+          specified for <constant>SD_BUS_VTABLE_START()</constant>, the annotation is applied to the
+          enclosing interface.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>SD_BUS_VTABLE_HIDDEN</constant></term>
+
+          <listitem><para>Make this vtable entry hidden. It will not be shown in introspection data.
+          If specified for <constant>SD_BUS_VTABLE_START()</constant>, all entries in the array are
+          hidden.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>SD_BUS_VTABLE_METHOD_NO_REPLY</constant></term>
+
+          <listitem><para>Mark this vtable entry as a method that will not return a reply using the
+          <constant>org.freedesktop.DBus.Method.NoReply</constant> annotation in introspection data.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>SD_BUS_VTABLE_PROPERTY_CONST</constant></term>
+          <term><constant>SD_BUS_VTABLE_PROPERTY_EMITS_CHANGE</constant></term>
+          <term><constant>SD_BUS_VTABLE_PROPERTY_EMITS_INVALIDATION</constant></term>
+
+          <listitem><para>Those three flags correspond to different values of the
+          <constant>org.freedesktop.DBus.Property.EmitsChangedSignal</constant> annotation, which
+          specifies whether the
+          <constant>org.freedesktop.DBus.Properties.PropertiesChanged</constant> signal is emitted
+          whenever the property changes. <constant>SD_BUS_VTABLE_PROPERTY_CONST</constant>
+          corresponds to <constant>const</constant> and means that the property never changes during
+          the lifetime of the object it belongs to, so no signal needs to be emitted.
+          <constant>SD_BUS_VTABLE_PROPERTY_EMITS_CHANGE</constant> corresponds to
+          <constant>true</constant> and means that the signal is emitted.
+          <constant>SD_BUS_VTABLE_PROPERTY_EMITS_INVALIDATION</constant> corresponds to
+          <constant>invalidates</constant> and means that the signal is emitted, but the value is
+          not included in the signal.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>SD_BUS_VTABLE_PROPERTY_EXPLICIT</constant></term>
+
+          <listitem><para>Mark this vtable property entry as requiring explicit request to for the
+          value to be shown (generally because the value is large or slow to calculate). This entry
+          cannot be combined with <constant>SD_BUS_VTABLE_PROPERTY_EMITS_CHANGE</constant>, and will
+          not be shown in property listings by default (e.g. <command>busctl introspect</command>).
+          This corresponds to the <constant>org.freedesktop.systemd1.Explicit</constant> annotation
+          in introspection data.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>SD_BUS_VTABLE_SENSITIVE</constant></term>
+
+          <listitem><para>Mark this vtable method entry as processing sensitive data. When set,
+          incoming method call messages and their outgoing reply messages are marked as sensitive using
+          <citerefentry><refentrytitle>sd_bus_message_sensitive</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+          so that they are erased from memory when freed.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>SD_BUS_VTABLE_ABSOLUTE_OFFSET</constant></term>
+
+          <listitem><para>Mark this vtable method or property entry so that the user data pointer passed to
+          its associated handler functions is determined slightly differently: instead of adding the offset
+          parameter of the entry to the user data pointer specified during vtable registration, the offset is
+          passed directly, converted to a pointer, without taking the user data pointer specified during
+          vtable registration into account.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>SD_BUS_VTABLE_CAPABILITY(<replaceable>capability</replaceable>)</constant></term>
+
+          <listitem><para>Access to this vtable entry will be allowed if the calling process has the
+          capability <replaceable>capability</replaceable>, as described in
+          <citerefentry><refentrytitle>sd_bus_query_sender_privilege</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+          If used for <constant>SD_BUS_VTABLE_START()</constant>, provides a default for all entries in the
+          array. If not specified, either for an individual entry or the whole array,
+          <constant>CAP_SYS_ADMIN</constant> is checked by default. See <citerefentry
+          project='man-pages'><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+          for information about capabilities.</para>
+
+          <para>Note that vtable entries may be marked as unprivileged and the whole bus may be marked as
+          trusted, see the discussion of <constant>SD_BUS_VTABLE_UNPRIVILEGED</constant> below.</para>
+
+          <xi:include href="version-info.xml" xpointer="v251"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>SD_BUS_VTABLE_UNPRIVILEGED</constant></term>
+
+          <listitem><para>Mark this vtable entry as unprivileged. Access to privileged entries is limited to
+          users with appropriate capabilities as described above. In practice many vtable entries are marked
+          as unprivileged, and either are open to everyone, or the decision whether to allow access is taken
+          later, e.g. by delegating to <ulink
+          url="https://www.freedesktop.org/software/polkit/docs/latest/">polkit</ulink>.</para>
+
+          <para>The whole bus may be marked as trusted, in which case annotations at the entry level are
+          ignored, see
+          <citerefentry><refentrytitle>sd_bus_set_trusted</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+          </para>
+
+          <para>When <emphasis>not</emphasis> specified, the
+          <constant>org.freedesktop.systemd1.Privileged</constant> annotation with value
+          <literal>true</literal> will be shown in introspection data.</para>
+
+          <para>Note that this page describes checks implemented in the D-Bus client. The D-Bus server has an
+          additional policy that may permit or deny connections, see
+          "CONFIGURATION FILE" in
+          <citerefentry project='man-pages'><refentrytitle>dbus-daemon</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <refsect1>
+    <title>Examples</title>
+
+    <example>
+      <title>Create a simple listener on the bus</title>
+
+      <programlisting><xi:include href="vtable-example.c" parse="text" /></programlisting>
+
+      <para>This creates a simple client on the bus (the user bus, when run as normal user). We may
+      use the D-Bus <constant>org.freedesktop.DBus.Introspectable.Introspect</constant> call to
+      acquire the XML description of the interface:</para>
+
+      <programlisting><xi:include href="vtable-example.xml" parse="text" /></programlisting>
+    </example>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, <function>sd_bus_add_object_vtable()</function> and
+    <function>sd_bus_add_fallback_vtable()</function> return a non-negative integer. On
+    failure, they return a negative errno-style error code.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>One of the required parameters is <constant>NULL</constant> or invalid. A
+          reserved D-Bus interface was passed as the <replaceable>interface</replaceable> parameter.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOPKG</constant></term>
+
+          <listitem><para>The bus cannot be resolved.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ECHILD</constant></term>
+
+          <listitem><para>The bus was created in a different process, library or module instance.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOMEM</constant></term>
+
+          <listitem><para>Memory allocation failed.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EPROTOTYPE</constant></term>
+
+          <listitem><para><function>sd_bus_add_object_vtable()</function> and
+          <function>sd_bus_add_fallback_vtable()</function> have been both called for the same bus
+          object path, which is not allowed.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EEXIST</constant></term>
+
+          <listitem><para>This vtable has already been registered for this
+          <replaceable>interface</replaceable> and <replaceable>path</replaceable>.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_bus_property_get_t()</function>,
+    <function>sd_bus_property_set_t()</function>,
+    <function>sd_bus_object_find_t()</function>,
+    <function>sd_bus_add_object()</function>,
+    <function>sd_bus_add_fallback()</function>,
+    <function>sd_bus_add_object_vtable()</function>,
+    <function>sd_bus_add_fallback_vtable()</function>, and
+    <function>sd_bus_add_filter()</function> were added in version 246.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>busctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_emit_properties_changed</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_emit_object_added</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+</refentry>
diff --git a/man/sd_bus_add_object_manager.xml b/man/sd_bus_add_object_manager.xml
new file mode 100644
index 0000000..e5f410b
--- /dev/null
+++ b/man/sd_bus_add_object_manager.xml
@@ -0,0 +1,131 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_bus_add_object_manager"
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_bus_add_object_manager</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_add_object_manager</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_add_object_manager</refname>
+
+    <refpurpose>Add a D-Bus object manager for a D-Bus object sub-tree</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_add_object_manager</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>sd_bus_slot **<parameter>slot</parameter></paramdef>
+        <paramdef>const char *<parameter>path</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_bus_add_object_manager()</function> installs a handler for the given path
+    that implements the <function>GetManagedObjects()</function> method of the
+    <constant>org.freedesktop.DBus.ObjectManager</constant> interface. See
+    <ulink url="https://dbus.freedesktop.org/doc/dbus-specification.html#standard-interfaces-objectmanager">
+    org.freedesktop.DBus.ObjectManager</ulink> for more information.</para>
+
+    <para>To implement the <function>InterfacesAdded</function> and
+    <function>InterfacesRemoved</function> signals of the
+    <constant>org.freedesktop.DBus.ObjectManager</constant> interface, call
+    <citerefentry><refentrytitle>sd_bus_emit_interfaces_added</refentrytitle><manvolnum>3</manvolnum></citerefentry> and
+    <citerefentry><refentrytitle>sd_bus_emit_interfaces_removed</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    whenever interfaces are added or removed from the sub-tree, respectively.</para>
+
+    <para>When <function>sd_bus_add_object_manager()</function> succeeds, a slot is created
+    internally. If the output parameter <replaceable>slot</replaceable> is <constant>NULL</constant>,
+    a "floating" slot object is created, see
+    <citerefentry><refentrytitle>sd_bus_slot_set_floating</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+    Otherwise, a pointer to the slot object is returned. In that case, the reference to the slot
+    object should be dropped when the object manager is not needed anymore, see
+    <citerefentry><refentrytitle>sd_bus_slot_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+    </para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, <function>sd_bus_add_object_manager()</function> returns a non-negative
+    integer. On failure, it returns a negative errno-style error code.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>One of the required parameters is <constant>NULL</constant> or
+          <parameter>path</parameter> is not a valid object path.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOPKG</constant></term>
+
+          <listitem><para>The bus cannot be resolved.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ECHILD</constant></term>
+
+          <listitem><para>The bus was created in a different process, library or module instance.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOMEM</constant></term>
+
+          <listitem><para>Memory allocation failed.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_bus_add_object_manager()</function> was added in version 246.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>busctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_add_object_vtable</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_emit_interfaces_added</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_slot_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+</refentry>
diff --git a/man/sd_bus_attach_event.xml b/man/sd_bus_attach_event.xml
new file mode 100644
index 0000000..979783c
--- /dev/null
+++ b/man/sd_bus_attach_event.xml
@@ -0,0 +1,126 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_bus_attach_event"
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_bus_attach_event</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_attach_event</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_attach_event</refname>
+    <refname>sd_bus_detach_event</refname>
+    <refname>sd_bus_get_event</refname>
+
+    <refpurpose>Attach a bus connection object to an event loop</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_attach_event</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>sd_event *<parameter>e</parameter></paramdef>
+        <paramdef>int <parameter>priority</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_detach_event</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>sd_event *<function>sd_bus_get_event</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_bus_attach_event()</function> attaches the specified bus connection object to an
+    <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry> event loop object at
+    the specified priority (see
+    <citerefentry><refentrytitle>sd_event_source_set_priority</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    for details on event loop priorities). When a bus connection object is attached to an event loop incoming messages
+    will be automatically read and processed, and outgoing messages written, whenever the event loop is run. When the
+    event loop is about to terminate, the bus connection is automatically flushed and closed (see
+    <citerefentry><refentrytitle>sd_bus_set_close_on_exit</refentrytitle><manvolnum>3</manvolnum></citerefentry> for
+    details on this). By default bus connection objects are not attached to any event loop. When a bus connection
+    object is attached to one it is not necessary to invoke
+    <citerefentry><refentrytitle>sd_bus_wait</refentrytitle><manvolnum>3</manvolnum></citerefentry> or
+    <citerefentry><refentrytitle>sd_bus_process</refentrytitle><manvolnum>3</manvolnum></citerefentry> as this
+    functionality is handled automatically by the event loop.</para>
+
+    <para><function>sd_bus_detach_event()</function> detaches a bus object from its event loop.</para>
+
+    <para>The <function>sd_bus_get_event()</function> returns the event loop object the specified bus object is
+    currently attached to, or <constant>NULL</constant> if it is currently not attached to any.</para>
+
+    <para>Note that <function>sd_bus_attach_event()</function> is only one of three supported ways to implement I/O
+    event handling for bus connections. Alternatively use
+    <citerefentry><refentrytitle>sd_bus_get_fd</refentrytitle><manvolnum>3</manvolnum></citerefentry> for hooking up a
+    bus connection object with external or manual event loops. Or use
+    <citerefentry><refentrytitle>sd_bus_wait</refentrytitle><manvolnum>3</manvolnum></citerefentry> as a simple
+    synchronous, blocking I/O waiting call.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, <function>sd_bus_attach_event()</function> and <function>sd_bus_detach_event()</function> return
+    0 or a positive integer. On failure, they return a negative errno-style error code.</para>
+
+    <para><function>sd_bus_get_event()</function> returns an event loop object or <constant>NULL</constant>.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-ECHILD</constant></term>
+
+          <listitem><para>The bus connection has been created in a different process, library or module instance.</para></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_bus_attach_event()</function>,
+    <function>sd_bus_detach_event()</function>, and
+    <function>sd_bus_get_event()</function> were added in version 240.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_source_set_priority</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_set_close_on_exit</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_wait</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_get_fd</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_bus_call.xml b/man/sd_bus_call.xml
new file mode 100644
index 0000000..0bd863d
--- /dev/null
+++ b/man/sd_bus_call.xml
@@ -0,0 +1,220 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_bus_call"
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_bus_call</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_call</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_call</refname>
+    <refname>sd_bus_call_async</refname>
+
+    <refpurpose>Invoke a D-Bus method call</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <xi:include href="sd_bus_add_match.xml" xpointer="sd_bus_message_handler_t"/>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_call</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>sd_bus_message *<parameter>m</parameter></paramdef>
+        <paramdef>uint64_t <parameter>usec</parameter></paramdef>
+        <paramdef>sd_bus_error *<parameter>ret_error</parameter></paramdef>
+        <paramdef>sd_bus_message **<parameter>reply</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_call_async</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>sd_bus_slot **<parameter>slot</parameter></paramdef>
+        <paramdef>sd_bus_message *<parameter>m</parameter></paramdef>
+        <paramdef>sd_bus_message_handler_t <parameter>callback</parameter></paramdef>
+        <paramdef>void *<parameter>userdata</parameter></paramdef>
+        <paramdef>uint64_t <parameter>usec</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_bus_call()</function> takes a complete bus message object and calls the
+    corresponding D-Bus method. On success, the response is stored in <parameter>reply</parameter>.
+    <parameter>usec</parameter> indicates the timeout in microseconds. If
+    <parameter>ret_error</parameter> is not <constant>NULL</constant> and
+    <function>sd_bus_call()</function> fails (either because of an internal error or because it
+    received a D-Bus error reply), <parameter>ret_error</parameter> is initialized to an instance of
+    <structname>sd_bus_error</structname> describing the error.</para>
+
+    <para><function>sd_bus_call_async()</function> is like <function>sd_bus_call()</function> but works
+    asynchronously. The <parameter>callback</parameter> indicates the function to call when the response
+    arrives. The <parameter>userdata</parameter> pointer will be passed to the callback function, and may be
+    chosen freely by the caller. If <parameter>slot</parameter> is not <constant>NULL</constant> and
+    <function>sd_bus_call_async()</function> succeeds, <parameter>slot</parameter> is set to a slot object
+    which can be used to cancel the method call at a later time using
+    <citerefentry><refentrytitle>sd_bus_slot_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+    If <parameter>slot</parameter> is <constant>NULL</constant>, the lifetime of the method call is bound to
+    the lifetime of the bus object itself, and it cannot be cancelled independently. See
+    <citerefentry><refentrytitle>sd_bus_slot_set_floating</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    for details. <parameter>callback</parameter> is called when a reply arrives with the reply,
+    <parameter>userdata</parameter> and an <structname>sd_bus_error</structname> output parameter as its
+    arguments. Unlike <function>sd_bus_call()</function>, the <structname>sd_bus_error</structname> output
+    parameter passed to the callback will be empty. To determine whether the method call succeeded, use
+    <citerefentry><refentrytitle>sd_bus_message_is_method_error</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    on the reply message passed to the callback instead. If the callback returns zero and the
+    <structname>sd_bus_error</structname> output parameter is still empty when the callback finishes, other
+    handlers registered with functions such as
+    <citerefentry><refentrytitle>sd_bus_add_filter</refentrytitle><manvolnum>3</manvolnum></citerefentry> or
+    <citerefentry><refentrytitle>sd_bus_add_match</refentrytitle><manvolnum>3</manvolnum></citerefentry> are
+    given a chance to process the message. If the callback returns a non-zero value or the
+    <structname>sd_bus_error</structname> output parameter is not empty when the callback finishes, no
+    further processing of the message is done. Generally, you want to return zero from the callback to give
+    other registered handlers a chance to process the reply as well. (Note that the
+    <structname>sd_bus_error</structname> parameter is an output parameter of the callback function, not an
+    input parameter; it can be used to propagate errors from the callback handler, it will not receive any
+    error that was received as method reply.)</para>
+
+    <para>The message <parameter>m</parameter> passed to the callback is only borrowed, that is, the callback should
+    not call <citerefentry><refentrytitle>sd_bus_message_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    on it. If the callback wants to hold on to the message beyond the lifetime of the callback, it needs to call
+    <citerefentry><refentrytitle>sd_bus_message_ref</refentrytitle><manvolnum>3</manvolnum></citerefentry> to create a
+    new reference.</para>
+
+    <para>If <parameter>usec</parameter> is zero, the default D-Bus method call timeout is used. See
+    <citerefentry><refentrytitle>sd_bus_get_method_call_timeout</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+    </para>
+
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, these functions return a non-negative integer. On failure, they return a
+    negative errno-style error code.</para>
+
+    <refsect2 id='errors'>
+      <title>Errors</title>
+
+      <para>When <function>sd_bus_call()</function> internally receives a D-Bus error reply, it will set
+      <parameter>ret_error</parameter> if it is not <constant>NULL</constant>, and will return a negative
+      value mapped from the error reply, see
+      <citerefentry><refentrytitle>sd_bus_error_get_errno</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+      </para>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>The input parameter <parameter>m</parameter> is <constant>NULL</constant>.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+
+          <listitem><para>The input parameter <parameter>m</parameter> is not a D-Bus method call.
+          To create a new D-Bus method call, use
+          <citerefentry><refentrytitle>sd_bus_message_new_method_call</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+          </para></listitem>
+
+          <listitem><para>The input parameter <parameter>m</parameter> has the
+          <constant>BUS_MESSAGE_NO_REPLY_EXPECTED</constant> flag set.</para></listitem>
+
+          <listitem><para>The input parameter <parameter>error</parameter> is
+          non-<constant>NULL</constant> but was not set to <constant>SD_BUS_ERROR_NULL</constant>.
+          </para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ECHILD</constant></term>
+
+          <listitem><para>The bus connection was allocated in a parent process and is being reused
+          in a child process after <function>fork()</function>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOTCONN</constant></term>
+
+          <listitem><para>The input parameter <parameter>bus</parameter> is
+          <constant>NULL</constant> or the bus is not connected.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ECONNRESET</constant></term>
+
+          <listitem><para>The bus connection was closed while waiting for the response.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ETIMEDOUT</constant></term>
+
+          <listitem><para>A response was not received within the given timeout.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ELOOP</constant></term>
+
+          <listitem><para>The message <parameter>m</parameter> is addressed to its own client.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOMEM</constant></term>
+
+          <listitem><para>Memory allocation failed.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_bus_call()</function> and
+    <function>sd_bus_call_async()</function> were added in version 246.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_call_method</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_call_method_async</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_message_new_method_call</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_message_append</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_error</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_bus_call_method.xml b/man/sd_bus_call_method.xml
new file mode 100644
index 0000000..f25c8c7
--- /dev/null
+++ b/man/sd_bus_call_method.xml
@@ -0,0 +1,164 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_bus_call_method"
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_bus_call_method</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_call_method</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_call_method</refname>
+    <refname>sd_bus_call_methodv</refname>
+    <refname>sd_bus_call_method_async</refname>
+    <refname>sd_bus_call_method_asyncv</refname>
+
+    <refpurpose>Initialize a bus message object and invoke the corresponding D-Bus method call
+    </refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <xi:include href="sd_bus_add_match.xml" xpointer="sd_bus_message_handler_t"/>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_call_method</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>const char *<parameter>destination</parameter></paramdef>
+        <paramdef>const char *<parameter>path</parameter></paramdef>
+        <paramdef>const char *<parameter>interface</parameter></paramdef>
+        <paramdef>const char *<parameter>member</parameter></paramdef>
+        <paramdef>sd_bus_error *<parameter>ret_error</parameter></paramdef>
+        <paramdef>sd_bus_message **<parameter>reply</parameter></paramdef>
+        <paramdef>const char *<parameter>types</parameter></paramdef>
+        <paramdef>...</paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_call_methodv</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>const char *<parameter>destination</parameter></paramdef>
+        <paramdef>const char *<parameter>path</parameter></paramdef>
+        <paramdef>const char *<parameter>interface</parameter></paramdef>
+        <paramdef>const char *<parameter>member</parameter></paramdef>
+        <paramdef>sd_bus_error *<parameter>ret_error</parameter></paramdef>
+        <paramdef>sd_bus_message **<parameter>reply</parameter></paramdef>
+        <paramdef>const char *<parameter>types</parameter></paramdef>
+        <paramdef>va_list <parameter>ap</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_call_method_async</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>sd_bus_slot **<parameter>slot</parameter></paramdef>
+        <paramdef>const char *<parameter>destination</parameter></paramdef>
+        <paramdef>const char *<parameter>path</parameter></paramdef>
+        <paramdef>const char *<parameter>interface</parameter></paramdef>
+        <paramdef>const char *<parameter>member</parameter></paramdef>
+        <paramdef>sd_bus_message_handler_t <parameter>callback</parameter></paramdef>
+        <paramdef>void *<parameter>userdata</parameter></paramdef>
+        <paramdef>const char *<parameter>types</parameter></paramdef>
+        <paramdef>...</paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_call_method_asyncv</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>sd_bus_slot **<parameter>slot</parameter></paramdef>
+        <paramdef>const char *<parameter>destination</parameter></paramdef>
+        <paramdef>const char *<parameter>path</parameter></paramdef>
+        <paramdef>const char *<parameter>interface</parameter></paramdef>
+        <paramdef>const char *<parameter>member</parameter></paramdef>
+        <paramdef>sd_bus_message_handler_t <parameter>callback</parameter></paramdef>
+        <paramdef>void *<parameter>userdata</parameter></paramdef>
+        <paramdef>const char *<parameter>types</parameter></paramdef>
+        <paramdef>va_list <parameter>ap</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_bus_call_method()</function> is a convenience function for initializing a
+    bus message object and calling the corresponding D-Bus method. It combines the
+    <citerefentry><refentrytitle>sd_bus_message_new_method_call</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_bus_message_append</refentrytitle><manvolnum>3</manvolnum></citerefentry> and
+    <citerefentry><refentrytitle>sd_bus_call</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    functions into a single function call.</para>
+
+    <para><function>sd_bus_call_method_async()</function> is a convenience function for initializing
+    a bus message object and calling the corresponding D-Bus method asynchronously. It combines the
+    <citerefentry><refentrytitle>sd_bus_message_new_method_call</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_bus_message_append</refentrytitle><manvolnum>3</manvolnum></citerefentry> and
+    <citerefentry><refentrytitle>sd_bus_call_async</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    functions into a single function call.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, these functions return a non-negative integer. On failure, they return a
+    negative errno-style error code.</para>
+
+    <refsect2 id='errors'>
+      <title>Errors</title>
+
+      <para>See the man pages of
+      <citerefentry><refentrytitle>sd_bus_message_new_method_call</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_message_append</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_call</refentrytitle><manvolnum>3</manvolnum></citerefentry> and
+      <citerefentry><refentrytitle>sd_bus_call_async</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+      for a list of possible errors.</para>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>Examples</title>
+
+    <example>
+      <title>Make a call to a D-Bus method that takes a single parameter</title>
+
+      <programlisting><xi:include href="print-unit-path-call-method.c" parse="text" /></programlisting>
+      <para>This defines a minimally useful program that will open a connection to the bus, call a method,
+      wait for the reply, and finally extract and print the answer. It does error handling and proper
+      memory management.</para>
+    </example>
+  </refsect1>
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_bus_call_method()</function>,
+    <function>sd_bus_call_methodv()</function>,
+    <function>sd_bus_call_method_async()</function>, and
+    <function>sd_bus_call_method_asyncv()</function> were added in version 246.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_message_new_method_call</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_message_append</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_call</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_set_property</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_emit_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_bus_can_send.xml b/man/sd_bus_can_send.xml
new file mode 100644
index 0000000..321b19d
--- /dev/null
+++ b/man/sd_bus_can_send.xml
@@ -0,0 +1,104 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_bus_can_send"
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_bus_can_send</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_can_send</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_can_send</refname>
+
+    <refpurpose>Check which types can be sent over a bus object</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>void <function>sd_bus_can_send</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>char <parameter>type</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_bus_can_send()</function> is mostly used for checking if file descriptor
+    passing is available on the given bus. <parameter>type</parameter> can be any of the
+    <constant>SD_BUS_TYPE</constant> constants.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On failure, <function>sd_bus_can_send()</function> returns a negative errno-style error
+    code. If values of the given type can be sent over the given bus, it returns a positive integer.
+    Otherwise, it returns zero.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-ENOPKG</constant></term>
+
+          <listitem><para>The bus object <parameter>bus</parameter> could not be resolved.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOTCONN</constant></term>
+
+          <listitem><para>The input parameter <parameter>bus</parameter> is
+          <constant>NULL</constant> or the bus is not connected.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ECHILD</constant></term>
+
+          <listitem><para>The bus object <parameter>bus</parameter> was created in a different
+          process.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_bus_can_send()</function> was added in version 246.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_bus_close.xml b/man/sd_bus_close.xml
new file mode 100644
index 0000000..997e67b
--- /dev/null
+++ b/man/sd_bus_close.xml
@@ -0,0 +1,126 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_bus_close"
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_bus_close</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_close</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_close</refname>
+    <refname>sd_bus_flush</refname>
+    <refname>sd_bus_default_flush_close</refname>
+
+    <refpurpose>Close and flush a bus connection</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>void <function>sd_bus_close</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_flush</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>void <function>sd_bus_default_flush_close</function></funcdef>
+        <paramdef>void</paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_bus_close()</function> disconnects the specified bus connection. When this
+    call is invoked and the specified bus object refers to an active connection it is immediately
+    terminated. No further messages may be sent or received on it. Any messages queued in the bus
+    object (both incoming and outgoing) are released. If invoked on <constant>NULL</constant> bus
+    object or when the bus connection is already closed this function executes no operation. This
+    call does not free or unreference the bus object itself. Use
+    <citerefentry><refentrytitle>sd_bus_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    for that.</para>
+
+    <para><function>sd_bus_flush()</function> synchronously writes out all outgoing queued message
+    on a bus connection if there are any. This function call may block if the peer is not processing
+    bus messages quickly.</para>
+
+    <para>Before a program exits it is usually a good idea to flush any pending messages with
+    <function>sd_bus_flush()</function> and then close connections with
+    <function>sd_bus_close()</function> to ensure that no unwritten messages are lost, no further
+    messages may be queued and all incoming but unprocessed messages are released. After both
+    operations have been done, it is a good idea to  also drop any remaining references to the bus
+    object so that it may be freed. Since these three operations are frequently done together a
+    helper call
+    <citerefentry><refentrytitle>sd_bus_flush_close_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    is provided that combines them into one.</para>
+
+    <para><function>sd_bus_default_flush_close()</function> is similar to
+    <function>sd_bus_flush_close_unref()</function>, but does not take a bus pointer argument and
+    instead iterates over any of the "default" buses opened by
+    <citerefentry><refentrytitle>sd_bus_default</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_bus_default_user</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_bus_default_system</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    and similar calls. <function>sd_bus_default_flush_close()</function> is particularly useful to
+    clean up any buses opened using those calls before the program exits.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, <function>sd_bus_flush()</function> returns a non-negative integer. On
+    failure, it returns a negative errno-style error code.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-ECHILD</constant></term>
+
+          <listitem><para>The bus connection has been created in a different process, library or module instance.</para>
+          </listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_bus_close()</function> and
+    <function>sd_bus_flush()</function> were added in version 240.</para>
+    <para><function>sd_bus_default_flush_close()</function> was added in version 246.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_set_close_on_exit</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_bus_creds_get_pid.xml b/man/sd_bus_creds_get_pid.xml
new file mode 100644
index 0000000..66fcaa7
--- /dev/null
+++ b/man/sd_bus_creds_get_pid.xml
@@ -0,0 +1,564 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_bus_creds_get_pid" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_bus_creds_get_pid</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_creds_get_pid</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_creds_get_pid</refname>
+    <refname>sd_bus_creds_get_ppid</refname>
+    <refname>sd_bus_creds_get_tid</refname>
+    <refname>sd_bus_creds_get_uid</refname>
+    <refname>sd_bus_creds_get_euid</refname>
+    <refname>sd_bus_creds_get_suid</refname>
+    <refname>sd_bus_creds_get_fsuid</refname>
+    <refname>sd_bus_creds_get_gid</refname>
+    <refname>sd_bus_creds_get_egid</refname>
+    <refname>sd_bus_creds_get_sgid</refname>
+    <refname>sd_bus_creds_get_fsgid</refname>
+    <refname>sd_bus_creds_get_supplementary_gids</refname>
+    <refname>sd_bus_creds_get_comm</refname>
+    <refname>sd_bus_creds_get_tid_comm</refname>
+    <refname>sd_bus_creds_get_exe</refname>
+    <refname>sd_bus_creds_get_cmdline</refname>
+    <refname>sd_bus_creds_get_cgroup</refname>
+    <refname>sd_bus_creds_get_unit</refname>
+    <refname>sd_bus_creds_get_slice</refname>
+    <refname>sd_bus_creds_get_user_unit</refname>
+    <refname>sd_bus_creds_get_user_slice</refname>
+    <refname>sd_bus_creds_get_session</refname>
+    <refname>sd_bus_creds_get_owner_uid</refname>
+    <refname>sd_bus_creds_has_effective_cap</refname>
+    <refname>sd_bus_creds_has_permitted_cap</refname>
+    <refname>sd_bus_creds_has_inheritable_cap</refname>
+    <refname>sd_bus_creds_has_bounding_cap</refname>
+    <refname>sd_bus_creds_get_selinux_context</refname>
+    <refname>sd_bus_creds_get_audit_session_id</refname>
+    <refname>sd_bus_creds_get_audit_login_uid</refname>
+    <refname>sd_bus_creds_get_tty</refname>
+    <refname>sd_bus_creds_get_unique_name</refname>
+    <refname>sd_bus_creds_get_well_known_names</refname>
+    <refname>sd_bus_creds_get_description</refname>
+
+    <refpurpose>Retrieve fields from a credentials object</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_creds_get_pid</function></funcdef>
+        <paramdef>sd_bus_creds *<parameter>c</parameter></paramdef>
+        <paramdef>pid_t *<parameter>pid</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_creds_get_ppid</function></funcdef>
+        <paramdef>sd_bus_creds *<parameter>c</parameter></paramdef>
+        <paramdef>pid_t *<parameter>ppid</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_creds_get_tid</function></funcdef>
+        <paramdef>sd_bus_creds *<parameter>c</parameter></paramdef>
+        <paramdef>pid_t *<parameter>tid</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_creds_get_uid</function></funcdef>
+        <paramdef>sd_bus_creds *<parameter>c</parameter></paramdef>
+        <paramdef>uid_t *<parameter>uid</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_creds_get_euid</function></funcdef>
+        <paramdef>sd_bus_creds *<parameter>c</parameter></paramdef>
+        <paramdef>uid_t *<parameter>uid</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_creds_get_suid</function></funcdef>
+        <paramdef>sd_bus_creds *<parameter>c</parameter></paramdef>
+        <paramdef>uid_t *<parameter>uid</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_creds_get_fsuid</function></funcdef>
+        <paramdef>sd_bus_creds *<parameter>c</parameter></paramdef>
+        <paramdef>uid_t *<parameter>uid</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_creds_get_gid</function></funcdef>
+        <paramdef>sd_bus_creds *<parameter>c</parameter></paramdef>
+        <paramdef>gid_t *<parameter>gid</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_creds_get_egid</function></funcdef>
+        <paramdef>sd_bus_creds *<parameter>c</parameter></paramdef>
+        <paramdef>gid_t *<parameter>gid</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_creds_get_sgid</function></funcdef>
+        <paramdef>sd_bus_creds *<parameter>c</parameter></paramdef>
+        <paramdef>gid_t *<parameter>gid</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_creds_get_fsgid</function></funcdef>
+        <paramdef>sd_bus_creds *<parameter>c</parameter></paramdef>
+        <paramdef>gid_t *<parameter>gid</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_creds_get_supplementary_gids</function></funcdef>
+        <paramdef>sd_bus_creds *<parameter>c</parameter></paramdef>
+        <paramdef>const gid_t **<parameter>gids</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_creds_get_comm</function></funcdef>
+        <paramdef>sd_bus_creds *<parameter>c</parameter></paramdef>
+        <paramdef>const char **<parameter>comm</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_creds_get_tid_comm</function></funcdef>
+        <paramdef>sd_bus_creds *<parameter>c</parameter></paramdef>
+        <paramdef>const char **<parameter>comm</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_creds_get_exe</function></funcdef>
+        <paramdef>sd_bus_creds *<parameter>c</parameter></paramdef>
+        <paramdef>const char **<parameter>exe</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_creds_get_cmdline</function></funcdef>
+        <paramdef>sd_bus_creds *<parameter>c</parameter></paramdef>
+        <paramdef>char ***<parameter>cmdline</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_creds_get_cgroup</function></funcdef>
+        <paramdef>sd_bus_creds *<parameter>c</parameter></paramdef>
+        <paramdef>const char **<parameter>cgroup</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_creds_get_unit</function></funcdef>
+        <paramdef>sd_bus_creds *<parameter>c</parameter></paramdef>
+        <paramdef>const char **<parameter>unit</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_creds_get_slice</function></funcdef>
+        <paramdef>sd_bus_creds *<parameter>c</parameter></paramdef>
+        <paramdef>const char **<parameter>slice</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_creds_get_user_unit</function></funcdef>
+        <paramdef>sd_bus_creds *<parameter>c</parameter></paramdef>
+        <paramdef>const char **<parameter>unit</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_creds_get_user_slice</function></funcdef>
+        <paramdef>sd_bus_creds *<parameter>c</parameter></paramdef>
+        <paramdef>const char **<parameter>slice</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_creds_get_session</function></funcdef>
+        <paramdef>sd_bus_creds *<parameter>c</parameter></paramdef>
+        <paramdef>const char **<parameter>slice</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_creds_get_owner_uid</function></funcdef>
+        <paramdef>sd_bus_creds *<parameter>c</parameter></paramdef>
+        <paramdef>uid_t *<parameter>uid</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_creds_has_effective_cap</function></funcdef>
+        <paramdef>sd_bus_creds *<parameter>c</parameter></paramdef>
+        <paramdef>int <parameter>capability</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_creds_has_permitted_cap</function></funcdef>
+        <paramdef>sd_bus_creds *<parameter>c</parameter></paramdef>
+        <paramdef>int <parameter>capability</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_creds_has_inheritable_cap</function></funcdef>
+        <paramdef>sd_bus_creds *<parameter>c</parameter></paramdef>
+        <paramdef>int <parameter>capability</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_creds_has_bounding_cap</function></funcdef>
+        <paramdef>sd_bus_creds *<parameter>c</parameter></paramdef>
+        <paramdef>int <parameter>capability</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_creds_get_selinux_context</function></funcdef>
+        <paramdef>sd_bus_creds *<parameter>c</parameter></paramdef>
+        <paramdef>const char **<parameter>context</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_creds_get_audit_session_id</function></funcdef>
+        <paramdef>sd_bus_creds *<parameter>c</parameter></paramdef>
+        <paramdef>uint32_t *<parameter>sessionid</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_creds_get_audit_login_uid</function></funcdef>
+        <paramdef>sd_bus_creds *<parameter>c</parameter></paramdef>
+        <paramdef>uid_t *<parameter>loginuid</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_creds_get_tty</function></funcdef>
+        <paramdef>sd_bus_creds *<parameter>c</parameter></paramdef>
+        <paramdef>const char **<parameter>tty</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_creds_get_unique_name</function></funcdef>
+        <paramdef>sd_bus_creds *<parameter>c</parameter></paramdef>
+        <paramdef>const char **<parameter>name</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_creds_get_well_known_names</function></funcdef>
+        <paramdef>sd_bus_creds *<parameter>c</parameter></paramdef>
+        <paramdef>char ***<parameter>name</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_creds_get_description</function></funcdef>
+        <paramdef>sd_bus_creds *<parameter>c</parameter></paramdef>
+        <paramdef>const char **<parameter>name</parameter></paramdef>
+      </funcprototype>
+
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>These functions return credential information from an
+    <parameter>sd_bus_creds</parameter> object. Credential objects may
+    be created with
+    <citerefentry><refentrytitle>sd_bus_creds_new_from_pid</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    in which case they describe the credentials of the process
+    identified by the specified PID, with
+    <citerefentry><refentrytitle>sd_bus_get_name_creds</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    in which case they describe the credentials of a bus peer
+    identified by the specified bus name, with
+    <citerefentry><refentrytitle>sd_bus_get_owner_creds</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    in which case they describe the credentials of the creator of a
+    bus, or with
+    <citerefentry><refentrytitle>sd_bus_message_get_creds</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    in which case they describe the credentials of the sender of the
+    message.</para>
+
+    <para>Not all credential fields are part of every
+    <literal>sd_bus_creds</literal> object. Use
+    <citerefentry><refentrytitle>sd_bus_creds_get_mask</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    to determine the mask of fields available.</para>
+
+    <para><function>sd_bus_creds_get_pid()</function> will retrieve
+    the PID (process identifier). Similarly,
+    <function>sd_bus_creds_get_ppid()</function> will retrieve the
+    parent PID. Note that PID 1 has no parent process, in which case
+    -ENXIO is returned.</para>
+
+    <para><function>sd_bus_creds_get_tid()</function> will retrieve the
+    TID (thread identifier).</para>
+
+    <para><function>sd_bus_creds_get_uid()</function> will retrieve
+    the numeric UID (user identifier). Similarly,
+    <function>sd_bus_creds_get_euid()</function> returns the effective
+    UID, <function>sd_bus_creds_get_suid()</function> the saved UID
+    and <function>sd_bus_creds_get_fsuid()</function> the file system
+    UID.</para>
+
+    <para><function>sd_bus_creds_get_gid()</function> will retrieve the
+    numeric GID (group identifier). Similarly,
+    <function>sd_bus_creds_get_egid()</function> returns the effective
+    GID, <function>sd_bus_creds_get_sgid()</function> the saved GID
+    and <function>sd_bus_creds_get_fsgid()</function> the file system
+    GID.</para>
+
+    <para><function>sd_bus_creds_get_supplementary_gids()</function>
+    will retrieve the supplementary GIDs list.</para>
+
+    <para><function>sd_bus_creds_get_comm()</function> will retrieve the
+    comm field (truncated name of the executable, as stored in
+    <filename>/proc/<replaceable>pid</replaceable>/comm</filename>).
+    </para>
+
+    <para><function>sd_bus_creds_get_tid_comm()</function> will retrieve
+    the comm field of the thread (as stored in
+    <filename>/proc/<replaceable>pid</replaceable>/task/<replaceable>tid</replaceable>/comm</filename>).
+    </para>
+
+    <para><function>sd_bus_creds_get_exe()</function> will retrieve the path to the program executable (as
+    stored in the <filename>/proc/<replaceable>pid</replaceable>/exe</filename> link, but with the <literal>
+    (deleted)</literal> suffix removed). Note that kernel threads do not have an executable path, in which
+    case -ENXIO is returned. Note that this property should not be used for more than explanatory
+    information, in particular it should not be used for security-relevant decisions. That's because the
+    executable might have been replaced or removed by the time the value can be processed. Moreover, the
+    kernel exports this information in an ambiguous way (i.e. a deleted executable cannot be safely
+    distinguished from one whose name suffix is <literal> (deleted)</literal>).</para>
+
+    <para><function>sd_bus_creds_get_cmdline()</function> will
+    retrieve an array of command line arguments (as stored in
+    <filename>/proc/<replaceable>pid</replaceable>/cmdline</filename>). Note
+    that kernel threads do not have a command line, in which case
+    -ENXIO is returned.</para>
+
+    <para><function>sd_bus_creds_get_cgroup()</function> will retrieve the control group path. See <ulink
+    url="https://docs.kernel.org/admin-guide/cgroup-v2.html">Control Groups v2</ulink>.
+    </para>
+
+    <para><function>sd_bus_creds_get_unit()</function> will retrieve
+    the systemd unit name (in the system instance of systemd) that the
+    process is a part of. See
+    <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>. For
+    processes that are not part of a unit, returns -ENXIO.
+    </para>
+
+    <para><function>sd_bus_creds_get_user_unit()</function> will
+    retrieve the systemd unit name (in the user instance of systemd)
+    that the process is a part of. See
+    <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>. For
+    processes that are not part of a user unit, returns -ENXIO.
+    </para>
+
+    <para><function>sd_bus_creds_get_slice()</function> will retrieve
+    the systemd slice (a unit in the system instance of systemd) that
+    the process is a part of. See
+    <citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry>. Similarly,
+    <function>sd_bus_creds_get_user_slice()</function> retrieves the
+    systemd slice of the process, in the user instance of systemd.
+    </para>
+
+    <para><function>sd_bus_creds_get_session()</function> will
+    retrieve the identifier of the login session that the process is
+    a part of. Please note the login session may be limited to a stub
+    process or two.  User processes may instead be started from their
+    systemd user manager, e.g. GUI applications started using DBus
+    activation, as well as service processes which are shared between
+    multiple logins of the same user. For processes that are not part
+    of a session, returns -ENXIO.</para>
+
+    <para><function>sd_bus_creds_get_owner_uid()</function> will
+    retrieve the numeric UID (user identifier) of the user who owns
+    the user unit or login session that the process is a part of. See
+    <citerefentry><refentrytitle>systemd-logind.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+    For processes that are not part of a user unit or session, returns
+    -ENXIO.
+    </para>
+
+    <para><function>sd_bus_creds_has_effective_cap()</function> will check whether the capability specified by
+    <parameter>capability</parameter> was set in the effective capabilities mask. A positive return value means that it
+    was set, zero means that it was not set, and a negative return value indicates an error. See <citerefentry
+    project='man-pages'><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry> and the
+    <varname>AmbientCapabilities=</varname> and <varname>CapabilityBoundingSet=</varname> settings in
+    <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+    </para>
+
+    <para><function>sd_bus_creds_has_permitted_cap()</function> is
+    similar to <function>sd_bus_creds_has_effective_cap()</function>,
+    but will check the permitted capabilities mask.</para>
+
+    <para><function>sd_bus_creds_has_inheritable_cap()</function> is
+    similar to <function>sd_bus_creds_has_effective_cap()</function>,
+    but will check the inheritable capabilities mask.</para>
+
+    <para><function>sd_bus_creds_has_bounding_cap()</function> is
+    similar to <function>sd_bus_creds_has_effective_cap()</function>,
+    but will check the bounding capabilities mask.</para>
+
+    <para><function>sd_bus_creds_get_selinux_context()</function> will
+    retrieve the SELinux security context (label) of the process.</para>
+
+    <para><function>sd_bus_creds_get_audit_session_id()</function>
+    will retrieve the audit session identifier of the process. Returns
+    -ENXIO for processes that are not part of an audit session.</para>
+
+    <para><function>sd_bus_creds_get_audit_login_uid()</function> will
+    retrieve the audit user login identifier (the identifier of the
+    user who is "responsible" for the session). Returns -ENXIO for
+    processes that are not part of an audit session.</para>
+
+    <para><function>sd_bus_creds_get_tty()</function> will retrieve
+    the controlling TTY, without the prefixing "/dev/". Returns -ENXIO
+    for processes that have no controlling TTY.</para>
+
+    <para><function>sd_bus_creds_get_unique_name()</function> will
+    retrieve the D-Bus unique name. See <ulink
+    url="https://dbus.freedesktop.org/doc/dbus-specification.html#message-protocol-names-bus">The
+    D-Bus specification</ulink>.</para>
+
+    <para><function>sd_bus_creds_get_well_known_names()</function> will
+    retrieve the set of D-Bus well-known names. See <ulink
+    url="https://dbus.freedesktop.org/doc/dbus-specification.html#message-protocol-names-bus">The
+    D-Bus specification</ulink>.</para>
+
+    <para><function>sd_bus_creds_get_description()</function> will
+    retrieve a descriptive name of the bus connection of the
+    peer. This name is useful to discern multiple bus connections by
+    the same peer, and may be altered by the peer with the
+    <citerefentry><refentrytitle>sd_bus_set_description</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    call.</para>
+
+    <para>All functions that take a <parameter>const
+    char**</parameter> parameter will store the answer there as an
+    address of a <constant>NUL</constant>-terminated string. It will be valid as long as
+    <parameter>c</parameter> remains valid, and should not be freed or
+    modified by the caller.</para>
+
+    <para>All functions that take a <parameter>char***</parameter>
+    parameter will store the answer there as an address of an array
+    of strings. Each individual string is <constant>NUL</constant>-terminated, and the
+    array is <constant>NULL</constant>-terminated as a whole. It will be valid as long as
+    <parameter>c</parameter> remains valid, and should not be freed or
+    modified by the caller.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, these calls return 0 or a positive integer. On
+    failure, these calls return a negative errno-style error code.
+    </para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-ENODATA</constant></term>
+
+          <listitem><para>The given field is not available in the credentials object
+          <parameter>c</parameter>.</para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENXIO</constant></term>
+
+          <listitem><para>The given field is not specified for the described process or peer. This will be
+          returned by <function>sd_bus_creds_get_unit()</function>,
+          <function>sd_bus_creds_get_slice()</function>, <function>sd_bus_creds_get_user_unit()</function>,
+          <function>sd_bus_creds_get_user_slice()</function>, and
+          <function>sd_bus_creds_get_session()</function> if the process is not part of a systemd system
+          unit, systemd user unit, systemd slice, or logind session. It will be returned by
+          <function>sd_bus_creds_get_owner_uid()</function> if the process is not part of a systemd user unit
+          or logind session. It will also be returned by <function>sd_bus_creds_get_exe()</function> and
+          <function>sd_bus_creds_get_cmdline()</function> for kernel threads (since these are not started
+          from an executable binary, nor have a command line), and by
+          <function>sd_bus_creds_get_audit_session_id()</function> and
+          <function>sd_bus_creds_get_audit_login_uid()</function> when the process is not part of an audit
+          session, and <function>sd_bus_creds_get_tty()</function> if the process has no controlling
+          TTY.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>Specified pointer parameter is <constant>NULL</constant>.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOMEM</constant></term>
+
+          <listitem><para>Memory allocation failed.</para></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_bus_creds_get_pid()</function>,
+    <function>sd_bus_creds_get_tid()</function>,
+    <function>sd_bus_creds_get_gid()</function>,
+    <function>sd_bus_creds_get_comm()</function>,
+    <function>sd_bus_creds_get_tid_comm()</function>,
+    <function>sd_bus_creds_get_exe()</function>,
+    <function>sd_bus_creds_get_cmdline()</function>,
+    <function>sd_bus_creds_get_cgroup()</function>,
+    <function>sd_bus_creds_get_unit()</function>,
+    <function>sd_bus_creds_get_user_unit()</function>,
+    <function>sd_bus_creds_get_slice()</function>,
+    <function>sd_bus_creds_get_session()</function>,
+    <function>sd_bus_creds_get_owner_uid()</function>,
+    <function>sd_bus_creds_has_effective_cap()</function>,
+    <function>sd_bus_creds_has_permitted_cap()</function>,
+    <function>sd_bus_creds_has_inheritable_cap()</function>,
+    <function>sd_bus_creds_has_bounding_cap()</function>,
+    <function>sd_bus_creds_get_selinux_context()</function>,
+    <function>sd_bus_creds_get_audit_session_id()</function>,
+    <function>sd_bus_creds_get_audit_login_uid()</function>,
+    <function>sd_bus_creds_get_unique_name()</function>, and
+    <function>sd_bus_creds_get_well_known_names()</function> were added in version 209.</para>
+    <para><function>sd_bus_creds_get_ppid()</function>,
+    <function>sd_bus_creds_get_uid()</function>,
+    <function>sd_bus_creds_get_euid()</function>,
+    <function>sd_bus_creds_get_suid()</function>,
+    <function>sd_bus_creds_get_fsuid()</function>,
+    <function>sd_bus_creds_get_egid()</function>,
+    <function>sd_bus_creds_get_sgid()</function>,
+    <function>sd_bus_creds_get_fsgid()</function>,
+    <function>sd_bus_creds_get_supplementary_gids()</function>,
+    <function>sd_bus_creds_get_tty()</function>, and
+    <function>sd_bus_creds_get_description()</function> were added in version 220.</para>
+    <para><function>sd_bus_creds_get_user_slice()</function> was added in version 223.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_creds_new_from_pid</refentrytitle><manvolnum>2</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>fork</refentrytitle><manvolnum>2</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>execve</refentrytitle><manvolnum>2</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>credentials</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>free</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>proc</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.journal-fields</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_bus_creds_new_from_pid.xml b/man/sd_bus_creds_new_from_pid.xml
new file mode 100644
index 0000000..239f996
--- /dev/null
+++ b/man/sd_bus_creds_new_from_pid.xml
@@ -0,0 +1,325 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_bus_creds_new_from_pid" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_bus_creds_new_from_pid</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_creds_new_from_pid</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_creds_new_from_pid</refname>
+    <refname>sd_bus_creds_get_mask</refname>
+    <refname>sd_bus_creds_get_augmented_mask</refname>
+    <refname>sd_bus_creds_ref</refname>
+    <refname>sd_bus_creds_unref</refname>
+    <refname>sd_bus_creds_unrefp</refname>
+
+    <refpurpose>Retrieve credentials object for the specified PID</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_creds_new_from_pid</function></funcdef>
+        <paramdef>pid_t <parameter>pid</parameter></paramdef>
+        <paramdef>uint64_t <parameter>creds_mask</parameter></paramdef>
+        <paramdef>sd_bus_creds **<parameter>ret</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>uint64_t <function>sd_bus_creds_get_mask</function></funcdef>
+        <paramdef>sd_bus_creds *<parameter>c</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>uint64_t <function>sd_bus_creds_get_augmented_mask</function></funcdef>
+        <paramdef>sd_bus_creds *<parameter>c</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>sd_bus_creds *<function>sd_bus_creds_ref</function></funcdef>
+        <paramdef>sd_bus_creds *<parameter>c</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>sd_bus_creds *<function>sd_bus_creds_unref</function></funcdef>
+        <paramdef>sd_bus_creds *<parameter>c</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>void <function>sd_bus_creds_unrefp</function></funcdef>
+        <paramdef>sd_bus_creds **<parameter>c</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+
+    <para>
+      <constant>SD_BUS_CREDS_PID</constant>,
+      <constant>SD_BUS_CREDS_PPID</constant>,
+      <constant>SD_BUS_CREDS_TID</constant>,
+      <constant>SD_BUS_CREDS_UID</constant>,
+      <constant>SD_BUS_CREDS_EUID</constant>,
+      <constant>SD_BUS_CREDS_SUID</constant>,
+      <constant>SD_BUS_CREDS_FSUID</constant>,
+      <constant>SD_BUS_CREDS_GID</constant>,
+      <constant>SD_BUS_CREDS_EGID</constant>,
+      <constant>SD_BUS_CREDS_SGID</constant>,
+      <constant>SD_BUS_CREDS_FSGID</constant>,
+      <constant>SD_BUS_CREDS_SUPPLEMENTARY_GIDS</constant>,
+      <constant>SD_BUS_CREDS_COMM</constant>,
+      <constant>SD_BUS_CREDS_TID_COMM</constant>,
+      <constant>SD_BUS_CREDS_EXE</constant>,
+      <constant>SD_BUS_CREDS_CMDLINE</constant>,
+      <constant>SD_BUS_CREDS_CGROUP</constant>,
+      <constant>SD_BUS_CREDS_UNIT</constant>,
+      <constant>SD_BUS_CREDS_SLICE</constant>,
+      <constant>SD_BUS_CREDS_USER_UNIT</constant>,
+      <constant>SD_BUS_CREDS_USER_SLICE</constant>,
+      <constant>SD_BUS_CREDS_SESSION</constant>,
+      <constant>SD_BUS_CREDS_OWNER_UID</constant>,
+      <constant>SD_BUS_CREDS_EFFECTIVE_CAPS</constant>,
+      <constant>SD_BUS_CREDS_PERMITTED_CAPS</constant>,
+      <constant>SD_BUS_CREDS_INHERITABLE_CAPS</constant>,
+      <constant>SD_BUS_CREDS_BOUNDING_CAPS</constant>,
+      <constant>SD_BUS_CREDS_SELINUX_CONTEXT</constant>,
+      <constant>SD_BUS_CREDS_AUDIT_SESSION_ID</constant>,
+      <constant>SD_BUS_CREDS_AUDIT_LOGIN_UID</constant>,
+      <constant>SD_BUS_CREDS_TTY</constant>,
+      <constant>SD_BUS_CREDS_UNIQUE_NAME</constant>,
+      <constant>SD_BUS_CREDS_WELL_KNOWN_NAMES</constant>,
+      <constant>SD_BUS_CREDS_DESCRIPTION</constant>,
+      <constant>SD_BUS_CREDS_AUGMENT</constant>,
+      <constant>_SD_BUS_CREDS_ALL</constant>
+    </para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_bus_creds_new_from_pid()</function> creates a
+    new credentials object and fills it with information about the
+    process <parameter>pid</parameter>. The pointer to this object
+    will be stored in the <parameter>ret</parameter> pointer. Note that
+    credential objects may also be created and retrieved via
+    <citerefentry><refentrytitle>sd_bus_get_name_creds</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_bus_get_owner_creds</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    and
+    <citerefentry><refentrytitle>sd_bus_message_get_creds</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para>
+
+    <para>The information that will be stored is determined by
+    <parameter>creds_mask</parameter>. It may contain a subset of ORed
+    constants <constant>SD_BUS_CREDS_PID</constant>,
+    <constant>SD_BUS_CREDS_PPID</constant>,
+    <constant>SD_BUS_CREDS_TID</constant>,
+    <constant>SD_BUS_CREDS_UID</constant>,
+    <constant>SD_BUS_CREDS_EUID</constant>,
+    <constant>SD_BUS_CREDS_SUID</constant>,
+    <constant>SD_BUS_CREDS_FSUID</constant>,
+    <constant>SD_BUS_CREDS_GID</constant>,
+    <constant>SD_BUS_CREDS_EGID</constant>,
+    <constant>SD_BUS_CREDS_SGID</constant>,
+    <constant>SD_BUS_CREDS_FSGID</constant>,
+    <constant>SD_BUS_CREDS_SUPPLEMENTARY_GIDS</constant>,
+    <constant>SD_BUS_CREDS_COMM</constant>,
+    <constant>SD_BUS_CREDS_TID_COMM</constant>,
+    <constant>SD_BUS_CREDS_EXE</constant>,
+    <constant>SD_BUS_CREDS_CMDLINE</constant>,
+    <constant>SD_BUS_CREDS_CGROUP</constant>,
+    <constant>SD_BUS_CREDS_UNIT</constant>,
+    <constant>SD_BUS_CREDS_SLICE</constant>,
+    <constant>SD_BUS_CREDS_USER_UNIT</constant>,
+    <constant>SD_BUS_CREDS_USER_SLICE</constant>,
+    <constant>SD_BUS_CREDS_SESSION</constant>,
+    <constant>SD_BUS_CREDS_OWNER_UID</constant>,
+    <constant>SD_BUS_CREDS_EFFECTIVE_CAPS</constant>,
+    <constant>SD_BUS_CREDS_PERMITTED_CAPS</constant>,
+    <constant>SD_BUS_CREDS_INHERITABLE_CAPS</constant>,
+    <constant>SD_BUS_CREDS_BOUNDING_CAPS</constant>,
+    <constant>SD_BUS_CREDS_SELINUX_CONTEXT</constant>,
+    <constant>SD_BUS_CREDS_AUDIT_SESSION_ID</constant>,
+    <constant>SD_BUS_CREDS_AUDIT_LOGIN_UID</constant>,
+    <constant>SD_BUS_CREDS_TTY</constant>,
+    <constant>SD_BUS_CREDS_UNIQUE_NAME</constant>,
+    <constant>SD_BUS_CREDS_WELL_KNOWN_NAMES</constant>, and
+    <constant>SD_BUS_CREDS_DESCRIPTION</constant>. Use the special
+    value <constant>_SD_BUS_CREDS_ALL</constant> to request all
+    supported fields. The <constant>SD_BUS_CREDS_AUGMENT</constant>
+    constant may not be ORed into the mask for invocations of
+    <function>sd_bus_creds_new_from_pid()</function>.</para>
+
+    <para>Fields can be retrieved from the credentials object using
+    <citerefentry><refentrytitle>sd_bus_creds_get_pid</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    and other functions which correspond directly to the constants
+    listed above.</para>
+
+    <para>A mask of fields which were actually successfully retrieved
+    can be retrieved with
+    <function>sd_bus_creds_get_mask()</function>. If the credentials
+    object was created with
+    <function>sd_bus_creds_new_from_pid()</function>, this will be a
+    subset of fields requested in <parameter>creds_mask</parameter>.
+    </para>
+
+    <para>Similar to <function>sd_bus_creds_get_mask()</function>, the
+    function <function>sd_bus_creds_get_augmented_mask()</function>
+    returns a bitmask of field constants. The mask indicates which
+    credential fields have been retrieved in a non-atomic fashion. For
+    credential objects created via
+    <function>sd_bus_creds_new_from_pid()</function>, this mask will be
+    identical to the mask returned by
+    <function>sd_bus_creds_get_mask()</function>. However, for
+    credential objects retrieved via
+    <function>sd_bus_get_name_creds()</function>, this mask will be set
+    for the credential fields that could not be determined atomically
+    at peer connection time, and which were later added by reading
+    augmenting credential data from
+    <filename>/proc/</filename>. Similarly, for credential objects
+    retrieved via <function>sd_bus_get_owner_creds()</function>, the
+    mask is set for the fields that could not be determined atomically
+    at bus creation time, but have been augmented. Similarly, for
+    credential objects retrieved via
+    <function>sd_bus_message_get_creds()</function>, the mask is set
+    for the fields that could not be determined atomically at message
+    sending time, but have been augmented. The mask returned by
+    <function>sd_bus_creds_get_augmented_mask()</function> is always a
+    subset of (or identical to) the mask returned by
+    <function>sd_bus_creds_get_mask()</function> for the same
+    object. The latter call hence returns all credential fields
+    available in the credential object, the former then marks the
+    subset of those that have been augmented. Note that augmented
+    fields are unsuitable for authorization decisions, as they may be
+    retrieved at different times, thus being subject to races. Hence,
+    augmented fields should be used exclusively for informational
+    purposes.
+    </para>
+
+    <para><function>sd_bus_creds_ref()</function> creates a new
+    reference to the credentials object <parameter>c</parameter>. This
+    object will not be destroyed until
+    <function>sd_bus_creds_unref()</function> has been called as many
+    times plus once more. Once the reference count has dropped to zero,
+    <parameter>c</parameter> cannot be used anymore, so further
+    calls to <function>sd_bus_creds_ref(c)</function> or
+    <function>sd_bus_creds_unref(c)</function> are illegal.</para>
+
+    <para><function>sd_bus_creds_unref()</function> destroys a reference
+    to <parameter>c</parameter>.</para>
+
+    <para><function>sd_bus_creds_unrefp()</function> is similar to
+    <function>sd_bus_creds_unref()</function> but takes a pointer to a
+    pointer to an <type>sd_bus_creds</type> object. This call is useful in
+    conjunction with GCC's and LLVM's <ulink
+    url="https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html">Clean-up
+    Variable Attribute</ulink>. Note that this function is defined as
+    inline function.</para>
+
+    <para><function>sd_bus_creds_ref()</function>,
+    <function>sd_bus_creds_unref()</function> and
+    <function>sd_bus_creds_unrefp()</function> execute no operation if
+    the passed in bus credentials object is
+    <constant>NULL</constant>.</para>
+
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, <function>sd_bus_creds_new_from_pid()</function>
+    returns 0 or a positive integer. On failure, it returns a negative
+    errno-style error code.</para>
+
+    <para><function>sd_bus_creds_get_mask()</function> returns the
+    mask of successfully acquired fields.</para>
+
+    <para><function>sd_bus_creds_get_augmented_mask()</function>
+    returns the mask of fields that have been augmented from data in
+    <filename>/proc/</filename>, and are thus not suitable for
+    authorization decisions.</para>
+
+    <para><function>sd_bus_creds_ref()</function> always returns the
+    argument.</para>
+
+    <para><function>sd_bus_creds_unref()</function> always returns
+    <constant>NULL</constant>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Reference ownership</title>
+
+    <para>Function <function>sd_bus_creds_new_from_pid()</function>
+    creates a new object and the caller owns the sole reference. When
+    not needed anymore, this reference should be destroyed with
+    <citerefentry><refentrytitle>sd_bus_creds_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+    </para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+
+        <varlistentry>
+          <term><constant>-ESRCH</constant></term>
+
+          <listitem><para>Specified <parameter>pid</parameter> could not be found.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>Specified parameter is invalid (<constant>NULL</constant> in case of output
+          parameters).</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOMEM</constant></term>
+
+          <listitem><para>Memory allocation failed.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EOPNOTSUPP</constant></term>
+
+          <listitem><para>One of the requested fields is unknown to the local system.</para></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_bus_creds_new_from_pid()</function>,
+    <function>sd_bus_creds_get_mask()</function>,
+    <function>sd_bus_creds_ref()</function>, and
+    <function>sd_bus_creds_unref()</function> were added in version 209.</para>
+    <para><function>sd_bus_creds_get_augmented_mask()</function> was added in version 223.</para>
+    <para><function>sd_bus_creds_unrefp()</function> was added in version 229.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_creds_get_pid</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_get_name_creds</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_get_owner_creds</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_message_get_creds</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_bus_default.xml b/man/sd_bus_default.xml
new file mode 100644
index 0000000..05c438f
--- /dev/null
+++ b/man/sd_bus_default.xml
@@ -0,0 +1,367 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_bus_default" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_bus_default</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_default</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_default</refname>
+    <refname>sd_bus_default_user</refname>
+    <refname>sd_bus_default_system</refname>
+
+    <refname>sd_bus_open</refname>
+    <refname>sd_bus_open_with_description</refname>
+    <refname>sd_bus_open_user</refname>
+    <refname>sd_bus_open_user_with_description</refname>
+    <refname>sd_bus_open_user_machine</refname>
+    <refname>sd_bus_open_system</refname>
+    <refname>sd_bus_open_system_with_description</refname>
+    <refname>sd_bus_open_system_remote</refname>
+    <refname>sd_bus_open_system_machine</refname>
+
+    <refpurpose>Acquire a connection to a system or user bus</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_default</function></funcdef>
+        <paramdef>sd_bus **<parameter>bus</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_default_user</function></funcdef>
+        <paramdef>sd_bus **<parameter>bus</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_default_system</function></funcdef>
+        <paramdef>sd_bus **<parameter>bus</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_open</function></funcdef>
+        <paramdef>sd_bus **<parameter>bus</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_open_with_description</function></funcdef>
+        <paramdef>sd_bus **<parameter>bus</parameter></paramdef>
+        <paramdef>const char *<parameter>description</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_open_user</function></funcdef>
+        <paramdef>sd_bus **<parameter>bus</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_open_user_with_description</function></funcdef>
+        <paramdef>sd_bus **<parameter>bus</parameter></paramdef>
+        <paramdef>const char *<parameter>description</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_open_user_machine</function></funcdef>
+        <paramdef>sd_bus **<parameter>bus</parameter></paramdef>
+        <paramdef>const char *<parameter>machine</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_open_system</function></funcdef>
+        <paramdef>sd_bus **<parameter>bus</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_open_system_with_description</function></funcdef>
+        <paramdef>sd_bus **<parameter>bus</parameter></paramdef>
+        <paramdef>const char *<parameter>description</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_open_system_remote</function></funcdef>
+        <paramdef>sd_bus **<parameter>bus</parameter></paramdef>
+        <paramdef>const char *<parameter>host</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_open_system_machine</function></funcdef>
+        <paramdef>sd_bus **<parameter>bus</parameter></paramdef>
+        <paramdef>const char *<parameter>machine</parameter></paramdef>
+      </funcprototype>
+
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_bus_default()</function> acquires a bus
+    connection object to the user bus when invoked from within a user
+    slice (any session under <literal>user-*.slice</literal>, e.g.:
+    <literal>user@1000.service</literal>), or to the system bus
+    otherwise. The connection object is associated with the calling
+    thread. Each time the function is invoked from the same thread,
+    the same object is returned, but its reference count is increased
+    by one, as long as at least one reference is kept. When the last
+    reference to the connection is dropped (using the
+    <citerefentry><refentrytitle>sd_bus_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    call), the connection is terminated. Note that the connection is
+    not automatically terminated when the associated thread ends. It
+    is important to drop the last reference to the bus connection
+    explicitly before the thread ends, as otherwise, the connection will
+    leak. Also, queued but unread or unwritten messages keep the
+    bus referenced, see below.</para>
+
+    <para><function>sd_bus_default_user()</function> returns a user
+    bus connection object associated with the calling thread.
+    <function>sd_bus_default_system()</function> is similar, but
+    connects to the system bus. Note that
+    <function>sd_bus_default()</function> is identical to these two
+    calls, depending on the execution context.</para>
+
+    <para><function>sd_bus_open()</function> creates a new,
+    independent bus connection to the user bus when invoked in user
+    context, or the system bus
+    otherwise. <function>sd_bus_open_user()</function> is similar, but
+    connects only to the user bus.
+    <function>sd_bus_open_system()</function> does the same, but
+    connects to the system bus. In contrast to
+    <function>sd_bus_default()</function>,
+    <function>sd_bus_default_user()</function>, and
+    <function>sd_bus_default_system()</function>, these calls return
+    new, independent connection objects that are not associated with
+    the invoking thread and are not shared between multiple
+    invocations. It is recommended to share connections per thread to
+    efficiently make use the available resources. Thus, it is
+    recommended to use <function>sd_bus_default()</function>,
+    <function>sd_bus_default_user()</function> and
+    <function>sd_bus_default_system()</function> to connect to the
+    user or system buses.</para>
+
+    <para><function>sd_bus_open_with_description()</function>,
+    <function>sd_bus_open_user_with_description()</function>, and
+    <function>sd_bus_open_system_with_description()</function> are similar to
+    <function>sd_bus_open()</function>, <function>sd_bus_open_user()</function>, and
+    <function>sd_bus_open_system()</function>, but allow a description string to be set, see
+    <citerefentry><refentrytitle>sd_bus_set_description</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+    <parameter>description</parameter> may be <constant>NULL</constant>, in which case this function
+    is equivalent to <function>sd_bus_open()</function>. This description string is used in log
+    messages about the bus object, and including a "name" for the bus makes them easier to
+    understand. Some messages are emitted during bus initialization, hence using this function is
+    preferable to setting the description later with
+    <function>sd_bus_open_with_description()</function>. The argument is copied internally and will
+    not be referenced after the function returns.</para>
+
+    <para>If the <varname>$DBUS_SESSION_BUS_ADDRESS</varname> environment
+    variable is set
+    (cf. <citerefentry project='man-pages'><refentrytitle>environ</refentrytitle><manvolnum>7</manvolnum></citerefentry>),
+    it will be used as the address of the user bus. This variable can
+    contain multiple addresses separated by <literal>;</literal>. If
+    this variable is not set, a suitable default for the default user
+    D-Bus instance will be used.</para>
+
+    <para>If the <varname>$DBUS_SYSTEM_BUS_ADDRESS</varname>
+    environment variable is set, it will be used as the address of the
+    system bus. This variable uses the same syntax as
+    <varname>$DBUS_SESSION_BUS_ADDRESS</varname>. If this variable is
+    not set, a suitable default for the default system D-Bus instance
+    will be used.</para>
+
+    <para><function>sd_bus_open_system_remote()</function> connects to the system bus on
+    the specified host using
+    <citerefentry project='man-pages'><refentrytitle>ssh</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
+    <parameter>host</parameter> consists of an optional user name followed by the
+    <literal>@</literal> symbol, and the hostname, optionally followed by a
+    <literal>:</literal> and a port, optionally followed by a
+    <literal>/</literal> and a machine name. If the machine name is given, a connection
+    is created to the system bus in the specified container on the remote machine, and
+    otherwise a connection to the system bus on the specified host is created.</para>
+
+    <para>Note that entering a container is a privileged operation, and will likely only
+    work for the root user on the remote machine.</para>
+
+    <para><function>sd_bus_open_system_machine()</function> connects to the system bus in the specified
+    <parameter>machine</parameter>, where <parameter>machine</parameter> is the name of a local container,
+    possibly prefixed by a user name and a separating <literal>@</literal>. If the container name is
+    specified as the special string <literal>.host</literal> the connection is made to the local system. This
+    is useful to connect to the local system bus as specific user, e.g. <literal>foobar@.host</literal> to
+    connect to the local system bus as local user <literal>foobar</literal>. If the <literal>@</literal>
+    syntax is used either the left-hand side or the right-hand side may be omitted (but not both) in which
+    case the local user name or <literal>.host</literal> is implied. If the <literal>@</literal> syntax is
+    not used the connection is always made as root user. See
+    <citerefentry><refentrytitle>sd_bus_set_address</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    for a description of the address syntax, and
+    <citerefentry><refentrytitle>machinectl</refentrytitle><manvolnum>1</manvolnum></citerefentry> for more
+    information about the "machine" concept. Note that connections into local containers are only available
+    to privileged processes at this time.</para>
+
+    <para><function>sd_bus_open_user_machine()</function> is similar to
+    <function>sd_bus_open_system_machine()</function>, but connects to the user bus of the root user, or if
+    the <literal>@</literal> syntax is used, of the specified user.</para>
+
+    <para>These calls allocate a bus connection object and initiate
+    the connection to a well-known bus of some form. An alternative to
+    using these high-level calls is to create an unconnected bus
+    object with
+    <citerefentry><refentrytitle>sd_bus_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    and to connect it with
+    <citerefentry><refentrytitle>sd_bus_start</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+    </para>
+
+  </refsect1>
+
+  <refsect1>
+    <title>Reference ownership</title>
+    <para>The functions <function>sd_bus_open()</function>,
+    <function>sd_bus_open_user()</function>,
+    <function>sd_bus_open_user_machine()</function>,
+    <function>sd_bus_open_system()</function>,
+    <function>sd_bus_open_system_remote()</function>, and
+    <function>sd_bus_open_system_machine()</function> return a new
+    connection object and the caller owns the sole reference. When not
+    needed anymore, this reference should be destroyed with
+    <citerefentry><refentrytitle>sd_bus_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+    </para>
+
+    <para>The functions <function>sd_bus_default()</function>,
+    <function>sd_bus_default_user()</function> and
+    <function>sd_bus_default_system()</function> do not necessarily
+    create a new object, but increase the connection reference of an
+    existing connection object by one. Use
+    <citerefentry><refentrytitle>sd_bus_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    to drop the reference.</para>
+
+    <para>Queued but unwritten/unread messages keep a reference to their bus connection object. For this reason, even
+    if an application dropped all references to a bus connection, it might not get destroyed right away. Until all
+    incoming queued messages are read, and until all outgoing unwritten messages are written, the bus object will stay
+    alive. <function>sd_bus_flush()</function> may be used to write all outgoing queued messages so they drop their
+    references. To flush the unread incoming messages, use <function>sd_bus_close()</function>, which will also close
+    the bus connection. When using the default bus logic, it is a good idea to first invoke
+    <function>sd_bus_flush()</function> followed by <function>sd_bus_close()</function> when a thread or process
+    terminates, and thus its bus connection object should be freed.</para>
+
+    <para>Normally, slot objects (as created by
+    <citerefentry><refentrytitle>sd_bus_add_match</refentrytitle><manvolnum>3</manvolnum></citerefentry> and similar
+    calls) keep a reference to their bus connection object, too. Thus, as long as a bus slot object remains referenced
+    its bus object will remain allocated too. Optionally, bus slot objects may be placed in "floating" mode. When in
+    floating mode the life cycle of the bus slot object is bound to the bus object, i.e. when the bus object is freed
+    the bus slot object is automatically unreferenced too. The floating state of a slot object may be controlled
+    explicitly with
+    <citerefentry><refentrytitle>sd_bus_slot_set_floating</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    though usually floating bus slot objects are created by passing <constant>NULL</constant> as the
+    <parameter>slot</parameter> parameter of <function>sd_bus_add_match()</function> and related calls, thus indicating
+    that the caller is not directly interested in referencing and managing the bus slot object.</para>
+
+    <para>The life cycle of the default bus connection should be the
+    responsibility of the code that creates/owns the thread the
+    default bus connection object is associated with. Library code
+    should neither call <function>sd_bus_flush()</function> nor
+    <function>sd_bus_close()</function> on default bus objects unless
+    it does so in its own private, self-allocated thread. Library code
+    should not use the default bus object in other threads unless it
+    is clear that the program using it will life cycle the bus
+    connection object and flush and close it before exiting from the
+    thread. In libraries where it is not clear that the calling
+    program will life cycle the bus connection object, it is hence
+    recommended to use <function>sd_bus_open_system()</function>
+    instead of <function>sd_bus_default_system()</function> and
+    related calls.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, these calls return 0 or a positive
+    integer. On failure, these calls return a negative
+    errno-style error code.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>The specified parameters are invalid.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOMEDIUM</constant></term>
+
+          <listitem><para>The requested bus type is not available because of invalid environment (for example
+          the user session bus is not available because <varname>$XDG_RUNTIME_DIR</varname> is not set).
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v247"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOMEM</constant></term>
+
+          <listitem><para>Memory allocation failed.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ESOCKTNOSUPPORT</constant></term>
+
+          <listitem><para>The protocol version required to connect to the selected bus is not
+          supported.</para></listitem>
+        </varlistentry>
+      </variablelist>
+
+      <para>In addition, other connection-related errors may be returned. See
+      <citerefentry><refentrytitle>sd_bus_send</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_bus_default()</function>,
+    <function>sd_bus_default_user()</function>,
+    <function>sd_bus_default_system()</function>,
+    <function>sd_bus_open()</function>,
+    <function>sd_bus_open_user()</function>,
+    <function>sd_bus_open_system()</function>,
+    <function>sd_bus_open_system_remote()</function>, and
+    <function>sd_bus_open_system_machine()</function> were added in version 220.</para>
+    <para><function>sd_bus_open_with_description()</function>,
+    <function>sd_bus_open_user_with_description()</function>, and
+    <function>sd_bus_open_system_with_description()</function> were added in version 240.</para>
+    <para><function>sd_bus_open_user_machine()</function> was added in version 248.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_ref</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_close</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>ssh</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-machined.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>machinectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_bus_emit_signal.xml b/man/sd_bus_emit_signal.xml
new file mode 100644
index 0000000..7444e12
--- /dev/null
+++ b/man/sd_bus_emit_signal.xml
@@ -0,0 +1,298 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_bus_emit_signal"
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_bus_emit_signal</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_emit_signal</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_emit_signal</refname>
+    <refname>sd_bus_emit_signalv</refname>
+    <refname>sd_bus_emit_signal_to</refname>
+    <refname>sd_bus_emit_signal_tov</refname>
+    <refname>sd_bus_emit_interfaces_added</refname>
+    <refname>sd_bus_emit_interfaces_added_strv</refname>
+    <refname>sd_bus_emit_interfaces_removed</refname>
+    <refname>sd_bus_emit_interfaces_removed_strv</refname>
+    <refname>sd_bus_emit_properties_changed</refname>
+    <refname>sd_bus_emit_properties_changed_strv</refname>
+    <refname>sd_bus_emit_object_added</refname>
+    <refname>sd_bus_emit_object_removed</refname>
+
+    <refpurpose>Convenience functions for emitting (standard) D-Bus signals</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus-vtable.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_emit_signal</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>const char *<parameter>path</parameter></paramdef>
+        <paramdef>const char *<parameter>interface</parameter></paramdef>
+        <paramdef>const char *<parameter>member</parameter></paramdef>
+        <paramdef>const char *<parameter>types</parameter></paramdef>
+        <paramdef>...</paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_emit_signalv</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>const char *<parameter>path</parameter></paramdef>
+        <paramdef>const char *<parameter>interface</parameter></paramdef>
+        <paramdef>const char *<parameter>member</parameter></paramdef>
+        <paramdef>const char *<parameter>types</parameter></paramdef>
+        <paramdef>va_list <parameter>ap</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_emit_signal_to</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>const char *<parameter>destination</parameter></paramdef>
+        <paramdef>const char *<parameter>path</parameter></paramdef>
+        <paramdef>const char *<parameter>interface</parameter></paramdef>
+        <paramdef>const char *<parameter>member</parameter></paramdef>
+        <paramdef>const char *<parameter>types</parameter></paramdef>
+        <paramdef>...</paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_emit_signal_tov</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>const char *<parameter>destination</parameter></paramdef>
+        <paramdef>const char *<parameter>path</parameter></paramdef>
+        <paramdef>const char *<parameter>interface</parameter></paramdef>
+        <paramdef>const char *<parameter>member</parameter></paramdef>
+        <paramdef>const char *<parameter>types</parameter></paramdef>
+        <paramdef>va_list <parameter>ap</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_emit_interfaces_added</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>const char *<parameter>path</parameter></paramdef>
+        <paramdef>const char *<parameter>interface</parameter></paramdef>
+        <paramdef>...</paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_emit_interfaces_added_strv</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>const char *<parameter>path</parameter></paramdef>
+        <paramdef>const char **<parameter>interfaces</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_emit_interfaces_removed</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>const char *<parameter>path</parameter></paramdef>
+        <paramdef>const char *<parameter>interface</parameter></paramdef>
+        <paramdef>...</paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_emit_interfaces_removed_strv</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>const char *<parameter>path</parameter></paramdef>
+        <paramdef>const char **<parameter>interfaces</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_emit_properties_changed</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>const char *<parameter>path</parameter></paramdef>
+        <paramdef>const char *<parameter>interface</parameter></paramdef>
+        <paramdef>const char *<parameter>name</parameter></paramdef>
+        <paramdef>...</paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_emit_properties_changed_strv</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>const char *<parameter>path</parameter></paramdef>
+        <paramdef>const char *<parameter>interface</parameter></paramdef>
+        <paramdef>const char **<parameter>names</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_emit_object_added</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>const char *<parameter>path</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_emit_object_removed</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>const char *<parameter>path</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_bus_emit_signal()</function> is a convenience function for initializing a
+    bus message object and emitting the corresponding D-Bus signal. It combines the
+    <citerefentry><refentrytitle>sd_bus_message_new_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_bus_message_append</refentrytitle><manvolnum>3</manvolnum></citerefentry> and
+    <citerefentry><refentrytitle>sd_bus_send</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    functions into a single function call. <function>sd_bus_emit_signalv()</function> is
+    equivalent to <function>sd_bus_message_append()</function>, except that it is called with a
+    <literal>va_list</literal> instead of a variable number of arguments.</para>
+
+    <para><function>sd_bus_emit_signal_to()</function> and <function>sd_bus_emit_signal_tov()</function> are
+    identical to <function>sd_bus_emit_signal()</function> and <function>sd_bus_emit_signalv()</function>, except
+    that they can emit the signal to a single destination. Give <parameter>destination</parameter> as
+    <constant>NULL</constant> to broadcast the signal.</para>
+
+    <para><function>sd_bus_emit_interfaces_added()</function> and
+    <function>sd_bus_emit_interfaces_removed()</function> are used to implement the
+    <function>InterfacesAdded</function> and <function>InterfacesRemoved</function> signals of the
+    <constant>org.freedesktop.DBus.ObjectManager</constant> interface. They take a path whose
+    interfaces have been modified as an argument and a variable list of interfaces that have been
+    added or removed, respectively. The final argument passed to
+    <function>sd_bus_emit_interfaces_added()</function> and
+    <function>sd_bus_emit_interfaces_removed()</function> <emphasis>must</emphasis> be
+    <constant>NULL</constant>. This allows both functions to safely determine the number of passed
+    interface arguments. <function>sd_bus_emit_interfaces_added_strv()</function> and
+    <function>sd_bus_emit_interfaces_removed_strv()</function> are identical to their respective
+    counterparts but both take the list of interfaces as a single argument instead of a variable
+    number of arguments.</para>
+
+    <para><function>sd_bus_emit_properties_changed()</function> is used to implement the
+    <function>PropertiesChanged</function> signal of the
+    <constant>org.freedesktop.DBus.Properties</constant> interface. It takes an object path,
+    interface and a variable list of property names as its arguments.  The final argument passed to
+    <function>sd_bus_emit_properties_changed()</function> <emphasis>must</emphasis> be
+    <constant>NULL</constant>. This allows it to safely determine the number of passed property
+    names. <function>sd_bus_emit_properties_changed_strv()</function> is identical to
+    <function>sd_bus_emit_properties_changed()</function> but takes the list of property names as a
+    single argument instead of a variable number of arguments.</para>
+
+    <para><function>sd_bus_emit_object_added()</function> and
+    <function>sd_bus_emit_object_removed()</function> are convenience functions for emitting the
+    <function>InterfacesAdded</function> or <function>InterfacesRemoved</function> signals for all
+    interfaces registered on a specific object path, respectively. This includes any parent fallback
+    vtables if they are not overridden by a more applicable child vtable. It also includes all the
+    standard D-Bus interfaces implemented by sd-bus itself on any registered object.</para>
+
+    <para>Note that <function>sd_bus_emit_interfaces_added()</function>,
+    <function>sd_bus_emit_interfaces_removed()</function>,
+    <function>sd_bus_emit_object_added()</function> and
+    <function>sd_bus_emit_object_removed()</function> require an object manager to have been
+    registered on the given object path or one of its parent object paths using
+    <citerefentry><refentrytitle>sd_bus_add_object_manager</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+    </para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, these functions return a non-negative integer. On failure, they return a
+    negative errno-style error code.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>One of the required parameters is <constant>NULL</constant> or invalid. A
+          reserved D-Bus interface was passed as the <replaceable>interface</replaceable> parameter.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOPKG</constant></term>
+
+          <listitem><para>The bus cannot be resolved.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ECHILD</constant></term>
+
+          <listitem><para>The bus was created in a different process, library or module instance.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOMEM</constant></term>
+
+          <listitem><para>Memory allocation failed.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ESRCH</constant></term>
+
+          <listitem><para>One of <function>sd_bus_emit_interfaces_added()</function>,
+          <function>sd_bus_emit_interfaces_removed()</function>,
+          <function>sd_bus_emit_object_added()</function> or
+          <function>sd_bus_emit_object_removed()</function> was called on an object without an
+          object manager registered on its own object path or one of its parent object paths.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+      </variablelist>
+
+      <para>See the man pages of
+      <citerefentry><refentrytitle>sd_bus_message_new_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_message_append</refentrytitle><manvolnum>3</manvolnum></citerefentry> and
+      <citerefentry><refentrytitle>sd_bus_send</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+      for more possible errors.</para>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_bus_emit_signal()</function>,
+    <function>sd_bus_emit_signalv()</function>,
+    <function>sd_bus_emit_interfaces_added()</function>,
+    <function>sd_bus_emit_interfaces_added_strv()</function>,
+    <function>sd_bus_emit_interfaces_removed()</function>,
+    <function>sd_bus_emit_interfaces_removed_strv()</function>,
+    <function>sd_bus_emit_properties_changed()</function>,
+    <function>sd_bus_emit_properties_changed_strv()</function>,
+    <function>sd_bus_emit_object_added()</function>, and
+    <function>sd_bus_emit_object_removed()</function> were added in version 246.</para>
+    <para><function>sd_bus_emit_signal_to()</function> and
+    <function>sd_bus_emit_signal_tov()</function> were added in version 253.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>busctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_message_new_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_message_append</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_send</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_call_method</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+</refentry>
diff --git a/man/sd_bus_enqueue_for_read.xml b/man/sd_bus_enqueue_for_read.xml
new file mode 100644
index 0000000..dac32a0
--- /dev/null
+++ b/man/sd_bus_enqueue_for_read.xml
@@ -0,0 +1,95 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_bus_enqueue_for_read"
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_bus_enqueue_for_read</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_enqueue_for_read</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_enqueue_for_read</refname>
+
+    <refpurpose>Re-enqueue a bus message on a bus connection, for reading</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_enqueue_for_read</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>sd_bus_message *<parameter>message</parameter></paramdef>
+      </funcprototype>
+
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_bus_enqueue_for_read()</function> may be used to re-enqueue an incoming bus message on
+    the local read queue, so that it is processed and dispatched locally again, similarly to how an incoming
+    message from the peer is processed. Takes a bus connection object and the message to enqueue. A reference
+    is taken of the message and the caller's reference thus remains in possession of the caller. The message
+    is enqueued at the end of the queue, thus will be dispatched after all other already queued messages are
+    dispatched.</para>
+
+    <para>This call is primarily useful for dealing with incoming method calls that may be processed only
+    after an additional asynchronous operation completes. One example are PolicyKit authorization requests
+    that are determined to be necessary to authorize a newly incoming method call: when the PolicyKit response
+    is received the original method call may be re-enqueued to process it again, this time with the
+    authorization result known.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, this function return 0 or a positive integer. On failure, it returns a negative errno-style
+    error code.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-ECHILD</constant></term>
+
+          <listitem><para>The bus connection has been created in a different process, library or module instance.</para>
+
+          <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_bus_enqueue_for_read()</function> was added in version 245.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_send</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_bus_error-example.c b/man/sd_bus_error-example.c
new file mode 100644
index 0000000..9b162eb
--- /dev/null
+++ b/man/sd_bus_error-example.c
@@ -0,0 +1,18 @@
+/* SPDX-License-Identifier: MIT-0 */
+
+#include <errno.h>
+#include <string.h>
+#include <unistd.h>
+#include <sd-bus.h>
+
+int writer_with_negative_errno_return(int fd, sd_bus_error *error) {
+  const char *message = "Hello, World!\n";
+
+  ssize_t n = write(fd, message, strlen(message));
+  if (n >= 0)
+    return n; /* On success, return the number of bytes written, possibly 0. */
+
+  /* On error, initialize the error structure, and also propagate the errno
+   * value that write(2) set for us. */
+  return sd_bus_error_set_errnof(error, errno, "Failed to write to fd %i: %m", fd);
+}
diff --git a/man/sd_bus_error.xml b/man/sd_bus_error.xml
new file mode 100644
index 0000000..3f7a28c
--- /dev/null
+++ b/man/sd_bus_error.xml
@@ -0,0 +1,426 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_bus_error" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_bus_error</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_error</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_error</refname>
+    <refname>SD_BUS_ERROR_MAKE_CONST</refname>
+    <refname>SD_BUS_ERROR_NULL</refname>
+    <refname>sd_bus_error_free</refname>
+    <refname>sd_bus_error_set</refname>
+    <refname>sd_bus_error_setf</refname>
+    <refname>sd_bus_error_setfv</refname>
+    <refname>sd_bus_error_set_const</refname>
+    <refname>sd_bus_error_set_errno</refname>
+    <refname>sd_bus_error_set_errnof</refname>
+    <refname>sd_bus_error_set_errnofv</refname>
+    <refname>sd_bus_error_get_errno</refname>
+    <refname>sd_bus_error_copy</refname>
+    <refname>sd_bus_error_move</refname>
+    <refname>sd_bus_error_is_set</refname>
+    <refname>sd_bus_error_has_name</refname>
+    <refname>sd_bus_error_has_names_sentinel</refname>
+    <refname>sd_bus_error_has_names</refname>
+
+    <refpurpose>sd-bus error handling</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <funcsynopsisinfo>typedef struct {
+        const char *name;
+        const char *message;
+        …
+} sd_bus_error;</funcsynopsisinfo>
+
+      <para>
+        <constant>SD_BUS_ERROR_MAKE_CONST(<replaceable>name</replaceable>, <replaceable>message</replaceable>)</constant>
+      </para>
+      <para>
+        <constant>SD_BUS_ERROR_NULL</constant>
+      </para>
+
+      <funcprototype>
+        <funcdef>void <function>sd_bus_error_free</function></funcdef>
+        <paramdef>sd_bus_error *<parameter>e</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_error_set</function></funcdef>
+        <paramdef>sd_bus_error *<parameter>e</parameter></paramdef>
+        <paramdef>const char *<parameter>name</parameter></paramdef>
+        <paramdef>const char *<parameter>message</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_error_setf</function></funcdef>
+        <paramdef>sd_bus_error *<parameter>e</parameter></paramdef>
+        <paramdef>const char *<parameter>name</parameter></paramdef>
+        <paramdef>const char *<parameter>format</parameter></paramdef>
+        <paramdef>…</paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_error_setfv</function></funcdef>
+        <paramdef>sd_bus_error *<parameter>e</parameter></paramdef>
+        <paramdef>const char *<parameter>name</parameter></paramdef>
+        <paramdef>const char *<parameter>format</parameter></paramdef>
+        <paramdef>va_list <parameter>ap</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_error_set_const</function></funcdef>
+        <paramdef>sd_bus_error *<parameter>e</parameter></paramdef>
+        <paramdef>const char *<parameter>name</parameter></paramdef>
+        <paramdef>const char *<parameter>message</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_error_set_errno</function></funcdef>
+        <paramdef>sd_bus_error *<parameter>e</parameter></paramdef>
+        <paramdef>int <parameter>error</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_error_set_errnof</function></funcdef>
+        <paramdef>sd_bus_error *<parameter>e</parameter></paramdef>
+        <paramdef>int <parameter>error</parameter></paramdef>
+        <paramdef>const char *<parameter>format</parameter></paramdef>
+        <paramdef>…</paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_error_set_errnofv</function></funcdef>
+        <paramdef>sd_bus_error *<parameter>e</parameter></paramdef>
+        <paramdef>int <parameter>error</parameter></paramdef>
+        <paramdef>const char *<parameter>format</parameter></paramdef>
+        <paramdef>va_list <parameter>ap</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_error_get_errno</function></funcdef>
+        <paramdef>const sd_bus_error *<parameter>e</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_error_copy</function></funcdef>
+        <paramdef>sd_bus_error *<parameter>dst</parameter></paramdef>
+        <paramdef>const sd_bus_error *<parameter>e</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_error_move</function></funcdef>
+        <paramdef>sd_bus_error *<parameter>dst</parameter></paramdef>
+        <paramdef>sd_bus_error *<parameter>e</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_error_is_set</function></funcdef>
+        <paramdef>const sd_bus_error *<parameter>e</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_error_has_name</function></funcdef>
+        <paramdef>const sd_bus_error *<parameter>e</parameter></paramdef>
+        <paramdef>const char *<parameter>name</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_error_has_names_sentinel</function></funcdef>
+        <paramdef>const sd_bus_error *<parameter>e</parameter></paramdef>
+        <paramdef>...</paramdef>
+      </funcprototype>
+
+      <para>
+        &#35;define sd_bus_error_has_names(e, ...) sd_bus_error_has_names_sentinel(e, ..., NULL)
+      </para>
+    </funcsynopsis>
+
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>The <structname>sd_bus_error</structname> structure carries information about a D-Bus error
+    condition, or lack thereof. The functions described below may be used to set and query fields in this
+    structure.
+    <itemizedlist>
+      <listitem><para>The <structfield>name</structfield> field contains a short identifier of an error. It
+      should follow the rules for error names described in the D-Bus specification, subsection <ulink
+      url="https://dbus.freedesktop.org/doc/dbus-specification.html#message-protocol-names">Valid
+      D-Bus Names</ulink>. A number of common, standardized error names are described in
+      <citerefentry><refentrytitle>sd-bus-errors</refentrytitle><manvolnum>3</manvolnum></citerefentry>, but
+      additional domain-specific errors may be defined by applications.</para></listitem>
+
+      <listitem><para>The <structfield>message</structfield> field usually contains a human-readable string
+      describing the details, but might be <constant>NULL</constant>.</para></listitem>
+    </itemizedlist>
+    An unset <structname>sd_bus_error</structname> structure should have both fields initialized to
+    <constant>NULL</constant>, and signifies lack of an error, i.e. success. Assign
+    <constant>SD_BUS_ERROR_NULL</constant> to the structure in order to initialize both fields to
+    <constant>NULL</constant>. When no longer necessary, resources held by the
+    <structname>sd_bus_error</structname> structure should be destroyed with
+    <function>sd_bus_error_free()</function>.</para>
+
+    <para><function>sd_bus_error_set()</function> sets an error structure to the specified name and message
+    strings. The strings will be copied into internal, newly allocated memory. It is essential to free the
+    contents again when they are not required anymore (see above). Do not use this call on error structures
+    that have already been set. If you intend to reuse an error structure, free the old data stored in it
+    with <function>sd_bus_error_free()</function> first.</para>
+
+    <para><function>sd_bus_error_set()</function> will return an <varname>errno</varname>-like value (see
+    <citerefentry
+    project='man-pages'><refentrytitle>errno</refentrytitle><manvolnum>3</manvolnum></citerefentry>)
+    determined from the specified error name <parameter>name</parameter>. If <parameter>name</parameter> is
+    <constant>NULL</constant>, it is assumed that no error occurred, and <constant>0</constant> is returned.
+    If <parameter>name</parameter> is nonnull, a negative value is always returned. If
+    <parameter>e</parameter> is <constant>NULL</constant>, no error structure is initialized, but
+    <parameter>name</parameter> is still converted into an <varname>errno</varname>-style value.</para>
+
+    <para>Various well-known D-Bus errors are converted to well-known <varname>errno</varname> counterparts,
+    and the other ones to <constant>-EIO</constant>. See
+    <citerefentry><refentrytitle>sd-bus-errors</refentrytitle><manvolnum>3</manvolnum></citerefentry> for a
+    list of well-known error names. Additional error mappings may be defined with
+    <citerefentry><refentrytitle>sd_bus_error_add_map</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+    </para>
+
+    <para><function>sd_bus_error_set()</function> is designed to be conveniently used in a
+    <function>return</function> statement. If <parameter>message</parameter> is <constant>NULL</constant>, no
+    message is set. This call can fail if no memory may be allocated for the name and message strings, in
+    which case an <constant>SD_BUS_ERROR_NO_MEMORY</constant> error will be set instead and
+    <constant>-ENOMEM</constant> returned. </para>
+
+    <para><function>sd_bus_error_setf()</function> and <function>sd_bus_error_setfv()</function> are similar
+    to <function>sd_bus_error_set()</function>, but take a <citerefentry
+    project='man-pages'><refentrytitle>printf</refentrytitle><manvolnum>3</manvolnum></citerefentry> format
+    string and corresponding arguments to generate the <structfield>message</structfield> field.
+    <function>sd_bus_error_setf()</function> uses variadic arguments, and
+    <function>sd_bus_error_setfv()</function> accepts the arguments as a
+    <citerefentry
+    project='man-pages'><refentrytitle>va_arg</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    parameter list.</para>
+
+    <para><function>sd_bus_error_set_const()</function> is similar to
+    <function>sd_bus_error_set()</function>, but the string parameters are not copied internally, and must
+    hence remain constant and valid for the lifetime of <parameter>e</parameter>. Use this call to avoid
+    memory allocations when setting error structures. Since this call does not allocate memory, it will not
+    fail with an out-of-memory condition as <function>sd_bus_error_set()</function> may, as described
+    above. Alternatively, the <constant>SD_BUS_ERROR_MAKE_CONST()</constant> macro may be used to generate a
+    literal, constant bus error structure on-the-fly.</para>
+
+    <para><function>sd_bus_error_set_errno()</function> will immediately return <constant>0</constant> if the
+    specified error parameter <parameter>error</parameter> is <constant>0</constant>. Otherwise, it will set
+    <structfield>name</structfield> from an <varname>errno</varname>-like value that is converted to a D-Bus
+    error. <citerefentry
+    project='die-net'><refentrytitle>strerror_r</refentrytitle><manvolnum>3</manvolnum></citerefentry> will
+    be used to set <structfield>message</structfield>. Well-known D-Bus error names will be used for
+    <structfield>name</structfield> if applicable, otherwise a name in the <literal>System.Error.</literal>
+    namespace will be generated. The sign of the specified error number is ignored and the absolute value is
+    used implicitly. If the specified error <parameter>error</parameter> is non-zero, the call always returns
+    a negative value, for convenient usage in <function>return</function> statements. This call might fail
+    due to lack of memory, in which case an <constant>SD_BUS_ERROR_NO_MEMORY</constant> error is set instead,
+    and <constant>-ENOMEM</constant> is returned.</para>
+
+    <para><function>sd_bus_error_set_errnof()</function> and <function>sd_bus_error_set_errnof()</function>
+    are similar to <function>sd_bus_error_set_errno()</function>, but in addition to
+    <parameter>error</parameter>, take a <citerefentry
+    project='man-pages'><refentrytitle>printf</refentrytitle><manvolnum>3</manvolnum></citerefentry> format
+    string and corresponding arguments. The <structfield>message</structfield> field will be generated from
+    <parameter>format</parameter> and the arguments.
+    <function>sd_bus_error_set_errnof()</function> uses variadic arguments, and
+    <function>sd_bus_error_set_errnofv()</function> accepts the arguments as a
+    <citerefentry
+    project='man-pages'><refentrytitle>va_arg</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    parameter list.</para>
+
+    <para><function>sd_bus_error_get_errno()</function> converts the <structfield>name</structfield> field of
+    an error structure to an <varname>errno</varname>-like (positive) value using the same rules as
+    <function>sd_bus_error_set()</function>.  If <parameter>e</parameter> is <constant>NULL</constant>,
+    <constant>0</constant> will be returned.</para>
+
+    <para><function>sd_bus_error_copy()</function> will initialize <parameter>dst</parameter> using the
+    values in <parameter>e</parameter>, if <parameter>e</parameter> has been set with an error value before.
+    Otherwise, it will return immediately. If the strings in <parameter>e</parameter> were set using
+    <function>sd_bus_error_set_const()</function>, they will be shared. Otherwise, they will be
+    copied. Before this call, <parameter>dst</parameter> must be unset, i.e. either freshly initialized with
+    <constant>NULL</constant> or reset using <function>sd_bus_error_free()</function>.</para>
+
+    <para><function>sd_bus_error_copy()</function> generally returns <constant>0</constant> or a negative
+    <varname>errno</varname>-like value based on the input parameter <parameter>e</parameter>:
+    <constant>0</constant> if it was unset and a negative integer if it was set to some error, similarly to
+    <function>sd_bus_error_set()</function>. It may however also return an error generated internally, for
+    example <constant>-ENOMEM</constant> if a memory allocation fails.</para>
+
+    <para><function>sd_bus_error_move()</function> is similar to <function>sd_bus_error_copy()</function>,
+    but will move any error information from <parameter>e</parameter> into <parameter>dst</parameter>,
+    resetting the former. This function cannot fail, as no new memory is allocated. Note that if
+    <parameter>e</parameter> is not set, <parameter>dst</parameter> is initialized to
+    <constant>SD_BUS_ERROR_NULL</constant>. Moreover, if <parameter>dst</parameter> is
+    <constant>NULL</constant> no operation is executed on it and resources held by <parameter>e</parameter>
+    are freed and reset. Returns a converted <varname>errno</varname>-like, non-positive error value.</para>
+
+    <para><function>sd_bus_error_is_set()</function> will return a
+    non-zero value if <parameter>e</parameter> is
+    non-<constant>NULL</constant> and an error has been set,
+    <constant>false</constant> otherwise.</para>
+
+    <para><function>sd_bus_error_has_name()</function> will return a
+    non-zero value if <parameter>e</parameter> is
+    non-<constant>NULL</constant> and an error with the same
+    <parameter>name</parameter> has been set,
+    <constant>false</constant> otherwise.</para>
+
+    <para><function>sd_bus_error_has_names_sentinel()</function> is similar to
+    <function>sd_bus_error_has_name()</function>, but takes multiple names to check against. The list must be
+    terminated with <constant>NULL</constant>. <function>sd_bus_error_has_names()</function>
+    is a macro wrapper around <function>sd_bus_error_has_names_sentinel()</function> that adds the
+    <constant>NULL</constant> sentinel automatically.</para>
+
+    <para><function>sd_bus_error_free()</function> will destroy
+    resources held by <parameter>e</parameter>. The parameter itself
+    will not be deallocated, and must be <citerefentry
+    project='man-pages'><refentrytitle>free</refentrytitle><manvolnum>3</manvolnum></citerefentry>d
+    by the caller if necessary. The function may also be called safely
+    on unset errors (error structures with both fields set to <constant>NULL</constant>),
+    in which case it performs no operation. This call will reset the
+    error structure after freeing the data, so that all fields are set
+    to <constant>NULL</constant>. The structure may be reused afterwards.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Reference ownership</title>
+
+    <para><structname>sd_bus_error</structname> is not reference-counted. Users should destroy resources held
+    by it by calling <function>sd_bus_error_free()</function>. Usually, error structures are allocated on the
+    stack or passed in as function parameters, but they may also be allocated dynamically, in which case it
+    is the duty of the caller to <citerefentry
+    project='man-pages'><refentrytitle>free</refentrytitle><manvolnum>3</manvolnum></citerefentry> the memory
+    held by the structure itself after freeing its contents with
+    <function>sd_bus_error_free()</function>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>The functions <function>sd_bus_error_set()</function>, <function>sd_bus_error_setf()</function>,
+    and <function>sd_bus_error_set_const()</function> always return <constant>0</constant> when the specified
+    error value is <constant>NULL</constant>, and a negative errno-like value corresponding to the
+    <parameter>name</parameter> parameter otherwise. The functions
+    <function>sd_bus_error_set_errno()</function>, <function>sd_bus_error_set_errnof()</function> and
+    <function>sd_bus_error_set_errnofv()</function>, return <constant>0</constant> when the specified error
+    value is <constant>0</constant>, and a negative errno-like value corresponding to the
+    <parameter>error</parameter> parameter otherwise. If an error occurs internally, one of the negative
+    error values listed below will be returned. This allows those functions to be conveniently used in a
+    <constant>return</constant> statement, see the example below.</para>
+
+    <para><function>sd_bus_error_get_errno()</function> returns
+    <constant>false</constant> when <parameter>e</parameter> is
+    <constant>NULL</constant>, and a positive errno value mapped from
+    <parameter>e-&gt;name</parameter> otherwise.</para>
+
+    <para><function>sd_bus_error_copy()</function> and <function>sd_bus_error_move()</function> return a
+    negative error value converted from the source error, and zero if the error has not been set.  This
+    allows those functions to be conveniently used in a <constant>return</constant> statement, see the
+    example below.</para>
+
+    <para><function>sd_bus_error_is_set()</function> returns a
+    non-zero value when <parameter>e</parameter> and the
+    <structfield>name</structfield> field are
+    non-<constant>NULL</constant>, zero otherwise.</para>
+
+    <para><function>sd_bus_error_has_name()</function>, <function>sd_bus_error_has_names()</function>, and
+    <function>sd_bus_error_has_names_sentinel()</function> return a non-zero value when <parameter>e</parameter> is
+    non-<constant>NULL</constant> and the <structfield>name</structfield> field is equal to one of the given
+    names, zero otherwise.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Return value may indicate the following problems in the invocation of the function itself:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>Error was already set in the <structname>sd_bus_error</structname> structure when
+          one the error-setting functions was called.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOMEM</constant></term>
+
+          <listitem><para>Memory allocation failed.</para></listitem>
+        </varlistentry>
+      </variablelist>
+
+      <para>On success, <function>sd_bus_error_set()</function>, <function>sd_bus_error_setf()</function>,
+      <function>sd_bus_error_set_const()</function>, <function>sd_bus_error_set_errno()</function>,
+      <function>sd_bus_error_set_errnof()</function>, <function>sd_bus_error_set_errnofv()</function>,
+      <function>sd_bus_error_copy()</function>, and <function>sd_bus_error_move()</function> will return a
+      negative converted <varname>errno</varname>-style value, or <constant>0</constant> if the error
+      parameter is <constant>NULL</constant> or unset. D-Bus errors are converted to the integral
+      <varname>errno</varname>-style value, and the mapping mechanism is extensible, see the discussion
+      above. This effectively means that almost any negative <varname>errno</varname>-style value can be
+      returned.</para>
+    </refsect2>
+  </refsect1>
+
+  <refsect1>
+    <title>Examples</title>
+
+    <example>
+      <title>Using the negative return value to propagate an error</title>
+
+      <programlisting><xi:include href="sd_bus_error-example.c" parse="text" /></programlisting>
+    </example>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_bus_error_free()</function>,
+    <function>sd_bus_error_set()</function>,
+    <function>sd_bus_error_setf()</function>,
+    <function>sd_bus_error_set_const()</function>,
+    <function>sd_bus_error_set_errno()</function>,
+    <function>sd_bus_error_set_errnof()</function>,
+    <function>sd_bus_error_get_errno()</function>,
+    <function>sd_bus_error_copy()</function>,
+    <function>sd_bus_error_is_set()</function>, and
+    <function>sd_bus_error_has_name()</function> were added in version 209.</para>
+    <para><function>sd_bus_error_set_errnofv()</function> was added in version 223.</para>
+    <para><function>sd_bus_error_move()</function> was added in version 240.</para>
+    <para><function>sd_bus_error_has_names_sentinel()</function> was added in version 247.</para>
+    <para><function>sd_bus_error_setfv()</function> was added in version 252.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus-errors</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_error_add_map</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>errno</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>strerror_r</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_bus_error_add_map.xml b/man/sd_bus_error_add_map.xml
new file mode 100644
index 0000000..6676455
--- /dev/null
+++ b/man/sd_bus_error_add_map.xml
@@ -0,0 +1,139 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_bus_error_add_map"
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_bus_error_add_map</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_error_add_map</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_error_add_map</refname>
+    <refname>sd_bus_error_map</refname>
+    <refname>SD_BUS_ERROR_MAP</refname>
+    <refname>SD_BUS_ERROR_END</refname>
+
+    <refpurpose>Additional sd-dbus error mappings</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <funcsynopsisinfo>typedef struct {
+        const char *name;
+        int code;
+        …
+} sd_bus_error_map;</funcsynopsisinfo>
+
+      <funcsynopsisinfo><constant>SD_BUS_ERROR_MAP(<replaceable>name</replaceable>, <replaceable>code</replaceable>)</constant></funcsynopsisinfo>
+
+      <funcsynopsisinfo><constant>SD_BUS_ERROR_MAP_END</constant></funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_error_add_map</function></funcdef>
+        <paramdef>const sd_bus_error_map *<parameter>map</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>The <function>sd_bus_error_add_map()</function> call may be
+    used to register additional mappings for converting D-Bus errors
+    to Linux <varname>errno</varname>-style errors. The mappings
+    defined with this call are consulted by calls such as
+    <citerefentry><refentrytitle>sd_bus_error_set</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    or
+    <citerefentry><refentrytitle>sd_bus_error_get_errno</refentrytitle><manvolnum>3</manvolnum></citerefentry>. By
+    default, a number of generic, standardized mappings are known, as
+    documented in
+    <citerefentry><refentrytitle>sd-bus-errors</refentrytitle><manvolnum>3</manvolnum></citerefentry>. Use
+    this call to add further, application-specific mappings.</para>
+
+    <para>The function takes a pointer to an array of
+    <structname>sd_bus_error_map</structname> structures. A reference
+    to the specified array is added to the lookup tables for error
+    mappings. Note that the structure is not copied, and that it is hence
+    essential that the array stays available and constant during the
+    entire remaining runtime of the process.</para>
+
+    <para>The mapping array should be put together with a series of
+    <constant>SD_BUS_ERROR_MAP()</constant> macro invocations that
+    take a literal name string and a (positive)
+    <varname>errno</varname>-style error number. The last entry of the
+    array should be an invocation of the
+    <constant>SD_BUS_ERROR_MAP_END</constant> macro. The array should not be
+    put together without use of these two macros.</para>
+
+    <para>Note that the call is idempotent: it is safe to invoke it
+    multiple times with the parameter, which will only add the passed
+    mapping array once.</para>
+
+    <para>Note that the memory allocated by this call is not intended
+    to be freed during the lifetime of the process. It should not be
+    freed explicitly.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para><function>sd_bus_error_add_map()</function> returns a
+    positive value when the new array was added to the lookup
+    tables. It returns zero when the same array was already added
+    before. On error, a negative <varname>errno</varname>-style error
+    code is returned. See below for known error codes.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>The specified mapping array is invalid.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOMEM</constant></term>
+
+          <listitem><para>Memory allocation failed.</para></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_bus_error_add_map()</function> was added in version 223.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_error</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus-errors</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>errno</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>strerror_r</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_bus_get_current_handler.xml b/man/sd_bus_get_current_handler.xml
new file mode 100644
index 0000000..a1eefc1
--- /dev/null
+++ b/man/sd_bus_get_current_handler.xml
@@ -0,0 +1,94 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_bus_get_current_handler" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_bus_get_current_handler</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_get_current_handler</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_get_current_handler</refname>
+    <refname>sd_bus_get_current_message</refname>
+    <refname>sd_bus_get_current_slot</refname>
+    <refname>sd_bus_get_current_userdata</refname>
+
+    <refpurpose>Query information of the callback a bus object is currently running</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <xi:include href="sd_bus_add_match.xml" xpointer="sd_bus_message_handler_t"/>
+
+      <funcprototype>
+        <funcdef>sd_bus_message_handler_t <function>sd_bus_get_current_handler</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>sd_bus_message* <function>sd_bus_get_current_message</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>sd_bus_slot* <function>sd_bus_get_current_slot</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>void* <function>sd_bus_get_current_userdata</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>Whenever sd-bus is about to invoke a user-supplied callback function, it stores the
+    current callback, D-Bus message, slot and userdata pointer and allows these to be queried via
+    <function>sd_bus_get_current_handler()</function>,
+    <function>sd_bus_get_current_message()</function>,
+    <function>sd_bus_get_current_slot()</function> and
+    <function>sd_bus_get_current_userdata()</function>, respectively. If <parameter>bus</parameter>
+    cannot be resolved or if execution does not reside in a user-supplied callback of
+    <parameter>bus</parameter>, these functions return <constant>NULL</constant>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, these functions return the requested object. On failure, they return
+    <constant>NULL</constant>.</para>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_bus_get_current_handler()</function>,
+    <function>sd_bus_get_current_message()</function>,
+    <function>sd_bus_get_current_slot()</function>, and
+    <function>sd_bus_get_current_userdata()</function> were added in version 246.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_bus_get_fd.xml b/man/sd_bus_get_fd.xml
new file mode 100644
index 0000000..5931527
--- /dev/null
+++ b/man/sd_bus_get_fd.xml
@@ -0,0 +1,184 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+
+<!--
+  SPDX-License-Identifier: LGPL-2.1-or-later
+
+  Copyright © 2016 Julian Orth
+-->
+
+<refentry id="sd_bus_get_fd" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_bus_get_fd</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_get_fd</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_get_fd</refname>
+    <refname>sd_bus_get_events</refname>
+    <refname>sd_bus_get_timeout</refname>
+
+    <refpurpose>Get the file descriptor, I/O events and timeout to wait for from a message bus
+    object</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_get_fd</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_get_events</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_get_timeout</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>uint64_t *<parameter>timeout_usec</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_bus_get_fd()</function> returns the file descriptor used to communicate from
+    a message bus object. This descriptor can be used with
+    <citerefentry project='man-pages'><refentrytitle>poll</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    or a similar function to wait for I/O events on the specified bus connection object. If the bus
+    object was configured with the <function>sd_bus_set_fd()</function> function, then the
+    <parameter>input_fd</parameter> file descriptor used in that call is returned.</para>
+
+    <para><function>sd_bus_get_events()</function> returns the I/O events to wait for, suitable for
+    passing to <function>poll()</function> or a similar call. Returns a combination of
+    <constant>POLLIN</constant>, <constant>POLLOUT</constant>, … events, or negative on error.
+    </para>
+
+    <para><function>sd_bus_get_timeout()</function> returns the <emphasis>absolute</emphasis> time-out in μs,
+    from which the relative time-out to pass to <function>poll()</function> (or a similar call) can be
+    derived, when waiting for events on the specified bus connection. The returned timeout may be zero, in
+    which case a subsequent I/O polling call should be invoked in non-blocking mode. The returned timeout may
+    be <constant>UINT64_MAX</constant> in which case the I/O polling call may block indefinitely, without any
+    applied timeout. Note that the returned timeout should be considered only a maximum sleeping time. It is
+    permissible (and even expected) that shorter timeouts are used by the calling program, in case other
+    event sources are polled in the same event loop. Note that the returned time-value is absolute, based of
+    <constant>CLOCK_MONOTONIC</constant> and specified in microseconds. When converting this value in order
+    to pass it as third argument to <function>poll()</function> (which expects relative milliseconds), care
+    should be taken to convert to a relative time and use a division that rounds up to ensure the I/O polling
+    operation doesn't sleep for shorter than necessary, which might result in unintended busy looping
+    (alternatively, use <citerefentry
+    project='man-pages'><refentrytitle>ppoll</refentrytitle><manvolnum>2</manvolnum></citerefentry> instead
+    of plain <function>poll()</function>, which understands timeouts with nano-second granularity).</para>
+
+    <para>These three functions are useful to hook up a bus connection object with an external or
+    manual event loop involving <function>poll()</function> or a similar I/O polling call. Before
+    each invocation of the I/O polling call, all three functions should be invoked: the file
+    descriptor returned by <function>sd_bus_get_fd()</function> should be polled for the events
+    indicated by <function>sd_bus_get_events()</function>, and the I/O call should block for that up
+    to the timeout returned by <function>sd_bus_get_timeout()</function>. After each I/O polling
+    call the bus connection needs to process incoming or outgoing data, by invoking
+    <citerefentry><refentrytitle>sd_bus_process</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+    </para>
+
+    <para>Note that these functions are only one of three supported ways to implement I/O event
+    handling for bus connections. Alternatively use
+    <citerefentry><refentrytitle>sd_bus_attach_event</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    to attach a bus connection to an
+    <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    event loop. Or use
+    <citerefentry><refentrytitle>sd_bus_wait</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    as a simple synchronous, blocking I/O waiting call.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, <function>sd_bus_get_fd()</function> returns the file descriptor used for
+    communication. On failure, it returns a negative errno-style error code.</para>
+
+    <para>On success, <function>sd_bus_get_events()</function> returns the I/O event mask to use for
+    I/O event watching. On failure, it returns a negative errno-style error code.</para>
+
+    <para>On success, <function>sd_bus_get_timeout()</function> returns a non-negative integer. On
+    failure, it returns a negative errno-style error code.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>An invalid bus object was passed.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ECHILD</constant></term>
+
+          <listitem><para>The bus connection was allocated in a parent process and is being reused
+          in a child process after <function>fork()</function>.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOTCONN</constant></term>
+
+          <listitem><para>The bus connection has been terminated.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EPERM</constant></term>
+
+          <listitem><para>Two distinct file descriptors were passed for input and output using
+          <function>sd_bus_set_fd()</function>, which <function>sd_bus_get_fd()</function> cannot
+          return.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOPKG</constant></term>
+
+          <listitem><para>The bus cannot be resolved.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_bus_get_fd()</function> was added in version 231.</para>
+    <para><function>sd_bus_get_events()</function> and
+    <function>sd_bus_get_timeout()</function> were added in version 240.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_process</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_attach_event</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_wait</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_set_fd</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>poll</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_bus_get_n_queued_read.xml b/man/sd_bus_get_n_queued_read.xml
new file mode 100644
index 0000000..e37b54c
--- /dev/null
+++ b/man/sd_bus_get_n_queued_read.xml
@@ -0,0 +1,106 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_bus_get_n_queued_read">
+
+  <refentryinfo>
+    <title>sd_bus_get_fd</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_get_n_queued_read</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_get_n_queued_read</refname>
+    <refname>sd_bus_get_n_queued_write</refname>
+
+    <refpurpose>Get the number of pending bus messages in the read and write queues of a bus connection object</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_get_n_queued_read</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>uint64_t *<parameter>ret</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_get_n_queued_write</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>uint64_t *<parameter>ret</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>
+      <function>sd_bus_get_n_queued_read()</function> may be used to query the number of bus messages in the read queue
+      of a bus connection object. The read queue contains all messages read from the transport medium (e.g. network
+      socket) but not yet processed locally. The function expects two arguments: the bus object to query, and a pointer
+      to a 64-bit counter variable to write the current queue size to. Use <function>sd_bus_process()</function> in
+      order to process queued messages, i.e. to reduce the size of the read queue (as well as, in fact, the write
+      queue, see below).
+    </para>
+
+    <para>
+      Similarly, <function>sd_bus_get_n_queued_write()</function> may be used to query the number of currently pending
+      bus messages in the write queue of a bus connection object. The write queue contains all messages enqueued into
+      the connection with a call such as <function>sd_bus_send()</function> but not yet written to the transport
+      medium. The expected arguments are similar to <function>sd_bus_get_n_queued_read()</function>. Here too, use
+      <function>sd_bus_process()</function> to reduce the size of the write queue. Alternatively, use
+      <function>sd_bus_flush()</function> to synchronously write out any pending bus messages until the write queue is
+      empty.
+    </para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, these functions return 0 or a positive integer. On failure, they return a negative errno-style
+    error code.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-ECHILD</constant></term>
+
+          <listitem><para>The bus connection was created in a different process, library or module instance.</para></listitem>
+        </varlistentry>
+
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_bus_get_n_queued_read()</function> and
+    <function>sd_bus_get_n_queued_write()</function> were added in version 238.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_process</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_send</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_flush</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_bus_get_name_creds.xml b/man/sd_bus_get_name_creds.xml
new file mode 100644
index 0000000..d7531af
--- /dev/null
+++ b/man/sd_bus_get_name_creds.xml
@@ -0,0 +1,137 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_bus_get_name_creds" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_bus_get_name_creds</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_get_name_creds</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_get_name_creds</refname>
+    <refname>sd_bus_get_owner_creds</refname>
+
+    <refpurpose>Query bus client credentials</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_get_name_creds</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>const char *<parameter>name</parameter></paramdef>
+        <paramdef>uint64_t <parameter>mask</parameter></paramdef>
+        <paramdef>sd_bus_creds **<parameter>creds</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_get_owner_creds</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>uint64_t <parameter>mask</parameter></paramdef>
+        <paramdef>sd_bus_creds **<parameter>creds</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_bus_get_name_creds()</function> queries the credentials of the bus client
+    identified by <parameter>name</parameter>. The <parameter>mask</parameter> parameter is a combo of
+    <constant index='false'>SD_BUS_CREDS_*</constant> flags that indicate which credential info the caller is
+    interested in. See
+    <citerefentry><refentrytitle>sd_bus_creds_new_from_pid</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    for a list of possible flags. On success, <parameter>creds</parameter> contains a new
+    <structname>sd_bus_creds</structname> instance with the requested information. Ownership of this instance
+    belongs to the caller and it should be freed once no longer needed by calling
+    <citerefentry><refentrytitle>sd_bus_creds_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+    </para>
+
+    <para><function>sd_bus_get_owner_creds()</function> queries the credentials of the creator of the given
+    bus. The <parameter>mask</parameter> and <parameter>creds</parameter> parameters behave the same as in
+    <function>sd_bus_get_name_creds()</function>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, these functions return a non-negative integer. On failure, they return a negative
+    errno-style error code.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>An argument is invalid.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOPKG</constant></term>
+
+          <listitem><para>The bus cannot be resolved.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EPERM</constant></term>
+
+          <listitem><para>The bus has already been started.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ECHILD</constant></term>
+
+          <listitem><para>The bus was created in a different process, library or module instance.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOMEM</constant></term>
+
+          <listitem><para>Memory allocation failed.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_bus_get_name_creds()</function> and
+    <function>sd_bus_get_owner_creds()</function> were added in version 246.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_creds_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+</refentry>
diff --git a/man/sd_bus_get_name_machine_id.xml b/man/sd_bus_get_name_machine_id.xml
new file mode 100644
index 0000000..64019c9
--- /dev/null
+++ b/man/sd_bus_get_name_machine_id.xml
@@ -0,0 +1,111 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_bus_get_name_machine_id" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_bus_get_name_machine_id</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_get_name_machine_id</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_get_name_machine_id</refname>
+
+    <refpurpose>Retrieve a bus client's machine identity</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_get_name_machine_id</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>const char *<parameter>name</parameter></paramdef>
+        <paramdef>sd_id128_t *<parameter>machine</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_bus_get_name_machine_id()</function> retrieves the D-Bus machine identity of the
+    machine that the bus client identified by <parameter>name</parameter> is running on. Internally, it calls
+    the <function>GetMachineId</function> method of the <constant>org.freedesktop.DBus.Peer</constant>
+    interface. The D-Bus machine identity is a 128-bit UUID. On Linux systems running systemd, this
+    corresponds to the contents of <filename>/etc/machine-id</filename>. On success, the machine identity is
+    stored in <parameter>machine</parameter>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, this function returns a non-negative integer. On failure, it returns a negative
+    errno-style error code.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>An argument is invalid.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOPKG</constant></term>
+
+          <listitem><para>The bus cannot be resolved.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ECHILD</constant></term>
+
+          <listitem><para>The bus was created in a different process, library or module instance.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOMEM</constant></term>
+
+          <listitem><para>Memory allocation failed.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_bus_get_name_machine_id()</function> was added in version 246.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_bus_interface_name_is_valid.xml b/man/sd_bus_interface_name_is_valid.xml
new file mode 100644
index 0000000..bd526a1
--- /dev/null
+++ b/man/sd_bus_interface_name_is_valid.xml
@@ -0,0 +1,108 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_bus_interface_name_is_valid" xmlns:xi="http://www.w3.org/2001/XInclude">
+  <refentryinfo>
+    <title>sd_bus_interface_name_is_valid</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_interface_name_is_valid</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_interface_name_is_valid</refname>
+    <refname>sd_bus_service_name_is_valid</refname>
+    <refname>sd_bus_member_name_is_valid</refname>
+    <refname>sd_bus_object_path_is_valid</refname>
+
+    <refpurpose>Check if a string is a valid bus name or object path</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_interface_name_is_valid</function></funcdef>
+        <paramdef>const char* <parameter>p</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_service_name_is_valid</function></funcdef>
+        <paramdef>const char* <parameter>p</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_member_name_is_valid</function></funcdef>
+        <paramdef>const char* <parameter>p</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_object_path_is_valid</function></funcdef>
+        <paramdef>const char* <parameter>p</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_bus_interface_name_is_valid()</function> checks if a given string
+    <parameter>p</parameter> is a syntactically valid bus interface name. Similarly,
+    <function>sd_bus_service_name_is_valid()</function> checks if the argument is a valid bus service name,
+    <function>sd_bus_member_name_is_valid()</function> checks if the argument is a valid bus interface member
+    name, and <function>sd_bus_object_path_is_valid()</function> checks if the argument is a valid bus object
+    path. Those functions generally check that only allowed characters are used and that the length of the
+    string is within limits.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>Those functions return 1 if the argument is a valid interface / service / member name or object
+    path, and 0 if it is not. If the argument is <constant>NULL</constant>, an error is returned.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>The <parameter>p</parameter> parameter is
+          <constant>NULL</constant>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_bus_interface_name_is_valid()</function>,
+    <function>sd_bus_service_name_is_valid()</function>,
+    <function>sd_bus_member_name_is_valid()</function>, and
+    <function>sd_bus_object_path_is_valid()</function> were added in version 246.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_call_method</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_bus_is_open.xml b/man/sd_bus_is_open.xml
new file mode 100644
index 0000000..586d1f6
--- /dev/null
+++ b/man/sd_bus_is_open.xml
@@ -0,0 +1,112 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_bus_is_open"
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_bus_is_open</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_is_open</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_is_open</refname>
+    <refname>sd_bus_is_ready</refname>
+
+    <refpurpose>Check whether the bus connection is open or ready</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_is_open</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_is_ready</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+      </funcprototype>
+
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_bus_is_open()</function> checks whether the specified bus connection is open, i.e. in the
+    process of being established, already established or in the process of being torn down. It returns zero when the
+    connection has not been started yet
+    (i.e. <citerefentry><refentrytitle>sd_bus_start</refentrytitle><manvolnum>3</manvolnum></citerefentry> or some
+    equivalent call has not been invoked yet), or is fully terminated again (for example after
+    <citerefentry><refentrytitle>sd_bus_close</refentrytitle><manvolnum>3</manvolnum></citerefentry>), it returns
+    positive otherwise.</para>
+
+    <para><function>sd_bus_is_ready()</function> checks whether the specified connection is fully established,
+    i.e. completed the connection and authentication phases of the protocol and received the
+    <function>Hello()</function> method call response, and is not in the process of being torn down again. It returns
+    zero outside of this state, and positive otherwise. Effectively, this function returns positive while regular
+    messages can be sent or received on the connection.</para>
+
+    <para>The <parameter>bus</parameter> argument may be <constant>NULL</constant>, zero is also returned in
+    that case.</para>
+
+    <para>To be notified when the connection is fully established, use
+    <citerefentry><refentrytitle>sd_bus_set_connected_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry> and
+    install a match for the <function>Connected()</function> signal on the
+    <literal>org.freedesktop.DBus.Local</literal> interface. To be notified when the connection is torn down again,
+    install a match for the <function>Disconnected()</function> signal on the
+    <literal>org.freedesktop.DBus.Local</literal> interface.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>Those functions return 0 if the bus is <emphasis>not</emphasis> in the given state, and a positive
+    integer when it is. On failure, a negative errno-style error code is returned.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-ECHILD</constant></term>
+
+          <listitem><para>The bus connection has been created in a different process, library or module instance.</para></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_bus_is_open()</function> and
+    <function>sd_bus_is_ready()</function> were added in version 237.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_start</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_close</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_set_connected_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_bus_list_names.xml b/man/sd_bus_list_names.xml
new file mode 100644
index 0000000..77cd477
--- /dev/null
+++ b/man/sd_bus_list_names.xml
@@ -0,0 +1,125 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_bus_list_names"
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_bus_list_names</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_list_names</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_list_names</refname>
+
+    <refpurpose>Retrieve information about registered names on a bus</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_list_names</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>char ***<parameter>acquired</parameter></paramdef>
+        <paramdef>char ***<parameter>activatable</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_bus_list_names()</function> retrieves information about the registered names on a bus.
+    If <parameter>acquired</parameter> is not <constant>NULL</constant>, this function calls
+    <ulink url="https://dbus.freedesktop.org/doc/dbus-specification.html#bus-messages-list-names">
+    org.freedesktop.DBus.ListNames</ulink> to retrieve the list of currently-owned names on the bus. If
+    <parameter>acquired</parameter> is not <constant>NULL</constant>, the function calls
+    <ulink url="https://dbus.freedesktop.org/doc/dbus-specification.html#bus-messages-list-activatable-names">
+    org.freedesktop.DBus.ListActivableNames</ulink> to retrieve the list of all names on the bus that can be
+    activated. Note that ownership of the arrays returned by <function>sd_bus_list_names()</function> in
+    <parameter>acquired</parameter> and <parameter>activatable</parameter> is transferred to the caller and
+    hence, the caller is responsible for freeing these arrays and their contents.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, <function>sd_bus_list_names()</function> returns a non-negative integer. On failure,
+    it returns a negative errno-style error code.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para><parameter>bus</parameter> or both <parameter>acquired</parameter> and
+          <parameter>activatable</parameter> were <constant>NULL</constant>.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOPKG</constant></term>
+
+          <listitem><para>The bus cannot be resolved.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ECHILD</constant></term>
+
+          <listitem><para>The bus was created in a different process, library or module instance.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOMEM</constant></term>
+
+          <listitem><para>Memory allocation failed.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOTCONN</constant></term>
+
+          <listitem><para>The bus is not connected.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_bus_list_names()</function> was added in version 246.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+</refentry>
diff --git a/man/sd_bus_message_append.xml b/man/sd_bus_message_append.xml
new file mode 100644
index 0000000..98667ad
--- /dev/null
+++ b/man/sd_bus_message_append.xml
@@ -0,0 +1,239 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_bus_message_append"
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_bus_message_append</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_message_append</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_message_append</refname>
+    <refname>sd_bus_message_appendv</refname>
+
+    <refpurpose>Attach fields to a D-Bus message based on a type string</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int sd_bus_message_append</funcdef>
+        <paramdef>sd_bus_message *<parameter>m</parameter></paramdef>
+        <paramdef>const char *<parameter>types</parameter></paramdef>
+        <paramdef>…</paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int sd_bus_message_appendv</funcdef>
+        <paramdef>sd_bus_message *<parameter>m</parameter></paramdef>
+        <paramdef>const char *<parameter>types</parameter></paramdef>
+        <paramdef>va_list <parameter>ap</parameter></paramdef>
+      </funcprototype>
+
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>The <function>sd_bus_message_append()</function> function appends a sequence of fields to
+    the D-Bus message object <parameter>m</parameter>. The type string <parameter>types</parameter>
+    describes the types of the field arguments that follow. For each type specified in the type
+    string, one or more arguments need to be specified, in the same order as declared in the type
+    string.</para>
+
+    <para>The type string is composed of the elements shown in the table below. It contains zero or
+    more single "complete types". Each complete type may be one of the basic types or a fully
+    described container type. A container type may be a structure with the contained types, a
+    variant, an array with its element type, or a dictionary entry with the contained types. The
+    type string is <constant>NUL</constant>-terminated.</para>
+
+    <para>In case of a basic type, one argument of the corresponding type is expected.</para>
+
+    <para>A structure is denoted by a sequence of complete types between <literal>(</literal> and
+    <literal>)</literal>. This sequence cannot be empty — it must contain at least one type.
+    Arguments corresponding to this nested sequence follow the same rules as if they were not
+    nested.</para>
+
+    <para>A variant is denoted by <literal>v</literal>. Corresponding arguments must begin with a
+    type string denoting a complete type, and following that, arguments corresponding to the
+    specified type.</para>
+
+    <para>An array is denoted by <literal>a</literal> followed by a complete type. Corresponding
+    arguments must begin with the number of entries in the array, followed by the entries
+    themselves, matching the element type of the array.</para>
+
+    <para>A dictionary is an array of dictionary entries, denoted by <literal>a</literal> followed
+    by a pair of complete types between <literal>{</literal> and <literal>}</literal>. The first of
+    those types must be a basic type. Corresponding arguments must begin with the number of
+    dictionary entries, followed by a pair of values for each entry matching the element type of the
+    dictionary entries.</para>
+
+    <para><function>sd_bus_message_appendv()</function> is equivalent to
+    <function>sd_bus_message_append()</function>, except that it is called with a
+    <literal>va_list</literal> instead of a variable number of arguments. This function does not
+    call the <function>va_end()</function> macro. Because it invokes the
+    <function>va_arg()</function> macro, the value of <parameter>ap</parameter> is undefined after
+    the call.</para>
+
+    <para>For further details on the D-Bus type system, please consult the
+    <ulink url="https://dbus.freedesktop.org/doc/dbus-specification.html#type-system">D-Bus Specification</ulink>.
+    </para>
+
+    <table>
+      <title>Item type specifiers</title>
+
+      <tgroup cols='5'>
+        <xi:include href="sd_bus_message_append_basic.xml" xpointer="xpointer(//table[@id='format-specifiers'])//colspec" />
+        <xi:include href="sd_bus_message_append_basic.xml" xpointer="xpointer(//table[@id='format-specifiers']//thead)" />
+
+        <tbody>
+          <xi:include href="sd_bus_message_append_basic.xml" xpointer="xpointer(//table[@id='format-specifiers']//tbody/*)" />
+
+          <row>
+            <entry><literal>a</literal></entry>
+            <entry><constant>SD_BUS_TYPE_ARRAY</constant></entry>
+            <entry>array</entry>
+            <entry>determined by array type and size</entry>
+            <entry>int, followed by array contents</entry>
+          </row>
+
+          <row>
+            <entry><literal>v</literal></entry>
+            <entry><constant>SD_BUS_TYPE_VARIANT</constant></entry>
+            <entry>variant</entry>
+            <entry>determined by the type argument</entry>
+            <entry>signature string, followed by variant contents</entry>
+          </row>
+
+          <row>
+            <entry><literal>(</literal></entry>
+            <entry><constant>SD_BUS_TYPE_STRUCT_BEGIN</constant></entry>
+            <entry>array start</entry>
+            <entry morerows="1">determined by the nested types</entry>
+            <entry morerows="1">structure contents</entry>
+          </row>
+          <row>
+            <entry><literal>)</literal></entry>
+            <entry><constant>SD_BUS_TYPE_STRUCT_END</constant></entry>
+            <entry>array end</entry>
+          </row>
+
+          <row>
+            <entry><literal>{</literal></entry>
+            <entry><constant>SD_BUS_TYPE_DICT_ENTRY_BEGIN</constant></entry>
+            <entry>dictionary entry start</entry>
+            <entry morerows="1">determined by the nested types</entry>
+            <entry morerows="1">dictionary contents</entry>
+          </row>
+          <row>
+            <entry><literal>}</literal></entry>
+            <entry><constant>SD_BUS_TYPE_DICT_ENTRY_END</constant></entry>
+            <entry>dictionary entry end</entry>
+          </row>
+       </tbody>
+      </tgroup>
+    </table>
+
+    <para>For types <literal>s</literal> and <literal>g</literal> (unicode string or signature), the pointer
+    may be <constant>NULL</constant>, which is equivalent to an empty string. For <literal>h</literal> (UNIX
+    file descriptor), the descriptor is duplicated by this call and the passed descriptor stays in possession
+    of the caller. See
+    <citerefentry><refentrytitle>sd_bus_message_append_basic</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    for the precise interpretation of those and other types.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Types String Grammar</title>
+
+    <programlisting>types ::= complete_type*
+complete_type ::= basic_type | variant | structure | array | dictionary
+basic_type ::= "y" | "n" | "q" | "u" | "i" | "x" | "t" | "d" |
+               "b" | "h" |
+               "s" | "o" | "g"
+variant ::= "v"
+structure ::= "(" complete_type+ ")"
+array ::= "a" complete_type
+dictionary ::= "a" "{" basic_type complete_type "}"
+</programlisting>
+  </refsect1>
+
+  <refsect1>
+    <title>Examples</title>
+
+    <para>Append a single basic type (the string <literal>a string</literal>):
+    </para>
+
+    <programlisting>sd_bus_message *m;
+…
+sd_bus_message_append(m, "s", "a string");</programlisting>
+
+    <para>Append all types of integers:</para>
+
+    <programlisting>uint8_t y = 1;
+int16_t n = 2;
+uint16_t q = 3;
+int32_t i = 4;
+uint32_t u = 5;
+int32_t x = 6;
+uint32_t t = 7;
+double d = 8.0;
+sd_bus_message_append(m, "ynqiuxtd", y, n, q, i, u, x, t, d);</programlisting>
+
+     <para>Append a structure composed of a string and a D-Bus path:</para>
+
+     <programlisting>sd_bus_message_append(m, "(so)", "a string", "/a/path");
+    </programlisting>
+
+     <para>Append an array of UNIX file descriptors:</para>
+
+     <programlisting>sd_bus_message_append(m, "ah", 3, STDIN_FILENO, STDOUT_FILENO, STDERR_FILENO);
+    </programlisting>
+
+     <para>Append a variant, with the real type "g" (signature),
+     and value "sdbusisgood":</para>
+
+     <programlisting>sd_bus_message_append(m, "v", "g", "sdbusisgood");</programlisting>
+
+     <para>Append a dictionary containing the mapping {1=>"a", 2=>"b", 3=>""}:
+     </para>
+
+     <programlisting>sd_bus_message_append(m, "a{is}", 3, 1, "a", 2, "b", 3, NULL);
+     </programlisting>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, these functions return a non-negative integer. On failure, they return a
+    negative errno-style error code.</para>
+
+    <xi:include href="sd_bus_message_append_basic.xml" xpointer="errors" />
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_message_append_basic</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_message_append_array</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_message_open_container</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_bus_message_append_array.xml b/man/sd_bus_message_append_array.xml
new file mode 100644
index 0000000..ea8f532
--- /dev/null
+++ b/man/sd_bus_message_append_array.xml
@@ -0,0 +1,179 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_bus_message_append_array"
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_bus_message_append_array</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_message_append_array</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_message_append_array</refname>
+    <refname>sd_bus_message_append_array_memfd</refname>
+    <refname>sd_bus_message_append_array_iovec</refname>
+    <refname>sd_bus_message_append_array_space</refname>
+
+    <refpurpose>Append an array of fields to a D-Bus
+    message</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int sd_bus_message_append_array</funcdef>
+        <paramdef>sd_bus_message *<parameter>m</parameter></paramdef>
+        <paramdef>char <parameter>type</parameter></paramdef>
+        <paramdef>void *<parameter>ptr</parameter></paramdef>
+        <paramdef>size_t <parameter>size</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int sd_bus_message_append_array_memfd</funcdef>
+        <paramdef>sd_bus_message *<parameter>m</parameter></paramdef>
+        <paramdef>char <parameter>type</parameter></paramdef>
+        <paramdef>int <parameter>memfd</parameter></paramdef>
+        <paramdef>uint64_t <parameter>offset</parameter></paramdef>
+        <paramdef>uint64_t <parameter>size</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int sd_bus_message_append_array_iovec</funcdef>
+        <paramdef>sd_bus_message *<parameter>m</parameter></paramdef>
+        <paramdef>char <parameter>type</parameter></paramdef>
+        <paramdef>const struct iovec *<parameter>iov</parameter></paramdef>
+        <paramdef>unsigned <parameter>n</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int sd_bus_message_append_array_space</funcdef>
+        <paramdef>sd_bus_message *<parameter>m</parameter></paramdef>
+        <paramdef>char <parameter>type</parameter></paramdef>
+        <paramdef>size_t <parameter>size</parameter></paramdef>
+        <paramdef>void **<parameter>ptr</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>The <function>sd_bus_message_append_array()</function>
+    function appends an array to a D-Bus message
+    <parameter>m</parameter>. A container will be opened, the array
+    contents appended, and the container closed. The parameter
+    <parameter>type</parameter> determines how the pointer
+    <parameter>p</parameter> is interpreted.
+    <parameter>type</parameter> must be one of the "trivial" types
+    <literal>y</literal>, <literal>n</literal>, <literal>q</literal>,
+    <literal>i</literal>, <literal>u</literal>, <literal>x</literal>,
+    <literal>t</literal>, <literal>d</literal> (but not
+    <literal>b</literal>), as defined by the <ulink
+    url="https://dbus.freedesktop.org/doc/dbus-specification.html#basic-types">Basic
+    D-Bus Types</ulink> section of the D-Bus specification, and listed in
+    <citerefentry><refentrytitle>sd_bus_message_append_basic</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+    Pointer <parameter>p</parameter> must point to an array of size
+    <parameter>size</parameter> bytes containing items of the
+    respective type. Size <parameter>size</parameter> must be a
+    multiple of the size of the type <parameter>type</parameter>. As a
+    special case, <parameter>p</parameter> may be
+    <constant>NULL</constant>, if <parameter>size</parameter> is 0.
+    The memory pointed to by <parameter>p</parameter> is copied into
+    the memory area containing the message and stays in possession of
+    the caller. The caller may hence freely change the data after this
+    call without affecting the message the array was appended
+    to.</para>
+
+    <para>The <function>sd_bus_message_append_array_memfd()</function>
+    function appends an array of a trivial type to message
+    <parameter>m</parameter>, similar to
+    <function>sd_bus_message_append_array()</function>. The contents
+    of the memory file descriptor <parameter>memfd</parameter>
+    starting at the specified offset and of the specified size is
+    used as the contents of the array. The offset and size must be a
+    multiple of the size of the type
+    <parameter>type</parameter>. However, as a special exception, if
+    the offset is specified as zero and the size specified as
+    UINT64_MAX the full memory file descriptor contents is used. The
+    memory file descriptor is sealed by this call if it has not been
+    sealed yet, and cannot be modified after this call. See
+    <citerefentry
+    project='man-pages'><refentrytitle>memfd_create</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+    for details about memory file descriptors. Appending arrays with
+    memory file descriptors enables efficient zero-copy data transfer,
+    as the memory file descriptor may be passed as-is to the
+    destination, without copying the memory in it to the destination
+    process. Not all protocol transports support passing memory file
+    descriptors between participants, in which case this call will
+    automatically fall back to copying. Also, as memory file
+    descriptor passing is inefficient for smaller amounts of data,
+    copying might still be enforced even where memory file descriptor
+    passing is supported.</para>
+
+    <para>The <function>sd_bus_message_append_array_iovec()</function>
+    function appends an array of a trivial type to the message
+    <parameter>m</parameter>, similar to
+    <function>sd_bus_message_append_array()</function>. Contents of
+    the I/O vector array <parameter>iov</parameter> are used as the
+    contents of the array. The total size of
+    <parameter>iov</parameter> payload (the sum of
+    <structfield>iov_len</structfield> fields) must be a multiple of
+    the size of the type <parameter>type</parameter>. The
+    <parameter>iov</parameter> argument must point to
+    <parameter>n</parameter> I/O vector structures. Each structure may
+    have the <structname>iov_base</structname> field set, in which
+    case the memory pointed to will be copied into the message, or
+    unset (set to zero), in which case a block of zeros of length
+    <structname>iov_len</structname> bytes will be inserted. The
+    memory pointed at by <parameter>iov</parameter> may be changed
+    after this call.</para>
+
+    <para>The <function>sd_bus_message_append_array_space()</function>
+    function appends space for an array of a trivial type to message
+    <parameter>m</parameter>.  It behaves the same as
+    <function>sd_bus_message_append_array()</function>, but instead of
+    copying items to the message, it returns a pointer to the
+    destination area to the caller in pointer
+    <parameter>p</parameter>. The caller should subsequently write the
+    array contents to this memory. Modifications to the memory
+    pointed to should only occur until the next operation on the bus
+    message is invoked. Most importantly, the memory should not be
+    altered anymore when another field has been added to the message
+    or the message has been sealed.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, these calls return 0 or a positive integer. On failure, they return a negative
+    errno-style error code.</para>
+
+    <xi:include href="sd_bus_message_append_basic.xml" xpointer="errors" />
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_message_append</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_message_append_basic</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>memfd_create</refentrytitle><manvolnum>2</manvolnum></citerefentry>,
+      <ulink url="https://dbus.freedesktop.org/doc/dbus-specification.html">The D-Bus specification</ulink>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_bus_message_append_basic.xml b/man/sd_bus_message_append_basic.xml
new file mode 100644
index 0000000..3509095
--- /dev/null
+++ b/man/sd_bus_message_append_basic.xml
@@ -0,0 +1,261 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_bus_message_append_basic" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_bus_message_append_basic</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_message_append_basic</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_message_append_basic</refname>
+
+    <refpurpose>Attach a single field to a message</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int sd_bus_message_append_basic</funcdef>
+        <paramdef>sd_bus_message *<parameter>m</parameter></paramdef>
+        <paramdef>char <parameter>type</parameter></paramdef>
+        <paramdef>const void *<parameter>p</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_bus_message_append_basic()</function> appends a
+    single field to the message <parameter>m</parameter>. The
+    parameter <parameter>type</parameter> determines how the pointer
+    <parameter>p</parameter> is interpreted.
+    <parameter>type</parameter> must be one of the basic types as
+    defined by the <ulink
+    url="https://dbus.freedesktop.org/doc/dbus-specification.html#basic-types">Basic
+    Types</ulink> section of the D-Bus specification, and listed in
+    the table below.
+    </para>
+
+    <table id='format-specifiers'>
+      <title>Item type specifiers</title>
+
+      <tgroup cols='5'>
+        <colspec colname='specifier' />
+        <colspec colname='constant' />
+        <colspec colname='description' />
+        <colspec colname='size' />
+        <colspec colname='ctype' />
+        <thead>
+          <row>
+            <entry>Specifier</entry>
+            <entry>Constant</entry>
+            <entry>Description</entry>
+            <entry>Size</entry>
+            <entry>Expected C Type</entry>
+          </row>
+        </thead>
+        <tbody>
+          <row>
+            <entry><literal>y</literal></entry>
+            <entry><constant>SD_BUS_TYPE_BYTE</constant></entry>
+            <entry>unsigned integer</entry>
+            <entry>1 byte</entry>
+            <entry>uint8_t</entry>
+          </row>
+
+          <row>
+            <entry><literal>b</literal></entry>
+            <entry><constant>SD_BUS_TYPE_BOOLEAN</constant></entry>
+            <entry>boolean</entry>
+            <entry>4 bytes</entry>
+            <entry>int</entry>
+          </row>
+
+          <row>
+            <entry><literal>n</literal></entry>
+            <entry><constant>SD_BUS_TYPE_INT16</constant></entry>
+            <entry>signed integer</entry>
+            <entry>2 bytes</entry>
+            <entry>int16_t</entry>
+          </row>
+
+          <row>
+            <entry><literal>q</literal></entry>
+            <entry><constant>SD_BUS_TYPE_UINT16</constant></entry>
+            <entry>unsigned integer</entry>
+            <entry>2 bytes</entry>
+            <entry>uint16_t</entry>
+          </row>
+
+          <row>
+            <entry><literal>i</literal></entry>
+            <entry><constant>SD_BUS_TYPE_INT32</constant></entry>
+            <entry>signed integer</entry>
+            <entry>4 bytes</entry>
+            <entry>int32_t</entry>
+          </row>
+
+          <row>
+            <entry><literal>u</literal></entry>
+            <entry><constant>SD_BUS_TYPE_UINT32</constant></entry>
+            <entry>unsigned integer</entry>
+            <entry>4 bytes</entry>
+            <entry>uint32_t</entry>
+          </row>
+
+          <row>
+            <entry><literal>x</literal></entry>
+            <entry><constant>SD_BUS_TYPE_INT64</constant></entry>
+            <entry>signed integer</entry>
+            <entry>8 bytes</entry>
+            <entry>int64_t</entry>
+          </row>
+
+          <row>
+            <entry><literal>t</literal></entry>
+            <entry><constant>SD_BUS_TYPE_UINT64</constant></entry>
+            <entry>unsigned integer</entry>
+            <entry>8 bytes</entry>
+            <entry>uint64_t</entry>
+          </row>
+
+          <row>
+            <entry><literal>d</literal></entry>
+            <entry><constant>SD_BUS_TYPE_DOUBLE</constant></entry>
+            <entry>floating-point</entry>
+            <entry>8 bytes</entry>
+            <entry>double</entry>
+          </row>
+
+          <row>
+            <entry><literal>s</literal></entry>
+            <entry><constant>SD_BUS_TYPE_STRING</constant></entry>
+            <entry>Unicode string</entry>
+            <entry>variable</entry>
+            <entry>char[]</entry>
+          </row>
+
+          <row>
+            <entry><literal>o</literal></entry>
+            <entry><constant>SD_BUS_TYPE_OBJECT_PATH</constant></entry>
+            <entry>object path</entry>
+            <entry>variable</entry>
+            <entry>char[]</entry>
+          </row>
+
+          <row>
+            <entry><literal>g</literal></entry>
+            <entry><constant>SD_BUS_TYPE_SIGNATURE</constant></entry>
+            <entry>signature</entry>
+            <entry>variable</entry>
+            <entry>char[]</entry>
+          </row>
+
+          <row>
+            <entry><literal>h</literal></entry>
+            <entry><constant>SD_BUS_TYPE_UNIX_FD</constant></entry>
+            <entry>UNIX file descriptor</entry>
+            <entry>4 bytes</entry>
+            <entry>int</entry>
+          </row>
+       </tbody>
+      </tgroup>
+    </table>
+
+    <para>The value of the parameter is copied into a memory area held
+    by the message object, stays in the possession of the caller and
+    may hence be freely changed after this call without affecting the
+    bus message it has been added to. If <parameter>type</parameter>
+    is <literal>h</literal> (UNIX file descriptor), the descriptor is
+    duplicated by this call and the passed descriptor stays in
+    possession of the caller.</para>
+
+    <para>For types <literal>s</literal>, <literal>o</literal>, and
+    <literal>g</literal>, the parameter <parameter>p</parameter> is
+    interpreted as a pointer to a <constant>NUL</constant>-terminated
+    character sequence. As a special case, a <constant>NULL</constant>
+    pointer is interpreted as an empty string. The string should be
+    valid Unicode string encoded as UTF-8. In case of the two latter
+    types, the additional requirements for a D-Bus object path or
+    type signature should be satisfied. Those requirements should be
+    verified by the recipient of the message.
+    </para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, this call returns 0 or a positive integer. On
+    failure, it returns a negative errno-style error code.</para>
+
+    <refsect2 id='errors'>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>Specified parameter is invalid.
+          </para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EPERM</constant></term>
+
+          <listitem><para>Message has been sealed.
+          </para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ESTALE</constant></term>
+
+          <listitem><para>Message is in invalid state.
+          </para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENXIO</constant></term>
+
+          <listitem><para>Message cannot be appended to.
+          </para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOMEM</constant></term>
+
+          <listitem><para>Memory allocation failed.</para></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_message_read_basic</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_message_append</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <ulink url="https://dbus.freedesktop.org/doc/dbus-specification.html">The D-Bus specification</ulink>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_bus_message_append_string_memfd.xml b/man/sd_bus_message_append_string_memfd.xml
new file mode 100644
index 0000000..5a4db0d
--- /dev/null
+++ b/man/sd_bus_message_append_string_memfd.xml
@@ -0,0 +1,119 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_bus_message_append_string_memfd"
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_bus_message_append_string_memfd</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_message_append_string_memfd</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_message_append_string_memfd</refname>
+    <refname>sd_bus_message_append_string_iovec</refname>
+    <refname>sd_bus_message_append_string_space</refname>
+
+    <refpurpose>Attach a string to a message</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int sd_bus_message_append_string_memfd</funcdef>
+        <paramdef>sd_bus_message *<parameter>m</parameter></paramdef>
+        <paramdef>int <parameter>memfd</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int sd_bus_message_append_string_iovec</funcdef>
+        <paramdef>sd_bus_message *<parameter>m</parameter></paramdef>
+        <paramdef>const struct iovec *<parameter>iov</parameter></paramdef>
+        <paramdef>unsigned <parameter>n</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int sd_bus_message_append_string_space</funcdef>
+        <paramdef>sd_bus_message *<parameter>m</parameter></paramdef>
+        <paramdef>size_t <parameter>size</parameter></paramdef>
+        <paramdef>char **<parameter>s</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>The functions
+    <function>sd_bus_message_append_string_memfd()</function> and
+    <function>sd_bus_message_append_string_iovec()</function> can be
+    used to append a single string (item of type <literal>s</literal>)
+    to message <parameter>m</parameter>.</para>
+
+    <para>In case of
+    <function>sd_bus_message_append_string_memfd()</function>, the
+    contents of <parameter>memfd</parameter> are the string. They must
+    satisfy the same constraints as described for the
+    <literal>s</literal> type in
+    <citerefentry><refentrytitle>sd_bus_message_append_basic</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para>
+
+    <para>In case of
+    <function>sd_bus_message_append_string_iovec()</function>, the
+    payload of <parameter>iov</parameter> is the string. It must
+    satisfy the same constraints as described for the
+    <literal>s</literal> type in
+    <citerefentry><refentrytitle>sd_bus_message_append_basic</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para>
+
+    <para>The <parameter>iov</parameter> argument must point to
+    <parameter>n</parameter> <structname>struct iovec</structname>
+    structures. Each structure may have the
+    <structname>iov_base</structname> field set, in which case the
+    memory pointed to will be copied into the message, or unset, in
+    which case a block of spaces (ASCII 32) of length
+    <structname>iov_len</structname> will be inserted. The
+    memory pointed at by <parameter>iov</parameter> may be changed
+    after this call.</para>
+
+    <para>The
+    <function>sd_bus_message_append_string_space()</function> function appends
+    space for a string to message <parameter>m</parameter>. It behaves
+    similar to <function>sd_bus_message_append_basic()</function> with
+    type <literal>s</literal>, but instead of copying a string into
+    the message, it returns a pointer to the destination area to
+    the caller in pointer <parameter>p</parameter>. Space for the string
+    of length <parameter>size</parameter> plus the terminating
+    <constant>NUL</constant> is allocated.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, those calls return 0 or a positive integer. On failure, they return a negative
+    errno-style error code.</para>
+
+    <xi:include href="sd_bus_message_append_basic.xml" xpointer="errors" />
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_message_append_basic</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <ulink url="https://dbus.freedesktop.org/doc/dbus-specification.html">The D-Bus specification</ulink>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_bus_message_append_strv.xml b/man/sd_bus_message_append_strv.xml
new file mode 100644
index 0000000..8bf78dd
--- /dev/null
+++ b/man/sd_bus_message_append_strv.xml
@@ -0,0 +1,81 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_bus_message_append_strv"
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_bus_message_append_strv</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_message_append_strv</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_message_append_strv</refname>
+
+    <refpurpose>Attach an array of strings to a message</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int sd_bus_message_append_strv</funcdef>
+        <paramdef>sd_bus_message *<parameter>m</parameter></paramdef>
+        <paramdef>char **<parameter>l</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>The <function>sd_bus_message_append()</function> function can be
+    used to append an array of strings to message
+    <parameter>m</parameter>. The parameter <parameter>l</parameter>
+    shall point to a <constant>NULL</constant>-terminated array of pointers
+    to <constant>NUL</constant>-terminated strings. Each string must
+    satisfy the same constraints as described for the
+    <literal>s</literal> type in
+    <citerefentry><refentrytitle>sd_bus_message_append_basic</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+    </para>
+
+    <para>The memory pointed at by <parameter>p</parameter> and the
+    contents of the strings themselves are copied into the memory area
+    containing the message and may be changed after this call. Note
+    that the signature of <parameter>l</parameter> parameter is to be
+    treated as <type>const char *const *</type>, and the contents
+    will not be modified.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, this call returns 0 or a positive integer. On failure, a negative errno-style error
+    code is returned.</para>
+
+    <xi:include href="sd_bus_message_append_basic.xml" xpointer="errors" />
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_message_append</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_message_append_array</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <ulink url="https://dbus.freedesktop.org/doc/dbus-specification.html">The D-Bus specification</ulink>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_bus_message_at_end.xml b/man/sd_bus_message_at_end.xml
new file mode 100644
index 0000000..cb5bba6
--- /dev/null
+++ b/man/sd_bus_message_at_end.xml
@@ -0,0 +1,95 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_bus_message_at_end" xmlns:xi="http://www.w3.org/2001/XInclude">
+  <refentryinfo>
+    <title>sd_bus_message_at_end</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_message_at_end</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_message_at_end</refname>
+
+    <refpurpose>Check if a message has been fully read</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_message_at_end</function></funcdef>
+        <paramdef>sd_bus_message *<parameter>m</parameter></paramdef>
+        <paramdef>int <parameter>complete</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_bus_message_at_end()</function> returns whether all data from the currently opened
+    container in <parameter>m</parameter> or all data from all containers in <parameter>m</parameter> has
+    been read. If <parameter>complete</parameter> is zero, this function returns whether all data from the
+    currently opened container has been read. If <parameter>complete</parameter> is non-zero, this function
+    returns whether all data from all containers in <parameter>m</parameter> has been read.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>If all data from all containers or the current container (depending on the value of
+    <parameter>complete</parameter>) has been read, <function>sd_bus_message_at_end()</function> returns a
+    positive integer. If there is still data left to be read, it returns zero. On failure, it returns a
+    negative errno-style error code.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>The <parameter>m</parameter> parameter is <constant>NULL</constant>.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EPERM</constant></term>
+
+          <listitem><para>The message is not sealed.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_bus_message_at_end()</function> was added in version 246.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_message_read</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+</refentry>
diff --git a/man/sd_bus_message_copy.xml b/man/sd_bus_message_copy.xml
new file mode 100644
index 0000000..278bc35
--- /dev/null
+++ b/man/sd_bus_message_copy.xml
@@ -0,0 +1,111 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_bus_message_copy" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_bus_message_copy</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_message_copy</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_message_copy</refname>
+
+    <refpurpose>Copy the contents of one message to another</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int sd_bus_message_copy</funcdef>
+        <paramdef>sd_bus_message *<parameter>m</parameter></paramdef>
+        <paramdef>sd_bus_message *<parameter>source</parameter></paramdef>
+        <paramdef>int <parameter>all</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_bus_message_copy()</function> copies the contents from
+    message <parameter>source</parameter> to <parameter>m</parameter>. If
+    <parameter>all</parameter> is false, a single complete type is copied
+    (basic or container). If <parameter>all</parameter> is true, the contents
+    are copied until the end of the currently open container or the end
+    of <parameter>source</parameter>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, this call returns true if anything was copied, and false if
+    there was nothing to copy. On failure, it returns a negative errno-style error
+    code.</para>
+
+    <refsect2 id='errors'>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para><parameter>source</parameter> or <parameter>m</parameter> are
+          <constant>NULL</constant>.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EPERM</constant></term>
+
+          <listitem><para>Message <parameter>m</parameter> has been sealed or <parameter>source</parameter>
+          has <emphasis>not</emphasis> been sealed.  </para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ESTALE</constant></term>
+
+          <listitem><para>Destination message is in invalid state.
+          </para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENXIO</constant></term>
+
+          <listitem><para>Destination message cannot be appended to.
+          </para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOMEM</constant></term>
+
+          <listitem><para>Memory allocation failed.</para></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_message_append</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_bus_message_dump.xml b/man/sd_bus_message_dump.xml
new file mode 100644
index 0000000..83a4a4e
--- /dev/null
+++ b/man/sd_bus_message_dump.xml
@@ -0,0 +1,108 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_bus_message_dump"
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_bus_message_dump</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_message_dump</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_message_dump</refname>
+
+    <refpurpose>Produce a string representation of a message for debugging purposes</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int sd_bus_message_dump</funcdef>
+        <paramdef>sd_bus_message *<parameter>m</parameter></paramdef>
+        <paramdef>FILE *<parameter>f</parameter></paramdef>
+        <paramdef>uint64_t <parameter>flags</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+
+    <para>
+      <constant>SD_BUS_MESSAGE_DUMP_WITH_HEADER</constant>,
+      <constant>SD_BUS_MESSAGE_DUMP_SUBTREE_ONLY</constant>
+    </para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>The <function>sd_bus_message_dump()</function> function writes a textual representation of the
+    message <parameter>m</parameter> to the stream <parameter>f</parameter>. If <parameter>f</parameter> is
+    <constant>NULL</constant>, standard output (<constant>stdio</constant>) will be used. This function is
+    intended to be used for debugging purposes, and the output is neither stable nor designed to be machine
+    readable.</para>
+
+    <para>The <parameter>flags</parameter> parameter may be used to modify the output. With
+    <constant>SD_BUS_MESSAGE_DUMP_WITH_HEADER</constant>, a header that specifies the message type and flags
+    and some additional metadata is printed. When <constant>SD_BUS_MESSAGE_DUMP_SUBTREE_ONLY</constant> is
+    not passed, the contents of the whole message are printed. When it <emphasis>is</emphasis> passed,
+    only the current container in printed.</para>
+
+    <para>Note that this function moves the read pointer of the message. It may be necessary to reset the
+    position afterwards, for example with
+    <citerefentry><refentrytitle>sd_bus_message_rewind</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+    </para>
+  </refsect1>
+
+  <refsect1>
+    <title>Examples</title>
+
+    <para>Output for a signal message (with <constant>SD_BUS_MESSAGE_DUMP_WITH_HEADER</constant>):
+    <programlisting>
+‣ Type=signal  Endian=l  Flags=1  Version=1  Cookie=22
+  Path=/value/a  Interface=org.freedesktop.DBus.Properties  Member=PropertiesChanged
+  MESSAGE "sa{sv}as" {
+          STRING "org.freedesktop.systemd.ValueTest";
+          ARRAY "{sv}" {
+                  DICT_ENTRY "sv" {
+                          STRING "Value";
+                          VARIANT "s" {
+                                  STRING "object 0x1e, path /value/a";
+                          };
+                  };
+          };
+          ARRAY "s" {
+                  STRING "Value2";
+                  STRING "AnExplicitProperty";
+          };
+  };
+    </programlisting>
+    </para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, this function returns 0 or a positive integer. On failure, it returns a negative
+    errno-style error code. No error codes are currently defined.</para>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_bus_message_get_cookie.xml b/man/sd_bus_message_get_cookie.xml
new file mode 100644
index 0000000..ee41bf4
--- /dev/null
+++ b/man/sd_bus_message_get_cookie.xml
@@ -0,0 +1,113 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_bus_message_get_cookie"
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_bus_message_get_cookie</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_message_get_cookie</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_message_get_cookie</refname>
+    <refname>sd_bus_message_get_reply_cookie</refname>
+    <refpurpose>Returns the transaction cookie of a message</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_message_get_cookie</function></funcdef>
+        <paramdef>sd_bus_message *<parameter>message</parameter></paramdef>
+        <paramdef>uint64_t *<parameter>cookie</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_message_get_reply_cookie</function></funcdef>
+        <paramdef>sd_bus_message *<parameter>message</parameter></paramdef>
+        <paramdef>uint64_t *<parameter>cookie</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_bus_message_get_cookie()</function> returns the
+    transaction cookie of a message. The cookie uniquely identifies a
+    message within each bus peer, but is not globally unique. It is
+    assigned when a message is sent.</para>
+
+    <para><function>sd_bus_message_get_reply_cookie()</function>
+    returns the transaction cookie of the message the specified
+    message is a response to. When a reply message is generated for a
+    method call message, its cookie is copied over into this field.
+    Note that while every message that is transferred is identified by
+    a cookie, only response messages carry a reply cookie
+    field.</para>
+
+    <para>Both functions take a message object as first parameter and
+    a place to store the 64-bit cookie in.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, these calls return 0 or a positive integer. On failure, they return a negative
+    errno-style error code.</para>
+
+    <para>On success, the cookie/reply cookie is returned in the specified 64-bit unsigned integer
+    variable.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>A specified parameter is invalid.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENODATA</constant></term>
+
+          <listitem><para>No cookie has been assigned to this message.  This either indicates that the
+          message has not been sent yet and hence has no cookie assigned, or that the message is not a method
+          response message and hence carries a reply cookie field.</para></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_bus_message_get_cookie()</function> and
+    <function>sd_bus_message_get_reply_cookie()</function> were added in version 209.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_bus_message_get_monotonic_usec.xml b/man/sd_bus_message_get_monotonic_usec.xml
new file mode 100644
index 0000000..2e7017a
--- /dev/null
+++ b/man/sd_bus_message_get_monotonic_usec.xml
@@ -0,0 +1,148 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_bus_message_get_monotonic_usec"
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_bus_message_get_monotonic_usec</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_message_get_monotonic_usec</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_message_get_monotonic_usec</refname>
+    <refname>sd_bus_message_get_realtime_usec</refname>
+    <refname>sd_bus_message_get_seqnum</refname>
+    <refpurpose>Retrieve the sender timestamps and sequence number of a message</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_message_get_monotonic_usec</function></funcdef>
+        <paramdef>sd_bus_message *<parameter>message</parameter></paramdef>
+        <paramdef>uint64_t *<parameter>usec</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_message_get_realtime_usec</function></funcdef>
+        <paramdef>sd_bus_message *<parameter>message</parameter></paramdef>
+        <paramdef>uint64_t *<parameter>usec</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_message_get_seqnum</function></funcdef>
+        <paramdef>sd_bus_message *<parameter>message</parameter></paramdef>
+        <paramdef>uint64_t *<parameter>seqnum</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_bus_message_get_monotonic_usec()</function>
+    returns the monotonic timestamp of the time the message was sent.
+    This value is in microseconds since the
+    <constant>CLOCK_MONOTONIC</constant> epoch, see
+    <citerefentry><refentrytitle>clock_gettime</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+    for details.</para>
+
+    <para>Similarly,
+    <function>sd_bus_message_get_realtime_usec()</function> returns
+    the realtime (wallclock) timestamp of the time the message was
+    sent. This value is in microseconds since Jan 1st, 1970, i.e. in
+    the <constant>CLOCK_REALTIME</constant> clock.</para>
+
+    <para><function>sd_bus_message_get_seqnum()</function> returns the
+    kernel-assigned sequence number of the message. The kernel assigns
+    a global, monotonically increasing sequence number to all messages
+    transmitted on the local system, at the time the message was sent.
+    This sequence number is useful for determining message send order,
+    even across different buses of the local system. The sequence
+    number combined with the boot ID of the system (as returned by
+    <citerefentry><refentrytitle>sd_id128_get_boot</refentrytitle><manvolnum>3</manvolnum></citerefentry>)
+    is a suitable globally unique identifier for bus messages.</para>
+
+    <para>Note that the sending order and receiving order of messages
+    might differ, in particular for broadcast messages. This means
+    that the sequence number and the timestamps of messages a client
+    reads are not necessarily monotonically increasing.</para>
+
+    <para>These timestamps and the sequence number are attached to
+    each message by the kernel and cannot be manipulated by the
+    sender.</para>
+
+    <para>Note that these timestamps are only available on some bus
+    transports, and only after support for them has been negotiated
+    with the
+    <citerefentry><refentrytitle>sd_bus_negotiate_timestamp</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    call.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, these calls return 0 or a positive integer. On
+    failure, these calls return a negative errno-style error
+    code.</para>
+
+    <para>On success, the timestamp or sequence number is returned in
+    the specified 64-bit unsigned integer variable.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>A specified parameter is invalid.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENODATA</constant></term>
+
+          <listitem><para>No timestamp or sequence number information is attached to the passed message. This
+          error is returned if the underlying transport does not support timestamping or assigning of
+          sequence numbers, or if this feature has not been negotiated with
+          <citerefentry><refentrytitle>sd_bus_negotiate_timestamp</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_bus_message_get_monotonic_usec()</function>,
+    <function>sd_bus_message_get_realtime_usec()</function>, and
+    <function>sd_bus_message_get_seqnum()</function> were added in version 209.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_negotiate_timestamp</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>clock_gettime</refentrytitle><manvolnum>2</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_id128_get_boot</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_bus_message_get_signature.xml b/man/sd_bus_message_get_signature.xml
new file mode 100644
index 0000000..6eac36c
--- /dev/null
+++ b/man/sd_bus_message_get_signature.xml
@@ -0,0 +1,118 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_bus_message_get_signature" xmlns:xi="http://www.w3.org/2001/XInclude">
+  <refentryinfo>
+    <title>sd_bus_message_get_signature</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_message_get_signature</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_message_get_signature</refname>
+    <refname>sd_bus_message_is_empty</refname>
+    <refname>sd_bus_message_has_signature</refname>
+
+    <refpurpose>Query bus message signature</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>const char* <function>sd_bus_message_get_signature</function></funcdef>
+        <paramdef>sd_bus_message *<parameter>message</parameter></paramdef>
+        <paramdef>int <parameter>complete</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_message_is_empty</function></funcdef>
+        <paramdef>sd_bus_message *<parameter>message</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_message_has_signature</function></funcdef>
+        <paramdef>sd_bus_message *<parameter>message</parameter></paramdef>
+        <paramdef>const char *<parameter>signature</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_bus_message_get_signature()</function> returns the signature of message
+    <parameter>message</parameter>. If <parameter>complete</parameter> is true, the signature of the
+    whole message is returned, and just the signature of the currently open container otherwise.
+    </para>
+
+    <para><function>sd_bus_message_is_empty()</function> returns true if the message is empty,
+    i.e. when its signature is empty.</para>
+
+    <para><function>sd_bus_message_has_signature()</function> returns true if the signature of the
+    message <parameter>message</parameter> matches given <parameter>signature</parameter>. Parameter
+    <parameter>signature</parameter> may be <constant>NULL</constant>, this is treated the same as
+    an empty string, which is equivalent to calling <function>sd_bus_message_is_empty()</function>.
+    </para>
+</refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, <function>sd_bus_message_get_signature()</function> returns
+    the signature, and <constant>NULL</constant> on error.</para>
+
+    <para>The other functions return 0 or a positive integer on success. On failure, they return a
+    negative errno-style error code.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>The <parameter>message</parameter> parameter is <constant>NULL</constant>.
+          </para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>NULL</constant></term>
+
+          <listitem><para>The <parameter>message</parameter> parameter is <constant>NULL</constant>.
+          </para></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_bus_message_get_signature()</function>,
+    <function>sd_bus_message_is_empty()</function>, and
+    <function>sd_bus_message_has_signature()</function> were added in version 240.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_message_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_bus_message_get_type.xml b/man/sd_bus_message_get_type.xml
new file mode 100644
index 0000000..b2edaa8
--- /dev/null
+++ b/man/sd_bus_message_get_type.xml
@@ -0,0 +1,178 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_bus_message_get_type" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_bus_message_get_type</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_message_get_type</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_message_get_type</refname>
+    <refname>sd_bus_message_get_error</refname>
+    <refname>sd_bus_message_get_errno</refname>
+    <refname>sd_bus_message_get_creds</refname>
+    <refname>sd_bus_message_is_signal</refname>
+    <refname>sd_bus_message_is_method_call</refname>
+    <refname>sd_bus_message_is_method_error</refname>
+
+    <refpurpose>Query bus message addressing/credentials metadata</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_message_get_type</function></funcdef>
+        <paramdef>sd_bus_message *<parameter>m</parameter></paramdef>
+        <paramdef>uint8_t *<parameter>type</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>sd_bus_error* <function>sd_bus_message_get_error</function></funcdef>
+        <paramdef>sd_bus_message *<parameter>m</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_message_get_errno</function></funcdef>
+        <paramdef>sd_bus_message *<parameter>m</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>sd_bus_creds* <function>sd_bus_message_get_creds</function></funcdef>
+        <paramdef>sd_bus_message *<parameter>m</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_message_is_signal</function></funcdef>
+        <paramdef>sd_bus_message *<parameter>m</parameter></paramdef>
+        <paramdef>const char *<parameter>interface</parameter></paramdef>
+        <paramdef>const char *<parameter>member</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_message_is_method_call</function></funcdef>
+        <paramdef>sd_bus_message *<parameter>m</parameter></paramdef>
+        <paramdef>const char *<parameter>interface</parameter></paramdef>
+        <paramdef>const char *<parameter>member</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_message_is_method_error</function></funcdef>
+        <paramdef>sd_bus_message *<parameter>m</parameter></paramdef>
+        <paramdef>const char *<parameter>name</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_bus_message_get_type()</function> returns the type of a message in the output
+    parameter <parameter>type</parameter>, one of <constant>SD_BUS_MESSAGE_METHOD_CALL</constant>,
+    <constant>SD_BUS_MESSAGE_METHOD_RETURN</constant>, <constant>SD_BUS_MESSAGE_METHOD_ERROR</constant>,
+    <constant>SD_BUS_MESSAGE_SIGNAL</constant>. This type is either specified as a parameter when the message
+    is created using
+    <citerefentry><refentrytitle>sd_bus_message_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    or is set automatically when the message is created using
+    <citerefentry><refentrytitle>sd_bus_message_new_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_bus_message_new_method_call</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_bus_message_new_method_error</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    and similar functions.</para>
+
+    <para><function>sd_bus_message_get_error()</function> returns the error stored in the message
+    <parameter>m</parameter>, if there is any. Otherwise, it returns <constant>NULL</constant>.
+    <function>sd_bus_message_get_errno()</function> returns the error stored in the message
+    <parameter>m</parameter> as a positive errno-style value, if there is any. Otherwise, it returns zero.
+    Errors are mapped to errno values according to the default and any additional registered error mappings.
+    See <citerefentry><refentrytitle>sd-bus-errors</refentrytitle><manvolnum>3</manvolnum></citerefentry> and
+    <citerefentry><refentrytitle>sd_bus_error_add_map</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+    </para>
+
+    <para><function>sd_bus_message_get_creds()</function> returns the message credentials attached to the
+    message <parameter>m</parameter>. If no credentials are attached to the message, it returns
+    <constant>NULL</constant>. Ownership of the credentials instance is not transferred to the caller and
+    hence should not be freed.</para>
+
+    <para><function>sd_bus_message_is_signal()</function> checks if message <parameter>m</parameter> is a
+    signal message. If <parameter>interface</parameter> is non-null, it also checks if the message has the
+    same interface set. If <parameter>member</parameter> is non-null, it also checks if the message has the
+    same member set. Also see
+    <citerefentry><refentrytitle>sd_bus_message_new_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+    It returns true when all checks pass.</para>
+
+    <para><function>sd_bus_message_is_method_call()</function> checks if message <parameter>m</parameter>
+    is a method call message. If <parameter>interface</parameter> is non-null, it also checks if the message
+    has the same interface set. If <parameter>member</parameter> is non-null, it also checks if the message
+    has the same member set. Also see
+    <citerefentry><refentrytitle>sd_bus_message_new_method_call</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+    It returns true when all checks pass.</para>
+
+    <para><function>sd_bus_message_is_method_error()</function> checks if message <parameter>m</parameter>
+    is an error reply message. If <parameter>name</parameter> is non-null, it also checks if the message has
+    the same error identifier set. Also see
+    <citerefentry><refentrytitle>sd_bus_message_new_method_error</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+    It returns true when all checks pass.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, these functions (except <function>sd_bus_message_get_error()</function> and
+    <function>sd_bus_message_get_creds()</function>) return a non-negative integer. On failure, they return a
+    negative errno-style error code. <function>sd_bus_message_get_errno()</function> always returns a
+    non-negative integer, even on failure.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>The message parameter <parameter>m</parameter> or an output parameter is
+          <constant>NULL</constant>.</para></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_bus_message_get_type()</function>,
+    <function>sd_bus_message_is_signal()</function>,
+    <function>sd_bus_message_is_method_call()</function>, and
+    <function>sd_bus_message_is_method_error()</function> were added in version 240.</para>
+    <para><function>sd_bus_message_get_error()</function>,
+    <function>sd_bus_message_get_errno()</function>, and
+    <function>sd_bus_message_get_creds()</function> were added in version 246.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_message_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_message_set_destination</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus-errors</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_error_add_map</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_bus_message_new.xml b/man/sd_bus_message_new.xml
new file mode 100644
index 0000000..b9a6b2f
--- /dev/null
+++ b/man/sd_bus_message_new.xml
@@ -0,0 +1,197 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_bus_message_new" xmlns:xi="http://www.w3.org/2001/XInclude">
+  <refentryinfo>
+    <title>sd_bus_message_new</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_message_new</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_message_new</refname>
+    <refname>sd_bus_message_ref</refname>
+    <refname>sd_bus_message_unref</refname>
+    <refname>sd_bus_message_unrefp</refname>
+    <refname>SD_BUS_MESSAGE_METHOD_CALL</refname>
+    <refname>SD_BUS_MESSAGE_METHOD_RETURN</refname>
+    <refname>SD_BUS_MESSAGE_METHOD_ERROR</refname>
+    <refname>SD_BUS_MESSAGE_SIGNAL</refname>
+    <refname>sd_bus_message_get_bus</refname>
+
+    <refpurpose>Create a new bus message object and create or destroy references to it</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <funcsynopsisinfo><token>enum</token> {
+      <constant>SD_BUS_MESSAGE_METHOD_CALL</constant>,
+      <constant>SD_BUS_MESSAGE_METHOD_RETURN</constant>,
+      <constant>SD_BUS_MESSAGE_METHOD_ERROR</constant>,
+      <constant>SD_BUS_MESSAGE_SIGNAL</constant>,
+};</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_message_new</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>sd_bus_message **<parameter>m</parameter></paramdef>
+        <paramdef>uint8_t <parameter>type</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>sd_bus_message *<function>sd_bus_message_ref</function></funcdef>
+        <paramdef>sd_bus_message *<parameter>m</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>sd_bus_message *<function>sd_bus_message_unref</function></funcdef>
+        <paramdef>sd_bus_message *<parameter>m</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>void <function>sd_bus_message_unrefp</function></funcdef>
+        <paramdef>sd_bus_message **<parameter>mp</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>sd_bus *<function>sd_bus_message_get_bus</function></funcdef>
+        <paramdef>sd_bus_message *<parameter>m</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_bus_message_new()</function> creates a new bus message object attached to the
+    bus <parameter>bus</parameter> and returns it in the output parameter <parameter>m</parameter>.
+    This object is reference-counted, and will be destroyed when all references are gone. Initially,
+    the caller of this function owns the sole reference to the message object. Note that the message
+    object holds a reference to the bus object, so the bus object will not be destroyed as long as
+    the message exists.</para>
+
+    <para>Note: this is a low-level call. In most cases functions like
+    <citerefentry><refentrytitle>sd_bus_message_new_method_call</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_bus_message_new_method_error</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_bus_message_new_method_return</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    and <citerefentry><refentrytitle>sd_bus_message_new_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    that create a message of a certain type and initialize various fields are easier to use.</para>
+
+    <para>The <parameter>type</parameter> parameter specifies the type of the message.  It must be
+    one of <constant>SD_BUS_MESSAGE_METHOD_CALL</constant> — a method call,
+    <constant>SD_BUS_MESSAGE_METHOD_RETURN</constant> — a method call reply,
+    <constant>SD_BUS_MESSAGE_METHOD_ERROR</constant> — an error reply to a method call,
+    <constant>SD_BUS_MESSAGE_SIGNAL</constant> — a broadcast message with no reply.
+    </para>
+
+    <para>The flag to allow interactive authorization is initialized based on the current value set
+    in the bus object, see
+    <citerefentry><refentrytitle>sd_bus_set_allow_interactive_authorization</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+    This may be changed using
+    <citerefentry><refentrytitle>sd_bus_message_set_allow_interactive_authorization</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+    </para>
+
+    <para><function>sd_bus_message_ref()</function> increases the internal reference counter of
+    <parameter>m</parameter> by one.</para>
+
+    <para><function>sd_bus_message_unref()</function> decreases the internal reference counter of
+    <parameter>m</parameter> by one. Once the reference count has dropped to zero, message object is
+    destroyed and cannot be used anymore, so further calls to <function>sd_bus_message_ref()</function> or
+    <function>sd_bus_message_unref()</function> are illegal.</para>
+
+    <para><function>sd_bus_message_unrefp()</function> is similar to
+    <function>sd_bus_message_unref()</function> but takes a pointer to a
+    pointer to an <type>sd_bus_message</type> object. This call is useful in
+    conjunction with GCC's and LLVM's <ulink
+    url="https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html">Clean-up
+    Variable Attribute</ulink>. See
+    <citerefentry><refentrytitle>sd_bus_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    for an example how to use the cleanup attribute.</para>
+
+    <para><function>sd_bus_message_ref()</function> and <function>sd_bus_message_unref()</function>
+    execute no operation if the passed in bus message object address is
+    <constant>NULL</constant>. <function>sd_bus_message_unrefp()</function> will first dereference
+    its argument, which must not be <constant>NULL</constant>, and will execute no operation if
+    <emphasis>that</emphasis> is <constant>NULL</constant>.
+    </para>
+
+    <para><function>sd_bus_message_get_bus()</function> returns the bus object that message
+    <parameter>m</parameter> is attached to.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, <function>sd_bus_message_new()</function> returns 0 or a positive integer. On
+    failure, it returns a negative errno-style error code.</para>
+
+    <para><function>sd_bus_message_ref()</function> always returns the argument.
+    </para>
+
+    <para><function>sd_bus_message_unref()</function> always returns
+    <constant>NULL</constant>.</para>
+
+    <para><function>sd_bus_message_get_bus()</function> always returns the bus object.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>Specified <parameter>type</parameter> is invalid.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOTCONN</constant></term>
+
+          <listitem><para>The bus parameter <parameter>bus</parameter> is <constant>NULL</constant> or
+          the bus is not connected.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOMEM</constant></term>
+
+          <listitem><para>Memory allocation failed.</para></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_bus_message_new()</function>,
+    <function>sd_bus_message_ref()</function>,
+    <function>sd_bus_message_unref()</function>,
+    <function>sd_bus_message_unrefp()</function>, and
+    <function>sd_bus_message_get_bus()</function> were added in version 240.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_message_new_method_call</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_message_new_method_error</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_message_new_method_return</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_message_new_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_bus_message_new_method_call.xml b/man/sd_bus_message_new_method_call.xml
new file mode 100644
index 0000000..5a29cb0
--- /dev/null
+++ b/man/sd_bus_message_new_method_call.xml
@@ -0,0 +1,178 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_bus_message_new_method_call"
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_bus_message_new_method_call</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_message_new_method_call</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_message_new_method_call</refname>
+    <refname>sd_bus_message_new_method_return</refname>
+
+    <refpurpose>Create a method call message</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_message_new_method_call</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>sd_bus_message **<parameter>m</parameter></paramdef>
+        <paramdef>const char *<parameter>destination</parameter></paramdef>
+        <paramdef>const char *<parameter>path</parameter></paramdef>
+        <paramdef>const char *<parameter>interface</parameter></paramdef>
+        <paramdef>const char *<parameter>member</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_message_new_method_return</function></funcdef>
+        <paramdef>sd_bus_message *<parameter>call</parameter></paramdef>
+        <paramdef>sd_bus_message **<parameter>m</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>The <function>sd_bus_message_new_method_call()</function> function creates a new bus
+    message object that encapsulates a D-Bus method call, and returns it in the
+    <parameter>m</parameter> output parameter. The call will be made on the destination
+    <parameter>destination</parameter>, path <parameter>path</parameter>, on the interface
+    <parameter>interface</parameter>, member <parameter>member</parameter>.</para>
+
+    <para>Briefly, the <emphasis>destination</emphasis> is a dot-separated name that identifies a
+    service connected to the bus. The <emphasis>path</emphasis> is a slash-separated identifier of
+    an object within the destination that resembles a file system path. The meaning of this path is
+    defined by the destination. The <emphasis>interface</emphasis> is a dot-separated name that
+    resembles a Java interface name that identifies a group of methods and signals supported by the
+    object identified by path. Methods and signals are collectively called
+    <emphasis>members</emphasis> and are identified by a simple name composed of ASCII letters,
+    numbers, and underscores. See the <ulink
+    url="https://dbus.freedesktop.org/doc/dbus-tutorial.html#concepts">D-Bus Tutorial</ulink> for an
+    in-depth explanation.</para>
+
+    <para>The <parameter>destination</parameter> parameter may be <constant>NULL</constant>. The
+    <parameter>interface</parameter> parameter may be <constant>NULL</constant>, if the destination
+    has only a single member with the given name and there is no ambiguity if the interface name is
+    omitted.</para>
+
+    <para>Note that this is a low level interface. See
+    <citerefentry><refentrytitle>sd_bus_call_method</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    for a more convenient way of calling D-Bus methods.</para>
+
+    <para>The <function>sd_bus_message_new_method_return()</function> function creates a new bus
+    message object that is a reply to the method call <parameter>call</parameter> and returns it in
+    the <parameter>m</parameter> output parameter. The <parameter>call</parameter> parameter must be
+    a method call message. The sender of <parameter>call</parameter> is used as the destination.
+    </para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, these functions return a non-negative integer. On failure, they return a
+    negative errno-style error code.</para>
+
+    <refsect2 id='errors'>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>The output parameter <parameter>m</parameter> is
+          <constant>NULL</constant>.</para>
+
+          <para>The <parameter>destination</parameter> parameter is non-null and is not a valid D-Bus
+          service name (<literal>org.somewhere.Something</literal>), the <parameter>path</parameter>
+          parameter is not a valid D-Bus path (<literal>/an/object/path</literal>), the
+          <parameter>interface</parameter> parameter is non-null and is not a valid D-Bus interface
+          name (<literal>an.interface.name</literal>), or the <parameter>member</parameter> parameter
+          is not a valid D-Bus member (<literal>Name</literal>).</para>
+
+          <para>The <parameter>call</parameter> parameter is not a method call object.</para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOTCONN</constant></term>
+
+          <listitem><para>The bus parameter <parameter>bus</parameter> is <constant>NULL</constant> or
+          the bus is not connected.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOMEM</constant></term>
+
+          <listitem><para>Memory allocation failed.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EPERM</constant></term>
+
+          <listitem>
+            <para>The <parameter>call</parameter> parameter is not sealed.</para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EOPNOTSUPP</constant></term>
+
+          <listitem>
+            <para>The <parameter>call</parameter> message does not have a cookie.</para>
+          </listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>Examples</title>
+
+    <example>
+      <title>Make a call to a D-Bus method that takes a single parameter</title>
+
+      <programlisting><xi:include href="print-unit-path.c" parse="text" /></programlisting>
+      <para>This defines a minimally useful program that will open a connection to the bus, create a
+      message object, send it, wait for the reply, and finally extract and print the answer. It does
+      error handling and proper memory management.</para>
+    </example>
+  </refsect1>
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_bus_message_new_method_call()</function> and
+    <function>sd_bus_message_new_method_return()</function> were added in version 246.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_call</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_call_method</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_path_encode</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_bus_message_new_method_error.xml b/man/sd_bus_message_new_method_error.xml
new file mode 100644
index 0000000..92c4ac6
--- /dev/null
+++ b/man/sd_bus_message_new_method_error.xml
@@ -0,0 +1,187 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_bus_message_new_method_error"
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_bus_message_new_method_error</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_message_new_method_error</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_message_new_method_error</refname>
+    <refname>sd_bus_message_new_method_errorf</refname>
+    <refname>sd_bus_message_new_method_errno</refname>
+    <refname>sd_bus_message_new_method_errnof</refname>
+
+    <refpurpose>Create an error reply for a method call</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int sd_bus_message_new_method_error</funcdef>
+        <paramdef>sd_bus_message *<parameter>call</parameter></paramdef>
+        <paramdef>sd_bus_message **<parameter>m</parameter></paramdef>
+        <paramdef>const sd_bus_error *<parameter>e</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int sd_bus_message_new_method_errorf</funcdef>
+        <paramdef>sd_bus_message *<parameter>call</parameter></paramdef>
+        <paramdef>sd_bus_message **<parameter>m</parameter></paramdef>
+        <paramdef>const char *<parameter>name</parameter></paramdef>
+        <paramdef>const char *<parameter>format</parameter></paramdef>
+        <paramdef>…</paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int sd_bus_message_new_method_errno</funcdef>
+        <paramdef>sd_bus_message *<parameter>call</parameter></paramdef>
+        <paramdef>sd_bus_message **<parameter>m</parameter></paramdef>
+        <paramdef>int <parameter>error</parameter></paramdef>
+        <paramdef>const sd_bus_error *<parameter>p</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int sd_bus_message_new_method_errnof</funcdef>
+        <paramdef>sd_bus_message *<parameter>call</parameter></paramdef>
+        <paramdef>sd_bus_message **<parameter>m</parameter></paramdef>
+        <paramdef>int <parameter>error</parameter></paramdef>
+        <paramdef>const char *<parameter>format</parameter></paramdef>
+        <paramdef>…</paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>The <function>sd_bus_message_new_method_error()</function> function creates
+    a new bus message object that is an error reply to the
+    <parameter>call</parameter> message, and returns it in the
+    <parameter>m</parameter> output parameter. The error information from error
+    <parameter>e</parameter> is appended: the <parameter>name</parameter> field of
+    <parameter>e</parameter> is used as the error identifier in the reply header (for
+    example an error name such as
+    <literal>org.freedesktop.DBus.Error.NotSupported</literal> or the equivalent
+    symbolic <constant>SD_BUS_ERROR_NOT_SUPPORTED</constant>), and the
+    <parameter>message</parameter> field is set as the human readable error message
+    string if present. The error <parameter>e</parameter> must have the
+    <parameter>name</parameter> field set, see
+    <citerefentry><refentrytitle>sd_bus_error_is_set</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+    </para>
+
+    <para>The <function>sd_bus_message_new_method_errorf()</function> function
+    creates an error reply similarly to
+    <function>sd_bus_message_new_method_error()</function>, but instead of a ready
+    error structure, it takes an error identifier string <parameter>name</parameter>,
+    plus a <citerefentry
+    project='man-pages'><refentrytitle>printf</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    format string <parameter>format</parameter> and corresponding arguments. An error
+    reply is sent with the error identifier <parameter>name</parameter> and the
+    formatted string as the message. <parameter>name</parameter> and
+    <parameter>format</parameter> must not be <constant>NULL</constant>.
+    </para>
+
+    <para>The <function>sd_bus_message_new_method_errno()</function> function creates
+    an error reply similarly to
+    <function>sd_bus_message_new_method_error()</function>, but in addition to the
+    error structure <parameter>p</parameter>, it takes an
+    <citerefentry project='man-pages'><refentrytitle>errno</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    error value in parameter <parameter>error</parameter>. If the error
+    <parameter>p</parameter> is set (see
+    <citerefentry><refentrytitle>sd_bus_error_is_set</refentrytitle><manvolnum>3</manvolnum></citerefentry>),
+    it is used in the reply. Otherwise, <parameter>error</parameter> is translated to
+    an error identifier and used to create a new error structure using
+    <citerefentry><refentrytitle>sd_bus_error_set_errno</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    and that is used in the reply. (If <parameter>error</parameter> is zero, no error
+    is actually set, and an error reply with no information is created.)</para>
+
+    <para>The <function>sd_bus_message_new_method_errnof()</function> function
+    creates an error reply similarly to
+    <function>sd_bus_message_new_method_error()</function>. It takes an
+    <citerefentry project='man-pages'><refentrytitle>errno</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    error value in parameter <parameter>error</parameter>, plus a <citerefentry
+    project='man-pages'><refentrytitle>printf</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    format string <parameter>format</parameter> and corresponding arguments.
+    <literal>%m</literal> may be used in the format string to refer to the error
+    string corresponding to the specified errno code. The error message is initialized
+    using the error identifier generated from <constant>error</constant> and the
+    formatted string. (If <parameter>error</parameter> is zero, no error is actually
+    set, and an error reply with no information is created.)</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>These functions return 0 if the error reply was successfully created, and a
+    negative errno-style error code otherwise.</para>
+
+    <refsect2 id='errors'>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>The call message <parameter>call</parameter> or the output
+          parameter <parameter>m</parameter> are <constant>NULL</constant>.</para>
+
+          <para>Message <parameter>call</parameter> is not a method call
+          message.</para>
+
+          <para>The error <parameter>e</parameter> parameter to
+          <function>sd_bus_message_new_method_error()</function> is not set, see
+          <citerefentry><refentrytitle>sd_bus_error_is_set</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+          </para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EPERM</constant></term>
+
+          <listitem><para>Message <parameter>call</parameter> has been sealed.
+          </para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOTCONN</constant></term>
+
+          <listitem><para>The bus to which message <parameter>call</parameter> is
+          attached is not connected.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOMEM</constant></term>
+
+          <listitem><para>Memory allocation failed.</para></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_bus_message_new_signal.xml b/man/sd_bus_message_new_signal.xml
new file mode 100644
index 0000000..3f13889
--- /dev/null
+++ b/man/sd_bus_message_new_signal.xml
@@ -0,0 +1,139 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_bus_message_new_signal"
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_bus_message_new_signal</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_message_new_signal</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_message_new_signal</refname>
+    <refname>sd_bus_message_new_signal_to</refname>
+
+    <refpurpose>Create a signal message</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int sd_bus_message_new_signal</funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>sd_bus_message **<parameter>m</parameter></paramdef>
+        <paramdef>const char *<parameter>path</parameter></paramdef>
+        <paramdef>const char *<parameter>interface</parameter></paramdef>
+        <paramdef>const char *<parameter>member</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int sd_bus_message_new_signal_to</funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>sd_bus_message **<parameter>m</parameter></paramdef>
+        <paramdef>const char *<parameter>destination</parameter></paramdef>
+        <paramdef>const char *<parameter>path</parameter></paramdef>
+        <paramdef>const char *<parameter>interface</parameter></paramdef>
+        <paramdef>const char *<parameter>member</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>The <function>sd_bus_message_new_signal()</function> function creates a new bus message
+    object that encapsulates a D-Bus signal, and returns it in the <parameter>m</parameter> output
+    parameter. The signal will be sent to path <parameter>path</parameter>, on the interface
+    <parameter>interface</parameter>, member <parameter>member</parameter>. When this message is
+    sent, no reply is expected. See
+    <citerefentry><refentrytitle>sd_bus_message_new_method_call</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    for a short description of the meaning of the <parameter>path</parameter>,
+    <parameter>interface</parameter>, and <parameter>member</parameter> parameters.
+    </para>
+
+    <para><function>sd_bus_message_new_signal_to()</function> is a shorthand for creating a new bus message
+    to a specific destination. It's behavior is similar to calling
+    <function>sd_bus_message_new_signal()</function> followed by calling
+    <citerefentry><refentrytitle>sd_bus_message_set_destination</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+    </para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>This function returns 0 if the message object was successfully created, and a negative
+    errno-style error code otherwise.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>The output parameter <parameter>m</parameter> is
+          <constant>NULL</constant>.</para>
+
+          <para>The <parameter>path</parameter> parameter is not a valid D-Bus path
+          (<literal>/an/object/path</literal>), the <parameter>interface</parameter> parameter is not
+          a valid D-Bus interface name (<literal>an.interface.name</literal>), or the
+          <parameter>member</parameter> parameter is not a valid D-Bus member
+          (<literal>Name</literal>).</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOTCONN</constant></term>
+
+          <listitem><para>The bus parameter <parameter>bus</parameter> is <constant>NULL</constant> or
+          the bus is not connected.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOMEM</constant></term>
+
+          <listitem><para>Memory allocation failed.</para></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>Examples</title>
+
+    <example>
+      <title>Send a simple signal</title>
+
+      <programlisting><xi:include href="send-unit-files-changed.c" parse="text" /></programlisting>
+
+      <para>This function in systemd sources is used to emit the
+      <literal>UnitFilesChanged</literal> signal when the unit files have been changed.
+      </para>
+    </example>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_emit_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+      <citerefentry><refentrytitle>sd_bus_message_set_destination</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_bus_message_open_container.xml b/man/sd_bus_message_open_container.xml
new file mode 100644
index 0000000..d08382e
--- /dev/null
+++ b/man/sd_bus_message_open_container.xml
@@ -0,0 +1,211 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_bus_message_open_container"
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_bus_message_open_container</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_message_open_container</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_message_open_container</refname>
+    <refname>sd_bus_message_close_container</refname>
+    <refname>sd_bus_message_enter_container</refname>
+    <refname>sd_bus_message_exit_container</refname>
+
+    <refpurpose>Create and move between containers in D-Bus messages</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int sd_bus_message_open_container</funcdef>
+        <paramdef>sd_bus_message *<parameter>m</parameter></paramdef>
+        <paramdef>char <parameter>type</parameter></paramdef>
+        <paramdef>const char *<parameter>contents</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int sd_bus_message_close_container</funcdef>
+        <paramdef>sd_bus_message *<parameter>m</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int sd_bus_message_enter_container</funcdef>
+        <paramdef>sd_bus_message *<parameter>m</parameter></paramdef>
+        <paramdef>char <parameter>type</parameter></paramdef>
+        <paramdef>const char *<parameter>contents</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int sd_bus_message_exit_container</funcdef>
+        <paramdef>sd_bus_message *<parameter>m</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_bus_message_open_container()</function> appends a new container to the message
+    <parameter>m</parameter>. After opening a new container, it can be filled with content using
+    <citerefentry><refentrytitle>sd_bus_message_append</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    and similar functions. Containers behave like a stack. To nest containers inside each other, call
+    <function>sd_bus_message_open_container()</function> multiple times without calling
+    <function>sd_bus_message_close_container()</function> in between. Each container will be nested inside the
+    previous container. <parameter>type</parameter> represents the container type and should be one of
+    <literal>r</literal>, <literal>a</literal>, <literal>v</literal> or <literal>e</literal> as described in
+    <citerefentry><refentrytitle>sd_bus_message_append</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+    Instead of literals, the corresponding constants <constant>SD_BUS_TYPE_STRUCT</constant>,
+    <constant>SD_BUS_TYPE_ARRAY</constant>, <constant>SD_BUS_TYPE_VARIANT</constant> or
+    <constant>SD_BUS_TYPE_DICT_ENTRY</constant> can also be used. <parameter>contents</parameter> describes
+    the type of the container's elements and should be a D-Bus type string following the rules described in
+    <citerefentry><refentrytitle>sd_bus_message_append</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+    </para>
+
+    <para><function>sd_bus_message_close_container()</function> closes the last container opened with
+    <function>sd_bus_message_open_container()</function>. On success, the write pointer of the message
+    <parameter>m</parameter> is positioned after the closed container in its parent container or in
+    <parameter>m</parameter> itself if there is no parent container.</para>
+
+    <para><function>sd_bus_message_enter_container()</function> enters the next container of the message
+    <parameter>m</parameter> for reading. It behaves mostly the same as
+    <function>sd_bus_message_open_container()</function>. Entering a container allows reading its contents
+    with
+    <citerefentry><refentrytitle>sd_bus_message_read</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    and similar functions. <parameter>type</parameter> and <parameter>contents</parameter> are the same as in
+    <function>sd_bus_message_open_container()</function>.</para>
+
+    <para><function>sd_bus_message_exit_container()</function> exits the scope of the last container entered
+    with <function>sd_bus_message_enter_container()</function>. It behaves mostly the same as
+    <function>sd_bus_message_close_container()</function>. Note that
+    <function>sd_bus_message_exit_container()</function> may only be called after iterating through all
+    members of the container, i.e. reading or skipping over them. Use
+    <citerefentry><refentrytitle>sd_bus_message_skip</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    to skip over fields of a container in order to be able to exit the container with
+    <function>sd_bus_message_exit_container()</function> without reading all members.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, these functions return a non-negative integer.
+    <function>sd_bus_message_open_container()</function> and <function>sd_bus_message_close_container()</function>
+    return 0.
+    <function>sd_bus_message_enter_container()</function> returns 1 if it successfully opened a new container, and 0 if
+    that was not possible because the end of the currently open container or message was reached.
+    <function>sd_bus_message_exit_container()</function> returns 1 on success.
+    On failure, all of these functions return a negative errno-style error code.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para><parameter>m</parameter> or <parameter>contents</parameter> are
+          <constant>NULL</constant> or <parameter>type</parameter> is invalid.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EBADMSG</constant></term>
+
+          <listitem><para>Message <parameter>m</parameter> has invalid structure.</para>
+
+          <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENXIO</constant></term>
+
+          <listitem><para>Message <parameter>m</parameter> does not have a container of type
+          <parameter>type</parameter> at the current position, or the contents do not match
+          <parameter>contents</parameter>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EPERM</constant></term>
+
+          <listitem><para>The message <parameter>m</parameter> is already sealed.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ESTALE</constant></term>
+
+          <listitem><para>The message <parameter>m</parameter> is in an invalid state.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOMEM</constant></term>
+
+          <listitem><para>Memory allocation failed.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EBUSY</constant></term>
+
+          <listitem><para><function>sd_bus_message_exit_container()</function> was called but there are
+          unread members left in the container.</para>
+
+          <xi:include href="version-info.xml" xpointer="v247"/></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>Examples</title>
+
+    <example>
+      <title>Append an array of strings to a message</title>
+
+      <programlisting><xi:include href="sd-bus-container-append.c" parse="text" /></programlisting>
+    </example>
+
+    <example>
+      <title>Read an array of strings from a message</title>
+
+      <programlisting><xi:include href="sd-bus-container-read.c" parse="text" /></programlisting>
+    </example>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_message_append</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_message_read</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_message_skip</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <ulink url="https://dbus.freedesktop.org/doc/dbus-specification.html">The D-Bus specification</ulink>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_bus_message_read.xml b/man/sd_bus_message_read.xml
new file mode 100644
index 0000000..65497aa
--- /dev/null
+++ b/man/sd_bus_message_read.xml
@@ -0,0 +1,284 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_bus_message_read"
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_bus_message_read</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_message_read</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_message_read</refname>
+    <refname>sd_bus_message_readv</refname>
+    <refname>sd_bus_message_peek_type</refname>
+
+    <refpurpose>Read a sequence of values from a message</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_message_read</function></funcdef>
+        <paramdef>sd_bus_message *<parameter>m</parameter></paramdef>
+        <paramdef>const char *<parameter>types</parameter></paramdef>
+        <paramdef>...</paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_message_readv</function></funcdef>
+        <paramdef>sd_bus_message *<parameter>m</parameter></paramdef>
+        <paramdef>const char *<parameter>types</parameter></paramdef>
+        <paramdef>va_list <parameter>ap</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_message_peek_type</function></funcdef>
+        <paramdef>sd_bus_message *<parameter>m</parameter></paramdef>
+        <paramdef>char *<parameter>type</parameter></paramdef>
+        <paramdef>const char **<parameter>contents</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_bus_message_read()</function> reads a sequence of fields from the D-Bus message object
+    <parameter>m</parameter> and advances the read position in the message. The type string
+    <parameter>types</parameter> describes the types of items expected in the message and the field arguments
+    that follow. The type string may be <constant>NULL</constant> or empty, in which case nothing is read.
+    </para>
+
+    <para>The type string is composed of the elements described in
+    <citerefentry><refentrytitle>sd_bus_message_append</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    i.e. basic and container types. It must contain zero or more single "complete types". The type string is
+    <constant>NUL</constant>-terminated.</para>
+
+    <para>For each type specified in the type string, one or more arguments need to be specified after the
+    <parameter>types</parameter> parameter, in the same order. The arguments must be pointers to appropriate
+    types (a pointer to <type>int8_t</type> for a <literal>y</literal> in the type string, a pointer to
+    <type>int32_t</type> for an <literal>i</literal>, a pointer to <type>const char*</type> for an
+    <literal>s</literal>, ...)  which are set based on the values in the message. As an exception, in case of
+    array and variant types, the first argument is an "input" argument that further specifies how the message
+    should be read. See the table below for a complete list of allowed arguments and their types. Note that,
+    if the basic type is a pointer (e.g., <type>const char *</type> in the case of a string), the argument is
+    a pointer to a pointer, and also the pointer value that is written is only borrowed and the contents must
+    be copied if they are to be used after the end of the message's lifetime. If the type is
+    <literal>h</literal> (UNIX file descriptor), the descriptor is not duplicated by this call and the
+    returned descriptor remains in possession of the message object, and needs to be duplicated by the caller
+    in order to keep an open reference to it after the message object is freed.</para>
+
+    <para>Each argument may also be <constant>NULL</constant>, in which case the value is read and ignored.
+    </para>
+
+    <table>
+      <title>Item type specifiers</title>
+
+      <tgroup cols='5'>
+        <colspec colname='specifier' />
+        <colspec colname='constant' />
+        <colspec colname='description' />
+        <colspec colname='type1' />
+        <colspec colname='type2' />
+        <thead>
+          <row>
+            <entry>Specifier</entry>
+            <entry>Constant</entry>
+            <entry>Description</entry>
+            <entry>Type of the first argument</entry>
+            <entry>Types of the subsequent arguments, if any</entry>
+          </row>
+        </thead>
+
+        <tbody>
+          <xi:include href="sd_bus_message_read_basic.xml" xpointer="xpointer(//table[@id='format-specifiers']//tbody/*)" />
+
+          <row>
+            <entry><literal>a</literal></entry>
+            <entry><constant>SD_BUS_TYPE_ARRAY</constant></entry>
+            <entry>array</entry>
+            <entry><type>int</type>, which specifies the expected length <parameter>n</parameter> of the array</entry>
+            <entry><parameter>n</parameter> sets of arguments appropriate for the array element type</entry>
+          </row>
+
+          <row>
+            <entry><literal>v</literal></entry>
+            <entry><constant>SD_BUS_TYPE_VARIANT</constant></entry>
+            <entry>variant</entry>
+            <entry>signature string</entry>
+            <entry>arguments appropriate for the types specified by the signature</entry>
+          </row>
+
+          <row>
+            <entry><literal>(</literal></entry>
+            <entry><constant>SD_BUS_TYPE_STRUCT_BEGIN</constant></entry>
+            <entry>array start</entry>
+            <entry morerows="1" namest="type1" nameend="type2">arguments appropriate for the structure elements</entry>
+          </row>
+          <row>
+            <entry><literal>)</literal></entry>
+            <entry><constant>SD_BUS_TYPE_STRUCT_END</constant></entry>
+            <entry>array end</entry>
+          </row>
+
+          <row>
+            <entry><literal>{</literal></entry>
+            <entry><constant>SD_BUS_TYPE_DICT_ENTRY_BEGIN</constant></entry>
+            <entry>dictionary entry start</entry>
+            <entry morerows="1">arguments appropriate for the first type in the pair</entry>
+            <entry morerows="1">arguments appropriate for the second type in the pair</entry>
+            </row>
+          <row>
+            <entry><literal>}</literal></entry>
+            <entry><constant>SD_BUS_TYPE_DICT_ENTRY_END</constant></entry>
+            <entry>dictionary entry end</entry>
+          </row>
+       </tbody>
+      </tgroup>
+    </table>
+
+    <para>If objects of the specified types are not present at the current position in the message, an error
+    is returned.</para>
+
+    <para>The <function>sd_bus_message_readv()</function> is equivalent to the
+    <function>sd_bus_message_read()</function>, except that it is called with a <literal>va_list</literal>
+    instead of a variable number of arguments. This function does not call the <function>va_end()</function>
+    macro. Because it invokes the <function>va_arg()</function> macro, the value of <parameter>ap</parameter>
+    is undefined after the call.</para>
+
+    <para><function>sd_bus_message_peek_type()</function> determines the type of the next element in
+    <parameter>m</parameter> to be read by <function>sd_bus_message_read()</function> or similar functions.
+    On success, the type is stored in <parameter>type</parameter>, if it is not <constant>NULL</constant>.
+    If the type is a container type, the type of its elements is stored in <parameter>contents</parameter>,
+    if it is not <constant>NULL</constant>. If this function successfully determines the type of the next
+    element in <parameter>m</parameter>, it returns a positive integer. If there are no more elements to be
+    read, it returns zero.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, these functions return a non-negative integer. On failure, they return a negative
+    errno-style error code.</para>
+
+    <refsect2 id='errors'>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <xi:include href="sd_bus_message_read_basic.xml" xpointer="errors-einval"/>
+        <xi:include href="sd_bus_message_read_basic.xml" xpointer="errors-enxio"/>
+        <xi:include href="sd_bus_message_read_basic.xml" xpointer="errors-ebadmsg"/>
+        <varlistentry>
+          <term><constant>-EBUSY</constant></term>
+
+          <listitem><para>When reading from a container, this error will be returned if unread elements
+          are left in the container.</para>
+
+          <xi:include href="version-info.xml" xpointer="v251"/></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>Examples</title>
+
+    <para>Read a single basic type (a 64-bit integer):
+    </para>
+
+    <programlisting>sd_bus_message *m;
+int64_t x;
+
+sd_bus_message_read(m, "x", &amp;x);</programlisting>
+
+    <para>Read a boolean value:</para>
+
+    <programlisting>sd_bus_message *m;
+int x; /* Do not use C99 'bool' type here, it's typically smaller
+          in memory and would cause memory corruption */
+
+sd_bus_message_read(m, "b", &amp;x);</programlisting>
+
+    <para>Read all types of integers:</para>
+
+    <programlisting>uint8_t y;
+int16_t n;
+uint16_t q;
+int32_t i;
+uint32_t u;
+int32_t x;
+uint32_t t;
+double d;
+
+sd_bus_message_read(m, "ynqiuxtd", &amp;y, &amp;n, &amp;q, &amp;i, &amp;u, &amp;x, &amp;t, &amp;d);</programlisting>
+
+     <para>Read a structure composed of a string and a D-Bus path:</para>
+
+     <programlisting>const char *s, *p;
+
+sd_bus_message_read(m, "(so)", &amp;s, &amp;p);
+</programlisting>
+
+     <para>Read a variant, with the real type "gt" (signature, unsigned integer):
+     </para>
+
+     <programlisting>const char *s;
+uint64_t *v;
+
+sd_bus_message_read(m, "v", "gt", &amp;s, &amp;v);</programlisting>
+
+     <para>Read a dictionary containing three pairs of type {integer=>string}:
+     </para>
+
+     <programlisting>int i, j, k;
+const char *s, *t, *u;
+
+sd_bus_message_read(m, "a{is}", 3, &amp;i, &amp;s, &amp;j, &amp;t, &amp;k, &amp;u);
+     </programlisting>
+
+     <para>Read a single file descriptor, and duplicate it in order to keep it open after the message is
+     freed.</para>
+
+     <programlisting>sd_bus_message *m;
+int fd, fd_copy;
+
+sd_bus_message_read(m, "h", &amp;fd);
+fd_copy = fcntl(fd, FD_DUPFD_CLOEXEC, 3);</programlisting>
+  </refsect1>
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_bus_message_read()</function> and
+    <function>sd_bus_message_readv()</function> were added in version 240.</para>
+    <para><function>sd_bus_message_peek_type()</function> was added in version 246.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_message_read_basic</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_message_skip</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_message_append</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_message_enter_container</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_bus_message_read_array.xml b/man/sd_bus_message_read_array.xml
new file mode 100644
index 0000000..1feec20
--- /dev/null
+++ b/man/sd_bus_message_read_array.xml
@@ -0,0 +1,121 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_bus_message_read_array">
+
+  <refentryinfo>
+    <title>sd_bus_message_read_array</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_message_read_array</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_message_read_array</refname>
+
+    <refpurpose>Access an array of elements in a message</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_message_read_array</function></funcdef>
+        <paramdef>sd_bus_message *<parameter>m</parameter></paramdef>
+        <paramdef>char <parameter>type</parameter></paramdef>
+        <paramdef>const void **<parameter>ptr</parameter></paramdef>
+        <paramdef>size_t *<parameter>size</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_bus_message_read_array()</function> provides access to an array elements in the
+    bus message <parameter>m</parameter>. The "read pointer" in the message must be right before an array of type
+    <parameter>type</parameter>. As a special case, <parameter>type</parameter> may be
+    <constant>NUL</constant>, in which case any trivial type is acceptable. A pointer to the array data is returned
+    in the parameter <parameter>ptr</parameter> and the size of array data (in bytes) is returned in the
+    parameter <parameter>size</parameter>. If the returned <parameter>size</parameter> parameter is 0, a
+    valid non-null pointer will be returned as <parameter>ptr</parameter>, but it may not be
+    dereferenced. The data is aligned as appropriate for the data type. The data is part of the message — it
+    may not be modified and is valid only as long as the message is referenced. After this function returns,
+    the "read pointer" points at the next element after the array.</para>
+
+    <para>Note that this function only supports arrays of trivial types, i.e. arrays of booleans, the various
+    integer types, as well as floating point numbers. In particular it may not be used for arrays of strings,
+    structures or similar.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>
+      On success and when an array was read, <function>sd_bus_message_read_array()</function> returns an
+      integer greater than zero. If invoked while inside a container element (such as an array, e.g. when
+      operating on an array of arrays) and the final element of the outer container has been read already and
+      the read pointer is thus behind the last element of the outer container this call returns 0 (and the
+      returned pointer will be <constant>NULL</constant> and the size will be 0). On failure, it returns a
+      negative errno-style error code.
+    </para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>Specified type is invalid or not a trivial type (see above), or the message
+          parameter or one of the output parameters are <constant>NULL</constant>.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EOPNOTSUPP</constant></term>
+
+          <listitem><para>The byte order in the message is different than native byte
+          order.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EPERM</constant></term>
+
+          <listitem><para>The message is not sealed.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EBADMSG</constant></term>
+
+          <listitem><para>The message cannot be parsed.</para></listitem>
+        </varlistentry>
+
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_bus_message_read_array()</function> was added in version 240.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_message_read</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_message_read_strv</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_bus_message_read_basic.xml b/man/sd_bus_message_read_basic.xml
new file mode 100644
index 0000000..9619e2b
--- /dev/null
+++ b/man/sd_bus_message_read_basic.xml
@@ -0,0 +1,242 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+
+<!--
+  SPDX-License-Identifier: LGPL-2.1-or-later
+
+  Copyright © 2016 Julian Orth
+-->
+
+<refentry id="sd_bus_message_read_basic">
+
+  <refentryinfo>
+    <title>sd_bus_message_read_basic</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_message_read_basic</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_message_read_basic</refname>
+
+    <refpurpose>Read a basic type from a message</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_message_read_basic</function></funcdef>
+        <paramdef>sd_bus_message *<parameter>m</parameter></paramdef>
+        <paramdef>char <parameter>type</parameter></paramdef>
+        <paramdef>void *<parameter>p</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>
+      <function>sd_bus_message_read_basic()</function> reads a basic type from a
+      message and advances the read position in the message. The set of basic
+      types and their ascii codes passed in <parameter>type</parameter> are
+      described in the <ulink
+        url="https://dbus.freedesktop.org/doc/dbus-specification.html">D-Bus
+        Specification</ulink>.
+    </para>
+
+    <para>
+      If <parameter>p</parameter> is not <constant>NULL</constant>, it should contain a pointer to an
+      appropriate object. For example, if <parameter>type</parameter> is <constant>'y'</constant>, the object
+      passed in <parameter>p</parameter> should have type <type>uint8_t *</type>. If
+      <parameter>type</parameter> is <constant>'s'</constant>, the object passed in <parameter>p</parameter>
+      should have type <type>const char **</type>. Note that, if the basic type is a pointer (e.g.,
+      <type>const char *</type> in the case of a string), the pointer is only borrowed and the contents must
+      be copied if they are to be used after the end of the message's lifetime. Similarly, during the
+      lifetime of such a pointer, the message must not be modified. If <parameter>type</parameter> is
+      <constant>'h'</constant> (UNIX file descriptor), the descriptor is not duplicated by this call and the
+      returned descriptor remains in possession of the message object, and needs to be duplicated by the
+      caller in order to keep an open reference to it after the message object is freed (for example by
+      calling <literal>fcntl(fd, FD_DUPFD_CLOEXEC, 3)</literal>). See the table below for a complete list of
+      allowed types.
+    </para>
+
+    <table id='format-specifiers'>
+      <title>Item type specifiers</title>
+
+      <tgroup cols='4'>
+        <colspec colname='specifier' />
+        <colspec colname='constant' />
+        <colspec colname='description' />
+        <colspec colname='ctype' />
+        <thead>
+          <row>
+            <entry>Specifier</entry>
+            <entry>Constant</entry>
+            <entry>Description</entry>
+            <entry>Expected C Type</entry>
+          </row>
+        </thead>
+        <tbody>
+          <row>
+            <entry><literal>y</literal></entry>
+            <entry><constant>SD_BUS_TYPE_BYTE</constant></entry>
+            <entry>8-bit unsigned integer</entry>
+            <entry><type>uint8_t *</type></entry>
+          </row>
+
+          <row>
+            <entry><literal>b</literal></entry>
+            <entry><constant>SD_BUS_TYPE_BOOLEAN</constant></entry>
+            <entry>boolean</entry>
+            <entry><type>int *</type> (NB: not <type>bool *</type>)</entry>
+          </row>
+
+          <row>
+            <entry><literal>n</literal></entry>
+            <entry><constant>SD_BUS_TYPE_INT16</constant></entry>
+            <entry>16-bit signed integer</entry>
+            <entry><type>int16_t *</type></entry>
+          </row>
+
+          <row>
+            <entry><literal>q</literal></entry>
+            <entry><constant>SD_BUS_TYPE_UINT16</constant></entry>
+            <entry>16-bit unsigned integer</entry>
+            <entry><type>uint16_t *</type></entry>
+          </row>
+
+          <row>
+            <entry><literal>i</literal></entry>
+            <entry><constant>SD_BUS_TYPE_INT32</constant></entry>
+            <entry>32-bit signed integer</entry>
+            <entry><type>int32_t *</type></entry>
+          </row>
+
+          <row>
+            <entry><literal>u</literal></entry>
+            <entry><constant>SD_BUS_TYPE_UINT32</constant></entry>
+            <entry>32-bit unsigned integer</entry>
+            <entry><type>uint32_t *</type></entry>
+          </row>
+
+          <row>
+            <entry><literal>x</literal></entry>
+            <entry><constant>SD_BUS_TYPE_INT64</constant></entry>
+            <entry>64-bit signed integer</entry>
+            <entry><type>int64_t *</type></entry>
+          </row>
+
+          <row>
+            <entry><literal>t</literal></entry>
+            <entry><constant>SD_BUS_TYPE_UINT64</constant></entry>
+            <entry>64-bit unsigned integer</entry>
+            <entry><type>uint64_t *</type></entry>
+          </row>
+
+          <row>
+            <entry><literal>d</literal></entry>
+            <entry><constant>SD_BUS_TYPE_DOUBLE</constant></entry>
+            <entry>IEEE 754 double precision floating-point</entry>
+            <entry><type>double *</type></entry>
+          </row>
+
+          <row>
+            <entry><literal>s</literal></entry>
+            <entry><constant>SD_BUS_TYPE_STRING</constant></entry>
+            <entry>UTF-8 string</entry>
+            <entry><type>const char **</type></entry>
+          </row>
+
+          <row>
+            <entry><literal>o</literal></entry>
+            <entry><constant>SD_BUS_TYPE_OBJECT_PATH</constant></entry>
+            <entry>D-Bus object path string</entry>
+            <entry><type>const char **</type></entry>
+          </row>
+
+          <row>
+            <entry><literal>g</literal></entry>
+            <entry><constant>SD_BUS_TYPE_SIGNATURE</constant></entry>
+            <entry>D-Bus signature string</entry>
+            <entry><type>const char **</type></entry>
+          </row>
+
+          <row>
+            <entry><literal>h</literal></entry>
+            <entry><constant>SD_BUS_TYPE_UNIX_FD</constant></entry>
+            <entry>UNIX file descriptor</entry>
+            <entry><type>int *</type></entry>
+          </row>
+       </tbody>
+      </tgroup>
+    </table>
+
+    <para>
+      If there is no object of the specified type at the current position in the
+      message, an error is returned.
+    </para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>
+      On success, <function>sd_bus_message_read_basic()</function> returns a positive integer.
+      If the end of the currently opened array has been reached, it returns 0.
+      On failure, it returns a negative errno-style error code.
+    </para>
+
+    <refsect2 id='errors'>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry id="errors-einval">
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>Specified type string is invalid or the message parameter is
+          <constant>NULL</constant>.</para></listitem>
+        </varlistentry>
+
+        <varlistentry id="errors-enxio">
+          <term><constant>-ENXIO</constant></term>
+
+          <listitem><para>The message does not contain the specified type at current position.
+          </para></listitem>
+        </varlistentry>
+
+        <varlistentry id="errors-ebadmsg">
+          <term><constant>-EBADMSG</constant></term>
+
+          <listitem><para>The message cannot be parsed.</para></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_bus_message_read_basic()</function> was added in version 231.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_message_append_basic</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_message_skip</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_message_read</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_bus_message_read_strv.xml b/man/sd_bus_message_read_strv.xml
new file mode 100644
index 0000000..6e23f6c
--- /dev/null
+++ b/man/sd_bus_message_read_strv.xml
@@ -0,0 +1,127 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_bus_message_read_strv" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_bus_message_read_strv</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_message_read_strv</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_message_read_strv</refname>
+    <refname>sd_bus_message_read_strv_extend</refname>
+
+    <refpurpose>Access an array of strings in a message</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_message_read_strv</function></funcdef>
+        <paramdef>sd_bus_message *<parameter>m</parameter></paramdef>
+        <paramdef>char ***<parameter>l</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_message_read_strv_extend</function></funcdef>
+        <paramdef>sd_bus_message *<parameter>m</parameter></paramdef>
+        <paramdef>char ***<parameter>l</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_bus_message_read_strv()</function> reads an array of string-like items from the
+    message <parameter>m</parameter>. The "read pointer" in the message must be right before an array of
+    strings (D-Bus type <literal>as</literal>), object paths (D-Bus type <literal>ao</literal>), or
+    signatures (D-Bus type <literal>ag</literal>). On success, a pointer to a
+    <constant>NULL</constant>-terminated array of strings (strv) is returned in the output parameter
+    <parameter>l</parameter>. Note that ownership of this array is transferred to the caller. Hence, the
+    caller is responsible for freeing this array and its contents.</para>
+
+    <para><function>sd_bus_message_read_strv_extend()</function> is similar, but the second parameter is an
+    input-output parameter. If <parameter>*l</parameter> is <constant>NULL</constant>, if behaves identically
+    to <function>sd_bus_message_read_strv()</function>. Otherwise, <parameter>*l</parameter> must point to a
+    strv, which will be reallocated and extended with additional strings. This function is particularly
+    useful when combining multiple lists of strings in a message or messages into a single array of strings.
+    </para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, these functions return a non-negative integer. On failure, they return a negative
+    errno-style error code.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para><parameter>m</parameter> or <parameter>l</parameter> are <constant>NULL</constant>.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EPERM</constant></term>
+
+          <listitem><para>The message is not sealed.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EBADMSG</constant></term>
+
+          <listitem><para>The message cannot be parsed.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENXIO</constant></term>
+
+          <listitem><para>The message "read pointer" is not right before an array of the appropriate type.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v248"/></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_bus_message_read_strv()</function> was added in version 246.</para>
+    <para><function>sd_bus_message_read_strv_extend()</function> was added in version 252.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_message_read</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_bus_message_rewind.xml b/man/sd_bus_message_rewind.xml
new file mode 100644
index 0000000..78f1bbc
--- /dev/null
+++ b/man/sd_bus_message_rewind.xml
@@ -0,0 +1,93 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_bus_message_rewind"
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_bus_message_rewind</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_message_rewind</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_message_rewind</refname>
+
+    <refpurpose>Return to beginning of message or current container</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_message_rewind</function></funcdef>
+        <paramdef>sd_bus_message *<parameter>m</parameter></paramdef>
+        <paramdef>int <parameter>complete</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_bus_message_rewind()</function> moves the "read pointer" in the message
+    <parameter>m</parameter> to either the beginning of the message (if
+    <parameter>complete</parameter> is true) or to the beginning of the currently open container. If
+    no container is open, <parameter>complete</parameter> has no effect.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>
+      On success, this function returns 0 or a positive integer. The value is zero if the current
+      container or whole message in case no container is open is empty, and positive otherwise. On
+      failure, it returns a negative errno-style error code.
+    </para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>The <parameter>m</parameter> parameter is <constant>NULL</constant>.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EPERM</constant></term>
+
+          <listitem><para>The message <parameter>m</parameter> has not been sealed.</para></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_bus_message_rewind()</function> was added in version 240.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_message_read</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_bus_message_seal.xml b/man/sd_bus_message_seal.xml
new file mode 100644
index 0000000..6c4b1f1
--- /dev/null
+++ b/man/sd_bus_message_seal.xml
@@ -0,0 +1,117 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_bus_message_seal"
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_bus_message_seal</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_message_seal</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_message_seal</refname>
+
+    <refpurpose>Prepare a D-Bus message for transmission</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_message_seal</function></funcdef>
+        <paramdef>sd_bus_message *<parameter>m</parameter></paramdef>
+        <paramdef>uint64_t <parameter>cookie</parameter></paramdef>
+        <paramdef>uint64_t <parameter>timeout_usec</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_bus_message_seal()</function> finishes the message <parameter>m</parameter>
+    and prepares it for transmission using
+    <citerefentry><refentrytitle>sd_bus_send</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+    <parameter>cookie</parameter> specifies the identifier used to match the message reply to its
+    corresponding request. <parameter>timeout_usec</parameter> specifies the maximum time in
+    microseconds to wait for a reply to arrive.</para>
+
+    <para>Note that in most scenarios, it's not necessary to call this function directly.
+    <citerefentry><refentrytitle>sd_bus_call</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_bus_call_async</refentrytitle><manvolnum>3</manvolnum></citerefentry> and
+    <citerefentry><refentrytitle>sd_bus_send</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    will seal any given messages if they have not been sealed yet.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, this function returns a non-negative integer. On failure, it returns a
+    negative errno-style error code.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>The <parameter>m</parameter> parameter is <constant>NULL</constant>.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+         <varlistentry>
+          <term><constant>-EBADMSG</constant></term>
+
+          <listitem><para>The D-Bus message <parameter>m</parameter> has open containers.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOMSG</constant></term>
+
+          <listitem><para>The D-Bus message <parameter>m</parameter> is a reply but its type
+          signature does not match the return type signature of its corresponding member in the
+          object vtable.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_bus_message_seal()</function> was added in version 246.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_call</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_call_async</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_send</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_bus_message_sensitive.xml b/man/sd_bus_message_sensitive.xml
new file mode 100644
index 0000000..ff15a4a
--- /dev/null
+++ b/man/sd_bus_message_sensitive.xml
@@ -0,0 +1,92 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_bus_message_sensitive" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_bus_message_sensitive</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_message_sensitive</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_message_sensitive</refname>
+
+    <refpurpose>Mark a message object as containing sensitive data</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_message_sensitive</function></funcdef>
+        <paramdef>sd_bus_message *<parameter>message</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_bus_message_sensitive()</function> marks an allocated bus message as containing
+    sensitive data. This ensures that the message data is carefully removed from memory (specifically,
+    overwritten with zero bytes) when released. It is recommended to mark all incoming and outgoing messages
+    like this that contain security credentials and similar data that should be dealt with carefully. Note
+    that it is not possible to unmark messages like this, it's a one way operation. If a message is already
+    marked sensitive and then marked sensitive a second time the message remains marked so and no further
+    operation is executed.</para>
+
+    <para>As a safety precaution all messages that are created as reply to messages that are marked sensitive
+    are also implicitly marked so.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, this functions return 0 or a positive integer. On failure, it returns a
+    negative errno-style error code.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>The <parameter>message</parameter> parameter is
+          <constant>NULL</constant>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+        </varlistentry>
+
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_bus_message_sensitive()</function> was added in version 245.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_message_new_method_call</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_bus_message_set_destination.xml b/man/sd_bus_message_set_destination.xml
new file mode 100644
index 0000000..d8cff27
--- /dev/null
+++ b/man/sd_bus_message_set_destination.xml
@@ -0,0 +1,162 @@
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_bus_message_set_destination" xmlns:xi="http://www.w3.org/2001/XInclude">
+  <refentryinfo>
+    <title>sd_bus_message_set_destination</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_message_set_destination</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_message_set_destination</refname>
+    <refname>sd_bus_message_get_destination</refname>
+    <refname>sd_bus_message_get_path</refname>
+    <refname>sd_bus_message_get_interface</refname>
+    <refname>sd_bus_message_get_member</refname>
+    <refname>sd_bus_message_set_sender</refname>
+    <refname>sd_bus_message_get_sender</refname>
+
+    <refpurpose>Set and query bus message addressing information</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_message_set_destination</function></funcdef>
+        <paramdef>sd_bus_message *<parameter>message</parameter></paramdef>
+        <paramdef>const char *<parameter>destination</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>const char* <function>sd_bus_message_get_destination</function></funcdef>
+        <paramdef>sd_bus_message *<parameter>message</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>const char* <function>sd_bus_message_get_path</function></funcdef>
+        <paramdef>sd_bus_message *<parameter>message</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>const char* <function>sd_bus_message_get_interface</function></funcdef>
+        <paramdef>sd_bus_message *<parameter>message</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>const char* <function>sd_bus_message_get_member</function></funcdef>
+        <paramdef>sd_bus_message *<parameter>message</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_message_set_sender</function></funcdef>
+        <paramdef>sd_bus_message *<parameter>message</parameter></paramdef>
+        <paramdef>const char *<parameter>sender</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>const char* <function>sd_bus_message_get_sender</function></funcdef>
+        <paramdef>sd_bus_message *<parameter>message</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_bus_message_set_destination()</function> sets the destination service name
+    for the specified bus message object. The specified name must be a valid unique or well-known
+    service name.</para>
+
+    <para><function>sd_bus_message_get_destination()</function>,
+    <function>sd_bus_message_get_path()</function>,
+    <function>sd_bus_message_get_interface()</function>, and
+    <function>sd_bus_message_get_member()</function> return the destination, path, interface, and
+    member fields from <parameter>message</parameter> header. The return value will be
+    <constant>NULL</constant> is <parameter>message</parameter> is <constant>NULL</constant> or the
+    message is of a type that doesn't use those fields or the message doesn't have them set. See
+    <citerefentry><refentrytitle>sd_bus_message_new_method_call</refentrytitle><manvolnum>3</manvolnum></citerefentry> and
+    <citerefentry><refentrytitle>sd_bus_message_set_destination</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    for more discussion of those values.</para>
+
+    <para><function>sd_bus_message_set_sender()</function> sets the sender service name for the specified bus message
+    object. The specified name must be a valid unique or well-known service name. This function is useful only for
+    messages to send on direct connections as for connections to bus brokers the broker will fill in the destination
+    field anyway, and the sender field set by original sender is ignored.</para>
+
+    <para><function>sd_bus_message_get_sender()</function> returns the sender field from
+    <parameter>message</parameter>.</para>
+
+    <para>When a string is returned, it is a pointer to internal storage, and may not be modified or
+    freed. It is only valid as long as the <parameter>message</parameter> remains referenced and
+    this field hasn't been changed by a different call.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, these calls return 0 or a positive integer. On failure, these calls return a
+    negative errno-style error code.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>The <parameter>message</parameter> parameter or the output parameter are
+          <constant>NULL</constant>.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EPERM</constant></term>
+
+          <listitem><para>For <function>sd_bus_message_set_destination()</function> and
+          <function>sd_bus_message_set_sender()</function>, the message is already sealed.</para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EEXIST</constant></term>
+
+          <listitem><para>The message already has a destination or sender field set.</para></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_bus_message_set_destination()</function> and
+    <function>sd_bus_message_set_sender()</function> were added in version 237.</para>
+    <para><function>sd_bus_message_get_destination()</function>,
+    <function>sd_bus_message_get_path()</function>,
+    <function>sd_bus_message_get_interface()</function>,
+    <function>sd_bus_message_get_member()</function>, and
+    <function>sd_bus_message_get_sender()</function> were added in version 240.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_set_sender</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_bus_message_set_expect_reply.xml b/man/sd_bus_message_set_expect_reply.xml
new file mode 100644
index 0000000..674b884
--- /dev/null
+++ b/man/sd_bus_message_set_expect_reply.xml
@@ -0,0 +1,157 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_bus_message_set_expect_reply" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_bus_message_set_expect_reply</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_message_set_expect_reply</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_message_set_expect_reply</refname>
+    <refname>sd_bus_message_get_expect_reply</refname>
+    <refname>sd_bus_message_set_auto_start</refname>
+    <refname>sd_bus_message_get_auto_start</refname>
+    <refname>sd_bus_message_set_allow_interactive_authorization</refname>
+    <refname>sd_bus_message_get_allow_interactive_authorization</refname>
+
+    <refpurpose>Set and query bus message metadata</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_message_set_expect_reply</function></funcdef>
+        <paramdef>sd_bus_message *<parameter>message</parameter></paramdef>
+        <paramdef>int <parameter>b</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_message_get_expect_reply</function></funcdef>
+        <paramdef>sd_bus_message *<parameter>message</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_message_set_auto_start</function></funcdef>
+        <paramdef>sd_bus_message *<parameter>message</parameter></paramdef>
+        <paramdef>int <parameter>b</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_message_get_auto_start</function></funcdef>
+        <paramdef>sd_bus_message *<parameter>message</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_message_set_allow_interactive_authorization</function></funcdef>
+        <paramdef>sd_bus_message *<parameter>message</parameter></paramdef>
+        <paramdef>int <parameter>b</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_message_get_allow_interactive_authorization</function></funcdef>
+        <paramdef>sd_bus_message *<parameter>message</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_bus_message_set_expect_reply()</function> sets or clears the
+    <constant>NO_REPLY_EXPECTED</constant> flag on the message <parameter>m</parameter>. This flag matters
+    only for method call messages and is used to specify that no method return or error reply is expected.
+    It is ignored for other types. Thus, for a method call message, calling
+    <programlisting>sd_bus_message_set_expect_reply(…, 0)</programlisting> sets the flag and suppresses the
+    reply.</para>
+
+    <para><function>sd_bus_message_get_expect_reply()</function> checks if the
+    <constant>NO_REPLY_EXPECTED</constant> flag is set on the message <parameter>m</parameter>. It will
+    return positive if it is not set, and zero if it is.</para>
+
+    <para><function>sd_bus_message_set_auto_start()</function> sets or clears the
+    <constant>NO_AUTO_START</constant> flag on the message <parameter>m</parameter>. When the flag is set,
+    the bus must not launch an owner for the destination name in response to this message. Calling
+    <programlisting>sd_bus_message_set_auto_start(…, 0)</programlisting> sets the flag.</para>
+
+    <para><function>sd_bus_message_get_auto_start()</function> checks if the
+    <constant>NO_AUTO_START</constant> flag is set on the message <parameter>m</parameter>. It will return
+    positive if it is not set, and zero if it is.</para>
+
+    <para><function>sd_bus_message_set_allow_interactive_authorization()</function> sets or clears the
+    <constant>ALLOW_INTERACTIVE_AUTHORIZATION</constant> flag on the message <parameter>m</parameter>.
+    Setting this flag informs the receiver that the caller is prepared to wait for interactive authorization
+    via polkit or a similar framework. Note that setting this flag does not guarantee that the receiver will
+    actually perform interactive authorization. Also, make sure to set a suitable message timeout when using
+    this flag since interactive authorization could potentially take a long time as it depends on user input.
+    If <parameter>b</parameter> is non-zero, the flag is set.</para>
+
+    <para><function>sd_bus_message_get_allow_interactive_authorization()</function> checks if the
+    <constant>ALLOW_INTERACTIVE_AUTHORIZATION</constant> flag is set on the message <parameter>m</parameter>.
+    It will return a positive integer if the flag is set. Otherwise, it returns zero.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, these functions return a non-negative integer. On failure, they return a negative
+    errno-style error code.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>The <parameter>message</parameter> parameter is <constant>NULL</constant>.
+          </para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EPERM</constant></term>
+
+          <listitem>
+          <para>The message <parameter>message</parameter> is sealed when trying to set a flag.</para>
+
+          <para>The message <parameter>message</parameter> has wrong type.</para>
+          </listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_bus_message_set_expect_reply()</function>,
+    <function>sd_bus_message_get_expect_reply()</function>,
+    <function>sd_bus_message_set_auto_start()</function>, and
+    <function>sd_bus_message_get_auto_start()</function> were added in version 240.</para>
+    <para><function>sd_bus_message_set_allow_interactive_authorization()</function> and
+    <function>sd_bus_message_get_allow_interactive_authorization()</function> were added in version 246.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_set_description</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+</refentry>
diff --git a/man/sd_bus_message_skip.xml b/man/sd_bus_message_skip.xml
new file mode 100644
index 0000000..e10c969
--- /dev/null
+++ b/man/sd_bus_message_skip.xml
@@ -0,0 +1,113 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_bus_message_skip" xmlns:xi="http://www.w3.org/2001/XInclude">
+  <refentryinfo>
+    <title>sd_bus_message_skip</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_message_skip</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_message_skip</refname>
+
+    <refpurpose>Skip elements in a bus message</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_message_skip</function></funcdef>
+        <paramdef>sd_bus_message *<parameter>m</parameter></paramdef>
+        <paramdef>const char* <parameter>types</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_bus_message_skip()</function> is somewhat similar to
+    <citerefentry><refentrytitle>sd_bus_message_read</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    but instead of reading the contents of the message, it only moves the "read pointer". Subsequent
+    read operations will read the elements that are after the elements that were skipped.</para>
+
+    <para>The <parameter>types</parameter> argument has the same meaning as in
+    <function>sd_bus_message_read()</function>. It may also be <constant>NULL</constant>, to skip a
+    single element of any type.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, <function>sd_bus_message_skip()</function> returns 0 or a positive integer. On
+    failure, it returns a negative errno-style error code.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>The <parameter>m</parameter> parameter is
+          <constant>NULL</constant>.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EBADMSG</constant></term>
+
+          <listitem><para>The message cannot be parsed.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EPERM</constant></term>
+
+          <listitem><para>The message is not sealed.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENXIO</constant></term>
+
+          <listitem><para>The message end has been reached and the requested elements cannot be read.
+          </para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOMEM</constant></term>
+
+          <listitem><para>Memory allocation failed.</para></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_bus_message_skip()</function> was added in version 240.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_message_read</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_message_read_basic</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_bus_message_verify_type.xml b/man/sd_bus_message_verify_type.xml
new file mode 100644
index 0000000..9f3a347
--- /dev/null
+++ b/man/sd_bus_message_verify_type.xml
@@ -0,0 +1,99 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_bus_message_verify_type" xmlns:xi="http://www.w3.org/2001/XInclude">
+  <refentryinfo>
+    <title>sd_bus_message_verify_type</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_message_verify_type</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_message_verify_type</refname>
+
+    <refpurpose>Check if the message has specified type at the current location</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int sd_bus_message_verify_type</funcdef>
+        <paramdef>sd_bus_message *<parameter>m</parameter></paramdef>
+        <paramdef>char <parameter>type</parameter></paramdef>
+        <paramdef>const char* <parameter>contents</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_bus_message_verify_type()</function> checks if the complete type at the
+    current location in the message <parameter>m</parameter> matches the specified
+    <parameter>type</parameter> and <parameter>contents</parameter>. If non-zero, parameter
+    <parameter>type</parameter> must be one of the types specified in
+    <citerefentry><refentrytitle>sd_bus_message_append</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
+    If non-null, parameter <parameter>contents</parameter> must be a valid sequence of complete
+    types. If both <parameter>type</parameter> and <parameter>contents</parameter> are specified
+    <parameter>type</parameter> must be a container type.</para>
+
+    <para>If <parameter>type</parameter> is specified, the type in the message must match.  If
+    <parameter>contents</parameter> is specified, the type in the message must be a container type
+    with this signature.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, this call returns true if the type matches and zero if not (the message
+    <parameter>m</parameter> contains different data or the end of the message has been reached). On
+    failure, it returns a negative errno-style error code.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para><parameter>m</parameter> or both <parameter>type</parameter> and
+          <parameter>contents</parameter> are <constant>NULL</constant>.</para>
+
+          <para>Arguments do not satisfy other constraints listed above.</para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EPERM</constant></term>
+
+          <listitem><para>Message <parameter>m</parameter> is not sealed.
+          </para></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_message_append</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_bus_negotiate_fds.xml b/man/sd_bus_negotiate_fds.xml
new file mode 100644
index 0000000..d7d3a51
--- /dev/null
+++ b/man/sd_bus_negotiate_fds.xml
@@ -0,0 +1,177 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_bus_negotiate_fds" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_bus_negotiate_fds</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_negotiate_fds</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_negotiate_fds</refname>
+    <refname>sd_bus_negotiate_timestamp</refname>
+    <refname>sd_bus_negotiate_creds</refname>
+    <refname>sd_bus_get_creds_mask</refname>
+
+    <refpurpose>Control feature negotiation on bus connections</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_negotiate_fds</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>int <parameter>b</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_negotiate_timestamp</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>int <parameter>b</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_negotiate_creds</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>int <parameter>b</parameter></paramdef>
+        <paramdef>uint64_t <parameter>mask</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_get_creds_mask</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>uint64_t *<parameter>mask</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_bus_negotiate_fds()</function> controls whether file descriptor passing shall be
+    negotiated for the specified bus connection. It takes a bus object and a boolean, which, when true,
+    enables file descriptor passing, and, when false, disables it. Note that not all transports and servers
+    support file descriptor passing. In particular, networked transports generally do not support file
+    descriptor passing. To find out whether file descriptor passing is available after negotiation, use
+    <citerefentry><refentrytitle>sd_bus_can_send</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    and pass <constant>SD_BUS_TYPE_UNIX_FD</constant>. Note that file descriptor passing is always enabled
+    for both sending and receiving or for neither, but never only in one direction. By default, file
+    descriptor passing is negotiated for all connections.</para>
+
+    <para><function>sd_bus_negotiate_timestamp()</function> controls whether implicit sender timestamps shall
+    be attached automatically to all incoming messages. Takes a bus object and a boolean, which, when true,
+    enables timestamping, and, when false, disables it.  Use
+    <citerefentry><refentrytitle>sd_bus_message_get_monotonic_usec</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_bus_message_get_realtime_usec</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_bus_message_get_seqnum</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    to query the timestamps of incoming messages. If negotiation is disabled or not supported, these calls
+    will fail with <constant>-ENODATA</constant>. Note that currently no transports support timestamping of
+    messages. By default, message timestamping is not negotiated for connections.</para>
+
+    <para><function>sd_bus_negotiate_creds()</function> controls whether and which implicit sender
+    credentials shall be attached automatically to all incoming messages. Takes a bus object and a boolean
+    indicating whether to enable or disable the credential parts encoded in the bit mask value argument. Note
+    that not all transports support attaching sender credentials to messages, or do not support all types of
+    sender credential parameters, or might suppress them under certain circumstances for individual messages.
+    Specifically, dbus1 only supports <constant>SD_BUS_CREDS_UNIQUE_NAME</constant>. The sender credentials
+    are suitable for authorization decisions. By default, only
+    <constant>SD_BUS_CREDS_WELL_KNOWN_NAMES</constant> and <constant>SD_BUS_CREDS_UNIQUE_NAME</constant> are
+    enabled. In fact, these two credential fields are always sent along and cannot be turned off.</para>
+
+    <para><function>sd_bus_get_creds_mask()</function> returns the set of sender credentials that was
+    negotiated to be attached to all incoming messages in <parameter>mask</parameter>. This value is an
+    upper boundary only. Hence, always make sure to explicitly check which credentials are attached to a
+    specific message before using it.</para>
+
+    <para>The <function>sd_bus_negotiate_fds()</function> function may be called only before the connection
+    has been started with
+    <citerefentry><refentrytitle>sd_bus_start</refentrytitle><manvolnum>3</manvolnum></citerefentry>. Both
+    <function>sd_bus_negotiate_timestamp()</function> and <function>sd_bus_negotiate_creds()</function> may
+    also be called after a connection has been set up. Note that, when operating on a connection that is
+    shared between multiple components of the same program (for example via
+    <citerefentry><refentrytitle>sd_bus_default</refentrytitle><manvolnum>3</manvolnum></citerefentry>), it
+    is highly recommended to only enable additional per message metadata fields, but never disable them
+    again, in order not to disable functionality needed by other components.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, these functions return a non-negative integer. On failure, they return a negative
+    errno-style error code.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-EPERM</constant></term>
+
+          <listitem><para>The bus connection has already been started.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>An argument is invalid.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOPKG</constant></term>
+
+          <listitem><para>The bus cannot be resolved.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ECHILD</constant></term>
+
+          <listitem><para>The bus was created in a different process, library or module instance.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_bus_negotiate_fds()</function>,
+    <function>sd_bus_negotiate_timestamp()</function>, and
+    <function>sd_bus_negotiate_creds()</function> were added in version 212.</para>
+    <para><function>sd_bus_get_creds_mask()</function> was added in version 246.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_start</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_can_send</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_message_get_monotonic_usec</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_message_get_realtime_usec</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_message_get_seqnum</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_message_get_creds</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_bus_new.xml b/man/sd_bus_new.xml
new file mode 100644
index 0000000..1e61481
--- /dev/null
+++ b/man/sd_bus_new.xml
@@ -0,0 +1,211 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_bus_new" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_bus_new</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_new</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_new</refname>
+    <refname>sd_bus_ref</refname>
+    <refname>sd_bus_unref</refname>
+    <refname>sd_bus_unrefp</refname>
+    <refname>sd_bus_close_unref</refname>
+    <refname>sd_bus_close_unrefp</refname>
+    <refname>sd_bus_flush_close_unref</refname>
+    <refname>sd_bus_flush_close_unrefp</refname>
+
+    <refpurpose>Create a new bus object and create or destroy references to it</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_new</function></funcdef>
+        <paramdef>sd_bus **<parameter>bus</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>sd_bus *<function>sd_bus_ref</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>sd_bus *<function>sd_bus_unref</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>sd_bus *<function>sd_bus_close_unref</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>sd_bus *<function>sd_bus_flush_close_unref</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>void <function>sd_bus_unrefp</function></funcdef>
+        <paramdef>sd_bus **<parameter>busp</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>void <function>sd_bus_close_unrefp</function></funcdef>
+        <paramdef>sd_bus **<parameter>busp</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>void <function>sd_bus_flush_close_unrefp</function></funcdef>
+        <paramdef>sd_bus **<parameter>busp</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_bus_new()</function> creates a new bus
+    object. This object is reference-counted, and will be destroyed
+    when all references are gone. Initially, the caller of this
+    function owns the sole reference and the bus object will not be
+    connected to any bus. To connect it to a bus, make sure
+    to set an address with
+    <citerefentry><refentrytitle>sd_bus_set_address</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    or a related call, and then start the connection with
+    <citerefentry><refentrytitle>sd_bus_start</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para>
+
+    <para>In most cases, it is better to use
+    <citerefentry><refentrytitle>sd_bus_default_user</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_bus_default_system</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    or related calls instead of the more low-level <function>sd_bus_new()</function> and
+    <function>sd_bus_start()</function>. The higher-level functions not only allocate a bus object but also
+    start the connection to a well-known bus in a single function call.</para>
+
+    <para><function>sd_bus_ref()</function> increases the reference
+    counter of <parameter>bus</parameter> by one.</para>
+
+    <para><function>sd_bus_unref()</function> decreases the reference
+    counter of <parameter>bus</parameter> by one. Once the reference
+    count has dropped to zero, <parameter>bus</parameter> is destroyed
+    and cannot be used anymore, so further calls to
+    <function>sd_bus_ref()</function> or
+    <function>sd_bus_unref()</function> are illegal.</para>
+
+    <para><function>sd_bus_unrefp()</function> is similar to
+    <function>sd_bus_unref()</function> but takes a pointer to a
+    pointer to an <type>sd_bus</type> object. This call is useful in
+    conjunction with GCC's and LLVM's <ulink
+    url="https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html">Clean-up
+    Variable Attribute</ulink>. Note that this function is defined as an
+    inline function. Use a declaration like the following, in order to
+    allocate a bus object that is freed automatically as the code
+    block is left:</para>
+
+    <programlisting>{
+  __attribute__((cleanup(sd_bus_unrefp))) sd_bus *bus = NULL;
+  int r;
+  …
+  r = sd_bus_default(&amp;bus);
+  if (r &lt; 0) {
+    errno = -r;
+    fprintf(stderr, "Failed to allocate bus: %m\n");
+  }
+  …
+}</programlisting>
+
+    <para><function>sd_bus_ref()</function> and <function>sd_bus_unref()</function> execute no operation if
+    the argument is <constant>NULL</constant>. <function>sd_bus_unrefp()</function> will first dereference
+    its argument, which must not be <constant>NULL</constant>, and will execute no operation if
+    <emphasis>that</emphasis> is <constant>NULL</constant>.</para>
+
+    <para><function>sd_bus_close_unref()</function> is similar to <function>sd_bus_unref()</function>, but
+    first executes
+    <citerefentry><refentrytitle>sd_bus_close</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    ensuring that the connection is terminated before the reference to the connection is dropped and possibly
+    the object freed.</para>
+
+    <para><function>sd_bus_flush_close_unref()</function> is similar to <function>sd_bus_unref()</function>,
+    but first executes
+    <citerefentry><refentrytitle>sd_bus_flush</refentrytitle><manvolnum>3</manvolnum></citerefentry> as well
+    as <citerefentry><refentrytitle>sd_bus_close</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    ensuring that any pending messages are synchronously flushed out before the reference to the connection
+    is dropped and possibly the object freed. This call is particularly useful immediately before exiting
+    from a program as it ensures that any pending outgoing messages are written out, and unprocessed but
+    queued incoming messages released before the connection is terminated and released.</para>
+
+    <para><function>sd_bus_close_unrefp()</function> is similar to
+    <function>sd_bus_close_unref()</function>, but may be used in GCC's and LLVM's Clean-up Variable
+    Attribute, see above. Similarly, <function>sd_bus_flush_close_unrefp()</function> is similar to
+    <function>sd_bus_flush_close_unref()</function>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, <function>sd_bus_new()</function> returns 0 or a
+    positive integer. On failure, it returns a negative errno-style
+    error code.</para>
+
+    <para><function>sd_bus_ref()</function> always returns the argument.
+    </para>
+
+    <para><function>sd_bus_unref()</function> and <function>sd_bus_flush_close_unref()</function> always return
+    <constant>NULL</constant>.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-ENOMEM</constant></term>
+
+          <listitem><para>Memory allocation failed.</para></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_bus_new()</function>,
+    <function>sd_bus_ref()</function>, and
+    <function>sd_bus_unref()</function> were added in version 209.</para>
+    <para><function>sd_bus_unrefp()</function> was added in version 229.</para>
+    <para><function>sd_bus_flush_close_unref()</function> and
+    <function>sd_bus_flush_close_unrefp()</function> were added in version 240.</para>
+    <para><function>sd_bus_close_unref()</function> and
+    <function>sd_bus_close_unrefp()</function> were added in version 241.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_default_user</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_default_system</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_open_user</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_open_system</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_close</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_bus_path_encode.xml b/man/sd_bus_path_encode.xml
new file mode 100644
index 0000000..e1b0dfc
--- /dev/null
+++ b/man/sd_bus_path_encode.xml
@@ -0,0 +1,161 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_bus_path_encode" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_bus_path_encode</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_path_encode</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_path_encode</refname>
+    <refname>sd_bus_path_encode_many</refname>
+    <refname>sd_bus_path_decode</refname>
+    <refname>sd_bus_path_decode_many</refname>
+
+    <refpurpose>Convert an external identifier into an object path and back</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_path_encode</function></funcdef>
+        <paramdef>const char *<parameter>prefix</parameter></paramdef>
+        <paramdef>const char *<parameter>external_id</parameter></paramdef>
+        <paramdef>char **<parameter>ret_path</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_path_encode_many</function></funcdef>
+        <paramdef>char **<parameter>out</parameter></paramdef>
+        <paramdef>const char *<parameter>path_template</parameter></paramdef>
+        <paramdef>…</paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_path_decode</function></funcdef>
+        <paramdef>const char *<parameter>path</parameter></paramdef>
+        <paramdef>const char *<parameter>prefix</parameter></paramdef>
+        <paramdef>char **<parameter>ret_external_id</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_path_decode_many</function></funcdef>
+        <paramdef>const char *<parameter>path</parameter></paramdef>
+        <paramdef>const char *<parameter>path_template</parameter></paramdef>
+        <paramdef>…</paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_bus_path_encode()</function> and
+    <function>sd_bus_path_decode()</function> convert external
+    identifier strings into object paths and back. These functions are
+    useful to map application-specific string identifiers of any kind
+    into bus object paths in a simple, reversible and safe way.</para>
+
+    <para><function>sd_bus_path_encode()</function> takes a bus path
+    prefix and an external identifier string as arguments, plus a
+    place to store the returned bus path string. The bus path prefix
+    must be a valid bus path, starting with a slash
+    <literal>/</literal>, and not ending in one. The external
+    identifier string may be in any format, may be the empty string,
+    and has no restrictions on the charset — however, it must
+    always be <constant>NUL</constant>-terminated. The returned string
+    will be the concatenation of the bus path prefix plus an escaped
+    version of the external identifier string. This operation may be
+    reversed with <function>sd_bus_path_decode()</function>. It is
+    recommended to only use external identifiers that generally
+    require little escaping to be turned into valid bus path
+    identifiers (for example, by sticking to a 7-bit ASCII character
+    set), in order to ensure the resulting bus path is still short and
+    easily processed.</para>
+
+    <para><function>sd_bus_path_decode()</function> reverses the
+    operation of <function>sd_bus_path_encode()</function> and thus
+    regenerates an external identifier string from a bus path. It
+    takes a bus path and a prefix string, plus a place to store the
+    returned external identifier string. If the bus path does not
+    start with the specified prefix, 0 is returned and the returned
+    string is set to <constant>NULL</constant>. Otherwise, the
+    string following the prefix is unescaped and returned in the
+    external identifier string.</para>
+
+    <para>The escaping used will replace all characters which are
+    invalid in a bus object path by <literal>_</literal>, followed by a
+    hexadecimal value. As a special case, the empty string will be
+    replaced by a lone <literal>_</literal>.</para>
+
+    <para><function>sd_bus_path_encode_many()</function> works like
+    its counterpart <function>sd_bus_path_encode()</function>, but
+    takes a path template as argument and encodes multiple labels
+    according to its embedded directives. For each
+    <literal>%</literal> character found in the template, the caller
+    must provide a string via varargs, which will be encoded and
+    embedded at the position of the <literal>%</literal> character.
+    Any other character in the template is copied verbatim into the
+    encoded path.</para>
+
+    <para><function>sd_bus_path_decode_many()</function> does the
+    reverse of <function>sd_bus_path_encode_many()</function>. It
+    decodes the passed object path according to the given
+    path template. For each <literal>%</literal> character in the
+    template, the caller must provide an output storage
+    (<literal>char **</literal>) via varargs. The decoded label
+    will be stored there. Each <literal>%</literal> character will
+    only match the current label. It will never match across labels.
+    Furthermore, only a single directive is allowed per label.
+    If <constant>NULL</constant> is passed as output storage, the
+    label is verified but not returned to the caller.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, <function>sd_bus_path_encode()</function>
+    returns positive or 0, and a valid bus path in the return
+    argument. On success, <function>sd_bus_path_decode()</function>
+    returns a positive value if the prefixed matched, or 0 if it
+    did not. If the prefix matched, the external identifier is returned
+    in the return parameter. If it did not match, <constant>NULL</constant> is returned in
+    the return parameter. On failure, a negative errno-style error
+    number is returned by either function. The returned strings must
+    be
+    <citerefentry project='man-pages'><refentrytitle>free</refentrytitle><manvolnum>3</manvolnum></citerefentry>'d
+    by the caller.</para>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_bus_path_encode()</function> and
+    <function>sd_bus_path_decode()</function> were added in version 211.</para>
+    <para><function>sd_bus_path_encode_many()</function> and
+    <function>sd_bus_path_decode_many()</function> were added in version 227.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>free</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_bus_process.xml b/man/sd_bus_process.xml
new file mode 100644
index 0000000..8e142dd
--- /dev/null
+++ b/man/sd_bus_process.xml
@@ -0,0 +1,138 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+
+<!--
+  SPDX-License-Identifier: LGPL-2.1-or-later
+
+  Copyright © 2016 Julian Orth
+-->
+
+<refentry id="sd_bus_process" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_bus_process</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_process</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_process</refname>
+
+    <refpurpose>Drive the connection</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_process</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>sd_bus_message **<parameter>ret</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_bus_process()</function> drives the connection between the client and the message bus.
+    That is, it handles connecting, authentication, and processing of messages. When invoked, pending I/O
+    work is executed, and queued incoming messages are dispatched to registered callbacks. Each time it is
+    invoked a single operation is executed. It returns zero when no operations were pending and positive if a
+    message was processed. When zero is returned the caller should poll for I/O events before calling into
+    <function>sd_bus_process()</function> again. For that either use the simple, blocking
+    <citerefentry><refentrytitle>sd_bus_wait</refentrytitle><manvolnum>3</manvolnum></citerefentry> call, or
+    hook up the bus connection object to an external or manual event loop using
+    <citerefentry><refentrytitle>sd_bus_get_fd</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+    </para>
+
+    <para><function>sd_bus_process()</function> processes at most one incoming message per call.  If the parameter
+    <parameter>ret</parameter> is not <constant>NULL</constant> and the call processed a message,
+    <parameter>*ret</parameter> is set to this message.  The caller owns a reference to this message and should call
+    <citerefentry><refentrytitle>sd_bus_message_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry> when the
+    message is no longer needed. If <parameter>ret</parameter> is not <constant>NULL</constant>, progress was made, but no message was
+    processed, <parameter>*ret</parameter> is set to <constant>NULL</constant>.</para>
+
+    <para>If the bus object is connected to an
+    <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry> event loop (with
+    <citerefentry><refentrytitle>sd_bus_attach_event</refentrytitle><manvolnum>3</manvolnum></citerefentry>), it is not
+    necessary to call <function>sd_bus_process()</function> directly as it is invoked automatically when
+    necessary.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>If progress was made, a positive integer is returned. If no progress was made, 0 is returned. If an
+    error occurs, a negative <varname>errno</varname>-style error code is returned.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>An invalid bus object was passed.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ECHILD</constant></term>
+
+          <listitem><para>The bus connection was allocated in a parent process and is being reused in a child
+          process after <function>fork()</function>.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOTCONN</constant></term>
+
+          <listitem><para>The bus connection has been terminated already.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ECONNRESET</constant></term>
+
+          <listitem><para>The bus connection has been terminated just now.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EBUSY</constant></term>
+
+          <listitem><para>This function is already being called, i.e. <function>sd_bus_process()</function>
+          has been called from a callback function that itself was called by
+          <function>sd_bus_process()</function>.</para></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_bus_process()</function> was added in version 231.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_wait</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_get_fd</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_message_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_attach_event</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_bus_query_sender_creds.xml b/man/sd_bus_query_sender_creds.xml
new file mode 100644
index 0000000..52c1da3
--- /dev/null
+++ b/man/sd_bus_query_sender_creds.xml
@@ -0,0 +1,148 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_bus_query_sender_creds" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_bus_query_sender_creds</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_query_sender_creds</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_query_sender_creds</refname>
+    <refname>sd_bus_query_sender_privilege</refname>
+
+    <refpurpose>Query bus message sender credentials/privileges</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_query_sender_creds</function></funcdef>
+        <paramdef>sd_bus_message *<parameter>m</parameter></paramdef>
+        <paramdef>uint64_t <parameter>mask</parameter></paramdef>
+        <paramdef>sd_bus_creds **<parameter>creds</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>sd_bus_error* <function>sd_bus_query_sender_privilege</function></funcdef>
+        <paramdef>sd_bus_message *<parameter>m</parameter></paramdef>
+        <paramdef>int <parameter>capability</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_bus_query_sender_creds()</function> returns the credentials of the message
+    <parameter>m</parameter>. The <parameter>mask</parameter> parameter is a combo of
+    <constant index='false'>SD_BUS_CREDS_*</constant> flags that indicate which credential info the caller is
+    interested in. See
+    <citerefentry><refentrytitle>sd_bus_creds_new_from_pid</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    for a list of possible flags. First, this message checks if the requested credentials are attached to the
+    message itself. If not, but the message contains the pid of the sender and the caller specified the
+    <constant index='false'>SD_BUS_CREDS_AUGMENT</constant> flag, this function tries to figure out
+    the missing credentials via other means (starting from the pid). If the pid isn't available but the
+    message has a sender, this function calls
+    <citerefentry><refentrytitle>sd_bus_get_name_creds</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    to get the requested credentials. If the message has no sender (when a direct connection is used), this
+    function calls
+    <citerefentry><refentrytitle>sd_bus_get_owner_creds</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    to get the requested credentials. On success, the requested credentials are stored in
+    <parameter>creds</parameter>. Ownership of the credentials object in <parameter>creds</parameter> is
+    transferred to the caller and should be freed by calling
+    <citerefentry><refentrytitle>sd_bus_creds_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+    </para>
+
+    <para><function>sd_bus_query_sender_privilege()</function> checks if the message <parameter>m</parameter>
+    has the requested privileges. If <parameter>capability</parameter> is a non-negative integer, this
+    function checks if the message has the capability with the same value. See
+    <citerefentry project='man-pages'><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+    for a list of capabilities. If <parameter>capability</parameter> is a negative integer, this function
+    returns whether the sender of the message runs as the same user as the receiver of the message, or if the
+    sender of the message runs as root and the receiver of the message does not run as root. On success and
+    if the message has the requested privileges, this function returns a positive integer. If the message
+    does not have the requested privileges, this function returns zero.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, these functions return a non-negative integer. On failure, they return a negative
+    errno-style error code.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>The message <parameter>m</parameter> or an output parameter is
+          <constant>NULL</constant>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOTCONN</constant></term>
+
+          <listitem><para>The bus of <parameter>m</parameter> is not connected.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ECHILD</constant></term>
+
+          <listitem><para>The bus of <parameter>m</parameter> was created in a different process, library or module instance.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EPERM</constant></term>
+
+          <listitem><para>The message <parameter>m</parameter> is not sealed.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_bus_query_sender_creds()</function> and
+    <function>sd_bus_query_sender_privilege()</function> were added in version 246.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_creds_new_from_pid</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_get_name_creds</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_get_owner_creds</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_creds_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+</refentry>
diff --git a/man/sd_bus_reply_method_error.xml b/man/sd_bus_reply_method_error.xml
new file mode 100644
index 0000000..c9553a0
--- /dev/null
+++ b/man/sd_bus_reply_method_error.xml
@@ -0,0 +1,176 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_bus_reply_method_error"
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_bus_reply_method_error</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_reply_method_error</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_reply_method_error</refname>
+    <refname>sd_bus_reply_method_errorf</refname>
+    <refname>sd_bus_reply_method_errorfv</refname>
+    <refname>sd_bus_reply_method_errno</refname>
+    <refname>sd_bus_reply_method_errnof</refname>
+    <refname>sd_bus_reply_method_errnofv</refname>
+
+    <refpurpose>Reply with an error to a D-Bus method call</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int sd_bus_reply_method_error</funcdef>
+        <paramdef>sd_bus_message *<parameter>call</parameter></paramdef>
+        <paramdef>const sd_bus_error *<parameter>e</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int sd_bus_reply_method_errorf</funcdef>
+        <paramdef>sd_bus_message *<parameter>call</parameter></paramdef>
+        <paramdef>const char *<parameter>name</parameter></paramdef>
+        <paramdef>const char *<parameter>format</parameter></paramdef>
+        <paramdef>...</paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int sd_bus_reply_method_errorfv</funcdef>
+        <paramdef>sd_bus_message *<parameter>call</parameter></paramdef>
+        <paramdef>const char *<parameter>name</parameter></paramdef>
+        <paramdef>const char *<parameter>format</parameter></paramdef>
+        <paramdef>va_list <parameter>ap</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int sd_bus_reply_method_errno</funcdef>
+        <paramdef>sd_bus_message *<parameter>call</parameter></paramdef>
+        <paramdef>int <parameter>error</parameter></paramdef>
+        <paramdef>const sd_bus_error *<parameter>p</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int sd_bus_reply_method_errnof</funcdef>
+        <paramdef>sd_bus_message *<parameter>call</parameter></paramdef>
+        <paramdef>int <parameter>error</parameter></paramdef>
+        <paramdef>const char *<parameter>format</parameter></paramdef>
+        <paramdef>...</paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int sd_bus_reply_method_errnofv</funcdef>
+        <paramdef>sd_bus_message *<parameter>call</parameter></paramdef>
+        <paramdef>int <parameter>error</parameter></paramdef>
+        <paramdef>const char *<parameter>format</parameter></paramdef>
+        <paramdef>va_list <parameter>ap</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>The <function>sd_bus_reply_method_error()</function> function sends an error reply to the
+    <parameter>call</parameter> message. The error structure <parameter>e</parameter> specifies the
+    error to send, and is used as described in
+    <citerefentry><refentrytitle>sd_bus_message_new_method_error</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+    If no reply is expected to <parameter>call</parameter>, this function succeeds without sending a
+    reply.</para>
+
+    <para>The <function>sd_bus_reply_method_errorf()</function> is to
+    <function>sd_bus_reply_method_error()</function> what
+    <function>sd_bus_message_new_method_errorf()</function> is to
+    <function>sd_bus_message_new_method_error()</function>.</para>
+
+    <para>The <function>sd_bus_reply_method_errno()</function> is to
+    <function>sd_bus_reply_method_error()</function> what
+    <function>sd_bus_message_new_method_errno()</function> is to
+    <function>sd_bus_message_new_method_error()</function>.</para>
+
+    <para>The <function>sd_bus_reply_method_errnof()</function> is to
+    <function>sd_bus_reply_method_error()</function> what
+    <function>sd_bus_message_new_method_errnof()</function> is to
+    <function>sd_bus_message_new_method_error()</function>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>This function returns a non-negative integer if the error reply was successfully sent or
+    if <parameter>call</parameter> does not expect a reply. On failure, it returns a negative
+    errno-style error code.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>The input parameter <parameter>call</parameter> is
+          <constant>NULL</constant>.</para>
+
+          <para>Message <parameter>call</parameter> is not a method call message.</para>
+
+          <para>Message <parameter>call</parameter> is not attached to a bus.</para>
+
+          <para>The error parameter <parameter>e</parameter> to
+          <function>sd_bus_reply_method_error()</function> is not set, see
+          <citerefentry><refentrytitle>sd_bus_error_is_set</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+          </para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EPERM</constant></term>
+
+          <listitem><para>Message <parameter>call</parameter> has been sealed.
+          </para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOTCONN</constant></term>
+
+          <listitem><para>The bus to which message <parameter>call</parameter> is attached is not
+          connected.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOMEM</constant></term>
+
+          <listitem><para>Memory allocation failed.</para></listitem>
+        </varlistentry>
+      </variablelist>
+
+      <para>In addition, any error returned by
+      <citerefentry><refentrytitle>sd_bus_send</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+      may be returned.</para>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_message_new_method_error</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_bus_reply_method_return.xml b/man/sd_bus_reply_method_return.xml
new file mode 100644
index 0000000..4810413
--- /dev/null
+++ b/man/sd_bus_reply_method_return.xml
@@ -0,0 +1,131 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_bus_reply_method_return"
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_bus_reply_method_return</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_reply_method_return</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_reply_method_return</refname>
+    <refname>sd_bus_reply_method_returnv</refname>
+
+    <refpurpose>Reply to a D-Bus method call</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int sd_bus_reply_method_return</funcdef>
+        <paramdef>sd_bus_message *<parameter>call</parameter></paramdef>
+        <paramdef>const char *<parameter>types</parameter></paramdef>
+        <paramdef>...</paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int sd_bus_reply_method_returnv</funcdef>
+        <paramdef>sd_bus_message *<parameter>call</parameter></paramdef>
+        <paramdef>const char *<parameter>types</parameter></paramdef>
+        <paramdef>va_list <parameter>ap</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_bus_reply_method_return()</function> sends a reply to the
+    <parameter>call</parameter> message. The type string <parameter>types</parameter> and the
+    arguments that follow it must adhere to the format described in
+    <citerefentry><refentrytitle>sd_bus_message_append</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+    If no reply is expected to <parameter>call</parameter>, this function succeeds without sending a
+    reply.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, this function returns a non-negative integer. On failure, it returns a
+    negative errno-style error code.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>The input parameter <parameter>call</parameter> is
+          <constant>NULL</constant>.</para>
+
+          <para>Message <parameter>call</parameter> is not a method call message.
+          </para>
+
+          <para>Message <parameter>call</parameter> is not attached to a bus.</para>
+
+          <para>Message <parameter>m</parameter> is not a method reply message.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EPERM</constant></term>
+
+          <listitem><para>Message <parameter>call</parameter> has been sealed.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOTCONN</constant></term>
+
+          <listitem><para>The bus to which message <parameter>call</parameter> is attached is not
+          connected.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOMEM</constant></term>
+
+          <listitem><para>Memory allocation failed.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+      </variablelist>
+
+      <para>In addition, any error returned by
+      <citerefentry><refentrytitle>sd_bus_send</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+      may be returned.</para>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_message_new_method_return</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_bus_request_name.xml b/man/sd_bus_request_name.xml
new file mode 100644
index 0000000..4fa2e20
--- /dev/null
+++ b/man/sd_bus_request_name.xml
@@ -0,0 +1,224 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_bus_request_name"
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_bus_request_name</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_request_name</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_request_name</refname>
+    <refname>sd_bus_request_name_async</refname>
+    <refname>sd_bus_release_name</refname>
+    <refname>sd_bus_release_name_async</refname>
+    <refpurpose>Request or release a well-known service name on a bus</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <xi:include href="sd_bus_add_match.xml" xpointer="sd_bus_message_handler_t"/>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_request_name</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>const char *<parameter>name</parameter></paramdef>
+        <paramdef>uint64_t <parameter>flags</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_request_name_async</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>sd_bus_slot **<parameter>slot</parameter></paramdef>
+        <paramdef>const char *<parameter>name</parameter></paramdef>
+        <paramdef>uint64_t <parameter>flags</parameter></paramdef>
+        <paramdef>sd_bus_message_handler_t <parameter>callback</parameter></paramdef>
+        <paramdef>void *<parameter>userdata</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_release_name</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>const char *<parameter>name</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_release_name_async</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>sd_bus_slot **<parameter>slot</parameter></paramdef>
+        <paramdef>const char *<parameter>name</parameter></paramdef>
+        <paramdef>sd_bus_message_handler_t <parameter>callback</parameter></paramdef>
+        <paramdef>void *<parameter>userdata</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_bus_request_name()</function> requests a well-known service name on a bus. It takes a
+    bus connection, a valid bus name, and a flags parameter. The flags parameter is a combination of zero or
+    more of the following flags:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><constant>SD_BUS_NAME_ALLOW_REPLACEMENT</constant></term>
+
+        <listitem><para>After acquiring the name successfully, permit other peers to take over the name when they try
+        to acquire it with the <constant>SD_BUS_NAME_REPLACE_EXISTING</constant> flag set. If
+        <constant>SD_BUS_NAME_ALLOW_REPLACEMENT</constant> is not set on the original request, such a request by other
+        peers will be denied.</para>
+
+        <xi:include href="version-info.xml" xpointer="v209"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><constant>SD_BUS_NAME_REPLACE_EXISTING</constant></term>
+
+        <listitem><para>Take over the name if it was already acquired by another peer, and that other peer
+        has permitted takeover by setting <constant>SD_BUS_NAME_ALLOW_REPLACEMENT</constant> while acquiring
+        it.</para>
+
+        <xi:include href="version-info.xml" xpointer="v209"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><constant>SD_BUS_NAME_QUEUE</constant></term>
+
+        <listitem><para>Queue the acquisition of the name when the name is already taken.</para>
+
+        <xi:include href="version-info.xml" xpointer="v209"/></listitem>
+      </varlistentry>
+    </variablelist>
+
+    <para><function>sd_bus_request_name()</function> operates in a synchronous fashion: a message requesting the name
+    is sent to the bus broker, and the call waits until the broker responds.</para>
+
+    <para><function>sd_bus_request_name_async()</function> is an asynchronous version of
+    <function>sd_bus_request_name()</function>. Instead of waiting for the request to complete, the request message is
+    enqueued. The specified <parameter>callback</parameter> will be called when the broker's response is received. If
+    the parameter is specified as <constant>NULL</constant> a default implementation is used instead which will
+    terminate the connection when the name cannot be acquired. The function returns a slot object in its
+    <parameter>slot</parameter> parameter — if it is passed as non-<constant>NULL</constant> — which may be used as a
+    reference to the name request operation. Use
+    <citerefentry><refentrytitle>sd_bus_slot_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry> to destroy
+    this reference. Note that destroying the reference will not unregister the name, but simply ensure the specified
+    callback is no longer called.</para>
+
+    <para><function>sd_bus_release_name()</function> releases an acquired well-known name. It takes a bus connection
+    and a valid bus name as parameters. This function operates synchronously, sending a release request message to the
+    bus broker and waiting for it to reply.</para>
+
+    <para><function>sd_bus_release_name_async()</function> is an asynchronous version of
+    <function>sd_bus_release_name()</function>. The specified <parameter>callback</parameter> function is called when
+    the name has been released successfully. If specified as <constant>NULL</constant> a generic implementation is used
+    that ignores the result of the operation. As above, the <parameter>slot</parameter> (if
+    non-<constant>NULL</constant>) is set to an object that may be used to reference the operation.</para>
+
+    <para>These functions are supported only on bus connections, i.e. connections to a bus broker and not on direct
+    connections.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, these calls return 0 or a positive integer. On failure, these calls return a negative errno-style
+    error code.</para>
+
+    <para>If <constant>SD_BUS_NAME_QUEUE</constant> is specified, <function>sd_bus_request_name()</function> will return
+    0 when the name is already taken by another peer and the client has been added to the queue for the name. In that
+    case, the caller can subscribe to <literal>NameOwnerChanged</literal> signals to be notified when the name is
+    successfully acquired.  <function>sd_bus_request_name()</function> returns &gt; 0 when the name has immediately
+    been acquired successfully.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-EALREADY</constant></term>
+
+          <listitem><para>The caller already is the owner of the specified name.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EEXIST</constant></term>
+
+          <listitem><para>The name has already been acquired by a different peer, and SD_BUS_NAME_REPLACE_EXISTING was
+          not specified or the other peer did not specify SD_BUS_NAME_ALLOW_REPLACEMENT while acquiring the
+          name.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ESRCH</constant></term>
+
+          <listitem><para>It was attempted to release a name that is currently not registered on the
+          bus.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EADDRINUSE</constant></term>
+
+          <listitem><para>It was attempted to release a name that is owned by a different peer on the
+          bus.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>A specified parameter is invalid. This is also generated when the requested name is
+          a special service name reserved by the D-Bus specification, or when the operation is requested on a
+          connection that does not refer to a bus.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOTCONN</constant></term>
+
+          <listitem><para>The bus connection has been disconnected.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ECHILD</constant></term>
+
+          <listitem><para>The bus connection has been created in a different process than the current
+          one.</para></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_bus_request_name()</function> and
+    <function>sd_bus_release_name()</function> were added in version 209.</para>
+    <para><function>sd_bus_request_name_async()</function> and
+    <function>sd_bus_release_name_async()</function> were added in version 237.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_slot_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_bus_send.xml b/man/sd_bus_send.xml
new file mode 100644
index 0000000..0f2f90c
--- /dev/null
+++ b/man/sd_bus_send.xml
@@ -0,0 +1,188 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_bus_send"
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_bus_send</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_send</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_send</refname>
+    <refname>sd_bus_send_to</refname>
+    <refname>sd_bus_message_send</refname>
+
+    <refpurpose>Queue a D-Bus message for transfer</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_send</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>sd_bus_message *<parameter>m</parameter></paramdef>
+        <paramdef>uint64_t *<parameter>cookie</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_send_to</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>sd_bus_message *<parameter>m</parameter></paramdef>
+        <paramdef>const char *<parameter>destination</parameter></paramdef>
+        <paramdef>uint64_t *<parameter>cookie</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int sd_bus_message_send</funcdef>
+        <paramdef>sd_bus_message *<parameter>m</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_bus_send()</function> queues the bus message object <parameter>m</parameter> for
+    transfer. If <parameter>bus</parameter> is <constant>NULL</constant>, the bus that
+    <parameter>m</parameter> is attached to is used. <parameter>bus</parameter> only needs to be set when the
+    message is sent to a different bus than the one it's attached to, for example when forwarding messages.
+    If the output parameter <parameter>cookie</parameter> is not <constant>NULL</constant>, it is set to the
+    message identifier. This value can later be used to match incoming replies to their corresponding
+    messages. If <parameter>cookie</parameter> is set to <constant>NULL</constant> and the message is not
+    sealed, <function>sd_bus_send()</function> assumes the message <parameter>m</parameter> doesn't expect a
+    reply and adds the necessary headers to indicate this.</para>
+
+    <para>Note that in most scenarios, <function>sd_bus_send()</function> should not be called
+    directly. Instead, use higher level functions such as
+    <citerefentry><refentrytitle>sd_bus_call_method</refentrytitle><manvolnum>3</manvolnum></citerefentry> and
+    <citerefentry><refentrytitle>sd_bus_reply_method_return</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    which call <function>sd_bus_send()</function> internally.</para>
+
+    <para><function>sd_bus_send_to()</function> is a shorthand for sending a message to a specific
+    destination. It's main use case is to simplify sending unicast signal messages (signals that only have a
+    single receiver). It's behavior is similar to calling
+    <citerefentry><refentrytitle>sd_bus_message_set_destination</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    followed by calling <function>sd_bus_send()</function>.</para>
+
+    <para><function>sd_bus_send()</function>/<function>sd_bus_send_to()</function> will write the message
+    directly to the underlying transport (e.g. kernel socket buffer) if possible. If the connection is not
+    set up fully yet the message is queued locally. If the transport buffers are congested any unwritten
+    message data is queued locally, too. If the connection has been closed or is currently being closed the
+    call fails.
+    <citerefentry><refentrytitle>sd_bus_process</refentrytitle><manvolnum>3</manvolnum></citerefentry> should
+    be invoked to write out any queued message data to the transport.</para>
+
+    <para><function>sd_bus_message_send()</function> is the same as <function>sd_bus_send()</function> but
+    without the first and last argument. <function>sd_bus_message_send(m)</function> is equivalent to
+    <function>sd_bus_send(sd_bus_message_get_bus(m), m, NULL)</function>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, these functions return a non-negative integer. On failure, they return a negative
+    errno-style error code.</para>
+
+    <refsect2 id='errors'>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>The input parameter <parameter>m</parameter> is <constant>NULL</constant>.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EOPNOTSUPP</constant></term>
+
+          <listitem><para>The bus connection does not support sending file descriptors.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ECHILD</constant></term>
+
+          <listitem><para>The bus connection was allocated in a parent process and is being reused in a child
+          process after <function>fork()</function>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOBUFS</constant></term>
+
+          <listitem><para>The bus connection's write queue is full.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOTCONN</constant></term>
+
+          <listitem><para>The input parameter <parameter>bus</parameter> is
+          <constant>NULL</constant> or the bus is not connected.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ECONNRESET</constant></term>
+
+          <listitem><para>The bus connection was closed while waiting for the response.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOMEM</constant></term>
+
+          <listitem><para>Memory allocation failed.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_bus_send()</function> and
+    <function>sd_bus_send_to()</function> were added in version 246.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_call_method</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_message_set_destination</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_reply_method_return</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_process</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_bus_service_reconnect.c b/man/sd_bus_service_reconnect.c
new file mode 100644
index 0000000..fdb18c3
--- /dev/null
+++ b/man/sd_bus_service_reconnect.c
@@ -0,0 +1,223 @@
+/* SPDX-License-Identifier: MIT-0 */
+
+/* Implements a D-Bus service that automatically reconnects when the system bus is restarted.
+ *
+ * Compile with 'cc sd_bus_service_reconnect.c $(pkg-config --libs --cflags libsystemd)'
+ *
+ * To allow the program to take ownership of the name 'org.freedesktop.ReconnectExample',
+ * add the following as /etc/dbus-1/system.d/org.freedesktop.ReconnectExample.conf
+ * and then reload the broker with 'systemctl reload dbus':
+
+<?xml version="1.0"?> <!--*-nxml-*-->
+<!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"
+        "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
+<busconfig>
+        <policy user="root">
+                <allow own="org.freedesktop.ReconnectExample"/>
+                <allow send_destination="org.freedesktop.ReconnectExample"/>
+                <allow receive_sender="org.freedesktop.ReconnectExample"/>
+        </policy>
+
+        <policy context="default">
+                <allow send_destination="org.freedesktop.ReconnectExample"/>
+                <allow receive_sender="org.freedesktop.ReconnectExample"/>
+        </policy>
+</busconfig>
+
+ *
+ * To get the property via busctl:
+ *
+ * $ busctl --user get-property org.freedesktop.ReconnectExample \
+ *                              /org/freedesktop/ReconnectExample \
+ *                              org.freedesktop.ReconnectExample \
+ *                              Example
+ *   s "example"
+ */
+
+#include <errno.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <systemd/sd-bus.h>
+
+#define _cleanup_(f) __attribute__((cleanup(f)))
+
+#define check(x) ({                             \
+  int _r = (x);                                 \
+  errno = _r < 0 ? -_r : 0;                     \
+  printf(#x ": %m\n");                          \
+  if (_r < 0)                                   \
+    return EXIT_FAILURE;                        \
+  })
+
+typedef struct object {
+  const char *example;
+  sd_bus **bus;
+  sd_event **event;
+} object;
+
+static int property_get(
+                sd_bus *bus,
+                const char *path,
+                const char *interface,
+                const char *property,
+                sd_bus_message *reply,
+                void *userdata,
+                sd_bus_error *error) {
+
+  object *o = userdata;
+
+  if (strcmp(property, "Example") == 0)
+    return sd_bus_message_append(reply, "s", o->example);
+
+  return sd_bus_error_setf(error,
+                           SD_BUS_ERROR_UNKNOWN_PROPERTY,
+                           "Unknown property '%s'",
+                           property);
+}
+
+/* https://www.freedesktop.org/software/systemd/man/sd_bus_add_object.html */
+static const sd_bus_vtable vtable[] = {
+  SD_BUS_VTABLE_START(0),
+  SD_BUS_PROPERTY(
+    "Example", "s",
+    property_get,
+    0,
+    SD_BUS_VTABLE_PROPERTY_CONST),
+  SD_BUS_VTABLE_END
+};
+
+static int setup(object *o);
+
+static int on_disconnect(sd_bus_message *message, void *userdata, sd_bus_error *ret_error) {
+  check(setup((object *)userdata));
+  return 0;
+}
+
+/* Ensure the event loop exits with a clear error if acquiring the well-known service name fails */
+static int request_name_callback(sd_bus_message *m, void *userdata, sd_bus_error *ret_error) {
+  if (!sd_bus_message_is_method_error(m, NULL))
+    return 1;
+
+  const sd_bus_error *error = sd_bus_message_get_error(m);
+
+  if (sd_bus_error_has_names(error, SD_BUS_ERROR_TIMEOUT, SD_BUS_ERROR_NO_REPLY))
+    return 1; /* The bus is not available, try again later */
+
+  printf("Failed to request name: %s\n", error->message);
+  object *o = userdata;
+  check(sd_event_exit(*o->event, -sd_bus_error_get_errno(error)));
+
+  return 1;
+}
+
+static int setup(object *o) {
+  /* If we are reconnecting, then the bus object needs to be closed, detached from
+   * the event loop and recreated.
+   * https://www.freedesktop.org/software/systemd/man/sd_bus_detach_event.html
+   * https://www.freedesktop.org/software/systemd/man/sd_bus_close_unref.html
+   */
+  if (*o->bus) {
+    check(sd_bus_detach_event(*o->bus));
+    *o->bus = sd_bus_close_unref(*o->bus);
+  }
+
+  /* Set up a new bus object for the system bus, configure it to wait for D-Bus to be available
+   * instead of failing if it is not, and start it. All the following operations are asyncronous
+   * and will not block waiting for D-Bus to be available.
+   * https://www.freedesktop.org/software/systemd/man/sd_bus_new.html
+   * https://www.freedesktop.org/software/systemd/man/sd_bus_set_address.html
+   * https://www.freedesktop.org/software/systemd/man/sd_bus_set_bus_client.html
+   * https://www.freedesktop.org/software/systemd/man/sd_bus_negotiate_creds.html
+   * https://www.freedesktop.org/software/systemd/man/sd_bus_set_watch_bind.html
+   * https://www.freedesktop.org/software/systemd/man/sd_bus_set_connected_signal.html
+   * https://www.freedesktop.org/software/systemd/man/sd_bus_start.html
+   */
+  check(sd_bus_new(o->bus));
+  check(sd_bus_set_address(*o->bus, "unix:path=/run/dbus/system_bus_socket"));
+  check(sd_bus_set_bus_client(*o->bus, 1));
+  check(sd_bus_negotiate_creds(*o->bus, 1, SD_BUS_CREDS_UID|SD_BUS_CREDS_EUID|SD_BUS_CREDS_EFFECTIVE_CAPS));
+  check(sd_bus_set_watch_bind(*o->bus, 1));
+  check(sd_bus_start(*o->bus));
+
+  /* Publish an interface on the bus, specifying our well-known object access
+   * path and public interface name.
+   * https://www.freedesktop.org/software/systemd/man/sd_bus_add_object.html
+   * https://dbus.freedesktop.org/doc/dbus-tutorial.html
+   */
+  check(sd_bus_add_object_vtable(*o->bus,
+                                 NULL,
+                                 "/org/freedesktop/ReconnectExample",
+                                 "org.freedesktop.ReconnectExample",
+                                 vtable,
+                                 o));
+  /* By default the service is only assigned an ephemeral name. Also add a well-known
+   * one, so that clients know whom to call. This needs to be asynchronous, as
+   * D-Bus might not be yet available. The callback will check whether the error is
+   * expected or not, in case it fails.
+   * https://www.freedesktop.org/software/systemd/man/sd_bus_request_name.html
+   */
+  check(sd_bus_request_name_async(*o->bus,
+                                  NULL,
+                                  "org.freedesktop.ReconnectExample",
+                                  0,
+                                  request_name_callback,
+                                  o));
+  /* When D-Bus is disconnected this callback will be invoked, which will
+   * set up the connection again. This needs to be asynchronous, as D-Bus might not
+   * yet be available.
+   * https://www.freedesktop.org/software/systemd/man/sd_bus_match_signal_async.html
+   */
+  check(sd_bus_match_signal_async(*o->bus,
+                                  NULL,
+                                  "org.freedesktop.DBus.Local",
+                                  NULL,
+                                  "org.freedesktop.DBus.Local",
+                                  "Disconnected",
+                                  on_disconnect,
+                                  NULL,
+                                  o));
+  /* Attach the bus object to the event loop so that calls and signals are processed.
+   * https://www.freedesktop.org/software/systemd/man/sd_bus_attach_event.html
+   */
+  check(sd_bus_attach_event(*o->bus, *o->event, 0));
+
+  return 0;
+}
+
+int main(int argc, char **argv) {
+  /* The bus should be relinquished before the program terminates. The cleanup
+   * attribute allows us to do it nicely and cleanly whenever we exit the
+   * block.
+   */
+  _cleanup_(sd_bus_flush_close_unrefp) sd_bus *bus = NULL;
+  _cleanup_(sd_event_unrefp) sd_event *event = NULL;
+  object o = {
+    .example = "example",
+    .bus = &bus,
+    .event = &event,
+  };
+
+  /* Create an event loop data structure, with default parameters.
+   * https://www.freedesktop.org/software/systemd/man/sd_event_default.html
+   */
+  check(sd_event_default(&event));
+
+  /* By default the event loop will terminate when all sources have disappeared, so
+   * we have to keep it 'occupied'. Register signal handling to do so.
+   * https://www.freedesktop.org/software/systemd/man/sd_event_add_signal.html
+   */
+  check(sd_event_add_signal(event, NULL, SIGINT|SD_EVENT_SIGNAL_PROCMASK, NULL, NULL));
+  check(sd_event_add_signal(event, NULL, SIGTERM|SD_EVENT_SIGNAL_PROCMASK, NULL, NULL));
+
+  check(setup(&o));
+
+  /* Enter the main loop, it will exit only on sigint/sigterm.
+   * https://www.freedesktop.org/software/systemd/man/sd_event_loop.html
+   */
+  check(sd_event_loop(event));
+
+  /* https://www.freedesktop.org/software/systemd/man/sd_bus_release_name.html */
+  check(sd_bus_release_name(bus, "org.freedesktop.ReconnectExample"));
+
+  return 0;
+}
diff --git a/man/sd_bus_set_address.xml b/man/sd_bus_set_address.xml
new file mode 100644
index 0000000..558349d
--- /dev/null
+++ b/man/sd_bus_set_address.xml
@@ -0,0 +1,205 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_bus_set_address"
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_bus_set_address</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_set_address</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_set_address</refname>
+    <refname>sd_bus_get_address</refname>
+    <refname>sd_bus_set_exec</refname>
+
+    <refpurpose>Set or query the address of the bus connection</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_set_address</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>const char *<parameter>address</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_get_address</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>const char **<parameter>address</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_set_exec</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>const char *<parameter>path</parameter></paramdef>
+        <paramdef>char *const *<parameter>argv</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_bus_set_address()</function> configures a list of addresses of bus brokers to try to
+    connect to from a subsequent
+    <citerefentry><refentrytitle>sd_bus_start</refentrytitle><manvolnum>3</manvolnum></citerefentry> call.
+    The argument is a <literal>;</literal>-separated list of addresses to try. Each item must be one of the
+    following:
+    </para>
+
+    <itemizedlist>
+      <listitem>
+        <para>A unix socket address specified as
+        <literal>unix:guid=<replaceable>guid</replaceable>,path=<replaceable>path</replaceable></literal> or
+        <literal>unix:guid=<replaceable>guid</replaceable>,abstract=<replaceable>path</replaceable></literal>.
+        Exactly one of the <varname>path=</varname> and <varname>abstract=</varname> keys must be present,
+        while <varname>guid=</varname> is optional.</para>
+      </listitem>
+
+      <listitem>
+        <para>A TCP socket address specified as
+        <literal>tcp:[guid=<replaceable>guid</replaceable>,][host=<replaceable>host</replaceable>][,port=<replaceable>port</replaceable>][,family=<replaceable>family</replaceable>]</literal>.
+        One or both of the <varname>host=</varname> and <varname>port=</varname> keys must be present, while
+        the rest is optional. <replaceable>family</replaceable> may be either <option>ipv4</option> or
+        <option>ipv6</option>.</para>
+      </listitem>
+
+      <listitem>
+        <para>An executable to spawn specified as
+        <literal>unixexec:guid=<replaceable>guid</replaceable>,path=<replaceable>path</replaceable>,argv1=<replaceable>argument</replaceable>,argv2=<replaceable>argument</replaceable>,...</literal>.
+        The <varname>path=</varname> key must be present, while <varname>guid=</varname> is optional.</para>
+      </listitem>
+
+      <listitem>
+        <para>A machine (container) to connect to specified as
+        <literal>x-machine-unix:guid=<replaceable>guid</replaceable>,machine=<replaceable>machine</replaceable>,pid=<replaceable>pid</replaceable></literal>.
+        Exactly one of the <varname>machine=</varname> and <varname>pid=</varname> keys must be present,
+        while <varname>guid=</varname> is optional. <parameter>machine</parameter> is the name of a local
+        container. See
+        <citerefentry><refentrytitle>machinectl</refentrytitle><manvolnum>1</manvolnum></citerefentry> for
+        more information about the "machine" concept. <literal>machine=.host</literal> may be used to specify
+        the host machine. A connection to the standard system bus socket inside of the specified machine will
+        be created.</para>
+      </listitem>
+    </itemizedlist>
+
+    <para>In all cases, parameter <parameter>guid</parameter> is an identifier of the remote peer, in the
+    syntax accepted by
+    <citerefentry><refentrytitle>sd_id128_from_string</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+    If specified, the identifier returned by the peer after the connection is established will be checked and
+    the connection will be rejected in case of a mismatch.</para>
+
+    <para>Note that the addresses passed to <function>sd_bus_set_address()</function> may not be verified
+    immediately. If they are invalid, an error may be returned e.g. from a subsequent call to
+    <citerefentry><refentrytitle>sd_bus_start</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+    </para>
+
+    <para><function>sd_bus_get_address()</function> returns any previously set addresses. In addition to
+    being explicitly set by <function>sd_bus_set_address()</function>, the address will also be set
+    automatically by
+    <citerefentry><refentrytitle>sd_bus_open</refentrytitle><manvolnum>3</manvolnum></citerefentry> and
+    similar calls, based on environment variables or built-in defaults.</para>
+
+    <para><function>sd_bus_set_exec()</function> is a shorthand function for setting a
+    <literal>unixexec</literal> address that spawns the given executable with the given arguments.
+    If <parameter>argv</parameter> is <constant>NULL</constant>, the given executable is spawned
+    without any extra arguments.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, these functions return a non-negative integer. On failure, they return a negative
+    errno-style error code.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>The input parameters <parameter>bus</parameter> or <parameter>address</parameter> are <constant>NULL</constant>.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOPKG</constant></term>
+
+          <listitem><para>The bus object <parameter>bus</parameter> could not be resolved.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EPERM</constant></term>
+
+          <listitem><para>The input parameter <parameter>bus</parameter> is in a wrong state
+          (<function>sd_bus_set_address()</function> may only be called once on a newly-created bus object).</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ECHILD</constant></term>
+
+          <listitem><para>The bus object <parameter>bus</parameter> was created in a different
+          process.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENODATA</constant></term>
+
+          <listitem><para>The bus object <parameter>bus</parameter> has no address configured.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+          </listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_bus_set_address()</function>,
+    <function>sd_bus_get_address()</function>, and
+    <function>sd_bus_set_exec()</function> were added in version 246.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_start</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-machined.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>machinectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_bus_set_close_on_exit.xml b/man/sd_bus_set_close_on_exit.xml
new file mode 100644
index 0000000..c467df8
--- /dev/null
+++ b/man/sd_bus_set_close_on_exit.xml
@@ -0,0 +1,114 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_bus_set_close_on_exit"
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_bus_set_close_on_exit</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_set_close_on_exit</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_set_close_on_exit</refname>
+    <refname>sd_bus_get_close_on_exit</refname>
+
+    <refpurpose>Control whether to close the bus connection during the event loop exit phase
+    </refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_set_close_on_exit</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>int <parameter>b</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_get_close_on_exit</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+      </funcprototype>
+
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_bus_set_close_on_exit()</function> may be used to enable or disable whether
+    the bus connection is automatically flushed (as in
+    <citerefentry><refentrytitle>sd_bus_flush</refentrytitle><manvolnum>3</manvolnum></citerefentry>)
+    and closed (as in
+    <citerefentry><refentrytitle>sd_bus_close</refentrytitle><manvolnum>3</manvolnum></citerefentry>)
+    during the exit phase of the event loop. This logic only applies to bus connections that are
+    attached to an
+    <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    event loop, see
+    <citerefentry><refentrytitle>sd_bus_attach_event</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+    By default this mechanism is enabled and makes sure that any pending messages that have not been
+    written to the bus connection are written out when the event loop is shutting down. In some
+    cases this behaviour is not desirable, for example when the bus connection shall remain usable
+    until after the event loop exited. If <parameter>b</parameter> is true, the feature is enabled
+    (which is the default), otherwise disabled.</para>
+
+    <para><function>sd_bus_get_close_on_exit()</function> may be used to query the current setting
+    of this feature. It returns zero when the feature is disabled, and positive if enabled.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, <function>sd_bus_set_close_on_exit()</function> returns a non-negative
+    integer. On failure, it returns a negative errno-style error code.</para>
+
+    <para><function>sd_bus_get_close_on_exit()</function> returns 0 if the feature is currently
+    disabled or a positive integer if it is enabled. On failure, it returns a negative errno-style
+    error code.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-ECHILD</constant></term>
+
+          <listitem><para>The bus connection was created in a different process, library or module instance.</para>
+          </listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_bus_set_close_on_exit()</function> and
+    <function>sd_bus_get_close_on_exit()</function> were added in version 240.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_flush</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_attach_event</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_exit</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+</refentry>
diff --git a/man/sd_bus_set_connected_signal.xml b/man/sd_bus_set_connected_signal.xml
new file mode 100644
index 0000000..c8e5c44
--- /dev/null
+++ b/man/sd_bus_set_connected_signal.xml
@@ -0,0 +1,115 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_bus_set_connected_signal"
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_bus_set_connected_signal</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_set_connected_signal</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_set_connected_signal</refname>
+    <refname>sd_bus_get_connected_signal</refname>
+
+    <refpurpose>Control emission of local connection establishment signal on bus connections</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_set_connected_signal</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>int <parameter>b</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_get_connected_signal</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+      </funcprototype>
+
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_bus_set_connected_signal()</function> may be used to control whether a local, synthetic
+    <function>Connected()</function> signal message shall be generated and enqueued for dispatching when the connection
+    is fully established. If the <parameter>b</parameter> parameter is zero the message is not generated (the default),
+    otherwise it is generated.</para>
+
+    <para><function>sd_bus_get_connected_signal()</function> may be used to query whether this feature is enabled. It
+    returns zero if not, positive otherwise.</para>
+
+    <para>The <function>Connected()</function> signal message is generated from the
+    <literal>org.freedesktop.DBus.Local</literal> service and interface, and
+    <literal>/org/freedesktop/DBus/Local</literal> object path. Use
+    <citerefentry><refentrytitle>sd_bus_match_signal_async</refentrytitle><manvolnum>3</manvolnum></citerefentry> to
+    match on this signal.</para>
+
+    <para>This message is particularly useful on slow transports where connections take a long time to be
+    established. This is especially the case when
+    <citerefentry><refentrytitle>sd_bus_set_watch_bind</refentrytitle><manvolnum>3</manvolnum></citerefentry> is
+    used. The signal is generated when the
+    <citerefentry><refentrytitle>sd_bus_is_ready</refentrytitle><manvolnum>3</manvolnum></citerefentry> returns
+    positive for the first time.</para>
+
+    <para>The <function>Connected()</function> signal corresponds with the <function>Disconnected()</function> signal
+    that is synthesized locally when the connection is terminated. The latter is generated unconditionally however,
+    unlike the former which needs to be enabled explicitly before it is generated, with
+    <function>sd_bus_set_connected_signal()</function>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, these functions return 0 or a positive integer. On failure, they return a negative
+    errno-style error code.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-ECHILD</constant></term>
+
+          <listitem><para>The bus connection has been created in a different process, library or module instance.</para></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_bus_set_connected_signal()</function> and
+    <function>sd_bus_get_connected_signal()</function> were added in version 237.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_match_signal_async</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_set_watch_bind</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_is_ready</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_bus_set_description.xml b/man/sd_bus_set_description.xml
new file mode 100644
index 0000000..0b49ba3
--- /dev/null
+++ b/man/sd_bus_set_description.xml
@@ -0,0 +1,268 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_bus_set_description" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_bus_set_description</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_set_description</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_set_description</refname>
+    <refname>sd_bus_get_description</refname>
+    <refname>sd_bus_set_anonymous</refname>
+    <refname>sd_bus_is_anonymous</refname>
+    <refname>sd_bus_set_trusted</refname>
+    <refname>sd_bus_is_trusted</refname>
+    <refname>sd_bus_set_allow_interactive_authorization</refname>
+    <refname>sd_bus_get_allow_interactive_authorization</refname>
+    <refname>sd_bus_get_scope</refname>
+    <refname>sd_bus_get_tid</refname>
+    <refname>sd_bus_get_unique_name</refname>
+
+    <refpurpose>Set or query properties of a bus object</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_set_description</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>const char *<parameter>description</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_get_description</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>const char **<parameter>description</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_set_anonymous</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>int <parameter>b</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_is_anonymous</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_set_trusted</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>int <parameter>b</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_is_trusted</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_set_allow_interactive_authorization</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>int <parameter>b</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_get_allow_interactive_authorization</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_get_scope</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>const char **<parameter>scope</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_get_tid</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>pid_t *<parameter>tid</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_get_unique_name</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>const char **<parameter>unique</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_bus_set_description()</function> sets the description string that is used in
+    logging to the specified string. The string is copied internally and freed when the bus object
+    is deallocated. The <parameter>description</parameter> argument may be
+    <constant>NULL</constant>, in which case the description is unset. This function must be called
+    before the bus is started.</para>
+
+    <para><function>sd_bus_get_description()</function> returns a description string in
+    <parameter>description</parameter>. This string may have been previously set with
+    <function>sd_bus_set_description()</function> or
+    <citerefentry><refentrytitle>sd_bus_open_with_description</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    or similar. If not set this way, a default string like <literal>system</literal> or
+    <literal>user</literal> will be returned for the system or user buses, and
+    <constant>-ENXIO</constant> otherwise.</para>
+
+    <para><function>sd_bus_set_anonymous()</function> enables or disables "anonymous authentication",
+    i.e. lack of authentication, of the bus peer. This function must be called before the bus is
+    started. See the
+    <ulink url="view-source:https://dbus.freedesktop.org/doc/dbus-specification.html#auth-mechanisms">
+    D-Bus Authentication Mechanisms</ulink> section of the D-Bus specification for details.</para>
+
+    <para><function>sd_bus_is_anonymous()</function> returns true if the bus connection allows
+    anonymous authentication (in the sense described in previous paragraph).</para>
+
+    <para><function>sd_bus_set_trusted()</function> sets the "trusted" state on the
+    <parameter>bus</parameter> object. If true, all connections on the bus are trusted and access to
+    all privileged and unprivileged methods is granted. This function must be called before the bus
+    is started.</para>
+
+    <para><function>sd_bus_is_trusted()</function> returns true if the bus connection is trusted (in
+    the sense described in previous paragraph).</para>
+
+    <para><function>sd_bus_set_allow_interactive_authorization()</function> enables or disables
+    interactive authorization for method calls. If true, messages are marked with the
+    <constant>ALLOW_INTERACTIVE_AUTHORIZATION</constant> flag specified by the
+    <ulink url="view-source:https://dbus.freedesktop.org/doc/dbus-specification.html">D-Bus</ulink>
+    specification, informing the receiving side that the caller is prepared to wait for interactive
+    authorization, which might take a considerable time to complete. If this flag is set, the user
+    may be queried for passwords or confirmation via
+    <ulink url="https://www.freedesktop.org/wiki/Software/polkit">polkit</ulink> or a similar
+    framework.</para>
+
+    <para><function>sd_bus_get_allow_interactive_authorization()</function> returns true if
+    interactive authorization is allowed and false if not.</para>
+
+    <para><function>sd_bus_get_scope()</function> stores the scope of the given bus object in
+    <parameter>scope</parameter>. The scope of the system bus is <literal>system</literal>. The
+    scope of a user session bus is <literal>user</literal>. If the given bus object is not the
+    system or a user session bus, <function>sd_bus_get_scope()</function> returns an error.</para>
+
+    <para><function>sd_bus_get_tid()</function> stores the kernel thread id of the thread associated
+    with the given bus object in <parameter>tid</parameter>. If <parameter>bus</parameter> is a
+    default bus object obtained by calling one of the functions of the
+    <citerefentry><refentrytitle>sd_bus_default</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    family of functions, it stores the thread id of the thread the bus object was created in.
+    Otherwise, if the bus object is attached to an event loop, it stores the thread id of the
+    thread the event loop object was created in. If <parameter>bus</parameter> is not a default bus
+    object and is not attached to an event loop, <function>sd_bus_get_tid()</function> returns an
+    error.</para>
+
+    <para><function>sd_bus_get_unique_name()</function> stores the unique name of the bus object on
+    the bus in <parameter>unique</parameter>. See
+    <ulink url="https://dbus.freedesktop.org/doc/dbus-specification.html#message-protocol-names-bus">
+    The D-Bus specification</ulink> for more information on bus names. Note that the caller does not
+    own the string stored in <parameter>unique</parameter> and should not free it.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, these functions return a non-negative integer. On failure, they return a
+    negative errno-style error code.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>An argument is invalid.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOPKG</constant></term>
+
+          <listitem><para>The bus cannot be resolved.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EPERM</constant></term>
+
+          <listitem><para>The bus has already been started.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ECHILD</constant></term>
+
+          <listitem><para>The bus was created in a different process, library or module instance.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOMEM</constant></term>
+
+          <listitem><para>Memory allocation failed.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENODATA</constant></term>
+
+          <listitem><para>The bus object passed to <function>sd_bus_get_scope()</function> was not a
+          system or user session bus.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENXIO</constant></term>
+
+          <listitem><para>The bus object passed to <function>sd_bus_get_tid()</function> was not a
+          default bus object and is not attached to an event loop.</para>
+
+          <para>The bus object passed to <function>sd_bus_get_description()</function> did
+          not have a <parameter>description</parameter>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_bus_set_description()</function>,
+    <function>sd_bus_get_description()</function>,
+    <function>sd_bus_set_anonymous()</function>,
+    <function>sd_bus_set_trusted()</function>,
+    <function>sd_bus_set_allow_interactive_authorization()</function>, and
+    <function>sd_bus_get_allow_interactive_authorization()</function> were added in version 240.</para>
+    <para><function>sd_bus_is_anonymous()</function>,
+    <function>sd_bus_is_trusted()</function>,
+    <function>sd_bus_get_scope()</function>,
+    <function>sd_bus_get_tid()</function>, and
+    <function>sd_bus_get_unique_name()</function> were added in version 246.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_default_user</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_default_system</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_open_user</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_open_system</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_bus_set_exit_on_disconnect.xml b/man/sd_bus_set_exit_on_disconnect.xml
new file mode 100644
index 0000000..de4105b
--- /dev/null
+++ b/man/sd_bus_set_exit_on_disconnect.xml
@@ -0,0 +1,126 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_bus_set_exit_on_disconnect"
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_bus_set_exit_on_disconnect</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_set_exit_on_disconnect</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_set_exit_on_disconnect</refname>
+    <refname>sd_bus_get_exit_on_disconnect</refname>
+
+    <refpurpose>Control the exit behavior when the bus object disconnects</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_set_exit_on_disconnect</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>int <parameter>b</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_get_exit_on_disconnect</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_bus_set_exit_on_disconnect()</function> may be used to configure the exit
+    behavior when the given bus object disconnects. If <parameter>b</parameter> is zero, no special
+    logic is executed when the bus object disconnects. If <parameter>b</parameter> is non-zero, the
+    behavior on disconnect depends on whether the bus object is attached to an event loop or not. If
+    the bus object is attached to an event loop (see
+    <citerefentry><refentrytitle>sd_bus_attach_event</refentrytitle><manvolnum>3</manvolnum></citerefentry>),
+    the event loop is closed when the bus object disconnects (as if calling
+    <citerefentry><refentrytitle>sd_event_exit</refentrytitle><manvolnum>3</manvolnum></citerefentry>).
+    Otherwise,
+    <citerefentry project='man-pages'><refentrytitle>exit</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    is called. The exit code passed to <function>sd_event_exit()</function> and
+    <function>exit()</function> is <constant>EXIT_FAILURE</constant>. If the bus object has already
+    disconnected when enabling the exit behavior, the exit behavior is executed immediately. By
+    default, the exit behavior is disabled.</para>
+
+    <para><function>sd_bus_get_exit_on_disconnect()</function> returns whether the exit on
+    disconnect behavior is enabled for the given bus object.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, <function>sd_bus_set_exit_on_disconnect()</function> returns a non-negative
+    integer. On failure, it returns a negative errno-style error code.</para>
+
+    <para><function>sd_bus_get_exit_on_disconnect()</function> returns a positive integer if the
+    exit on disconnect behavior is enabled. Otherwise, it returns zero.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>A required parameter was <constant>NULL</constant>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOPKG</constant></term>
+
+          <listitem><para>The bus object could not be resolved.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ECHILD</constant></term>
+
+          <listitem><para>The bus connection was created in a different process, library or module instance.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_bus_set_exit_on_disconnect()</function> and
+    <function>sd_bus_get_exit_on_disconnect()</function> were added in version 246.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_attach_event</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_exit</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+</refentry>
diff --git a/man/sd_bus_set_fd.xml b/man/sd_bus_set_fd.xml
new file mode 100644
index 0000000..d05ed27
--- /dev/null
+++ b/man/sd_bus_set_fd.xml
@@ -0,0 +1,135 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+
+<!--
+  SPDX-License-Identifier: LGPL-2.1-or-later
+
+  Copyright © 2016 Julian Orth
+-->
+
+<refentry id="sd_bus_set_fd" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_bus_set_fd</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_set_fd</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_set_fd</refname>
+
+    <refpurpose>Set the file descriptors to use for bus communication</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_set_fd</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>int <parameter>input_fd</parameter></paramdef>
+        <paramdef>int <parameter>output_fd</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_bus_set_fd()</function> sets the file descriptors used to communicate by a bus
+    connection object. Both <parameter>input_fd</parameter> and <parameter>output_fd</parameter> must be
+    valid file descriptors, referring to stream-based file objects (e.g. a stream socket, a pair of pipes or
+    FIFOs, or even a TTY device). <parameter>input_fd</parameter> must be readable, and
+    <parameter>output_fd</parameter> must be writable. The same file descriptor may be used (and typically is
+    used) as both the input and the output file descriptor. This function must be called before the bus
+    connection is started via
+    <citerefentry><refentrytitle>sd_bus_start</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para>
+
+    <para>The bus connection object will take possession of the passed file descriptors and will close them
+    automatically when it is freed. Use
+    <citerefentry><refentrytitle>sd_bus_set_close_on_exit</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    to turn off this behaviour.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, <function>sd_bus_set_fd()</function> returns a non-negative integer. On
+    failure, it returns a negative errno-style error code.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>An invalid bus object was passed.</para>
+
+          <xi:include href="version-info.xml" xpointer="v248"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ECHILD</constant></term>
+
+          <listitem><para>The bus connection was allocated in a parent process and is being reused
+          in a child process after <function>fork()</function>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v248"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EBADF</constant></term>
+
+          <listitem><para>An invalid file descriptor was passed to
+          <function>sd_bus_set_fd()</function>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v248"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOPKG</constant></term>
+
+          <listitem><para>The bus cannot be resolved.</para>
+
+          <xi:include href="version-info.xml" xpointer="v248"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EPERM</constant></term>
+
+          <listitem><para>The bus connection has already been started.</para>
+
+          <xi:include href="version-info.xml" xpointer="v248"/></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_bus_set_fd()</function> was added in version 248.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_get_fd</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_start</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_bus_set_method_call_timeout.xml b/man/sd_bus_set_method_call_timeout.xml
new file mode 100644
index 0000000..293bbcb
--- /dev/null
+++ b/man/sd_bus_set_method_call_timeout.xml
@@ -0,0 +1,113 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_bus_set_method_call_timeout" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_bus_set_method_call_timeout</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_set_method_call_timeout</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_set_method_call_timeout</refname>
+    <refname>sd_bus_get_method_call_timeout</refname>
+
+    <refpurpose>Set or query the default D-Bus method call timeout of a bus object</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_set_method_call_timeout</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>uint64_t <parameter>usec</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_get_method_call_timeout</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>uint64_t *<parameter>ret</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_bus_set_method_call_timeout()</function> sets the default D-Bus method call
+    timeout of <parameter>bus</parameter> to <parameter>usec</parameter> microseconds.</para>
+
+    <para><function>sd_bus_get_method_call_timeout()</function> queries the default D-Bus method
+    call timeout of <parameter>bus</parameter>. If no method call timeout was set using
+    <function>sd_bus_set_method_call_timeout()</function>, the timeout is read from the
+    <varname>$SYSTEMD_BUS_TIMEOUT</varname> environment variable. If this environment variable is
+    unset or does not contain a valid timeout, the implementation falls back to a predefined method
+    call timeout of 25 seconds. Note that <varname>$SYSTEMD_BUS_TIMEOUT</varname> is read once and
+    cached so callers should not rely on being able to change the default method call timeout at
+    runtime by changing the value of <varname>$SYSTEMD_BUS_TIMEOUT</varname>. Instead, call
+    <function>sd_bus_set_method_call_timeout()</function> to change the default method call timeout.
+    </para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, these functions return a non-negative integer. On failure, they return a
+    negative errno-style error code.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>The parameters <parameter>bus</parameter> or <parameter>ret</parameter>
+          are <constant>NULL</constant>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOPKG</constant></term>
+
+          <listitem><para>Bus object <parameter>bus</parameter> could not be resolved.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+          </listitem>
+        </varlistentry>
+      </variablelist>
+
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_bus_set_method_call_timeout()</function> and
+    <function>sd_bus_get_method_call_timeout()</function> were added in version 246.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_call</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_bus_set_property.xml b/man/sd_bus_set_property.xml
new file mode 100644
index 0000000..2c39874
--- /dev/null
+++ b/man/sd_bus_set_property.xml
@@ -0,0 +1,183 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_bus_set_property"
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_bus_set_property</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_set_property</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_set_property</refname>
+    <refname>sd_bus_set_propertyv</refname>
+    <refname>sd_bus_get_property</refname>
+    <refname>sd_bus_get_property_trivial</refname>
+    <refname>sd_bus_get_property_string</refname>
+    <refname>sd_bus_get_property_strv</refname>
+
+    <refpurpose>Set or query D-Bus service properties</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_set_property</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>const char *<parameter>destination</parameter></paramdef>
+        <paramdef>const char *<parameter>path</parameter></paramdef>
+        <paramdef>const char *<parameter>interface</parameter></paramdef>
+        <paramdef>const char *<parameter>member</parameter></paramdef>
+        <paramdef>sd_bus_error *<parameter>ret_error</parameter></paramdef>
+        <paramdef>const char *<parameter>type</parameter></paramdef>
+        <paramdef>...</paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_set_propertyv</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>const char *<parameter>destination</parameter></paramdef>
+        <paramdef>const char *<parameter>path</parameter></paramdef>
+        <paramdef>const char *<parameter>interface</parameter></paramdef>
+        <paramdef>const char *<parameter>member</parameter></paramdef>
+        <paramdef>sd_bus_error *<parameter>ret_error</parameter></paramdef>
+        <paramdef>const char *<parameter>type</parameter></paramdef>
+        <paramdef>va_list <parameter>ap</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_get_property</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>const char *<parameter>destination</parameter></paramdef>
+        <paramdef>const char *<parameter>path</parameter></paramdef>
+        <paramdef>const char *<parameter>interface</parameter></paramdef>
+        <paramdef>const char *<parameter>member</parameter></paramdef>
+        <paramdef>sd_bus_error *<parameter>ret_error</parameter></paramdef>
+        <paramdef>sd_bus_message **<parameter>reply</parameter></paramdef>
+        <paramdef>const char *<parameter>type</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_get_property_trivial</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>const char *<parameter>destination</parameter></paramdef>
+        <paramdef>const char *<parameter>path</parameter></paramdef>
+        <paramdef>const char *<parameter>interface</parameter></paramdef>
+        <paramdef>const char *<parameter>member</parameter></paramdef>
+        <paramdef>sd_bus_error *<parameter>ret_error</parameter></paramdef>
+        <paramdef>char <parameter>type</parameter></paramdef>
+        <paramdef>void *<parameter>ret_ptr</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_get_property_string</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>const char *<parameter>destination</parameter></paramdef>
+        <paramdef>const char *<parameter>path</parameter></paramdef>
+        <paramdef>const char *<parameter>interface</parameter></paramdef>
+        <paramdef>const char *<parameter>member</parameter></paramdef>
+        <paramdef>sd_bus_error *<parameter>ret_error</parameter></paramdef>
+        <paramdef>char **<parameter>ret</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_get_property_strv</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>const char *<parameter>destination</parameter></paramdef>
+        <paramdef>const char *<parameter>path</parameter></paramdef>
+        <paramdef>const char *<parameter>interface</parameter></paramdef>
+        <paramdef>const char *<parameter>member</parameter></paramdef>
+        <paramdef>sd_bus_error *<parameter>ret_error</parameter></paramdef>
+        <paramdef>char ***<parameter>ret</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>These functions set or query D-Bus properties. D-Bus properties are service fields exposed
+    via the <constant>org.freedesktop.DBus.Properties</constant> interface. Under the hood, these
+    functions call methods of the <constant>org.freedesktop.DBus.Properties</constant> interface and
+    as a result their semantics are similar to
+    <citerefentry><refentrytitle>sd_bus_call_method</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+    </para>
+
+    <para><function>sd_bus_set_property()</function> sets a D-Bus property. If setting the property
+    fails or an internal error occurs, an error is returned and an extended description of the error
+    is optionally stored in <parameter>ret_error</parameter> if it is not <constant>NULL</constant>.
+    <parameter>type</parameter> and the arguments that follow it describe the new value of the
+    property and must follow the format described in
+    <citerefentry><refentrytitle>sd_bus_message_append</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+    </para>
+
+    <para><function>sd_bus_set_propertyv()</function> is equivalent to
+    <function>sd_bus_set_property()</function>, except that it is called with a
+    <literal>va_list</literal> instead of a variable number of arguments.</para>
+
+    <para><function>sd_bus_get_property()</function> queries a D-Bus property. If retrieving the
+    property fails or an internal error occurs, an error is returned and an extended description of
+    the error is optionally stored in <parameter>ret_error</parameter> if it is not
+    <constant>NULL</constant>. On success, the property is stored in <parameter>reply</parameter>.
+    <parameter>type</parameter> describes the property type and must follow the format described in
+    <citerefentry><refentrytitle>sd_bus_message_append</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+    </para>
+
+    <para><function>sd_bus_get_property_trivial()</function>,
+    <function>sd_bus_get_property_string()</function> and
+    <function>sd_bus_get_property_strv()</function> are shorthands for
+    <function>sd_bus_get_property()</function> that are used to query basic, string and string
+    vector properties respectively. The caller is responsible for freeing the string and string
+    vector results stored in <parameter>ret</parameter> by
+    <function>sd_bus_get_property_string()</function> and
+    <function>sd_bus_get_property_strv()</function>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, these functions return a non-negative integer. On failure, they return a
+    negative errno-style error code.</para>
+
+    <refsect2 id='errors'>
+      <title>Errors</title>
+
+      <para>See the
+      <citerefentry><refentrytitle>sd_bus_call_method</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+      man page for a list of possible errors.</para>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_bus_set_property()</function>,
+    <function>sd_bus_set_propertyv()</function>,
+    <function>sd_bus_get_property()</function>,
+    <function>sd_bus_get_property_trivial()</function>,
+    <function>sd_bus_get_property_string()</function>, and
+    <function>sd_bus_get_property_strv()</function> were added in version 246.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_call_method</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_bus_set_sender.xml b/man/sd_bus_set_sender.xml
new file mode 100644
index 0000000..e767df3
--- /dev/null
+++ b/man/sd_bus_set_sender.xml
@@ -0,0 +1,109 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_bus_set_sender"
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_bus_set_sender</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_set_sender</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_set_sender</refname>
+    <refname>sd_bus_get_sender</refname>
+
+    <refpurpose>Configure default sender for outgoing messages</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_set_sender</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>const char* <parameter>name</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_get_sender</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>const char** <parameter>name</parameter></paramdef>
+      </funcprototype>
+
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_bus_set_sender()</function> configures the default sender service name to use for outgoing
+    messages. The service name specified in the <parameter>name</parameter> parameter is set on all outgoing messages
+    that are sent on the connection and have no sender set yet, for example through
+    <citerefentry><refentrytitle>sd_bus_message_set_sender</refentrytitle><manvolnum>3</manvolnum></citerefentry>. Note
+    that this function is only supported on direct connections, i.e. not on connections to a bus broker as the broker
+    will fill in the sender service name automatically anyway. By default no sender name is configured, and hence
+    messages are sent without sender field set. If the <parameter>name</parameter> parameter is specified as
+    <constant>NULL</constant> the default sender service name is cleared, returning to the default state if a default
+    sender service name was set before. If passed as non-<constant>NULL</constant> the specified name must be a valid
+    unique or well-known service name.</para>
+
+    <para><function>sd_bus_get_sender()</function> may be used to query the current default service name for outgoing
+    messages.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, these functions return 0 or a positive integer. On failure, they return a negative
+    errno-style error code.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-ECHILD</constant></term>
+
+          <listitem><para>The bus connection has been created in a different process, library or module instance.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EPERM</constant></term>
+
+          <listitem><para>The specified bus connection object is a not a direct but a brokered
+          connection.</para></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_bus_set_sender()</function> and
+    <function>sd_bus_get_sender()</function> were added in version 237.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_message_set_sender</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_bus_set_server.xml b/man/sd_bus_set_server.xml
new file mode 100644
index 0000000..cfea163
--- /dev/null
+++ b/man/sd_bus_set_server.xml
@@ -0,0 +1,214 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_bus_set_server"
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_bus_set_server</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_set_server</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_set_server</refname>
+    <refname>sd_bus_is_server</refname>
+    <refname>sd_bus_get_bus_id</refname>
+    <refname>sd_bus_set_bus_client</refname>
+    <refname>sd_bus_is_bus_client</refname>
+    <refname>sd_bus_set_monitor</refname>
+    <refname>sd_bus_is_monitor</refname>
+
+    <refpurpose>Configure connection mode for a bus object</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_set_server</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>int <parameter>b</parameter></paramdef>
+        <paramdef>sd_id128_t <parameter>id</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_is_server</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_get_bus_id</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>sd_id128_t *<parameter>id</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_set_bus_client</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>int <parameter>b</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_is_bus_client</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_set_monitor</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>int <parameter>b</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_is_monitor</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_bus_set_server()</function> configures the bus object as a server for direct D-Bus
+    connections. <parameter>b</parameter> enables/disables the server mode. If zero, the server mode is
+    disabled. Otherwise, the server mode is enabled. Configuring a bus object as a server is required to
+    allow establishing direct connections between two peers without going via the D-Bus daemon.
+    <parameter>id</parameter> must contain a 128-bit integer id for the server. If clients add a guid field
+    to their D-Bus address string, the server id must match this guid or the D-Bus authentication handshake
+    will fail. If no specific id is defined for the server,
+    <citerefentry><refentrytitle>sd_id128_randomize</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    can be used to generate a random id instead.</para>
+
+    <para><function>sd_bus_is_server()</function> returns whether the server mode is enabled for the given
+    bus object.</para>
+
+    <para><function>sd_bus_get_bus_id()</function> stores the D-Bus server id configured using
+    <function>sd_bus_set_server()</function> (for server bus objects) or received during D-Bus authentication
+    (for client bus objects) in <parameter>id</parameter>.</para>
+
+    <para><function>sd_bus_set_bus_client()</function> configures the bus object as a D-Bus daemon client.
+    <parameter>b</parameter> enables/disables the client mode. If zero, the client mode is disabled and the
+    bus object should connect directly to a D-Bus server. Otherwise, the client mode is enabled and the bus
+    object should connect to a D-Bus daemon. When connecting to an existing bus using any of the functions in
+    the <citerefentry><refentrytitle>sd_bus_open</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    family of functions or any of the functions in the
+    <citerefentry><refentrytitle>sd_bus_default</refentrytitle><manvolnum>3</manvolnum></citerefentry> family
+    of functions, the bus object is automatically configured as a bus client. However, when connecting to a
+    D-Bus daemon by calling
+    <citerefentry><refentrytitle>sd_bus_set_address</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    followed by
+    <citerefentry><refentrytitle>sd_bus_start</refentrytitle><manvolnum>3</manvolnum></citerefentry>, the bus
+    object should be manually configured as a bus client using <function>sd_bus_set_bus_client()</function>.
+    By default, a bus object is not configured as a D-Bus daemon client.</para>
+
+    <para><function>sd_bus_is_bus_client()</function> returns whether the client mode is enabled/disabled for
+    the given bus object.</para>
+
+    <para><function>sd_bus_set_monitor()</function> configures the bus object as a D-Bus monitor object.
+    <parameter>b</parameter> enables/disables the monitor mode. If zero, the monitor mode is disabled. If
+    non-zero, the monitor mode is enabled. When the monitor mode is enabled, no messages may be sent via the
+    bus object and it may not expose any objects on the bus. To start monitoring messages, call the
+    <function>org.freedesktop.DBus.Monitoring.BecomeMonitor</function> method of the D-Bus daemon and pass
+    a list of matches indicating which messages to intercept. See
+    <ulink url="https://dbus.freedesktop.org/doc/dbus-specification.html#bus-messages-become-monitor">
+    The D-Bus specification</ulink> for more information.</para>
+
+    <para><function>sd_bus_is_monitor()</function> returns whether the monitor mode is enabled/disabled for
+    the given bus object.</para>
+
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, <function>sd_bus_set_server()</function>,
+    <function>sd_bus_get_bus_id()</function>, <function>sd_bus_set_bus_client()</function> and
+    <function>sd_bus_set_monitor()</function> return a non-negative integer. On failure, they return a
+    negative errno-style error code.</para>
+
+    <para><function>sd_bus_is_server()</function>, <function>sd_bus_is_bus_client()</function> and
+    <function>sd_bus_is_monitor()</function> return a positive integer when the server or client mode is
+    enabled, respectively. Otherwise, they return zero.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-ECHILD</constant></term>
+
+          <listitem><para>The bus connection has been created in a different process, library or module instance.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EPERM</constant></term>
+
+          <listitem><para>The bus connection has already been started.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+         <varlistentry>
+          <term><constant>-ENOPKG</constant></term>
+
+          <listitem><para>The bus cannot be resolved.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>A required parameter was <constant>NULL</constant> or
+          <parameter>b</parameter> was zero and <parameter>id</parameter> did not equal
+          <constant>SD_ID128_NULL</constant>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOTCONN</constant></term>
+
+          <listitem><para>The bus is not connected.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_bus_set_server()</function>,
+    <function>sd_bus_is_server()</function>,
+    <function>sd_bus_get_bus_id()</function>,
+    <function>sd_bus_set_bus_client()</function>,
+    <function>sd_bus_is_bus_client()</function>,
+    <function>sd_bus_set_monitor()</function>, and
+    <function>sd_bus_is_monitor()</function> were added in version 246.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_bus_set_watch_bind.xml b/man/sd_bus_set_watch_bind.xml
new file mode 100644
index 0000000..02e5f8f
--- /dev/null
+++ b/man/sd_bus_set_watch_bind.xml
@@ -0,0 +1,139 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_bus_set_watch_bind"
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_bus_set_watch_bind</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_set_watch_bind</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_set_watch_bind</refname>
+    <refname>sd_bus_get_watch_bind</refname>
+
+    <refpurpose>Control socket binding watching on bus connections</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_set_watch_bind</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>int <parameter>b</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_get_watch_bind</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+      </funcprototype>
+
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_bus_set_watch_bind()</function> may be used to enable or disable client-side watching of server
+    socket binding for a bus connection object. If the <parameter>b</parameter> is true, the feature is enabled,
+    otherwise disabled (which is the default). When enabled, and the selected bus address refers to an
+    <filename>AF_UNIX</filename> socket in the file system which does not exist while the connection attempt is made an
+    <citerefentry project='man-pages'><refentrytitle>inotify</refentrytitle><manvolnum>7</manvolnum></citerefentry> watch is installed on
+    it, waiting for the socket to appear. As soon as the socket appears the connection is made. This functionality is
+    useful in particular in early-boot programs that need to run before the system bus is available, but want to
+    connect to it the instant it may be connected to.</para>
+
+    <para><function>sd_bus_get_watch_bind()</function> may be used to query the current setting of this feature. It
+    returns zero when the feature is disabled, and positive if enabled.</para>
+
+    <para>Note that no timeout is applied while we wait for the socket to appear. This means that any
+    synchronous remote operation (such as
+    <citerefentry><refentrytitle>sd_bus_call</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_bus_add_match</refentrytitle><manvolnum>3</manvolnum></citerefentry> or
+    <citerefentry><refentrytitle>sd_bus_request_name</refentrytitle><manvolnum>3</manvolnum></citerefentry>),
+    that is used on a connection with this feature enabled that hasn't been established yet, might block
+    forever if the socket is never created. However, asynchronous remote operations (such as
+    <citerefentry><refentrytitle>sd_bus_send</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_bus_call_async</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_bus_add_match_async</refentrytitle><manvolnum>3</manvolnum></citerefentry>)
+    do not block in this case, and safely enqueue the requested operations to be dispatched the instant the
+    connection is set up.</para>
+
+    <para>Use <citerefentry><refentrytitle>sd_bus_is_ready</refentrytitle><manvolnum>3</manvolnum></citerefentry> to
+    determine whether the connection is fully established, i.e. whether the peer socket has been bound, connected to
+    and authenticated. Use
+    <citerefentry><refentrytitle>sd_bus_set_connected_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry> to
+    be notified when the connection is fully established.</para>
+
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, these functions return 0 or a positive integer. On failure, they return a negative
+    errno-style error code.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-ECHILD</constant></term>
+
+          <listitem><para>The bus connection has been created in a different process, library or module instance.</para></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>Example</title>
+
+    <example>
+      <title>Create a simple system service that publishes a property on the system bus and can reconnect
+      when D-Bus disconnects and reconnects</title>
+
+      <programlisting><xi:include href="sd_bus_service_reconnect.c" parse="text"/></programlisting>
+
+      <para>This is particularly useful for services that are configured to survive a soft-reboot, see
+      <citerefentry><refentrytitle>systemd-soft-reboot.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+      for more details.</para>
+    </example>
+  </refsect1>
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_bus_set_watch_bind()</function> and
+    <function>sd_bus_get_watch_bind()</function> were added in version 237.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>inotify</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_call</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_add_match</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_request_name</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_is_ready</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_set_connected_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_bus_slot_get_bus.xml b/man/sd_bus_slot_get_bus.xml
new file mode 100644
index 0000000..f24d944
--- /dev/null
+++ b/man/sd_bus_slot_get_bus.xml
@@ -0,0 +1,98 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_bus_slot_get_bus" xmlns:xi="http://www.w3.org/2001/XInclude">
+  <refentryinfo>
+    <title>sd_bus_slot_get_bus</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_slot_get_bus</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_slot_get_bus</refname>
+    <refname>sd_bus_slot_get_current_handler</refname>
+    <refname>sd_bus_slot_get_current_message</refname>
+    <refname>sd_bus_slot_get_current_userdata</refname>
+
+    <refpurpose>Query information attached to a bus slot object</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <xi:include href="sd_bus_add_match.xml" xpointer="sd_bus_message_handler_t"/>
+
+      <funcprototype>
+        <funcdef>sd_bus *<function>sd_bus_slot_get_bus</function></funcdef>
+        <paramdef>sd_bus_slot *<parameter>slot</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>sd_bus_message_handler_t <function>sd_bus_slot_get_current_handler</function>
+        </funcdef>
+        <paramdef>sd_bus_slot *<parameter>slot</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>sd_bus_message *<function>sd_bus_slot_get_current_message</function></funcdef>
+        <paramdef>sd_bus_slot *<parameter>slot</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>void *<function>sd_bus_slot_get_current_userdata</function></funcdef>
+        <paramdef>sd_bus_slot *<parameter>slot</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_bus_slot_get_bus()</function> returns the bus object that message
+    <parameter>slot</parameter> is attached to.</para>
+
+    <para><function>sd_bus_slot_get_current_handler()</function>,
+    <function>sd_bus_slot_get_current_message()</function> and
+    <function>sd_bus_slot_get_current_userdata()</function> return the current handler, message and
+    userdata respectively of the bus <parameter>slot</parameter> is attached to if we're currently
+    executing the callback associated with <parameter>slot</parameter>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para><function>sd_bus_slot_get_bus()</function> always returns the bus object.</para>
+
+    <para>On success, <function>sd_bus_slot_get_current_handler()</function>,
+    <function>sd_bus_slot_get_current_message()</function> and
+    <function>sd_bus_slot_get_current_userdata()</function> return the requested object. On failure,
+    they return <constant>NULL</constant>.</para>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_bus_slot_get_bus()</function>,
+    <function>sd_bus_slot_get_current_handler()</function>,
+    <function>sd_bus_slot_get_current_message()</function>, and
+    <function>sd_bus_slot_get_current_userdata()</function> were added in version 246.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_bus_slot_ref.xml b/man/sd_bus_slot_ref.xml
new file mode 100644
index 0000000..055bf00
--- /dev/null
+++ b/man/sd_bus_slot_ref.xml
@@ -0,0 +1,101 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_bus_slot_ref" xmlns:xi="http://www.w3.org/2001/XInclude">
+  <refentryinfo>
+    <title>sd_bus_slot_ref</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_slot_ref</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_slot_ref</refname>
+    <refname>sd_bus_slot_unref</refname>
+    <refname>sd_bus_slot_unrefp</refname>
+
+    <refpurpose>Create and destroy references to a bus slot object</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>sd_bus_slot *<function>sd_bus_slot_ref</function></funcdef>
+        <paramdef>sd_bus_slot *<parameter>slot</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>sd_bus_slot *<function>sd_bus_slot_unref</function></funcdef>
+        <paramdef>sd_bus_slot *<parameter>slot</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>void <function>sd_bus_slot_unrefp</function></funcdef>
+        <paramdef>sd_bus_slot **<parameter>slotp</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_bus_slot_ref()</function> increases the internal reference counter of
+    <parameter>slot</parameter> by one.</para>
+
+    <para><function>sd_bus_slot_unref()</function> decreases the internal reference counter of
+    <parameter>slot</parameter> by one. Once the reference count has dropped to zero, slot object is
+    destroyed and cannot be used anymore, so further calls to <function>sd_bus_slot_ref()</function>
+    or <function>sd_bus_slot_unref()</function> are illegal.</para>
+
+    <para><function>sd_bus_slot_unrefp()</function> is similar to
+    <function>sd_bus_slot_unref()</function> but takes a pointer to a pointer to an
+    <type>sd_bus_slot</type> object. This call is useful in conjunction with GCC's and LLVM's <ulink
+    url="https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html">Clean-up Variable
+    Attribute</ulink>. See
+    <citerefentry><refentrytitle>sd_bus_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    for an example how to use the cleanup attribute.</para>
+
+    <para><function>sd_bus_slot_ref()</function> and <function>sd_bus_slot_unref()</function>
+    execute no operation if the passed in bus object address is
+    <constant>NULL</constant>. <function>sd_bus_slot_unrefp()</function> will first dereference
+    its argument, which must not be <constant>NULL</constant>, and will execute no operation if
+    <emphasis>that</emphasis> is <constant>NULL</constant>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para><function>sd_bus_slot_ref()</function> always returns the argument.</para>
+
+    <para><function>sd_bus_slot_unref()</function> always returns <constant>NULL</constant>.</para>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_bus_slot_ref()</function>,
+    <function>sd_bus_slot_unref()</function>, and
+    <function>sd_bus_slot_unrefp()</function> were added in version 240.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_message_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_call_method_async</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_bus_slot_set_description.xml b/man/sd_bus_slot_set_description.xml
new file mode 100644
index 0000000..b24f8e1
--- /dev/null
+++ b/man/sd_bus_slot_set_description.xml
@@ -0,0 +1,111 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_bus_slot_set_description" xmlns:xi="http://www.w3.org/2001/XInclude">
+  <refentryinfo>
+    <title>sd_bus_slot_set_description</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_slot_set_description</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_slot_set_description</refname>
+    <refname>sd_bus_slot_get_description</refname>
+
+    <refpurpose>Set or query the description of bus slot objects</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_slot_set_description</function></funcdef>
+        <paramdef>sd_bus_slot* <parameter>slot</parameter></paramdef>
+        <paramdef>const char *<parameter>description</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_slot_get_description</function></funcdef>
+        <paramdef>sd_bus_slot* <parameter>bus</parameter></paramdef>
+        <paramdef>const char **<parameter>description</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_bus_slot_set_description()</function> sets the description string
+    that is used in logging to the specified string. The string is copied internally
+    and freed when the bus slot object is deallocated. The
+    <parameter>description</parameter> argument may be <constant>NULL</constant>, in
+    which case the description is unset.</para>
+
+    <para><function>sd_bus_slot_get_description()</function> returns a description string in
+    <parameter>description</parameter>. If the string is not set, e.g. with
+    <function>sd_bus_slot_set_description()</function>, and the slot is a bus match callback slot,
+    the match string will be returned. Otherwise, <constant>-ENXIO</constant> is returned.
+    </para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, these functions return 0 or a positive integer. On failure,
+    they return a negative errno-style error code.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>An required argument is <constant>NULL</constant>.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENXIO</constant></term>
+
+          <listitem><para>The bus slot object has no description.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOMEM</constant></term>
+
+          <listitem><para>Memory allocation failed.</para></listitem>
+        </varlistentry>
+      </variablelist>
+
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_bus_slot_set_description()</function> and
+    <function>sd_bus_slot_get_description()</function> were added in version 240.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+      <citerefentry><refentrytitle>sd_bus_slot_ref</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_slot_set_userdata</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_bus_slot_set_destroy_callback.xml b/man/sd_bus_slot_set_destroy_callback.xml
new file mode 100644
index 0000000..404db6e
--- /dev/null
+++ b/man/sd_bus_slot_set_destroy_callback.xml
@@ -0,0 +1,139 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_bus_slot_set_destroy_callback"
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_bus_slot_set_destroy_callback</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_slot_set_destroy_callback</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_slot_set_destroy_callback</refname>
+    <refname>sd_bus_slot_get_destroy_callback</refname>
+    <refname>sd_bus_track_set_destroy_callback</refname>
+    <refname>sd_bus_track_get_destroy_callback</refname>
+    <refname>sd_bus_destroy_t</refname>
+
+    <refpurpose>Define the callback function for resource cleanup</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>typedef int (*<function>sd_bus_destroy_t</function>)</funcdef>
+        <paramdef>void *<parameter>userdata</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_slot_set_destroy_callback</function></funcdef>
+        <paramdef>sd_bus_slot *<parameter>slot</parameter></paramdef>
+        <paramdef>sd_bus_destroy_t <parameter>callback</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_slot_get_destroy_callback</function></funcdef>
+        <paramdef>sd_bus_slot *<parameter>slot</parameter></paramdef>
+        <paramdef>sd_bus_destroy_t *<parameter>callback</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_track_set_destroy_callback</function></funcdef>
+        <paramdef>sd_bus_track *<parameter>track</parameter></paramdef>
+        <paramdef>sd_bus_destroy_t <parameter>callback</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_track_get_destroy_callback</function></funcdef>
+        <paramdef>sd_bus_track *<parameter>track</parameter></paramdef>
+        <paramdef>sd_bus_destroy_t *<parameter>callback</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_bus_slot_set_destroy_callback()</function> sets <parameter>callback</parameter> as the callback
+    function to be called right before the bus slot object <parameter>slot</parameter> is deallocated. The
+    <parameter>userdata</parameter> pointer from the slot object will be passed as the <parameter>userdata</parameter>
+    parameter. This pointer can be set by an argument to the constructor functions, see
+    <citerefentry><refentrytitle>sd_bus_add_match</refentrytitle><manvolnum>3</manvolnum></citerefentry>, or directly,
+    see <citerefentry><refentrytitle>sd_bus_slot_set_userdata</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+    This callback function is called even if <parameter>userdata</parameter> is <constant>NULL</constant>. Note that
+    this callback is invoked at a time where the bus slot object itself is already invalidated, and executing
+    operations or taking new references to the bus slot object is not permissible.</para>
+
+    <para><function>sd_bus_slot_get_destroy_callback()</function> returns the current callback
+    for <parameter>slot</parameter> in the <parameter>callback</parameter> parameter.</para>
+
+    <para><function>sd_bus_track_set_destroy_callback()</function> and
+    <function>sd_bus_track_get_destroy_callback()</function> provide equivalent functionality for the
+    <parameter>userdata</parameter> pointer associated with bus peer tracking objects. For details about bus peer
+    tracking objects, see
+    <citerefentry><refentrytitle>sd_bus_track_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, <function>sd_bus_slot_set_destroy_callback()</function> and
+    <function>sd_bus_track_set_destroy_callback()</function> return 0 or a positive integer. On failure, they
+    return a negative errno-style error code.</para>
+
+    <para><function>sd_bus_slot_get_destroy_callback()</function> and
+    <function>sd_bus_track_get_destroy_callback()</function> return positive if the destroy callback function
+    is set, 0 if not. On failure, they return a negative errno-style error code.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>The <parameter>slot</parameter> or <parameter>track</parameter> parameter is
+          <constant>NULL</constant>.</para></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_bus_destroy_t()</function>,
+    <function>sd_bus_slot_set_destroy_callback()</function>,
+    <function>sd_bus_slot_get_destroy_callback()</function>,
+    <function>sd_bus_track_set_destroy_callback()</function>, and
+    <function>sd_bus_track_get_destroy_callback()</function> were added in version 239.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_slot_set_floating</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_add_match</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_track_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_slot_set_userdata</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_track_set_userdata</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_bus_slot_set_floating.xml b/man/sd_bus_slot_set_floating.xml
new file mode 100644
index 0000000..df2cbc6
--- /dev/null
+++ b/man/sd_bus_slot_set_floating.xml
@@ -0,0 +1,123 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_bus_slot_set_floating" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_bus_slot_set_floating</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_slot_set_floating</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_slot_set_floating</refname>
+    <refname>sd_bus_slot_get_floating</refname>
+
+    <refpurpose>Control whether a bus slot object is "floating"</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_slot_set_floating</function></funcdef>
+        <paramdef>sd_bus_slot *<parameter>slot</parameter></paramdef>
+        <paramdef>int <parameter>b</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_slot_get_floating</function></funcdef>
+        <paramdef>sd_bus_slot *<parameter>slot</parameter></paramdef>
+      </funcprototype>
+
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_bus_slot_set_floating()</function> controls whether the specified bus slot object
+    <parameter>slot</parameter> shall be "floating" or not. A floating bus slot object's lifetime is bound to the
+    lifetime of the bus object it is associated with, meaning that it remains allocated as long as the bus object
+    itself and is freed automatically when the bus object is freed. Regular (i.e. non-floating) bus slot objects keep
+    the bus referenced, hence the bus object remains allocated at least as long as there remains at least one
+    referenced bus slot object around. The floating state hence controls the direction of referencing between the bus
+    object and the bus slot objects: if floating the bus pins the bus slot, and otherwise the bus slot pins the bus
+    objects. Use <function>sd_bus_slot_set_floating()</function> to switch between both modes: if the
+    <parameter>b</parameter> parameter is zero, the slot object is considered floating, otherwise it is made a regular
+    (non-floating) slot object.</para>
+
+    <para>Bus slot objects may be allocated with calls such as
+    <citerefentry><refentrytitle>sd_bus_add_match</refentrytitle><manvolnum>3</manvolnum></citerefentry>. If the
+    <parameter>slot</parameter> of these functions is non-<constant>NULL</constant> the slot object will be of the
+    regular kind (i.e. non-floating), otherwise it will be created floating. With
+    <function>sd_bus_slot_set_floating()</function> a bus slot object allocated as regular can be converted into a
+    floating object and back. This is particularly useful for creating a bus slot object, then changing parameters of
+    it, and then turning it into a floating object, whose lifecycle is managed by the bus object.</para>
+
+    <para><function>sd_bus_slot_get_floating()</function> returns the current floating state of the specified bus slot
+    object. It returns negative on error, zero if the bus slot object is a regular (non-floating) object and positive
+    otherwise.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, these functions return 0 or a positive integer. On failure, they return a negative
+    errno-style error code.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>The <parameter>slot</parameter> parameter is <constant>NULL</constant>.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ECHILD</constant></term>
+
+          <listitem><para>The bus connection has been created in a different process, library or module instance.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ESTALE</constant></term>
+
+          <listitem><para>The bus object the specified bus slot object is associated with has already been
+          freed, and hence no change in the floating state can be made anymore.</para></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_bus_slot_set_floating()</function> and
+    <function>sd_bus_slot_get_floating()</function> were added in version 239.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_slot_set_destroy_callback</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_add_match</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_bus_slot_set_userdata.xml b/man/sd_bus_slot_set_userdata.xml
new file mode 100644
index 0000000..691ed2d
--- /dev/null
+++ b/man/sd_bus_slot_set_userdata.xml
@@ -0,0 +1,94 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_bus_slot_set_userdata" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_bus_slot_set_userdata</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_slot_set_userdata</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_slot_set_userdata</refname>
+    <refname>sd_bus_slot_get_userdata</refname>
+
+    <refpurpose>Set and query the value in the "userdata" field</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>void* <function>sd_bus_slot_set_userdata</function></funcdef>
+        <paramdef>sd_bus_slot* <parameter>slot</parameter></paramdef>
+        <paramdef>void* <parameter>userdata</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>void* <function>sd_bus_slot_get_userdata</function></funcdef>
+        <paramdef>sd_bus_slot* <parameter>slot</parameter></paramdef>
+      </funcprototype>
+
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>The userdata pointer allows data to be passed between the point where a callback is
+    registered, for example when a filter is added using
+    <citerefentry><refentrytitle>sd_bus_add_filter</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    or an asynchronous function call is made using
+    <citerefentry><refentrytitle>sd_bus_call_async</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    and the point where the callback is called, without having any global state. The pointer has
+    type <type>void*</type> and is not used by the sd-bus functions in any way, except to pass to
+    the callback function.</para>
+
+    <para>Usually, the userdata field is set when the slot object is initially
+    registered. <function>sd_bus_slot_set_userdata()</function> may be used to change it later for
+    the bus slot object <parameter>slot</parameter>. Previous value of the field is returned. The
+    argument and returned value may be <constant>NULL</constant>. It will be passed as the
+    <parameter>userdata</parameter> argument to the callback function attached to the slot.</para>
+
+    <para><function>sd_bus_slot_set_userdata()</function> gets the value of the userdata field in
+    the bus slot object <parameter>slot</parameter>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, these functions return the value of the userdata field before the function
+    call. If the <parameter>slot</parameter> object is <constant>NULL</constant>,
+    <constant>NULL</constant> will be returned to signify an error, but this is not distinguishable
+    from the userdata field value being <constant>NULL</constant>.</para>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_bus_slot_set_userdata()</function> and
+    <function>sd_bus_slot_get_userdata()</function> were added in version 240.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_slot_set_destroy_callback</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_add_match</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_slot_get_current_userdata</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_bus_start.xml b/man/sd_bus_start.xml
new file mode 100644
index 0000000..bf693ce
--- /dev/null
+++ b/man/sd_bus_start.xml
@@ -0,0 +1,137 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_bus_start"
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_bus_start</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_start</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_start</refname>
+
+    <refpurpose>Initiate a bus connection to the D-bus broker daemon
+    </refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_start</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_bus_start()</function> connects an existing bus connection object to the D-Bus
+    broker daemon, usually
+    <citerefentry project='die-net'><refentrytitle>dbus-daemon</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    or
+    <citerefentry project='mankier'><refentrytitle>dbus-broker</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
+    The mechanism to use for the connection must be configured before the call to
+    <function>sd_bus_start()</function>, using one of
+    <citerefentry><refentrytitle>sd_bus_set_address</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_bus_set_fd</refentrytitle><manvolnum>3</manvolnum></citerefentry>, or
+    <citerefentry><refentrytitle>sd_bus_set_exec</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+    <function>sd_bus_start()</function> will open the connection socket or spawn the executable as
+    needed, and asynchronously start a <function>org.freedesktop.DBus.Hello()</function> call. The
+    answer to the Hello call will be processed later from
+    <citerefentry><refentrytitle>sd_bus_process</refentrytitle><manvolnum>3</manvolnum></citerefentry>. If
+    opening of the connection or queuing of the asynchronous call fail, the connection will be closed with
+    <citerefentry><refentrytitle>sd_bus_close</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para>
+
+    <para>In most cases, it is better to use
+    <citerefentry><refentrytitle>sd_bus_default_user</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_bus_default_system</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    or related calls instead of the more low-level <function>sd_bus_new()</function> and
+    <function>sd_bus_start()</function>. The higher-level functions not only allocate a bus object but also
+    start the connection to a well-known bus in a single function call.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, this function returns a non-negative integer. On failure, it returns a negative
+    errno-style error code.</para>
+
+    <refsect2 id='errors'>
+      <title>Errors</title>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>The input parameter <parameter>bus</parameter> is <constant>NULL</constant>.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOPKG</constant></term>
+
+          <listitem><para>Bus object <parameter>bus</parameter> could not be resolved.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EPERM</constant></term>
+
+          <listitem><para>The input parameter <parameter>bus</parameter> is in a wrong state
+          (<function>sd_bus_start()</function> may only be called once on a newly-created bus object).</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ECHILD</constant></term>
+
+          <listitem><para>The bus object <parameter>bus</parameter> was created in a different
+          process.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+          </listitem>
+        </varlistentry>
+      </variablelist>
+
+      <para>In addition, other connection-related errors may be returned. See
+      <citerefentry><refentrytitle>sd_bus_send</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_bus_start()</function> was added in version 246.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_default</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_call_async</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_bus_track_add_name.xml b/man/sd_bus_track_add_name.xml
new file mode 100644
index 0000000..d52fb21
--- /dev/null
+++ b/man/sd_bus_track_add_name.xml
@@ -0,0 +1,242 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_bus_track_add_name" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_bus_track_add_name</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_track_add_name</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_track_add_name</refname>
+    <refname>sd_bus_track_add_sender</refname>
+    <refname>sd_bus_track_remove_name</refname>
+    <refname>sd_bus_track_remove_sender</refname>
+    <refname>sd_bus_track_count</refname>
+    <refname>sd_bus_track_count_sender</refname>
+    <refname>sd_bus_track_count_name</refname>
+    <refname>sd_bus_track_contains</refname>
+    <refname>sd_bus_track_first</refname>
+    <refname>sd_bus_track_next</refname>
+
+    <refpurpose>Add, remove and retrieve bus peers tracked in a bus peer tracking object</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_track_add_name</function></funcdef>
+        <paramdef>sd_bus_track* <parameter>t</parameter></paramdef>
+        <paramdef>const char* <parameter>name</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_track_add_sender</function></funcdef>
+        <paramdef>sd_bus_track* <parameter>t</parameter></paramdef>
+        <paramdef>sd_bus_message* <parameter>message</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_track_remove_name</function></funcdef>
+        <paramdef>sd_bus_track* <parameter>t</parameter></paramdef>
+        <paramdef>const char* <parameter>name</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_track_remove_sender</function></funcdef>
+        <paramdef>sd_bus_track* <parameter>t</parameter></paramdef>
+        <paramdef>sd_bus_message* <parameter>message</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>unsigned <function>sd_bus_track_count</function></funcdef>
+        <paramdef>sd_bus_track* <parameter>t</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_track_count_name</function></funcdef>
+        <paramdef>sd_bus_track* <parameter>t</parameter></paramdef>
+        <paramdef>const char* <parameter>name</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_track_count_sender</function></funcdef>
+        <paramdef>sd_bus_track* <parameter>t</parameter></paramdef>
+        <paramdef>sd_bus_message* <parameter>message</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_track_contains</function></funcdef>
+        <paramdef>sd_bus_track* <parameter>t</parameter></paramdef>
+        <paramdef>const char* <parameter>name</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>const char* <function>sd_bus_track_first</function></funcdef>
+        <paramdef>sd_bus_track* <parameter>t</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>const char* <function>sd_bus_track_next</function></funcdef>
+        <paramdef>sd_bus_track* <parameter>t</parameter></paramdef>
+      </funcprototype>
+
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_bus_track_add_name()</function> adds a peer to track to a bus peer tracking object. The first
+    argument should refer to a bus peer tracking object created with
+    <citerefentry><refentrytitle>sd_bus_track_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>, the second
+    name should refer to a D-Bus peer name to track, either in unique or well-known service format. If the name is not
+    tracked yet it will be added to the list of names to track. If it already is being tracked and non-recursive mode
+    is enabled, no operation is executed by this call. If recursive mode is enabled a per-name counter is increased by
+    one each time this call is invoked, and <function>sd_bus_track_remove_name()</function> has to be called as many
+    times as <function>sd_bus_track_add_name()</function> was invoked before in order to stop tracking of the name. Use
+    <citerefentry><refentrytitle>sd_bus_track_set_recursive</refentrytitle><manvolnum>3</manvolnum></citerefentry> to
+    switch from the default non-recursive mode to recursive mode, or back. Note that the specified name is tracked as
+    it is, well-known names are not resolved to unique names by this call. Note that multiple bus peer tracking objects
+    may track the same name.</para>
+
+    <para><function>sd_bus_track_remove_name()</function> undoes the effect of
+    <function>sd_bus_track_add_name()</function> and removes a bus peer name from the list of peers to watch. Depending
+    on whether non-recursive or recursive mode is enabled for the bus peer tracking object this call will either remove
+    the name fully from the tracking object, or will simply decrement the per-name counter by one, removing the name
+    only when the counter reaches zero (see above). Note that a bus peer disconnecting from the bus will implicitly
+    remove its names fully from the bus peer tracking object, regardless of the current per-name counter.</para>
+
+    <para><function>sd_bus_track_add_sender()</function> and <function>sd_bus_track_remove_sender()</function> are
+    similar to <function>sd_bus_track_add_name()</function> and <function>sd_bus_track_remove_name()</function> but
+    take a bus message as argument. The sender of this bus message is determined and added to/removed from the bus peer
+    tracking object. As messages always originate from unique names, and never from well-known names this means that
+    this call will effectively only add unique names to the bus peer tracking object.</para>
+
+    <para><function>sd_bus_track_count()</function> returns the number of names currently being tracked by the
+    specified bus peer tracking object. Note that this function always returns the actual number of names tracked, and
+    hence if <function>sd_bus_track_add_name()</function> has been invoked multiple times for the same name it is only
+    counted as one, regardless if recursive mode is used or not.</para>
+
+    <para><function>sd_bus_track_count_name()</function> returns the current per-name counter for the specified
+    name. If non-recursive mode is used this returns either 1 or 0, depending on whether the specified name has been
+    added to the tracking object before, or not. If recursive mode has been enabled, values larger than 1 may be
+    returned too, in case <function>sd_bus_track_add_name()</function> has been called multiple times for the same
+    name.</para>
+
+    <para><function>sd_bus_track_count_sender()</function> is similar to
+    <function>sd_bus_track_count_name()</function>, but takes a bus message object and returns the per-name counter
+    matching the sender of the message.</para>
+
+    <para><function>sd_bus_track_contains()</function> may be used to determine whether the specified name has been
+    added at least once to the specified bus peer tracking object.</para>
+
+    <para><function>sd_bus_track_first()</function> and <function>sd_bus_track_next()</function> may be used to
+    enumerate all names currently being tracked by the passed bus peer tracking
+    object. <function>sd_bus_track_first()</function> returns the first entry in the object, and resets an internally
+    maintained read index. Each subsequent invocation of <function>sd_bus_track_next()</function> returns the next name
+    contained in the bus object. If the end is reached <constant>NULL</constant> is returned. If no names have been
+    added to the object yet <function>sd_bus_track_first()</function> will return <constant>NULL</constant>
+    immediately. The order in which names are returned is undefined; in particular which name is considered the first
+    returned is not defined. If recursive mode is enabled and the same name has been added multiple times to the bus
+    peer tracking object it is only returned once by this enumeration. If new names are added to or existing names
+    removed from the bus peer tracking object while it is being enumerated the enumeration ends on the next invocation
+    of <function>sd_bus_track_next()</function> as <constant>NULL</constant> is returned.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, <function>sd_bus_track_add_name()</function> and <function>sd_bus_track_add_sender()</function>
+    return 0 if the specified name has already been added to the bus peer tracking object before and positive if it
+    hasn't. On failure, they return a negative errno-style error code.</para>
+
+    <para><function>sd_bus_track_remove_name()</function> and <function>sd_bus_track_remove_sender()</function> return
+    positive if the specified name was previously tracked by the bus peer tracking object and has now been removed. In
+    non-recursive mode, 0 is returned if the specified name was not being tracked yet. In recursive mode
+    <constant>-EUNATCH</constant> is returned in this case. On failure, they return a negative errno-style error
+    code.</para>
+
+    <para><function>sd_bus_track_count()</function> returns the number of names currently being tracked, or 0 on
+    failure.</para>
+
+    <para><function>sd_bus_track_count_name()</function> and <function>sd_bus_track_count_sender()</function> return
+    the current per-name counter for the specified name or the sender of the specified message. Zero is returned for
+    names that are not being tracked yet, a positive value for names added at least once. Larger values than 1 are only
+    returned in recursive mode. On failure, a negative errno-style error code is returned.</para>
+
+    <para><function>sd_bus_track_contains()</function> returns the passed name if it exists in the bus peer tracking
+    object. On failure, and if the name has not been added yet <constant>NULL</constant> is returned.</para>
+
+    <para><function>sd_bus_track_first()</function> and <function>sd_bus_track_next()</function> return the first/next
+    name contained in the bus peer tracking object, and <constant>NULL</constant> if the end of the enumeration is
+    reached and on error.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+
+        <varlistentry>
+          <term><constant>-EUNATCH</constant></term>
+
+          <listitem><para><function>sd_bus_track_remove_name()</function> or
+          <function>sd_bus_track_remove_sender()</function> have been invoked for a name not previously added
+          to the bus peer object.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>Specified parameter is invalid.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOMEM</constant></term>
+
+          <listitem><para>Memory allocation failed.</para></listitem>
+        </varlistentry>
+
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_bus_track_add_name()</function>,
+    <function>sd_bus_track_add_sender()</function>,
+    <function>sd_bus_track_remove_name()</function>,
+    <function>sd_bus_track_remove_sender()</function>,
+    <function>sd_bus_track_count()</function>,
+    <function>sd_bus_track_count_name()</function>,
+    <function>sd_bus_track_count_sender()</function>,
+    <function>sd_bus_track_contains()</function>,
+    <function>sd_bus_track_first()</function>, and
+    <function>sd_bus_track_next()</function> were added in version 232.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_track_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_bus_track_new.xml b/man/sd_bus_track_new.xml
new file mode 100644
index 0000000..de6b48d
--- /dev/null
+++ b/man/sd_bus_track_new.xml
@@ -0,0 +1,244 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_bus_track_new" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_bus_track_new</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_track_new</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_track_new</refname>
+    <refname>sd_bus_track_ref</refname>
+    <refname>sd_bus_track_unref</refname>
+    <refname>sd_bus_track_unrefp</refname>
+    <refname>sd_bus_track_set_recursive</refname>
+    <refname>sd_bus_track_get_recursive</refname>
+    <refname>sd_bus_track_get_bus</refname>
+    <refname>sd_bus_track_get_userdata</refname>
+    <refname>sd_bus_track_set_userdata</refname>
+
+    <refpurpose>Track bus peers</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_track_new</function></funcdef>
+        <paramdef>sd_bus* <parameter>bus</parameter></paramdef>
+        <paramdef>sd_bus_track** <parameter>ret</parameter></paramdef>
+        <paramdef>sd_bus_track_handler_t <parameter>handler</parameter></paramdef>
+        <paramdef>void* <parameter>userdata</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>sd_bus_track *<function>sd_bus_track_ref</function></funcdef>
+        <paramdef>sd_bus_track *<parameter>t</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>sd_bus_track *<function>sd_bus_track_unref</function></funcdef>
+        <paramdef>sd_bus_track *<parameter>t</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>void <function>sd_bus_track_unrefp</function></funcdef>
+        <paramdef>sd_bus_track **<parameter>t</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_track_get_recursive</function></funcdef>
+        <paramdef>sd_bus_track *<parameter>t</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_track_set_recursive</function></funcdef>
+        <paramdef>sd_bus_track *<parameter>t</parameter></paramdef>
+        <paramdef>int <parameter>b</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>sd_bus* <function>sd_bus_track_get_bus</function></funcdef>
+        <paramdef>sd_bus_track *<parameter>t</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>void* <function>sd_bus_track_get_userdata</function></funcdef>
+        <paramdef>sd_bus_track *<parameter>t</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>void* <function>sd_bus_track_set_userdata</function></funcdef>
+        <paramdef>sd_bus_track *<parameter>t</parameter></paramdef>
+        <paramdef>void *userdata</paramdef>
+      </funcprototype>
+
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_bus_track_new()</function> creates a new bus peer tracking object. The object is allocated for
+    the specified bus, and returned in the <parameter>*ret</parameter> parameter. After use, the object should be freed
+    again by dropping the acquired reference with <function>sd_bus_track_unref()</function> (see below). A bus peer
+    tracking object may be used to keep track of peers on a specific IPC bus, for cases where peers are making use of
+    one or more local objects, in order to control the lifecycle of the local objects and ensure they stay around as
+    long as the peers needing them are around, and unreferenced (and possibly destroyed) as soon as all relevant peers
+    have vanished. Each bus peer tracking object may be used to track zero, one or more peers add a time. References to
+    specific bus peers are added via
+    <citerefentry><refentrytitle>sd_bus_track_add_name</refentrytitle><manvolnum>3</manvolnum></citerefentry> or
+    <function>sd_bus_track_add_sender()</function>. They may be dropped again via
+    <function>sd_bus_track_remove_name()</function> and
+    <function>sd_bus_track_remove_sender()</function>. Alternatively, references on peers are removed automatically
+    when they disconnect from the bus.  If non-<constant>NULL</constant> the <parameter>handler</parameter> may specify
+    a function that is invoked whenever the last reference is dropped, regardless whether the reference is dropped
+    explicitly via <function>sd_bus_track_remove_name()</function> or implicitly because the peer disconnected from the
+    bus. The final argument <parameter>userdata</parameter> may be used to attach a generic user data pointer to the
+    object. This pointer is passed to the handler callback when it is invoked.</para>
+
+    <para><function>sd_bus_track_ref()</function> creates a new reference to a bus peer tracking object. This object
+    will not be destroyed until <function>sd_bus_track_unref()</function> has been called as many times plus once
+    more. Once the reference count has dropped to zero, the specified object cannot be used anymore, further calls to
+    <function>sd_bus_track_ref()</function> or <function>sd_bus_track_unref()</function> on the same object are
+    illegal.</para>
+
+    <para><function>sd_bus_track_unref()</function> destroys a reference to a bus peer tracking object.</para>
+
+    <para><function>sd_bus_track_unrefp()</function> is similar to <function>sd_bus_track_unref()</function> but takes
+    a pointer to a pointer to an <type>sd_bus_track</type> object. This call is useful in conjunction with GCC's and
+    LLVM's <ulink url="https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html">Clean-up Variable
+    Attribute</ulink>. Note that this function is defined as inline function.</para>
+
+    <para><function>sd_bus_track_ref()</function>, <function>sd_bus_track_unref()</function> and
+    <function>sd_bus_track_unrefp()</function> execute no operation if the passed in bus peer tracking object is
+    <constant>NULL</constant>.</para>
+
+    <para>Bus peer tracking objects may exist in two modes: by default they operate in non-recursive mode, but may
+    optionally be switched into recursive mode. If operating in the default non-recursive mode a peer is either tracked
+    or not tracked. In this mode invoking <function>sd_bus_track_add_name()</function> multiple times in a row for the
+    same peer is fully equivalent to calling it just once, as the call adds the peer to the set of tracked peers if
+    necessary, and executes no operation if the peer is already being tracked. A single invocation of
+    <function>sd_bus_track_remove_name()</function> removes the reference on the peer again, regardless how many times
+    <function>sd_bus_track_add_name()</function> was called before. If operating in recursive mode, the number of times
+    <function>sd_bus_track_add_name()</function> is invoked for the same peer name is counted and
+    <function>sd_bus_track_remove_name()</function> must be called the same number of times before the peer is not
+    tracked anymore, with the exception when the tracked peer vanishes from the bus, in which case the count is
+    irrelevant and the tracking of the specific peer is immediately
+    removed. <function>sd_bus_track_get_recursive()</function> may be used to determine whether the bus peer tracking
+    object is operating in recursive mode. <function>sd_bus_track_set_recursive()</function> may be used to enable or
+    disable recursive mode. By default a bus peer tracking object operates in non-recursive mode, and
+    <function>sd_bus_track_get_recursive()</function> for a newly allocated object hence returns a value equal to
+    zero. Use <function>sd_bus_track_set_recursive()</function> to enable recursive mode, right after allocation. It
+    takes a boolean argument to enable or disable recursive mode. Note that tracking objects for which
+    <function>sd_bus_track_add_name()</function> was already invoked at least once (and which hence track already one
+    or more peers) may not be switched from recursive to non-recursive mode anymore.</para>
+
+    <para><function>sd_bus_track_get_bus()</function> returns the bus object the bus peer tracking object belongs
+    to. It returns the bus object initially passed to <function>sd_bus_track_new()</function> when the object was
+    allocated.</para>
+
+    <para><function>sd_bus_track_get_userdata()</function> returns the generic user data pointer set on the bus peer
+    tracking object at the time of creation using <function>sd_bus_track_new()</function> or at a later time, using
+    <function>sd_bus_track_set_userdata()</function>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, <function>sd_bus_track_new()</function> and <function>sd_bus_track_set_recursive()</function>
+    return 0 or a positive integer. On failure, they return a negative errno-style error code.</para>
+
+    <para><function>sd_bus_track_ref()</function> always returns the argument.</para>
+
+    <para><function>sd_bus_track_unref()</function> always returns <constant>NULL</constant>.</para>
+
+    <para><function>sd_bus_track_get_recursive()</function> returns 0 if non-recursive mode is selected (default), and
+    greater than 0 if recursive mode is selected. On failure a negative errno-style error code is returned.</para>
+
+    <para><function>sd_bus_track_get_bus()</function> returns the bus object associated to the bus peer tracking
+    object.</para>
+
+    <para><function>sd_bus_track_get_userdata()</function> returns the generic user data pointer associated with the
+    bus peer tracking object. <function>sd_bus_track_set_userdata()</function> returns the previous user data pointer
+    set.</para>
+
+  </refsect1>
+
+  <refsect1>
+    <title>Reference ownership</title>
+
+    <para>The <function>sd_bus_track_new()</function> function creates a new object and the caller owns the sole
+    reference. When not needed anymore, this reference should be destroyed with
+    <function>sd_bus_track_unref()</function>.
+    </para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+
+        <varlistentry>
+          <term><constant>-EBUSY</constant></term>
+
+          <listitem><para>Bus peers have already been added to the bus peer tracking object and
+          <function>sd_bus_track_set_recursive()</function> was called to change tracking mode.
+          </para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>Specified parameter is invalid
+          (<constant>NULL</constant> in case of output
+          parameters).</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOMEM</constant></term>
+
+          <listitem><para>Memory allocation failed.</para></listitem>
+        </varlistentry>
+
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_bus_track_new()</function>,
+    <function>sd_bus_track_ref()</function>,
+    <function>sd_bus_track_unref()</function>,
+    <function>sd_bus_track_unrefp()</function>,
+    <function>sd_bus_track_get_recursive()</function>,
+    <function>sd_bus_track_set_recursive()</function>,
+    <function>sd_bus_track_get_bus()</function>,
+    <function>sd_bus_track_get_userdata()</function>, and
+    <function>sd_bus_track_set_userdata()</function> were added in version 232.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+      <citerefentry><refentrytitle>sd_bus_track_add_name</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_bus_wait.xml b/man/sd_bus_wait.xml
new file mode 100644
index 0000000..04dd090
--- /dev/null
+++ b/man/sd_bus_wait.xml
@@ -0,0 +1,118 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+
+<!--
+  SPDX-License-Identifier: LGPL-2.1-or-later
+
+  Copyright © 2016 Julian Orth
+-->
+
+<refentry id="sd_bus_wait" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_bus_wait</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_bus_wait</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_bus_wait</refname>
+
+    <refpurpose>Wait for I/O on a bus connection</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_bus_wait</function></funcdef>
+        <paramdef>sd_bus *<parameter>bus</parameter></paramdef>
+        <paramdef>uint64_t <parameter>timeout_usec</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_bus_wait()</function> synchronously waits for I/O on the specified bus connection object. This
+    function is supposed to be called whenever
+    <citerefentry><refentrytitle>sd_bus_process</refentrytitle><manvolnum>3</manvolnum></citerefentry> returns zero,
+    indicating that no work is pending on the connection. Internally, this call invokes <citerefentry
+    project='man-pages'><refentrytitle>ppoll</refentrytitle><manvolnum>2</manvolnum></citerefentry>, to wait for I/O on
+    the bus connection. If the <parameter>timeout_usec</parameter> parameter is specified, the call will block at most
+    for the specified amount of time in μs. Pass <constant>UINT64_MAX</constant> to permit it to sleep
+    indefinitely.</para>
+
+    <para>After each invocation of <function>sd_bus_wait()</function> the <function>sd_bus_process()</function> call
+    should be invoked in order to process any now pending I/O work.</para>
+
+    <para>Note that <function>sd_bus_wait()</function> is suitable only for simple programs as it does not permit
+    waiting for other I/O events. For more complex programs either connect the bus connection object to an external
+    event loop using <citerefentry><refentrytitle>sd_bus_get_fd</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    or to an <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry> event loop
+    using
+    <citerefentry><refentrytitle>sd_bus_attach_event</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>If any I/O was seen, a positive value is returned, zero otherwise. If an error occurs, a negative
+    <varname>errno</varname>-style error code is returned.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>An invalid bus object was passed.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ECHILD</constant></term>
+
+          <listitem><para>The bus connection was allocated in a parent process and is being reused in a child
+          process after <function>fork()</function>.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOTCONN</constant></term>
+
+          <listitem><para>The bus connection has been terminated already.</para></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_bus_wait()</function> was added in version 240.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_process</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_get_fd</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_bus_attach_event</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_device_get_syspath.xml b/man/sd_device_get_syspath.xml
new file mode 100644
index 0000000..c8adacd
--- /dev/null
+++ b/man/sd_device_get_syspath.xml
@@ -0,0 +1,219 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_device_get_syspath"
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_device_get_syspath</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_device_get_syspath</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_device_get_syspath</refname>
+    <refname>sd_device_get_devpath</refname>
+    <refname>sd_device_get_sysname</refname>
+    <refname>sd_device_get_sysnum</refname>
+    <refname>sd_device_get_subsystem</refname>
+    <refname>sd_device_get_devtype</refname>
+    <refname>sd_device_get_devname</refname>
+    <refname>sd_device_get_devnum</refname>
+    <refname>sd_device_get_ifindex</refname>
+    <refname>sd_device_get_driver</refname>
+    <refname>sd_device_get_diskseq</refname>
+
+    <refpurpose>Returns various fields of device objects</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-device.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_device_get_syspath</function></funcdef>
+        <paramdef>sd_device *<parameter>device</parameter></paramdef>
+        <paramdef>const char **<parameter>ret</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_device_get_devpath</function></funcdef>
+        <paramdef>sd_device *<parameter>device</parameter></paramdef>
+        <paramdef>const char **<parameter>ret</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_device_get_sysname</function></funcdef>
+        <paramdef>sd_device *<parameter>device</parameter></paramdef>
+        <paramdef>const char **<parameter>ret</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_device_get_sysnum</function></funcdef>
+        <paramdef>sd_device *<parameter>device</parameter></paramdef>
+        <paramdef>const char **<parameter>ret</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_device_get_subsystem</function></funcdef>
+        <paramdef>sd_device *<parameter>device</parameter></paramdef>
+        <paramdef>const char **<parameter>ret</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_device_get_devtype</function></funcdef>
+        <paramdef>sd_device *<parameter>device</parameter></paramdef>
+        <paramdef>const char **<parameter>ret</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_device_get_devname</function></funcdef>
+        <paramdef>sd_device *<parameter>device</parameter></paramdef>
+        <paramdef>const char **<parameter>ret</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_device_get_devnum</function></funcdef>
+        <paramdef>sd_device *<parameter>device</parameter></paramdef>
+        <paramdef>dev_t *<parameter>ret</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_device_get_ifindex</function></funcdef>
+        <paramdef>sd_device *<parameter>device</parameter></paramdef>
+        <paramdef>int *<parameter>ret</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_device_get_driver</function></funcdef>
+        <paramdef>sd_device *<parameter>device</parameter></paramdef>
+        <paramdef>const char **<parameter>ret</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_device_get_diskseq</function></funcdef>
+        <paramdef>sd_device *<parameter>device</parameter></paramdef>
+        <paramdef>uint64_t *<parameter>ret</parameter></paramdef>
+      </funcprototype>
+
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_device_get_syspath()</function> returns the sysfs path of the specified device record,
+    including the <filename>/sys</filename> prefix. Example: <filename>/sys/devices/virtual/tty/tty7</filename></para>
+
+    <para><function>sd_device_get_devpath()</function> returns the sysfs path of the specified device record,
+    excluding the <filename>/sys</filename> prefix. Example: <filename>/devices/virtual/tty/tty7</filename></para>
+
+    <para><function>sd_device_get_sysname()</function> returns the sysfs name of the specified device record,
+    i.e. the last component of the sysfs path. Example: <literal>tty7</literal> for the device
+    <filename>/sys/devices/virtual/tty/tty7</filename></para>
+
+    <para><function>sd_device_get_sysnum()</function> returns the sysfs device number of the specified device
+    record, i.e. the numeric suffix of the last component of the sysfs path. Example: <literal>7</literal>
+    for the device <filename>/sys/devices/virtual/tty/tty7</filename></para>
+
+    <para><function>sd_device_get_subsystem()</function> returns the kernel subsystem of the specified device
+    record. This is a short string fitting into a filename, and thus does not contain a slash and cannot be
+    empty. Example: <literal>tty</literal>, <literal>block</literal> or <literal>net</literal>.</para>
+
+    <para><function>sd_device_get_devtype()</function> returns the device type of the specified device
+    record, if the subsystem manages multiple types of devices. Example: for devices of the
+    <literal>block</literal> subsystem this can be <literal>disk</literal> or <literal>partition</literal>
+    </para>
+
+    <para><function>sd_device_get_devname()</function> returns the device node path of the specified device
+    record if the device has a device node. Example: for <filename>/sys/devices/virtual/tty/tty7</filename>
+    the string <filename>/dev/tty7</filename> is typically returned.</para>
+
+    <para><function>sd_device_get_devnum()</function> returns the device node major/minor
+    (i.e. <type>dev_t</type>) of the specified device record if the device has a device node (i.e. the one
+    returned by <function>sd_device_get_devname()</function>). For devices belonging to the
+    <literal>block</literal> subsystem this refers to a block device node, in all other cases to a character
+    device node. Example: for the <filename>/sys/devices/virtual/tty/tty7</filename> device this typically
+    returns the device number with major/minor <literal>4:7</literal>.</para>
+
+    <para><function>sd_device_get_ifindex()</function> returns the network interface index of the specified
+    device record, if the device encapsulates a network interface device, i.e. belongs to the
+    <literal>net</literal> subsystem. Example: the <literal>lo</literal> interface typically has interface
+    index 1.</para>
+
+    <para><function>sd_device_get_driver()</function> returns the kernel driver name attached to the
+    device. Note that the driver field is set on the devices consumed by the driver, not on the device
+    created by it. Example: a PCI device <filename>/sys/bus/pci/devices/0000:00:1f.6</filename> might be
+    attached to a driver <literal>e1000e</literal>.</para>
+
+    <para><function>sd_device_get_diskseq()</function> returns the kernel disk sequence number of the block
+    device. This number monotonically increases whenever a backing medium of a block device changes without
+    the device name changing, and is relevant for block devices encapsulating devices with changing media
+    (e.g. floppy or CD-ROM), or loopback block devices. Only defined for block devices, i.e. those of
+    subsystem <literal>block</literal>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, these calls return 0 or a positive integer. On failure, they return a negative
+    errno-style error code.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>A specified parameter is invalid.</para>
+
+          <xi:include href="version-info.xml" xpointer="v251"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOENT</constant></term>
+
+          <listitem><para>The requested field is not present in the device record.</para>
+
+          <xi:include href="version-info.xml" xpointer="v251"/></listitem>
+        </varlistentry>
+
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_device_get_syspath()</function>,
+    <function>sd_device_get_devpath()</function>,
+    <function>sd_device_get_sysname()</function>,
+    <function>sd_device_get_sysnum()</function>,
+    <function>sd_device_get_subsystem()</function>,
+    <function>sd_device_get_devtype()</function>,
+    <function>sd_device_get_devname()</function>,
+    <function>sd_device_get_devnum()</function>,
+    <function>sd_device_get_ifindex()</function>,
+    <function>sd_device_get_driver()</function>, and
+    <function>sd_device_get_diskseq()</function> were added in version 251.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_device_ref.xml b/man/sd_device_ref.xml
new file mode 100644
index 0000000..e5fc18f
--- /dev/null
+++ b/man/sd_device_ref.xml
@@ -0,0 +1,91 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_device_ref" xmlns:xi="http://www.w3.org/2001/XInclude">
+  <refentryinfo>
+    <title>sd_device_ref</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_device_ref</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_device_ref</refname>
+    <refname>sd_device_unref</refname>
+    <refname>sd_device_unrefp</refname>
+
+    <refpurpose>Create or destroy references to a device object</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-device.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>sd_device* <function>sd_device_ref</function></funcdef>
+        <paramdef>sd_device *<parameter>device</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>sd_device* <function>sd_device_unref</function></funcdef>
+        <paramdef>sd_device *<parameter>device</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>void <function>sd_device_unrefp</function></funcdef>
+        <paramdef>sd_device **<parameter>device</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+
+    <para><function>sd_device_ref()</function> increases the internal reference counter of
+    <parameter>device</parameter> by one.</para>
+
+    <para><function>sd_device_unref()</function> decreases the internal reference counter of
+    <parameter>device</parameter> by one. Once the reference count has dropped to zero,
+    <parameter>device</parameter> is destroyed and cannot be used anymore, so further calls to
+    <function>sd_device_ref()</function> or <function>sd_device_unref()</function> are illegal.</para>
+
+    <para><function>sd_device_unrefp()</function> is similar to <function>sd_device_unref()</function> but
+    takes a pointer to a pointer to an <type>sd_device</type> object. This call is useful in conjunction with
+    GCC's and LLVM's <ulink url="https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html">Clean-up
+    Variable Attribute</ulink>. Note that this function is defined as an inline function. Use a declaration
+    like the following, in order to allocate a device object that is freed automatically as the code block is
+    left:</para>
+
+    <programlisting>{
+  __attribute__((cleanup(sd_device_unrefp))) sd_device *device = NULL;
+  int r;
+  …
+  r = sd_device_new_from_syspath(&amp;device, "…");
+  if (r &lt; 0) {
+    errno = -r;
+    fprintf(stderr, "Failed to allocate device: %m\n");
+  }
+  …
+}</programlisting>
+
+    <para><function>sd_device_ref()</function> and <function>sd_device_unref()</function> execute no
+    operation if the argument is <constant>NULL</constant>. <function>sd_device_unrefp()</function> will
+    first dereference its argument, which must not be <constant>NULL</constant>, and will execute no
+    operation if <emphasis>that</emphasis> is <constant>NULL</constant>.</para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para><function>sd_device_ref()</function> always returns the argument, and
+    <function>sd_device_unref()</function> always returns <constant>NULL</constant>.
+    </para>
+  </refsect1>
+<refsect1>
+    <title>History</title>
+    <para><function>sd_device_ref()</function>,
+    <function>sd_device_unref()</function>, and
+    <function>sd_device_unrefp()</function> were added in version 251.</para>
+  </refsect1>
+</refentry>
diff --git a/man/sd_event_add_child.xml b/man/sd_event_add_child.xml
new file mode 100644
index 0000000..ca6aa61
--- /dev/null
+++ b/man/sd_event_add_child.xml
@@ -0,0 +1,368 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_event_add_child" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_event_add_child</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_event_add_child</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_event_add_child</refname>
+    <refname>sd_event_add_child_pidfd</refname>
+    <refname>sd_event_source_get_child_pid</refname>
+    <refname>sd_event_source_get_child_pidfd</refname>
+    <refname>sd_event_source_get_child_pidfd_own</refname>
+    <refname>sd_event_source_set_child_pidfd_own</refname>
+    <refname>sd_event_source_get_child_process_own</refname>
+    <refname>sd_event_source_set_child_process_own</refname>
+    <refname>sd_event_source_send_child_signal</refname>
+    <refname>sd_event_child_handler_t</refname>
+
+    <refpurpose>Add a child process state change event source to an event loop</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-event.h&gt;</funcsynopsisinfo>
+
+      <funcsynopsisinfo><token>typedef</token> struct sd_event_source sd_event_source;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>typedef int (*<function>sd_event_child_handler_t</function>)</funcdef>
+        <paramdef>sd_event_source *<parameter>s</parameter></paramdef>
+        <paramdef>const siginfo_t *<parameter>si</parameter></paramdef>
+        <paramdef>void *<parameter>userdata</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_event_add_child</function></funcdef>
+        <paramdef>sd_event *<parameter>event</parameter></paramdef>
+        <paramdef>sd_event_source **<parameter>source</parameter></paramdef>
+        <paramdef>pid_t <parameter>pid</parameter></paramdef>
+        <paramdef>int <parameter>options</parameter></paramdef>
+        <paramdef>sd_event_child_handler_t <parameter>handler</parameter></paramdef>
+        <paramdef>void *<parameter>userdata</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_event_add_child_pidfd</function></funcdef>
+        <paramdef>sd_event *<parameter>event</parameter></paramdef>
+        <paramdef>sd_event_source **<parameter>source</parameter></paramdef>
+        <paramdef>int <parameter>pidfd</parameter></paramdef>
+        <paramdef>int <parameter>options</parameter></paramdef>
+        <paramdef>sd_event_child_handler_t <parameter>handler</parameter></paramdef>
+        <paramdef>void *<parameter>userdata</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_event_source_get_child_pid</function></funcdef>
+        <paramdef>sd_event_source *<parameter>source</parameter></paramdef>
+        <paramdef>pid_t *<parameter>pid</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_event_source_get_child_pidfd</function></funcdef>
+        <paramdef>sd_event_source *<parameter>source</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_event_source_get_child_pidfd_own</function></funcdef>
+        <paramdef>sd_event_source *<parameter>source</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_event_source_set_child_pidfd_own</function></funcdef>
+        <paramdef>sd_event_source *<parameter>source</parameter></paramdef>
+        <paramdef>int <parameter>own</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_event_source_get_child_process_own</function></funcdef>
+        <paramdef>sd_event_source *<parameter>source</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_event_source_set_child_process_own</function></funcdef>
+        <paramdef>sd_event_source *<parameter>source</parameter></paramdef>
+        <paramdef>int <parameter>own</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_event_source_send_child_signal</function></funcdef>
+        <paramdef>sd_event_source *<parameter>source</parameter></paramdef>
+        <paramdef>int <parameter>sig</parameter></paramdef>
+        <paramdef>const siginfo_t *<parameter>info</parameter></paramdef>
+        <paramdef>unsigned <parameter>flags</parameter></paramdef>
+      </funcprototype>
+
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_event_add_child()</function> adds a new child process state change event source to an
+    event loop. The event loop object is specified in the <parameter>event</parameter> parameter, the event
+    source object is returned in the <parameter>source</parameter> parameter. The <parameter>pid</parameter>
+    parameter specifies the PID of the process to watch, which must be a direct child process of the invoking
+    process. The <parameter>options</parameter> parameter determines which state changes will be watched for.
+    It must contain an OR-ed mask of <constant>WEXITED</constant> (watch for the child process terminating),
+    <constant>WSTOPPED</constant> (watch for the child process being stopped by a signal), and
+    <constant>WCONTINUED</constant> (watch for the child process being resumed by a signal). See
+    <citerefentry project='man-pages'><refentrytitle>waitid</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+    for further information.</para>
+
+    <para>The <parameter>handler</parameter> must be a function to call when the process changes state or
+    <constant>NULL</constant>. The handler function will be passed the <parameter>userdata</parameter>
+    pointer, which may be chosen freely by the caller. The handler also receives a pointer to a
+    <structname>siginfo_t</structname> structure containing information about the child process event. The
+    handler may return negative to signal an error (see below), other return values are ignored. If
+    <parameter>handler</parameter> is <constant>NULL</constant>, a default handler that calls
+    <citerefentry><refentrytitle>sd_event_exit</refentrytitle><manvolnum>3</manvolnum></citerefentry> will be
+    used.</para>
+
+    <para>Only a single handler may be installed for a specific child process. The handler is enabled for a
+    single event (<constant>SD_EVENT_ONESHOT</constant>), but this may be changed with
+    <citerefentry><refentrytitle>sd_event_source_set_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+    If the handler function returns a negative error code, it will either be disabled after the invocation,
+    even if the <constant>SD_EVENT_ON</constant> mode was requested before, or it will cause the loop to
+    terminate, see
+    <citerefentry><refentrytitle>sd_event_source_set_exit_on_failure</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+    </para>
+
+    <para>To destroy an event source object use
+    <citerefentry><refentrytitle>sd_event_source_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    but note that the event source is only removed from the event loop
+    when all references to the event source are dropped. To make sure
+    an event source does not fire anymore, even when there's still a
+    reference to it kept, consider setting the event source to
+    <constant>SD_EVENT_OFF</constant> with
+    <citerefentry><refentrytitle>sd_event_source_set_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para>
+
+    <para>The <constant>SIGCHLD</constant> signal must be blocked in all threads before this function is
+    called (using <citerefentry
+    project='man-pages'><refentrytitle>sigprocmask</refentrytitle><manvolnum>2</manvolnum></citerefentry> or
+    <citerefentry
+    project='man-pages'><refentrytitle>pthread_sigmask</refentrytitle><manvolnum>3</manvolnum></citerefentry>).</para>
+
+    <para>If the second parameter of <function>sd_event_add_child()</function> is passed as
+    <constant>NULL</constant> no reference to the event source object is returned. In this case the event
+    source is considered "floating", and will be destroyed implicitly when the event loop itself is
+    destroyed.</para>
+
+    <para>Note that the <parameter>handler</parameter> function is
+    invoked at a time where the child process is not reaped yet (and
+    thus still is exposed as a zombie process by the kernel). However,
+    the child will be reaped automatically after the function
+    returns. Child processes for which no child process state change
+    event sources are installed will not be reaped by the event loop
+    implementation.</para>
+
+    <para>If the <parameter>handler</parameter> parameter to <function>sd_event_add_child()</function> is
+    <constant>NULL</constant>, and the event source fires, this will be considered a request to exit the
+    event loop. In this case, the <parameter>userdata</parameter> parameter, cast to an integer, is passed as
+    the exit code parameter to
+    <citerefentry><refentrytitle>sd_event_exit</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para>
+
+    <para>If both a child process state change event source and a
+    <constant>SIGCHLD</constant> signal event source is installed in
+    the same event loop, the configured event source priorities decide
+    which event source is dispatched first. If the signal handler is
+    processed first, it should leave the child processes for which
+    child process state change event sources are installed unreaped.</para>
+
+    <para><function>sd_event_add_child_pidfd()</function> is similar to
+    <function>sd_event_add_child()</function> but takes a file descriptor referencing the process ("pidfd")
+    instead of the numeric PID. A suitable file descriptor may be acquired via <citerefentry
+    project='man-pages'><refentrytitle>pidfd_open</refentrytitle><manvolnum>2</manvolnum></citerefentry> and
+    related calls. The passed file descriptor is not closed when the event source is freed again, unless
+    <function>sd_event_source_set_child_pidfd_own()</function> is used to turn this behaviour on. Note that
+    regardless which of <function>sd_event_add_child()</function> and
+    <function>sd_event_add_child_pidfd()</function> is used for allocating an event source, the watched
+    process has to be a direct child process of the invoking process. Also in both cases
+    <constant>SIGCHLD</constant> has to be blocked in the invoking process.</para>
+
+    <para><function>sd_event_source_get_child_pid()</function>
+    retrieves the configured PID of a child process state change event
+    source created previously with
+    <function>sd_event_add_child()</function>. It takes the event
+    source object as the <parameter>source</parameter> parameter and a
+    pointer to a <type>pid_t</type> variable to return the process ID
+    in.
+    </para>
+
+    <para><function>sd_event_source_get_child_pidfd()</function> retrieves the file descriptor referencing
+    the watched process ("pidfd") if this functionality is available. On kernels that support the concept the
+    event loop will make use of pidfds to watch child processes, regardless if the individual event sources
+    are allocated via <function>sd_event_add_child()</function> or
+    <function>sd_event_add_child_pidfd()</function>. If the latter call was used to allocate the event
+    source, this function returns the file descriptor used for allocation. On kernels that do not support the
+    pidfd concept this function will fail with <constant>EOPNOTSUPP</constant>. This call takes the event
+    source object as the <parameter>source</parameter> parameter and returns the numeric file descriptor.
+    </para>
+
+    <para><function>sd_event_source_get_child_pidfd_own()</function> may be used to query whether the pidfd
+    the event source encapsulates shall be closed when the event source is freed. This function returns zero
+    if the pidfd shall be left open, and positive if it shall be closed automatically. By default this
+    setting defaults to on if the event source was allocated via <function>sd_event_add_child()</function>
+    and off if it was allocated via <function>sd_event_add_child_pidfd()</function>. The
+    <function>sd_event_source_set_child_pidfd_own()</function> function may be used to change the setting and
+    takes a boolean parameter with the new setting.</para>
+
+    <para><function>sd_event_source_get_child_process_own()</function> may be used to query whether the
+    process the event source watches shall be killed (with <constant>SIGKILL</constant>) and reaped when the
+    event source is freed. This function returns zero if the process shell be left running, and positive if
+    it shall be killed and reaped automatically. By default this setting defaults to off. The
+    <function>sd_event_source_set_child_process_own()</function> function may be used to change the setting
+    and takes a boolean parameter with the new setting. Note that currently if the calling process is
+    terminated abnormally the watched process might survive even thought the event source ceases to
+    exist. This behaviour might change eventually.</para>
+
+    <para><function>sd_event_source_send_child_signal()</function> may be used to send a UNIX signal to the
+    watched process. If the pidfd concept is supported in the kernel, this is implemented via <citerefentry
+    project='man-pages'><refentrytitle>pidfd_send_signal</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+    and otherwise via <citerefentry
+    project='man-pages'><refentrytitle>rt_sigqueueinfo</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+    (or via <citerefentry
+    project='man-pages'><refentrytitle>kill</refentrytitle><manvolnum>2</manvolnum></citerefentry> in case
+    <parameter>info</parameter> is <constant>NULL</constant>). The specified parameters match those of these
+    underlying system calls, except that the <parameter>info</parameter> is never modified (and is thus
+    declared constant). Like for the underlying system calls, the <parameter>flags</parameter> parameter
+    currently must be zero.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, these functions return 0 or a positive
+    integer. On failure, they return a negative errno-style error
+    code.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-ENOMEM</constant></term>
+
+          <listitem><para>Not enough memory to allocate an object.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>An invalid argument has been passed. This includes
+          specifying an empty mask in <parameter>options</parameter> or a mask
+          which contains values different than a combination of
+          <constant>WEXITED</constant>, <constant>WSTOPPED</constant>, and
+          <constant>WCONTINUED</constant>.
+          </para></listitem>
+
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EBUSY</constant></term>
+
+          <listitem><para>A handler is already installed for this child process, or
+          <constant>SIGCHLD</constant> is not blocked.</para></listitem>
+
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ESTALE</constant></term>
+
+          <listitem><para>The event loop is already terminated.</para></listitem>
+
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ECHILD</constant></term>
+
+          <listitem><para>The event loop has been created in a different process, library or module instance.</para></listitem>
+
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EDOM</constant></term>
+
+          <listitem><para>The passed event source is not a child process event source.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EOPNOTSUPP</constant></term>
+
+          <listitem><para>A pidfd was requested but the kernel does not support this concept.</para>
+
+          <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+        </varlistentry>
+
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>Example</title>
+
+    <example>
+      <title>Exit loop when the child terminates</title>
+
+      <programlisting><xi:include href="event-quick-child.c" parse="text" /></programlisting>
+    </example>
+  </refsect1>
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_event_add_child()</function>,
+    <function>sd_event_child_handler_t()</function>, and
+    <function>sd_event_source_get_child_pid()</function> were added in version 217.</para>
+    <para><function>sd_event_add_child_pidfd()</function>,
+    <function>sd_event_source_get_child_pidfd()</function>,
+    <function>sd_event_source_get_child_pidfd_own()</function>,
+    <function>sd_event_source_set_child_pidfd_own()</function>,
+    <function>sd_event_source_get_child_process_own()</function>,
+    <function>sd_event_source_set_child_process_own()</function>, and
+    <function>sd_event_source_send_child_signal()</function> were added in version 245.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_now</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_io</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_time</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_inotify</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_defer</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_source_set_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_source_set_priority</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_source_set_userdata</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_source_set_description</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_source_set_floating</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>waitid</refentrytitle><manvolnum>2</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>sigprocmask</refentrytitle><manvolnum>2</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>pthread_sigmask</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>pidfd_open</refentrytitle><manvolnum>2</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>pidfd_send_signal</refentrytitle><manvolnum>2</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>rt_sigqueueinfo</refentrytitle><manvolnum>2</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>kill</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_event_add_defer.xml b/man/sd_event_add_defer.xml
new file mode 100644
index 0000000..de9125f
--- /dev/null
+++ b/man/sd_event_add_defer.xml
@@ -0,0 +1,210 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_event_add_defer" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_event_add_defer</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_event_add_defer</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_event_add_defer</refname>
+    <refname>sd_event_add_post</refname>
+    <refname>sd_event_add_exit</refname>
+    <refname>sd_event_handler_t</refname>
+
+    <refpurpose>Add static event sources to an event loop</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-event.h&gt;</funcsynopsisinfo>
+
+      <funcsynopsisinfo><token>typedef</token> struct sd_event_source sd_event_source;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>typedef int (*<function>sd_event_handler_t</function>)</funcdef>
+        <paramdef>sd_event_source *<parameter>s</parameter></paramdef>
+        <paramdef>void *<parameter>userdata</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_event_add_defer</function></funcdef>
+        <paramdef>sd_event *<parameter>event</parameter></paramdef>
+        <paramdef>sd_event_source **<parameter>source</parameter></paramdef>
+        <paramdef>sd_event_handler_t <parameter>handler</parameter></paramdef>
+        <paramdef>void *<parameter>userdata</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_event_add_post</function></funcdef>
+        <paramdef>sd_event *<parameter>event</parameter></paramdef>
+        <paramdef>sd_event_source **<parameter>source</parameter></paramdef>
+        <paramdef>sd_event_handler_t <parameter>handler</parameter></paramdef>
+        <paramdef>void *<parameter>userdata</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_event_add_exit</function></funcdef>
+        <paramdef>sd_event *<parameter>event</parameter></paramdef>
+        <paramdef>sd_event_source **<parameter>source</parameter></paramdef>
+        <paramdef>sd_event_handler_t <parameter>handler</parameter></paramdef>
+        <paramdef>void *<parameter>userdata</parameter></paramdef>
+      </funcprototype>
+
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>These three functions add new static event sources to an event loop. The event loop object is
+    specified in the <parameter>event</parameter> parameter, the event source object is returned in the
+    <parameter>source</parameter> parameter. The event sources are enabled statically and will "fire" when
+    the event loop is run and the conditions described below are met.</para>
+
+    <para>The <parameter>handler</parameter> is a function to call or <constant>NULL</constant>. The handler
+    function will be passed the <parameter>userdata</parameter> pointer, which may be chosen freely by the
+    caller. The handler may return negative to signal an error (see below), other return values are
+    ignored. If <parameter>handler</parameter> is <constant>NULL</constant>, a default handler that calls
+    <citerefentry><refentrytitle>sd_event_exit</refentrytitle><manvolnum>3</manvolnum></citerefentry> will be
+    used.</para>
+
+    <para><function>sd_event_add_defer()</function> adds a new event
+    source that will be dispatched instantly, before the event loop
+    goes to sleep again and waits for new events. By default, the
+    handler will be called once
+    (<constant>SD_EVENT_ONESHOT</constant>). Note that if the event
+    source is set to <constant>SD_EVENT_ON</constant> the event loop
+    will never go to sleep again, but continuously call the handler,
+    possibly interleaved with other event sources.</para>
+
+    <para><function>sd_event_add_post()</function> adds a new event
+    source that is run before the event loop will sleep and wait
+    for new events, but only after at least one other non-post event
+    source was dispatched. By default, the source is enabled
+    permanently (<constant>SD_EVENT_ON</constant>). Note that this
+    event source type will still allow the event loop to go to sleep
+    again, even if set to <constant>SD_EVENT_ON</constant>, as long as
+    no other event source is ever triggered.</para>
+
+    <para><function>sd_event_add_exit()</function> adds a new event
+    source that will be dispatched when the event loop is terminated
+    with <citerefentry><refentrytitle>sd_event_exit</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para>
+
+    <para>The
+    <citerefentry><refentrytitle>sd_event_source_set_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    function may be used to enable the event source permanently
+    (<constant>SD_EVENT_ON</constant>) or to make it fire just once
+    (<constant>SD_EVENT_ONESHOT</constant>).</para>
+
+    <para>If the handler function returns a negative error code, it will either be disabled after the
+    invocation, even if the <constant>SD_EVENT_ON</constant> mode was requested before, or it will cause the
+    loop to terminate, see
+    <citerefentry><refentrytitle>sd_event_source_set_exit_on_failure</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+    </para>
+
+    <para>To destroy an event source object use
+    <citerefentry><refentrytitle>sd_event_source_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    but note that the event source is only removed from the event loop
+    when all references to the event source are dropped. To make sure
+    an event source does not fire anymore, even when there's still a
+    reference to it kept, consider setting the event source to
+    <constant>SD_EVENT_OFF</constant> with
+    <citerefentry><refentrytitle>sd_event_source_set_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para>
+
+    <para>If the second parameter of these functions is passed as <constant>NULL</constant> no reference to
+    the event source object is returned. In this case the event source is considered "floating", and will be
+    destroyed implicitly when the event loop itself is destroyed.</para>
+
+    <para>If the <parameter>handler</parameter> parameter to <function>sd_event_add_defer()</function> or
+    <function>sd_event_add_post()</function> is <constant>NULL</constant>, and the event source fires, this
+    will be considered a request to exit the event loop. In this case, the <parameter>userdata</parameter>
+    parameter, cast to an integer, is passed as the exit code parameter to
+    <citerefentry><refentrytitle>sd_event_exit</refentrytitle><manvolnum>3</manvolnum></citerefentry>. Similar
+    functionality is not available for <function>sd_event_add_exit()</function>, as these types of event
+    sources are only dispatched when exiting anyway.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, these functions return 0 or a positive
+    integer. On failure, they return a negative errno-style error
+    code.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-ENOMEM</constant></term>
+
+          <listitem><para>Not enough memory to allocate an object.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>An invalid argument has been passed.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ESTALE</constant></term>
+
+          <listitem><para>The event loop is already terminated.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ECHILD</constant></term>
+
+          <listitem><para>The event loop has been created in a different process, library or module instance.</para></listitem>
+        </varlistentry>
+
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_event_add_defer()</function>,
+    <function>sd_event_add_post()</function>,
+    <function>sd_event_add_exit()</function>, and
+    <function>sd_event_handler_t()</function> were added in version 217.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_now</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_io</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_time</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_child</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_inotify</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_source_set_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_source_set_priority</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_source_set_userdata</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_source_set_description</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_source_set_floating</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_exit</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_event_add_inotify.xml b/man/sd_event_add_inotify.xml
new file mode 100644
index 0000000..7781d8e
--- /dev/null
+++ b/man/sd_event_add_inotify.xml
@@ -0,0 +1,246 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_event_add_inotify" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_event_add_inotify</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_event_add_inotify</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_event_add_inotify</refname>
+    <refname>sd_event_add_inotify_fd</refname>
+    <refname>sd_event_source_get_inotify_mask</refname>
+    <refname>sd_event_inotify_handler_t</refname>
+
+    <refpurpose>Add an "inotify" file system inode event source to an event loop</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-event.h&gt;</funcsynopsisinfo>
+
+      <funcsynopsisinfo><token>typedef</token> struct sd_event_source sd_event_source;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>typedef int (*<function>sd_event_inotify_handler_t</function>)</funcdef>
+        <paramdef>sd_event_source *<parameter>s</parameter></paramdef>
+        <paramdef>const struct inotify_event *<parameter>event</parameter></paramdef>
+        <paramdef>void *<parameter>userdata</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_event_add_inotify</function></funcdef>
+        <paramdef>sd_event *<parameter>event</parameter></paramdef>
+        <paramdef>sd_event_source **<parameter>source</parameter></paramdef>
+        <paramdef>const char *<parameter>path</parameter></paramdef>
+        <paramdef>uint32_t <parameter>mask</parameter></paramdef>
+        <paramdef>sd_event_inotify_handler_t <parameter>handler</parameter></paramdef>
+        <paramdef>void *<parameter>userdata</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_event_add_inotify_fd</function></funcdef>
+        <paramdef>sd_event *<parameter>event</parameter></paramdef>
+        <paramdef>sd_event_source **<parameter>source</parameter></paramdef>
+        <paramdef>int <parameter>fd</parameter></paramdef>
+        <paramdef>uint32_t <parameter>mask</parameter></paramdef>
+        <paramdef>sd_event_inotify_handler_t <parameter>handler</parameter></paramdef>
+        <paramdef>void *<parameter>userdata</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_event_source_get_inotify_mask</function></funcdef>
+        <paramdef>sd_event_source *<parameter>source</parameter></paramdef>
+        <paramdef>uint32_t *<parameter>mask</parameter></paramdef>
+      </funcprototype>
+
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_event_add_inotify()</function> adds a new <citerefentry
+    project='man-pages'><refentrytitle>inotify</refentrytitle><manvolnum>7</manvolnum></citerefentry> file
+    system inode event source to an event loop. The event loop object is specified in the
+    <parameter>event</parameter> parameter, the event source object is returned in the
+    <parameter>source</parameter> parameter. The <parameter>path</parameter> parameter specifies the path of
+    the file system inode to watch. The <parameter>mask</parameter> parameter specifies which types of inode
+    events to watch specifically. It must contain an OR-ed combination of <constant>IN_ACCESS</constant>,
+    <constant>IN_ATTRIB</constant>, <constant>IN_CLOSE_WRITE</constant>, … flags. See <citerefentry
+    project='man-pages'><refentrytitle>inotify</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
+    further information.</para>
+
+    <para>The <parameter>handler</parameter> must reference a function to call when the inode changes or
+    <constant>NULL</constant>. The handler function will be passed the <parameter>userdata</parameter> pointer,
+    which may be chosen freely by the caller. The handler also receives a pointer to a <structname>struct
+    inotify_event</structname> structure containing information about the inode event. The handler may return
+    negative to signal an error (see below), other return values are ignored. If
+    <parameter>handler</parameter> is <constant>NULL</constant>, a default handler that calls
+    <citerefentry><refentrytitle>sd_event_exit</refentrytitle><manvolnum>3</manvolnum></citerefentry> will be
+    used.</para>
+
+    <para><function>sd_event_add_inotify_fd()</function> is identical to
+    <function>sd_event_add_inotify()</function>, except that it takes a file descriptor to an inode (possibly
+    an <constant>O_PATH</constant> one, but any other will do too) instead of a path in the file system.
+    </para>
+
+    <para>If multiple event sources are installed for the same inode the backing inotify watch descriptor is
+    automatically shared. The mask parameter may contain any flag defined by the inotify API, with the exception of
+    <constant>IN_MASK_ADD</constant>.</para>
+
+    <para>The handler is enabled continuously (<constant>SD_EVENT_ON</constant>), but this may be changed with
+    <citerefentry><refentrytitle>sd_event_source_set_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+    Alternatively, the <constant>IN_ONESHOT</constant> mask flag may be used to request
+    <constant>SD_EVENT_ONESHOT</constant> mode. If the handler function returns a negative error code, it
+    will be disabled after the invocation, even if the <constant>SD_EVENT_ON</constant> mode was requested
+    before.</para>
+
+    <para>As a special limitation the priority of inotify event sources may only be altered (see
+    <citerefentry><refentrytitle>sd_event_source_set_priority</refentrytitle><manvolnum>3</manvolnum></citerefentry>)
+    in the time between creation of the event source object with <function>sd_event_add_inotify()</function> and the
+    beginning of the next event loop iteration. Attempts of changing the priority any later will be refused. Consider
+    freeing and allocating a new inotify event source to change the priority at that point.</para>
+
+    <para>To destroy an event source object use
+    <citerefentry><refentrytitle>sd_event_source_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry>, but note
+    that the event source is only removed from the event loop when all references to the event source are dropped. To
+    make sure an event source does not fire anymore, even when there's still a reference to it kept, consider disabling
+    it with
+    <citerefentry><refentrytitle>sd_event_source_set_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para>
+
+    <para>If the second parameter of <function>sd_event_add_inotify()</function> is passed as
+    <constant>NULL</constant> no reference to the event source object is returned. In this case the event
+    source is considered "floating", and will be destroyed implicitly when the event loop itself is
+    destroyed.</para>
+
+    <para>If the <parameter>handler</parameter> parameter to <function>sd_event_add_inotify()</function> is
+    <constant>NULL</constant>, and the event source fires, this will be considered a request to exit the
+    event loop. In this case, the <parameter>userdata</parameter> parameter, cast to an integer, is passed as
+    the exit code parameter to
+    <citerefentry><refentrytitle>sd_event_exit</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para>
+
+    <para><function>sd_event_source_get_inotify_mask()</function> retrieves the configured inotify watch mask of an
+    event source created previously with <function>sd_event_add_inotify()</function>. It takes the event source object
+    as the <parameter>source</parameter> parameter and a pointer to a <type>uint32_t</type> variable to return the mask
+    in.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, these functions return 0 or a positive integer. On failure, they return a negative errno-style
+    error code.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-ENOMEM</constant></term>
+
+          <listitem><para>Not enough memory to allocate an object.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>An invalid argument has been passed. This includes specifying a mask with
+          <constant>IN_MASK_ADD</constant> set.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ESTALE</constant></term>
+
+          <listitem><para>The event loop is already terminated.</para></listitem>
+
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ECHILD</constant></term>
+
+          <listitem><para>The event loop has been created in a different process, library or module instance.</para></listitem>
+
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EDOM</constant></term>
+
+          <listitem><para>The passed event source is not an inotify process event source.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EBADF</constant></term>
+
+          <listitem><para>The passed file descriptor is not valid.</para>
+
+          <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOSYS</constant></term>
+
+          <listitem><para><function>sd_event_add_inotify_fd()</function> was called without
+          <filename>/proc/</filename> mounted.</para>
+
+          <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+        </varlistentry>
+
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <refsect1>
+    <title>Examples</title>
+
+    <example>
+      <title>A simple program that uses inotify to monitor one or two directories</title>
+
+      <programlisting><xi:include href="inotify-watch-tmp.c" parse="text" /></programlisting>
+    </example>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_event_inotify_handler_t()</function>,
+    <function>sd_event_add_inotify()</function>, and
+    <function>sd_event_source_get_inotify_mask()</function> were added in version 239.</para>
+    <para><function>sd_event_add_inotify_fd()</function> was added in version 250.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_now</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_io</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_time</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_defer</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_child</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_source_set_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_source_set_priority</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_source_set_userdata</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_source_set_description</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_source_set_floating</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>waitid</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_event_add_io.xml b/man/sd_event_add_io.xml
new file mode 100644
index 0000000..da0fa58
--- /dev/null
+++ b/man/sd_event_add_io.xml
@@ -0,0 +1,335 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_event_add_io" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_event_add_io</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_event_add_io</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_event_add_io</refname>
+    <refname>sd_event_source_get_io_events</refname>
+    <refname>sd_event_source_set_io_events</refname>
+    <refname>sd_event_source_get_io_revents</refname>
+    <refname>sd_event_source_get_io_fd</refname>
+    <refname>sd_event_source_set_io_fd</refname>
+    <refname>sd_event_source_get_io_fd_own</refname>
+    <refname>sd_event_source_set_io_fd_own</refname>
+    <refname>sd_event_source</refname>
+    <refname>sd_event_io_handler_t</refname>
+
+    <refpurpose>Add an I/O event source to an event loop</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-event.h&gt;</funcsynopsisinfo>
+
+      <funcsynopsisinfo><token>typedef</token> struct sd_event_source sd_event_source;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>typedef int (*<function>sd_event_io_handler_t</function>)</funcdef>
+        <paramdef>sd_event_source *<parameter>s</parameter></paramdef>
+        <paramdef>int <parameter>fd</parameter></paramdef>
+        <paramdef>uint32_t <parameter>revents</parameter></paramdef>
+        <paramdef>void *<parameter>userdata</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_event_add_io</function></funcdef>
+        <paramdef>sd_event *<parameter>event</parameter></paramdef>
+        <paramdef>sd_event_source **<parameter>source</parameter></paramdef>
+        <paramdef>int <parameter>fd</parameter></paramdef>
+        <paramdef>uint32_t <parameter>events</parameter></paramdef>
+        <paramdef>sd_event_io_handler_t <parameter>handler</parameter></paramdef>
+        <paramdef>void *<parameter>userdata</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_event_source_get_io_events</function></funcdef>
+        <paramdef>sd_event_source *<parameter>source</parameter></paramdef>
+        <paramdef>uint32_t *<parameter>events</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_event_source_set_io_events</function></funcdef>
+        <paramdef>sd_event_source *<parameter>source</parameter></paramdef>
+        <paramdef>uint32_t <parameter>events</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_event_source_get_io_revents</function></funcdef>
+        <paramdef>sd_event_source *<parameter>source</parameter></paramdef>
+        <paramdef>uint32_t *<parameter>revents</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_event_source_get_io_fd</function></funcdef>
+        <paramdef>sd_event_source *<parameter>source</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_event_source_set_io_fd</function></funcdef>
+        <paramdef>sd_event_source *<parameter>source</parameter></paramdef>
+        <paramdef>int <parameter>fd</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_event_source_get_io_fd_own</function></funcdef>
+        <paramdef>sd_event_source *<parameter>source</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_event_source_set_io_fd_own</function></funcdef>
+        <paramdef>sd_event_source *<parameter>source</parameter></paramdef>
+        <paramdef>int <parameter>b</parameter></paramdef>
+      </funcprototype>
+
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_event_add_io()</function> adds a new I/O event source to an event loop. The event loop
+    object is specified in the <parameter>event</parameter> parameter, the event source object is returned in
+    the <parameter>source</parameter> parameter. The <parameter>fd</parameter> parameter takes the UNIX file
+    descriptor to watch, which may refer to a socket, a FIFO, a message queue, a serial connection, a
+    character device, or any other file descriptor compatible with Linux <citerefentry
+    project='man-pages'><refentrytitle>epoll</refentrytitle><manvolnum>7</manvolnum></citerefentry>. The
+    <parameter>events</parameter> parameter takes a bit mask of events to watch for, a combination of the
+    following event flags: <constant>EPOLLIN</constant>, <constant>EPOLLOUT</constant>,
+    <constant>EPOLLRDHUP</constant>, <constant>EPOLLPRI</constant>, and <constant>EPOLLET</constant>, see
+    <citerefentry
+    project='man-pages'><refentrytitle>epoll_ctl</refentrytitle><manvolnum>2</manvolnum></citerefentry> for
+    details. Note that not all file descriptors are compatible with epoll, for example regular file or
+    directories are not. If this function is called with a file descriptor that does not support epoll,
+    <constant>-EPERM</constant> is returned (also see below). In most cases such file descriptors may be
+    treated as always-readable or always-writable, so that IO event watching is unnecessary.</para>
+
+    <para>The <parameter>handler</parameter> is a function to call when the event source is triggered or
+    <constant>NULL</constant>. The <parameter>userdata</parameter> pointer will be passed to the handler
+    function, and may be chosen freely by the caller. The handler will also be passed the file descriptor the
+    event was seen on, as well as the actual event flags. It's generally a subset of the events watched,
+    however may additionally include <constant>EPOLLERR</constant> and <constant>EPOLLHUP</constant>. The
+    handler may return negative to signal an error (see below), other return values are ignored. If
+    <parameter>handler</parameter> is <constant>NULL</constant>, a default handler that calls
+    <citerefentry><refentrytitle>sd_event_exit</refentrytitle><manvolnum>3</manvolnum></citerefentry> will be
+    used.</para>
+
+    <para>By default, an event source will stay enabled continuously (<constant>SD_EVENT_ON</constant>), but
+    this may be changed with
+    <citerefentry><refentrytitle>sd_event_source_set_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+    If the handler function returns a negative error code, it will either be disabled after the invocation,
+    even if the <constant>SD_EVENT_ON</constant> mode was requested before, or it will cause the loop to
+    terminate, see
+    <citerefentry><refentrytitle>sd_event_source_set_exit_on_failure</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+    Note that an event source set to <constant>SD_EVENT_ON</constant> will fire continuously unless data is
+    read from or written to the file descriptor to reset the mask of events seen.</para>
+
+    <para>Setting the I/O event mask to watch for to 0 does not mean
+    that the event source won't be triggered anymore, as
+    <constant>EPOLLHUP</constant> and <constant>EPOLLERR</constant>
+    may be triggered even with a zero event mask. To temporarily
+    disable an I/O event source use
+    <citerefentry><refentrytitle>sd_event_source_set_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    with <constant>SD_EVENT_OFF</constant> instead.</para>
+
+    <para>To destroy an event source object use
+    <citerefentry><refentrytitle>sd_event_source_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    but note that the event source is only removed from the event loop
+    when all references to the event source are dropped. To make sure
+    an event source does not fire anymore, even if it is still referenced,
+    disable the event source using
+    <citerefentry><refentrytitle>sd_event_source_set_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    with <constant>SD_EVENT_OFF</constant>.</para>
+
+    <para>If the second parameter of
+    <function>sd_event_add_io()</function> is
+    <constant>NULL</constant> no reference to the event source object
+    is returned. In this case the event source is considered
+    "floating", and will be destroyed implicitly when the event loop
+    itself is destroyed.</para>
+
+    <para>If the <parameter>handler</parameter> to <function>sd_event_add_io()</function> is
+    <constant>NULL</constant>, and the event source fires, this will be considered a request to exit the
+    event loop. In this case, the <parameter>userdata</parameter> parameter, cast to an integer, is passed as
+    the exit code parameter to
+    <citerefentry><refentrytitle>sd_event_exit</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para>
+
+    <para>Note that this call does not take possession of the file descriptor passed in, ownership (and thus
+    the duty to close it when it is no longer needed) remains with the caller. However, with the
+    <function>sd_event_source_set_io_fd_own()</function> call (see below) the event source may optionally
+    take ownership of the file descriptor after the event source has been created. In that case the file
+    descriptor is closed automatically as soon as the event source is released.</para>
+
+    <para>It is recommended to use
+    <function>sd_event_add_io()</function> only in conjunction with
+    file descriptors that have <constant>O_NONBLOCK</constant> set, to
+    ensure that all I/O operations from invoked handlers are properly
+    asynchronous and non-blocking. Using file descriptors without
+    <constant>O_NONBLOCK</constant> might result in unexpected
+    starvation of other event sources. See
+    <citerefentry project='man-pages'><refentrytitle>fcntl</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+    for details on enabling <constant>O_NONBLOCK</constant> mode.</para>
+
+    <para><function>sd_event_source_get_io_events()</function> retrieves
+    the configured mask of watched I/O events of an event source created
+    previously with <function>sd_event_add_io()</function>. It takes
+    the event source object and a pointer to a variable to store the
+    mask in.</para>
+
+    <para><function>sd_event_source_set_io_events()</function>
+    configures the mask of watched I/O events of an event source created
+    previously with <function>sd_event_add_io()</function>. It takes the
+    event source object and the new event mask.</para>
+
+    <para><function>sd_event_source_get_io_revents()</function>
+    retrieves the I/O event mask of currently seen but undispatched
+    events from an event source created previously with
+    <function>sd_event_add_io()</function>. It takes the event source
+    object and a pointer to a variable to store the event mask
+    in. When called from a handler function on the handler's event
+    source object this will return the same mask as passed to the
+    handler's <parameter>revents</parameter> parameter. This call is
+    primarily useful to check for undispatched events of an event
+    source from the handler of an unrelated (possibly higher priority)
+    event source. Note the relation between
+    <function>sd_event_source_get_pending()</function> and
+    <function>sd_event_source_get_io_revents()</function>: both
+    functions will report non-zero results when there's an event
+    pending for the event source, but the former applies to all event
+    source types, the latter only to I/O event sources.</para>
+
+    <para><function>sd_event_source_get_io_fd()</function> retrieves
+    the UNIX file descriptor of an event source created previously
+    with <function>sd_event_add_io()</function>. It takes the event
+    source object and returns the non-negative file descriptor
+    or a negative error number on error (see below).</para>
+
+    <para><function>sd_event_source_set_io_fd()</function>
+    changes the UNIX file descriptor of an I/O event source created
+    previously with <function>sd_event_add_io()</function>. It takes
+    the event source object and the new file descriptor.</para>
+
+    <para><function>sd_event_source_set_io_fd_own()</function> controls whether the file descriptor of the event source
+    shall be closed automatically when the event source is freed, i.e. whether it shall be considered 'owned' by the
+    event source object. By default it is not closed automatically, and the application has to do this on its own. The
+    <parameter>b</parameter> parameter is a boolean parameter: if zero, the file descriptor is not closed automatically
+    when the event source is freed, otherwise it is closed.</para>
+
+    <para><function>sd_event_source_get_io_fd_own()</function> may be used to query the current setting of the file
+    descriptor ownership boolean flag as set with <function>sd_event_source_set_io_fd_own()</function>. It returns
+    positive if the file descriptor is closed automatically when the event source is destroyed, zero if not, and
+    negative on error.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, these functions return 0 or a positive
+    integer. On failure, they return a negative errno-style error
+    code.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned values may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-ENOMEM</constant></term>
+
+          <listitem><para>Not enough memory to allocate an object.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>An invalid argument has been passed.</para></listitem>
+
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ESTALE</constant></term>
+
+          <listitem><para>The event loop is already terminated.</para></listitem>
+
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ECHILD</constant></term>
+
+          <listitem><para>The event loop has been created in a different process, library or module instance.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EDOM</constant></term>
+
+          <listitem><para>The passed event source is not an I/O event source.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EPERM</constant></term>
+
+          <listitem><para>The passed file descriptor does not support the <citerefentry
+          project='man-pages'><refentrytitle>epoll</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+          API, for example because it is a regular file or directory. See <citerefentry
+          project='man-pages'><refentrytitle>epoll_ctl</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+          for details.</para>
+
+          <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_event_io_handler_t()</function>,
+    <function>sd_event_add_io()</function>,
+    <function>sd_event_source_get_io_events()</function>,
+    <function>sd_event_source_set_io_events()</function>,
+    <function>sd_event_source_get_io_revents()</function>,
+    <function>sd_event_source_get_io_fd()</function>, and
+    <function>sd_event_source_set_io_fd()</function> were added in version 229.</para>
+    <para><function>sd_event_source_get_io_fd_own()</function> and
+    <function>sd_event_source_set_io_fd_own()</function> were added in version 239.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_now</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_time</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_child</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_inotify</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_defer</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_source_set_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_source_set_priority</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_source_set_userdata</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_source_set_description</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_source_get_pending</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_source_set_floating</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>epoll_ctl</refentrytitle><manvolnum>2</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>epoll</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_event_add_memory_pressure.xml b/man/sd_event_add_memory_pressure.xml
new file mode 100644
index 0000000..25c166e
--- /dev/null
+++ b/man/sd_event_add_memory_pressure.xml
@@ -0,0 +1,301 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_event_add_memory_pressure" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_event_add_memory_pressure</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_event_add_memory_pressure</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_event_add_memory_pressure</refname>
+    <refname>sd_event_source_set_memory_pressure_type</refname>
+    <refname>sd_event_source_set_memory_pressure_period</refname>
+    <refname>sd_event_trim_memory</refname>
+
+    <refpurpose>Add and configure an event source run as result of memory pressure</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-event.h&gt;</funcsynopsisinfo>
+
+      <funcsynopsisinfo><token>typedef</token> struct sd_event_source sd_event_source;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_event_add_memory_pressure</function></funcdef>
+        <paramdef>sd_event *<parameter>event</parameter></paramdef>
+        <paramdef>sd_event_source **<parameter>ret_source</parameter></paramdef>
+        <paramdef>sd_event_handler_t <parameter>handler</parameter></paramdef>
+        <paramdef>void *<parameter>userdata</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_event_source_set_memory_pressure_type</function></funcdef>
+        <paramdef>sd_event_source *<parameter>source</parameter></paramdef>
+        <paramdef>const char *<parameter>type</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_event_source_set_memory_pressure_period</function></funcdef>
+        <paramdef>sd_event_source *<parameter>source</parameter></paramdef>
+        <paramdef>uint64_t <parameter>threshold_usec</parameter></paramdef>
+        <paramdef>uint64_t <parameter>window_usec</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_event_trim_memory</function></funcdef>
+        <paramdef>void</paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_event_add_memory_pressure()</function> adds a new event source that is triggered
+    whenever memory pressure is seen. This functionality is built around the Linux kernel's <ulink
+    url="https://docs.kernel.org/accounting/psi.html">Pressure Stall Information (PSI)</ulink> logic.</para>
+
+    <para>Expects an event loop object as first parameter, and returns the allocated event source object in
+    the second parameter, on success. The <parameter>handler</parameter> parameter is a function to call when
+    memory pressure is seen, or <constant>NULL</constant>. The handler function will be passed the
+    <parameter>userdata</parameter> pointer, which may be chosen freely by the caller. The handler may return
+    negative to signal an error (see below), other return values are ignored. If
+    <parameter>handler</parameter> is <constant>NULL</constant>, a default handler that compacts allocation
+    caches maintained by <filename>libsystemd</filename> as well as glibc (via <citerefentry
+    project='man-pages'><refentrytitle>malloc_trim</refentrytitle><manvolnum>3</manvolnum></citerefentry>)
+    will be used.</para>
+
+    <para>To destroy an event source object use
+    <citerefentry><refentrytitle>sd_event_source_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    but note that the event source is only removed from the event loop when all references to the event
+    source are dropped. To make sure an event source does not fire anymore, even if it is still referenced,
+    disable the event source using
+    <citerefentry><refentrytitle>sd_event_source_set_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    with <constant>SD_EVENT_OFF</constant>.</para>
+
+    <para>If the second parameter of <function>sd_event_add_memory_pressure()</function> is
+    <constant>NULL</constant> no reference to the event source object is returned. In this case the event
+    source is considered "floating", and will be destroyed implicitly when the event loop itself is
+    destroyed.</para>
+
+    <para>The event source will fire according to the following logic:</para>
+
+    <orderedlist>
+      <listitem><para>If the
+      <varname>$MEMORY_PRESSURE_WATCH</varname>/<varname>$MEMORY_PRESSURE_WRITE</varname> environment
+      variables are set at the time the event source is established, it will watch the file, FIFO or AF_UNIX
+      socket specified via <varname>$MEMORY_PRESSURE_WATCH</varname> (which must contain an absolute path
+      name) for <constant>POLLPRI</constant> (in case it is a regular file) or <constant>POLLIN</constant>
+      events (otherwise). After opening the inode, it will write the (decoded) Base64 data provided via
+      <varname>$MEMORY_PRESSURE_WRITE</varname> into it before it starts polling on it (the variable may be
+      unset in which case this is skipped). Typically, if used, <varname>$MEMORY_PRESSURE_WATCH</varname>
+      will contain a path such as <filename>/proc/pressure/memory</filename> or a path to a specific
+      <filename>memory.pressure</filename> file in the control group file system
+      (cgroupfs).</para></listitem>
+
+      <listitem><para>If these environment variables are not set, the local PSI interface file
+      <filename>memory.pressure</filename> of the control group the invoking process is running in is
+      used.</para></listitem>
+
+      <listitem><para>If that file does not exist, the system-wide PSI interface file
+      <filename>/proc/pressure/memory</filename> is watched instead.</para></listitem>
+    </orderedlist>
+
+    <para>Or in other words: preferably any explicit configuration passed in by an invoking service manager
+    (or similar) is used as notification source, before falling back to local notifications of the service,
+    and finally to global notifications of the system.</para>
+
+    <para>Well-behaving services and applications are recommended to react to memory pressure events by
+    executing one or more of the following operations, in order to ensure optimal behaviour even on loaded
+    and resource-constrained systems:</para>
+
+    <itemizedlist>
+      <listitem><para>Release allocation caches such as <function>malloc_trim()</function> or similar, both
+      implemented in the libraries consumed by the program and in private allocation caches of the program
+      itself.</para></listitem>
+
+      <listitem><para>Release any other form of in-memory caches that can easily be recovered if
+      needed (e.g. browser caches).</para></listitem>
+
+      <listitem><para>Terminate idle worker threads or processes, or similar.</para></listitem>
+
+      <listitem><para>Even exit entirely from the program if it is idle and can be automatically started when
+      needed (for example via socket or bus activation).</para></listitem>
+    </itemizedlist>
+
+    <para>Any of the suggested operations should help easing memory pressure situations and allowing the
+    system to make progress by reclaiming the memory for other purposes.</para>
+
+    <para>This event source typically fires on memory pressure stalls, i.e. when operational latency above a
+    configured threshold already has been seen. This should be taken into consideration when discussing
+    whether later latency to re-aquire any released resources is acceptable: it's usually more important to
+    think of the latencies that already happened than those coming up in future.</para>
+
+    <para>The <function>sd_event_source_set_memory_pressure_type()</function> and
+    <function>sd_event_source_set_memory_pressure_period()</function> functions can be used to fine-tune the
+    PSI parameters for pressure notifications. The former takes either <literal>some</literal>,
+    <literal>full</literal> as second parameter, the latter takes threshold and period times in microseconds
+    as parameters. For details about these three parameters see the PSI documentation. Note that these two
+    calls must be invoked immediately after allocating the event source, as they must be configured before
+    polling begins. Also note that these calls will fail if memory pressure parameterization has been passed
+    in via the <varname>$MEMORY_PRESSURE_WATCH</varname>/<varname>$MEMORY_PRESSURE_WRITE</varname>
+    environment variables (or in other words: configuration supplied by a service manager wins over internal
+    settings).</para>
+
+    <para>The <function>sd_event_trim_memory()</function> function releases various internal allocation
+    caches maintained by <filename>libsystemd</filename> and then invokes glibc's <citerefentry
+    project='man-pages'><refentrytitle>malloc_trim</refentrytitle><manvolnum>3</manvolnum></citerefentry>. This
+    makes the operation executed when the handler function parameter of
+    <function>sd_event_add_memory_pressure</function> is passed as <constant>NULL</constant> directly
+    accessible for invocation at any time (see above). This function will log a structured log message at
+    <constant>LOG_DEBUG</constant> level (with message ID f9b0be465ad540d0850ad32172d57c21) about the memory
+    pressure operation.</para>
+
+    <para>For further details see <ulink url="https://systemd.io/MEMORY_PRESSURE">Memory Pressure Handling in
+    systemd</ulink>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, these functions return 0 or a positive
+    integer. On failure, they return a negative errno-style error
+    code.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-ENOMEM</constant></term>
+
+          <listitem><para>Not enough memory to allocate an object.</para>
+
+          <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>An invalid argument has been passed.</para>
+
+          <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EHOSTDOWN</constant></term>
+
+          <listitem><para>The <varname>$MEMORY_PRESSURE_WATCH</varname> variable has been set to the literal
+          string <filename>/dev/null</filename>, in order to explicitly disable memory pressure
+          handling.</para>
+
+          <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EBADMSG</constant></term>
+
+          <listitem><para>The <varname>$MEMORY_PRESSURE_WATCH</varname> variable has been set to an invalid
+          string, for example a relative rather than an absolute path.</para>
+
+          <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOTTY</constant></term>
+
+          <listitem><para>The <varname>$MEMORY_PRESSURE_WATCH</varname> variable points to a regular file
+          outside of the procfs or cgroupfs file systems.</para>
+
+          <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EOPNOTSUPP</constant></term>
+
+          <listitem><para>No configuration via <varname>$MEMORY_PRESSURE_WATCH</varname> has been specified
+          and the local kernel does not support the PSI interface.</para>
+
+          <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EBUSY</constant></term>
+
+          <listitem><para>This is returned by <function>sd_event_source_set_memory_pressure_type()</function>
+          and <function>sd_event_source_set_memory_pressure_period()</function> if invoked on event sources
+          at a time later than immediately after allocating them.</para>
+
+          <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ESTALE</constant></term>
+
+          <listitem><para>The event loop is already terminated.</para>
+
+          <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ECHILD</constant></term>
+
+          <listitem><para>The event loop has been created in a different process, library or module instance.</para>
+
+          <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EDOM</constant></term>
+
+          <listitem><para>The passed event source is not a signal event source.</para>
+
+          <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+        </varlistentry>
+
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_event_add_memory_pressure()</function>,
+    <function>sd_event_source_set_memory_pressure_type()</function>,
+    <function>sd_event_source_set_memory_pressure_period()</function>, and
+    <function>sd_event_trim_memory()</function> were added in version 254.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_io</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_time</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_child</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_inotify</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_defer</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_source_set_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_source_set_description</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_source_set_userdata</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_source_set_floating</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_event_add_signal.xml b/man/sd_event_add_signal.xml
new file mode 100644
index 0000000..6fb0d1b
--- /dev/null
+++ b/man/sd_event_add_signal.xml
@@ -0,0 +1,214 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_event_add_signal" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_event_add_signal</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_event_add_signal</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_event_add_signal</refname>
+    <refname>sd_event_source_get_signal</refname>
+    <refname>sd_event_signal_handler_t</refname>
+    <refname>SD_EVENT_SIGNAL_PROCMASK</refname>
+
+    <refpurpose>Add a UNIX process signal event source to an event
+    loop</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-event.h&gt;</funcsynopsisinfo>
+
+      <funcsynopsisinfo><token>typedef</token> struct sd_event_source sd_event_source;</funcsynopsisinfo>
+
+      <funcsynopsisinfo><constant>SD_EVENT_SIGNAL_PROCMASK</constant></funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>typedef int (*<function>sd_event_signal_handler_t</function>)</funcdef>
+        <paramdef>sd_event_source *<parameter>s</parameter></paramdef>
+        <paramdef>const struct signalfd_siginfo *<parameter>si</parameter></paramdef>
+        <paramdef>void *<parameter>userdata</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_event_add_signal</function></funcdef>
+        <paramdef>sd_event *<parameter>event</parameter></paramdef>
+        <paramdef>sd_event_source **<parameter>source</parameter></paramdef>
+        <paramdef>int <parameter>signal</parameter></paramdef>
+        <paramdef>sd_event_signal_handler_t <parameter>handler</parameter></paramdef>
+        <paramdef>void *<parameter>userdata</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_event_source_get_signal</function></funcdef>
+        <paramdef>sd_event_source *<parameter>source</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_event_add_signal()</function> adds a new UNIX process signal event source to an event
+    loop. The event loop object is specified in the <parameter>event</parameter> parameter, and the event
+    source object is returned in the <parameter>source</parameter> parameter. The
+    <parameter>signal</parameter> parameter specifies the numeric signal to be handled (see <citerefentry
+    project='man-pages'><refentrytitle>signal</refentrytitle><manvolnum>7</manvolnum></citerefentry>).</para>
+
+    <para>The <parameter>handler</parameter> parameter is a function to call when the signal is received or
+    <constant>NULL</constant>. The handler function will be passed the <parameter>userdata</parameter>
+    pointer, which may be chosen freely by the caller. The handler also receives a pointer to a
+    <structname>signalfd_siginfo</structname> structure containing information about the received signal. See
+    <citerefentry
+    project='man-pages'><refentrytitle>signalfd</refentrytitle><manvolnum>2</manvolnum></citerefentry> for
+    further information. The handler may return negative to signal an error (see below), other return values
+    are ignored. If <parameter>handler</parameter> is <constant>NULL</constant>, a default handler that calls
+    <citerefentry><refentrytitle>sd_event_exit</refentrytitle><manvolnum>3</manvolnum></citerefentry> will be
+    used.</para>
+
+    <para>Only a single handler may be installed for a specific signal. The signal must be blocked in all
+    threads before this function is called (using <citerefentry
+    project='man-pages'><refentrytitle>sigprocmask</refentrytitle><manvolnum>2</manvolnum></citerefentry> or
+    <citerefentry
+    project='man-pages'><refentrytitle>pthread_sigmask</refentrytitle><manvolnum>3</manvolnum></citerefentry>). For
+    convenience, if the special flag <constant>SD_EVENT_SIGNAL_PROCMASK</constant> is ORed into the specified
+    signal the signal will be automatically masked as necessary, for the calling thread. Note that this only
+    works reliably if the signal is already masked in all other threads of the process, or if there are no
+    other threads at the moment of invocation.</para>
+
+    <para>By default, the event source is enabled permanently (<constant>SD_EVENT_ON</constant>), but this
+    may be changed with
+    <citerefentry><refentrytitle>sd_event_source_set_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+    If the handler function returns a negative error code, it will either be disabled after the invocation,
+    even if the <constant>SD_EVENT_ON</constant> mode was requested before, or it will cause the loop to
+    terminate, see
+    <citerefentry><refentrytitle>sd_event_source_set_exit_on_failure</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+    </para>
+
+    <para>To destroy an event source object use
+    <citerefentry><refentrytitle>sd_event_source_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    but note that the event source is only removed from the event loop
+    when all references to the event source are dropped. To make sure
+    an event source does not fire anymore, even if it is still referenced,
+    disable the event source using
+    <citerefentry><refentrytitle>sd_event_source_set_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    with <constant>SD_EVENT_OFF</constant>.</para>
+
+    <para>If the second parameter of
+    <function>sd_event_add_signal()</function> is
+    <constant>NULL</constant> no reference to the event source object
+    is returned. In this case the event source is considered
+    "floating", and will be destroyed implicitly when the event loop
+    itself is destroyed.</para>
+
+    <para>If the <parameter>handler</parameter> parameter to <function>sd_event_add_signal()</function> is
+    <constant>NULL</constant>, and the event source fires, this will be considered a request to exit the
+    event loop. In this case, the <parameter>userdata</parameter> parameter, cast to an integer, is passed as
+    the exit code parameter to
+    <citerefentry><refentrytitle>sd_event_exit</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para>
+
+    <para><function>sd_event_source_get_signal()</function> returns
+    the configured signal number of an event source created previously
+    with <function>sd_event_add_signal()</function>. It takes the
+    event source object as the <parameter>source</parameter>
+    parameter.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, these functions return 0 or a positive
+    integer. On failure, they return a negative errno-style error
+    code.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-ENOMEM</constant></term>
+
+          <listitem><para>Not enough memory to allocate an object.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>An invalid argument has been passed.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EBUSY</constant></term>
+
+          <listitem><para>A handler is already installed for this
+          signal or the signal was not blocked previously.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ESTALE</constant></term>
+
+          <listitem><para>The event loop is already terminated.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ECHILD</constant></term>
+
+          <listitem><para>The event loop has been created in a different process, library or module instance.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EDOM</constant></term>
+
+          <listitem><para>The passed event source is not a signal event source.</para></listitem>
+        </varlistentry>
+
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_event_add_signal()</function>,
+    <function>sd_event_signal_handler_t()</function>, and
+    <function>sd_event_source_get_signal()</function> were added in version 217.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_now</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_io</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_time</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_child</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_inotify</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_defer</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_source_set_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_source_set_description</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_source_set_userdata</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_source_set_floating</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>signal</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>signalfd</refentrytitle><manvolnum>2</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>sigprocmask</refentrytitle><manvolnum>2</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>pthread_sigmask</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_event_add_time.xml b/man/sd_event_add_time.xml
new file mode 100644
index 0000000..d3a7373
--- /dev/null
+++ b/man/sd_event_add_time.xml
@@ -0,0 +1,341 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_event_add_time" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_event_add_time</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_event_add_time</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_event_add_time</refname>
+    <refname>sd_event_add_time_relative</refname>
+    <refname>sd_event_source_get_time</refname>
+    <refname>sd_event_source_set_time</refname>
+    <refname>sd_event_source_set_time_relative</refname>
+    <refname>sd_event_source_get_time_accuracy</refname>
+    <refname>sd_event_source_set_time_accuracy</refname>
+    <refname>sd_event_source_get_time_clock</refname>
+    <refname>sd_event_time_handler_t</refname>
+
+    <refpurpose>Add a timer event source to an event loop</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-event.h&gt;</funcsynopsisinfo>
+
+      <funcsynopsisinfo><token>typedef</token> struct sd_event_source sd_event_source;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>typedef int (*<function>sd_event_time_handler_t</function>)</funcdef>
+        <paramdef>sd_event_source *<parameter>s</parameter></paramdef>
+        <paramdef>uint64_t <parameter>usec</parameter></paramdef>
+        <paramdef>void *<parameter>userdata</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_event_add_time</function></funcdef>
+        <paramdef>sd_event *<parameter>event</parameter></paramdef>
+        <paramdef>sd_event_source **<parameter>source</parameter></paramdef>
+        <paramdef>clockid_t <parameter>clock</parameter></paramdef>
+        <paramdef>uint64_t <parameter>usec</parameter></paramdef>
+        <paramdef>uint64_t <parameter>accuracy</parameter></paramdef>
+        <paramdef>sd_event_time_handler_t <parameter>handler</parameter></paramdef>
+        <paramdef>void *<parameter>userdata</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_event_add_time_relative</function></funcdef>
+        <paramdef>sd_event *<parameter>event</parameter></paramdef>
+        <paramdef>sd_event_source **<parameter>source</parameter></paramdef>
+        <paramdef>clockid_t <parameter>clock</parameter></paramdef>
+        <paramdef>uint64_t <parameter>usec</parameter></paramdef>
+        <paramdef>uint64_t <parameter>accuracy</parameter></paramdef>
+        <paramdef>sd_event_time_handler_t <parameter>handler</parameter></paramdef>
+        <paramdef>void *<parameter>userdata</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_event_source_get_time</function></funcdef>
+        <paramdef>sd_event_source *<parameter>source</parameter></paramdef>
+        <paramdef>uint64_t *<parameter>usec</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_event_source_set_time</function></funcdef>
+        <paramdef>sd_event_source *<parameter>source</parameter></paramdef>
+        <paramdef>uint64_t <parameter>usec</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_event_source_set_time_relative</function></funcdef>
+        <paramdef>sd_event_source *<parameter>source</parameter></paramdef>
+        <paramdef>uint64_t <parameter>usec</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_event_source_get_time_accuracy</function></funcdef>
+        <paramdef>sd_event_source *<parameter>source</parameter></paramdef>
+        <paramdef>uint64_t *<parameter>usec</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_event_source_set_time_accuracy</function></funcdef>
+        <paramdef>sd_event_source *<parameter>source</parameter></paramdef>
+        <paramdef>uint64_t <parameter>usec</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_event_source_get_time_clock</function></funcdef>
+        <paramdef>sd_event_source *<parameter>source</parameter></paramdef>
+        <paramdef>clockid_t *<parameter>clock</parameter></paramdef>
+      </funcprototype>
+
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_event_add_time()</function> adds a new timer event source to an event loop. The event loop
+    object is specified in the <parameter>event</parameter> parameter, the event source object is returned in the
+    <parameter>source</parameter> parameter. The <parameter>clock</parameter> parameter takes a clock identifier, one
+    of <constant>CLOCK_REALTIME</constant>, <constant>CLOCK_MONOTONIC</constant>, <constant>CLOCK_BOOTTIME</constant>,
+    <constant>CLOCK_REALTIME_ALARM</constant>, or <constant>CLOCK_BOOTTIME_ALARM</constant>. See
+    <citerefentry><refentrytitle>timerfd_create</refentrytitle><manvolnum>2</manvolnum></citerefentry> for details
+    regarding the various types of clocks. The <parameter>usec</parameter> parameter specifies the earliest time, in
+    microseconds (μs), relative to the clock's epoch, when the timer shall be triggered. If a time already in the past
+    is specified (including <constant>0</constant>), this timer source "fires" immediately and is ready to be
+    dispatched. If the parameter is specified as <constant>UINT64_MAX</constant> the timer event will never elapse,
+    which may be used as an alternative to explicitly disabling a timer event source with
+    <citerefentry><refentrytitle>sd_event_source_set_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry>. The
+    <parameter>accuracy</parameter> parameter specifies an additional accuracy value in μs specifying how much the
+    timer event may be delayed. Use <constant>0</constant> to select the default accuracy (250ms). Use 1μs for maximum
+    accuracy. Consider specifying 60000000μs (1min) or larger for long-running events that may be delayed
+    substantially. Picking higher accuracy values allows the system to coalesce timer events more aggressively,
+    improving power efficiency.</para>
+
+    <para>The <parameter>handler</parameter> is a function to call when the timer elapses or
+    <constant>NULL</constant>. The <parameter>userdata</parameter> pointer will be passed to the handler
+    function, and may be chosen freely by the caller. The configured trigger time is also passed to the
+    handler, even if the call actually happens slightly later, subject to the specified accuracy value, the
+    kernel timer slack (see
+    <citerefentry><refentrytitle>prctl</refentrytitle><manvolnum>2</manvolnum></citerefentry>), and
+    additional scheduling latencies. To query the actual time the handler was called use
+    <citerefentry><refentrytitle>sd_event_now</refentrytitle><manvolnum>3</manvolnum></citerefentry>. The
+    handler may return negative to signal an error (see below), other return values are ignored. If
+    <parameter>handler</parameter> is <constant>NULL</constant>, a default handler that calls
+    <citerefentry><refentrytitle>sd_event_exit</refentrytitle><manvolnum>3</manvolnum></citerefentry> will be
+    used.</para>
+
+    <para>By default, the timer will elapse once (<constant>SD_EVENT_ONESHOT</constant>), but this may be
+    changed with
+    <citerefentry><refentrytitle>sd_event_source_set_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+    If the handler function returns a negative error code, it will either be disabled after the invocation,
+    even if the <constant>SD_EVENT_ON</constant> mode was requested before, or it will cause the loop to
+    terminate, see
+    <citerefentry><refentrytitle>sd_event_source_set_exit_on_failure</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+    Note that a timer event set to <constant>SD_EVENT_ON</constant> will fire continuously unless its
+    configured time is updated using <function>sd_event_source_set_time()</function>.</para>
+
+    <para><function>sd_event_add_time_relative()</function> is like <function>sd_event_add_time()</function>,
+    but takes a relative time specification. It's relative to the current time of the event loop iteration,
+    as returned by
+    <citerefentry><refentrytitle>sd_event_now</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para>
+
+    <para>To destroy an event source object use
+    <citerefentry><refentrytitle>sd_event_source_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    but note that the event source is only removed from the event loop
+    when all references to the event source are dropped. To make sure
+    an event source does not fire anymore, even if it is still referenced,
+    disable the event source using
+    <citerefentry><refentrytitle>sd_event_source_set_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    with <constant>SD_EVENT_OFF</constant>.</para>
+
+    <para>If the second parameter of
+    <function>sd_event_add_time()</function> is
+    <constant>NULL</constant> no reference to the event source object
+    is returned. In this case the event source is considered
+    "floating", and will be destroyed implicitly when the event loop
+    itself is destroyed.</para>
+
+    <para>If the <parameter>handler</parameter> parameter to <function>sd_event_add_time()</function> is
+    <constant>NULL</constant>, and the event source fires, this will be considered a request to exit the
+    event loop. In this case, the <parameter>userdata</parameter> parameter, cast to an integer, is passed as
+    the exit code parameter to
+    <citerefentry><refentrytitle>sd_event_exit</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para>
+
+    <para>Use <constant>CLOCK_BOOTTIME_ALARM</constant> and
+    <constant>CLOCK_REALTIME_ALARM</constant> to define event sources
+    that may wake up the system from suspend.</para>
+
+    <para>In order to set up relative timers (that is, relative to the
+    current time), retrieve the current time via
+    <citerefentry><refentrytitle>sd_event_now</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    add the desired timespan to it, and use the result as
+    the <parameter>usec</parameter> parameter to
+    <function>sd_event_add_time()</function>.</para>
+
+    <para>In order to set up repetitive timers (that is, timers that
+    are triggered in regular intervals), set up the timer normally,
+    for the first invocation. Each time the event handler is invoked,
+    update the timer's trigger time with
+    <citerefentry><refentrytitle>sd_event_source_set_time</refentrytitle><manvolnum>3</manvolnum></citerefentry> for the next timer
+    iteration, and reenable the timer using
+    <function>sd_event_source_set_enabled()</function>. To calculate
+    the next point in time to pass to
+    <function>sd_event_source_set_time()</function>, either use as
+    base the <parameter>usec</parameter> parameter passed to the timer
+    callback, or the timestamp returned by
+    <function>sd_event_now()</function>. In the former case timer
+    events will be regular, while in the latter case the scheduling
+    latency will keep accumulating on the timer.</para>
+
+    <para><function>sd_event_source_get_time()</function> retrieves the configured time value of an event
+    source created previously with <function>sd_event_add_time()</function> or
+    <function>sd_event_add_time_relative()</function>. It takes the event source object and a pointer to a
+    variable to store the time in, relative to the selected clock's epoch, in μs. The returned value is
+    relative to the epoch, even if the event source was created with a relative time via
+    <function>sd_event_add_time_relative()</function>.</para>
+
+    <para><function>sd_event_source_set_time()</function> changes the time of an event source created
+    previously with <function>sd_event_add_time()</function> or
+    <function>sd_event_add_time_relative()</function>. It takes the event source object and a time relative
+    to the selected clock's epoch, in μs.</para>
+
+    <para><function>sd_event_source_set_time_relative()</function> is similar to
+    <function>sd_event_source_set_time()</function>, but takes a time relative to the current time of the
+    event loop iteration, as returned by <function>sd_event_now()</function>.</para>
+
+    <para><function>sd_event_source_get_time_accuracy()</function>
+    retrieves the configured accuracy value of an event source
+    created previously with <function>sd_event_add_time()</function>. It
+    takes the event source object and a pointer to a variable to store
+    the accuracy in. The accuracy is specified in μs.</para>
+
+    <para><function>sd_event_source_set_time_accuracy()</function>
+    changes the configured accuracy of a timer event source created
+    previously with <function>sd_event_add_time()</function>. It takes
+    the event source object and accuracy, in μs.</para>
+
+    <para><function>sd_event_source_get_time_clock()</function>
+    retrieves the configured clock of an event source created
+    previously with <function>sd_event_add_time()</function>. It takes
+    the event source object and a pointer to a variable to store the
+    clock identifier in.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, these functions return 0 or a positive
+    integer. On failure, they return a negative errno-style error
+    code. </para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned values may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-ENOMEM</constant></term>
+
+          <listitem><para>Not enough memory to allocate an object.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>An invalid argument has been passed.</para></listitem>
+
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ESTALE</constant></term>
+
+          <listitem><para>The event loop is already terminated.</para></listitem>
+
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ECHILD</constant></term>
+
+          <listitem><para>The event loop has been created in a different process, library or module instance.</para></listitem>
+
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EOPNOTSUPP</constant></term>
+
+          <listitem><para>The selected clock is not supported by the event loop implementation.</para></listitem>
+
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EDOM</constant></term>
+
+          <listitem><para>The passed event source is not a timer event source.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EOVERFLOW</constant></term>
+
+          <listitem><para>The passed relative time is outside of the allowed range for time values (i.e. the
+          specified value added to the current time is outside the 64 bit unsigned integer range).</para>
+
+          <xi:include href="version-info.xml" xpointer="v247"/></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_event_add_time()</function>,
+    <function>sd_event_source_get_time()</function>,
+    <function>sd_event_source_set_time()</function>,
+    <function>sd_event_source_get_time_accuracy()</function>,
+    <function>sd_event_source_set_time_accuracy()</function>, and
+    <function>sd_event_source_get_time_clock()</function> were added in version 213.</para>
+    <para><function>sd_event_time_handler_t()</function> was added in version 217.</para>
+    <para><function>sd_event_add_time_relative()</function> and
+    <function>sd_event_source_set_time_relative()</function> were added in version 247.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_now</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_io</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_child</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_inotify</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_defer</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_source_set_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_source_set_priority</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_source_set_userdata</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_source_set_description</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_source_set_floating</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>clock_gettime</refentrytitle><manvolnum>2</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>timerfd_create</refentrytitle><manvolnum>2</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>prctl</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_event_exit.xml b/man/sd_event_exit.xml
new file mode 100644
index 0000000..bea8acd
--- /dev/null
+++ b/man/sd_event_exit.xml
@@ -0,0 +1,156 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_event_exit" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_event_exit</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_event_exit</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_event_exit</refname>
+    <refname>sd_event_get_exit_code</refname>
+
+    <refpurpose>Ask the event loop to exit</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-event.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_event_exit</function></funcdef>
+        <paramdef>sd_event *<parameter>event</parameter></paramdef>
+        <paramdef>int <parameter>code</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_event_get_exit_code</function></funcdef>
+        <paramdef>sd_event *<parameter>event</parameter></paramdef>
+        <paramdef>int *<parameter>code</parameter></paramdef>
+      </funcprototype>
+
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_event_exit()</function> requests the event loop
+    specified in the <parameter>event</parameter> event loop object to
+    exit. The <parameter>code</parameter> parameter may be any integer
+    value and is returned as-is by
+    <citerefentry><refentrytitle>sd_event_loop</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    after the last event loop iteration. It may also be queried
+    using <function>sd_event_get_exit_code()</function>, see
+    below. </para>
+
+    <para>When exiting is requested the event loop will stop listening
+    for and dispatching regular event sources. Instead it will proceed
+    with executing only event sources registered with
+    <citerefentry><refentrytitle>sd_event_add_exit</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    in the order defined by their priority. After all exit event
+    sources have been dispatched the event loop is terminated.</para>
+
+    <para>If <function>sd_event_exit()</function> is invoked a second
+    time while the event loop is still processing exit event sources,
+    the exit code stored in the event loop object is updated, but
+    otherwise no further operation is executed.</para>
+
+    <para><function>sd_event_get_exit_code()</function> may be used to
+    query the exit code passed into
+    <function>sd_event_exit()</function> earlier.</para>
+
+    <para>While the full positive and negative integer ranges may be used
+    for the exit code, care should be taken not pick exit codes that
+    conflict with regular exit codes returned by
+    <function>sd_event_loop()</function>, if these exit codes shall be
+    distinguishable.</para>
+
+    <para>Note that for most event source types passing the callback pointer as <constant>NULL</constant> in
+    the respective constructor call (i.e. in
+    <citerefentry><refentrytitle>sd_event_add_time</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_event_add_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    …) has the effect of <function>sd_event_exit()</function> being invoked once the event source triggers,
+    with the specified userdata pointer cast to an integer as the exit code parameter. This is useful to
+    automatically terminate an event loop after some condition, such as a time-out or reception of
+    <constant>SIGTERM</constant> or similar. See the documentation for the respective constructor call for
+    details.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, <function>sd_event_exit()</function> and <function>sd_event_get_exit_code()</function>
+    return 0 or a positive integer. On failure, they return a negative errno-style error code.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>The event loop object or error code pointer are invalid.</para></listitem>
+
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ECHILD</constant></term>
+
+          <listitem><para>The event loop was created in a different process, library or module instance.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ESTALE</constant></term>
+
+          <listitem><para>The event loop has exited already and all exit handlers are already processed.
+          </para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENODATA</constant></term>
+
+          <listitem><para>The event loop has not been requested to exit yet.</para></listitem>
+        </varlistentry>
+
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_event_exit()</function> and
+    <function>sd_event_get_exit_code()</function> were added in version 229.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_exit</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_time</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_io</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_defer</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_inotify</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_event_get_fd.xml b/man/sd_event_get_fd.xml
new file mode 100644
index 0000000..e68b688
--- /dev/null
+++ b/man/sd_event_get_fd.xml
@@ -0,0 +1,116 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_event_get_fd" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_event_get_fd</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_event_get_fd</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_event_get_fd</refname>
+
+    <refpurpose>Obtain a file descriptor to poll for event loop events</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-event.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_event_get_fd</function></funcdef>
+        <paramdef>sd_event *<parameter>event</parameter></paramdef>
+      </funcprototype>
+
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_event_get_fd()</function> returns the file
+    descriptor that an event loop object returned by the
+    <citerefentry><refentrytitle>sd_event_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    function uses to wait for events. This file descriptor may itself
+    be polled for
+    <constant>POLLIN</constant>/<constant>EPOLLIN</constant>
+    events. This makes it possible to embed an
+    <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    event loop into another, possibly foreign, event loop.</para>
+
+    <para>The returned file descriptor refers to an <citerefentry
+    project='man-pages'><refentrytitle>epoll</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+    object. It is recommended not to alter it by invoking
+    <citerefentry
+    project='man-pages'><refentrytitle>epoll_ctl</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+    on it, in order to avoid interference with the event loop's inner
+    logic and assumptions.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, <function>sd_event_get_fd()</function> returns a non-negative file descriptor. On
+    failure, it returns a negative errno-style error code.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para><parameter>event</parameter> is not a valid pointer to an
+          <structname>sd_event</structname> structure.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ECHILD</constant></term>
+
+          <listitem><para>The event loop has been created in a different process, library or module instance.</para></listitem>
+
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <refsect1>
+    <title>Examples</title>
+
+    <example>
+      <title>Integration in the GLib event loop</title>
+
+      <programlisting><xi:include href="glib-event-glue.c" parse="text" /></programlisting>
+    </example>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_event_get_fd()</function> was added in version 217.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_wait</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>epoll_ctl</refentrytitle><manvolnum>2</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>epoll</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_event_new.xml b/man/sd_event_new.xml
new file mode 100644
index 0000000..a01cc78
--- /dev/null
+++ b/man/sd_event_new.xml
@@ -0,0 +1,228 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_event_new" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_event_new</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_event_new</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_event_new</refname>
+    <refname>sd_event_default</refname>
+    <refname>sd_event_ref</refname>
+    <refname>sd_event_unref</refname>
+    <refname>sd_event_unrefp</refname>
+    <refname>sd_event_get_tid</refname>
+    <refname>sd_event</refname>
+
+    <refpurpose>Acquire and release an event loop object</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-event.h&gt;</funcsynopsisinfo>
+
+      <funcsynopsisinfo><token>typedef</token> struct sd_event sd_event;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_event_new</function></funcdef>
+        <paramdef>sd_event **<parameter>event</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_event_default</function></funcdef>
+        <paramdef>sd_event **<parameter>event</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>sd_event *<function>sd_event_ref</function></funcdef>
+        <paramdef>sd_event *<parameter>event</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>sd_event *<function>sd_event_unref</function></funcdef>
+        <paramdef>sd_event *<parameter>event</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>void <function>sd_event_unrefp</function></funcdef>
+        <paramdef>sd_event **<parameter>event</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_event_get_tid</function></funcdef>
+        <paramdef>sd_event *<parameter>event</parameter></paramdef>
+        <paramdef>pid_t *<parameter>tid</parameter></paramdef>
+      </funcprototype>
+
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_event_new()</function> allocates a new event
+    loop object. The event loop object is returned in the
+    <parameter>event</parameter> parameter. After use, drop
+    the returned reference with
+    <function>sd_event_unref()</function>. When the last reference is
+    dropped, the object is freed.</para>
+
+    <para><function>sd_event_default()</function> acquires a reference
+    to the default event loop object of the calling thread, possibly
+    allocating a new object if no default event loop object has been
+    allocated yet for the thread. After use, drop the returned
+    reference with <function>sd_event_unref()</function>. When the
+    last reference is dropped, the event loop is freed. If this
+    function is called while the object returned from a previous call
+    from the same thread is still referenced, the same object is
+    returned again, but the reference is increased by one. It is
+    recommended to use this call instead of
+    <function>sd_event_new()</function> in order to share event loop
+    objects between various components that are dispatched in the same
+    thread. All threads have exactly either zero or one default event loop
+    objects associated, but never more.</para>
+
+    <para>After allocating an event loop object, add event sources to
+    it with
+    <citerefentry><refentrytitle>sd_event_add_io</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_event_add_time</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_event_add_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_event_add_child</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_event_add_inotify</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_event_add_defer</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_event_add_post</refentrytitle><manvolnum>3</manvolnum></citerefentry> or
+    <citerefentry><refentrytitle>sd_event_add_exit</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    and then execute the event loop using
+    <citerefentry><refentrytitle>sd_event_loop</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para>
+
+    <para><function>sd_event_ref()</function> increases the reference
+    count of the specified event loop object by one.</para>
+
+    <para><function>sd_event_unref()</function> decreases the
+    reference count of the specified event loop object by one. If
+    the count hits zero, the object is freed. Note that it
+    is freed regardless of whether it is the default event loop object for a
+    thread or not. This means that allocating an event loop with
+    <function>sd_event_default()</function>, then releasing it, and
+    then acquiring a new one with
+    <function>sd_event_default()</function> will result in two
+    distinct objects. Note that, in order to free an event loop object,
+    all remaining event sources of the event loop also need to be
+    freed as each keeps a reference to it.</para>
+
+    <para><function>sd_event_unrefp()</function> is similar to
+    <function>sd_event_unref()</function> but takes a pointer to a
+    pointer to an <type>sd_event</type> object. This call is useful in
+    conjunction with GCC's and LLVM's <ulink
+    url="https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html">Clean-up
+    Variable Attribute</ulink>. Note that this function is defined as
+    inline function. Use a declaration like the following,
+    in order to allocate an event loop object that is freed
+    automatically as the code block is left:</para>
+
+    <programlisting>{
+        __attribute__((cleanup(sd_event_unrefp))) sd_event *event = NULL;
+        int r;
+        …
+        r = sd_event_default(&amp;event);
+        if (r &lt; 0) {
+          errno = -r;
+          fprintf(stderr, "Failed to allocate event loop: %m\n");
+        }
+        …
+}</programlisting>
+
+    <para><function>sd_event_ref()</function>,
+    <function>sd_event_unref()</function> and
+    <function>sd_event_unrefp()</function> execute no operation if the
+    passed in event loop object is <constant>NULL</constant>.</para>
+
+    <para><function>sd_event_get_tid()</function> retrieves the thread
+    identifier ("TID") of the thread the specified event loop object
+    is associated with. This call is only supported for event loops
+    allocated with <function>sd_event_default()</function>, and
+    returns the identifier for the thread the event loop is the
+    default event loop of. See <citerefentry
+    project='man-pages'><refentrytitle>gettid</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+    for more information on thread identifiers.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, <function>sd_event_new()</function>, <function>sd_event_default()</function> and
+    <function>sd_event_get_tid()</function> return 0 or a positive integer. On failure, they return a
+    negative errno-style error code. <function>sd_event_ref()</function> always returns a pointer to the
+    event loop object passed in. <function>sd_event_unref()</function> always returns
+    <constant>NULL</constant>.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-ENOMEM</constant></term>
+
+          <listitem><para>Not enough memory to allocate the object.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EMFILE</constant></term>
+
+          <listitem><para>The maximum number of event loops has been allocated.</para></listitem>
+
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENXIO</constant></term>
+
+          <listitem><para><function>sd_event_get_tid()</function> was invoked on an event loop object that
+          was not allocated with <function>sd_event_default()</function>.</para></listitem>
+        </varlistentry>
+
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_event_new()</function>,
+    <function>sd_event_default()</function>,
+    <function>sd_event_ref()</function>, and
+    <function>sd_event_unref()</function> were added in version 213.</para>
+    <para><function>sd_event_unrefp()</function> and
+    <function>sd_event_get_tid()</function> were added in version 229.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_io</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_time</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_child</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_inotify</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_defer</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_run</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>gettid</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_event_now.xml b/man/sd_event_now.xml
new file mode 100644
index 0000000..100d39a
--- /dev/null
+++ b/man/sd_event_now.xml
@@ -0,0 +1,119 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_event_now" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_event_now</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_event_now</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_event_now</refname>
+
+    <refpurpose>Retrieve current event loop iteration timestamp</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-event.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_event_now</function></funcdef>
+        <paramdef>sd_event *<parameter>event</parameter></paramdef>
+        <paramdef>clockid_t <parameter>clock</parameter></paramdef>
+        <paramdef>uint64_t *<parameter>usec</parameter></paramdef>
+      </funcprototype>
+
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_event_now()</function> returns the time when
+    the most recent event loop iteration began. A timestamp
+    is taken right after returning from the event sleep, and before
+    dispatching any event sources. The <parameter>event</parameter>
+    parameter specifies the event loop object to retrieve the timestamp
+    from. The <parameter>clock</parameter> parameter specifies the clock to
+    retrieve the timestamp for, and is one of
+    <constant>CLOCK_REALTIME</constant> (or equivalently
+    <constant>CLOCK_REALTIME_ALARM</constant>),
+    <constant>CLOCK_MONOTONIC</constant>, or
+    <constant>CLOCK_BOOTTIME</constant> (or equivalently
+    <constant>CLOCK_BOOTTIME_ALARM</constant>), see
+    <citerefentry project='man-pages'><refentrytitle>clock_gettime</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+    for more information on the various clocks. The retrieved
+    timestamp is stored in the <parameter>usec</parameter> parameter,
+    in μs since the clock's epoch. If this function is invoked before
+    the first event loop iteration, the current time is returned, as
+    reported by <function>clock_gettime()</function>. To distinguish
+    this case from a regular invocation the return value will be
+    positive, and zero when the returned timestamp refers to an actual
+    event loop iteration.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>If the first event loop iteration has not run yet <function>sd_event_now()</function> writes
+    current time to <parameter>usec</parameter> and returns a positive return value.  Otherwise, it will
+    write the requested timestamp to <parameter>usec</parameter> and return 0. On failure, the call returns a
+    negative errno-style error code.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned values may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>An invalid parameter was passed.</para></listitem>
+
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EOPNOTSUPP</constant></term>
+
+          <listitem><para>Unsupported clock type.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ECHILD</constant></term>
+
+          <listitem><para>The event loop object was created in a different process, library or module instance.</para></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_event_now()</function> was added in version 229.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_time</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>clock_gettime</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_event_run.xml b/man/sd_event_run.xml
new file mode 100644
index 0000000..7df74ab
--- /dev/null
+++ b/man/sd_event_run.xml
@@ -0,0 +1,170 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_event_run" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_event_run</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_event_run</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_event_run</refname>
+    <refname>sd_event_loop</refname>
+
+    <refpurpose>Run an event loop</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-event.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_event_run</function></funcdef>
+        <paramdef>sd_event *<parameter>event</parameter></paramdef>
+        <paramdef>uint64_t <parameter>usec</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_event_loop</function></funcdef>
+        <paramdef>sd_event *<parameter>event</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_event_run()</function> may be used to run a single
+    iteration of the event loop specified in the
+    <parameter>event</parameter> parameter. The function waits until an event to
+    process is available, and dispatches the registered handler for
+    it. The <parameter>usec</parameter> parameter specifies the
+    maximum time (in microseconds) to wait for an event. Use
+    <constant>(uint64_t) -1</constant> to specify an infinite
+    timeout.</para>
+
+    <para><function>sd_event_loop()</function> invokes
+    <function>sd_event_run()</function> in a loop, thus implementing
+    the actual event loop. The call returns as soon as exiting was
+    requested using
+    <citerefentry><refentrytitle>sd_event_exit</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para>
+
+    <para>The event loop object <parameter>event</parameter> is
+    created with
+    <citerefentry><refentrytitle>sd_event_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+    Events sources to wait for and their handlers may be registered
+    with
+    <citerefentry><refentrytitle>sd_event_add_io</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_event_add_time</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_event_add_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_event_add_child</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_event_add_defer</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_event_add_post</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    and
+    <citerefentry><refentrytitle>sd_event_add_exit</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+    </para>
+
+    <para>For low-level control of event loop execution, use
+    <citerefentry><refentrytitle>sd_event_prepare</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_event_wait</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    and
+    <citerefentry><refentrytitle>sd_event_dispatch</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    which are wrapped by <function>sd_event_run()</function>. Along
+    with
+    <citerefentry><refentrytitle>sd_event_get_fd</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    these functions allow integration of an
+    <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    event loop into foreign event loop implementations.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On failure, these functions return a negative errno-style
+    error code. <function>sd_event_run()</function> returns a
+    positive, non-zero integer if an event source was dispatched, and
+    zero when the specified timeout hit before an event source has
+    seen any event, and hence no event source was
+    dispatched. <function>sd_event_loop()</function> returns the exit
+    code specified when invoking
+    <function>sd_event_exit()</function>.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>The <parameter>event</parameter> parameter is invalid or
+          <constant>NULL</constant>.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EBUSY</constant></term>
+
+          <listitem><para>The event loop object is not in the right
+          state (see
+          <citerefentry><refentrytitle>sd_event_prepare</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+          for an explanation of possible states).</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ESTALE</constant></term>
+
+          <listitem><para>The event loop is already terminated.</para></listitem>
+
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ECHILD</constant></term>
+
+          <listitem><para>The event loop has been created in a different process, library or module instance.</para></listitem>
+
+        </varlistentry>
+
+      </variablelist>
+
+      <para>Other errors are possible, too.</para>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_event_run()</function> and
+    <function>sd_event_loop()</function> were added in version 220.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_io</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_time</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_child</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_inotify</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_defer</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_exit</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_get_fd</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_wait</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <ulink url="https://developer.gnome.org/glib/unstable/glib-The-Main-Event-Loop.html">GLib Main Event Loop</ulink>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_event_set_signal_exit.xml b/man/sd_event_set_signal_exit.xml
new file mode 100644
index 0000000..1ac208e
--- /dev/null
+++ b/man/sd_event_set_signal_exit.xml
@@ -0,0 +1,110 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_event_set_signal_exit" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_event_set_signal_exit</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_event_set_signal_exit</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_event_set_signal_exit</refname>
+
+    <refpurpose>Automatically leave event loop on <constant>SIGINT</constant> and <constant>SIGTERM</constant></refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-event.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_event_set_signal_exit</function></funcdef>
+        <paramdef>sd_event *<parameter>event</parameter></paramdef>
+        <paramdef>int b</paramdef>
+      </funcprototype>
+
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_event_set_signal_exit()</function> may be used to ensure the event loop terminates
+    once a <constant>SIGINT</constant> or <constant>SIGTERM</constant> signal is received. It is a
+    convenience wrapper around invocations of
+    <citerefentry><refentrytitle>sd_event_add_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    for both signals. The two signals are automatically added to the calling thread's signal mask (if a
+    program is multi-threaded care should be taken to either invoke this function before the first thread is
+    started or to manually block the two signals process-wide first).</para>
+
+    <para>If the parameter <parameter>b</parameter> is specified as true, the event loop will terminate on
+    <constant>SIGINT</constant> and <constant>SIGTERM</constant>. If specified as false, it will no
+    longer. When this functionality is turned off the calling thread's signal mask is restored to match the
+    state before it was turned on, for the two signals. By default the two signals are not handled by the
+    event loop, and Linux' default signal handling for them is in effect.</para>
+
+    <para>It's customary for UNIX programs to exit on either of these two signals, hence it's typically a
+    good idea to enable this functionality for the main event loop of a program.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para><function>sd_event_set_signal_exit()</function> returns a positive non-zero value when the setting
+    was successfully changed. It returns a zero when the specified setting was already in effect. On failure,
+    it returns a negative errno-style error code.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+
+        <varlistentry>
+          <term><constant>-ECHILD</constant></term>
+
+          <listitem><para>The event loop has been created in a different process, library or module instance.</para>
+
+          <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>The passed event loop object was invalid.</para>
+
+          <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+        </varlistentry>
+
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_event_set_signal_exit()</function> was added in version 252.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_event_set_watchdog.xml b/man/sd_event_set_watchdog.xml
new file mode 100644
index 0000000..a91ca64
--- /dev/null
+++ b/man/sd_event_set_watchdog.xml
@@ -0,0 +1,151 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_event_set_watchdog" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_event_set_watchdog</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_event_set_watchdog</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_event_set_watchdog</refname>
+    <refname>sd_event_get_watchdog</refname>
+
+    <refpurpose>Enable event loop watchdog support</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-event.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_event_set_watchdog</function></funcdef>
+        <paramdef>sd_event *<parameter>event</parameter></paramdef>
+        <paramdef>int b</paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_event_get_watchdog</function></funcdef>
+        <paramdef>sd_event *<parameter>event</parameter></paramdef>
+      </funcprototype>
+
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_event_set_watchdog()</function> may be used to
+    enable or disable automatic watchdog notification support in the
+    event loop object specified in the <parameter>event</parameter>
+    parameter. Specifically, depending on the <parameter>b</parameter>
+    boolean argument this will make sure the event loop wakes up in
+    regular intervals and sends watchdog notification messages to the
+    service manager, if this was requested by the service
+    manager. Watchdog support is determined with
+    <citerefentry><refentrytitle>sd_watchdog_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    and watchdog messages are sent with
+    <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>. See
+    the <varname>WatchdogSec=</varname> setting in
+    <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for details on how to enable watchdog support for a service and
+    the protocol used. The wake-up interval is chosen as half the
+    watchdog timeout declared by the service manager via the
+    <varname>$WATCHDOG_USEC</varname> environment variable. If the
+    service manager did not request watchdog notifications, or if the
+    process was not invoked by the service manager this call with a
+    true <parameter>b</parameter> parameter executes no
+    operation. Passing a false <parameter>b</parameter> parameter will
+    disable the automatic sending of watchdog notification messages if
+    it was enabled before. Newly allocated event loop objects have
+    this feature disabled.</para>
+
+    <para>The first watchdog notification message is sent immediately
+    when <function>sd_event_set_watchdog()</function> is invoked with
+    a true <parameter>b</parameter> parameter.</para>
+
+    <para>The watchdog logic is designed to allow the service manager
+    to automatically detect services that ceased processing of
+    incoming events, and thus appear "hung". Watchdog notifications
+    are sent out only at the beginning of each event loop
+    iteration. If an event source dispatch function blocks for an
+    excessively long time and does not return execution to the event
+    loop quickly, this might hence cause the notification message to
+    be delayed, and possibly result in abnormal program termination,
+    as configured in the service unit file.</para>
+
+    <para><function>sd_event_get_watchdog()</function> may be used to
+    determine whether watchdog support was previously requested by a
+    call to <function>sd_event_set_watchdog()</function> with a true
+    <parameter>b</parameter> parameter and successfully
+    enabled.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, <function>sd_event_set_watchdog()</function> and
+    <function>sd_event_get_watchdog()</function> return a non-zero positive integer if the service manager
+    requested watchdog support and watchdog support was successfully enabled. They return zero if the service
+    manager did not request watchdog support, or if watchdog support was explicitly disabled with a false
+    <parameter>b</parameter> parameter. On failure, they return a negative errno-style error code.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+
+        <varlistentry>
+          <term><constant>-ECHILD</constant></term>
+
+          <listitem><para>The event loop has been created in a different process, library or module instance.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>The passed event loop object was invalid.</para></listitem>
+        </varlistentry>
+
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_event_set_watchdog()</function> and
+    <function>sd_event_get_watchdog()</function> were added in version 229.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_io</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_time</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_child</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_inotify</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_defer</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_watchdog_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_event_source_get_event.xml b/man/sd_event_source_get_event.xml
new file mode 100644
index 0000000..50d3a9b
--- /dev/null
+++ b/man/sd_event_source_get_event.xml
@@ -0,0 +1,79 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_event_source_get_event" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_event_source_get_event</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_event_source_get_event</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_event_source_get_event</refname>
+
+    <refpurpose>Retrieve the event loop of an event source</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-event.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>sd_event* <function>sd_event_source_get_event</function></funcdef>
+        <paramdef>sd_event_source *<parameter>source</parameter></paramdef>
+      </funcprototype>
+
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_event_source_get_event()</function> may be used
+    to retrieve the event loop object the event source object specified
+    as <parameter>source</parameter> is associated with. The event
+    loop object is specified when creating an event source object with
+    calls such as
+    <citerefentry><refentrytitle>sd_event_add_io</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    or
+    <citerefentry><refentrytitle>sd_event_add_time</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, <function>sd_event_source_get_event()</function>
+    returns the associated event loop object. On failure, it returns
+    <constant>NULL</constant>.</para>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_event_source_get_event()</function> was added in version 229.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_io</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_time</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_child</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_inotify</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_defer</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_source_set_userdata</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_event_source_get_pending.xml b/man/sd_event_source_get_pending.xml
new file mode 100644
index 0000000..62b718b
--- /dev/null
+++ b/man/sd_event_source_get_pending.xml
@@ -0,0 +1,142 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_event_source_get_pending" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_event_source_get_pending</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_event_source_get_pending</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_event_source_get_pending</refname>
+
+    <refpurpose>Determine pending state of event sources</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-event.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_event_source_get_pending</function></funcdef>
+        <paramdef>sd_event_source *<parameter>source</parameter></paramdef>
+      </funcprototype>
+
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_event_source_get_pending()</function> may be
+    used to determine whether the event source object specified as
+    <parameter>source</parameter> has seen events but has not been
+    dispatched yet (and thus is marked "pending").</para>
+
+    <para>Event source objects initially are not marked pending, when
+    they are created with calls such as
+    <citerefentry><refentrytitle>sd_event_add_io</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_event_add_time</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    with the exception of those created with
+    <citerefentry><refentrytitle>sd_event_add_defer</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    which are immediately marked pending, and
+    <citerefentry><refentrytitle>sd_event_add_exit</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    for which the "pending" concept is not defined. For details see
+    the respective manual pages.</para>
+
+    <para>In each event loop iteration one event source of those
+    marked pending is dispatched, in the order defined by the event
+    source priority, as set with
+    <citerefentry><refentrytitle>sd_event_source_set_priority</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para>
+
+    <para>For I/O event sources, as created with
+    <citerefentry><refentrytitle>sd_event_add_io</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    the call
+    <citerefentry><refentrytitle>sd_event_source_get_io_revents</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    may be used to query the type of event pending in more
+    detail.</para>
+
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, <function>sd_event_source_get_pending()</function> returns an integer greater than zero
+    when the event source is marked pending, and zero when the event source is not marked pending. On
+    failure, it returns a negative errno-style error code.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para><parameter>source</parameter> is not a valid pointer to an
+          <structname>sd_event_source</structname> object.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EDOM</constant></term>
+
+          <listitem><para><parameter>source</parameter> refers to an event source object created with
+          <citerefentry><refentrytitle>sd_event_add_exit</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOMEM</constant></term>
+
+          <listitem><para>Not enough memory.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ESTALE</constant></term>
+
+          <listitem><para>The event loop is already terminated.</para></listitem>
+
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ECHILD</constant></term>
+
+          <listitem><para>The event loop has been created in a different process, library or module instance.</para></listitem>
+
+        </varlistentry>
+
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_event_source_get_pending()</function> was added in version 229.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_io</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_time</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_child</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_inotify</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_defer</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_source_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_event_source_set_description.xml b/man/sd_event_source_set_description.xml
new file mode 100644
index 0000000..e4cd775
--- /dev/null
+++ b/man/sd_event_source_set_description.xml
@@ -0,0 +1,146 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_event_source_set_description" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_event_source_set_description</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_event_source_set_description</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_event_source_set_description</refname>
+    <refname>sd_event_source_get_description</refname>
+
+    <refpurpose>Set or retrieve descriptive names of event sources</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-event.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_event_source_set_description</function></funcdef>
+        <paramdef>sd_event_source *<parameter>source</parameter></paramdef>
+        <paramdef>const char *<parameter>description</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_event_source_get_description</function></funcdef>
+        <paramdef>sd_event_source *<parameter>source</parameter></paramdef>
+        <paramdef>const char **<parameter>description</parameter></paramdef>
+      </funcprototype>
+
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_event_source_set_description()</function> may
+    be used to set an arbitrary descriptive name for the event source
+    object specified as <parameter>source</parameter>. This name will
+    be used in debugging messages generated by
+    <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    for this event source, and may be queried using
+    <function>sd_event_source_get_description()</function> for
+    debugging purposes. The <parameter>description</parameter> parameter shall
+    point to a <constant>NUL</constant>-terminated string or be
+    <constant>NULL</constant>. In the latter case, the descriptive
+    name will be unset. The string is copied internally, hence the
+    <parameter>description</parameter> argument is not referenced
+    after the function returns.</para>
+
+    <para><function>sd_event_source_get_description()</function> may
+    be used to query the current descriptive name assigned to the
+    event source object <parameter>source</parameter>. It returns a
+    pointer to the current name in <parameter>description</parameter>,
+    stored in memory internal to the event source. The memory is
+    invalidated when the event source is destroyed or the descriptive
+    name is changed.</para>
+
+    <para>Event source objects generally have no description set when
+    they are created, except for UNIX signal event sources created
+    with
+    <citerefentry><refentrytitle>sd_event_add_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    whose descriptive name is initialized to the signal's C constant
+    name (e.g. <literal>SIGINT</literal> or
+    <literal>SIGTERM</literal>).</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, <function>sd_event_source_set_description()</function> and
+    <function>sd_event_source_get_description()</function> return a non-negative integer. On failure, they
+    return a negative errno-style error code.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para><parameter>source</parameter> is not a valid pointer to an
+          <structname>sd_event_source</structname> object or the <parameter>description</parameter> argument
+          for <function>sd_event_source_get_description()</function> is <constant>NULL</constant>.
+          </para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOMEM</constant></term>
+
+          <listitem><para>Not enough memory to copy the name.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ECHILD</constant></term>
+
+          <listitem><para>The event loop has been created in a different process, library or module instance.</para></listitem>
+
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENXIO</constant></term>
+
+          <listitem><para>No name was set for the event source.</para></listitem>
+        </varlistentry>
+
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_event_source_set_description()</function> and
+    <function>sd_event_source_get_description()</function> were added in version 229.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_io</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_time</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_child</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_inotify</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_defer</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_source_set_userdata</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_event_source_set_destroy_callback.xml b/man/sd_event_source_set_destroy_callback.xml
new file mode 100644
index 0000000..d276385
--- /dev/null
+++ b/man/sd_event_source_set_destroy_callback.xml
@@ -0,0 +1,119 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_event_source_set_destroy_callback"
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_event_source_set_destroy_callback</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_event_source_set_destroy_callback</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_event_source_set_destroy_callback</refname>
+    <refname>sd_event_source_get_destroy_callback</refname>
+    <refname>sd_event_destroy_t</refname>
+
+    <refpurpose>Define the callback function for resource cleanup</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-event.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>typedef int (*<function>sd_event_destroy_t</function>)</funcdef>
+        <paramdef>void *<parameter>userdata</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_event_source_set_destroy_callback</function></funcdef>
+        <paramdef>sd_event_source *<parameter>source</parameter></paramdef>
+        <paramdef>sd_event_destroy_t <parameter>callback</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_event_source_get_destroy_callback</function></funcdef>
+        <paramdef>sd_event_source *<parameter>source</parameter></paramdef>
+        <paramdef>sd_event_destroy_t *<parameter>callback</parameter></paramdef>
+      </funcprototype>
+
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_event_source_set_destroy_callback()</function> sets <parameter>callback</parameter> as the
+    callback function to be called right before the event source object <parameter>source</parameter> is
+    deallocated. The <parameter>userdata</parameter> pointer from the event source object will be passed as the
+    <parameter>userdata</parameter> parameter. This pointer can be set by an argument to the constructor functions, see
+    <citerefentry><refentrytitle>sd_event_add_io</refentrytitle><manvolnum>3</manvolnum></citerefentry>, or directly,
+    see
+    <citerefentry><refentrytitle>sd_event_source_set_userdata</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+    This callback function is called even if <parameter>userdata</parameter> is <constant>NULL</constant>. Note that
+    this callback is invoked at a time where the event source object itself is already invalidated, and executing
+    operations or taking new references to the event source object is not permissible.</para>
+
+    <para><function>sd_event_source_get_destroy_callback()</function> returns the current callback
+    for <parameter>source</parameter> in the <parameter>callback</parameter> parameter.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, <function>sd_event_source_set_destroy_callback()</function> returns 0 or a positive
+    integer. On failure, it returns a negative errno-style error code.</para>
+
+    <para><function>sd_event_source_get_destroy_callback()</function> returns positive if the destroy
+    callback function is set, 0 if not. On failure, returns a negative errno-style error code.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>The <parameter>source</parameter> parameter is <constant>NULL</constant>.
+          </para></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_event_destroy_t()</function>,
+    <function>sd_event_source_set_destroy_callback()</function>, and
+    <function>sd_event_source_get_destroy_callback()</function> were added in version 239.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_io</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_time</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_child</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_inotify</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_defer</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_source_set_userdata</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_event_source_set_enabled.xml b/man/sd_event_source_set_enabled.xml
new file mode 100644
index 0000000..07c5322
--- /dev/null
+++ b/man/sd_event_source_set_enabled.xml
@@ -0,0 +1,162 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_event_source_set_enabled" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_event_source_set_enabled</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_event_source_set_enabled</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_event_source_set_enabled</refname>
+    <refname>sd_event_source_get_enabled</refname>
+    <refname>SD_EVENT_ON</refname>
+    <refname>SD_EVENT_OFF</refname>
+    <refname>SD_EVENT_ONESHOT</refname>
+
+    <refpurpose>Enable or disable event sources</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-event.h&gt;</funcsynopsisinfo>
+
+      <funcsynopsisinfo><token>enum</token> {
+        <constant>SD_EVENT_OFF</constant> = 0,
+        <constant>SD_EVENT_ON</constant> = 1,
+        <constant>SD_EVENT_ONESHOT</constant> = -1,
+};</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_event_source_set_enabled</function></funcdef>
+        <paramdef>sd_event_source *<parameter>source</parameter></paramdef>
+        <paramdef>int <parameter>enabled</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_event_source_get_enabled</function></funcdef>
+        <paramdef>sd_event_source *<parameter>source</parameter></paramdef>
+        <paramdef>int *<parameter>enabled</parameter></paramdef>
+      </funcprototype>
+
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_event_source_set_enabled()</function> may be used to enable or disable the event
+    source object specified as <parameter>source</parameter>. The <parameter>enabled</parameter> parameter
+    takes one of <constant>SD_EVENT_ON</constant> (to enable), <constant>SD_EVENT_OFF</constant> (to disable)
+    or <constant>SD_EVENT_ONESHOT</constant>. If invoked with <constant>SD_EVENT_ONESHOT</constant> the event
+    source will be enabled but automatically reset to <constant>SD_EVENT_OFF</constant> after one dispatch.
+    For <constant>SD_EVENT_OFF</constant>, the event source <parameter>source</parameter> may be
+    <constant>NULL</constant>, in which case the function does nothing. Otherwise,
+    <parameter>source</parameter> must be a valid pointer to an <structname>sd_event_source</structname>
+    object.</para>
+
+    <para>Event sources that are disabled will not result in event
+    loop wakeups and will not be dispatched, until they are enabled
+    again.</para>
+
+    <para><function>sd_event_source_get_enabled()</function> may be used to query whether the event source
+    object <parameter>source</parameter> is currently enabled or not. If both the
+    <parameter>source</parameter> and the output parameter <parameter>enabled</parameter> are
+    <constant>NULL</constant>, this function returns false. Otherwise, <parameter>source</parameter> must be
+    a valid pointer to an <structname>sd_event_source</structname> object. If the output parameter
+    <parameter>enabled</parameter> is not <constant>NULL</constant>, it is set to the enablement state (one
+    of <constant>SD_EVENT_ON</constant>, <constant>SD_EVENT_OFF</constant>,
+    <constant>SD_EVENT_ONESHOT</constant>). The function also returns true if the event source is not
+    disabled.</para>
+
+    <para>Event source objects are enabled when they are first created
+    with calls such as
+    <citerefentry><refentrytitle>sd_event_add_io</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_event_add_time</refentrytitle><manvolnum>3</manvolnum></citerefentry>. However,
+    depending on the event source type they are enabled continuously
+    (<constant>SD_EVENT_ON</constant>) or only for a single invocation
+    of the event source handler
+    (<constant>SD_EVENT_ONESHOT</constant>). For details see the
+    respective manual pages.</para>
+
+    <para>As event source objects stay active and may be dispatched as
+    long as there is at least one reference to them, in many cases it
+    is a good idea to combine a call to
+    <citerefentry><refentrytitle>sd_event_source_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    with a prior call to
+    <function>sd_event_source_set_enabled()</function> with
+    <constant>SD_EVENT_OFF</constant>, to ensure the event source is
+    not dispatched again until all other remaining references are dropped.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, <function>sd_event_source_set_enabled()</function> returns a non-negative
+    integer. <function>sd_event_source_get_enabled()</function> returns zero if the source is disabled
+    (<constant>SD_EVENT_OFF</constant>) and a positive integer otherwise. On failure, they return a negative
+    errno-style error code.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para><parameter>source</parameter> is not a valid pointer to an
+          <structname>sd_event_source</structname> object.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOMEM</constant></term>
+
+          <listitem><para>Not enough memory.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ECHILD</constant></term>
+
+          <listitem><para>The event loop has been created in a different process, library or module instance.</para></listitem>
+
+        </varlistentry>
+
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_event_source_set_enabled()</function> and
+    <function>sd_event_source_get_enabled()</function> were added in version 229.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_io</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_time</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_child</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_inotify</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_defer</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_source_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_source_set_ratelimit</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_event_source_set_exit_on_failure.xml b/man/sd_event_source_set_exit_on_failure.xml
new file mode 100644
index 0000000..fd7f21f
--- /dev/null
+++ b/man/sd_event_source_set_exit_on_failure.xml
@@ -0,0 +1,118 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_event_source_set_exit_on_failure" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_event_source_set_exit_on_failure</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_event_source_set_exit_on_failure</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_event_source_set_exit_on_failure</refname>
+    <refname>sd_event_source_get_exit_on_failure</refname>
+
+    <refpurpose>Set or retrieve the exit-on-failure feature of event sources</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-event.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_event_source_set_exit_on_failure</function></funcdef>
+        <paramdef>sd_event_source *<parameter>source</parameter></paramdef>
+        <paramdef>int <parameter>b</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_event_source_get_exit_on_failure</function></funcdef>
+        <paramdef>sd_event_source *<parameter>source</parameter></paramdef>
+      </funcprototype>
+
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_event_source_set_exit_on_failure()</function> may be used to set/unset the
+    exit-on-failure flag of the event source object specified as <parameter>source</parameter>. The flag
+    defaults to off. If on and the callback function set for the event source returns a failure code (i.e. a
+    negative value) the event loop is exited too, using the callback return code as the exit code for
+    <citerefentry><refentrytitle>sd_event_exit</refentrytitle><manvolnum>3</manvolnum></citerefentry>. If
+    off, the event source is disabled but the event loop continues to run. Setting this flag is useful for
+    "dominant" event sources that define the purpose and reason for the event loop, and whose failure hence
+    should propagate to the event loop itself — as opposed to "auxiliary" event sources whose failures should
+    remain local and affect the event source, but not propagate further.</para>
+
+    <para><function>sd_event_source_get_exit_on_failure()</function> may be used to query the flag currently
+    set for the event source object <parameter>source</parameter>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, <function>sd_event_source_set_exit_on_failure()</function> returns a non-negative
+    integer.  <function>sd_event_source_get_exit_on_failure()</function> returns 0 if the flag is off, &gt; 0
+    if the flag is on. On failure, both return a negative errno-style error code.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para><parameter>source</parameter> is not a valid pointer to an
+          <structname>sd_event_source</structname> object.</para>
+
+          <xi:include href="version-info.xml" xpointer="v247"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EDOM</constant></term>
+
+          <listitem><para>The event source refers to an exit event source (as created with
+          <citerefentry><refentrytitle>sd_event_add_exit</refentrytitle><manvolnum>3</manvolnum></citerefentry>),
+          for which this functionality is not supported.</para>
+
+          <xi:include href="version-info.xml" xpointer="v247"/></listitem>
+        </varlistentry>
+
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_event_source_set_exit_on_failure()</function> and
+    <function>sd_event_source_get_exit_on_failure()</function> were added in version 247.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_io</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_time</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_child</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_inotify</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_defer</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_event_source_set_floating.xml b/man/sd_event_source_set_floating.xml
new file mode 100644
index 0000000..e2cc5d5
--- /dev/null
+++ b/man/sd_event_source_set_floating.xml
@@ -0,0 +1,128 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_event_source_set_floating" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_event_source_set_floating</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_event_source_set_floating</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_event_source_set_floating</refname>
+    <refname>sd_event_source_get_floating</refname>
+
+    <refpurpose>Set or retrieve 'floating' state of event sources</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-event.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_event_source_set_floating</function></funcdef>
+        <paramdef>sd_event_source *<parameter>source</parameter></paramdef>
+        <paramdef>int <parameter>floating</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_event_source_get_floating</function></funcdef>
+        <paramdef>sd_event_source *<parameter>source</parameter></paramdef>
+      </funcprototype>
+
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_event_source_set_floating()</function> takes a boolean and sets the 'floating' state
+    of the specified event source object. This is used to change the direction of reference counts for the
+    object and the event loop it is associated with. In non-floating mode, the event source object holds a
+    reference to the event loop object, but not vice versa. The creator of the event source object must hold
+    a reference to it as long as the source should exist. In floating mode, the event loop holds a reference
+    to the source object, and will decrease the reference count when being freed. This means that a reference
+    to the event loop should be held to prevent both from being destroyed.</para>
+
+    <para>Various calls that allocate event source objects (i.e.
+    <citerefentry><refentrytitle>sd_event_add_io</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_event_add_time</refentrytitle><manvolnum>3</manvolnum></citerefentry> and
+    similar) will automatically set an event source object to 'floating' mode if the caller passed
+    <constant>NULL</constant> in the parameter used to return a reference to the event source object.
+    Nevertheless, it may be necessary to gain temporary access to the source object, for example to adjust
+    event source properties after allocation (e.g. its priority or description string). In those cases the
+    object may be created in non-floating mode, and the returned reference used to adjust the properties, and
+    the object marked as floating afterwards, and the reference in the caller dropped.</para>
+
+    <para><function>sd_event_source_get_floating()</function> may be used to query the current 'floating'
+    state of the event source object <parameter>source</parameter>. It returns zero if 'floating' mode is
+    off, positive if it is on.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, <function>sd_event_source_set_floating()</function> and
+    <function>sd_event_source_get_floating()</function> return a non-negative integer. On failure, they
+    return a negative errno-style error code.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para><parameter>source</parameter> is not a valid pointer to an
+          <structname>sd_event_source</structname> object.</para>
+
+          <xi:include href="version-info.xml" xpointer="v244"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ECHILD</constant></term>
+
+          <listitem><para>The event loop has been created in a different process, library or module instance.</para>
+
+          <xi:include href="version-info.xml" xpointer="v244"/></listitem>
+
+        </varlistentry>
+
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_event_source_set_floating()</function> and
+    <function>sd_event_source_get_floating()</function> were added in version 244.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_io</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_time</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_child</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_inotify</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_defer</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_source_set_description</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_source_set_priority</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_event_source_set_prepare.xml b/man/sd_event_source_set_prepare.xml
new file mode 100644
index 0000000..8d78873
--- /dev/null
+++ b/man/sd_event_source_set_prepare.xml
@@ -0,0 +1,148 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_event_source_set_prepare" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_event_source_set_prepare</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_event_source_set_prepare</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_event_source_set_prepare</refname>
+
+    <refpurpose>Set a preparation callback for event sources</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-event.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_event_source_set_prepare</function></funcdef>
+        <paramdef>sd_event_source *<parameter>source</parameter></paramdef>
+        <paramdef>sd_event_handler_t <parameter>callback</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>typedef int (*<function>sd_event_handler_t</function>)</funcdef>
+        <paramdef>sd_event_source *<parameter>s</parameter></paramdef>
+        <paramdef>void *<parameter>userdata</parameter></paramdef>
+      </funcprototype>
+
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_event_source_set_prepare()</function> may be
+    used to set a preparation callback for the event source object
+    specified as <parameter>source</parameter>. The callback function
+    specified as <parameter>callback</parameter> will be invoked
+    immediately before the event loop goes to sleep to wait for
+    incoming events. It is invoked with the user data pointer passed
+    when the event source was created. The event source will be disabled
+    if the callback function returns a negative error code. The callback
+    function may be used to reconfigure the precise events to wait for.
+    If the <parameter>callback</parameter> parameter is passed as <constant>NULL</constant>
+    the callback function is reset. </para>
+
+    <para>Event source objects have no preparation callback associated
+    when they are first created with calls such as
+    <citerefentry><refentrytitle>sd_event_add_io</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_event_add_time</refentrytitle><manvolnum>3</manvolnum></citerefentry>. Preparation
+    callback functions are supported for all event source types with
+    the exception of those created with
+    <citerefentry><refentrytitle>sd_event_add_exit</refentrytitle><manvolnum>3</manvolnum></citerefentry>. Preparation
+    callback functions are dispatched in the order indicated by the
+    event source's priority field, as set with
+    <citerefentry><refentrytitle>sd_event_source_set_priority</refentrytitle><manvolnum>3</manvolnum></citerefentry>. Preparation
+    callbacks of disabled event sources (see
+    <citerefentry><refentrytitle>sd_event_source_set_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry>)
+    are not invoked.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, <function>sd_event_source_set_prepare()</function> returns a non-negative integer. On
+    failure, it returns a negative errno-style error code.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para><parameter>source</parameter> is not a valid pointer to an
+          <structname>sd_event_source</structname> object.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ESTALE</constant></term>
+
+          <listitem><para>The event loop is already terminated.</para></listitem>
+
+        </varlistentry>
+        <varlistentry>
+          <term><constant>-ENOMEM</constant></term>
+
+          <listitem><para>Not enough memory.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ECHILD</constant></term>
+
+          <listitem><para>The event loop has been created in a different process, library or module instance.</para></listitem>
+
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EDOM</constant></term>
+
+          <listitem><para>The specified event source has been created with
+          <citerefentry><refentrytitle>sd_event_add_exit</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para></listitem>
+
+        </varlistentry>
+
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_event_source_set_prepare()</function> and
+    <function>sd_event_handler_t()</function> were added in version 229.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_io</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_time</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_child</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_inotify</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_defer</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_source_set_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_source_set_priority</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_source_set_userdata</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_event_source_set_priority.xml b/man/sd_event_source_set_priority.xml
new file mode 100644
index 0000000..7b6f046
--- /dev/null
+++ b/man/sd_event_source_set_priority.xml
@@ -0,0 +1,172 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_event_source_set_priority" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_event_source_set_priority</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_event_source_set_priority</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_event_source_set_priority</refname>
+    <refname>sd_event_source_get_priority</refname>
+    <refname>SD_EVENT_PRIORITY_IMPORTANT</refname>
+    <refname>SD_EVENT_PRIORITY_NORMAL</refname>
+    <refname>SD_EVENT_PRIORITY_IDLE</refname>
+
+    <refpurpose>Set or retrieve the priority of event sources</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-event.h&gt;</funcsynopsisinfo>
+
+      <funcsynopsisinfo><token>enum</token> {
+        <constant>SD_EVENT_PRIORITY_IMPORTANT</constant> = -100,
+        <constant>SD_EVENT_PRIORITY_NORMAL</constant> = 0,
+        <constant>SD_EVENT_PRIORITY_IDLE</constant> = 100,
+};</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_event_source_set_priority</function></funcdef>
+        <paramdef>sd_event_source *<parameter>source</parameter></paramdef>
+        <paramdef>int64_t <parameter>priority</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_event_source_get_priority</function></funcdef>
+        <paramdef>sd_event_source *<parameter>source</parameter></paramdef>
+        <paramdef>int64_t *<parameter>priority</parameter></paramdef>
+      </funcprototype>
+
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_event_source_set_priority()</function> may be
+    used to set the priority for the event source object specified as
+    <parameter>source</parameter>. The priority is specified as an
+    arbitrary signed 64-bit integer. The priority is initialized to
+    <constant>SD_EVENT_PRIORITY_NORMAL</constant> (0) when the event
+    source is allocated with a call such as
+    <citerefentry><refentrytitle>sd_event_add_io</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    or
+    <citerefentry><refentrytitle>sd_event_add_time</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    and may be changed with this call. If multiple event sources have seen events at the same time, they are dispatched in the order indicated by the
+    event sources' priorities. Event sources with smaller priority
+    values are dispatched first. As well-known points of reference,
+    the constants <constant>SD_EVENT_PRIORITY_IMPORTANT</constant>
+    (-100), <constant>SD_EVENT_PRIORITY_NORMAL</constant> (0) and
+    <constant>SD_EVENT_PRIORITY_IDLE</constant> (100) may be used to
+    indicate event sources that shall be dispatched early, normally or
+    late. It is recommended to specify priorities based on these
+    definitions, and relative to them — however, the full 64-bit
+    signed integer range is available for ordering event
+    sources.</para>
+
+    <para>Priorities define the order in which event sources that have
+    seen events are dispatched. Care should be taken to ensure that
+    high-priority event sources (those with negative priority values
+    assigned) do not cause starvation of low-priority event sources
+    (those with positive priority values assigned).</para>
+
+    <para>The order in which event sources with the same priority are
+    dispatched is undefined, but the event loop generally tries to
+    dispatch them in the order it learnt about events on them. As the
+    backing kernel primitives do not provide accurate information
+    about the order in which events occurred this is not necessarily
+    reliable. However, it is guaranteed that if events are seen on
+    multiple same-priority event sources at the same time, each one is
+    not dispatched again until all others have been dispatched
+    once. This behavior guarantees that within each priority
+    particular event sources do not starve or dominate the event
+    loop.</para>
+
+    <para>The priority of event sources may be changed at any time of their lifetime, with the exception of inotify
+    event sources (i.e. those created with
+    <citerefentry><refentrytitle>sd_event_add_inotify</refentrytitle><manvolnum>3</manvolnum></citerefentry>) whose
+    priority may only be changed in the time between their initial creation and the first subsequent event loop
+    iteration.</para>
+
+    <para><function>sd_event_source_get_priority()</function> may be
+    used to query the current priority assigned to the event source
+    object <parameter>source</parameter>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, <function>sd_event_source_set_priority()</function> and
+    <function>sd_event_source_get_priority()</function> return a non-negative integer. On failure, they
+    return a negative errno-style error code.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para><parameter>source</parameter> is not a valid pointer to an
+          <structname>sd_event_source</structname> object.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOMEM</constant></term>
+
+          <listitem><para>Not enough memory.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ESTALE</constant></term>
+
+          <listitem><para>The event loop is already terminated.</para></listitem>
+
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ECHILD</constant></term>
+
+          <listitem><para>The event loop has been created in a different process, library or module instance.</para></listitem>
+
+        </varlistentry>
+
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_event_source_set_priority()</function> and
+    <function>sd_event_source_get_priority()</function> were added in version 229.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_io</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_time</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_child</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_inotify</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_defer</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_event_source_set_ratelimit.xml b/man/sd_event_source_set_ratelimit.xml
new file mode 100644
index 0000000..cf45102
--- /dev/null
+++ b/man/sd_event_source_set_ratelimit.xml
@@ -0,0 +1,188 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_event_source_set_ratelimit" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_event_source_set_ratelimit</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_event_source_set_ratelimit</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_event_source_set_ratelimit</refname>
+    <refname>sd_event_source_get_ratelimit</refname>
+    <refname>sd_event_source_is_ratelimited</refname>
+    <refname>sd_event_source_set_ratelimit_expire_callback</refname>
+    <refname>sd_event_source_leave_ratelimit</refname>
+
+    <refpurpose>Configure rate limiting on event sources</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-event.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_event_source_set_ratelimit</function></funcdef>
+        <paramdef>sd_event_source *<parameter>source</parameter></paramdef>
+        <paramdef>uint64_t <parameter>interval_usec</parameter></paramdef>
+        <paramdef>unsigned <parameter>burst</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_event_source_get_ratelimit</function></funcdef>
+        <paramdef>sd_event_source *<parameter>source</parameter></paramdef>
+        <paramdef>uint64_t* <parameter>ret_interval_usec</parameter></paramdef>
+        <paramdef>unsigned* <parameter>ret_burst</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_event_source_is_ratelimited</function></funcdef>
+        <paramdef>sd_event_source *<parameter>source</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_event_source_set_ratelimit_expire_callback</function></funcdef>
+        <paramdef>sd_event_source *<parameter>source</parameter></paramdef>
+        <paramdef>sd_event_handler_t<parameter>callback</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_event_source_leave_ratelimit</function></funcdef>
+        <paramdef>sd_event_source *<parameter>source</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_event_source_set_ratelimit()</function> may be used to enforce rate limiting on an
+    event source. When used an event source will be temporarily turned off when it fires more often then a
+    specified burst number within a specified time interval. This is useful as simple mechanism to avoid
+    event source starvation if high priority event sources fire very frequently.</para>
+
+    <para>Pass the event source to operate on as first argument, a time interval in microseconds as second
+    argument and a maximum dispatch limit ("burst") as third parameter. Whenever the event source is
+    dispatched more often than the specified burst within the specified interval it is placed in a mode
+    similar to being disabled with
+    <citerefentry><refentrytitle>sd_event_source_set_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    and the <constant>SD_EVENT_OFF</constant> parameter. However it is disabled only temporarily – once the
+    specified interval is over regular operation resumes. It is again disabled temporarily once the specified rate
+    limiting is hit the next time. If either the interval or the burst value are specified as zero, rate
+    limiting is turned off. By default event sources do not have rate limiting enabled. Note that rate
+    limiting and disabling via <function>sd_event_source_set_enabled()</function> are independent of each
+    other, and an event source will only effect event loop wake-ups and is dispatched while it both is
+    enabled and rate limiting is not in effect.</para>
+
+    <para><function>sd_event_source_get_ratelimit()</function> may be used to query the current rate limiting
+    parameters set on the event source object <parameter>source</parameter>. The previously set interval and
+    burst vales are returned in the second and third argument.</para>
+
+    <para><function>sd_event_source_is_ratelimited()</function> may be used to query whether the event source
+    is currently affected by rate limiting, i.e. it has recently hit the rate limit and is currently
+    temporarily disabled due to that.</para>
+
+    <para><function>sd_event_source_set_ratelimit_expire_callback()</function> may be used to set a callback
+    function that is invoked every time the event source leaves rate limited state. Note that function is
+    called in the same event loop iteration in which state transition occurred.</para>
+
+    <para><function>sd_event_source_leave_ratelimit()</function> may be used to immediately reenable an event
+    source that was temporarily disabled due to rate limiting. This will reset the ratelimit counters for the
+    current time interval.</para>
+
+    <para>Rate limiting is currently implemented for I/O, timer, signal, defer and inotify event
+    sources.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, <function>sd_event_source_set_ratelimit()</function>,
+    <function>sd_event_source_set_ratelimit_expire_callback</function> and
+    <function>sd_event_source_get_ratelimit()</function> return a non-negative integer. On failure, they
+    return a negative errno-style error code. <function>sd_event_source_is_ratelimited()</function> returns
+    zero if rate limiting is currently not in effect and greater than zero if it is in effect; it returns a
+    negative errno-style error code on failure. <function>sd_event_source_leave_ratelimit()</function>
+    returns zero if rate limiting wasn't in effect on the specified event source, and positive if it was and
+    rate limiting is now turned off again; it returns a negative errno-style error code on failure.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para><parameter>source</parameter> is not a valid pointer to an
+          <structname>sd_event_source</structname> object.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v248"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ECHILD</constant></term>
+
+          <listitem><para>The event loop has been created in a different process, library or module instance.</para>
+
+          <xi:include href="version-info.xml" xpointer="v248"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EDOM</constant></term>
+
+          <listitem><para>It was attempted to use the rate limiting feature on an event source type that does
+          not support rate limiting.</para>
+
+          <xi:include href="version-info.xml" xpointer="v248"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOEXEC</constant></term>
+
+          <listitem><para><function>sd_event_source_get_ratelimit()</function> was called on an event source
+          that doesn't have rate limiting configured.</para>
+
+          <xi:include href="version-info.xml" xpointer="v248"/></listitem>
+        </varlistentry>
+
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_event_source_set_ratelimit()</function>,
+    <function>sd_event_source_get_ratelimit()</function>, and
+    <function>sd_event_source_is_ratelimited()</function> were added in version 248.</para>
+    <para><function>sd_event_source_set_ratelimit_expire_callback()</function> was added in version 250.</para>
+    <para><function>sd_event_source_leave_ratelimit()</function> was added in version 254.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_io</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_time</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_inotify</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_defer</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_source_set_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_event_source_set_userdata.xml b/man/sd_event_source_set_userdata.xml
new file mode 100644
index 0000000..b1bd8d4
--- /dev/null
+++ b/man/sd_event_source_set_userdata.xml
@@ -0,0 +1,99 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_event_source_set_userdata" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_event_source_set_userdata</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_event_source_set_userdata</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_event_source_set_userdata</refname>
+    <refname>sd_event_source_get_userdata</refname>
+
+    <refpurpose>Set or retrieve user data pointer of event sources</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-event.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>void* <function>sd_event_source_set_userdata</function></funcdef>
+        <paramdef>sd_event_source *<parameter>source</parameter></paramdef>
+        <paramdef>void *<parameter>userdata</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>void* <function>sd_event_source_get_userdata</function></funcdef>
+        <paramdef>sd_event_source *<parameter>source</parameter></paramdef>
+      </funcprototype>
+
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_event_source_set_userdata()</function> may be
+    used to set an arbitrary user data pointer for the event source
+    object specified as <parameter>source</parameter>. The user data
+    pointer is usually specified when creating an event source object
+    with calls such as
+    <citerefentry><refentrytitle>sd_event_add_io</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    or
+    <citerefentry><refentrytitle>sd_event_add_time</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    and may be updated with this call. The user data pointer is also
+    passed to all handler callback functions associated with the event
+    source. The <parameter>userdata</parameter> parameter specifies
+    the new user data pointer to set, the function returns the
+    previous user data pointer. Note that <constant>NULL</constant> is
+    a valid user data pointer.</para>
+
+    <para><function>sd_event_source_get_userdata()</function> may be
+    used to query the current user data pointer assigned to the event
+    source object <parameter>source</parameter>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success,
+    <function>sd_event_source_set_userdata()</function> and
+    <function>sd_event_source_get_userdata()</function> return the
+    previously set user data pointer. On failure, they return
+    <constant>NULL</constant>.</para>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_event_source_set_userdata()</function> and
+    <function>sd_event_source_get_userdata()</function> were added in version 229.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_io</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_time</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_child</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_inotify</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_defer</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_source_set_description</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_event_source_unref.xml b/man/sd_event_source_unref.xml
new file mode 100644
index 0000000..22ce6f5
--- /dev/null
+++ b/man/sd_event_source_unref.xml
@@ -0,0 +1,141 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_event_source_unref" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_event_source_unref</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_event_source_unref</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_event_source_unref</refname>
+    <refname>sd_event_source_unrefp</refname>
+    <refname>sd_event_source_ref</refname>
+    <refname>sd_event_source_disable_unref</refname>
+    <refname>sd_event_source_disable_unrefp</refname>
+
+    <refpurpose>Increase or decrease event source reference counters</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-event.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>sd_event_source* <function>sd_event_source_unref</function></funcdef>
+        <paramdef>sd_event_source *<parameter>source</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>void <function>sd_event_source_unrefp</function></funcdef>
+        <paramdef>sd_event_source **<parameter>source</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>sd_event_source* <function>sd_event_source_ref</function></funcdef>
+        <paramdef>sd_event_source *<parameter>source</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>sd_event_source* <function>sd_event_source_disable_unref</function></funcdef>
+        <paramdef>sd_event_source *<parameter>source</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>void <function>sd_event_source_disable_unrefp</function></funcdef>
+        <paramdef>sd_event_source **<parameter>source</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_event_source_unref()</function> may be used to decrement by one the internal reference
+    counter of the event source object specified as <parameter>source</parameter>. The reference counter is
+    initially set to one, when the event source is created with calls such as
+    <citerefentry><refentrytitle>sd_event_add_io</refentrytitle><manvolnum>3</manvolnum></citerefentry> or
+    <citerefentry><refentrytitle>sd_event_add_time</refentrytitle><manvolnum>3</manvolnum></citerefentry>. When
+    the reference counter reaches zero, the object is detached from the event loop object and destroyed.
+    </para>
+
+    <para><function>sd_event_source_unrefp()</function> is similar to
+    <function>sd_event_source_unref()</function> but takes a pointer to a
+    pointer to an <type>sd_event_source</type> object. This call is useful in
+    conjunction with GCC's and LLVM's <ulink
+    url="https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html">Clean-up
+    Variable Attribute</ulink>. Note that this function is defined as
+    inline function.</para>
+
+    <para><function>sd_event_source_ref()</function> may be used to increase by one the internal reference
+    counter of the event source object specified as <parameter>source</parameter>.</para>
+
+    <para><function>sd_event_source_unref()</function>,
+    <function>sd_bus_creds_unrefp()</function> and
+    <function>sd_bus_creds_ref()</function> execute no operation if
+    the passed event source object is
+    <constant>NULL</constant>.</para>
+
+    <para>Note that event source objects stay alive and may be dispatched as long as they have a reference
+    counter greater than zero. In order to drop a reference of an event source and make sure the associated
+    event source handler function is not called anymore it is recommended to combine a call of
+    <function>sd_event_source_unref()</function> with a prior call to
+    <function>sd_event_source_set_enabled()</function> with <constant>SD_EVENT_OFF</constant> or call
+    <function>sd_event_source_disable_unref()</function>, see below.</para>
+
+    <para><function>sd_event_source_disable_unref()</function> combines a call to
+    <function>sd_event_source_set_enabled()</function> with <constant>SD_EVENT_OFF</constant> with
+    <function>sd_event_source_unref()</function>. This ensures that the source is disabled before the local
+    reference to it is lost. The <parameter>source</parameter> parameter is allowed to be
+    <constant>NULL</constant>.</para>
+
+    <para><function>sd_event_source_disable_unrefp()</function> is similar to
+    <function>sd_event_source_unrefp()</function>, but in addition disables the source first. This call is
+    useful in conjunction with GCC's and LLVM's
+    <ulink url="https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html">Clean-up Variable
+    Attribute</ulink>. Note that this function is defined as inline function.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para><function>sd_event_source_unref()</function> and
+    <function>sd_event_source_disable_unref()</function> always return <constant>NULL</constant>.
+    <function>sd_event_source_ref()</function> always returns the event source object passed in.</para>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_event_source_unref()</function>,
+    <function>sd_event_source_unrefp()</function>, and
+    <function>sd_event_source_ref()</function> were added in version 229.</para>
+    <para><function>sd_event_source_disable_unref()</function> and
+    <function>sd_event_source_disable_unrefp()</function> were added in version 243.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_io</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_time</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_child</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_inotify</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_defer</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_source_set_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_event_wait.xml b/man/sd_event_wait.xml
new file mode 100644
index 0000000..0f635f6
--- /dev/null
+++ b/man/sd_event_wait.xml
@@ -0,0 +1,347 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_event_wait" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_event_wait</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_event_wait</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_event_wait</refname>
+    <refname>sd_event_prepare</refname>
+    <refname>sd_event_dispatch</refname>
+    <refname>sd_event_get_state</refname>
+    <refname>sd_event_get_iteration</refname>
+    <refname>SD_EVENT_INITIAL</refname>
+    <refname>SD_EVENT_PREPARING</refname>
+    <refname>SD_EVENT_ARMED</refname>
+    <refname>SD_EVENT_PENDING</refname>
+    <refname>SD_EVENT_RUNNING</refname>
+    <refname>SD_EVENT_EXITING</refname>
+    <refname>SD_EVENT_FINISHED</refname>
+
+    <refpurpose>Low-level event loop operations</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-event.h&gt;</funcsynopsisinfo>
+
+      <funcsynopsisinfo><token>enum</token> {
+        <constant>SD_EVENT_INITIAL</constant>,
+        <constant>SD_EVENT_PREPARING</constant>,
+        <constant>SD_EVENT_ARMED</constant>,
+        <constant>SD_EVENT_PENDING</constant>,
+        <constant>SD_EVENT_RUNNING</constant>,
+        <constant>SD_EVENT_EXITING</constant>,
+        <constant>SD_EVENT_FINISHED</constant>,
+};</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_event_prepare</function></funcdef>
+        <paramdef>sd_event *<parameter>event</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_event_wait</function></funcdef>
+        <paramdef>sd_event *<parameter>event</parameter></paramdef>
+        <paramdef>uint64_t <parameter>usec</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_event_dispatch</function></funcdef>
+        <paramdef>sd_event *<parameter>event</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_event_get_state</function></funcdef>
+        <paramdef>sd_event *<parameter>event</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_event_get_iteration</function></funcdef>
+        <paramdef>sd_event *<parameter>event</parameter></paramdef>
+        <paramdef>uint64_t *<parameter>ret</parameter></paramdef>
+      </funcprototype>
+
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>The low-level <function>sd_event_prepare()</function>,
+    <function>sd_event_wait()</function> and
+    <function>sd_event_dispatch()</function> functions may be used to
+    execute specific phases of an event loop. See
+    <citerefentry><refentrytitle>sd_event_run</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    and
+    <citerefentry><refentrytitle>sd_event_loop</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    for higher-level functions that execute individual but complete
+    iterations of an event loop or run it continuously.</para>
+
+    <para><function>sd_event_prepare()</function> checks for pending
+    events and arms necessary timers. If any events are ready to be
+    processed ("pending"), it returns a positive, non-zero value, and the caller
+    should process these events with
+    <function>sd_event_dispatch()</function>.</para>
+
+    <para><function>sd_event_dispatch()</function> dispatches the
+    highest priority event source that has a pending event. On
+    success, <function>sd_event_dispatch()</function> returns either
+    zero, which indicates that no further event sources may be
+    dispatched and exiting of the event loop was requested via
+    <citerefentry><refentrytitle>sd_event_exit</refentrytitle><manvolnum>3</manvolnum></citerefentry>;
+    or a positive non-zero value, which means that an event source was
+    dispatched and the loop returned to its initial state, and the
+    caller should initiate the next event loop iteration by invoking
+    <function>sd_event_prepare()</function> again.</para>
+
+    <para>In case <function>sd_event_prepare()</function> returned
+    zero, <function>sd_event_wait()</function> should be called to
+    wait for further events or a timeout. If any events are ready to
+    be processed, it returns a positive, non-zero value, and the
+    events should be dispatched with
+    <function>sd_event_dispatch()</function>. Otherwise, the event
+    loop returned to its initial state and the next event loop
+    iteration should be initiated by invoking
+    <function>sd_event_prepare()</function> again.</para>
+
+    <para><function>sd_event_get_state()</function> may be used to
+    determine the state the event loop is currently in. It returns one
+    of the states described below.</para>
+
+    <para><function>sd_event_get_iteration()</function> may be used to determine the current iteration of the event
+    loop. It returns an unsigned 64-bit integer containing a counter that increases monotonically with each iteration of
+    the event loop, starting with 0. The counter is increased at the time of the
+    <function>sd_event_prepare()</function> invocation.</para>
+
+    <para>All five functions take, as the first argument, the event loop object <parameter>event</parameter> that has
+    been created with <function>sd_event_new()</function>. The timeout for <function>sd_event_wait()</function> is
+    specified in <parameter>usec</parameter> in microseconds.  <constant>(uint64_t) -1</constant> may be used to
+    specify an infinite timeout.</para>
+</refsect1>
+
+  <refsect1>
+    <title>State Machine</title>
+
+    <para>The event loop knows the following states, that may be
+    queried with <function>sd_event_get_state()</function>.</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><constant>SD_EVENT_INITIAL</constant></term>
+
+        <listitem><para>The initial state the event loop is in,
+        before each event loop iteration. Use
+        <function>sd_event_prepare()</function> to transition the
+        event loop into the <constant>SD_EVENT_ARMED</constant> or
+        <constant>SD_EVENT_PENDING</constant> states.</para>
+
+        <xi:include href="version-info.xml" xpointer="v229"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><constant>SD_EVENT_PREPARING</constant></term>
+
+        <listitem><para>An event source is currently being prepared,
+        i.e. the preparation handler is currently being executed, as
+        set with
+        <citerefentry><refentrytitle>sd_event_source_set_prepare</refentrytitle><manvolnum>3</manvolnum></citerefentry>. This
+        state is only seen in the event source preparation handler
+        that is invoked from the
+        <function>sd_event_prepare()</function> call and is
+        immediately followed by <constant>SD_EVENT_ARMED</constant> or
+        <constant>SD_EVENT_PENDING</constant>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v229"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><constant>SD_EVENT_ARMED</constant></term>
+
+        <listitem><para><function>sd_event_prepare()</function> has
+        been called and no event sources were ready to be
+        dispatched. Use <function>sd_event_wait()</function> to wait
+        for new events, and transition into
+        <constant>SD_EVENT_PENDING</constant> or back into
+        <constant>SD_EVENT_INITIAL</constant>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v229"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><constant>SD_EVENT_PENDING</constant></term>
+
+        <listitem><para><function>sd_event_prepare()</function> or
+        <function>sd_event_wait()</function> have been called and
+        there were event sources with events pending. Use
+        <function>sd_event_dispatch()</function> to dispatch the
+        highest priority event source and transition back to
+        <constant>SD_EVENT_INITIAL</constant>, or
+        <constant>SD_EVENT_FINISHED</constant>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v229"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><constant>SD_EVENT_RUNNING</constant></term>
+
+        <listitem><para>A regular event source is currently being
+        dispatched. This state is only seen in the event source
+        handler that is invoked from the
+        <function>sd_event_dispatch()</function> call, and is
+        immediately followed by <constant>SD_EVENT_INITIAL</constant>
+        or <constant>SD_EVENT_FINISHED</constant> as soon the event
+        source handler returns. Note that during dispatching of exit
+        event sources the <constant>SD_EVENT_EXITING</constant> state
+        is seen instead.</para>
+
+        <xi:include href="version-info.xml" xpointer="v229"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><constant>SD_EVENT_EXITING</constant></term>
+
+        <listitem><para>Similar to
+        <constant>SD_EVENT_RUNNING</constant> but is the state in
+        effect while dispatching exit event sources. It is followed by
+        <constant>SD_EVENT_INITIAL</constant> or
+        <constant>SD_EVENT_FINISHED</constant> as soon as the event
+        handler returns.</para>
+
+        <xi:include href="version-info.xml" xpointer="v229"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><constant>SD_EVENT_FINISHED</constant></term>
+
+        <listitem><para>The event loop has exited. All exit event
+        sources have run. If the event loop is in this state it serves
+        no purpose anymore, and should be freed.</para>
+
+        <xi:include href="version-info.xml" xpointer="v229"/></listitem>
+      </varlistentry>
+
+    </variablelist>
+
+    <para>A simplified flow chart of the states and the calls to
+    transition between them is shown below. Note that
+    <constant>SD_EVENT_PREPARING</constant>,
+    <constant>SD_EVENT_RUNNING</constant> and
+    <constant>SD_EVENT_EXITING</constant> are not shown here.</para>
+
+    <programlisting>
+          INITIAL -&lt;---&lt;---&lt;---&lt;---&lt;---&lt;---&lt;---&lt;---&lt;---&lt;---&lt;---&lt;---\
+             |                                                     |
+             |                                                     ^
+             |                                                     |
+             v                 ret == 0                            |
+      sd_event_prepare() &gt;---&gt;---&gt;---&gt;---&gt;- ARMED                  |
+             |                                |                    ^
+             | ret > 0                        |                    |
+             |                                |                    |
+             v                                v          ret == 0  |
+          PENDING &lt;---&lt;---&lt;---&lt;---&lt;---&lt; sd_event_wait() &gt;---&gt;---&gt;--+
+             |           ret > 0                                   ^
+             |                                                     |
+             |                                                     |
+             v                                                     |
+      sd_event_dispatch() &gt;---&gt;---&gt;---&gt;---&gt;---&gt;---&gt;---&gt;---&gt;---&gt;---&gt;/
+             |                             ret > 0
+             | ret == 0
+             |
+             v
+          FINISHED
+    </programlisting>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, these functions return 0 or a positive integer.  On failure, they return a negative
+    errno-style error code. In case of <function>sd_event_prepare()</function> and
+    <function>sd_event_wait()</function>, a positive, non-zero return code indicates that events are ready to
+    be processed and zero indicates that no events are ready. In case of
+    <function>sd_event_dispatch()</function>, a positive, non-zero return code indicates that the event loop
+    returned to its initial state and zero indicates the event loop has
+    exited. <function>sd_event_get_state()</function> returns a positive or zero state on success.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>The <parameter>event</parameter> parameter is invalid or <constant>NULL</constant>.
+          </para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EBUSY</constant></term>
+
+          <listitem><para>The event loop object is not in the right state.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ESTALE</constant></term>
+
+          <listitem><para>The event loop is already terminated.</para></listitem>
+
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ECHILD</constant></term>
+
+          <listitem><para>The event loop has been created in a different process, library or module instance.</para></listitem>
+
+        </varlistentry>
+
+      </variablelist>
+
+      <para>Other errors are possible, too.</para>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_event_prepare()</function>,
+    <function>sd_event_wait()</function>, and
+    <function>sd_event_dispatch()</function> were added in version 220.</para>
+    <para><function>sd_event_get_state()</function> was added in version 229.</para>
+    <para><function>sd_event_get_iteration()</function> was added in version 231.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_io</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_time</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_signal</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_child</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_inotify</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_add_defer</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_run</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_get_fd</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_source_set_prepare</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_get_seats.xml b/man/sd_get_seats.xml
new file mode 100644
index 0000000..a19495c
--- /dev/null
+++ b/man/sd_get_seats.xml
@@ -0,0 +1,123 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_get_seats" conditional='HAVE_PAM'
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_get_seats</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_get_seats</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_get_seats</refname>
+    <refname>sd_get_sessions</refname>
+    <refname>sd_get_uids</refname>
+    <refname>sd_get_machine_names</refname>
+    <refpurpose>Determine available seats, sessions, logged in users and virtual machines/containers</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-login.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_get_seats</function></funcdef>
+        <paramdef>char ***<parameter>seats</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_get_sessions</function></funcdef>
+        <paramdef>char ***<parameter>sessions</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_get_uids</function></funcdef>
+        <paramdef>uid_t **<parameter>users</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_get_machine_names</function></funcdef>
+        <paramdef>char ***<parameter>machines</parameter></paramdef>
+      </funcprototype>
+
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_get_seats()</function> may be used to determine
+    all currently available local seats. Returns the number of seat
+    identifiers and if the input pointer is non-<constant>NULL</constant>, a
+    <constant>NULL</constant>-terminated array of seat identifiers
+    is stored at the address.
+    The returned array and all strings it references need to be freed
+    with the libc
+    <citerefentry project='man-pages'><refentrytitle>free</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    call after use. Note that instead of an empty array
+    <constant>NULL</constant> may be returned and should be considered
+    equivalent to an empty array.</para>
+
+    <para>Similarly, <function>sd_get_sessions()</function> may be
+    used to determine all current login sessions.</para>
+
+    <para>Similarly, <function>sd_get_uids()</function> may be used to
+    determine all Unix users who currently have login sessions.</para>
+
+    <para>Similarly, <function>sd_get_machine_names()</function> may
+    be used to determine all current virtual machines and containers
+    on the system.</para>
+
+    <para>Note that the returned lists are not sorted and in an
+    undefined order.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, <function>sd_get_seats()</function>, <function>sd_get_sessions()</function>,
+    <function>sd_get_uids()</function> and <function>sd_get_machine_names()</function> return the number of
+    entries in the arrays. On failure, these calls return a negative errno-style error code.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+
+        <varlistentry>
+          <term><constant>-ENOMEM</constant></term>
+
+          <listitem><para>Memory allocation failed.</para></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_get_machine_names()</function> was added in version 203.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-login</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_session_get_seat</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_hwdb_get.xml b/man/sd_hwdb_get.xml
new file mode 100644
index 0000000..4f2e701
--- /dev/null
+++ b/man/sd_hwdb_get.xml
@@ -0,0 +1,171 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_hwdb_get" xmlns:xi="http://www.w3.org/2001/XInclude">
+  <refentryinfo>
+    <title>sd_hwdb_get</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_hwdb_get</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_hwdb_get</refname>
+    <refname>sd_hwdb_seek</refname>
+    <refname>sd_hwdb_enumerate</refname>
+    <refname>SD_HWDB_FOREACH_PROPERTY</refname>
+
+    <refpurpose>Seek to a location in hwdb or access entries</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-hwdb.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_hwdb_get</function></funcdef>
+        <paramdef>sd_hwdb *<parameter>hwdb</parameter></paramdef>
+        <paramdef>const char *<parameter>modalias</parameter></paramdef>
+        <paramdef>const char *<parameter>key</parameter></paramdef>
+        <paramdef>const char **<parameter>value</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_hwdb_seek</function></funcdef>
+        <paramdef>sd_hwdb *<parameter>hwdb</parameter></paramdef>
+        <paramdef>const char *<parameter>modalias</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_hwdb_enumerate</function></funcdef>
+        <paramdef>sd_hwdb *<parameter>hwdb</parameter></paramdef>
+        <paramdef>const char **<parameter>key</parameter></paramdef>
+        <paramdef>const char **<parameter>value</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef><function>SD_HWDB_FOREACH_PROPERTY</function></funcdef>
+        <paramdef>hwdb</paramdef>
+        <paramdef>modalias</paramdef>
+        <paramdef>key</paramdef>
+        <paramdef>value</paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_hwdb_get()</function> queries the <parameter>hwdb</parameter> object created earlier
+    with <citerefentry><refentrytitle>sd_hwdb_new</refentrytitle><manvolnum>3</manvolnum></citerefentry> for
+    entries matching the specified string <parameter>modalias</parameter>, and returns the value
+    corresponding to the key <parameter>key</parameter>. The value is returned as a
+    <constant>NUL</constant>-terminated string in <parameter>value</parameter>. It must not be modified by
+    the caller and is valid as long as a reference to <parameter>hwdb</parameter> is kept. When multiple
+    patterns in the database match <parameter>modalias</parameter>, the one with the highest priority is
+    used. See <citerefentry><refentrytitle>hwdb</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
+    details.</para>
+
+    <para><function>sd_hwdb_seek()</function> selects entries matching the specified string
+    <parameter>modalias</parameter>. Subsequent queries with <function>sd_hwdb_enumerate()</function> will
+    access the key-value pairs for that string.</para>
+
+    <para><function>sd_hwdb_enumerate()</function> returns (in turn) all the key-value pairs defined for the
+    string used with <function>sd_hwdb_seek()</function>. Each pair is returned as
+    <constant>NUL</constant>-terminated strings in <parameter>key</parameter> and
+    <parameter>value</parameter>. The strings must not be modified by the caller and are valid as long as a
+    reference to <parameter>hwdb</parameter> is kept. When multiple patterns in the database match
+    <parameter>modalias</parameter>, the combination of all matching key-value pairs is used. See
+    <citerefentry><refentrytitle>hwdb</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
+    details.</para>
+
+    <para>The <function>SD_HWDB_FOREACH_PROPERTY()</function> macro combines
+    <function>sd_hwdb_seek()</function> and <function>sd_hwdb_enumerate()</function>. No error handling is
+    performed and iteration simply stops on error. See the example below.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, <function>sd_hwdb_get()</function> and <function>sd_hwdb_seek()</function> return a
+    non-negative integer. On failure, they return a negative errno-style error code.</para>
+
+    <para><function>sd_hwdb_enumerate()</function> returns a positive integer if another key-value pair was found or zero if
+    all entries have already been enumerated. On failure, it returns a negative errno-style error code.
+    </para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>A parameter is <constant>NULL</constant>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOENT</constant></term>
+
+          <listitem><para>An entry for the specified <parameter>modalias</parameter> was not found.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EAGAIN</constant></term>
+
+          <listitem><para><function>sd_hwdb_seek()</function> was not called before
+          <function>sd_hwdb_enumerate()</function>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>Examples</title>
+
+    <example>
+      <title>Look up hwdb entries for a USB device</title>
+
+      <programlisting><xi:include href="hwdb-usb-device.c" parse="text" /></programlisting>
+
+      <para>The effect is similar to calling <command>systemd-hwdb query usb:v046DpC534</command>.
+      </para>
+    </example>
+  </refsect1>
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_hwdb_get()</function>,
+    <function>sd_hwdb_seek()</function>,
+    <function>sd_hwdb_enumerate()</function>, and
+    <function>SD_HWDB_FOREACH_PROPERTY()</function> were added in version 246.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-udevd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-hwdb</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-hwdb</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_hwdb_new.xml b/man/sd_hwdb_new.xml
new file mode 100644
index 0000000..4d02dea
--- /dev/null
+++ b/man/sd_hwdb_new.xml
@@ -0,0 +1,145 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_hwdb_new" xmlns:xi="http://www.w3.org/2001/XInclude">
+  <refentryinfo>
+    <title>sd_hwdb_new</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_hwdb_new</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_hwdb_new</refname>
+    <refname>sd_hwdb_new_from_path</refname>
+    <refname>sd_hwdb_ref</refname>
+    <refname>sd_hwdb_unref</refname>
+
+    <refpurpose>Create a new hwdb object and create or destroy references to it</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-hwdb.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_hwdb_new</function></funcdef>
+        <paramdef>sd_hwdb **<parameter>hwdb</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_hwdb_new_from_path</function></funcdef>
+        <paramdef>const char *<parameter>path</parameter></paramdef>
+        <paramdef>sd_hwdb **<parameter>hwdb</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>sd_hwdb* <function>sd_hwdb_ref</function></funcdef>
+        <paramdef>sd_hwdb *<parameter>hwdb</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>sd_hwdb* <function>sd_hwdb_unref</function></funcdef>
+        <paramdef>sd_hwdb *<parameter>hwdb</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_hwdb_new()</function> creates a new hwdb object to access the binary hwdb
+    database. Upon initialization, the file containing the binary representation of the hardware database is
+    located and opened. The new object is returned in <parameter>hwdb</parameter>.</para>
+
+    <para><function>sd_hwdb_new_from_path()</function> may be used to specify the path from which the binary
+    hardware database should be opened.</para>
+
+    <para>The <parameter>hwdb</parameter> object is reference counted. <function>sd_hwdb_ref()</function> and
+    <function>sd_hwdb_unref()</function> may be used to get a new reference or destroy an existing reference
+    to an object. The caller must dispose of the reference acquired with <function>sd_hwdb_new()</function>
+    by calling <function>sd_hwdb_unref()</function> when done with the object.</para>
+
+    <para>Use
+    <citerefentry><refentrytitle>sd_hwdb_seek</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_hwdb_get</refentrytitle><manvolnum>3</manvolnum></citerefentry>, and
+    <citerefentry><refentrytitle>sd_hwdb_enumerate</refentrytitle><manvolnum>3</manvolnum></citerefentry> to
+    access entries.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, <function>sd_hwdb_new()</function> and <function>sd_hwdb_new_from_path()</function>
+    return a non-negative integer. On failure, a negative errno-style error code is returned.</para>
+
+    <para><function>sd_hwdb_ref()</function> always returns the argument.
+    </para>
+
+    <para><function>sd_hwdb_unref()</function> always returns <constant>NULL</constant>.
+    </para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-ENOENT</constant></term>
+
+          <listitem><para>The binary hardware database file could not be located. See
+          <citerefentry><refentrytitle>systemd-hwdb</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+          for more information.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>The located binary hardware database file is in an incompatible format.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOMEM</constant></term>
+
+          <listitem><para>Memory allocation failed.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_hwdb_new()</function>,
+    <function>sd_hwdb_ref()</function>, and
+    <function>sd_hwdb_unref()</function> were added in version 246.</para>
+    <para><function>sd_hwdb_new_from_path()</function> was added in version 252.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-udevd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-hwdb</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-hwdb</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_id128_get_machine.xml b/man/sd_id128_get_machine.xml
new file mode 100644
index 0000000..43ee26d
--- /dev/null
+++ b/man/sd_id128_get_machine.xml
@@ -0,0 +1,281 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_id128_get_machine" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_id128_get_machine</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_id128_get_machine</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_id128_get_machine</refname>
+    <refname>sd_id128_get_app_specific</refname>
+    <refname>sd_id128_get_machine_app_specific</refname>
+    <refname>sd_id128_get_boot</refname>
+    <refname>sd_id128_get_boot_app_specific</refname>
+    <refname>sd_id128_get_invocation</refname>
+    <refpurpose>Retrieve 128-bit IDs</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-id128.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_id128_get_machine</function></funcdef>
+        <paramdef>sd_id128_t *<parameter>ret</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_id128_get_app_specific</function></funcdef>
+        <paramdef>sd_id128_t <parameter>base</parameter></paramdef>
+        <paramdef>sd_id128_t <parameter>app_id</parameter></paramdef>
+        <paramdef>sd_id128_t *<parameter>ret</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_id128_get_machine_app_specific</function></funcdef>
+        <paramdef>sd_id128_t <parameter>app_id</parameter></paramdef>
+        <paramdef>sd_id128_t *<parameter>ret</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_id128_get_boot</function></funcdef>
+        <paramdef>sd_id128_t *<parameter>ret</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_id128_get_boot_app_specific</function></funcdef>
+        <paramdef>sd_id128_t <parameter>app_id</parameter></paramdef>
+        <paramdef>sd_id128_t *<parameter>ret</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_id128_get_invocation</function></funcdef>
+        <paramdef>sd_id128_t *<parameter>ret</parameter></paramdef>
+      </funcprototype>
+
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_id128_get_machine()</function> returns the machine ID of the executing host. This reads and
+    parses the <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    file. This function caches the machine ID internally to make retrieving the machine ID a cheap operation. This ID
+    may be used wherever a unique identifier for the local system is needed. However, it is recommended to use this ID
+    as-is only in trusted environments. In untrusted environments it is recommended to derive an application specific
+    ID from this machine ID, in an irreversible (cryptographically secure) way. To make this easy
+    <function>sd_id128_get_machine_app_specific()</function> is provided, see below.</para>
+
+    <para><function>sd_id128_get_app_specific()</function> returns a machine ID that is a combination of the
+    <parameter>base</parameter> and <parameter>app_id</parameter> parameters. Internally, this function
+    calculates HMAC-SHA256 of the <parameter>app_id</parameter> parameter keyed by the
+    <parameter>base</parameter> parameter, and truncates this result to fit in
+    <structname>sd_id128_t</structname> and turns it into a valid Variant 1 Version 4 UUID, in accordance
+    with <ulink url="https://tools.ietf.org/html/rfc4122">RFC 4122</ulink>. Neither of the two input
+    parameters can be calculated from the output parameter <parameter>ret</parameter>.</para>
+
+    <para><function>sd_id128_get_machine_app_specific()</function> is similar to
+    <function>sd_id128_get_machine()</function>, but retrieves a machine ID that is specific to the
+    application that is identified by the indicated application ID. It is recommended to use this function
+    instead of <function>sd_id128_get_machine()</function> when passing an ID to untrusted environments, in
+    order to make sure that the original machine ID may not be determined externally. This way, the ID used
+    by the application remains stable on a given machine, but cannot be easily correlated with IDs used in
+    other applications on the same machine. The application-specific ID should be generated via a tool like
+    <command>systemd-id128 new</command>, and may be compiled into the application. This function will return
+    the same application-specific ID for each combination of machine ID and application ID. Internally, this
+    function calls <function>sd_id128_get_app_specific()</function> with the result from
+    <function>sd_id128_get_machine()</function> and the <parameter>app_id</parameter> parameter.</para>
+
+    <para><function>sd_id128_get_boot()</function> returns the boot ID of the executing kernel. This reads and parses
+    the <filename>/proc/sys/kernel/random/boot_id</filename> file exposed by the kernel. It is randomly generated early
+    at boot and is unique for every running kernel instance. See <citerefentry
+    project='man-pages'><refentrytitle>random</refentrytitle><manvolnum>4</manvolnum></citerefentry> for more
+    information. This function also internally caches the returned ID to make this call a cheap operation. It is
+    recommended to use this ID as-is only in trusted environments. In untrusted environments it is recommended to
+    derive an application specific ID using <function>sd_id128_get_boot_app_specific()</function>, see below.</para>
+
+    <para><function>sd_id128_get_boot_app_specific()</function> is analogous to
+    <function>sd_id128_get_machine_app_specific()</function>, but returns an ID that changes between
+    boots. Some machines may be used for a long time without rebooting, hence the boot ID may remain constant
+    for a long time, and has properties similar to the machine ID during that time.</para>
+
+    <para><function>sd_id128_get_invocation()</function> returns the invocation ID of the currently executed
+    service. In its current implementation, this tries to read and parse the following:
+    <itemizedlist>
+      <listitem>
+        <para>The <varname>$INVOCATION_ID</varname> environment variable that the service manager sets when
+        activating a service.</para>
+      </listitem>
+      <listitem>
+        <para>An entry in the kernel keyring that the system service manager sets when activating a service.
+        </para>
+      </listitem>
+    </itemizedlist>
+    See <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for details. The ID is cached internally. In future a different mechanism to determine the invocation ID
+    may be added.</para>
+
+    <para>Note that <function>sd_id128_get_machine_app_specific()</function>,
+    <function>sd_id128_get_boot()</function>, <function>sd_id128_get_boot_app_specific()</function>, and
+    <function>sd_id128_get_invocation()</function> always return UUID Variant 1 Version 4 compatible IDs.
+    <function>sd_id128_get_machine()</function> will also return a UUID Variant 1 Version 4 compatible ID on
+    new installations but might not on older. It is possible to convert the machine ID non-reversibly into a
+    UUID Variant 1 Version 4 compatible one. For more information, see
+    <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>. It is
+    hence guaranteed that these functions will never return the ID consisting of all zero or all one bits
+    (<constant>SD_ID128_NULL</constant>, <constant>SD_ID128_ALLF</constant>) — with the possible exception of
+    <function>sd_id128_get_machine()</function>, as mentioned.</para>
+
+    <para>For more information about the <literal>sd_id128_t</literal>
+    type see
+    <citerefentry><refentrytitle>sd-id128</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>Those calls return 0 on success (in which case <parameter>ret</parameter> is filled in),
+    or a negative errno-style error code.</para>
+
+    <refsect2>
+      <title>Errors</title>
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-ENOENT</constant></term>
+
+          <listitem><para>Returned by <function>sd_id128_get_machine()</function> and
+          <function>sd_id128_get_machine_app_specific()</function> when <filename>/etc/machine-id</filename>
+          is missing.</para>
+
+          <xi:include href="version-info.xml" xpointer="v242"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOMEDIUM</constant></term>
+
+          <listitem><para>Returned by <function>sd_id128_get_machine()</function> and
+          <function>sd_id128_get_machine_app_specific()</function> when <filename>/etc/machine-id</filename>
+          is empty or all zeros. Also returned by <function>sd_id128_get_invocation()</function> when the
+          invocation ID is all zeros.</para>
+
+          <xi:include href="version-info.xml" xpointer="v242"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOPKG</constant></term>
+
+          <listitem><para>Returned by <function>sd_id128_get_machine()</function> and
+          <function>sd_id128_get_machine_app_specific()</function> when the content of
+          <filename>/etc/machine-id</filename> is <literal>uninitialized</literal>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v253"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOSYS</constant></term>
+
+          <listitem><para>Returned by <function>sd_id128_get_boot()</function> and
+          <function>sd_id128_get_boot_app_specific()</function> when <filename>/proc/</filename> is not
+          mounted.</para>
+
+          <xi:include href="version-info.xml" xpointer="v253"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENXIO</constant></term>
+
+          <listitem><para>Returned by <function>sd_id128_get_invocation()</function> if no invocation ID is
+          set. Also returned by <function>sd_id128_get_app_specific()</function>,
+          <function>sd_id128_get_machine_app_specific()</function>, and
+          <function>sd_id128_get_boot_app_specific()</function> when the <parameter>app_id</parameter>
+          parameter is all zeros.</para>
+
+          <xi:include href="version-info.xml" xpointer="v242"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EUCLEAN</constant></term>
+
+          <listitem><para>Returned by any of the functions described here when the configured value has
+          invalid format.</para>
+
+          <xi:include href="version-info.xml" xpointer="v253"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EPERM</constant></term>
+
+          <listitem><para>Requested information could not be retrieved because of insufficient permissions.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v242"/></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>Examples</title>
+
+    <example>
+      <title>Application-specific machine ID</title>
+
+      <para>First, generate the application ID:</para>
+      <programlisting>$ systemd-id128 -p new
+As string:
+c273277323db454ea63bb96e79b53e97
+
+As UUID:
+c2732773-23db-454e-a63b-b96e79b53e97
+
+As man:sd-id128(3) macro:
+#define MESSAGE_XYZ SD_ID128_MAKE(c2,73,27,73,23,db,45,4e,a6,3b,b9,6e,79,b5,3e,97)
+...
+</programlisting>
+
+      <para>Then use the new identifier in an example application:</para>
+
+      <programlisting><xi:include href="id128-app-specific.c" parse="text" /></programlisting>
+    </example>
+  </refsect1>
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_id128_get_machine()</function> and
+    <function>sd_id128_get_boot()</function> were added in version 187.</para>
+    <para><function>sd_id128_get_invocation()</function> was added in version 232.</para>
+    <para><function>sd_id128_get_machine_app_specific()</function> was added in version 233.</para>
+    <para><function>sd_id128_get_boot_app_specific()</function> was added in version 240.</para>
+    <para><function>sd_id128_get_app_specific()</function> was added in version 255.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-id128</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-id128</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_id128_randomize</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>random</refentrytitle><manvolnum>4</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_id128_randomize.xml b/man/sd_id128_randomize.xml
new file mode 100644
index 0000000..54184f0
--- /dev/null
+++ b/man/sd_id128_randomize.xml
@@ -0,0 +1,85 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_id128_randomize" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_id128_randomize</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_id128_randomize</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_id128_randomize</refname>
+    <refpurpose>Generate 128-bit IDs</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-id128.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_id128_randomize</function></funcdef>
+        <paramdef>sd_id128_t *<parameter>ret</parameter></paramdef>
+      </funcprototype>
+
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_id128_randomize()</function> generates a new randomized 128-bit ID and returns it in
+    <parameter>ret</parameter>. Every invocation returns a new randomly generated ID. This uses the
+    <citerefentry
+    project='man-pages'><refentrytitle>getrandom</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+    kernel random number generator.</para>
+
+    <para>Note that <function>sd_id128_randomize()</function> always returns a UUID Variant 1 Version 4
+    compatible ID. It is hence guaranteed that this function will never return the ID consisting of all zero
+    or all one bits (<constant>SD_ID128_NULL</constant>, <constant>SD_ID128_ALLF</constant>).</para>
+
+    <para>For more information about the <literal>sd_id128_t</literal>
+    type, see
+    <citerefentry><refentrytitle>sd-id128</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para>
+
+    <para><citerefentry><refentrytitle>systemd-id128</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s
+    <command>new</command> command may be used as a command line front-end for
+    <function>sd_id128_randomize()</function>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>The call returns 0 on success (in which case
+    <parameter>ret</parameter> is filled in), or a negative
+    errno-style error code.</para>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_id128_randomize()</function> was added in version 187.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-id128</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>getrandom</refentrytitle><manvolnum>2</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>random</refentrytitle><manvolnum>4</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_id128_get_machine</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_id128_to_string.xml b/man/sd_id128_to_string.xml
new file mode 100644
index 0000000..da44a0d
--- /dev/null
+++ b/man/sd_id128_to_string.xml
@@ -0,0 +1,129 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_id128_to_string" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_id128_to_string</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_id128_to_string</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_id128_to_string</refname>
+    <refname>SD_ID128_TO_STRING</refname>
+    <refname>SD_ID128_STRING_MAX</refname>
+    <refname>sd_id128_to_uuid_string</refname>
+    <refname>SD_ID128_TO_UUID_STRING</refname>
+    <refname>SD_ID128_UUID_STRING_MAX</refname>
+    <refname>sd_id128_from_string</refname>
+    <refpurpose>Format or parse 128-bit IDs as strings</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-id128.h&gt;</funcsynopsisinfo>
+
+      <funcsynopsisinfo>#define SD_ID128_STRING_MAX 33U</funcsynopsisinfo>
+
+      <funcsynopsisinfo>#define SD_ID128_UUID_STRING_MAX 37U</funcsynopsisinfo>
+
+      <funcsynopsisinfo>#define SD_ID128_TO_STRING(id) …</funcsynopsisinfo>
+
+      <funcsynopsisinfo>#define SD_ID128_TO_UUID_STRING(id) …</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>char *<function>sd_id128_to_string</function></funcdef>
+        <paramdef>sd_id128_t <parameter>id</parameter>, char <parameter>s</parameter>[static SD_ID128_STRING_MAX]</paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>char *<function>sd_id128_uuid_string</function></funcdef>
+        <paramdef>sd_id128_t <parameter>id</parameter>, char <parameter>s</parameter>[static SD_ID128_UUID_STRING_MAX]</paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_id128_from_string</function></funcdef>
+        <paramdef>const char *<parameter>s</parameter>, sd_id128_t *<parameter>ret</parameter></paramdef>
+      </funcprototype>
+
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_id128_to_string()</function> formats a 128-bit ID as a character string. It expects
+    the ID and a string array capable of storing 33 characters
+    (<constant>SD_ID128_STRING_MAX</constant>). The ID will be formatted as 32 lowercase hexadecimal digits
+    and be terminated by a <constant>NUL</constant> byte.</para>
+
+    <para><function>SD_ID128_TO_STRING()</function> is a macro that wraps
+    <function>sd_id128_to_string()</function> and passes an appropriately sized buffer as second argument,
+    allocated as C99 compound literal. Each use will thus implicitly acquire a suitable buffer on the stack
+    which remains valid until the end of the current code block. This is usually the simplest way to acquire
+    a string representation of a 128-bit ID in a buffer that is valid in the current code block.</para>
+
+    <para><function>sd_id128_to_uuid_string()</function> and <function>SD_ID128_TO_UUID_STRING()</function>
+    are similar to these two functions/macros, but format the 128-bit values as RFC4122 UUIDs, i.e. a series
+    of 36 lowercase hexadeciaml digits and dashes, terminated by a <constant>NUL</constant> byte.</para>
+
+    <para><function>sd_id128_from_string()</function> implements the reverse operation: it takes a 33
+    character string with 32 hexadecimal digits (either lowercase or uppercase, terminated by
+    <constant>NUL</constant>) and parses them back into a 128-bit ID returned in
+    <parameter>ret</parameter>. Alternatively, this call can also parse a 37-character string with a 128-bit
+    ID formatted as RFC UUID. If <parameter>ret</parameter> is passed as <constant>NULL</constant> the
+    function will validate the passed ID string, but not actually return it in parsed form.</para>
+
+    <para>Note that when formatting and parsing 36 character UUIDs this is done strictly in Big Endian byte order,
+    i.e. according to <ulink url="https://tools.ietf.org/html/rfc4122">RFC4122</ulink> Variant 1 rules, even
+    if the UUID encodes a different variant. This matches behaviour in various other Linux userspace
+    tools. It's probably wise to avoid UUIDs of other variant types.</para>
+
+    <para>For more information about the <literal>sd_id128_t</literal> type see
+    <citerefentry><refentrytitle>sd-id128</refentrytitle><manvolnum>3</manvolnum></citerefentry>.  Note that
+    these calls operate the same way on all architectures, i.e. the results do not depend on
+    endianness.</para>
+
+    <para>When formatting a 128-bit ID into a string, it is often easier to use a format string for
+    <citerefentry
+    project='man-pages'><refentrytitle>printf</refentrytitle><manvolnum>3</manvolnum></citerefentry>.  This
+    is easily done using the <constant>SD_ID128_FORMAT_STR</constant> and
+    <function>SD_ID128_FORMAT_VAL()</function> macros. For more information see
+    <citerefentry><refentrytitle>sd-id128</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para><function>sd_id128_to_string()</function> always succeeds and returns a pointer to the string array
+    passed in.  <function>sd_id128_from_string()</function> returns 0 on success, in which case
+    <parameter>ret</parameter> is filled in, or a negative errno-style error code.</para>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_id128_to_string()</function> and
+    <function>sd_id128_from_string()</function> were added in version 187.</para>
+    <para><function>sd_id128_uuid_string()</function> was added in version 251.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-id128</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>printf</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_is_fifo.xml b/man/sd_is_fifo.xml
new file mode 100644
index 0000000..a00a2cc
--- /dev/null
+++ b/man/sd_is_fifo.xml
@@ -0,0 +1,208 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_is_fifo"
+  xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_is_fifo</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_is_fifo</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_is_fifo</refname>
+    <refname>sd_is_socket</refname>
+    <refname>sd_is_socket_inet</refname>
+    <refname>sd_is_socket_unix</refname>
+    <refname>sd_is_socket_sockaddr</refname>
+    <refname>sd_is_mq</refname>
+    <refname>sd_is_special</refname>
+    <refpurpose>Check the type of a file descriptor</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-daemon.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_is_fifo</function></funcdef>
+        <paramdef>int <parameter>fd</parameter></paramdef>
+        <paramdef>const char *<parameter>path</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_is_socket</function></funcdef>
+        <paramdef>int <parameter>fd</parameter></paramdef>
+        <paramdef>int <parameter>family</parameter></paramdef>
+        <paramdef>int <parameter>type</parameter></paramdef>
+        <paramdef>int <parameter>listening</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_is_socket_inet</function></funcdef>
+        <paramdef>int <parameter>fd</parameter></paramdef>
+        <paramdef>int <parameter>family</parameter></paramdef>
+        <paramdef>int <parameter>type</parameter></paramdef>
+        <paramdef>int <parameter>listening</parameter></paramdef>
+        <paramdef>uint16_t <parameter>port</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_is_socket_sockaddr</function></funcdef>
+        <paramdef>int <parameter>fd</parameter></paramdef>
+        <paramdef>int <parameter>type</parameter></paramdef>
+        <paramdef>const struct sockaddr *<parameter>addr</parameter></paramdef>
+        <paramdef>unsigned <parameter>addr_len</parameter></paramdef>
+        <paramdef>int <parameter>listening</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_is_socket_unix</function></funcdef>
+        <paramdef>int <parameter>fd</parameter></paramdef>
+        <paramdef>int <parameter>type</parameter></paramdef>
+        <paramdef>int <parameter>listening</parameter></paramdef>
+        <paramdef>const char *<parameter>path</parameter></paramdef>
+        <paramdef>size_t <parameter>length</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_is_mq</function></funcdef>
+        <paramdef>int <parameter>fd</parameter></paramdef>
+        <paramdef>const char *<parameter>path</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_is_special</function></funcdef>
+        <paramdef>int <parameter>fd</parameter></paramdef>
+        <paramdef>const char *<parameter>path</parameter></paramdef>
+      </funcprototype>
+
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_is_fifo()</function> may be called to check
+    whether the specified file descriptor refers to a FIFO or pipe. If
+    the <parameter>path</parameter> parameter is not
+    <constant>NULL</constant>, it is checked whether the FIFO is bound
+    to the specified file system path.</para>
+
+    <para><function>sd_is_socket()</function> may be called to check
+    whether the specified file descriptor refers to a socket. If the
+    <parameter>family</parameter> parameter is not
+    <constant>AF_UNSPEC</constant>, it is checked whether the socket
+    is of the specified family (<constant>AF_UNIX</constant>,
+    <constant>AF_INET</constant>, …). If the <parameter>type</parameter>
+    parameter is not 0, it is checked whether the socket is of the
+    specified type (<constant>SOCK_STREAM</constant>,
+    <constant>SOCK_DGRAM</constant>, …). If the
+    <parameter>listening</parameter> parameter is positive, it is
+    checked whether the socket is in accepting mode, i.e.
+    <function>listen()</function> has been called for it. If
+    <parameter>listening</parameter> is 0, it is checked whether the
+    socket is not in this mode. If the parameter is negative, no such
+    check is made. The <parameter>listening</parameter> parameter
+    should only be used for stream sockets and should be set to a
+    negative value otherwise.</para>
+
+    <para><function>sd_is_socket_inet()</function> is similar to
+    <function>sd_is_socket()</function>, but optionally checks the
+    IPv4 or IPv6 port number the socket is bound to, unless
+    <parameter>port</parameter> is zero. For this call
+    <parameter>family</parameter> must be passed as either
+    <constant>AF_UNSPEC</constant>, <constant>AF_INET</constant>, or
+    <constant>AF_INET6</constant>.</para>
+
+    <para><function>sd_is_socket_sockaddr()</function> is similar to
+    <function>sd_is_socket_inet()</function>, but checks if the socket is bound to the
+    address specified by <parameter>addr</parameter>. The
+    <structfield>family</structfield> specified by <parameter>addr</parameter> must be
+    either <constant>AF_INET</constant> or <constant>AF_INET6</constant> and
+    <parameter>addr_len</parameter> must be large enough for that family. If
+    <parameter>addr</parameter> specifies a non-zero port, it is also checked if the
+    socket is bound to this port. In addition, for IPv6, if <parameter>addr</parameter>
+    specifies non-zero <structfield>sin6_flowinfo</structfield> or
+    <structfield>sin6_scope_id</structfield>, it is checked if the socket has the same
+    values.</para>
+
+    <para><function>sd_is_socket_unix()</function> is similar to
+    <function>sd_is_socket()</function> but optionally checks the
+    <constant>AF_UNIX</constant> path the socket is bound to, unless
+    the <parameter>path</parameter> parameter is
+    <constant>NULL</constant>. For normal file system
+    <constant>AF_UNIX</constant> sockets, set the
+    <parameter>length</parameter> parameter to 0. For Linux abstract
+    namespace sockets, set the <parameter>length</parameter> to the
+    size of the address, including the initial 0 byte, and set the
+    <parameter>path</parameter> to the initial 0 byte of the socket
+    address.</para>
+
+    <para><function>sd_is_mq()</function> may be called to check
+    whether the specified file descriptor refers to a POSIX message
+    queue. If the <parameter>path</parameter> parameter is not
+    <constant>NULL</constant>, it is checked whether the message queue
+    is bound to the specified name.</para>
+
+    <para><function>sd_is_special()</function> may be called to check
+    whether the specified file descriptor refers to a special file. If
+    the <parameter>path</parameter> parameter is not
+    <constant>NULL</constant>, it is checked whether the file
+    descriptor is bound to the specified filename. Special files in
+    this context are character device nodes and files in
+    <filename>/proc/</filename> or <filename>/sys/</filename>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On failure, these calls return a negative errno-style error
+    code. If the file descriptor is of the specified type and bound to
+    the specified address, a positive return value is returned,
+    otherwise zero.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Notes</title>
+
+    <xi:include href="libsystemd-pkgconfig.xml" xpointer="pkgconfig-text"/>
+
+    <para>Internally, these functions use a combination of
+    <citerefentry project='man-pages'><refentrytitle>fstat</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+    and
+    <citerefentry project='man-pages'><refentrytitle>getsockname</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+    to check the file descriptor type and where it is bound to.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_is_special()</function> was added in version 209.</para>
+    <para><function>sd_is_socket_sockaddr()</function> was added in version 233.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-daemon</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_listen_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>ip</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>ipv6</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>unix</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>fifo</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>mq_overview</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>socket</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_journal_add_match.xml b/man/sd_journal_add_match.xml
new file mode 100644
index 0000000..5329498
--- /dev/null
+++ b/man/sd_journal_add_match.xml
@@ -0,0 +1,185 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_journal_add_match" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_journal_add_match</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_journal_add_match</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_journal_add_match</refname>
+    <refname>sd_journal_add_disjunction</refname>
+    <refname>sd_journal_add_conjunction</refname>
+    <refname>sd_journal_flush_matches</refname>
+    <refpurpose>Add or remove entry matches</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-journal.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_journal_add_match</function></funcdef>
+        <paramdef>sd_journal *<parameter>j</parameter></paramdef>
+        <paramdef>const void *<parameter>data</parameter></paramdef>
+        <paramdef>size_t <parameter>size</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_journal_add_disjunction</function></funcdef>
+        <paramdef>sd_journal *<parameter>j</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_journal_add_conjunction</function></funcdef>
+        <paramdef>sd_journal *<parameter>j</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>void <function>sd_journal_flush_matches</function></funcdef>
+        <paramdef>sd_journal *<parameter>j</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_journal_add_match()</function> adds a match by
+    which to filter the entries of the journal file. Matches applied
+    with this call will filter what can be iterated through and read
+    from the journal file via calls like
+    <citerefentry><refentrytitle>sd_journal_next</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    and
+    <citerefentry><refentrytitle>sd_journal_get_data</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+    Parameter <parameter>data</parameter> must be of the form
+    <literal><replaceable>FIELD</replaceable>=<replaceable>value</replaceable></literal>,
+    where the <replaceable>FIELD</replaceable> part is a short uppercase string consisting only
+    of 0–9, A–Z and the underscore; it may not begin with two underscores or be the empty
+    string. The <replaceable>value</replaceable> part may be anything, including binary. Parameter
+    <parameter>size</parameter> specifies the number of bytes in <parameter>data</parameter>
+    (i.e. the length of <replaceable>FIELD</replaceable>, plus one, plus the length of
+    <replaceable>value</replaceable>). Parameter <parameter>size</parameter> may also be
+    specified as <constant>0</constant>, in which case <parameter>data</parameter>
+    must be a <constant>NUL</constant>-terminated string, and the bytes before the terminating
+    zero are used as the match.</para>
+
+    <para>If a match is applied, only entries with this field set
+    will be iterated. Multiple matches may be active at the same time:
+    If they apply to different fields, only entries with both fields
+    set like this will be iterated. If they apply to the same fields,
+    only entries where the field takes one of the specified values
+    will be iterated. Well known fields are documented in
+    <citerefentry><refentrytitle>systemd.journal-fields</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
+    Whenever a new match is added the current entry position is reset,
+    and
+    <citerefentry><refentrytitle>sd_journal_next</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    (or a similar call) needs to be called before entries can be read
+    again.</para>
+
+    <para><function>sd_journal_add_disjunction()</function> may be
+    used to insert a disjunction (i.e. logical OR) in the match list.
+    If this call is invoked, all previously added matches since the
+    last invocation of
+    <function>sd_journal_add_disjunction()</function> or
+    <function>sd_journal_add_conjunction()</function> are combined in
+    an OR with all matches added afterwards, until
+    <function>sd_journal_add_disjunction()</function> or
+    <function>sd_journal_add_conjunction()</function> is invoked again
+    to begin the next OR or AND term. </para>
+
+    <para><function>sd_journal_add_conjunction()</function> may be
+    used to insert a conjunction (i.e. logical AND) in the match list.
+    If this call is invoked, all previously added matches since the
+    last invocation of
+    <function>sd_journal_add_conjunction()</function> are combined in
+    an AND with all matches added afterwards, until
+    <function>sd_journal_add_conjunction()</function> is invoked again
+    to begin the next AND term. The combination of
+    <function>sd_journal_add_match()</function>,
+    <function>sd_journal_add_disjunction()</function> and
+    <function>sd_journal_add_conjunction()</function> may be used to
+    build complex search terms, even though full logical expressions
+    are not available. Note that
+    <function>sd_journal_add_conjunction()</function> operates one
+    level 'higher' than
+    <function>sd_journal_add_disjunction()</function>. It is hence
+    possible to build an expression of AND terms, consisting of OR
+    terms, consisting of AND terms, consisting of OR terms of matches
+    (the latter OR expression is implicitly created for matches with
+    the same field name, see above).</para>
+
+    <para><function>sd_journal_flush_matches()</function> may be used
+    to flush all matches, disjunction and conjunction terms again.
+    After this call all filtering is removed and all entries in the
+    journal will be iterated again.</para>
+
+    <para>Note that filtering via matches only applies to the way the
+    journal is read, it has no effect on storage on disk.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para><function>sd_journal_add_match()</function>,
+    <function>sd_journal_add_disjunction()</function> and
+    <function>sd_journal_add_conjunction()</function>
+    return 0 on success or a negative errno-style error
+    code. <function>sd_journal_flush_matches()</function>
+    returns nothing.</para>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>Examples</title>
+
+    <para>The following example adds matches to a journal context
+    object to iterate only through messages generated by the Avahi
+    service at the four error log levels, plus all messages of the
+    message ID 03bb1dab98ab4ecfbf6fff2738bdd964 coming from any
+    service (this example lacks the necessary error checking):</para>
+
+    <programlisting>…
+int add_matches(sd_journal *j) {
+  sd_journal_add_match(j, "_SYSTEMD_UNIT=avahi-daemon.service", 0);
+  sd_journal_add_match(j, "PRIORITY=0", 0);
+  sd_journal_add_match(j, "PRIORITY=1", 0);
+  sd_journal_add_match(j, "PRIORITY=2", 0);
+  sd_journal_add_match(j, "PRIORITY=3", 0);
+  sd_journal_add_disjunction(j);
+  sd_journal_add_match(j, "MESSAGE_ID=03bb1dab98ab4ecfbf6fff2738bdd964", 0);
+}</programlisting>
+  </refsect1>
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_journal_add_match()</function>,
+    <function>sd_journal_add_disjunction()</function>, and
+    <function>sd_journal_flush_matches()</function> were added in version 187.</para>
+    <para><function>sd_journal_add_conjunction()</function> was added in version 202.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-journal</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_journal_open</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_journal_next</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_journal_get_data</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.journal-fields</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_journal_enumerate_fields.xml b/man/sd_journal_enumerate_fields.xml
new file mode 100644
index 0000000..b2185b3
--- /dev/null
+++ b/man/sd_journal_enumerate_fields.xml
@@ -0,0 +1,121 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_journal_enumerate_fields" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_journal_enumerate_fields</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_journal_enumerate_fields</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_journal_enumerate_fields</refname>
+    <refname>sd_journal_restart_fields</refname>
+    <refname>SD_JOURNAL_FOREACH_FIELD</refname>
+    <refpurpose>Read used field names from the journal</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-journal.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_journal_enumerate_fields</function></funcdef>
+        <paramdef>sd_journal *<parameter>j</parameter></paramdef>
+        <paramdef>const char **<parameter>field</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>void <function>sd_journal_restart_fields</function></funcdef>
+        <paramdef>sd_journal *<parameter>j</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef><function>SD_JOURNAL_FOREACH_FIELD</function></funcdef>
+        <paramdef>sd_journal *<parameter>j</parameter></paramdef>
+        <paramdef>const char *<parameter>field</parameter></paramdef>
+      </funcprototype>
+
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_journal_enumerate_fields()</function> may be used to iterate through all field names used in the
+    opened journal files. On each invocation the next field name is returned. The order of the returned field names is
+    not defined. It takes two arguments: the journal context object, plus a pointer to a constant string pointer where
+    the field name is stored in. The returned data is in a read-only memory map and is only valid until the next
+    invocation of <function>sd_journal_enumerate_fields()</function>. Note that this call is subject to the data field
+    size threshold as controlled by <function>sd_journal_set_data_threshold()</function>.</para>
+
+    <para><function>sd_journal_restart_fields()</function> resets the field name enumeration index to the beginning of
+    the list. The next invocation of <function>sd_journal_enumerate_fields()</function> will return the first field
+    name again.</para>
+
+    <para>The <function>SD_JOURNAL_FOREACH_FIELD()</function> macro may be used as a handy wrapper around
+    <function>sd_journal_restart_fields()</function> and <function>sd_journal_enumerate_fields()</function>.</para>
+
+    <para>These functions currently are not influenced by matches set with <function>sd_journal_add_match()</function>
+    but this might change in a later version of this software.</para>
+
+    <para>To retrieve the possible values a specific field can take use
+    <citerefentry><refentrytitle>sd_journal_query_unique</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para><function>sd_journal_enumerate_fields()</function> returns a
+    positive integer if the next field name has been read, 0 when no
+    more field names are known, or a negative errno-style error code.
+    <function>sd_journal_restart_fields()</function> returns
+    nothing.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Notes</title>
+
+    <xi:include href="threads-aware.xml" xpointer="strict" />
+
+    <xi:include href="libsystemd-pkgconfig.xml" xpointer="pkgconfig-text"/>
+  </refsect1>
+
+  <refsect1>
+    <title>Examples</title>
+
+    <para>Use the <function>SD_JOURNAL_FOREACH_FIELD()</function> macro to iterate through all field names in use in the
+    current journal.</para>
+
+    <programlisting><xi:include href="journal-enumerate-fields.c" parse="text" /></programlisting>
+  </refsect1>
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_journal_enumerate_fields()</function>,
+    <function>sd_journal_restart_fields()</function>, and
+    <function>SD_JOURNAL_FOREACH_FIELD()</function> were added in version 229.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.journal-fields</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-journal</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_journal_open</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_journal_query_unique</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_journal_get_data</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_journal_add_match</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_journal_get_catalog.xml b/man/sd_journal_get_catalog.xml
new file mode 100644
index 0000000..6c82f05
--- /dev/null
+++ b/man/sd_journal_get_catalog.xml
@@ -0,0 +1,119 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_journal_get_catalog" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_journal_get_catalog</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_journal_get_catalog</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_journal_get_catalog</refname>
+    <refname>sd_journal_get_catalog_for_message_id</refname>
+    <refpurpose>Retrieve message catalog entry</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-journal.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_journal_get_catalog</function></funcdef>
+        <paramdef>sd_journal *<parameter>j</parameter></paramdef>
+        <paramdef>char **<parameter>ret</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_journal_get_catalog_for_message_id</function></funcdef>
+        <paramdef>sd_id128_t <parameter>id</parameter></paramdef>
+        <paramdef>char **<parameter>ret</parameter></paramdef>
+      </funcprototype>
+
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_journal_get_catalog()</function> retrieves a
+    message catalog entry for the current journal entry. This will
+    look up an entry in the message catalog by using the
+    <literal>MESSAGE_ID=</literal> field of the current journal entry.
+    Before returning the entry all journal field names in the catalog
+    entry text enclosed in "@" will be replaced by the respective
+    field values of the current entry. If a field name referenced in
+    the message catalog entry does not exist, in the current journal
+    entry, the "@" will be removed, but the field name otherwise left
+    untouched.</para>
+
+    <para><function>sd_journal_get_catalog_for_message_id()</function>
+    works similar to <function>sd_journal_get_catalog()</function> but
+    the entry is looked up by the specified message ID (no open
+    journal context is necessary for this), and no field substitution
+    is performed.</para>
+
+    <para>For more information about the journal message catalog
+    please refer to the <ulink
+    url="https://www.freedesktop.org/wiki/Software/systemd/catalog">Journal
+    Message Catalogs</ulink> documentation page.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para><function>sd_journal_get_catalog()</function> and
+    <function>sd_journal_get_catalog_for_message_id()</function>
+    return 0 on success or a negative errno-style error code. If no
+    matching message catalog entry is found, -ENOENT is
+    returned.</para>
+
+    <para>On successful return, <parameter>ret</parameter> points to a
+    new string, which must be freed with
+    <citerefentry project='man-pages'><refentrytitle>free</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+    </para>
+  </refsect1>
+
+  <refsect1>
+    <title>Notes</title>
+
+    <para>Function <function>sd_journal_get_catalog()</function> is thread-agnostic and only
+    a single specific thread may operate on a given object during its entire lifetime. It's safe to allocate multiple
+    independent objects and use each from a specific thread in parallel. However, it's not safe to allocate such an
+    object in one thread, and operate or free it from any other, even if locking is used to ensure these threads don't
+    operate on it at the very same time.</para>
+
+    <para>Function <function>sd_journal_get_catalog_for_message_id()</function> is are thread-safe and may be called in
+    parallel from multiple threads.</para>
+
+    <xi:include href="libsystemd-pkgconfig.xml" xpointer="pkgconfig-text"/>
+  </refsect1>
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_journal_get_catalog()</function> and
+    <function>sd_journal_get_catalog_for_message_id()</function> were added in version 196.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.journal-fields</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-journal</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_journal_open</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_journal_next</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_journal_get_data</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>malloc</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_journal_get_cursor.xml b/man/sd_journal_get_cursor.xml
new file mode 100644
index 0000000..0baae03
--- /dev/null
+++ b/man/sd_journal_get_cursor.xml
@@ -0,0 +1,120 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_journal_get_cursor" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_journal_get_cursor</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_journal_get_cursor</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_journal_get_cursor</refname>
+    <refname>sd_journal_test_cursor</refname>
+    <refpurpose>Get cursor string for or test cursor string against the current journal entry</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-journal.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_journal_get_cursor</function></funcdef>
+        <paramdef>sd_journal *<parameter>j</parameter></paramdef>
+        <paramdef>char **<parameter>cursor</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_journal_test_cursor</function></funcdef>
+        <paramdef>sd_journal *<parameter>j</parameter></paramdef>
+        <paramdef>const char *<parameter>cursor</parameter></paramdef>
+      </funcprototype>
+
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_journal_get_cursor()</function> returns a
+    cursor string for the current journal entry. A cursor is a
+    serialization of the current journal position formatted as text.
+    The string only contains printable characters and can be passed
+    around in text form. The cursor identifies a journal entry
+    globally and in a stable way and may be used to later seek to it
+    via
+    <citerefentry><refentrytitle>sd_journal_seek_cursor</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+    The cursor string should be considered opaque and not be parsed by
+    clients. Seeking to a cursor position without the specific entry
+    being available locally will seek to the next closest (in terms of
+    time) available entry. The call takes two arguments: a journal
+    context object and a pointer to a string pointer where the cursor
+    string will be placed. The string is allocated via libc
+    <citerefentry project='man-pages'><refentrytitle>malloc</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    and should be freed after use with
+    <citerefentry project='man-pages'><refentrytitle>free</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para>
+
+    <para>Note that <function>sd_journal_get_cursor()</function> will
+    not work before
+    <citerefentry><refentrytitle>sd_journal_next</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    (or related call) has been called at least once, in order to
+    position the read pointer at a valid entry.</para>
+
+    <para><function>sd_journal_test_cursor()</function>
+    may be used to check whether the current position in
+    the journal matches the specified cursor. This is
+    useful since cursor strings do not uniquely identify
+    an entry: the same entry might be referred to by
+    multiple different cursor strings, and hence string
+    comparing cursors is not possible. Use this call to
+    verify after an invocation of
+    <citerefentry><refentrytitle>sd_journal_seek_cursor</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    whether the entry being sought to was actually found
+    in the journal or the next closest entry was used
+    instead.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para><function>sd_journal_get_cursor()</function> returns 0 on
+    success or a negative errno-style error code.
+    <function>sd_journal_test_cursor()</function> returns positive if
+    the current entry matches the specified cursor, 0 if it does not
+    match the specified cursor or a negative errno-style error code on
+    failure.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Notes</title>
+
+    <xi:include href="threads-aware.xml" xpointer="strict" />
+
+    <xi:include href="libsystemd-pkgconfig.xml" xpointer="pkgconfig-text"/>
+  </refsect1>
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_journal_get_cursor()</function> was added in version 187.</para>
+    <para><function>sd_journal_test_cursor()</function> was added in version 195.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-journal</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_journal_open</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_journal_seek_cursor</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_journal_get_cutoff_realtime_usec.xml b/man/sd_journal_get_cutoff_realtime_usec.xml
new file mode 100644
index 0000000..a39a656
--- /dev/null
+++ b/man/sd_journal_get_cutoff_realtime_usec.xml
@@ -0,0 +1,120 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_journal_get_cutoff_realtime_usec" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_journal_get_cutoff_realtime_usec</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_journal_get_cutoff_realtime_usec</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_journal_get_cutoff_realtime_usec</refname>
+    <refname>sd_journal_get_cutoff_monotonic_usec</refname>
+    <refpurpose>Read cut-off timestamps from the current journal entry</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-journal.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_journal_get_cutoff_realtime_usec</function></funcdef>
+        <paramdef>sd_journal *<parameter>j</parameter></paramdef>
+        <paramdef>uint64_t *<parameter>from</parameter></paramdef>
+        <paramdef>uint64_t *<parameter>to</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_journal_get_cutoff_monotonic_usec</function></funcdef>
+        <paramdef>sd_journal *<parameter>j</parameter></paramdef>
+        <paramdef>sd_id128_t <parameter>boot_id</parameter></paramdef>
+        <paramdef>uint64_t *<parameter>from</parameter></paramdef>
+        <paramdef>uint64_t *<parameter>to</parameter></paramdef>
+      </funcprototype>
+
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_journal_get_cutoff_realtime_usec()</function>
+    retrieves the realtime (wallclock) timestamps of the first and
+    last entries accessible in the journal. It takes three arguments:
+    the journal context object <parameter>j</parameter> and two
+    pointers <parameter>from</parameter> and <parameter>to</parameter>
+    pointing at 64-bit unsigned integers to store the timestamps in.
+    The timestamps are in microseconds since the epoch, i.e.
+    <constant>CLOCK_REALTIME</constant>. Either one of the two
+    timestamp arguments may be passed as <constant>NULL</constant> in
+    case the timestamp is not needed, but not both.</para>
+
+    <para><function>sd_journal_get_cutoff_monotonic_usec()</function>
+    retrieves the monotonic timestamps of the first and last entries
+    accessible in the journal. It takes three arguments: the journal
+    context object <parameter>j</parameter>, a 128-bit identifier for
+    the boot <parameter>boot_id</parameter>, and two pointers to
+    64-bit unsigned integers to store the timestamps,
+    <parameter>from</parameter> and <parameter>to</parameter>. The
+    timestamps are in microseconds since boot-up of the specific boot,
+    i.e. <constant>CLOCK_MONOTONIC</constant>. Since the monotonic
+    clock begins new with every reboot it only defines a well-defined
+    point in time when used together with an identifier identifying
+    the boot, see
+    <citerefentry><refentrytitle>sd_id128_get_boot</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    for more information. The function will return the timestamps for
+    the boot identified by the passed boot ID. Either one of the two
+    timestamp arguments may be passed as <constant>NULL</constant> in
+    case the timestamp is not needed, but not both.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para><function>sd_journal_get_cutoff_realtime_usec()</function>
+    and <function>sd_journal_get_cutoff_monotonic_usec()</function>
+    return 1 on success, 0 if not suitable entries are in the journal
+    or a negative errno-style error code.</para>
+
+    <para>Locations pointed to by parameters
+    <parameter>from</parameter> and <parameter>to</parameter> will be
+    set only if the return value is positive, and obviously, the
+    parameters are non-null.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Notes</title>
+
+    <xi:include href="threads-aware.xml" xpointer="strict" />
+
+    <xi:include href="libsystemd-pkgconfig.xml" xpointer="pkgconfig-text"/>
+  </refsect1>
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_journal_get_cutoff_realtime_usec()</function> and
+    <function>sd_journal_get_cutoff_monotonic_usec()</function> were added in version 187.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-journal</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_journal_open</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_journal_get_realtime_usec</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_id128_get_boot</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>clock_gettime</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_journal_get_data.xml b/man/sd_journal_get_data.xml
new file mode 100644
index 0000000..ae0911f
--- /dev/null
+++ b/man/sd_journal_get_data.xml
@@ -0,0 +1,307 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_journal_get_data" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_journal_get_data</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_journal_get_data</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_journal_get_data</refname>
+    <refname>sd_journal_enumerate_data</refname>
+    <refname>sd_journal_enumerate_available_data</refname>
+    <refname>sd_journal_restart_data</refname>
+    <refname>SD_JOURNAL_FOREACH_DATA</refname>
+    <refname>sd_journal_set_data_threshold</refname>
+    <refname>sd_journal_get_data_threshold</refname>
+    <refpurpose>Read data fields from the current journal entry</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-journal.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_journal_get_data</function></funcdef>
+        <paramdef>sd_journal *<parameter>j</parameter></paramdef>
+        <paramdef>const char *<parameter>field</parameter></paramdef>
+        <paramdef>const void **<parameter>data</parameter></paramdef>
+        <paramdef>size_t *<parameter>length</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_journal_enumerate_data</function></funcdef>
+        <paramdef>sd_journal *<parameter>j</parameter></paramdef>
+        <paramdef>const void **<parameter>data</parameter></paramdef>
+        <paramdef>size_t *<parameter>length</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_journal_enumerate_available_data</function></funcdef>
+        <paramdef>sd_journal *<parameter>j</parameter></paramdef>
+        <paramdef>const void **<parameter>data</parameter></paramdef>
+        <paramdef>size_t *<parameter>length</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>void <function>sd_journal_restart_data</function></funcdef>
+        <paramdef>sd_journal *<parameter>j</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef><function>SD_JOURNAL_FOREACH_DATA</function></funcdef>
+        <paramdef>sd_journal *<parameter>j</parameter></paramdef>
+        <paramdef>const void *<parameter>data</parameter></paramdef>
+        <paramdef>size_t <parameter>length</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_journal_set_data_threshold</function></funcdef>
+        <paramdef>sd_journal *<parameter>j</parameter></paramdef>
+        <paramdef>size_t <parameter>sz</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_journal_get_data_threshold</function></funcdef>
+        <paramdef>sd_journal *<parameter>j</parameter></paramdef>
+        <paramdef>size_t *<parameter>sz</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_journal_get_data()</function> gets the data object associated with a specific field
+    from the current journal entry. It takes four arguments: the journal context object, a string with the
+    field name to request, plus a pair of pointers to pointer/size variables where the data object and its
+    size shall be stored in. The field name should be an entry field name. Well-known field names are listed in
+    <citerefentry><refentrytitle>systemd.journal-fields</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+    but any field can be specified. The returned data is in a read-only memory map and is only valid until
+    the next invocation of <function>sd_journal_get_data()</function>,
+    <function>sd_journal_enumerate_data()</function>,
+    <function>sd_journal_enumerate_available_data()</function>, or when the read pointer is altered. Note
+    that the data returned will be prefixed with the field name and <literal>=</literal>. Also note that, by
+    default, data fields larger than 64K might get truncated to 64K. This threshold may be changed and turned
+    off with <function>sd_journal_set_data_threshold()</function> (see below).</para>
+
+    <para><function>sd_journal_enumerate_data()</function> may be used
+    to iterate through all fields of the current entry. On each
+    invocation the data for the next field is returned. The order of
+    these fields is not defined. The data returned is in the same
+    format as with <function>sd_journal_get_data()</function> and also
+    follows the same life-time semantics.</para>
+
+    <para><function>sd_journal_enumerate_available_data()</function> is similar to
+    <function>sd_journal_enumerate_data()</function>, but silently skips any fields which may be valid, but
+    are too large or not supported by current implementation.</para>
+
+    <para><function>sd_journal_restart_data()</function> resets the
+    data enumeration index to the beginning of the entry. The next
+    invocation of <function>sd_journal_enumerate_data()</function>
+    will return the first field of the entry again.</para>
+
+    <para>Note that the <function>SD_JOURNAL_FOREACH_DATA()</function> macro may be used as a handy wrapper
+    around <function>sd_journal_restart_data()</function> and
+    <function>sd_journal_enumerate_available_data()</function>.</para>
+
+    <para>Note that these functions will not work before
+    <citerefentry><refentrytitle>sd_journal_next</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    (or related call) has been called at least once, in order to
+    position the read pointer at a valid entry.</para>
+
+    <para><function>sd_journal_set_data_threshold()</function> may be
+    used to change the data field size threshold for data returned by
+    <function>sd_journal_get_data()</function>,
+    <function>sd_journal_enumerate_data()</function> and
+    <function>sd_journal_enumerate_unique()</function>. This threshold
+    is a hint only: it indicates that the client program is interested
+    only in the initial parts of the data fields, up to the threshold
+    in size — but the library might still return larger data objects.
+    That means applications should not rely exclusively on this
+    setting to limit the size of the data fields returned, but need to
+    apply an explicit size limit on the returned data as well. This
+    threshold defaults to 64K by default. To retrieve the complete
+    data fields this threshold should be turned off by setting it to
+    0, so that the library always returns the complete data objects.
+    It is recommended to set this threshold as low as possible since
+    this relieves the library from having to decompress large
+    compressed data objects in full.</para>
+
+    <para><function>sd_journal_get_data_threshold()</function> returns
+    the currently configured data field size threshold.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para><function>sd_journal_get_data()</function> returns 0 on success or a negative errno-style error
+    code. <function>sd_journal_enumerate_data()</function> and
+    <function>sd_journal_enumerate_available_data()</function> return a positive integer if the next field
+    has been read, 0 when no more fields remain, or a negative errno-style error code.
+    <function>sd_journal_restart_data()</function> doesn't return anything.
+    <function>sd_journal_set_data_threshold()</function> and <function>sd_journal_get_threshold()</function>
+    return 0 on success or a negative errno-style error code.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry id='EINVAL'>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>One of the required parameters is <constant>NULL</constant> or invalid.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry id='ECHILD'>
+          <term><constant>-ECHILD</constant></term>
+
+          <listitem><para>The journal object was created in a different process, library or module instance.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry id='EADDRNOTAVAIL'>
+          <term><constant>-EADDRNOTAVAIL</constant></term>
+
+          <listitem><para>The read pointer is not positioned at a valid entry;
+          <citerefentry><refentrytitle>sd_journal_next</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+          or a related call has not been called at least once.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry id='ENOENT'>
+          <term><constant>-ENOENT</constant></term>
+
+          <listitem><para>The current entry does not include the specified field.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry id='ENOMEM'>
+          <term><constant>-ENOMEM</constant></term>
+
+          <listitem><para>Memory allocation failed.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry id='ENOBUFS'>
+          <term><constant>-ENOBUFS</constant></term>
+
+          <listitem><para>A compressed entry is too large.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry id='E2BIG'>
+          <term><constant>-E2BIG</constant></term>
+
+          <listitem><para>The data field is too large for this computer architecture (e.g. above 4 GB on a
+          32-bit architecture).</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry id='EPROTONOSUPPORT'>
+          <term><constant>-EPROTONOSUPPORT</constant></term>
+
+          <listitem><para>The journal is compressed with an unsupported method or the journal uses an
+          unsupported feature.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry id='EBADMSG'>
+          <term><constant>-EBADMSG</constant></term>
+
+          <listitem><para>The journal is corrupted (possibly just the entry being iterated over).
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry id='EIO'>
+          <term><constant>-EIO</constant></term>
+
+          <listitem><para>An I/O error was reported by the kernel.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <refsect1>
+    <title>Notes</title>
+
+    <xi:include href="threads-aware.xml" xpointer="strict"/>
+
+    <xi:include href="libsystemd-pkgconfig.xml" xpointer="pkgconfig-text"/>
+  </refsect1>
+
+  <refsect1>
+    <title>Examples</title>
+
+    <para>See
+    <citerefentry><refentrytitle>sd_journal_next</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    for a complete example how to use
+    <function>sd_journal_get_data()</function>.</para>
+
+    <para>Use the
+    <function>SD_JOURNAL_FOREACH_DATA()</function> macro to
+    iterate through all fields of the current journal
+    entry:</para>
+
+    <programlisting>…
+int print_fields(sd_journal *j) {
+  const void *data;
+  size_t length;
+  SD_JOURNAL_FOREACH_DATA(j, data, length)
+    printf("%.*s\n", (int) length, data);
+}
+…</programlisting>
+  </refsect1>
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_journal_get_data()</function>,
+    <function>sd_journal_enumerate_data()</function>,
+    <function>sd_journal_restart_data()</function>, and
+    <function>SD_JOURNAL_FOREACH_DATA()</function> were added in version 187.</para>
+    <para><function>sd_journal_set_data_threshold()</function> and
+    <function>sd_journal_get_data_threshold()</function> were added in version 196.</para>
+    <para><function>sd_journal_enumerate_available_data()</function> was added in version 246.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.journal-fields</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-journal</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_journal_open</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_journal_next</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_journal_get_realtime_usec</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_journal_query_unique</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_journal_get_fd.xml b/man/sd_journal_get_fd.xml
new file mode 100644
index 0000000..6e7e496
--- /dev/null
+++ b/man/sd_journal_get_fd.xml
@@ -0,0 +1,269 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_journal_get_fd" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_journal_get_fd</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_journal_get_fd</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_journal_get_fd</refname>
+    <refname>sd_journal_get_events</refname>
+    <refname>sd_journal_get_timeout</refname>
+    <refname>sd_journal_process</refname>
+    <refname>sd_journal_wait</refname>
+    <refname>sd_journal_reliable_fd</refname>
+    <refname>SD_JOURNAL_NOP</refname>
+    <refname>SD_JOURNAL_APPEND</refname>
+    <refname>SD_JOURNAL_INVALIDATE</refname>
+    <refpurpose>Journal change notification
+    interface</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-journal.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_journal_get_fd</function></funcdef>
+        <paramdef>sd_journal *<parameter>j</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_journal_get_events</function></funcdef>
+        <paramdef>sd_journal *<parameter>j</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_journal_get_timeout</function></funcdef>
+        <paramdef>sd_journal *<parameter>j</parameter></paramdef>
+        <paramdef>uint64_t *<parameter>timeout_usec</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_journal_process</function></funcdef>
+        <paramdef>sd_journal *<parameter>j</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_journal_wait</function></funcdef>
+        <paramdef>sd_journal *<parameter>j</parameter></paramdef>
+        <paramdef>uint64_t <parameter>timeout_usec</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_journal_reliable_fd</function></funcdef>
+        <paramdef>sd_journal *<parameter>j</parameter></paramdef>
+      </funcprototype>
+
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_journal_get_fd()</function> returns a file
+    descriptor that may be asynchronously polled in an external event
+    loop and is signaled as soon as the journal changes, because new
+    entries or files were added, rotation took place, or files have
+    been deleted, and similar. The file descriptor is suitable for
+    usage in
+    <citerefentry><refentrytitle>poll</refentrytitle><manvolnum>2</manvolnum></citerefentry>.
+    Use <function>sd_journal_get_events()</function> for an events
+    mask to watch for. The call takes one argument: the journal
+    context object. Note that not all file systems are capable of
+    generating the necessary events for wakeups from this file
+    descriptor for changes to be noticed immediately. In particular
+    network files systems do not generate suitable file change events
+    in all cases. Cases like this can be detected with
+    <function>sd_journal_reliable_fd()</function>, below.
+    <function>sd_journal_get_timeout()</function> will ensure in these
+    cases that wake-ups happen frequently enough for changes to be
+    noticed, although with a certain latency.</para>
+
+    <para><function>sd_journal_get_events()</function> will return the
+    <function>poll()</function> mask to wait for. This function will
+    return a combination of <constant>POLLIN</constant> and
+    <constant>POLLOUT</constant> and similar to fill into the
+    <literal>.events</literal> field of <varname>struct
+    pollfd</varname>.</para>
+
+    <para><function>sd_journal_get_timeout()</function> will return a
+    timeout value for usage in <function>poll()</function>. This
+    returns a value in microseconds since the epoch of
+    <constant>CLOCK_MONOTONIC</constant> for timing out
+    <function>poll()</function> in <varname>timeout_usec</varname>.
+    See
+    <citerefentry><refentrytitle>clock_gettime</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+    for details about <constant>CLOCK_MONOTONIC</constant>. If there
+    is no timeout to wait for, this will fill in <constant>(uint64_t)
+    -1</constant> instead. Note that <function>poll()</function> takes
+    a relative timeout in milliseconds rather than an absolute timeout
+    in microseconds. To convert the absolute 'us' timeout into
+    relative 'ms', use code like the following:</para>
+
+    <programlisting>uint64_t t;
+int msec;
+sd_journal_get_timeout(m, &amp;t);
+if (t == (uint64_t) -1)
+  msec = -1;
+else {
+  struct timespec ts;
+  uint64_t n;
+  clock_gettime(CLOCK_MONOTONIC, &amp;ts);
+  n = (uint64_t) ts.tv_sec * 1000000 + ts.tv_nsec / 1000;
+  msec = t > n ? (int) ((t - n + 999) / 1000) : 0;
+}</programlisting>
+
+    <para>The code above does not do any error checking for brevity's
+    sake. The calculated <varname>msec</varname> integer can be passed
+    directly as <function>poll()</function>'s timeout
+    parameter.</para>
+
+    <para>After each <function>poll()</function> wake-up
+    <function>sd_journal_process()</function> needs to be called to
+    process events. This call will also indicate what kind of change
+    has been detected (see below; note that spurious wake-ups are
+    possible).</para>
+
+    <para>A synchronous alternative for using
+    <function>sd_journal_get_fd()</function>,
+    <function>sd_journal_get_events()</function>,
+    <function>sd_journal_get_timeout()</function> and
+    <function>sd_journal_process()</function> is
+    <function>sd_journal_wait()</function>. It will synchronously wait
+    until the journal gets changed. The maximum time this call sleeps
+    may be controlled with the <parameter>timeout_usec</parameter>
+    parameter. Pass <constant>(uint64_t) -1</constant> to wait
+    indefinitely. Internally this call simply combines
+    <function>sd_journal_get_fd()</function>,
+    <function>sd_journal_get_events()</function>,
+    <function>sd_journal_get_timeout()</function>,
+    <function>poll()</function> and
+    <function>sd_journal_process()</function> into one.</para>
+
+    <para><function>sd_journal_reliable_fd()</function> may be used to check whether the wake-up events from
+    the file descriptor returned by <function>sd_journal_get_fd()</function> are known to be quickly
+    triggered. On certain file systems where file change events from the OS are not available (such as NFS)
+    changes need to be polled for repeatedly, and hence are detected only with a considerable latency. This
+    call will return a positive value if the journal changes are detected quickly and zero when they need to
+    be polled for. Note that there is usually no need to invoke this function directly as
+    <function>sd_journal_get_timeout()</function> will request appropriate timeouts anyway.</para>
+
+    <para>Note that all of the above change notification interfaces do not report changes
+    instantly. Latencies are introduced for multiple reasons: as mentioned certain storage backends require
+    time-based polling, in other cases wake-ups are optimized by coalescing events, and the OS introduces
+    additional IO/CPU scheduling latencies.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para><function>sd_journal_get_fd()</function> returns a valid
+    file descriptor on success or a negative errno-style error
+    code.</para>
+
+    <para><function>sd_journal_get_events()</function> returns a
+    combination of <constant>POLLIN</constant>,
+    <constant>POLLOUT</constant> and suchlike on success or a negative
+    errno-style error code.</para>
+
+    <para><function>sd_journal_reliable_fd()</function> returns a
+    positive integer if the file descriptor returned by
+    <function>sd_journal_get_fd()</function> will generate wake-ups
+    immediately for all journal changes. Returns 0 if there might be a
+    latency involved.</para>
+
+    <para><function>sd_journal_process()</function> and <function>sd_journal_wait()</function> return a negative
+    errno-style error code, or one of <constant>SD_JOURNAL_NOP</constant>, <constant>SD_JOURNAL_APPEND</constant> or
+    <constant>SD_JOURNAL_INVALIDATE</constant> on success:</para>
+
+    <itemizedlist>
+      <listitem><para>If <constant>SD_JOURNAL_NOP</constant> is returned, the journal did not change since the last
+      invocation.</para></listitem>
+
+      <listitem><para>If <constant>SD_JOURNAL_APPEND</constant> is returned, new entries have been appended to the end
+      of the journal. In this case it is sufficient to simply continue reading at the previous end location of the
+      journal, to read the newly added entries.</para></listitem>
+
+      <listitem><para>If <constant>SD_JOURNAL_INVALIDATE</constant>, journal files were added to or removed from the
+      set of journal files watched (e.g. due to rotation or vacuuming), and thus entries might have appeared or
+      disappeared at arbitrary places in the log stream, possibly before or after the previous end of the log
+      stream. If <constant>SD_JOURNAL_INVALIDATE</constant> is returned, live-view UIs that want to reflect on screen
+      the precise state of the log data on disk should probably refresh their entire display (relative to the cursor of
+      the log entry on the top of the screen). Programs only interested in a strictly sequential stream of log data may
+      treat <constant>SD_JOURNAL_INVALIDATE</constant> the same way as <constant>SD_JOURNAL_APPEND</constant>, thus
+      ignoring any changes to the log view earlier than the old end of the log stream.</para></listitem>
+    </itemizedlist>
+  </refsect1>
+
+  <refsect1>
+    <title>Signal safety</title>
+
+    <para>In general, <function>sd_journal_get_fd()</function>, <function>sd_journal_get_events()</function>, and
+    <function>sd_journal_get_timeout()</function> are <emphasis>not</emphasis> "async signal safe" in the meaning of
+    <citerefentry
+    project='man-pages'><refentrytitle>signal-safety</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
+    Nevertheless, only the first call to any of those three functions performs unsafe operations, so subsequent calls
+    <emphasis>are</emphasis> safe.</para>
+
+    <para><function>sd_journal_process()</function> and <function>sd_journal_wait()</function> are not
+    safe. <function>sd_journal_reliable_fd()</function> is safe.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Notes</title>
+
+    <xi:include href="threads-aware.xml" xpointer="strict"/>
+
+    <xi:include href="libsystemd-pkgconfig.xml" xpointer="pkgconfig-text"/>
+  </refsect1>
+
+  <refsect1>
+    <title>Examples</title>
+
+    <para>Iterating through the journal, in a live view tracking all
+    changes:</para>
+
+    <programlisting><xi:include href="journal-iterate-wait.c" parse="text" /></programlisting>
+
+    <para>Waiting with <function>poll()</function> (this
+    example lacks all error checking for the sake of
+    simplicity):</para>
+
+    <programlisting><xi:include href="journal-iterate-poll.c" parse="text" /></programlisting>
+  </refsect1>
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_journal_get_fd()</function>,
+    <function>sd_journal_process()</function>, and
+    <function>sd_journal_wait()</function> were added in version 187.</para>
+    <para><function>sd_journal_reliable_fd()</function> was added in version 196.</para>
+    <para><function>sd_journal_get_events()</function> and
+    <function>sd_journal_get_timeout()</function> were added in version 201.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-journal</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_journal_open</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_journal_next</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>poll</refentrytitle><manvolnum>2</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>clock_gettime</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_journal_get_realtime_usec.xml b/man/sd_journal_get_realtime_usec.xml
new file mode 100644
index 0000000..0d2b08e
--- /dev/null
+++ b/man/sd_journal_get_realtime_usec.xml
@@ -0,0 +1,119 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_journal_get_realtime_usec"
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_journal_get_realtime_usec</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_journal_get_realtime_usec</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_journal_get_realtime_usec</refname>
+    <refname>sd_journal_get_monotonic_usec</refname>
+    <refpurpose>Read timestamps from the current journal entry</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-journal.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_journal_get_realtime_usec</function></funcdef>
+        <paramdef>sd_journal *<parameter>j</parameter></paramdef>
+        <paramdef>uint64_t *<parameter>usec</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_journal_get_monotonic_usec</function></funcdef>
+        <paramdef>sd_journal *<parameter>j</parameter></paramdef>
+        <paramdef>uint64_t *<parameter>usec</parameter></paramdef>
+        <paramdef>sd_id128_t *<parameter>boot_id</parameter></paramdef>
+      </funcprototype>
+
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_journal_get_realtime_usec()</function> gets the
+    realtime (wallclock) timestamp of the current journal entry. It
+    takes two arguments: the journal context object and a pointer to a
+    64-bit unsigned integer to store the timestamp in. The timestamp
+    is in microseconds since the epoch, i.e.
+    <constant>CLOCK_REALTIME</constant>.</para>
+
+    <para><function>sd_journal_get_monotonic_usec()</function> gets
+    the monotonic timestamp of the current journal entry. It takes
+    three arguments: the journal context object, a pointer to a 64-bit
+    unsigned integer to store the timestamp in, as well as a 128-bit
+    ID buffer to store the boot ID of the monotonic timestamp. The
+    timestamp is in microseconds since boot-up of the specific boot,
+    i.e. <constant>CLOCK_MONOTONIC</constant>. Since the monotonic
+    clock begins new with every reboot, it only defines a well-defined
+    point in time when used together with an identifier identifying
+    the boot. See
+    <citerefentry><refentrytitle>sd_id128_get_boot</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    for more information. If the boot ID parameter is passed
+    <constant>NULL</constant>, the function will fail if the monotonic
+    timestamp of the current entry is not of the current system
+    boot.</para>
+
+    <para>Note that these functions will not work before
+    <citerefentry><refentrytitle>sd_journal_next</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    (or related call) has been called at least
+    once, in order to position the read pointer at a valid entry.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para><function>sd_journal_get_realtime_usec()</function> and
+    <function>sd_journal_get_monotonic_usec()</function> returns 0 on
+    success or a negative errno-style error code. If the boot ID
+    parameter was passed <constant>NULL</constant> and the monotonic
+    timestamp of the current journal entry is not of the current
+    system boot, <constant>-ESTALE</constant> is returned by
+    <function>sd_journal_get_monotonic_usec()</function>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Notes</title>
+
+    <xi:include href="threads-aware.xml" xpointer="strict"/>
+
+    <xi:include href="libsystemd-pkgconfig.xml" xpointer="pkgconfig-text"/>
+  </refsect1>
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_journal_get_realtime_usec()</function> and
+    <function>sd_journal_get_monotonic_usec()</function> were added in version 187.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-journal</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_journal_open</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_journal_next</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_journal_get_data</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_journal_get_seqnum</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_id128_get_boot</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>clock_gettime</refentrytitle><manvolnum>2</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_journal_get_cutoff_realtime_usec</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_journal_get_seqnum.xml b/man/sd_journal_get_seqnum.xml
new file mode 100644
index 0000000..5459d94
--- /dev/null
+++ b/man/sd_journal_get_seqnum.xml
@@ -0,0 +1,110 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_journal_get_seqnum"
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_journal_get_seqnum</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_journal_get_seqnum</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_journal_get_seqnum</refname>
+    <refpurpose>Read sequence number from the current journal entry</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-journal.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_journal_get_seqnum</function></funcdef>
+        <paramdef>sd_journal *<parameter>j</parameter></paramdef>
+        <paramdef>uint64_t *<parameter>ret_seqnum</parameter></paramdef>
+        <paramdef>sd_id128_t *<parameter>ret_seqnum_id</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_journal_get_seqnum()</function> returns the sequence number of the current journal
+    entry. It takes three arguments: the journal context object, a pointer to a 64-bit unsigned integer to
+    store the sequence number in, and a buffer to return the 128-bit sequence number ID in.</para>
+
+    <para>When writing journal entries to disk each <command>systemd-journald</command> instance will number
+    them sequentially, starting from 1 for the first entry written after subsystem initialization. Each such
+    series of sequence numbers is associated with a 128-bit sequence number ID which is initialized randomly,
+    once at <command>systemd-journal</command> initialization. Thus, while multiple instances of
+    <command>systemd-journald</command> will assign the same sequence numbers to their written journal
+    entries, they will have a distinct sequence number IDs. The sequence number is assigned at the moment of
+    writing the entry to disk. If log entries are rewritten (for example because the volatile logs from
+    <filename>/run/log/</filename> are flushed to <filename>/var/log/</filename> via
+    <filename>systemd-journald-flush.service</filename>) they will get new sequence numbers assigned.</para>
+
+    <para>Sequence numbers may be used to order entries (entries associated with the same sequence number ID
+    and lower sequence numbers should be ordered chronologically before those with higher sequence numbers),
+    and to detect lost entries. Note that journal service instances typically write to multiple journal files
+    in parallel (for example because <varname>SplitMode=</varname> is used), in which case each journal file
+    will only contain a subset of the sequence numbers. To recover the full stream of journal entries the
+    files must be combined ("interleaved"), a process that primarily relies on the sequence numbers. When
+    journal files are rotated (due to size or time limits), the series of sequence numbers is continued in
+    the replacement files. All journal files generated from the same journal instance will carry the same
+    sequence number ID.</para>
+
+    <para>As the sequence numbers are assigned at the moment of writing the journal entries to disk they do
+    not exist if storage is disabled via <varname>SplitMode=</varname>.</para>
+
+    <para>The <varname>ret_seqnum</varname> and <varname>ret_seqnum_id</varname> parameters may be specified
+    as <constant>NULL</constant> in which case the relevant data is not returned (but the call will otherwise
+    succeed).</para>
+
+    <para>Note that these functions will not work before
+    <citerefentry><refentrytitle>sd_journal_next</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    (or related call) has been called at least
+    once, in order to position the read pointer at a valid entry.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para><function>sd_journal_get_seqnum()</function> returns 0 on success or a negative errno-style error
+    code..</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Notes</title>
+
+    <xi:include href="threads-aware.xml" xpointer="strict"/>
+
+    <xi:include href="libsystemd-pkgconfig.xml" xpointer="pkgconfig-text"/>
+  </refsect1>
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_journal_get_seqnum()</function> was added in version 254.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-journal</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_journal_open</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_journal_next</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_journal_get_data</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_journal_get_monotonic_usec</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_journal_get_usage.xml b/man/sd_journal_get_usage.xml
new file mode 100644
index 0000000..e5fae28
--- /dev/null
+++ b/man/sd_journal_get_usage.xml
@@ -0,0 +1,76 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_journal_get_usage" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_journal_get_usage</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_journal_get_usage</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_journal_get_usage</refname>
+    <refpurpose>Journal disk usage</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-journal.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_journal_get_usage</function></funcdef>
+        <paramdef>sd_journal *<parameter>j</parameter></paramdef>
+        <paramdef>uint64_t *<parameter>bytes</parameter></paramdef>
+      </funcprototype>
+
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_journal_get_usage()</function> determines the
+    total disk space currently used by journal files (in bytes). If
+    <constant>SD_JOURNAL_LOCAL_ONLY</constant> was passed when opening
+    the journal, this value will only reflect the size of journal
+    files of the local host, otherwise of all hosts.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para><function>sd_journal_get_usage()</function> returns 0 on
+    success or a negative errno-style error code.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Notes</title>
+
+    <xi:include href="threads-aware.xml" xpointer="strict"/>
+
+    <xi:include href="libsystemd-pkgconfig.xml" xpointer="pkgconfig-text"/>
+  </refsect1>
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_journal_get_usage()</function> was added in version 190.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-journal</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_journal_open</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_journal_has_runtime_files.xml b/man/sd_journal_has_runtime_files.xml
new file mode 100644
index 0000000..90110be
--- /dev/null
+++ b/man/sd_journal_has_runtime_files.xml
@@ -0,0 +1,85 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+
+<!--
+  SPDX-License-Identifier: LGPL-2.1-or-later
+-->
+
+<refentry id="sd_journal_has_runtime_files" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_journal_has_runtime_files</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_journal_has_runtime_files</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_journal_has_runtime_files</refname>
+    <refname>sd_journal_has_persistent_files</refname>
+    <refpurpose>Query availability of runtime or persistent journal files</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-journal.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_journal_has_runtime_files</function></funcdef>
+        <paramdef>sd_journal *<parameter>j</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_journal_has_persistent_files</function></funcdef>
+        <paramdef>sd_journal *<parameter>j</parameter></paramdef>
+      </funcprototype>
+
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_journal_has_runtime_files()</function> returns a positive value
+    if runtime journal files (present in /run/systemd/journal/) have been found.
+    Otherwise returns 0.</para>
+
+    <para><function>sd_journal_has_persistent_files()</function> returns a positive value
+    if persistent journal files (present in /var/log/journal/) have been found.
+    Otherwise returns 0.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return value</title>
+    <para>Both <function>sd_journal_has_runtime_files()</function>
+    and <function>sd_journal_has_persistent_files()</function> return -EINVAL
+    if their argument is <constant>NULL</constant>.
+    </para>
+  </refsect1>
+
+  <refsect1>
+    <title>Notes</title>
+
+    <xi:include href="threads-aware.xml" xpointer="strict"/>
+
+    <xi:include href="libsystemd-pkgconfig.xml" xpointer="pkgconfig-text"/>
+  </refsect1>
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_journal_has_runtime_files()</function> and
+    <function>sd_journal_has_persistent_files()</function> were added in version 229.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>sd-journal</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_journal_next.xml b/man/sd_journal_next.xml
new file mode 100644
index 0000000..ea5cbef
--- /dev/null
+++ b/man/sd_journal_next.xml
@@ -0,0 +1,176 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_journal_next" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_journal_next</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_journal_next</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_journal_next</refname>
+    <refname>sd_journal_previous</refname>
+    <refname>sd_journal_step_one</refname>
+    <refname>sd_journal_next_skip</refname>
+    <refname>sd_journal_previous_skip</refname>
+    <refname>SD_JOURNAL_FOREACH</refname>
+    <refname>SD_JOURNAL_FOREACH_BACKWARDS</refname>
+    <refpurpose>Advance or set back the read pointer in the journal</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-journal.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_journal_next</function></funcdef>
+        <paramdef>sd_journal *<parameter>j</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_journal_previous</function></funcdef>
+        <paramdef>sd_journal *<parameter>j</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_journal_step_one</function></funcdef>
+        <paramdef>sd_journal *<parameter>j</parameter></paramdef>
+        <paramdef>int <parameter>advanced</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_journal_next_skip</function></funcdef>
+        <paramdef>sd_journal *<parameter>j</parameter></paramdef>
+        <paramdef>uint64_t <parameter>skip</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_journal_previous_skip</function></funcdef>
+        <paramdef>sd_journal *<parameter>j</parameter></paramdef>
+        <paramdef>uint64_t <parameter>skip</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef><function>SD_JOURNAL_FOREACH</function></funcdef>
+        <paramdef>sd_journal *<parameter>j</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef><function>SD_JOURNAL_FOREACH_BACKWARDS</function></funcdef>
+        <paramdef>sd_journal *<parameter>j</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_journal_next()</function> advances the read
+    pointer into the journal by one entry. The only argument taken is
+    a journal context object as allocated via
+    <citerefentry><refentrytitle>sd_journal_open</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+    After successful invocation the entry may be read with functions
+    such as
+    <citerefentry><refentrytitle>sd_journal_get_data</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para>
+
+    <para>Similarly, <function>sd_journal_previous()</function> sets
+    the read pointer back one entry.</para>
+
+    <para><function>sd_journal_step_one()</function> also moves the read pointer. If the current location
+    is the head of the journal, e.g. when this is called following
+    <function>sd_journal_seek_head()</function>, then this is equivalent to
+    <function>sd_journal_next()</function>, and the argument <varname>advanced</varname> will be ignored.
+    Similarly, if the current location is the tail of the journal, e.g. when this is called following
+    <function>sd_journal_seek_tail()</function>, then this is equivalent to
+    <function>sd_journal_previous()</function>, and <varname>advanced</varname> will be ignored. Otherwise,
+    this is equivalent to <function>sd_journal_next()</function> when <varname>advanced</varname> is
+    non-zero, and <function>sd_journal_previous()</function> when <varname>advanced</varname> is zero.</para>
+
+    <para><function>sd_journal_next_skip()</function> and
+    <function>sd_journal_previous_skip()</function> advance/set back the read pointer by multiple
+    entries at once, as specified in the <varname>skip</varname> parameter. The <varname>skip</varname>
+    parameter must be less than or equal to 2147483647 (2³¹-1).</para>
+
+    <para>The journal is strictly ordered by reception time, and hence
+    advancing to the next entry guarantees that the entry then
+    pointing to is later in time than then previous one, or has the
+    same timestamp.</para>
+
+    <para>Note that
+    <citerefentry><refentrytitle>sd_journal_get_data</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    and related calls will fail unless
+    <function>sd_journal_next()</function> has been invoked at least
+    once in order to position the read pointer on a journal
+    entry.</para>
+
+    <para>Note that the <function>SD_JOURNAL_FOREACH()</function>
+    macro may be used as a wrapper around
+    <citerefentry><refentrytitle>sd_journal_seek_head</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    and <function>sd_journal_next()</function> in order to make
+    iterating through the journal easier. See below for an example.
+    Similarly, <function>SD_JOURNAL_FOREACH_BACKWARDS()</function> may
+    be used for iterating the journal in reverse order.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>The four calls return the number of entries advanced/set
+    back on success or a negative errno-style error code. When the end
+    or beginning of the journal is reached, a number smaller than
+    requested is returned. More specifically, if
+    <function>sd_journal_next()</function> or
+    <function>sd_journal_previous()</function> reach the end/beginning
+    of the journal they will return 0, instead of 1 when they are
+    successful. This should be considered an EOF marker.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Notes</title>
+
+    <xi:include href="threads-aware.xml" xpointer="strict"/>
+
+    <xi:include href="libsystemd-pkgconfig.xml" xpointer="pkgconfig-text"/>
+  </refsect1>
+
+  <refsect1>
+    <title>Examples</title>
+
+    <para>Iterating through the journal:</para>
+
+    <programlisting><xi:include href="journal-iterate-foreach.c" parse="text" /></programlisting>
+  </refsect1>
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_journal_next()</function>,
+    <function>sd_journal_previous()</function>,
+    <function>sd_journal_next_skip()</function>,
+    <function>sd_journal_previous_skip()</function>,
+    <function>SD_JOURNAL_FOREACH()</function>, and
+    <function>SD_JOURNAL_FOREACH_BACKWARDS()</function> were added in version 187.</para>
+    <para><function>sd_journal_step_one()</function> was added in version 254.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-journal</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_journal_open</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_journal_get_data</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_journal_get_realtime_usec</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_journal_get_cursor</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_journal_open.xml b/man/sd_journal_open.xml
new file mode 100644
index 0000000..3b8fb1f
--- /dev/null
+++ b/man/sd_journal_open.xml
@@ -0,0 +1,243 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_journal_open"
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_journal_open</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_journal_open</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_journal_open</refname>
+    <refname>sd_journal_open_directory</refname>
+    <refname>sd_journal_open_directory_fd</refname>
+    <refname>sd_journal_open_files</refname>
+    <refname>sd_journal_open_files_fd</refname>
+    <refname>sd_journal_open_namespace</refname>
+    <refname>sd_journal_close</refname>
+    <refname>sd_journal</refname>
+    <refname>SD_JOURNAL_LOCAL_ONLY</refname>
+    <refname>SD_JOURNAL_RUNTIME_ONLY</refname>
+    <refname>SD_JOURNAL_SYSTEM</refname>
+    <refname>SD_JOURNAL_CURRENT_USER</refname>
+    <refname>SD_JOURNAL_OS_ROOT</refname>
+    <refname>SD_JOURNAL_ALL_NAMESPACES</refname>
+    <refname>SD_JOURNAL_INCLUDE_DEFAULT_NAMESPACE</refname>
+    <refname>SD_JOURNAL_TAKE_DIRECTORY_FD</refname>
+    <refpurpose>Open the system journal for reading</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-journal.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_journal_open</function></funcdef>
+        <paramdef>sd_journal **<parameter>ret</parameter></paramdef>
+        <paramdef>int <parameter>flags</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_journal_open_namespace</function></funcdef>
+        <paramdef>sd_journal **<parameter>ret</parameter></paramdef>
+        <paramdef>const char *<parameter>namespace</parameter></paramdef>
+        <paramdef>int <parameter>flags</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_journal_open_directory</function></funcdef>
+        <paramdef>sd_journal **<parameter>ret</parameter></paramdef>
+        <paramdef>const char *<parameter>path</parameter></paramdef>
+        <paramdef>int <parameter>flags</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_journal_open_directory_fd</function></funcdef>
+        <paramdef>sd_journal **<parameter>ret</parameter></paramdef>
+        <paramdef>int <parameter>fd</parameter></paramdef>
+        <paramdef>int <parameter>flags</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_journal_open_files</function></funcdef>
+        <paramdef>sd_journal **<parameter>ret</parameter></paramdef>
+        <paramdef>const char **<parameter>paths</parameter></paramdef>
+        <paramdef>int <parameter>flags</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_journal_open_files_fd</function></funcdef>
+        <paramdef>sd_journal **<parameter>ret</parameter></paramdef>
+        <paramdef>int <parameter>fds[]</parameter></paramdef>
+        <paramdef>unsigned <parameter>n_fds</parameter></paramdef>
+        <paramdef>int <parameter>flags</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>void <function>sd_journal_close</function></funcdef>
+        <paramdef>sd_journal *<parameter>j</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_journal_open()</function> opens the log journal
+    for reading. It will find all journal files automatically and
+    interleave them automatically when reading. As first argument it
+    takes a pointer to a <varname>sd_journal</varname> pointer, which,
+    on success, will contain a journal context object. The second
+    argument is a flags field, which may consist of the following
+    flags ORed together: <constant>SD_JOURNAL_LOCAL_ONLY</constant>
+    makes sure only journal files generated on the local machine will
+    be opened. <constant>SD_JOURNAL_RUNTIME_ONLY</constant> makes sure
+    only volatile journal files will be opened, excluding those which
+    are stored on persistent storage.
+    <constant>SD_JOURNAL_SYSTEM</constant> will cause journal files of
+    system services and the kernel (in opposition to user session
+    processes) to be opened.
+    <constant>SD_JOURNAL_CURRENT_USER</constant> will cause journal
+    files of the current user to be opened. If neither
+    <constant>SD_JOURNAL_SYSTEM</constant> nor
+    <constant>SD_JOURNAL_CURRENT_USER</constant> are specified, all
+    journal file types will be opened.</para>
+
+    <para><function>sd_journal_open_namespace()</function> is similar to
+    <function>sd_journal_open()</function> but takes an additional <parameter>namespace</parameter> parameter
+    that specifies which journal namespace to operate on. If specified as <constant>NULL</constant> the call
+    is identical to <function>sd_journal_open()</function>. If non-<constant>NULL</constant> only data from
+    the namespace identified by the specified parameter is accessed. This call understands two additional
+    flags: if <constant>SD_JOURNAL_ALL_NAMESPACES</constant> is specified the
+    <parameter>namespace</parameter> parameter is ignored and all defined namespaces are accessed
+    simultaneously; if <constant>SD_JOURNAL_INCLUDE_DEFAULT_NAMESPACE</constant> the specified namespace and
+    the default namespace are accessed but no others (this flag has no effect when
+    <parameter>namespace</parameter> is passed as <constant>NULL</constant>). For details about journal
+    namespaces see
+    <citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
+
+    <para><function>sd_journal_open_directory()</function> is similar to <function>sd_journal_open()</function> but
+    takes an absolute directory path as argument. All journal files in this directory will be opened and interleaved
+    automatically. This call also takes a flags argument. The flags parameters accepted by this call are
+    <constant>SD_JOURNAL_OS_ROOT</constant>, <constant>SD_JOURNAL_SYSTEM</constant>, and
+    <constant>SD_JOURNAL_CURRENT_USER</constant>. If <constant>SD_JOURNAL_OS_ROOT</constant> is specified, journal
+    files are searched for below the usual <filename>/var/log/journal</filename> and
+    <filename>/run/log/journal</filename> relative to the specified path, instead of directly beneath it.
+    The other two flags limit which files are opened, the same as for <function>sd_journal_open()</function>.
+    </para>
+
+    <para><function>sd_journal_open_directory_fd()</function> is similar to
+    <function>sd_journal_open_directory()</function>, but takes a file descriptor referencing a directory in the file
+    system instead of an absolute file system path. In addition to the flags accepted by
+    <function>sd_journal_open_directory()</function>, this function also accepts
+    <constant>SD_JOURNAL_TAKE_DIRECTORY_FD</constant>. If <constant>SD_JOURNAL_TAKE_DIRECTORY_FD</constant> is
+    specified, the function will take the ownership of the specified file descriptor on success, and it will be
+    closed by <function>sd_journal_close()</function>, hence the caller of the function must not close the file
+    descriptor. When the flag is not specified, <function>sd_journal_close()</function> will not close the file
+    descriptor, so the caller should close it after <function>sd_journal_close()</function>.</para>
+
+    <para><function>sd_journal_open_files()</function> is similar to <function>sd_journal_open()</function> but takes a
+    <constant>NULL</constant>-terminated list of file paths to open.  All files will be opened and interleaved
+    automatically. This call also takes a flags argument, but it must be passed as 0 as no flags are currently
+    understood for this call. Please note that in the case of a live journal, this function is only useful for
+    debugging, because individual journal files can be rotated at any moment, and the opening of specific files is
+    inherently racy.</para>
+
+    <para><function>sd_journal_open_files_fd()</function> is similar to <function>sd_journal_open_files()</function>
+    but takes an array of open file descriptors that must reference journal files, instead of an array of file system
+    paths. Pass the array of file descriptors as second argument, and the number of array entries in the third. The
+    flags parameter must be passed as 0.</para>
+
+    <para><varname>sd_journal</varname> objects cannot be used in the
+    child after a fork. Functions which take a journal object as an
+    argument (<function>sd_journal_next()</function> and others) will
+    return <constant>-ECHILD</constant> after a fork.
+    </para>
+
+    <para><function>sd_journal_close()</function> will close the
+    journal context allocated with
+    <function>sd_journal_open()</function> or
+    <function>sd_journal_open_directory()</function> and free its
+    resources.</para>
+
+    <para>When opening the journal only journal files accessible to
+    the calling user will be opened. If journal files are not
+    accessible to the caller, this will be silently ignored.</para>
+
+    <para>See
+    <citerefentry><refentrytitle>sd_journal_next</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    for an example of how to iterate through the journal after opening
+    it with <function>sd_journal_open()</function>.</para>
+
+    <para>A journal context object returned by
+    <function>sd_journal_open()</function> references a specific
+    journal entry as <emphasis>current</emphasis> entry, similar to a
+    file seek index in a classic file system file, but without
+    absolute positions. It may be altered with
+    <citerefentry><refentrytitle>sd_journal_next</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    and
+    <citerefentry><refentrytitle>sd_journal_seek_head</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    and related calls. The current entry position may be exported in
+    <emphasis>cursor</emphasis> strings, as accessible via
+    <citerefentry><refentrytitle>sd_journal_get_cursor</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+    Cursor strings may be used to globally identify a specific journal
+    entry in a stable way and then later to seek to it (or if the
+    specific entry is not available locally, to its closest entry in
+    time)
+    <citerefentry><refentrytitle>sd_journal_seek_cursor</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para>
+
+    <para>Notification of journal changes is available via
+    <function>sd_journal_get_fd()</function> and related calls.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>The <function>sd_journal_open()</function>,
+    <function>sd_journal_open_directory()</function>, and
+    <function>sd_journal_open_files()</function> calls return 0 on
+    success or a negative errno-style error code.
+    <function>sd_journal_close()</function> returns nothing.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Notes</title>
+
+    <xi:include href="threads-aware.xml" xpointer="strict"/>
+
+    <xi:include href="libsystemd-pkgconfig.xml" xpointer="pkgconfig-text"/>
+  </refsect1>
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_journal_open()</function>,
+    <function>sd_journal_open_directory()</function>, and
+    <function>sd_journal_close()</function> were added in version 187.</para>
+    <para><function>sd_journal_open_files()</function> was added in version 205.</para>
+    <para><function>sd_journal_open_directory_fd()</function> and
+    <function>sd_journal_open_files_fd()</function> were added in version 230.</para>
+    <para><function>sd_journal_open_namespace()</function> was added in version 245.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-journal</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_journal_next</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_journal_get_data</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_journal_print.xml b/man/sd_journal_print.xml
new file mode 100644
index 0000000..8c515a4
--- /dev/null
+++ b/man/sd_journal_print.xml
@@ -0,0 +1,290 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_journal_print" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_journal_print</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_journal_print</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_journal_print</refname>
+    <refname>sd_journal_printv</refname>
+    <refname>sd_journal_send</refname>
+    <refname>sd_journal_sendv</refname>
+    <refname>sd_journal_perror</refname>
+    <refname>SD_JOURNAL_SUPPRESS_LOCATION</refname>
+    <refname>sd_journal_print_with_location</refname>
+    <refname>sd_journal_printv_with_location</refname>
+    <refname>sd_journal_send_with_location</refname>
+    <refname>sd_journal_sendv_with_location</refname>
+    <refname>sd_journal_perror_with_location</refname>
+
+    <refpurpose>Submit log entries to the journal</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-journal.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_journal_print</function></funcdef>
+        <paramdef>int <parameter>priority</parameter></paramdef>
+        <paramdef>const char *<parameter>format</parameter></paramdef>
+        <paramdef>…</paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_journal_printv</function></funcdef>
+        <paramdef>int <parameter>priority</parameter></paramdef>
+        <paramdef>const char *<parameter>format</parameter></paramdef>
+        <paramdef>va_list <parameter>ap</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_journal_send</function></funcdef>
+        <paramdef>const char *<parameter>format</parameter></paramdef>
+        <paramdef>…</paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_journal_sendv</function></funcdef>
+        <paramdef>const struct iovec *<parameter>iov</parameter></paramdef>
+        <paramdef>int <parameter>n</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_journal_perror</function></funcdef>
+        <paramdef>const char *<parameter>message</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_journal_print_with_location</function></funcdef>
+        <paramdef>int <parameter>priority</parameter></paramdef>
+        <paramdef>const char *<parameter>file</parameter></paramdef>
+        <paramdef>const char *<parameter>line</parameter></paramdef>
+        <paramdef>const char *<parameter>func</parameter></paramdef>
+        <paramdef>const char *<parameter>format</parameter></paramdef>
+        <paramdef>…</paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_journal_printv_with_location</function></funcdef>
+        <paramdef>int <parameter>priority</parameter></paramdef>
+        <paramdef>const char *<parameter>file</parameter></paramdef>
+        <paramdef>const char *<parameter>line</parameter></paramdef>
+        <paramdef>const char *<parameter>func</parameter></paramdef>
+        <paramdef>const char *<parameter>format</parameter></paramdef>
+        <paramdef>va_list <parameter>ap</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_journal_send_with_location</function></funcdef>
+        <paramdef>const char *<parameter>file</parameter></paramdef>
+        <paramdef>const char *<parameter>line</parameter></paramdef>
+        <paramdef>const char *<parameter>func</parameter></paramdef>
+        <paramdef>const char *<parameter>format</parameter></paramdef>
+        <paramdef>…</paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_journal_sendv_with_location</function></funcdef>
+        <paramdef>const char *<parameter>file</parameter></paramdef>
+        <paramdef>const char *<parameter>line</parameter></paramdef>
+        <paramdef>const char *<parameter>func</parameter></paramdef>
+        <paramdef>const struct iovec *<parameter>iov</parameter></paramdef>
+        <paramdef>int <parameter>n</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_journal_perror_with_location</function></funcdef>
+        <paramdef>const char *<parameter>file</parameter></paramdef>
+        <paramdef>const char *<parameter>line</parameter></paramdef>
+        <paramdef>const char *<parameter>func</parameter></paramdef>
+        <paramdef>const char *<parameter>message</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_journal_print()</function> may be used to submit simple, plain text log entries to the system
+    journal. The first argument is a priority value. This is followed by a format string and its parameters, similar to
+    <citerefentry project='man-pages'><refentrytitle>printf</refentrytitle><manvolnum>3</manvolnum></citerefentry> or
+    <citerefentry project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+    Note that currently the resulting message will be truncated to <constant>LINE_MAX - 8</constant>.
+    The priority value is one of <constant>LOG_EMERG</constant>, <constant>LOG_ALERT</constant>,
+    <constant>LOG_CRIT</constant>, <constant>LOG_ERR</constant>, <constant>LOG_WARNING</constant>,
+    <constant>LOG_NOTICE</constant>, <constant>LOG_INFO</constant>, <constant>LOG_DEBUG</constant>, as defined in
+    <filename>syslog.h</filename>, see <citerefentry
+    project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry> for details. It is
+    recommended to use this call to submit log messages in the application locale or system locale and in UTF-8 format,
+    but no such restrictions are enforced. Note that log messages written using this function are generally not
+    expected to end in a new-line character. However, as all trailing whitespace (including spaces, new-lines,
+    tabulators and carriage returns) are automatically stripped from the logged string, it is acceptable to specify one
+    (or more). Empty lines (after trailing whitespace removal) are suppressed. On non-empty lines, leading whitespace
+    (as well as inner whitespace) is left unmodified. </para>
+
+    <para><function>sd_journal_printv()</function> is similar to
+    <function>sd_journal_print()</function> but takes a variable
+    argument list encapsulated in an object of type
+    <varname>va_list</varname> (see
+    <citerefentry project='man-pages'><refentrytitle>stdarg</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    for more information) instead of the format string. It is
+    otherwise equivalent in behavior.</para>
+
+    <para><function>sd_journal_send()</function> may be used to submit structured log entries to the system journal. It
+    takes a series of format strings, each immediately followed by their associated parameters, terminated by
+    <constant>NULL</constant>. The strings passed should be of the format <literal>VARIABLE=value</literal>.  The
+    variable name must be in uppercase and consist only of characters, numbers and underscores, and may not begin with
+    an underscore. (All assignments that do not follow this syntax will be ignored.) The value can be of any size and
+    format. It is highly recommended to submit text strings formatted in the UTF-8 character encoding only, and submit
+    binary fields only when formatting in UTF-8 strings is not sensible. A number of well-known fields are defined, see
+    <citerefentry><refentrytitle>systemd.journal-fields</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
+    details, but additional application defined fields may be used. A variable may be assigned more than one value per
+    entry. If this function is used, trailing whitespace is automatically removed from each formatted field.</para>
+
+    <para><function>sd_journal_sendv()</function> is similar to <function>sd_journal_send()</function> but takes an
+    array of <varname>struct iovec</varname> (as defined in <filename>uio.h</filename>, see <citerefentry
+    project='man-pages'><refentrytitle>readv</refentrytitle><manvolnum>3</manvolnum></citerefentry> for details)
+    instead of the format string. Each structure should reference one field of the entry to submit. The second argument
+    specifies the number of structures in the array.  <function>sd_journal_sendv()</function> is particularly useful to
+    submit binary objects to the journal where that is necessary. Note that this function will not strip trailing
+    whitespace of the passed fields, but passes the specified data along unmodified. This is different from both
+    <function>sd_journal_print()</function> and <function>sd_journal_send()</function> described above, which are based
+    on format strings, and do strip trailing whitespace.</para>
+
+    <para><function>sd_journal_perror()</function> is a similar to
+    <citerefentry project='die-net'><refentrytitle>perror</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    and writes a message to the journal that consists of the passed
+    string, suffixed with ": " and a human-readable representation of
+    the current error code stored in
+    <citerefentry project='man-pages'><refentrytitle>errno</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+    If the message string is passed as <constant>NULL</constant> or
+    empty string, only the error string representation will be
+    written, prefixed with nothing. An additional journal field ERRNO=
+    is included in the entry containing the numeric error code
+    formatted as decimal string. The log priority used is
+    <constant>LOG_ERR</constant> (3).</para>
+
+    <para>Note that <function>sd_journal_send()</function> is a
+    wrapper around <function>sd_journal_sendv()</function> to make it
+    easier to use when only text strings shall be submitted. Also, the
+    following two calls are mostly equivalent:</para>
+
+    <programlisting>sd_journal_print(LOG_INFO, "Hello World, this is PID %lu!", (unsigned long) getpid());
+
+sd_journal_send("MESSAGE=Hello World, this is PID %lu!", (unsigned long) getpid(),
+                "PRIORITY=%i", LOG_INFO,
+                NULL);</programlisting>
+
+    <para>Note that these calls implicitly add fields for the source file, function name and code line where
+    invoked. This is implemented with macros. If this is not desired, it can be turned off by defining
+    <constant>SD_JOURNAL_SUPPRESS_LOCATION</constant> before including <filename>sd-journal.h</filename>.
+    </para>
+
+    <para><function>sd_journal_print_with_location()</function>,
+    <function>sd_journal_printv_with_location()</function>, <function>sd_journal_send_with_location()</function>,
+    <function>sd_journal_sendv_with_location()</function>, and
+    <function>sd_journal_perror_with_location()</function> are similar to their counterparts without
+    <literal>_with_location</literal>, but accept additional parameters to explicitly set the source file
+    name, function, and line. The arguments <literal>file</literal> and <literal>line</literal> must contain valid
+    journal entries including the variable name, e.g. <literal>CODE_FILE=src/foo.c</literal> and
+    <literal>CODE_LINE=666</literal>, while <literal>func</literal> must only contain the function name, i.e. the value
+    without <literal>CODE_FUNC=</literal>. These variants are primarily useful when writing custom wrappers, for
+    example in bindings for a different language.</para>
+
+    <para><citerefentry project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    and <function>sd_journal_print()</function> may
+    largely be used interchangeably
+    functionality-wise. However, note that log messages
+    logged via the former take a different path to the
+    journal server than the later, and hence global
+    chronological ordering between the two streams cannot
+    be guaranteed. Using
+    <function>sd_journal_print()</function> has the
+    benefit of logging source code line, filenames, and
+    functions as metadata along all entries, and
+    guaranteeing chronological ordering with structured
+    log entries that are generated via
+    <function>sd_journal_send()</function>. Using
+    <function>syslog()</function> has the benefit of being
+    more portable.</para>
+
+    <para>These functions implement a client to the <ulink
+    url="https://systemd.io/JOURNAL_NATIVE_PROTOCOL">Native Journal Protocol</ulink>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>The ten functions return 0 on success or a negative errno-style error code. The
+    <citerefentry project='man-pages'><refentrytitle>errno</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    variable itself is not altered.</para>
+
+    <para>If
+    <citerefentry><refentrytitle>systemd-journald</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    is not running (the socket is not present), those functions do
+    nothing, and also return 0.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Thread safety</title>
+
+    <xi:include href="threads-aware.xml" xpointer="safe"/>
+
+    <para><function>sd_journal_sendv()</function> and <function>sd_journal_sendv_with_location()</function>
+    are "async signal safe" in the meaning of
+    <citerefentry project='man-pages'><refentrytitle>signal-safety</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
+    </para>
+
+    <para><function>sd_journal_print()</function>,
+    <function>sd_journal_printv()</function>,
+    <function>sd_journal_send()</function>,
+    <function>sd_journal_perror()</function>,
+    and their counterparts with <literal>_with_location</literal>
+    are not async signal safe.</para>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_journal_print()</function>,
+    <function>sd_journal_printv()</function>,
+    <function>sd_journal_send()</function>, and
+    <function>sd_journal_sendv()</function> were added in version 187.</para>
+    <para><function>sd_journal_perror()</function> was added in version 188.</para>
+    <para><function>sd_journal_print_with_location()</function>,
+    <function>sd_journal_printv_with_location()</function>,
+    <function>sd_journal_send_with_location()</function>,
+    <function>sd_journal_sendv_with_location()</function>, and
+    <function>sd_journal_perror_with_location()</function> were added in version 246.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-journal</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_journal_stream_fd</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry project='die-net'><refentrytitle>perror</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>errno</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.journal-fields</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>signal</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>socket</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_journal_query_unique.xml b/man/sd_journal_query_unique.xml
new file mode 100644
index 0000000..005c8d5
--- /dev/null
+++ b/man/sd_journal_query_unique.xml
@@ -0,0 +1,184 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_journal_query_unique" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_journal_query_unique</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_journal_query_unique</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_journal_query_unique</refname>
+    <refname>sd_journal_enumerate_unique</refname>
+    <refname>sd_journal_enumerate_available_unique</refname>
+    <refname>sd_journal_restart_unique</refname>
+    <refname>SD_JOURNAL_FOREACH_UNIQUE</refname>
+    <refpurpose>Read unique data fields from the journal</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-journal.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_journal_query_unique</function></funcdef>
+        <paramdef>sd_journal *<parameter>j</parameter></paramdef>
+        <paramdef>const char *<parameter>field</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_journal_enumerate_available_unique</function></funcdef>
+        <paramdef>sd_journal *<parameter>j</parameter></paramdef>
+        <paramdef>const void **<parameter>data</parameter></paramdef>
+        <paramdef>size_t *<parameter>length</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_journal_enumerate_unique</function></funcdef>
+        <paramdef>sd_journal *<parameter>j</parameter></paramdef>
+        <paramdef>const void **<parameter>data</parameter></paramdef>
+        <paramdef>size_t *<parameter>length</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>void <function>sd_journal_restart_unique</function></funcdef>
+        <paramdef>sd_journal *<parameter>j</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef><function>SD_JOURNAL_FOREACH_UNIQUE</function></funcdef>
+        <paramdef>sd_journal *<parameter>j</parameter></paramdef>
+        <paramdef>const void *<parameter>data</parameter></paramdef>
+        <paramdef>size_t <parameter>length</parameter></paramdef>
+      </funcprototype>
+
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_journal_query_unique()</function> queries the journal for all unique values the
+    specified field can take. It takes two arguments: the journal to query and the field name to look
+    for. Well-known field names are listed on
+    <citerefentry><refentrytitle>systemd.journal-fields</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+    but any field can be specified. Field names must be specified without a trailing
+    <literal>=</literal>. After this function has been executed successfully the field values may be queried
+    using <function>sd_journal_enumerate_unique()</function> and
+    <function>sd_journal_enumerate_available_unique()</function>. Invoking one of those calls will change the
+    field name being queried and reset the enumeration index to the first field value that matches.</para>
+
+    <para><function>sd_journal_enumerate_unique()</function> may be used to iterate through all data fields
+    which match the previously selected field name as set with
+    <function>sd_journal_query_unique()</function>. On each invocation the next field data matching the field
+    name is returned. The order of the returned data fields is not defined. It takes three arguments: the
+    journal object, plus a pair of pointers to pointer/size variables where the data object and its size
+    shall be stored. The returned data is in a read-only memory map and is only valid until the next
+    invocation of <function>sd_journal_enumerate_unique()</function>. Note that the data returned will be
+    prefixed with the field name and <literal>=</literal>. Note that this call is subject to the data field
+    size threshold as controlled by <function>sd_journal_set_data_threshold()</function> and only the initial
+    part of the field up to the threshold is returned. An error is returned for fields which cannot be
+    retrieved. See the error list below for details.</para>
+
+    <para><function>sd_journal_enumerate_available_unique()</function> is similar to
+    <function>sd_journal_enumerate_unique()</function>, but silently skips any fields which may be valid, but
+    are too large or not supported by current implementation.</para>
+
+    <para><function>sd_journal_restart_unique()</function> resets the
+    data enumeration index to the beginning of the list. The next
+    invocation of <function>sd_journal_enumerate_unique()</function>
+    will return the first field data matching the field name
+    again.</para>
+
+    <para>Note that the <function>SD_JOURNAL_FOREACH_UNIQUE()</function> macro may be used as a handy wrapper
+    around <function>sd_journal_restart_unique()</function> and
+    <function>sd_journal_enumerate_available_unique()</function>.</para>
+
+    <para>Note that these functions currently are not influenced by
+    matches set with <function>sd_journal_add_match()</function> but
+    this might change in a later version of this software.</para>
+
+    <para>To enumerate all field names currently in use (and thus all suitable field parameters for
+    <function>sd_journal_query_unique()</function>), use the
+    <citerefentry><refentrytitle>sd_journal_enumerate_fields</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    call.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para><function>sd_journal_query_unique()</function> returns 0 on success or a negative errno-style error
+    code. <function>sd_journal_enumerate_unique()</function> and
+    <function>sd_journal_query_available_unique()</function> return a positive integer if the next field data
+    has been read, 0 when no more fields remain, or a negative errno-style error code.
+    <function>sd_journal_restart_unique()</function> doesn't return anything.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <xi:include href="sd_journal_get_data.xml" xpointer="EINVAL"/>
+        <xi:include href="sd_journal_get_data.xml" xpointer="ECHILD"/>
+        <xi:include href="sd_journal_get_data.xml" xpointer="EADDRNOTAVAIL"/>
+        <xi:include href="sd_journal_get_data.xml" xpointer="ENOENT"/>
+        <xi:include href="sd_journal_get_data.xml" xpointer="ENOBUFS"/>
+        <xi:include href="sd_journal_get_data.xml" xpointer="E2BIG"/>
+        <xi:include href="sd_journal_get_data.xml" xpointer="EPROTONOSUPPORT"/>
+        <xi:include href="sd_journal_get_data.xml" xpointer="EBADMSG"/>
+        <xi:include href="sd_journal_get_data.xml" xpointer="EIO"/>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <refsect1>
+    <title>Notes</title>
+
+    <xi:include href="threads-aware.xml" xpointer="strict"/>
+
+    <xi:include href="libsystemd-pkgconfig.xml" xpointer="pkgconfig-text"/>
+  </refsect1>
+
+  <refsect1>
+    <title>Examples</title>
+
+    <para>Use the <function>SD_JOURNAL_FOREACH_UNIQUE()</function> macro to iterate through all values a field
+    of the journal can take (and which can be accessed on the given architecture and are not compressed with
+    an unsupported mechanism). The following example lists all unit names referenced in the journal:</para>
+
+    <programlisting><xi:include href="journal-iterate-unique.c" parse="text" /></programlisting>
+  </refsect1>
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_journal_query_unique()</function>,
+    <function>sd_journal_enumerate_unique()</function>,
+    <function>sd_journal_restart_unique()</function>, and
+    <function>SD_JOURNAL_FOREACH_UNIQUE()</function> were added in version 195.</para>
+    <para><function>sd_journal_enumerate_available_unique()</function> was added in version 246.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.journal-fields</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-journal</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_journal_open</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_journal_enumerate_fields</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_journal_get_data</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_journal_add_match</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_journal_seek_head.xml b/man/sd_journal_seek_head.xml
new file mode 100644
index 0000000..15c72c0
--- /dev/null
+++ b/man/sd_journal_seek_head.xml
@@ -0,0 +1,140 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_journal_seek_head" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_journal_seek_head</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_journal_seek_head</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_journal_seek_head</refname>
+    <refname>sd_journal_seek_tail</refname>
+    <refname>sd_journal_seek_monotonic_usec</refname>
+    <refname>sd_journal_seek_realtime_usec</refname>
+    <refname>sd_journal_seek_cursor</refname>
+    <refpurpose>Seek to a position in the
+    journal</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-journal.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_journal_seek_head</function></funcdef>
+        <paramdef>sd_journal *<parameter>j</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_journal_seek_tail</function></funcdef>
+        <paramdef>sd_journal *<parameter>j</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_journal_seek_monotonic_usec</function></funcdef>
+        <paramdef>sd_journal *<parameter>j</parameter></paramdef>
+        <paramdef>sd_id128_t <parameter>boot_id</parameter></paramdef>
+        <paramdef>uint64_t <parameter>usec</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_journal_seek_realtime_usec</function></funcdef>
+        <paramdef>sd_journal *<parameter>j</parameter></paramdef>
+        <paramdef>uint64_t <parameter>usec</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_journal_seek_cursor</function></funcdef>
+        <paramdef>sd_journal *<parameter>j</parameter></paramdef>
+        <paramdef>const char *<parameter>cursor</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_journal_seek_head()</function> seeks to the beginning of the journal, i.e. to the
+    position before the oldest available entry.</para>
+
+    <para>Similarly, <function>sd_journal_seek_tail()</function> may be used to seek to the end of the
+    journal, i.e. the position after the most recent available entry.</para>
+
+    <para><function>sd_journal_seek_monotonic_usec()</function> seeks to a position with the specified
+    monotonic timestamp, i.e.  <constant>CLOCK_MONOTONIC</constant>. Since monotonic time restarts on every
+    reboot a boot ID needs to be specified as well.</para>
+
+    <para><function>sd_journal_seek_realtime_usec()</function> seeks to a position with the specified
+    realtime (wallclock) timestamp, i.e. <constant>CLOCK_REALTIME</constant>. Note that the realtime clock is
+    not necessarily monotonic. If a realtime timestamp is ambiguous, it is not defined which position is
+    sought to.</para>
+
+    <para><function>sd_journal_seek_cursor()</function> seeks to the position at the specified cursor
+    string. For details on cursors, see
+    <citerefentry><refentrytitle>sd_journal_get_cursor</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+    If no entry matching the specified cursor is found the call will seek to the next closest entry (in terms
+    of time) instead. To verify whether the newly selected entry actually matches the cursor, use
+    <citerefentry><refentrytitle>sd_journal_test_cursor</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para>
+
+    <para>Note that these calls do not actually make any entry the new current entry, this needs to be done
+    in a separate step with a subsequent
+    <citerefentry><refentrytitle>sd_journal_next</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    invocation (or a similar call). Only then, entry data may be retrieved via
+    <citerefentry><refentrytitle>sd_journal_get_data</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    or an entry cursor be retrieved via
+    <citerefentry><refentrytitle>sd_journal_get_cursor</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+    If no entry exists that matches exactly the specified seek address, the next closest is sought to. If
+    <citerefentry><refentrytitle>sd_journal_next</refentrytitle><manvolnum>3</manvolnum></citerefentry> is
+    used, the closest following entry will be sought to, if
+    <citerefentry><refentrytitle>sd_journal_previous</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    is used the closest preceding entry is sought to.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>The functions return 0 on success or a negative errno-style
+    error code.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Notes</title>
+
+    <xi:include href="threads-aware.xml" xpointer="strict"/>
+
+    <xi:include href="libsystemd-pkgconfig.xml" xpointer="pkgconfig-text"/>
+  </refsect1>
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_journal_seek_head()</function>,
+    <function>sd_journal_seek_tail()</function>,
+    <function>sd_journal_seek_monotonic_usec()</function>,
+    <function>sd_journal_seek_realtime_usec()</function>, and
+    <function>sd_journal_seek_cursor()</function> were added in version 187.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-journal</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_journal_open</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_journal_next</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_journal_get_data</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_journal_get_cursor</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_journal_get_realtime_usec</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_journal_stream_fd.xml b/man/sd_journal_stream_fd.xml
new file mode 100644
index 0000000..cbaed06
--- /dev/null
+++ b/man/sd_journal_stream_fd.xml
@@ -0,0 +1,125 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_journal_stream_fd" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_journal_stream_fd</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_journal_stream_fd</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_journal_stream_fd</refname>
+    <refpurpose>Create log stream file descriptor to the journal</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-journal.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_journal_stream_fd</function></funcdef>
+        <paramdef>const char *<parameter>identifier</parameter></paramdef>
+        <paramdef>int <parameter>priority</parameter></paramdef>
+        <paramdef>int <parameter>level_prefix</parameter></paramdef>
+      </funcprototype>
+
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_journal_stream_fd()</function> may be used to
+    create a log stream file descriptor. Log messages written to this
+    file descriptor as simple newline-separated text strings are
+    written to the journal. This file descriptor can be used
+    internally by applications or be made standard output or standard
+    error of other processes executed.</para>
+
+    <para><function>sd_journal_stream_fd()</function> takes a short
+    program identifier string as first argument, which will be written
+    to the journal as SYSLOG_IDENTIFIER= field for each log entry
+    (see
+    <citerefentry><refentrytitle>systemd.journal-fields</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+    for more information). The second argument shall be the default
+    priority level for all messages. The priority level is one of
+    <constant>LOG_EMERG</constant>, <constant>LOG_ALERT</constant>,
+    <constant>LOG_CRIT</constant>, <constant>LOG_ERR</constant>,
+    <constant>LOG_WARNING</constant>, <constant>LOG_NOTICE</constant>,
+    <constant>LOG_INFO</constant>, <constant>LOG_DEBUG</constant>, as
+    defined in <filename>syslog.h</filename>, see
+    <citerefentry project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    for details. The third argument is a boolean: if true kernel-style
+    log level prefixes (such as <constant>SD_WARNING</constant>) are
+    interpreted, see
+    <citerefentry><refentrytitle>sd-daemon</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    for more information.</para>
+
+    <para>It is recommended that applications log UTF-8 messages only
+    with this API, but this is not enforced.</para>
+
+    <para>Each invocation of <function>sd_journal_stream_fd()</function> allocates a new log stream file descriptor,
+    that is not shared with prior or later invocations. The file descriptor is write-only (its reading direction is
+    shut down), and <constant>O_NONBLOCK</constant> is turned off initially.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>The call returns a valid write-only file descriptor on
+    success or a negative errno-style error code.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Signal safety</title>
+
+    <para><function>sd_journal_stream_fd()</function> is "async signal safe" in the meaning of <citerefentry
+    project='man-pages'><refentrytitle>signal-safety</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
+    </para>
+  </refsect1>
+
+  <refsect1>
+    <title>Notes</title>
+
+    <xi:include href="threads-aware.xml" xpointer="safe"/>
+
+    <xi:include href="libsystemd-pkgconfig.xml" xpointer="pkgconfig-text"/>
+  </refsect1>
+
+  <refsect1>
+    <title>Examples</title>
+
+    <para>Creating a log stream suitable for
+    <citerefentry project='man-pages'><refentrytitle>fprintf</refentrytitle><manvolnum>3</manvolnum></citerefentry>:</para>
+
+    <programlisting><xi:include href="journal-stream-fd.c" parse="text" /></programlisting>
+  </refsect1>
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_journal_stream_fd()</function> was added in version 187.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-journal</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-daemon</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_journal_print</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>fprintf</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.journal-fields</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_listen_fds.xml b/man/sd_listen_fds.xml
new file mode 100644
index 0000000..7cd744e
--- /dev/null
+++ b/man/sd_listen_fds.xml
@@ -0,0 +1,247 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_listen_fds"
+  xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_listen_fds</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_listen_fds</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_listen_fds</refname>
+    <refname>sd_listen_fds_with_names</refname>
+    <refname>SD_LISTEN_FDS_START</refname>
+    <refpurpose>Check for file descriptors passed by the system manager</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-daemon.h&gt;</funcsynopsisinfo>
+
+      <funcsynopsisinfo>#define SD_LISTEN_FDS_START 3</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_listen_fds</function></funcdef>
+        <paramdef>int <parameter>unset_environment</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_listen_fds_with_names</function></funcdef>
+        <paramdef>int <parameter>unset_environment</parameter></paramdef>
+        <paramdef>char*** <parameter>names</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_listen_fds()</function> may be invoked by a daemon to check for file descriptors
+    passed by the service manager as part of the socket-based activation and file descriptor store logic. It
+    returns the number of received file descriptors. If no file descriptors have been received, zero is
+    returned. The first file descriptor may be found at file descriptor number 3
+    (i.e. <constant>SD_LISTEN_FDS_START</constant>), the remaining descriptors follow at 4, 5, 6, …, if
+    any.</para>
+
+    <para>The file descriptors passed this way may be closed at will by the processes receiving them: it's up
+    to the processes themselves to close them after use or whether to leave them open until the process exits
+    (in which case the kernel closes them automatically). Note that the file descriptors received by daemons
+    are duplicates of the file descriptors the service manager originally allocated and bound and of which it
+    continuously keeps a copy (except if <varname>Accept=yes</varname> is used). This means any socket option
+    changes and other changes made to the sockets will be visible to the service manager too. Most
+    importantly this means it's generally not a good idea to invoke <citerefentry
+    project='man-pages'><refentrytitle>shutdown</refentrytitle><manvolnum>2</manvolnum></citerefentry> on
+    such sockets, since it will shut down communication on the file descriptor the service manager holds for
+    the same socket too. Also note that if a daemon is restarted (and its associated sockets are not) it will
+    receive file descriptors to the very same sockets as the earlier invocations, thus all socket options
+    applied then will still apply.</para>
+
+    <para>If a daemon receives more than one file descriptor, they will be passed in the same order as
+    configured in the systemd socket unit file (see
+    <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
+    details) — if there's only one such file (see below).  Nonetheless, it is recommended to verify the
+    correct socket types before using them. To simplify this checking, the functions
+    <citerefentry><refentrytitle>sd_is_fifo</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_is_socket</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_is_socket_inet</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>sd_is_socket_unix</refentrytitle><manvolnum>3</manvolnum></citerefentry> are
+    provided. In order to maximize flexibility, it is recommended to make these checks as loose as possible
+    without allowing incorrect setups. i.e. often, the actual port number a socket is bound to matters little
+    for the service to work, hence it should not be verified. On the other hand, whether a socket is a
+    datagram or stream socket matters a lot for the most common program logics and should be checked.</para>
+
+    <para>This function call will set the <constant>FD_CLOEXEC</constant> flag for all passed file
+    descriptors to avoid further inheritance to children of the calling process.</para>
+
+    <para>If multiple socket units activate the same service, the order
+    of the file descriptors passed to its main process is undefined.
+    If additional file descriptors have been passed to the service
+    manager using
+    <citerefentry><refentrytitle>sd_pid_notify_with_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry>'s
+    <literal>FDSTORE=1</literal> messages, these file descriptors are
+    passed last, in arbitrary order, and with duplicates
+    removed.</para>
+
+    <para>If the <parameter>unset_environment</parameter> parameter is
+    non-zero, <function>sd_listen_fds()</function> will unset the
+    <varname>$LISTEN_FDS</varname>, <varname>$LISTEN_PID</varname> and
+    <varname>$LISTEN_FDNAMES</varname> environment variables before
+    returning (regardless of whether the function call itself
+    succeeded or not). Further calls to
+    <function>sd_listen_fds()</function> will then return zero, but the
+    variables are no longer inherited by child processes.</para>
+
+    <para><function>sd_listen_fds_with_names()</function> is like
+    <function>sd_listen_fds()</function>, but optionally also returns
+    an array of strings with identification names for the passed file
+    descriptors, if that is available and the
+    <parameter>names</parameter> parameter is non-<constant>NULL</constant>. This
+    information is read from the <varname>$LISTEN_FDNAMES</varname>
+    variable, which may contain a colon-separated list of names. For
+    socket-activated services, these names may be configured with the
+    <varname>FileDescriptorName=</varname> setting in socket unit
+    files, see
+    <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for details. For file descriptors pushed into the file descriptor
+    store (see above), the name is set via the
+    <varname>FDNAME=</varname> field transmitted via
+    <function>sd_pid_notify_with_fds()</function>. The primary use case
+    for these names are services which accept a variety of file
+    descriptors which are not recognizable with functions like
+    <function>sd_is_socket()</function> alone, and thus require
+    identification via a name. It is recommended to rely on named file
+    descriptors only if identification via
+    <function>sd_is_socket()</function> and related calls is not
+    sufficient. Note that the names used are not unique in any
+    way. The returned array of strings has as many entries as file
+    descriptors have been received, plus a final <constant>NULL</constant> pointer
+    terminating the array. The caller needs to free the array itself
+    and each of its elements with libc's <function>free()</function>
+    call after use. If the <parameter>names</parameter> parameter is
+    <constant>NULL</constant>, the call is entirely equivalent to
+    <function>sd_listen_fds()</function>.</para>
+
+    <para>Under specific conditions, the following automatic file
+    descriptor names are returned:
+
+    <table>
+      <title>
+         <command>Special names</command>
+      </title>
+
+      <tgroup cols='2'>
+        <thead>
+          <row>
+            <entry>Name</entry>
+            <entry>Description</entry>
+          </row>
+        </thead>
+        <tbody>
+          <row>
+            <entry><literal>unknown</literal></entry>
+            <entry>The process received no name for the specific file descriptor from the service manager.</entry>
+          </row>
+
+          <row>
+            <entry><literal>stored</literal></entry>
+            <entry>The file descriptor originates in the service manager's per-service file descriptor store, and the <varname>FDNAME=</varname> field was absent when the file descriptor was submitted to the service manager.</entry>
+          </row>
+
+          <row>
+            <entry><literal>connection</literal></entry>
+            <entry>The service was activated in per-connection style using <varname>Accept=yes</varname> in the socket unit file, and the file descriptor is the connection socket.</entry>
+          </row>
+        </tbody>
+      </tgroup>
+    </table>
+    </para>
+
+    <para>For further information on the file descriptor store see the <ulink
+    url="https://systemd.io/FILE_DESCRIPTOR_STORE">File Descriptor Store</ulink> overview.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On failure, these calls returns a negative errno-style error
+    code. If
+    <varname>$LISTEN_FDS</varname>/<varname>$LISTEN_PID</varname> was
+    not set or was not correctly set for this daemon and hence no file
+    descriptors were received, 0 is returned. Otherwise, the number of
+    file descriptors passed is returned. The application may find them
+    starting with file descriptor SD_LISTEN_FDS_START, i.e. file
+    descriptor 3.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Notes</title>
+
+    <xi:include href="libsystemd-pkgconfig.xml" xpointer="pkgconfig-text"/>
+    <xi:include href="threads-aware.xml" xpointer="getenv"/>
+
+    <para>Internally, <function>sd_listen_fds()</function> checks
+    whether the <varname>$LISTEN_PID</varname> environment variable
+    equals the daemon PID. If not, it returns immediately. Otherwise,
+    it parses the number passed in the <varname>$LISTEN_FDS</varname>
+    environment variable, then sets the FD_CLOEXEC flag for the parsed
+    number of file descriptors starting from SD_LISTEN_FDS_START.
+    Finally, it returns the parsed
+    number. <function>sd_listen_fds_with_names()</function> does the
+    same but also parses <varname>$LISTEN_FDNAMES</varname> if
+    set.</para>
+
+    <para>These functions are not designed for services that specify <varname>StandardInput=socket</varname>
+    as the <varname>$LISTEN_FDS</varname> variable is not set in their environment.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Environment</title>
+
+    <variablelist class='environment-variables'>
+      <varlistentry>
+        <term><varname>$LISTEN_PID</varname></term>
+        <term><varname>$LISTEN_FDS</varname></term>
+        <term><varname>$LISTEN_FDNAMES</varname></term>
+
+        <listitem><para>Set by the service manager for supervised
+        processes that use socket-based activation. This environment
+        variable specifies the data
+        <function>sd_listen_fds()</function> and
+        <function>sd_listen_fds_with_names()</function> parses. See
+        above for details.</para></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_listen_fds_with_names()</function> was added in version 227.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-daemon</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_is_fifo</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_is_socket</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_is_socket_inet</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_is_socket_unix</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_pid_notify_with_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>daemon</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_login_monitor_new.xml b/man/sd_login_monitor_new.xml
new file mode 100644
index 0000000..5b59e09
--- /dev/null
+++ b/man/sd_login_monitor_new.xml
@@ -0,0 +1,256 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_login_monitor_new" conditional='HAVE_PAM'
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_login_monitor_new</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_login_monitor_new</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_login_monitor_new</refname>
+    <refname>sd_login_monitor_unref</refname>
+    <refname>sd_login_monitor_unrefp</refname>
+    <refname>sd_login_monitor_flush</refname>
+    <refname>sd_login_monitor_get_fd</refname>
+    <refname>sd_login_monitor_get_events</refname>
+    <refname>sd_login_monitor_get_timeout</refname>
+    <refname>sd_login_monitor</refname>
+    <refpurpose>Monitor login sessions, seats, users and virtual machines/containers</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-login.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_login_monitor_new</function></funcdef>
+        <paramdef>const char *<parameter>category</parameter></paramdef>
+        <paramdef>sd_login_monitor **<parameter>ret</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>sd_login_monitor *<function>sd_login_monitor_unref</function></funcdef>
+        <paramdef>sd_login_monitor *<parameter>m</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>void <function>sd_login_monitor_unrefp</function></funcdef>
+        <paramdef>sd_login_monitor **<parameter>m</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_login_monitor_flush</function></funcdef>
+        <paramdef>sd_login_monitor *<parameter>m</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_login_monitor_get_fd</function></funcdef>
+        <paramdef>sd_login_monitor *<parameter>m</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_login_monitor_get_events</function></funcdef>
+        <paramdef>sd_login_monitor *<parameter>m</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_login_monitor_get_timeout</function></funcdef>
+        <paramdef>sd_login_monitor *<parameter>m</parameter></paramdef>
+        <paramdef>uint64_t *<parameter>timeout_usec</parameter></paramdef>
+      </funcprototype>
+
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_login_monitor_new()</function> may be used to
+    monitor login sessions, users, seats, and virtual
+    machines/containers. Via a monitor object a file descriptor can be
+    integrated into an application defined event loop which is woken
+    up each time a user logs in, logs out or a seat is added or
+    removed, or a session, user, seat or virtual machine/container
+    changes state otherwise. The first parameter takes a string which
+    can be <literal>seat</literal> (to get only notifications about
+    seats being added, removed or changed), <literal>session</literal>
+    (to get only notifications about sessions being created or removed
+    or changed), <literal>uid</literal> (to get only notifications
+    when a user changes state in respect to logins) or
+    <literal>machine</literal> (to get only notifications when a
+    virtual machine or container is started or stopped). If
+    notifications shall be generated in all these conditions,
+    <constant>NULL</constant> may be passed. Note that in the future
+    additional categories may be defined. The second parameter returns
+    a monitor object and needs to be freed with the
+    <function>sd_login_monitor_unref()</function> call after
+    use.</para>
+
+    <para><function>sd_login_monitor_unref()</function> may be used to
+    destroy a monitor object. Note that this will invalidate any file
+    descriptor returned by
+    <function>sd_login_monitor_get_fd()</function>.</para>
+
+    <para><function>sd_login_monitor_unrefp()</function> is similar to
+    <function>sd_login_monitor_unref()</function> but takes a pointer
+    to a pointer to an <type>sd_login_monitor</type> object. This call
+    is useful in conjunction with GCC's and LLVM's <ulink
+    url="https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html">Clean-up
+    Variable Attribute</ulink>. Note that this function is defined as
+    inline function. Use a declaration like the following, in order to
+    allocate a login monitor object that is freed automatically as the
+    code block is left:</para>
+
+    <programlisting>{
+  __attribute__((cleanup(sd_login_monitor_unrefp))) sd_login_monitor *m = NULL;
+  int r;
+  …
+  r = sd_login_monitor_new(NULL, &amp;m);
+  if (r &lt; 0) {
+    errno = -r;
+    fprintf(stderr, "Failed to allocate login monitor object: %m\n");
+  }
+  …
+}</programlisting>
+
+    <para><function>sd_login_monitor_flush()</function> may be used to
+    reset the wakeup state of the monitor object. Whenever an event
+    causes the monitor to wake up the event loop via the file
+    descriptor this function needs to be called to reset the wake-up
+    state. If this call is not invoked, the file descriptor will
+    immediately wake up the event loop again.</para>
+
+    <para><function>sd_login_monitor_unref()</function> and
+    <function>sd_login_monitor_unrefp()</function> execute no
+    operation if the passed in monitor object is
+    <constant>NULL</constant>.</para>
+
+    <para><function>sd_login_monitor_get_fd()</function> may be used
+    to retrieve the file descriptor of the monitor object that may be
+    integrated in an application defined event loop, based around
+    <citerefentry><refentrytitle>poll</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+    or a similar interface. The application should include the
+    returned file descriptor as wake-up source for the events mask
+    returned by <function>sd_login_monitor_get_events()</function>. It
+    should pass a timeout value as returned by
+    <function>sd_login_monitor_get_timeout()</function>. Whenever a
+    wake-up is triggered the file descriptor needs to be reset via
+    <function>sd_login_monitor_flush()</function>. An application
+    needs to reread the login state with a function like
+    <citerefentry><refentrytitle>sd_get_seats</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    or similar to determine what changed.</para>
+
+    <para><function>sd_login_monitor_get_events()</function> will
+    return the <function>poll()</function> mask to wait for. This
+    function will return a combination of <constant>POLLIN</constant>,
+    <constant>POLLOUT</constant> and similar to fill into the
+    <literal>.events</literal> field of <varname>struct
+    pollfd</varname>.</para>
+
+    <para><function>sd_login_monitor_get_timeout()</function> will
+    return a timeout value for usage in <function>poll()</function>.
+    This returns a value in microseconds since the epoch of
+    <constant>CLOCK_MONOTONIC</constant> for timing out
+    <function>poll()</function> in <varname>timeout_usec</varname>.
+    See
+    <citerefentry><refentrytitle>clock_gettime</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+    for details about <constant>CLOCK_MONOTONIC</constant>. If there
+    is no timeout to wait for this will fill in <constant>(uint64_t)
+    -1</constant> instead. Note that <function>poll()</function> takes
+    a relative timeout in milliseconds rather than an absolute timeout
+    in microseconds. To convert the absolute 'μs' timeout into
+    relative 'ms', use code like the following:</para>
+
+    <programlisting>uint64_t t;
+int msec;
+sd_login_monitor_get_timeout(m, &amp;t);
+if (t == (uint64_t) -1)
+  msec = -1;
+else {
+  struct timespec ts;
+  uint64_t n;
+  clock_gettime(CLOCK_MONOTONIC, &amp;ts);
+  n = (uint64_t) ts.tv_sec * 1000000 + ts.tv_nsec / 1000;
+  msec = t > n ? (int) ((t - n + 999) / 1000) : 0;
+}</programlisting>
+
+    <para>The code above does not do any error checking for brevity's
+    sake. The calculated <varname>msec</varname> integer can be passed
+    directly as <function>poll()</function>'s timeout
+    parameter.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success,
+    <function>sd_login_monitor_new()</function>,
+    <function>sd_login_monitor_flush()</function> and
+    <function>sd_login_monitor_get_timeout()</function>
+    return 0 or a positive integer. On success,
+    <function>sd_login_monitor_get_fd()</function> returns
+    a Unix file descriptor. On success,
+    <function>sd_login_monitor_get_events()</function>
+    returns a combination of <constant>POLLIN</constant>,
+    <constant>POLLOUT</constant> and suchlike. On failure,
+    these calls return a negative errno-style error
+    code.</para>
+
+    <para><function>sd_login_monitor_unref()</function>
+    always returns <constant>NULL</constant>.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>An input parameter was invalid (out of range, or <constant>NULL</constant>, where
+          that is not accepted). The specified category to watch is not known.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOMEM</constant></term>
+
+          <listitem><para>Memory allocation failed.</para></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_login_monitor_get_events()</function> and
+    <function>sd_login_monitor_get_timeout()</function> were added in version 201.</para>
+    <para><function>sd_login_monitor_unrefp()</function> was added in version 229.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-login</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_get_seats</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>poll</refentrytitle><manvolnum>2</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>clock_gettime</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_machine_get_class.xml b/man/sd_machine_get_class.xml
new file mode 100644
index 0000000..e09b8a9
--- /dev/null
+++ b/man/sd_machine_get_class.xml
@@ -0,0 +1,122 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_machine_get_class" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_machine_get_class</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_machine_get_class</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_machine_get_class</refname>
+    <refname>sd_machine_get_ifindices</refname>
+    <refpurpose>Determine the class and network interface indices of a
+    locally running virtual machine or container</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-login.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_machine_get_class</function></funcdef>
+        <paramdef>const char* <parameter>machine</parameter></paramdef>
+        <paramdef>char **<parameter>class</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_machine_get_ifindices</function></funcdef>
+        <paramdef>const char* <parameter>machine</parameter></paramdef>
+        <paramdef>int **<parameter>ret_ifindices</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_machine_get_class()</function> may be used to
+    determine the class of a locally running virtual machine or
+    container that is registered with
+    <citerefentry><refentrytitle>systemd-machined.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+    The string returned is either <literal>vm</literal> or
+    <literal>container</literal>. The returned string needs to be
+    freed with the libc <citerefentry
+    project='man-pages'><refentrytitle>free</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    call after use.</para>
+
+    <para><function>sd_machine_get_ifindices()</function> may be used to determine the numeric indices of the
+    network interfaces on the host that are pointing towards the specified locally running virtual machine or
+    container. The vm or container must be registered with
+    <citerefentry><refentrytitle>systemd-machined.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+    The output parameter <parameter>ret_ifindices</parameter> may be passed as <constant>NULL</constant> when
+    the output value is not needed. The returned array needs to be freed with the libc <citerefentry
+    project='man-pages'><refentrytitle>free</refentrytitle><manvolnum>3</manvolnum></citerefentry> call after
+    use.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, these functions return a non-negative integer.
+    <function>sd_machine_get_ifindices()</function> returns the number of the relevant network interfaces.
+    On failure, these calls return a negative errno-style error code.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+
+        <varlistentry>
+          <term><constant>-ENXIO</constant></term>
+
+          <listitem><para>The specified machine does not exist or is currently not running.</para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>An input parameter was invalid (out of range, or <constant>NULL</constant>, where
+          that is not accepted).</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOMEM</constant></term>
+
+          <listitem><para>Memory allocation failed.</para></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_machine_get_class()</function> and
+    <function>sd_machine_get_ifindices()</function> were added in version 217.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-login</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-machined.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_pid_get_machine_name</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_notify.xml b/man/sd_notify.xml
new file mode 100644
index 0000000..7c32a22
--- /dev/null
+++ b/man/sd_notify.xml
@@ -0,0 +1,589 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_notify"
+  xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_notify</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_notify</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_notify</refname>
+    <refname>sd_notifyf</refname>
+    <refname>sd_pid_notify</refname>
+    <refname>sd_pid_notifyf</refname>
+    <refname>sd_pid_notify_with_fds</refname>
+    <refname>sd_pid_notifyf_with_fds</refname>
+    <refname>sd_notify_barrier</refname>
+    <refname>sd_pid_notify_barrier</refname>
+    <refpurpose>Notify service manager about start-up completion and other service status changes</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-daemon.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_notify</function></funcdef>
+        <paramdef>int <parameter>unset_environment</parameter></paramdef>
+        <paramdef>const char *<parameter>state</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_notifyf</function></funcdef>
+        <paramdef>int <parameter>unset_environment</parameter></paramdef>
+        <paramdef>const char *<parameter>format</parameter></paramdef>
+        <paramdef>…</paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_pid_notify</function></funcdef>
+        <paramdef>pid_t <parameter>pid</parameter></paramdef>
+        <paramdef>int <parameter>unset_environment</parameter></paramdef>
+        <paramdef>const char *<parameter>state</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_pid_notifyf</function></funcdef>
+        <paramdef>pid_t <parameter>pid</parameter></paramdef>
+        <paramdef>int <parameter>unset_environment</parameter></paramdef>
+        <paramdef>const char *<parameter>format</parameter></paramdef>
+        <paramdef>…</paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_pid_notify_with_fds</function></funcdef>
+        <paramdef>pid_t <parameter>pid</parameter></paramdef>
+        <paramdef>int <parameter>unset_environment</parameter></paramdef>
+        <paramdef>const char *<parameter>state</parameter></paramdef>
+        <paramdef>const int *<parameter>fds</parameter></paramdef>
+        <paramdef>unsigned <parameter>n_fds</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_pid_notifyf_with_fds</function></funcdef>
+        <paramdef>pid_t <parameter>pid</parameter></paramdef>
+        <paramdef>int <parameter>unset_environment</parameter></paramdef>
+        <paramdef>const int *<parameter>fds</parameter></paramdef>
+        <paramdef>size_t <parameter>n_fds</parameter></paramdef>
+        <paramdef>const char *<parameter>format</parameter></paramdef>
+        <paramdef>…</paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_notify_barrier</function></funcdef>
+        <paramdef>int <parameter>unset_environment</parameter></paramdef>
+        <paramdef>uint64_t <parameter>timeout</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_pid_notify_barrier</function></funcdef>
+        <paramdef>pid_t <parameter>pid</parameter></paramdef>
+        <paramdef>int <parameter>unset_environment</parameter></paramdef>
+        <paramdef>uint64_t <parameter>timeout</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_notify()</function> may be called by a service to notify the service manager about
+    state changes. It can be used to send arbitrary information, encoded in an environment-block-like string.
+    Most importantly, it can be used for start-up or reload completion notifications.</para>
+
+    <para>If the <parameter>unset_environment</parameter> parameter is non-zero,
+    <function>sd_notify()</function> will unset the <varname>$NOTIFY_SOCKET</varname> environment variable
+    before returning (regardless of whether the function call itself succeeded or not). Further calls to
+    <function>sd_notify()</function> will then fail, and the variable is no longer inherited by child
+    processes.</para>
+
+    <para>The <parameter>state</parameter> parameter should contain a newline-separated list of variable
+    assignments, similar in style to an environment block. A trailing newline is implied if none is
+    specified. The string may contain any kind of variable assignments, but see the next section
+    for a list of assignments understood by the service manager.</para>
+
+    <para>Note that systemd will accept status data sent from a service only if the
+    <varname>NotifyAccess=</varname> option is correctly set in the service definition file. See
+    <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
+    details.</para>
+
+    <para>Note that <function>sd_notify()</function> notifications may be attributed to units correctly only
+    if either the sending process is still around at the time PID 1 processes the message, or if the sending
+    process is explicitly runtime-tracked by the service manager. The latter is the case if the service
+    manager originally forked off the process, i.e. on all processes that match
+    <varname>NotifyAccess=</varname><option>main</option> or
+    <varname>NotifyAccess=</varname><option>exec</option>. Conversely, if an auxiliary process of the unit
+    sends an <function>sd_notify()</function> message and immediately exits, the service manager might not be
+    able to properly attribute the message to the unit, and thus will ignore it, even if
+    <varname>NotifyAccess=</varname><option>all</option> is set for it.</para>
+
+    <para>Hence, to eliminate all race conditions involving lookup of the client's unit and attribution of
+    notifications to units correctly, <function>sd_notify_barrier()</function> may be used. This call acts as
+    a synchronization point and ensures all notifications sent before this call have been picked up by the
+    service manager when it returns successfully. Use of <function>sd_notify_barrier()</function> is needed
+    for clients which are not invoked by the service manager, otherwise this synchronization mechanism is
+    unnecessary for attribution of notifications to the unit.</para>
+
+    <para><function>sd_notifyf()</function> is similar to <function>sd_notify()</function> but takes a
+    <function>printf()</function>-like format string plus arguments.</para>
+
+    <para><function>sd_pid_notify()</function> and <function>sd_pid_notifyf()</function> are similar to
+    <function>sd_notify()</function> and <function>sd_notifyf()</function> but take a process ID (PID) to use
+    as originating PID for the message as first argument. This is useful to send notification messages on
+    behalf of other processes, provided the appropriate privileges are available. If the PID argument is
+    specified as 0, the process ID of the calling process is used, in which case the calls are fully
+    equivalent to <function>sd_notify()</function> and <function>sd_notifyf()</function>.</para>
+
+    <para><function>sd_pid_notify_with_fds()</function> is similar to <function>sd_pid_notify()</function>
+    but takes an additional array of file descriptors. These file descriptors are sent along the notification
+    message to the service manager. This is particularly useful for sending <literal>FDSTORE=1</literal>
+    messages, as described above. The additional arguments are a pointer to the file descriptor array plus
+    the number of file descriptors in the array. If the number of file descriptors is passed as 0, the call
+    is fully equivalent to <function>sd_pid_notify()</function>, i.e. no file descriptors are passed. Note
+    that file descriptors sent to the service manager on a message without <literal>FDSTORE=1</literal> are
+    immediately closed on reception.</para>
+
+    <para><function>sd_pid_notifyf_with_fds()</function> is a combination of
+    <function>sd_pid_notify_with_fds()</function> and <function>sd_notifyf()</function>, i.e. it accepts both
+    a PID and a set of file descriptors as input, and processes a format string to generate the state
+    string.</para>
+
+    <para><function>sd_notify_barrier()</function> allows the caller to synchronize against reception of
+    previously sent notification messages and uses the <varname>BARRIER=1</varname> command. It takes a
+    relative <varname>timeout</varname> value in microseconds which is passed to
+    <citerefentry><refentrytitle>ppoll</refentrytitle><manvolnum>2</manvolnum>
+    </citerefentry>. A value of UINT64_MAX is interpreted as infinite timeout.</para>
+
+    <para><function>sd_pid_notify_barrier()</function> is just like <function>sd_notify_barrier()</function>,
+    but allows specifying the originating PID for the notification message.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Well-known assignments</title>
+
+    <para>The following assignments have a defined meaning:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term>READY=1</term>
+
+        <listitem><para>Tells the service manager that service startup is finished, or the service finished
+        re-loading its configuration. This is only used by systemd if the service definition file has
+        <varname>Type=notify</varname> or <varname>Type=notify-reload</varname> set. Since there is little
+        value in signaling non-readiness, the only value services should send is <literal>READY=1</literal>
+        (i.e.  <literal>READY=0</literal> is not defined).</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term>RELOADING=1</term>
+
+        <listitem><para>Tells the service manager that the service is beginning to reload its configuration.
+        This is useful to allow the service manager to track the service's internal state, and present it to
+        the user. Note that a service that sends this notification must also send a
+        <literal>READY=1</literal> notification when it completed reloading its configuration. Reloads the
+        service manager is notified about with this mechanisms are propagated in the same way as they are
+        when originally initiated through the service manager. This message is particularly relevant for
+        <varname>Type=notify-reload</varname> services, to inform the service manager that the request to
+        reload the service has been received and is now being processed.</para>
+
+        <xi:include href="version-info.xml" xpointer="v217"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term>STOPPING=1</term>
+
+        <listitem><para>Tells the service manager that the service is beginning its shutdown. This is useful
+        to allow the service manager to track the service's internal state, and present it to the user.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v217"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term>MONOTONIC_USEC=…</term>
+
+        <listitem><para>A field carrying the monotonic timestamp (as per
+        <constant>CLOCK_MONOTONIC</constant>) formatted in decimal in μs, when the notification message was
+        generated by the client. This is typically used in combination with <literal>RELOADING=1</literal>,
+        to allow the service manager to properly synchronize reload cycles. See
+        <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for details, specifically <literal>Type=notify-reload</literal>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v253"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term>STATUS=…</term>
+
+        <listitem><para>Passes a single-line UTF-8 status string back to the service manager that describes
+        the service state. This is free-form and can be used for various purposes: general state feedback,
+        fsck-like programs could pass completion percentages and failing programs could pass a human-readable
+        error message. Example: <literal>STATUS=Completed 66% of file system check…</literal></para>
+
+        <xi:include href="version-info.xml" xpointer="v233"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term>NOTIFYACCESS=…</term>
+
+        <listitem><para>Reset the access to the service status notification socket during runtime, overriding
+        <varname>NotifyAccess=</varname> setting in the service unit file. See
+        <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for details, specifically <literal>NotifyAccess=</literal> for a list of accepted values.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term>ERRNO=…</term>
+
+        <listitem><para>If a service fails, the errno-style error code, formatted as string. Example:
+        <literal>ERRNO=2</literal> for ENOENT.</para>
+
+        <xi:include href="version-info.xml" xpointer="v233"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term>BUSERROR=…</term>
+
+        <listitem><para>If a service fails, the D-Bus error-style error code. Example:
+        <literal>BUSERROR=org.freedesktop.DBus.Error.TimedOut</literal>. Note that this assignment is
+        currently not used by <command>systemd</command>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v233"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term>EXIT_STATUS=…</term>
+
+        <listitem><para>The exit status of a service or the manager itself. Note that
+        <command>systemd</command> currently does not consume this value when sent by services, so this
+        assignment is only informational. The manager will send this notification to <emphasis>its</emphasis>
+        notification socket, which may be used to to collect an exit status from the system (a container or
+        VM) as it shuts down. For example,
+        <citerefentry project='debian'><refentrytitle>mkosi</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+        makes use of this. The value to return may be set via the
+        <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+        <command>exit</command> verb.</para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term>MAINPID=…</term>
+
+        <listitem><para>The main process ID (PID) of the service, in case the service manager did not fork
+        off the process itself. Example: <literal>MAINPID=4711</literal>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v233"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term>WATCHDOG=1</term>
+
+        <listitem><para>Tells the service manager to update the watchdog timestamp. This is the keep-alive
+        ping that services need to issue in regular intervals if <varname>WatchdogSec=</varname> is enabled
+        for it. See
+        <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for information how to enable this functionality and
+        <citerefentry><refentrytitle>sd_watchdog_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+        for the details of how the service can check whether the watchdog is enabled. </para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term>WATCHDOG=trigger</term>
+
+        <listitem><para>Tells the service manager that the service detected an internal error that should be
+        handled by the configured watchdog options. This will trigger the same behaviour as if
+        <varname>WatchdogSec=</varname> is enabled and the service did not send <literal>WATCHDOG=1</literal>
+        in time. Note that <varname>WatchdogSec=</varname> does not need to be enabled for
+        <literal>WATCHDOG=trigger</literal> to trigger the watchdog action. See
+        <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for information about the watchdog behavior. </para>
+
+        <xi:include href="version-info.xml" xpointer="v243"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term>WATCHDOG_USEC=…</term>
+
+        <listitem><para>Reset <varname>watchdog_usec</varname> value during runtime.  Notice that this is not
+        available when using <function>sd_event_set_watchdog()</function> or
+        <function>sd_watchdog_enabled()</function>.  Example :
+        <literal>WATCHDOG_USEC=20000000</literal></para>
+
+        <xi:include href="version-info.xml" xpointer="v233"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term>EXTEND_TIMEOUT_USEC=…</term>
+
+        <listitem><para>Tells the service manager to extend the startup, runtime or shutdown service timeout
+        corresponding the current state. The value specified is a time in microseconds during which the
+        service must send a new message. A service timeout will occur if the message isn't received, but only
+        if the runtime of the current state is beyond the original maximum times of
+        <varname>TimeoutStartSec=</varname>, <varname>RuntimeMaxSec=</varname>, and
+        <varname>TimeoutStopSec=</varname>.  See
+        <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for effects on the service timeouts.</para>
+
+        <xi:include href="version-info.xml" xpointer="v236"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term>FDSTORE=1</term>
+
+        <listitem><para>Store file descriptors in the service manager. File descriptors sent this way will be
+        held for the service by the service manager and will later be handed back using the usual file
+        descriptor passing logic at the next start or restart of the service, see
+        <citerefentry><refentrytitle>sd_listen_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+        Any open sockets and other file descriptors which should not be closed during a restart may be stored
+        this way. When a service is stopped, its file descriptor store is discarded and all file descriptors
+        in it are closed, except when overridden with <varname>FileDescriptorStorePreserve=</varname>, see
+        <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+        </para>
+
+        <para>The service manager will accept messages for a service only if its
+        <varname>FileDescriptorStoreMax=</varname> setting is non-zero (defaults to zero, see
+        <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
+        The service manager will set the <varname>$FDSTORE</varname> environment variable for services that
+        have the file descriptor store enabled, see
+        <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+        </para>
+
+        <para>If <varname>FDPOLL=0</varname> is not set and the file descriptors are pollable (see
+        <citerefentry><refentrytitle>epoll_ctl</refentrytitle><manvolnum>2</manvolnum></citerefentry>), then
+        any <constant>EPOLLHUP</constant> or <constant>EPOLLERR</constant> event seen on them will result in
+        their automatic removal from the store.</para>
+
+        <para>Multiple sets of file descriptors may be sent in separate messages, in which case the sets are
+        combined. The service manager removes duplicate file descriptors (those pointing to the same object)
+        before passing them to the service.</para>
+
+        <para>This functionality should be used to implement services that can restart after an explicit
+        request or a crash without losing state. Application state can either be serialized to a file in
+        <filename>/run/</filename>, or better, stored in a
+        <citerefentry><refentrytitle>memfd_create</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+        memory file descriptor. Use <function>sd_pid_notify_with_fds()</function> to send messages with
+        <literal>FDSTORE=1</literal>. It is recommended to combine <varname>FDSTORE=</varname> with
+        <varname>FDNAME=</varname> to make it easier to manage the stored file descriptors.</para>
+
+        <para>For further information on the file descriptor store see the <ulink
+        url="https://systemd.io/FILE_DESCRIPTOR_STORE">File Descriptor Store</ulink> overview.</para>
+
+        <xi:include href="version-info.xml" xpointer="v219"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term>FDSTOREREMOVE=1</term>
+
+        <listitem><para>Removes file descriptors from the file descriptor store. This field needs to be
+        combined with <varname>FDNAME=</varname> to specify the name of the file descriptors to
+        remove.</para>
+
+        <xi:include href="version-info.xml" xpointer="v236"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term>FDNAME=…</term>
+
+        <listitem><para>When used in combination with <varname>FDSTORE=1</varname>, specifies a name for the
+        submitted file descriptors. When used with <varname>FDSTOREREMOVE=1</varname>, specifies the name for
+        the file descriptors to remove. This name is passed to the service during activation, and may be
+        queried using
+        <citerefentry><refentrytitle>sd_listen_fds_with_names</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+        File descriptors submitted without this field will be called <literal>stored</literal>.</para>
+
+        <para>The name may consist of arbitrary ASCII characters except control characters or
+        <literal>:</literal>. It may not be longer than 255 characters. If a submitted name does not follow
+        these restrictions, it is ignored.</para>
+
+        <para>Note that if multiple file descriptors are submitted in a single message, the specified name
+        will be used for all of them. In order to assign different names to submitted file descriptors,
+        submit them in separate messages.</para>
+
+        <xi:include href="version-info.xml" xpointer="v233"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term>FDPOLL=0</term>
+
+        <listitem><para>When used in combination with <varname>FDSTORE=1</varname>, disables polling of the
+        stored file descriptors regardless of whether or not they are pollable. As this option disables
+        automatic cleanup of the stored file descriptors on EPOLLERR and EPOLLHUP, care must be taken to
+        ensure proper manual cleanup.  Use of this option is not generally recommended except for when
+        automatic cleanup has unwanted behavior such as prematurely discarding file descriptors from the
+        store.</para>
+
+        <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term>BARRIER=1</term>
+
+        <listitem><para>Tells the service manager that the client is explicitly requesting synchronization by
+        means of closing the file descriptor sent with this command. The service manager guarantees that the
+        processing of a <varname>BARRIER=1</varname> command will only happen after all previous notification
+        messages sent before this command have been processed. Hence, this command accompanied with a single
+        file descriptor can be used to synchronize against reception of all previous status messages. Note
+        that this command cannot be mixed with other notifications, and has to be sent in a separate message
+        to the service manager, otherwise all assignments will be ignored. Note that sending 0 or more than 1
+        file descriptor with this command is a violation of the protocol.</para>
+
+        <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+      </varlistentry>
+    </variablelist>
+
+    <para>The notification messages sent by services are interpreted by the service manager. Unknown
+    assignments may be logged, but are otherwise ignored. Thus, it is not useful to send assignments which
+    are not in this list. The service manager also sends some messages to <emphasis>its</emphasis>
+    notification socket, which are then consumed by the machine or container manager.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On failure, these calls return a negative errno-style error code. If
+    <varname>$NOTIFY_SOCKET</varname> was not set and hence no status message could be sent, 0 is
+    returned. If the status was sent, these functions return a positive value. In order to support both
+    service managers that implement this scheme and those which do not, it is generally recommended to ignore
+    the return value of this call. Note that the return value simply indicates whether the notification
+    message was enqueued properly, it does not reflect whether the message could be processed
+    successfully. Specifically, no error is returned when a file descriptor is attempted to be stored using
+    <varname>FDSTORE=1</varname> but the service is not actually configured to permit storing of file
+    descriptors (see above).</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Notes</title>
+
+    <xi:include href="libsystemd-pkgconfig.xml" xpointer="pkgconfig-text"/>
+    <xi:include href="threads-aware.xml" xpointer="getenv"/>
+
+    <para>These functions send a single datagram with the state string as payload to the socket referenced in
+    the <varname>$NOTIFY_SOCKET</varname> environment variable. If the first character of
+    <varname>$NOTIFY_SOCKET</varname> is <literal>/</literal> or <literal>@</literal>, the string is
+    understood as an <constant>AF_UNIX</constant> or Linux abstract namespace socket (respectively), and in
+    both cases the datagram is accompanied by the process credentials of the sending service, using
+    SCM_CREDENTIALS. If the string starts with <literal>vsock:</literal> then the string is understood as an
+    <constant>AF_VSOCK</constant> address, which is useful for hypervisors/VMMs or other processes on the
+    host to receive a notification when a virtual machine has finished booting. Note that in case the
+    hypervisor does not support <constant>SOCK_DGRAM</constant> over <constant>AF_VSOCK</constant>,
+    <constant>SOCK_SEQPACKET</constant> will be used instead. The address should be in the form:
+    <literal>vsock:CID:PORT</literal>. Note that unlike other uses of vsock, the CID is mandatory and cannot
+    be <literal>VMADDR_CID_ANY</literal>.  Note that PID1 will send the VSOCK packets from a privileged port
+    (i.e.: lower than 1024), as an attempt to address concerns that unprivileged processes in the guest might
+    try to send malicious notifications to the host, driving it to make destructive decisions based on
+    them.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Environment</title>
+
+    <variablelist class='environment-variables'>
+      <varlistentry>
+        <term><varname>$NOTIFY_SOCKET</varname></term>
+
+        <listitem><para>Set by the service manager for supervised processes for status and start-up
+        completion notification.  This environment variable specifies the socket
+        <function>sd_notify()</function> talks to. See above for details.</para></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Examples</title>
+
+    <example>
+      <title>Start-up Notification</title>
+
+      <para>When a service finished starting up, it might issue the following call to notify the service
+      manager:</para>
+
+      <programlisting>sd_notify(0, "READY=1");</programlisting>
+    </example>
+
+    <example>
+      <title>Extended Start-up Notification</title>
+
+      <para>A service could send the following after completing initialization:</para>
+
+      <programlisting>
+sd_notifyf(0, "READY=1\n"
+           "STATUS=Processing requests…\n"
+           "MAINPID=%lu",
+           (unsigned long) getpid());</programlisting>
+    </example>
+
+    <example>
+      <title>Error Cause Notification</title>
+
+      <para>A service could send the following shortly before exiting, on failure:</para>
+
+      <programlisting>
+sd_notifyf(0, "STATUS=Failed to start up: %s\n"
+           "ERRNO=%i",
+           strerror_r(errnum, (char[1024]){}, 1024),
+           errnum);</programlisting>
+    </example>
+
+    <example>
+      <title>Store a File Descriptor in the Service Manager</title>
+
+      <para>To store an open file descriptor in the service manager, in order to continue operation after a
+      service restart without losing state, use <literal>FDSTORE=1</literal>:</para>
+
+      <programlisting>sd_pid_notify_with_fds(0, 0, "FDSTORE=1\nFDNAME=foobar", &amp;fd, 1);</programlisting>
+    </example>
+
+    <example>
+      <title>Eliminating race conditions</title>
+
+      <para>When the client sending the notifications is not spawned by the service manager, it may exit too
+      quickly and the service manager may fail to attribute them correctly to the unit. To prevent such
+      races, use <function>sd_notify_barrier()</function> to synchronize against reception of all
+      notifications sent before this call is made.</para>
+
+      <programlisting>
+sd_notify(0, "READY=1");
+/* set timeout to 5 seconds */
+sd_notify_barrier(0, 5 * 1000000);
+      </programlisting>
+    </example>
+  </refsect1>
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_pid_notify()</function>,
+    <function>sd_pid_notifyf()</function>, and
+    <function>sd_pid_notify_with_fds()</function> were added in version 219.</para>
+    <para><function>sd_notify_barrier()</function> was added in version 246.</para>
+    <para><function>sd_pid_notifyf_with_fds()</function> and
+    <function>sd_pid_notify_barrier()</function> were added in version 254.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-daemon</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_listen_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_listen_fds_with_names</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_watchdog_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>daemon</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_path_lookup.xml b/man/sd_path_lookup.xml
new file mode 100644
index 0000000..cb07303
--- /dev/null
+++ b/man/sd_path_lookup.xml
@@ -0,0 +1,235 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_path_lookup" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_path_lookup</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_path_lookup</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_path_lookup</refname>
+    <refname>sd_path_lookup_strv</refname>
+
+    <refpurpose>Query well-known file system paths</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-path.h&gt;</funcsynopsisinfo>
+
+      <!-- note: individual constants are not added as <refname>s, there's just too many -->
+
+      <funcsynopsisinfo><token>enum</token> {
+        <constant>SD_PATH_TEMPORARY</constant>,
+        <constant>SD_PATH_TEMPORARY_LARGE</constant>,
+
+        <constant>SD_PATH_SYSTEM_BINARIES</constant>,
+        <constant>SD_PATH_SYSTEM_INCLUDE</constant>,
+        <constant>SD_PATH_SYSTEM_LIBRARY_PRIVATE</constant>,
+        <constant>SD_PATH_SYSTEM_LIBRARY_ARCH</constant>,
+        <constant>SD_PATH_SYSTEM_SHARED</constant>,
+        <constant>SD_PATH_SYSTEM_CONFIGURATION_FACTORY</constant>,
+        <constant>SD_PATH_SYSTEM_STATE_FACTORY</constant>,
+
+        <constant>SD_PATH_SYSTEM_CONFIGURATION</constant>,
+        <constant>SD_PATH_SYSTEM_RUNTIME</constant>,
+        <constant>SD_PATH_SYSTEM_RUNTIME_LOGS</constant>,
+        <constant>SD_PATH_SYSTEM_STATE_PRIVATE</constant>,
+        <constant>SD_PATH_SYSTEM_STATE_LOGS</constant>,
+        <constant>SD_PATH_SYSTEM_STATE_CACHE</constant>,
+        <constant>SD_PATH_SYSTEM_STATE_SPOOL</constant>,
+
+        <constant>SD_PATH_USER_BINARIES</constant>,
+        <constant>SD_PATH_USER_LIBRARY_PRIVATE</constant>,
+        <constant>SD_PATH_USER_LIBRARY_ARCH</constant>,
+        <constant>SD_PATH_USER_SHARED</constant>,
+
+        <constant>SD_PATH_USER_CONFIGURATION</constant>,
+        <constant>SD_PATH_USER_RUNTIME</constant>,
+        <constant>SD_PATH_USER_STATE_PRIVATE</constant>,
+        <constant>SD_PATH_USER_STATE_CACHE</constant>,
+
+        <constant>SD_PATH_USER</constant>,
+        <constant>SD_PATH_USER_DOCUMENTS</constant>,
+        <constant>SD_PATH_USER_MUSIC</constant>,
+        <constant>SD_PATH_USER_PICTURES</constant>,
+        <constant>SD_PATH_USER_VIDEOS</constant>,
+        <constant>SD_PATH_USER_DOWNLOAD</constant>,
+        <constant>SD_PATH_USER_PUBLIC</constant>,
+        <constant>SD_PATH_USER_TEMPLATES</constant>,
+        <constant>SD_PATH_USER_DESKTOP</constant>,
+
+        <constant>SD_PATH_SEARCH_BINARIES</constant>,
+        <constant>SD_PATH_SEARCH_BINARIES_DEFAULT</constant>,
+        <constant>SD_PATH_SEARCH_LIBRARY_PRIVATE</constant>,
+        <constant>SD_PATH_SEARCH_LIBRARY_ARCH</constant>,
+        <constant>SD_PATH_SEARCH_SHARED</constant>,
+        <constant>SD_PATH_SEARCH_CONFIGURATION_FACTORY</constant>,
+        <constant>SD_PATH_SEARCH_STATE_FACTORY</constant>,
+        <constant>SD_PATH_SEARCH_CONFIGURATION</constant>,
+
+        <constant>SD_PATH_SYSTEMD_UTIL</constant>,
+        <constant>SD_PATH_SYSTEMD_SYSTEM_UNIT</constant>,
+        <constant>SD_PATH_SYSTEMD_SYSTEM_PRESET</constant>,
+        <constant>SD_PATH_SYSTEMD_USER_UNIT</constant>,
+        <constant>SD_PATH_SYSTEMD_USER_PRESET</constant>,
+        <constant>SD_PATH_SYSTEMD_SYSTEM_CONF</constant>,
+        <constant>SD_PATH_SYSTEMD_USER_CONF</constant>,
+        <constant>SD_PATH_SYSTEMD_SEARCH_SYSTEM_UNIT</constant>,
+        <constant>SD_PATH_SYSTEMD_SEARCH_USER_UNIT</constant>,
+        <constant>SD_PATH_SYSTEMD_SYSTEM_GENERATOR</constant>,
+        <constant>SD_PATH_SYSTEMD_USER_GENERATOR</constant>,
+        <constant>SD_PATH_SYSTEMD_SEARCH_SYSTEM_GENERATOR</constant>,
+        <constant>SD_PATH_SYSTEMD_SEARCH_USER_GENERATOR</constant>,
+        <constant>SD_PATH_SYSTEMD_SLEEP</constant>,
+        <constant>SD_PATH_SYSTEMD_SHUTDOWN</constant>,
+
+        <constant>SD_PATH_TMPFILES</constant>,
+        <constant>SD_PATH_SYSUSERS</constant>,
+        <constant>SD_PATH_SYSCTL</constant>,
+        <constant>SD_PATH_BINFMT</constant>,
+        <constant>SD_PATH_MODULES_LOAD</constant>,
+        <constant>SD_PATH_CATALOG</constant>,
+
+        <constant>SD_PATH_SYSTEMD_SEARCH_NETWORK</constant>,
+
+        <constant>SD_PATH_SYSTEMD_SYSTEM_ENVIRONMENT_GENERATOR</constant>,
+        <constant>SD_PATH_SYSTEMD_USER_ENVIRONMENT_GENERATOR</constant>,
+        <constant>SD_PATH_SYSTEMD_SEARCH_SYSTEM_ENVIRONMENT_GENERATOR</constant>,
+        <constant>SD_PATH_SYSTEMD_SEARCH_USER_ENVIRONMENT_GENERATOR</constant>,
+};</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_path_lookup</function></funcdef>
+        <paramdef>uint64_t <parameter>type</parameter></paramdef>
+        <paramdef>const char *<parameter>suffix</parameter></paramdef>
+        <paramdef>char **<parameter>paths</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_path_lookup_strv</function></funcdef>
+        <paramdef>uint64_t <parameter>type</parameter></paramdef>
+        <paramdef>const char *<parameter>suffix</parameter></paramdef>
+        <paramdef>char ***<parameter>paths</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_path_lookup()</function> and <function>sd_bus_path_lookup_strv()</function> return a
+    single path or set of file system paths specified by the argument <parameter>type</parameter>. In case of
+    <function>sd_path_lookup()</function> a single <constant>NUL</constant>-terminated string is returned.
+    When <parameter>type</parameter> specifies a set of paths, they are concatenated using
+    <literal>:</literal> as a separator (as is traditionally done for e.g. <varname>$PATH</varname> or
+    <varname>$LD_LIBRARY_PATH</varname>). In case of <function>sd_path_lookup_strv()</function> a
+    <constant>NULL</constant>-terminated array of strings is returned (strv). If suffix
+    <parameter>suffix</parameter> is given, it is concatenated to each of the paths after a slash
+    (<literal>/</literal>). All returned paths are absolute.</para>
+
+    <para>For paths which refer to user directories, the relevant XDG standard is followed, with support for
+    environment variables like <varname>$XDG_DOCUMENTS_DIR</varname>, <varname>$XDG_DESKTOP_DIR</varname>,
+    ..., and explicit configuration in <filename>/etc/xdg/user-dirs.conf</filename> or
+    <filename>${XDG_CONFIG_HOME}/user-dirs.dirs</filename>. See
+    <ulink url="https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html">
+      XDG Base Directory Specification</ulink> for details.</para>
+
+    <para><citerefentry><refentrytitle>systemd-path</refentrytitle><manvolnum>1</manvolnum></citerefentry> is
+    a wrapper around <function>sd_path_lookup()</function> and allows the same set of paths to be queried.
+    </para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, <function>sd_path_lookup()</function> and <function>sd_path_lookup_strv()</function>
+    return a non-negative integer. On failure, a negative errno-style error number is returned by either
+    function.</para>
+
+    <para>The returned string or string array (strv) must be
+    <citerefentry project='man-pages'><refentrytitle>free</refentrytitle><manvolnum>3</manvolnum></citerefentry>'d by the
+    caller.</para>
+
+    <refsect2 id='errors'>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><constant>-EOPNOTSUPP</constant></term>
+
+          <listitem><para>Unknown identifier <parameter>type</parameter>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>Output argument is <constant>NULL</constant>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENXIO</constant></term>
+
+          <listitem><para>Query failed because of an undefined environment variable (e.g. for
+          <constant>SD_PATH_USER_RUNTIME</constant> when <varname>$XDG_RUNTIME_DIR</varname> is not
+          defined).</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOMEM</constant></term>
+
+          <listitem><para>Memory allocation failed.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <refsect1>
+    <title>Examples</title>
+
+    <refsect2>
+      <title>Look up the location of ~/Documents</title>
+
+      <programlisting><xi:include href="path-documents.c" parse="text" /></programlisting>
+      <para>Note that the default answer of <filename index='false'>$HOME/Documents</filename> may be
+      overridden by <filename index='false'>user-dirs.conf</filename> or
+      <varname>$XDG_DOCUMENTS_DIR</varname>.</para>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_path_lookup()</function> and
+    <function>sd_path_lookup_strv()</function> were added in version 246.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd-path</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_pid_get_owner_uid.xml b/man/sd_pid_get_owner_uid.xml
new file mode 100644
index 0000000..4667e28
--- /dev/null
+++ b/man/sd_pid_get_owner_uid.xml
@@ -0,0 +1,410 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_pid_get_owner_uid" conditional='HAVE_PAM'
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_pid_get_owner_uid</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_pid_get_owner_uid</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_pid_get_owner_uid</refname>
+    <refname>sd_pid_get_session</refname>
+    <refname>sd_pid_get_user_unit</refname>
+    <refname>sd_pid_get_unit</refname>
+    <refname>sd_pid_get_machine_name</refname>
+    <refname>sd_pid_get_slice</refname>
+    <refname>sd_pid_get_user_slice</refname>
+    <refname>sd_pid_get_cgroup</refname>
+    <refname>sd_pidfd_get_owner_uid</refname>
+    <refname>sd_pidfd_get_session</refname>
+    <refname>sd_pidfd_get_user_unit</refname>
+    <refname>sd_pidfd_get_unit</refname>
+    <refname>sd_pidfd_get_machine_name</refname>
+    <refname>sd_pidfd_get_slice</refname>
+    <refname>sd_pidfd_get_user_slice</refname>
+    <refname>sd_pidfd_get_cgroup</refname>
+    <refname>sd_peer_get_owner_uid</refname>
+    <refname>sd_peer_get_session</refname>
+    <refname>sd_peer_get_user_unit</refname>
+    <refname>sd_peer_get_unit</refname>
+    <refname>sd_peer_get_machine_name</refname>
+    <refname>sd_peer_get_slice</refname>
+    <refname>sd_peer_get_user_slice</refname>
+    <refname>sd_peer_get_cgroup</refname>
+    <refpurpose>Determine the owner uid of the user unit or session,
+    or the session, user unit, system unit, container/VM or slice that
+    a specific PID or socket peer belongs to</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-login.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_pid_get_owner_uid</function></funcdef>
+        <paramdef>pid_t <parameter>pid</parameter></paramdef>
+        <paramdef>uid_t *<parameter>uid</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_pid_get_session</function></funcdef>
+        <paramdef>pid_t <parameter>pid</parameter></paramdef>
+        <paramdef>char **<parameter>session</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_pid_get_user_unit</function></funcdef>
+        <paramdef>pid_t <parameter>pid</parameter></paramdef>
+        <paramdef>char **<parameter>unit</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_pid_get_unit</function></funcdef>
+        <paramdef>pid_t <parameter>pid</parameter></paramdef>
+        <paramdef>char **<parameter>unit</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_pid_get_machine_name</function></funcdef>
+        <paramdef>pid_t <parameter>pid</parameter></paramdef>
+        <paramdef>char **<parameter>name</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_pid_get_slice</function></funcdef>
+        <paramdef>pid_t <parameter>pid</parameter></paramdef>
+        <paramdef>char **<parameter>slice</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_pid_get_user_slice</function></funcdef>
+        <paramdef>pid_t <parameter>pid</parameter></paramdef>
+        <paramdef>char **<parameter>slice</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_pid_get_cgroup</function></funcdef>
+        <paramdef>pid_t <parameter>pid</parameter></paramdef>
+        <paramdef>char **<parameter>cgroup</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_pidfd_get_owner_uid</function></funcdef>
+        <paramdef>int <parameter>pidfd</parameter></paramdef>
+        <paramdef>uid_t *<parameter>uid</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_pidfd_get_session</function></funcdef>
+        <paramdef>int <parameter>pidfd</parameter></paramdef>
+        <paramdef>char **<parameter>session</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_pidfd_get_user_unit</function></funcdef>
+        <paramdef>int <parameter>pidfd</parameter></paramdef>
+        <paramdef>char **<parameter>unit</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_pidfd_get_unit</function></funcdef>
+        <paramdef>int <parameter>pidfd</parameter></paramdef>
+        <paramdef>char **<parameter>unit</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_pidfd_get_machine_name</function></funcdef>
+        <paramdef>int <parameter>pidfd</parameter></paramdef>
+        <paramdef>char **<parameter>name</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_pidfd_get_slice</function></funcdef>
+        <paramdef>int <parameter>pidfd</parameter></paramdef>
+        <paramdef>char **<parameter>slice</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_pidfd_get_user_slice</function></funcdef>
+        <paramdef>int <parameter>pidfd</parameter></paramdef>
+        <paramdef>char **<parameter>slice</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_pidfd_get_cgroup</function></funcdef>
+        <paramdef>int <parameter>pidfd</parameter></paramdef>
+        <paramdef>char **<parameter>cgroup</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_peer_get_owner_uid</function></funcdef>
+        <paramdef>int <parameter>fd</parameter></paramdef>
+        <paramdef>uid_t *<parameter>uid</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_peer_get_session</function></funcdef>
+        <paramdef>int <parameter>fd</parameter></paramdef>
+        <paramdef>char **<parameter>session</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_peer_get_user_unit</function></funcdef>
+        <paramdef>int <parameter>fd</parameter></paramdef>
+        <paramdef>char **<parameter>unit</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_peer_get_unit</function></funcdef>
+        <paramdef>int <parameter>fd</parameter></paramdef>
+        <paramdef>char **<parameter>unit</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_peer_get_machine_name</function></funcdef>
+        <paramdef>int <parameter>fd</parameter></paramdef>
+        <paramdef>char **<parameter>name</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_peer_get_slice</function></funcdef>
+        <paramdef>int <parameter>fd</parameter></paramdef>
+        <paramdef>char **<parameter>slice</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_peer_get_user_slice</function></funcdef>
+        <paramdef>int <parameter>fd</parameter></paramdef>
+        <paramdef>char **<parameter>slice</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_peer_get_cgroup</function></funcdef>
+        <paramdef>int <parameter>fd</parameter></paramdef>
+        <paramdef>char **<parameter>cgroup</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_pid_get_owner_uid()</function> may be used to
+    determine the Unix UID (user identifier) which owns the login
+    session or systemd user unit of a process identified by the
+    specified PID. For processes which are not part of a login session
+    and not managed by a user manager, this function will fail with
+    <constant>-ENODATA</constant>.</para>
+
+    <para><function>sd_pid_get_session()</function> may be used to
+    determine the login session identifier of a process identified by
+    the specified process identifier. The session identifier is a
+    short string, suitable for usage in file system paths. Please
+    note the login session may be limited to a stub process or two.
+    User processes may instead be started from their systemd user
+    manager, e.g. GUI applications started using DBus activation, as
+    well as service processes which are shared between multiple logins
+    of the same user. For processes which are not part of a login
+    session, this function will fail with <constant>-ENODATA</constant>.
+    The returned string needs to be freed with the libc <citerefentry
+    project='man-pages'><refentrytitle>free</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    call after use.</para>
+
+    <para><function>sd_pid_get_user_unit()</function> may be used to
+    determine the systemd user unit (i.e. user service or scope unit)
+    identifier of a process identified by the specified PID. The
+    unit name is a short string, suitable for usage in file system
+    paths. For processes which are not managed by a user manager, this
+    function will fail with <constant>-ENODATA</constant>. The
+    returned string needs to be freed with the libc <citerefentry
+    project='man-pages'><refentrytitle>free</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    call after use.</para>
+
+    <para><function>sd_pid_get_unit()</function> may be used to
+    determine the systemd system unit (i.e. system service or scope
+    unit) identifier of a process identified by the specified PID. The
+    unit name is a short string, suitable for usage in file system
+    paths.  Note that not all processes are part of a system
+    unit/service. For processes not being part of a systemd system
+    unit, this function will fail with <constant>-ENODATA</constant>.
+    (More specifically, this call will not work for kernel threads.)
+    The returned string needs to be freed with the libc <citerefentry
+    project='man-pages'><refentrytitle>free</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    call after use.</para>
+
+    <para><function>sd_pid_get_machine_name()</function> may be used
+    to determine the name of the VM or container is a member of. The
+    machine name is a short string, suitable for usage in file system
+    paths. The returned string needs to be freed with the libc
+    <citerefentry
+    project='man-pages'><refentrytitle>free</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    call after use. For processes not part of a VM or container, this
+    function fails with <constant>-ENODATA</constant>.</para>
+
+    <para><function>sd_pid_get_slice()</function> may be used to
+    determine the slice unit the process is a member of. See
+    <citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for details about slices. The returned string needs to be freed
+    with the libc
+    <citerefentry project='man-pages'><refentrytitle>free</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    call after use.</para>
+
+    <para>Similarly, <function>sd_pid_get_user_slice()</function>
+    returns the user slice (as managed by the user's systemd instance)
+    of a process.</para>
+
+    <para><function>sd_pid_get_cgroup()</function> returns the control
+    group path of the specified process, relative to the root of the
+    hierarchy. Returns the path without trailing slash, except for
+    processes located in the root control group, where "/" is
+    returned. To find the actual control group path in the file system,
+    the returned path needs to be prefixed with
+    <filename>/sys/fs/cgroup/</filename> (if the unified control group
+    setup is used), or
+    <filename>/sys/fs/cgroup/<replaceable>HIERARCHY</replaceable>/</filename>
+    (if the legacy multi-hierarchy control group setup is used).</para>
+
+    <para>If the <varname>pid</varname> parameter of any of these
+    functions is passed as 0, the operation is executed for the
+    calling process.</para>
+
+    <para>The <function>sd_pidfd_get_owner_uid()</function>,
+    <function>sd_pidfd_get_session()</function>,
+    <function>sd_pidfd_get_user_unit()</function>,
+    <function>sd_pidfd_get_unit()</function>,
+    <function>sd_pidfd_get_machine_name()</function>,
+    <function>sd_pidfd_get_slice()</function>,
+    <function>sd_pidfd_get_user_slice()</function> and
+    <function>sd_pidfd_get_cgroup()</function> calls operate similarly to their PID counterparts, but accept a
+    <constant>PIDFD</constant> instead of a <constant>PID</constant>, which means they are not subject to recycle
+    race conditions as the process is pinned by the file descriptor during the whole duration of the invocation.
+    Note that these require a kernel that supports <constant>PIDFD</constant>. A suitable file descriptor may be
+    acquired via
+    <citerefentry project='man-pages'><refentrytitle>pidfd_open</refentrytitle><manvolnum>2</manvolnum></citerefentry>.</para>
+
+    <para>The <function>sd_peer_get_owner_uid()</function>,
+    <function>sd_peer_get_session()</function>,
+    <function>sd_peer_get_user_unit()</function>,
+    <function>sd_peer_get_unit()</function>,
+    <function>sd_peer_get_machine_name()</function>,
+    <function>sd_peer_get_slice()</function>,
+    <function>sd_peer_get_user_slice()</function> and
+    <function>sd_peer_get_cgroup()</function> calls operate similarly to their PID counterparts, but accept a
+    connected <constant>AF_UNIX</constant> socket and retrieve information about the connected peer process.
+    Note that these fields are retrieved via <filename>/proc/</filename>, and hence are not suitable for
+    authorization purposes, as they are subject to races.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, these calls return 0 or a positive integer. On failure, these calls return a negative
+    errno-style error code.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+
+        <varlistentry>
+          <term><constant>-ESRCH</constant></term>
+
+          <listitem><para>The specified PID does not refer to a running process.</para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EBADF</constant></term>
+
+          <listitem><para>The specified socket file descriptor was invalid.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENODATA</constant></term>
+
+          <listitem><para>The given field is not specified for the described process or peer.</para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>An input parameter was invalid (out of range, or <constant>NULL</constant>, where
+          that is not accepted).</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOMEM</constant></term>
+
+          <listitem><para>Memory allocation failed.</para></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <refsect1>
+    <title>Notes</title>
+
+    <xi:include href="libsystemd-pkgconfig.xml" xpointer="pkgconfig-text"/>
+
+    <para>Note that the login session identifier as
+    returned by <function>sd_pid_get_session()</function>
+    is completely unrelated to the process session
+    identifier as returned by
+    <citerefentry><refentrytitle>getsid</refentrytitle><manvolnum>2</manvolnum></citerefentry>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_peer_get_cgroup()</function>,
+    <function>sd_peer_get_machine_name()</function>,
+    <function>sd_peer_get_owner_uid()</function>,
+    <function>sd_peer_get_session()</function>,
+    <function>sd_peer_get_slice()</function>,
+    <function>sd_peer_get_unit()</function>,
+    <function>sd_peer_get_user_slice()</function>,
+    <function>sd_peer_get_user_unit()</function>,
+    <function>sd_pid_get_cgroup()</function>,
+    <function>sd_pid_get_machine_name()</function>,
+    <function>sd_pid_get_owner_uid()</function>,
+    <function>sd_pid_get_session()</function>,
+    <function>sd_pid_get_slice()</function>,
+    <function>sd_pid_get_unit()</function>,
+    <function>sd_pid_get_user_slice()</function>, and
+    <function>sd_pid_get_user_unit()</function> were added in version 236.</para>
+    <para><function>sd_pidfd_get_owner_uid()</function>,
+    <function>sd_pidfd_get_session()</function>,
+    <function>sd_pidfd_get_user_unit()</function>,
+    <function>sd_pidfd_get_unit()</function>,
+    <function>sd_pidfd_get_machine_name()</function>,
+    <function>sd_pidfd_get_slice()</function>,
+    <function>sd_pidfd_get_user_slice()</function>, and
+    <function>sd_pidfd_get_cgroup()</function> were added in version 253.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-login</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_session_is_active</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>getsid</refentrytitle><manvolnum>2</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-machined.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_seat_get_active.xml b/man/sd_seat_get_active.xml
new file mode 100644
index 0000000..d5d7c04
--- /dev/null
+++ b/man/sd_seat_get_active.xml
@@ -0,0 +1,161 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_seat_get_active" conditional='HAVE_PAM'
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_seat_get_active</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_seat_get_active</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_seat_get_active</refname>
+    <refname>sd_seat_get_sessions</refname>
+    <refname>sd_seat_can_tty</refname>
+    <refname>sd_seat_can_graphical</refname>
+    <refpurpose>Determine state of a specific seat</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-login.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_seat_get_active</function></funcdef>
+        <paramdef>const char *<parameter>seat</parameter></paramdef>
+        <paramdef>char **<parameter>session</parameter></paramdef>
+        <paramdef>uid_t *<parameter>uid</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_seat_get_sessions</function></funcdef>
+        <paramdef>const char *<parameter>seat</parameter></paramdef>
+        <paramdef>char ***<parameter>ret_sessions</parameter></paramdef>
+        <paramdef>uid_t **<parameter>ret_uids</parameter></paramdef>
+        <paramdef>unsigned int *<parameter>ret_n_uids</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_seat_can_tty</function></funcdef>
+        <paramdef>const char *<parameter>seat</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_seat_can_graphical</function></funcdef>
+        <paramdef>const char *<parameter>seat</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_seat_get_active()</function> may be used to
+    determine which session is currently active on a seat, if there is
+    any. Returns the session identifier and the user identifier of the
+    Unix user the session is belonging to. Either the session or the
+    user identifier parameter can be passed <constant>NULL</constant>,
+    in case only one of the parameters shall be queried. The returned
+    string needs to be freed with the libc
+    <citerefentry project='man-pages'><refentrytitle>free</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    call after use.</para>
+
+    <para><function>sd_seat_get_sessions()</function> may be used to determine all sessions on the specified
+    seat. Returns two arrays, one (<constant>NULL</constant> terminated) with the session identifiers of the
+    sessions and one with the user identifiers of the Unix users the sessions belong to. An additional
+    parameter may be used to return the number of entries in the latter array. This value is the same as the
+    return value if the return value is nonnegative. The output parameters may be passed as
+    <constant>NULL</constant> in case these output values are not needed. The arrays and the strings
+    referenced by them need to be freed with the libc <citerefentry
+    project='man-pages'><refentrytitle>free</refentrytitle><manvolnum>3</manvolnum></citerefentry> call after
+    use. Note that instead of an empty array <constant>NULL</constant> may be returned and should be
+    considered equivalent to an empty array.</para>
+
+    <para><function>sd_seat_can_tty()</function> may be used to
+    determine whether a specific seat provides TTY functionality, i.e.
+    is useful as a text console.</para>
+
+    <para><function>sd_seat_can_graphical()</function> may be used to
+    determine whether a specific seat provides graphics functionality,
+    i.e. is useful as a graphics display.</para>
+
+    <para>If the <varname>seat</varname> parameter of any of these
+    functions is passed as <constant>NULL</constant>, the operation is
+    executed for the seat of the session of the calling process, if
+    there is any.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para> On success, <function>sd_seat_get_active()</function> returns 0 or a positive integer. On success,
+    <function>sd_seat_get_sessions()</function> returns the number of entries in the session identifier
+    array. If the test succeeds,
+    <function>sd_seat_can_tty()</function> and <function>sd_seat_can_graphical()</function> return a positive
+    integer, if it fails 0. On failure, these calls return a negative errno-style error code.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+
+        <varlistentry>
+          <term><constant>-ENODATA</constant></term>
+
+          <listitem><para>The given field is not specified for the described seat.</para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENXIO</constant></term>
+
+          <listitem><para>The specified seat is unknown.</para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>An input parameter was invalid (out of range, or <constant>NULL</constant>, where
+          that is not accepted).</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOMEM</constant></term>
+
+          <listitem><para>Memory allocation failed.</para></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+
+    <para><function>sd_seat_can_tty()</function> and
+    <function>sd_seat_can_graphical()</function> were added in version 186.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-login</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_session_get_seat</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_session_is_active.xml b/man/sd_session_is_active.xml
new file mode 100644
index 0000000..79cf8af
--- /dev/null
+++ b/man/sd_session_is_active.xml
@@ -0,0 +1,368 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_session_is_active" conditional='HAVE_PAM'
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_session_is_active</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_session_is_active</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_session_is_active</refname>
+    <refname>sd_session_is_remote</refname>
+    <refname>sd_session_get_state</refname>
+    <refname>sd_session_get_uid</refname>
+    <refname>sd_session_get_username</refname>
+    <refname>sd_session_get_seat</refname>
+    <refname>sd_session_get_start_time</refname>
+    <refname>sd_session_get_service</refname>
+    <refname>sd_session_get_type</refname>
+    <refname>sd_session_get_class</refname>
+    <refname>sd_session_get_desktop</refname>
+    <refname>sd_session_get_display</refname>
+    <refname>sd_session_get_tty</refname>
+    <refname>sd_session_get_vt</refname>
+    <refname>sd_session_get_remote_host</refname>
+    <refname>sd_session_get_remote_user</refname>
+    <refname>sd_session_get_leader</refname>
+    <refpurpose>Determine state of a specific session</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-login.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_session_is_active</function></funcdef>
+        <paramdef>const char *<parameter>session</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_session_is_remote</function></funcdef>
+        <paramdef>const char *<parameter>session</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_session_get_state</function></funcdef>
+        <paramdef>const char *<parameter>session</parameter></paramdef>
+        <paramdef>char **<parameter>state</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_session_get_uid</function></funcdef>
+        <paramdef>const char *<parameter>session</parameter></paramdef>
+        <paramdef>uid_t *<parameter>uid</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_session_get_username</function></funcdef>
+        <paramdef>const char *<parameter>session</parameter></paramdef>
+        <paramdef>char **<parameter>username</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_session_get_seat</function></funcdef>
+        <paramdef>const char *<parameter>session</parameter></paramdef>
+        <paramdef>char **<parameter>seat</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_session_get_start_time</function></funcdef>
+        <paramdef>const char *<parameter>session</parameter></paramdef>
+        <paramdef>uint64_t *<parameter>usec</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_session_get_service</function></funcdef>
+        <paramdef>const char *<parameter>session</parameter></paramdef>
+        <paramdef>char **<parameter>service</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_session_get_type</function></funcdef>
+        <paramdef>const char *<parameter>session</parameter></paramdef>
+        <paramdef>char **<parameter>type</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_session_get_class</function></funcdef>
+        <paramdef>const char *<parameter>session</parameter></paramdef>
+        <paramdef>char **<parameter>class</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_session_get_desktop</function></funcdef>
+        <paramdef>const char *<parameter>session</parameter></paramdef>
+        <paramdef>char **<parameter>desktop</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_session_get_display</function></funcdef>
+        <paramdef>const char *<parameter>session</parameter></paramdef>
+        <paramdef>char **<parameter>display</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_session_get_leader</function></funcdef>
+        <paramdef>const char *<parameter>session</parameter></paramdef>
+        <paramdef>pid_t *<parameter>leader</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_session_get_remote_host</function></funcdef>
+        <paramdef>const char *<parameter>session</parameter></paramdef>
+        <paramdef>char **<parameter>remote_host</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_session_get_remote_user</function></funcdef>
+        <paramdef>const char *<parameter>session</parameter></paramdef>
+        <paramdef>char **<parameter>remote_user</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_session_get_tty</function></funcdef>
+        <paramdef>const char *<parameter>session</parameter></paramdef>
+        <paramdef>char **<parameter>tty</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_session_get_vt</function></funcdef>
+        <paramdef>const char *<parameter>session</parameter></paramdef>
+        <paramdef>unsigned int *<parameter>vt</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_session_is_active()</function> may be used to
+    determine whether the session identified by the specified session
+    identifier is currently active (i.e. currently in the foreground
+    and available for user input) or not.</para>
+
+    <para><function>sd_session_is_remote()</function> may be used to
+    determine whether the session identified by the specified session
+    identifier is a remote session (i.e. its remote host is known) or
+    not.</para>
+
+    <para><function>sd_session_get_state()</function> may be used to
+    determine the state of the session identified by the specified
+    session identifier. The following states are currently known:
+    <literal>online</literal> (session logged in, but session not
+    active, i.e. not in the foreground), <literal>active</literal>
+    (session logged in and active, i.e. in the foreground),
+    <literal>closing</literal> (session nominally logged out, but some
+    processes belonging to it are still around). In the future
+    additional states might be defined, client code should be written
+    to be robust in regards to additional state strings being
+    returned. This function is a more generic version of
+    <function>sd_session_is_active()</function>. The returned string
+    needs to be freed with the libc
+    <citerefentry project='man-pages'><refentrytitle>free</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    call after use.</para>
+
+    <para><function>sd_session_get_uid()</function> may be used to
+    determine the user identifier of the Unix user the session
+    identified by the specified session identifier belongs to.</para>
+
+    <para><function>sd_session_get_username()</function> may be used to
+    determine the name of the Unix user the session identified by
+    the specified session identifier belongs to. The returned string
+    needs to be freed with the libc
+    <citerefentry project='man-pages'><refentrytitle>free</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    call after use.</para>
+
+    <para><function>sd_session_get_seat()</function> may be used to
+    determine the seat identifier of the seat the session identified
+    by the specified session identifier belongs to. Note that not all
+    sessions are attached to a seat, this call will fail (returning
+    <constant>-ENODATA</constant>) for them. The returned string needs
+    to be freed with the libc
+    <citerefentry project='man-pages'><refentrytitle>free</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    call after use.</para>
+
+    <para><function>sd_session_get_start_time()</function> may be used to
+    determine the start time of the session identified by the specified
+    session identifier belongs to. The <parameter>usec</parameter>
+    is in microseconds since the epoch (<constant>CLOCK_REALTIME</constant>).</para>
+
+    <para><function>sd_session_get_service()</function> may be used to
+    determine the name of the service (as passed during PAM session
+    setup) that registered the session identified by the specified
+    session identifier. The returned string needs to be freed with the
+    libc
+    <citerefentry project='man-pages'><refentrytitle>free</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    call after use.</para>
+
+    <para><function>sd_session_get_type()</function> may be used to
+    determine the type of the session identified by the specified
+    session identifier. The returned string is one of
+    <literal>x11</literal>, <literal>wayland</literal>,
+    <literal>tty</literal>, <literal>mir</literal> or
+    <literal>unspecified</literal> and needs to be freed with the libc
+    <citerefentry project='man-pages'><refentrytitle>free</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    call after use.</para>
+
+    <para><function>sd_session_get_class()</function> may be used to
+    determine the class of the session identified by the specified
+    session identifier. The returned string is one of
+    <literal>user</literal>, <literal>greeter</literal>,
+    <literal>lock-screen</literal>, or <literal>background</literal>
+    and needs to be freed with the libc
+    <citerefentry project='man-pages'><refentrytitle>free</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    call after use.</para>
+
+    <para><function>sd_session_get_desktop()</function> may be used to
+    determine the brand of the desktop running on the session
+    identified by the specified session identifier. This field can be
+    set freely by desktop environments and does not follow any special
+    formatting. However, desktops are strongly recommended to use the
+    same identifiers and capitalization as for
+    <varname>$XDG_CURRENT_DESKTOP</varname>, as defined by the <ulink
+    url="https://standards.freedesktop.org/desktop-entry-spec/latest/">Desktop
+    Entry Specification</ulink>. The returned string needs to be freed
+    with the libc
+    <citerefentry project='man-pages'><refentrytitle>free</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    call after use.</para>
+
+    <para><function>sd_session_get_display()</function> may be used to
+    determine the X11 display of the session identified by the
+    specified session identifier. The returned string needs to be
+    freed with the libc
+    <citerefentry project='man-pages'><refentrytitle>free</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    call after use.</para>
+
+    <para><function>sd_session_get_leader()</function> may be used to
+    determine the PID of the leader of the session identified by the
+    specified session identifier.</para>
+
+    <para><function>sd_session_get_remote_host()</function> may be
+    used to determine the remote hostname of the session identified by
+    the specified session identifier. The returned string needs to be
+    freed with the libc
+    <citerefentry project='man-pages'><refentrytitle>free</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    call after use.</para>
+
+    <para><function>sd_session_get_remote_user()</function> may be
+    used to determine the remote username of the session identified by
+    the specified session identifier. The returned string needs to be
+    freed with the libc
+    <citerefentry project='man-pages'><refentrytitle>free</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    call after use. Note that this value is rarely known to the
+    system, and even then should not be relied on.</para>
+
+    <para><function>sd_session_get_tty()</function> may be used to
+    determine the TTY device of the session identified by the
+    specified session identifier. The returned string needs to be
+    freed with the libc
+    <citerefentry project='man-pages'><refentrytitle>free</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    call after use.</para>
+
+    <para><function>sd_session_get_vt()</function> may be used to
+    determine the VT number of the session identified by the specified
+    session identifier. This function will return an error if the seat
+    does not support VTs.</para>
+
+    <para>If the <varname>session</varname> parameter of any of these
+    functions is passed as <constant>NULL</constant>, the operation is
+    executed for the session the calling process is a member of, if
+    there is any.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>If the test succeeds,
+    <function>sd_session_is_active()</function> and
+    <function>sd_session_is_remote()</function> return a
+    positive integer; if it fails, 0.  On success,
+    <function>sd_session_get_state()</function>,
+    <function>sd_session_get_uid()</function>,
+    <function>sd_session_get_username()</function>,
+    <function>sd_session_get_seat()</function>,
+    <function>sd_session_get_service()</function>,
+    <function>sd_session_get_type()</function>,
+    <function>sd_session_get_class()</function>,
+    <function>sd_session_get_display()</function>,
+    <function>sd_session_get_leader()</function>,
+    <function>sd_session_get_remote_user()</function>,
+    <function>sd_session_get_remote_host()</function> and
+    <function>sd_session_get_tty()</function> return 0 or
+    a positive integer. On failure, these calls return a
+    negative errno-style error code.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+
+        <varlistentry>
+          <term><constant>-ENXIO</constant></term>
+
+          <listitem><para>The specified session does not exist.</para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENODATA</constant></term>
+
+          <listitem><para>The given field is not specified for the described session.</para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>An input parameter was invalid (out of range, or <constant>NULL</constant>, where
+          that is not accepted).</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOMEM</constant></term>
+
+          <listitem><para>Memory allocation failed.</para></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_session_get_state()</function> was added in version 186.</para>
+    <para><function>sd_session_get_tty()</function> was added in version 198.</para>
+    <para><function>sd_session_get_vt()</function> was added in version 207.</para>
+    <para><function>sd_session_is_remote()</function>,
+    <function>sd_session_get_remote_host()</function>, and
+    <function>sd_session_get_remote_user()</function> were added in version 209.</para>
+    <para><function>sd_session_get_desktop()</function> was added in version 217.</para>
+    <para><function>sd_session_get_username()</function>,
+    <function>sd_session_get_start_time()</function>, and
+    <function>sd_session_get_leader()</function> were added in version 254.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-login</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_pid_get_session</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_uid_get_state.xml b/man/sd_uid_get_state.xml
new file mode 100644
index 0000000..4a78ed9
--- /dev/null
+++ b/man/sd_uid_get_state.xml
@@ -0,0 +1,215 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_uid_get_state" conditional='HAVE_PAM'
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_uid_get_state</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_uid_get_state</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_uid_get_state</refname>
+    <refname>sd_uid_is_on_seat</refname>
+    <refname>sd_uid_get_sessions</refname>
+    <refname>sd_uid_get_seats</refname>
+    <refname>sd_uid_get_display</refname>
+    <refname>sd_uid_get_login_time</refname>
+    <refpurpose>Determine login state of a specific Unix user ID</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-login.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_uid_get_state</function></funcdef>
+        <paramdef>uid_t <parameter>uid</parameter></paramdef>
+        <paramdef>char **<parameter>state</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_uid_is_on_seat</function></funcdef>
+        <paramdef>uid_t <parameter>uid</parameter></paramdef>
+        <paramdef>int <parameter>require_active</parameter></paramdef>
+        <paramdef>const char *<parameter>seat</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_uid_get_sessions</function></funcdef>
+        <paramdef>uid_t <parameter>uid</parameter></paramdef>
+        <paramdef>int <parameter>require_active</parameter></paramdef>
+        <paramdef>char ***<parameter>sessions</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_uid_get_seats</function></funcdef>
+        <paramdef>uid_t <parameter>uid</parameter></paramdef>
+        <paramdef>int <parameter>require_active</parameter></paramdef>
+        <paramdef>char ***<parameter>seats</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_uid_get_display</function></funcdef>
+        <paramdef>uid_t <parameter>uid</parameter></paramdef>
+        <paramdef>char **<parameter>session</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>sd_uid_get_login_time</function></funcdef>
+        <paramdef>uid_t <parameter>uid</parameter></paramdef>
+        <paramdef>uint64_t *<parameter>usec</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>sd_uid_get_state()</function> may be used to
+    determine the login state of a specific Unix user identifier. The
+    following states are currently known: <literal>offline</literal>
+    (user not logged in at all), <literal>lingering</literal> (user
+    not logged in, but some user services running),
+    <literal>online</literal> (user logged in, but not active, i.e.
+    has no session in the foreground), <literal>active</literal> (user
+    logged in, and has at least one active session, i.e. one session
+    in the foreground), <literal>closing</literal> (user not logged
+    in, and not lingering, but some processes are still around). In
+    the future additional states might be defined, client code should
+    be written to be robust in regards to additional state strings
+    being returned. The returned string needs to be freed with the
+    libc
+    <citerefentry project='man-pages'><refentrytitle>free</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    call after use.</para>
+
+    <para><function>sd_uid_is_on_seat()</function> may be used to
+    determine whether a specific user is logged in or active on a
+    specific seat. Accepts a Unix user identifier and a seat
+    identifier string as parameters. The
+    <parameter>require_active</parameter> parameter is a boolean
+    value. If non-zero (true), this function will test if the user is
+    active (i.e. has a session that is in the foreground and accepting
+    user input) on the specified seat, otherwise (false) only if the
+    user is logged in (and possibly inactive) on the specified
+    seat.</para>
+
+    <para><function>sd_uid_get_sessions()</function> may be used to
+    determine the current sessions of the specified user. Accepts a
+    Unix user identifier as parameter. The
+    <parameter>require_active</parameter> parameter controls whether
+    the returned list shall consist of only those sessions where the
+    user is currently active (&gt; 0), where the user is currently
+    online but possibly inactive (= 0), or logged in but
+    possibly closing the session (&lt; 0). The call returns a
+    <constant>NULL</constant> terminated string array of session
+    identifiers in <parameter>sessions</parameter> which needs to be
+    freed by the caller with the libc
+    <citerefentry project='man-pages'><refentrytitle>free</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    call after use, including all the strings referenced. If the
+    string array parameter is passed as <constant>NULL</constant>, the
+    array will not be filled in, but the return code still indicates
+    the number of current sessions. Note that instead of an empty
+    array <constant>NULL</constant> may be returned and should be
+    considered equivalent to an empty array.</para>
+
+    <para>Similarly, <function>sd_uid_get_seats()</function> may be
+    used to determine the list of seats on which the user currently
+    has sessions. Similar semantics apply, however note that the user
+    may have multiple sessions on the same seat as well as sessions
+    with no attached seat and hence the number of entries in the
+    returned array may differ from the one returned by
+    <function>sd_uid_get_sessions()</function>.</para>
+
+    <para><function>sd_uid_get_display()</function> returns the name
+    of the "primary" session of a user. If the user has graphical
+    sessions, it will be the oldest graphical session. Otherwise, it
+    will be the oldest open session.</para>
+
+    <para><function>sd_uid_get_login_time()</function> may be used to
+    determine the time the user's service manager has been invoked,
+    which is the time when the user's first active session, since which
+    they stayed logged in continuously, began. The <parameter>usec</parameter>
+    is in microseconds since the epoch (<constant>CLOCK_REALTIME</constant>).
+    This call will fail with <constant>-ENXIO</constant> if the user is not
+    currently logged in.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, <function>sd_uid_get_state()</function> and
+    <function>sd_uid_get_login_time()</function> returns 0 or a positive
+    integer. If the test succeeds, <function>sd_uid_is_on_seat()</function>
+    returns a positive integer; if it fails, 0. <function>sd_uid_get_sessions()</function>
+    and <function>sd_uid_get_seats()</function> return the number of entries
+    in the returned arrays. <function>sd_uid_get_display()</function>
+    returns a non-negative code on success. On failure, these calls return
+    a negative errno-style error code.</para>
+
+    <refsect2>
+      <title>Errors</title>
+
+      <para>Returned errors may indicate the following problems:</para>
+
+      <variablelist>
+
+        <varlistentry>
+          <term><constant>-ENODATA</constant></term>
+
+          <listitem><para>The given field is not specified for the described user.</para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENXIO</constant></term>
+
+          <listitem><para>The specified seat is unknown.</para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-EINVAL</constant></term>
+
+          <listitem><para>An input parameter was invalid (out of range, or <constant>NULL</constant>,
+          where that is not accepted). This is also returned if the passed user ID is
+          <constant>0xFFFF</constant> or <constant>0xFFFFFFFF</constant>, which are undefined on Linux.
+          </para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>-ENOMEM</constant></term>
+
+          <listitem><para>Memory allocation failed.</para></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="libsystemd-pkgconfig.xml" />
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_uid_get_display()</function> was added in version 213.</para>
+    <para><function>sd_uid_get_login_time()</function> was added in version 254.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-login</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_pid_get_owner_uid</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sd_watchdog_enabled.xml b/man/sd_watchdog_enabled.xml
new file mode 100644
index 0000000..4a6bd6f
--- /dev/null
+++ b/man/sd_watchdog_enabled.xml
@@ -0,0 +1,152 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sd_watchdog_enabled"
+  xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sd_watchdog_enabled</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sd_watchdog_enabled</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sd_watchdog_enabled</refname>
+    <refpurpose>Check whether the service manager expects watchdog keep-alive notifications from a service</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;systemd/sd-daemon.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>sd_watchdog_enabled</function></funcdef>
+        <paramdef>int <parameter>unset_environment</parameter></paramdef>
+        <paramdef>uint64_t *<parameter>usec</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+    <para><function>sd_watchdog_enabled()</function> may be called by
+    a service to detect whether the service manager expects regular
+    keep-alive watchdog notification events from it, and the timeout
+    after which the manager will act on the service if it did not get
+    such a notification.</para>
+
+    <para>If the <varname>$WATCHDOG_USEC</varname> environment
+    variable is set, and the <varname>$WATCHDOG_PID</varname> variable
+    is unset or set to the PID of the current process, the service
+    manager expects notifications from this process. The manager will
+    usually terminate a service when it does not get a notification
+    message within the specified time after startup and after each
+    previous message. It is recommended that a daemon sends a
+    keep-alive notification message to the service manager every half
+    of the time returned here. Notification messages may be sent with
+    <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    with a message string of <literal>WATCHDOG=1</literal>.</para>
+
+    <para>If the <parameter>unset_environment</parameter> parameter is
+    non-zero, <function>sd_watchdog_enabled()</function> will unset
+    the <varname>$WATCHDOG_USEC</varname> and
+    <varname>$WATCHDOG_PID</varname> environment variables before
+    returning (regardless of whether the function call itself
+    succeeded or not). Those variables are no longer inherited by
+    child processes. Further calls to
+    <function>sd_watchdog_enabled()</function> will also return with
+    zero.</para>
+
+    <para>If the <parameter>usec</parameter> parameter is non-<constant>NULL</constant>,
+    <function>sd_watchdog_enabled()</function> will write the timeout
+    in μs for the watchdog logic to it.</para>
+
+    <para>To enable service supervision with the watchdog logic, use
+    <varname>WatchdogSec=</varname> in service files. See
+    <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for details.</para>
+
+    <para>Use
+    <citerefentry><refentrytitle>sd_event_set_watchdog</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    to enable automatic watchdog support in
+    <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry>-based event loops.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On failure, this call returns a negative errno-style error
+    code. If the service manager expects watchdog keep-alive
+    notification messages to be sent, &gt; 0 is returned, otherwise 0
+    is returned. Only if the return value is &gt; 0, the
+    <parameter>usec</parameter> parameter is valid after the
+    call.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Notes</title>
+
+    <xi:include href="libsystemd-pkgconfig.xml" xpointer="pkgconfig-text"/>
+    <xi:include href="threads-aware.xml" xpointer="getenv"/>
+
+    <para>Internally, this function parses the
+    <varname>$WATCHDOG_PID</varname> and
+    <varname>$WATCHDOG_USEC</varname> environment variable. The call
+    will ignore these variables if <varname>$WATCHDOG_PID</varname>
+    does not contain the PID of the current process, under the
+    assumption that in that case, the variables were set for a
+    different process further up the process tree.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Environment</title>
+
+    <variablelist class='environment-variables'>
+      <varlistentry>
+        <term><varname>$WATCHDOG_PID</varname></term>
+
+        <listitem><para>Set by the system manager for supervised
+        process for which watchdog support is enabled, and contains
+        the PID of that process. See above for
+        details.</para>
+
+        <xi:include href="version-info.xml" xpointer="v209"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>$WATCHDOG_USEC</varname></term>
+
+        <listitem><para>Set by the system manager for supervised
+        process for which watchdog support is enabled, and contains
+        the watchdog timeout in μs. See above for
+        details.</para>
+
+        <xi:include href="version-info.xml" xpointer="v209"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>History</title>
+    <para><function>sd_watchdog_enabled()</function> was added in version 209.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-daemon</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>daemon</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_event_set_watchdog</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/send-unit-files-changed.c b/man/send-unit-files-changed.c
new file mode 100644
index 0000000..dfd38a1
--- /dev/null
+++ b/man/send-unit-files-changed.c
@@ -0,0 +1,18 @@
+/* SPDX-License-Identifier: MIT-0 */
+
+#include <systemd/sd-bus.h>
+#define _cleanup_(f) __attribute__((cleanup(f)))
+
+int send_unit_files_changed(sd_bus *bus) {
+  _cleanup_(sd_bus_message_unrefp) sd_bus_message *message = NULL;
+  int r;
+
+  r = sd_bus_message_new_signal(bus, &message,
+                                "/org/freedesktop/systemd1",
+                                "org.freedesktop.systemd1.Manager",
+                                "UnitFilesChanged");
+  if (r < 0)
+    return r;
+
+  return sd_bus_send(bus, message, NULL);
+}
diff --git a/man/shutdown.xml b/man/shutdown.xml
new file mode 100644
index 0000000..d973704
--- /dev/null
+++ b/man/shutdown.xml
@@ -0,0 +1,158 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="shutdown"
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>shutdown</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>shutdown</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>shutdown</refname>
+    <refpurpose>Halt, power off or reboot the machine</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <cmdsynopsis>
+      <command>shutdown</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="opt">TIME</arg>
+      <arg choice="opt" rep="repeat">WALL</arg>
+    </cmdsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>shutdown</command> may be used to halt, power off, or reboot the machine.</para>
+
+    <para>The first argument may be a time string (which is usually
+    <literal>now</literal>). Optionally, this may be followed by a
+    wall message to be sent to all logged-in users before going
+    down.</para>
+
+    <para>The time string may either be in the format
+    <literal>hh:mm</literal> for hour/minutes specifying the time to
+    execute the shutdown at, specified in 24h clock format.
+    Alternatively it may be in the syntax <literal>+m</literal>
+    referring to the specified number of minutes m from now.
+    <literal>now</literal> is an alias for <literal>+0</literal>, i.e.
+    for triggering an immediate shutdown. If no time argument is
+    specified, <literal>+1</literal> is implied.</para>
+
+    <para>Note that to specify a wall message you must specify a time
+    argument, too.</para>
+
+    <para>If the time argument is used, 5 minutes before the system
+    goes down the <filename>/run/nologin</filename> file is created to
+    ensure that further logins shall not be allowed.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>The following options are understood:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><option>--help</option></term>
+
+        <xi:include href="standard-options.xml" xpointer="help-text" />
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-H</option></term>
+        <term><option>--halt</option></term>
+
+        <listitem><para>Halt the machine.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-P</option></term>
+        <term><option>--poweroff</option></term>
+
+        <listitem><para>Power the machine off (the default).</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-r</option></term>
+        <term><option>--reboot</option></term>
+
+        <listitem><para>Reboot the machine.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-h</option></term>
+
+        <listitem><para>The same as <option>--poweroff</option>, but does not override the action to take if
+        it is "halt". E.g. <command>shutdown --reboot -h</command> means "poweroff", but <command>shutdown
+        --halt -h</command> means "halt".</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-k</option></term>
+
+        <listitem><para>Do not halt, power off, or reboot, but just write the wall message.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--no-wall</option></term>
+
+        <listitem><para>Do not send wall message before halt, power off, or reboot.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-c</option></term>
+
+        <listitem><para>Cancel a pending shutdown. This may be used to cancel the effect of an invocation of
+        <command>shutdown</command> with a time argument that is not <literal>+0</literal> or
+        <literal>now</literal>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--show</option></term>
+
+        <listitem><para>Show a pending shutdown action and time if
+        there is any.</para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Exit status</title>
+
+    <para>On success, 0 is returned, a non-zero failure code
+    otherwise.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Compatibility</title>
+
+    <para>The <command> shutdown</command> command in previous init systems (including sysvinit) defaulted to
+    single-user mode instead of powering off the machine. To change into single-user mode, use
+    <command>systemctl rescue</command> instead.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>halt</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>wall</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/smbios-type-11.xml b/man/smbios-type-11.xml
new file mode 100644
index 0000000..18d17bd
--- /dev/null
+++ b/man/smbios-type-11.xml
@@ -0,0 +1,79 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="smbios-type-11" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>smbios-type-11</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>smbios-type-11</refentrytitle>
+    <manvolnum>7</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>smbios-type-11</refname>
+    <refpurpose>SMBIOS Type 11 strings</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>/sys/firmware/dmi/entries/11-*/raw</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>Various OS components process SMBIOS Type 11 vendor strings that a virtual machine manager (VMM)
+    may set and a virtual machine (VM) receives. SMBIOS Type 11 vendor strings may play a similar role as
+    <citerefentry><refentrytitle>kernel-command-line</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    parameters but generally are under control of the VMM rather than the boot loader or UKI.</para>
+
+    <para>For details on SMBIOS Type 11 see the <ulink url="https://www.dmtf.org/standards/smbios/">System
+    Management BIOS</ulink> specifications.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Strings</title>
+
+    <para>The following strings are supported:</para>
+
+    <variablelist class='smbios-type-11-options'>
+      <varlistentry>
+        <term><varname>io.systemd.credential:</varname><replaceable>CREDENTIAL=VALUE</replaceable></term>
+        <term><varname>io.systemd.credential.binary:</varname><replaceable>CREDENTIAL=VALUE</replaceable></term>
+
+        <listitem><para>This allows passing additional system credentials into the system, in textual or binary (Base64)
+        form. See
+        <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> and
+        <ulink url="https://systemd.io/CREDENTIALS">System and Service Credentials</ulink> for
+        details.</para>
+
+        <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>io.systemd.stub.kernel-cmdline-extra=</varname><replaceable>CMDLINE</replaceable></term>
+
+        <listitem><para>This allows configuration of additional kernel command line options, and is read by
+        the kernel UEFI stub. For details see
+        <citerefentry><refentrytitle>systemd-stub</refentrytitle><manvolnum>1</manvolnum></citerefentry>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+      <title>See Also</title>
+      <para>
+        <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>kernel-command-line</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.system-credentials</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+      </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/standard-conf.xml b/man/standard-conf.xml
new file mode 100644
index 0000000..cc2b874
--- /dev/null
+++ b/man/standard-conf.xml
@@ -0,0 +1,74 @@
+<?xml version="1.0"?>
+<!DOCTYPE refsection PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+          "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd">
+
+<!--
+  SPDX-License-Identifier: LGPL-2.1-or-later
+  Copyright © 2014 Josh Triplett
+-->
+
+<refsection>
+  <refsection id='confd'>
+    <title>Configuration Directories and Precedence</title>
+
+    <para>Configuration files are read from directories in <filename>/etc/</filename>,
+    <filename>/run/</filename>, <filename>/usr/local/lib/</filename>, and <filename>/usr/lib/</filename>, in
+    order of precedence, as listed in the SYNOPSIS section above. Files must have the
+    <literal>.conf</literal> extension. Files in <filename>/etc/</filename> override files with the same name
+    in <filename>/run/</filename>, <filename>/usr/local/lib/</filename>, and
+    <filename>/usr/lib/</filename>. Files in <filename>/run/</filename> override files with the same name
+    under <filename>/usr/</filename>.</para>
+
+    <para>All configuration files are sorted by their filename in lexicographic order, regardless of which of
+    the directories they reside in. If multiple files specify the same option, the entry in the file with the
+    lexicographically latest name will take precedence. Thus, the configuration in a certain file may either
+    be replaced completely (by placing a file with the same name in a directory with higher priority), or
+    individual settings might be changed (by specifying additional settings in a file with a different name
+    that is ordered later).</para>
+
+    <para>Packages should install their configuration files in <filename>/usr/lib/</filename> (distribution
+    packages) or <filename>/usr/local/lib/</filename> (local installs). Files in <filename>/etc/</filename>
+    are reserved for the local administrator, who may use this logic to override the configuration files
+    installed by vendor packages. It is recommended to prefix all filenames with a two-digit number and a
+    dash, to simplify the ordering of the files.</para>
+
+    <para>If the administrator wants to disable a configuration file supplied by the vendor, the recommended
+    way is to place a symlink to <filename>/dev/null</filename> in the configuration directory in
+    <filename>/etc/</filename>, with the same filename as the vendor configuration file. If the vendor
+    configuration file is included in the initrd image, the image has to be regenerated.</para>
+  </refsection>
+
+  <refsection id='main-conf'>
+    <title>Configuration Directories and Precedence</title>
+
+    <para>The default configuration is set during compilation, so configuration is only needed when it is
+    necessary to deviate from those defaults. The main configuration file is either in
+    <filename>/usr/lib/systemd/</filename> or <filename>/etc/systemd/</filename> and contains commented out
+    entries showing the defaults as a guide to the administrator. Local overrides can be created by creating
+    drop-ins, as described below. The main configuration file can also be edited for this purpose (or a copy
+    in <filename>/etc/</filename> if it's shipped in <filename>/usr/</filename>) however using drop-ins for
+    local configuration is recommended over modifications to the main configuration file.</para>
+
+    <para>In addition to the "main" configuration file, drop-in configuration snippets are read from
+    <filename>/usr/lib/systemd/*.conf.d/</filename>, <filename>/usr/local/lib/systemd/*.conf.d/</filename>,
+    and <filename>/etc/systemd/*.conf.d/</filename>. Those drop-ins have higher precedence and override the
+    main configuration file. Files in the <filename>*.conf.d/</filename> configuration subdirectories are
+    sorted by their filename in lexicographic order, regardless of in which of the subdirectories they
+    reside. When multiple files specify the same option, for options which accept just a single value, the
+    entry in the file sorted last takes precedence, and for options which accept a list of values, entries
+    are collected as they occur in the sorted files.</para>
+
+    <para>When packages need to customize the configuration, they can install drop-ins under
+    <filename>/usr/</filename>. Files in <filename>/etc/</filename> are reserved for the local administrator,
+    who may use this logic to override the configuration files installed by vendor packages. Drop-ins have to
+    be used to override package drop-ins, since the main configuration file has lower precedence. It is
+    recommended to prefix all filenames in those subdirectories with a two-digit number and a dash, to
+    simplify the ordering of the files. This also defined a concept of drop-in priority to allow
+    distributions to ship drop-ins within a specific range lower than the range used by users. This should
+    lower the risk of package drop-ins overriding accidentally drop-ins defined by users.</para>
+
+    <para>To disable a configuration file supplied by the vendor, the recommended way is to place a symlink
+    to <filename>/dev/null</filename> in the configuration directory in <filename>/etc/</filename>, with the
+    same filename as the vendor configuration file.</para>
+  </refsection>
+</refsection>
diff --git a/man/standard-options.xml b/man/standard-options.xml
new file mode 100644
index 0000000..eb27f5c
--- /dev/null
+++ b/man/standard-options.xml
@@ -0,0 +1,143 @@
+<?xml version="1.0"?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<variablelist
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <varlistentry id='help'>
+    <term><option>-h</option></term>
+    <term><option>--help</option></term>
+
+    <listitem id='help-text'>
+      <para>Print a short help text and exit.
+    </para></listitem>
+  </varlistentry>
+
+  <varlistentry id='version'>
+    <term><option>--version</option></term>
+
+    <listitem id='version-text'>
+      <para>Print a short version string and exit.</para>
+    </listitem>
+  </varlistentry>
+
+  <varlistentry id='no-pager'>
+    <term><option>--no-pager</option></term>
+
+    <listitem>
+      <para>Do not pipe output into a pager.</para>
+    </listitem>
+  </varlistentry>
+
+  <varlistentry id='no-pager-255'>
+    <term><option>--no-pager</option></term>
+
+    <listitem>
+      <para>Do not pipe output into a pager.</para>
+
+      <xi:include href="version-info.xml" xpointer="v255"/>
+    </listitem>
+  </varlistentry>
+
+  <varlistentry id='no-ask-password'>
+    <term><option>--no-ask-password</option></term>
+
+    <listitem><para>Do not query the user for authentication for privileged operations.</para></listitem>
+  </varlistentry>
+
+  <varlistentry id='legend'>
+    <term><option>--legend=</option><replaceable>BOOL</replaceable></term>
+
+    <listitem>
+      <para>Enable or disable printing of the legend, i.e. column headers and the footer with hints. The
+      legend is printed by default, unless disabled with <option>--quiet</option> or similar.</para>
+    </listitem>
+  </varlistentry>
+
+  <varlistentry id='no-legend'>
+    <term><option>--no-legend</option></term>
+
+    <listitem>
+      <para>Do not print the legend, i.e. column headers and the
+      footer with hints.</para>
+    </listitem>
+  </varlistentry>
+
+  <varlistentry id='cat-config'>
+    <term><option>--cat-config</option></term>
+
+    <listitem>
+      <para>Copy the contents of config files to standard output.
+      Before each file, the filename is printed as a comment.</para>
+    </listitem>
+  </varlistentry>
+
+  <varlistentry id='tldr'>
+    <term><option>--tldr</option></term>
+
+    <listitem>
+      <para>Copy the contents of config files to standard output. Only the "interesting" parts of the
+      configuration files are printed, comments and empty lines are skipped. Before each file, the filename
+      is printed as a comment.</para>
+    </listitem>
+  </varlistentry>
+
+  <varlistentry id='json'>
+    <term><option>--json=</option><replaceable>MODE</replaceable></term>
+
+    <listitem><para>Shows output formatted as JSON. Expects one of <literal>short</literal> (for the
+    shortest possible output without any redundant whitespace or line breaks), <literal>pretty</literal>
+    (for a pretty version of the same, with indentation and line breaks) or <literal>off</literal> (to turn
+    off JSON output, the default).</para></listitem>
+  </varlistentry>
+
+  <varlistentry id='signal'>
+    <term><option>-s</option></term>
+    <term><option>--signal=</option></term>
+
+    <listitem>
+      <para>When used with <command>kill</command>, choose which signal to send to selected processes. Must
+      be one of the well-known signal specifiers such as <constant>SIGTERM</constant>,
+      <constant>SIGINT</constant> or <constant>SIGSTOP</constant>. If omitted, defaults to
+      <option>SIGTERM</option>.</para>
+
+      <para>The special value <literal>help</literal> will list the known values and the program will exit
+      immediately, and the special value <literal>list</literal> will list known values along with the
+      numerical signal numbers and the program will exit immediately.</para>
+    </listitem>
+  </varlistentry>
+
+  <varlistentry id='image-policy-open'>
+    <term><option>--image-policy=<replaceable>policy</replaceable></option></term>
+
+    <listitem><para>Takes an image policy string as argument, as per
+    <citerefentry><refentrytitle>systemd.image-policy</refentrytitle><manvolnum>7</manvolnum></citerefentry>. The
+    policy is enforced when operating on the disk image specified via <option>--image=</option>, see
+    above. If not specified defaults to the <literal>*</literal> policy, i.e. all recognized file systems
+    in the image are used.</para></listitem>
+  </varlistentry>
+
+  <varlistentry id='esp-path'>
+    <term><option>--esp-path=</option></term>
+
+    <listitem>
+      <para>Path to the EFI System Partition (ESP). If not specified, <filename>/efi/</filename>,
+      <filename>/boot/</filename>, and <filename>/boot/efi/</filename> are checked in turn. It is
+      recommended to mount the ESP to <filename>/efi/</filename>, if possible.</para>
+    </listitem>
+  </varlistentry>
+
+  <varlistentry id='boot-path'>
+    <term><option>--boot-path=</option></term>
+
+    <listitem>
+      <para>Path to the Extended Boot Loader partition, as defined in the
+      <ulink url="https://uapi-group.org/specifications/specs/boot_loader_specification">Boot Loader Specification</ulink>.
+      If not specified, <filename>/boot/</filename> is checked. It is recommended to mount the Extended Boot
+      Loader partition to <filename>/boot/</filename>, if possible.</para>
+    </listitem>
+  </varlistentry>
+
+</variablelist>
diff --git a/man/standard-specifiers.xml b/man/standard-specifiers.xml
new file mode 100644
index 0000000..7aa7aca
--- /dev/null
+++ b/man/standard-specifiers.xml
@@ -0,0 +1,90 @@
+<?xml version="1.0"?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<tbody>
+  <!-- note: units also use the following deprecated specifiers that are not documented:
+       %c, %r, %R. Do not reuse. -->
+
+  <row id='a'>
+    <entry><literal>%a</literal></entry>
+    <entry>Architecture</entry>
+    <entry>A short string identifying the architecture of the local system. A string such as <constant>x86</constant>, <constant>x86-64</constant> or <constant>arm64</constant>. See the architectures defined for <varname>ConditionArchitecture=</varname> in <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> for a full list.</entry>
+  </row>
+  <row id='A'>
+    <entry><literal>%A</literal></entry>
+    <entry>Operating system image version</entry>
+    <entry>The operating system image version identifier of the running system, as read from the <varname>IMAGE_VERSION=</varname> field of <filename>/etc/os-release</filename>. If not set, resolves to an empty string. See <citerefentry><refentrytitle>os-release</refentrytitle><manvolnum>5</manvolnum></citerefentry> for more information.</entry>
+  </row>
+  <row id='b'>
+    <entry><literal>%b</literal></entry>
+    <entry>Boot ID</entry>
+    <entry>The boot ID of the running system, formatted as string. See <citerefentry><refentrytitle>random</refentrytitle><manvolnum>4</manvolnum></citerefentry> for more information.</entry>
+  </row>
+  <row id='B'>
+    <entry><literal>%B</literal></entry>
+    <entry>Operating system build ID</entry>
+    <entry>The operating system build identifier of the running system, as read from the <varname>BUILD_ID=</varname> field of <filename>/etc/os-release</filename>. If not set, resolves to an empty string. See <citerefentry><refentrytitle>os-release</refentrytitle><manvolnum>5</manvolnum></citerefentry> for more information.</entry>
+  </row>
+  <row id='H'>
+    <entry><literal>%H</literal></entry>
+    <entry>Host name</entry>
+    <entry>The hostname of the running system.</entry>
+  </row>
+  <row id='l'>
+    <entry><literal>%l</literal></entry>
+    <entry>Short host name</entry>
+    <entry>The hostname of the running system, truncated at the first dot to remove any domain component.</entry>
+  </row>
+  <row id='m'>
+    <entry><literal>%m</literal></entry>
+    <entry>Machine ID</entry>
+    <entry>The machine ID of the running system, formatted as string. See <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry> for more information.</entry>
+  </row>
+  <row id='M'>
+    <entry><literal>%M</literal></entry>
+    <entry>Operating system image identifier</entry>
+    <entry>The operating system image identifier of the running system, as read from the <varname>IMAGE_ID=</varname> field of <filename>/etc/os-release</filename>. If not set, resolves to an empty string. See <citerefentry><refentrytitle>os-release</refentrytitle><manvolnum>5</manvolnum></citerefentry> for more information.</entry>
+  </row>
+  <row id='o'>
+    <entry><literal>%o</literal></entry>
+    <entry>Operating system ID</entry>
+    <entry>The operating system identifier of the running system, as read from the <varname>ID=</varname> field of <filename>/etc/os-release</filename>. See <citerefentry><refentrytitle>os-release</refentrytitle><manvolnum>5</manvolnum></citerefentry> for more information.</entry>
+  </row>
+  <row id='q'>
+    <entry><literal>%q</literal></entry>
+    <entry>Pretty host name</entry>
+    <entry>The pretty hostname of the running system, as read from the <varname>PRETTY_HOSTNAME=</varname> field of <filename>/etc/machine-info</filename>. If not set, resolves to the short hostname. See <citerefentry><refentrytitle>machine-info</refentrytitle><manvolnum>5</manvolnum></citerefentry> for more information.</entry>
+  </row>
+  <row id='T'>
+    <entry><literal>%T</literal></entry>
+    <entry>Directory for temporary files</entry>
+    <entry>This is either <filename>/tmp<!-- no / --></filename> or the path <literal>$TMPDIR</literal>, <literal>$TEMP</literal> or <literal>$TMP</literal> are set to. (Note that the directory may be specified without a trailing slash.)</entry>
+  </row>
+  <row id='v'>
+    <entry><literal>%v</literal></entry>
+    <entry>Kernel release</entry>
+    <entry>Identical to <command>uname -r</command> output.</entry>
+  </row>
+  <row id='V'>
+    <entry><literal>%V</literal></entry>
+    <entry>Directory for larger and persistent temporary files</entry>
+    <entry>This is either <filename>/var/tmp<!-- no / --></filename> or the path <literal>$TMPDIR</literal>, <literal>$TEMP</literal> or <literal>$TMP</literal> are set to. (Note that the directory may be specified without a trailing slash.)</entry>
+  </row>
+  <row id='w'>
+    <entry><literal>%w</literal></entry>
+    <entry>Operating system version ID</entry>
+    <entry>The operating system version identifier of the running system, as read from the <varname>VERSION_ID=</varname> field of <filename>/etc/os-release</filename>. If not set, resolves to an empty string. See <citerefentry><refentrytitle>os-release</refentrytitle><manvolnum>5</manvolnum></citerefentry> for more information.</entry>
+  </row>
+  <row id='W'>
+    <entry><literal>%W</literal></entry>
+    <entry>Operating system variant ID</entry>
+    <entry>The operating system variant identifier of the running system, as read from the <varname>VARIANT_ID=</varname> field of <filename>/etc/os-release</filename>. If not set, resolves to an empty string. See <citerefentry><refentrytitle>os-release</refentrytitle><manvolnum>5</manvolnum></citerefentry> for more information.</entry>
+  </row>
+  <row id='percent'>
+    <entry><literal>%%</literal></entry>
+    <entry>Single percent sign</entry>
+    <entry>Use <literal>%%</literal> in place of <literal>%</literal> to specify a single percent sign.</entry>
+  </row>
+</tbody>
diff --git a/man/supported-controllers.xml b/man/supported-controllers.xml
new file mode 100644
index 0000000..61cdf46
--- /dev/null
+++ b/man/supported-controllers.xml
@@ -0,0 +1,14 @@
+<?xml version="1.0"?>
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd">
+
+<!--
+  SPDX-License-Identifier: LGPL-2.1-or-later
+-->
+
+<refsect1>
+
+<para id="controllers-text">The following controller names may be specified: <option>cpu</option>, <option>cpuacct</option>,
+<option>cpuset</option>, <option>io</option>, <option>blkio</option>, <option>memory</option>, <option>devices</option>,
+<option>pids</option>, <option>bpf-firewall</option>, and <option>bpf-devices</option>.</para>
+
+</refsect1>
diff --git a/man/sysctl.d.xml b/man/sysctl.d.xml
new file mode 100644
index 0000000..4d810e6
--- /dev/null
+++ b/man/sysctl.d.xml
@@ -0,0 +1,193 @@
+<?xml version="1.0"?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+<refentry id="sysctl.d"
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sysctl.d</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sysctl.d</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sysctl.d</refname>
+    <refpurpose>Configure kernel parameters at boot</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>/etc/sysctl.d/*.conf</filename></para>
+    <para><filename>/run/sysctl.d/*.conf</filename></para>
+    <para><filename>/usr/lib/sysctl.d/*.conf</filename></para>
+
+    <programlisting>key.name.under.proc.sys = some value
+key/name/under/proc/sys = some value
+key/middle.part.with.dots/foo = 123
+key.middle/part/with/dots.foo = 123
+-key.that.will.not.fail = value
+key.pattern.*.with.glob = whatever
+-key.pattern.excluded.with.glob
+key.pattern.overridden.with.glob = custom
+</programlisting>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>At boot,
+    <citerefentry><refentrytitle>systemd-sysctl.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    reads configuration files from the above directories to configure
+    <citerefentry project='man-pages'><refentrytitle>sysctl</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    kernel parameters.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Configuration Format</title>
+
+    <para>The configuration files contain a list of variable
+    assignments, separated by newlines. Empty lines and lines whose
+    first non-whitespace character is <literal>#</literal> or
+    <literal>;</literal> are ignored.</para>
+
+    <para>Note that either <literal>/</literal> or <literal>.</literal> may be used as separators within
+    sysctl variable names. If the first separator is a slash, remaining slashes and dots are left intact. If
+    the first separator is a dot, dots and slashes are interchanged.
+    <literal>kernel.domainname=foo</literal> and <literal>kernel/domainname=foo</literal> are equivalent and
+    will cause <literal>foo</literal> to be written to
+    <filename>/proc/sys/kernel/domainname</filename>. Either
+    <literal>net.ipv4.conf.enp3s0/200.forwarding</literal> or
+    <literal>net/ipv4/conf/enp3s0.200/forwarding</literal> may be used to refer to
+    <filename>/proc/sys/net/ipv4/conf/enp3s0.200/forwarding</filename>. A glob
+    <citerefentry project='man-pages'><refentrytitle>glob</refentrytitle><manvolnum>7</manvolnum></citerefentry> pattern may be
+    used to write the same value to all matching keys. Keys for which an explicit pattern exists will be
+    excluded from any glob matching. In addition, a key may be explicitly excluded from being set by any
+    matching glob patterns by specifying the key name prefixed with a <literal>-</literal> character and not
+    followed by <literal>=</literal>, see SYNOPSIS.</para>
+
+    <para>Any access permission errors and attempts to write variables not present on the local system are
+    logged at debug level and do not cause the service to fail. Other types of errors when setting variables
+    are logged with higher priority and cause the service to return failure at the end (after processing
+    other variables). As an exception, if a variable assignment is prefixed with a single
+    <literal>-</literal> character, failure to set the variable for any reason will be logged at debug level
+    and will not cause the service to fail.</para>
+
+    <para>The settings configured with <filename>sysctl.d</filename> files will be applied early on boot. The
+    network interface-specific options will also be applied individually for each network interface as it
+    shows up in the system. (More specifically, <filename>net.ipv4.conf.*</filename>,
+    <filename>net.ipv6.conf.*</filename>, <filename>net.ipv4.neigh.*</filename> and
+    <filename>net.ipv6.neigh.*</filename>).</para>
+
+    <para>Many sysctl parameters only become available when certain
+    kernel modules are loaded. Modules are usually loaded on demand,
+    e.g. when certain hardware is plugged in or network brought up.
+    This means that
+    <citerefentry><refentrytitle>systemd-sysctl.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    which runs during early boot will not configure such parameters if
+    they become available after it has run. To set such parameters, it
+    is recommended to add an
+    <citerefentry><refentrytitle>udev</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+    rule to set those parameters when they become available.
+    Alternatively, a slightly simpler and less efficient option is to
+    add the module to
+    <citerefentry><refentrytitle>modules-load.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    causing it to be loaded statically before sysctl settings are
+    applied (see example below).</para>
+  </refsect1>
+
+  <xi:include href="standard-conf.xml" xpointer="confd" />
+
+  <refsect1>
+    <title>Examples</title>
+    <example>
+      <title>Set kernel YP domain name</title>
+      <para><filename>/etc/sysctl.d/domain-name.conf</filename>:
+      </para>
+
+      <programlisting>kernel.domainname=example.com</programlisting>
+    </example>
+
+    <example>
+      <title>Apply settings available only when a certain module is loaded (method one)</title>
+      <para><filename>/etc/udev/rules.d/99-bridge.rules</filename>:
+      </para>
+
+      <programlisting>ACTION=="add", SUBSYSTEM=="module", KERNEL=="br_netfilter", \
+      RUN+="/usr/lib/systemd/systemd-sysctl --prefix=/net/bridge"
+</programlisting>
+
+      <para><filename>/etc/sysctl.d/bridge.conf</filename>:
+      </para>
+
+      <programlisting>net.bridge.bridge-nf-call-ip6tables = 0
+net.bridge.bridge-nf-call-iptables = 0
+net.bridge.bridge-nf-call-arptables = 0
+</programlisting>
+
+      <para>This method applies settings when the module is
+      loaded. Please note that, unless the <filename>br_netfilter</filename>
+      module is loaded, bridged packets will not be filtered by
+      Netfilter (starting with kernel 3.18), so simply not loading the
+      module is sufficient to avoid filtering.</para>
+    </example>
+
+    <example>
+      <title>Apply settings available only when a certain module is loaded (method two)</title>
+      <para><filename>/etc/modules-load.d/bridge.conf</filename>:
+      </para>
+
+      <programlisting>br_netfilter</programlisting>
+
+      <para><filename>/etc/sysctl.d/bridge.conf</filename>:
+      </para>
+
+      <programlisting>net.bridge.bridge-nf-call-ip6tables = 0
+net.bridge.bridge-nf-call-iptables = 0
+net.bridge.bridge-nf-call-arptables = 0
+</programlisting>
+
+      <para>This method forces the module to be always loaded. Please
+      note that, unless the <filename>br_netfilter</filename> module is
+      loaded, bridged packets will not be filtered with Netfilter
+      (starting with kernel 3.18), so simply not loading the module is
+      sufficient to avoid filtering.</para>
+    </example>
+
+    <example>
+      <title>Set network routing properties for all interfaces</title>
+      <para><filename>/etc/sysctl.d/20-rp_filter.conf</filename>:</para>
+
+      <programlisting>net.ipv4.conf.default.rp_filter = 2
+net.ipv4.conf.*.rp_filter = 2
+-net.ipv4.conf.all.rp_filter
+net.ipv4.conf.hub0.rp_filter = 1
+</programlisting>
+
+      <para>The <option>rp_filter</option> key will be set to "2" for all interfaces, except "hub0". We set
+      <filename>net.ipv4.conf.default.rp_filter</filename> first, so any interfaces which are added
+      <emphasis>later</emphasis> will get this value (this also covers any interfaces detected while we're
+      running). The glob matches any interfaces which were detected <emphasis>earlier</emphasis>. The glob
+      will also match <filename>net.ipv4.conf.all.rp_filter</filename>, which we don't want to set at all, so
+      it is explicitly excluded. And "hub0" is excluded from the glob because it has an explicit setting.
+      </para>
+    </example>
+
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-sysctl.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-delta</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>sysctl</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>sysctl.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>modprobe</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/system-only.xml b/man/system-only.xml
new file mode 100644
index 0000000..afd3d32
--- /dev/null
+++ b/man/system-only.xml
@@ -0,0 +1,16 @@
+<?xml version="1.0"?>
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd">
+
+<!--
+  SPDX-License-Identifier: LGPL-2.1-or-later
+-->
+
+<refsect1>
+
+<para id="singular">This option is only available for system services and is not supported for services
+running in per-user instances of the service manager.</para>
+
+<para id="plural">These options are only available for system services and are not supported for services
+running in per-user instances of the service manager.</para>
+
+</refsect1>
diff --git a/man/system-or-user-ns.xml b/man/system-or-user-ns.xml
new file mode 100644
index 0000000..532c1ef
--- /dev/null
+++ b/man/system-or-user-ns.xml
@@ -0,0 +1,20 @@
+<?xml version="1.0"?>
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd">
+
+<!--
+  SPDX-License-Identifier: LGPL-2.1-or-later
+-->
+
+<refsect1>
+
+<para id="singular">This option is only available for system services, or for services running in per-user
+ instances of the service manager in which case <varname>PrivateUsers=</varname> is implicitly enabled
+ (requires unprivileged user namespaces support to be enabled in the kernel via the
+ <literal>kernel.unprivileged_userns_clone=</literal> sysctl).</para>
+
+<para id="plural">These options are only available for system services, or for services running in per-user
+ instances of the service manager in which case <varname>PrivateUsers=</varname> is implicitly enabled
+ (requires unprivileged user namespaces support to be enabled in the kernel via the
+ <literal>kernel.unprivileged_userns_clone=</literal> sysctl).</para>
+
+</refsect1>
diff --git a/man/systemctl.xml b/man/systemctl.xml
new file mode 100644
index 0000000..25b6e46
--- /dev/null
+++ b/man/systemctl.xml
@@ -0,0 +1,2888 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [
+<!ENTITY % entities SYSTEM "custom-entities.ent" >
+%entities;
+]>
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemctl"
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemctl</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemctl</refentrytitle>
+    <manvolnum>1</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemctl</refname>
+    <refpurpose>Control the systemd system and service manager</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <cmdsynopsis>
+      <command>systemctl</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="plain">COMMAND</arg>
+      <arg choice="opt" rep="repeat">UNIT</arg>
+    </cmdsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>systemctl</command> may be used to introspect and
+    control the state of the <literal>systemd</literal> system and
+    service manager. Please refer to
+    <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    for an introduction into the basic concepts and functionality this
+    tool manages.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Commands</title>
+
+    <para>The following commands are understood:</para>
+
+    <refsect2>
+      <title>Unit Commands (Introspection and Modification)</title>
+
+      <variablelist>
+        <varlistentry>
+          <term><command>list-units</command> <optional><replaceable>PATTERN</replaceable>…</optional></term>
+
+          <listitem>
+            <para>List units that <command>systemd</command> currently has in memory. This includes units that are
+            either referenced directly or through a dependency, units that are pinned by applications programmatically,
+            or units that were active in the past and have failed. By default only units which are active, have pending
+            jobs, or have failed are shown; this can be changed with option <option>--all</option>. If one or more
+            <replaceable>PATTERN</replaceable>s are specified, only units matching one of them are shown. The units
+            that are shown are additionally filtered by <option>--type=</option> and <option>--state=</option> if those
+            options are specified.</para>
+
+            <para>Note that this command does not show unit templates, but only instances of unit
+            templates. Units templates that aren't instantiated are not runnable, and will thus never show up
+            in the output of this command. Specifically this means that <filename>foo@.service</filename>
+            will never be shown in this list — unless instantiated, e.g. as
+            <filename>foo@bar.service</filename>. Use <command>list-unit-files</command> (see below) for
+            listing installed unit template files.</para>
+
+            <para>Produces output similar to
+            <programlisting>  UNIT                         LOAD   ACTIVE SUB     DESCRIPTION
+  sys-module-fuse.device       loaded active plugged /sys/module/fuse
+  -.mount                      loaded active mounted Root Mount
+  boot-efi.mount               loaded active mounted /boot/efi
+  systemd-journald.service     loaded active running Journal Service
+  systemd-logind.service       loaded active running Login Service
+● user@1000.service            loaded failed failed  User Manager for UID 1000
+  …
+  systemd-tmpfiles-clean.timer loaded active waiting Daily Cleanup of Temporary Directories
+
+LOAD   = Reflects whether the unit definition was properly loaded.
+ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
+SUB    = The low-level unit activation state, values depend on unit type.
+
+123 loaded units listed. Pass --all to see loaded but inactive units, too.
+To show all installed unit files use 'systemctl list-unit-files'.</programlisting></para>
+
+            <para>The header and the last unit of a given type are underlined if the terminal supports
+            that. A colored dot is shown next to services which were masked, not found, or otherwise
+            failed.</para>
+
+            <para>The LOAD column shows the load state, one of <constant>loaded</constant>,
+            <constant>not-found</constant>, <constant>bad-setting</constant>, <constant>error</constant>,
+            <constant>masked</constant>. The ACTIVE columns shows the general unit state, one of
+            <constant>active</constant>, <constant>reloading</constant>, <constant>inactive</constant>,
+            <constant>failed</constant>, <constant>activating</constant>, <constant>deactivating</constant>. The SUB
+            column shows the unit-type-specific detailed state of the unit, possible values vary by unit type. The list
+            of possible LOAD, ACTIVE, and SUB states is not constant and new systemd releases may both add and remove
+            values. <programlisting>systemctl --state=help</programlisting> command may be used to display the
+            current set of possible values.</para>
+
+            <para>This is the default command.</para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><command>list-automounts</command> <optional><replaceable>PATTERN</replaceable>…</optional></term>
+
+          <listitem>
+            <para>List automount units currently in memory, ordered by mount path.  If one or more
+            <replaceable>PATTERN</replaceable>s are specified, only automount units matching one of them are shown.
+            Produces output similar to
+            <programlisting>
+WHAT        WHERE                    MOUNTED IDLE TIMEOUT UNIT
+/dev/sdb1   /mnt/test                no      120s         mnt-test.automount
+binfmt_misc /proc/sys/fs/binfmt_misc yes     0            proc-sys-fs-binfmt_misc.automount
+
+2 automounts listed.</programlisting>
+            </para>
+
+            <para>Also see <option>--show-types</option>, <option>--all</option>, and <option>--state=</option>.</para>
+
+            <xi:include href="version-info.xml" xpointer="v252"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><command>list-paths</command> <optional><replaceable>PATTERN</replaceable>…</optional></term>
+
+          <listitem>
+            <para>List path units currently in memory, ordered by path.  If one or more
+            <replaceable>PATTERN</replaceable>s are specified, only path units matching one of them are shown.
+            Produces output similar to
+            <programlisting>
+PATH                           CONDITION         UNIT                               ACTIVATES
+/run/systemd/ask-password      DirectoryNotEmpty systemd-ask-password-plymouth.path systemd-ask-password-plymouth.service
+/run/systemd/ask-password      DirectoryNotEmpty systemd-ask-password-wall.path     systemd-ask-password-wall.service
+/var/cache/cups/org.cups.cupsd PathExists        cups.path                          cups.service
+
+3 paths listed.</programlisting>
+            </para>
+
+            <para>Also see <option>--show-types</option>, <option>--all</option>, and <option>--state=</option>.</para>
+
+            <xi:include href="version-info.xml" xpointer="v254"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><command>list-sockets</command> <optional><replaceable>PATTERN</replaceable>…</optional></term>
+
+          <listitem>
+            <para>List socket units currently in memory, ordered by listening address.  If one or more
+            <replaceable>PATTERN</replaceable>s are specified, only socket units matching one of them are
+            shown. Produces output similar to
+            <programlisting>
+LISTEN           UNIT                        ACTIVATES
+/dev/initctl     systemd-initctl.socket      systemd-initctl.service
+…
+[::]:22          sshd.socket                 sshd.service
+kobject-uevent 1 systemd-udevd-kernel.socket systemd-udevd.service
+
+5 sockets listed.</programlisting>
+            Note: because the addresses might contains spaces, this output
+            is not suitable for programmatic consumption.
+            </para>
+
+            <para>Also see <option>--show-types</option>, <option>--all</option>, and <option>--state=</option>.</para>
+
+            <xi:include href="version-info.xml" xpointer="v202"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><command>list-timers</command> <optional><replaceable>PATTERN</replaceable>…</optional></term>
+
+          <listitem>
+            <para>List timer units currently in memory, ordered by the time they elapse next. If one or more
+            <replaceable>PATTERN</replaceable>s are specified, only units matching one of them are shown.
+            Produces output similar to
+            <programlisting>
+NEXT                         LEFT          LAST                         PASSED     UNIT                         ACTIVATES
+-                            -             Thu 2017-02-23 13:40:29 EST  3 days ago ureadahead-stop.timer        ureadahead-stop.service
+Sun 2017-02-26 18:55:42 EST  1min 14s left Thu 2017-02-23 13:54:44 EST  3 days ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
+Sun 2017-02-26 20:37:16 EST  1h 42min left Sun 2017-02-26 11:56:36 EST  6h ago     apt-daily.timer              apt-daily.service
+Sun 2017-02-26 20:57:49 EST  2h 3min left  Sun 2017-02-26 11:56:36 EST  6h ago     snapd.refresh.timer          snapd.refresh.service
+            </programlisting>
+            </para>
+
+            <para><emphasis>NEXT</emphasis> shows the next time the timer will run.</para>
+            <para><emphasis>LEFT</emphasis> shows how long till the next time the timer runs.</para>
+            <para><emphasis>LAST</emphasis> shows the last time the timer ran.</para>
+            <para><emphasis>PASSED</emphasis> shows how long has passed since the timer last ran.</para>
+            <para><emphasis>UNIT</emphasis> shows the name of the timer</para>
+            <para><emphasis>ACTIVATES</emphasis> shows the name the service the timer activates when it runs.</para>
+
+            <para>Also see <option>--all</option> and <option>--state=</option>.</para>
+
+            <xi:include href="version-info.xml" xpointer="v209"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><command>is-active <replaceable>PATTERN</replaceable>…</command></term>
+
+          <listitem>
+            <para>Check whether any of the specified units are active
+            (i.e. running). Returns an exit code
+            <constant>0</constant> if at least one is active, or
+            non-zero otherwise. Unless <option>--quiet</option> is
+            specified, this will also print the current unit state to
+            standard output.</para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><command>is-failed <optional><replaceable>PATTERN</replaceable>…</optional></command></term>
+
+          <listitem>
+            <para>Check whether any of the specified units is in the "failed" state. If no unit is specified,
+            check whether there are any failed units, which corresponds to the <literal>degraded</literal> state
+            returned by <command>is-system-running</command>. Returns an exit code <constant>0</constant>
+            if at least one has failed, non-zero otherwise. Unless <option>--quiet</option> is specified, this
+            will also print the current unit or system state to standard output.</para>
+
+            <xi:include href="version-info.xml" xpointer="v197"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><command>status</command> <optional><replaceable>PATTERN</replaceable>…|<replaceable>PID</replaceable>…]</optional></term>
+
+          <listitem>
+            <para>Show runtime status information about the whole system or about one or more units followed
+            by most recent log data from the journal. If no positional arguments are specified, and no unit
+            filter is given with <option>--type=</option>, <option>--state=</option>, or
+            <option>--failed</option>, shows the status of the whole system. If combined with
+            <option>--all</option>, follows that with the status of all units. If positional arguments are
+            specified, each positional argument is treated as either a unit name to show, or a glob pattern
+            to show units whose names match that pattern, or a PID to show the unit containing that PID. When
+            <option>--type=</option>, <option>--state=</option>, or <option>--failed</option> are used, units
+            are additionally filtered by the TYPE and ACTIVE state.</para>
+
+            <para>This function is intended to generate human-readable output. If you are looking for
+            computer-parsable output, use <command>show</command> instead. By default, this function only
+            shows 10 lines of output and ellipsizes lines to fit in the terminal window. This can be changed
+            with <option>--lines</option> and <option>--full</option>, see above. In addition,
+            <command>journalctl --unit=<replaceable>NAME</replaceable></command> or <command>journalctl
+            --user-unit=<replaceable>NAME</replaceable></command> use a similar filter for messages and might
+            be more convenient.</para>
+
+            <para>Note that this operation only displays <emphasis>runtime</emphasis> status, i.e. information about
+            the current invocation of the unit (if it is running) or the most recent invocation (if it is not
+            running anymore, and has not been released from memory). Information about earlier invocations,
+            invocations from previous system boots, or prior invocations that have already been released from
+            memory may be retrieved via <command>journalctl --unit=</command>.</para>
+
+            <para>systemd implicitly loads units as necessary, so just running the <command>status</command>
+            will attempt to load a file. The command is thus not useful for determining if something was
+            already loaded or not.  The units may possibly also be quickly unloaded after the operation is
+            completed if there's no reason to keep it in memory thereafter.</para>
+
+            <example>
+              <title>Example output from systemctl status </title>
+
+              <programlisting>$ systemctl status bluetooth
+● bluetooth.service - Bluetooth service
+   Loaded: loaded (/usr/lib/systemd/system/bluetooth.service; enabled; preset: enabled)
+   Active: active (running) since Wed 2017-01-04 13:54:04 EST; 1 weeks 0 days ago
+     Docs: man:bluetoothd(8)
+ Main PID: 930 (bluetoothd)
+   Status: "Running"
+    Tasks: 1
+   Memory: 648.0K
+      CPU: 435ms
+   CGroup: /system.slice/bluetooth.service
+           └─930 /usr/lib/bluetooth/bluetoothd
+
+Jan 12 10:46:45 example.com bluetoothd[8900]: Not enough free handles to register service
+Jan 12 10:46:45 example.com bluetoothd[8900]: Current Time Service could not be registered
+Jan 12 10:46:45 example.com bluetoothd[8900]: gatt-time-server: Input/output error (5)
+</programlisting>
+
+            <para>The dot ("●") uses color on supported terminals to summarize the unit state at a
+            glance. Along with its color, its shape varies according to its state:
+            <literal>inactive</literal> or <literal>maintenance</literal> is a white circle ("○"),
+            <literal>active</literal> is a green dot ("●"), <literal>deactivating</literal> is a white dot,
+            <literal>failed</literal> or <literal>error</literal> is a red cross ("×"), and
+            <literal>reloading</literal> is a green clockwise circle arrow ("↻").</para>
+
+            <para>The "Loaded:" line in the output will show <literal>loaded</literal> if the unit has been
+            loaded into memory. Other possible values for "Loaded:" include: <literal>error</literal> if
+            there was a problem loading it, <literal>not-found</literal> if no unit file was found for this
+            unit, <literal>bad-setting</literal> if an essential unit file setting could not be parsed and
+            <literal>masked</literal> if the unit file has been masked. Along with showing the path to the
+            unit file, this line will also show the enablement state.  Enabled units are included in the
+            dependency network between units, and thus are started at boot or via some other form of
+            activation.  See the full table of possible enablement states — including the definition of
+            <literal>masked</literal> — in the documentation for the <command>is-enabled</command> command.
+            </para>
+
+            <para>The "Active:" line shows active state.  The value is usually <literal>active</literal> or
+            <literal>inactive</literal>. Active could mean started, bound, plugged in, etc depending on the
+            unit type.  The unit could also be in process of changing states, reporting a state of
+            <literal>activating</literal> or <literal>deactivating</literal>. A special
+            <literal>failed</literal> state is entered when the service failed in some way, such as a crash,
+            exiting with an error code or timing out. If the failed state is entered the cause will be logged
+            for later reference.</para>
+            </example>
+
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><command>show</command> <optional><replaceable>PATTERN</replaceable>…|<replaceable>JOB</replaceable>…</optional></term>
+
+          <listitem>
+            <para>Show properties of one or more units, jobs, or the manager itself. If no argument is specified,
+            properties of the manager will be shown. If a unit name is specified, properties of the unit are shown, and
+            if a job ID is specified, properties of the job are shown. By default, empty properties are suppressed. Use
+            <option>--all</option> to show those too. To select specific properties to show, use
+            <option>--property=</option>. This command is intended to be used whenever computer-parsable output is
+            required. Use <command>status</command> if you are looking for formatted human-readable output.</para>
+
+            <para>Many properties shown by <command>systemctl show</command> map directly to configuration settings of
+            the system and service manager and its unit files. Note that the properties shown by the command are
+            generally more low-level, normalized versions of the original configuration settings and expose runtime
+            state in addition to configuration. For example, properties shown for service units include the service's
+            current main process identifier as <literal>MainPID</literal> (which is runtime state), and time settings
+            are always exposed as properties ending in the <literal>…USec</literal> suffix even if a matching
+            configuration options end in <literal>…Sec</literal>, because microseconds is the normalized time unit used
+            internally by the system and service manager.</para>
+
+            <para>For details about many of these properties, see the documentation of the D-Bus interface
+            backing these properties, see
+            <citerefentry><refentrytitle>org.freedesktop.systemd1</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><command>cat <replaceable>PATTERN</replaceable>…</command></term>
+
+          <listitem>
+            <para>Show backing files of one or more units. Prints the
+            "fragment" and "drop-ins" (source files) of units. Each
+            file is preceded by a comment which includes the file
+            name. Note that this shows the contents of the backing files
+            on disk, which may not match the system manager's
+            understanding of these units if any unit files were
+            updated on disk and the <command>daemon-reload</command>
+            command wasn't issued since.</para>
+
+            <xi:include href="version-info.xml" xpointer="v209"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><command>help <replaceable>PATTERN</replaceable>…|<replaceable>PID</replaceable>…</command></term>
+
+          <listitem>
+            <para>Show manual pages for one or more units, if
+            available. If a PID is given, the manual pages for the unit
+            the process belongs to are shown.</para>
+
+            <xi:include href="version-info.xml" xpointer="v185"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term>
+            <command>list-dependencies</command>
+            <optional><replaceable>UNIT</replaceable>...</optional>
+          </term>
+
+          <listitem>
+            <para>Shows units required and wanted by the specified
+            units. This recursively lists units following the
+            <varname>Requires=</varname>, <varname>Requisite=</varname>,
+            <varname>Wants=</varname>, <varname>ConsistsOf=</varname>,
+            <varname>BindsTo=</varname>, and <varname>Upholds=</varname>
+            dependencies. If no units are specified,
+            <filename>default.target</filename> is implied.</para>
+
+            <para>The units that are shown are additionally filtered by <option>--type=</option> and
+            <option>--state=</option> if those options are specified. Note that we won't be able to
+            use a tree structure in this case, so <option>--plain</option> is implied.</para>
+
+            <para>By default, only target units are recursively
+            expanded. When <option>--all</option> is passed, all other
+            units are recursively expanded as well.</para>
+
+            <para>Options <option>--reverse</option>,
+            <option>--after</option>, <option>--before</option>
+            may be used to change what types of dependencies
+            are shown.</para>
+
+            <para>Note that this command only lists units currently loaded into memory by the service manager. In
+            particular, this command is not suitable to get a comprehensive list at all reverse dependencies on a
+            specific unit, as it won't list the dependencies declared by units currently not loaded.</para>
+
+            <xi:include href="version-info.xml" xpointer="v198"/>
+          </listitem>
+        </varlistentry>
+
+        <!-- Commands that modify unit state start here -->
+
+        <varlistentry>
+          <term><command>start <replaceable>PATTERN</replaceable>…</command></term>
+
+          <listitem>
+            <para>Start (activate) one or more units specified on the command line.</para>
+
+            <para>Note that unit glob patterns expand to names of units currently in memory. Units which are
+            not active and are not in a failed state usually are not in memory, and will not be matched by
+            any pattern. In addition, in case of instantiated units, systemd is often unaware of the instance
+            name until the instance has been started. Therefore, using glob patterns with
+            <command>start</command> has limited usefulness. Also, secondary alias names of units are not
+            considered.</para>
+
+            <para>Option <option>--all</option> may be used to also operate on inactive units which are
+            referenced by other loaded units. Note that this is not the same as operating on "all" possible
+            units, because as the previous paragraph describes, such a list is ill-defined. Nevertheless,
+            <command>systemctl start --all <replaceable>GLOB</replaceable></command> may be useful if all the
+            units that should match the pattern are pulled in by some target which is known to be loaded.
+            </para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><command>stop <replaceable>PATTERN</replaceable>…</command></term>
+
+          <listitem>
+            <para>Stop (deactivate) one or more units specified on the command line.</para>
+
+            <para>This command will fail if the unit does not exist or if stopping of the unit is prohibited (see
+            <varname>RefuseManualStop=</varname> in
+            <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
+            It will <emphasis>not</emphasis> fail if any of the commands configured to stop the unit
+            (<varname>ExecStop=</varname>, etc.) fail, because the manager will still forcibly terminate the
+            unit.</para>
+
+            <para>If a unit that gets stopped can still be triggered by other units, a warning containing
+            the names of the triggering units is shown. <option>--no-warn</option> can be used to suppress
+            the warning.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><command>reload <replaceable>PATTERN</replaceable>…</command></term>
+
+          <listitem>
+            <para>Asks all units listed on the command line to reload
+            their configuration. Note that this will reload the
+            service-specific configuration, not the unit configuration
+            file of systemd. If you want systemd to reload the
+            configuration file of a unit, use the
+            <command>daemon-reload</command> command. In other words:
+            for the example case of Apache, this will reload Apache's
+            <filename>httpd.conf</filename> in the web server, not the
+            <filename>apache.service</filename> systemd unit
+            file.</para>
+
+            <para>This command should not be confused with the
+            <command>daemon-reload</command> command.</para>
+          </listitem>
+
+        </varlistentry>
+        <varlistentry>
+          <term><command>restart <replaceable>PATTERN</replaceable>…</command></term>
+
+          <listitem>
+            <para>Stop and then start one or more units specified on the command line. If the units are not running
+            yet, they will be started.</para>
+
+            <para>Note that restarting a unit with this command does not necessarily flush out all of the unit's
+            resources before it is started again. For example, the per-service file descriptor storage facility (see
+            <varname>FileDescriptorStoreMax=</varname> in
+            <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>) will
+            remain intact as long as the unit has a job pending, and is only cleared when the unit is fully stopped and
+            no jobs are pending anymore. If it is intended that the file descriptor store is flushed out, too, during a
+            restart operation an explicit <command>systemctl stop</command> command followed by <command>systemctl
+            start</command> should be issued.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><command>try-restart <replaceable>PATTERN</replaceable>…</command></term>
+
+          <listitem>
+            <para>Stop and then start one or more units specified on the
+            command line if the units are running. This does nothing
+            if units are not running.</para>
+            <!-- Note that we don't document condrestart here, as that is just compatibility support, and we generally
+                 don't document that. -->
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><command>reload-or-restart <replaceable>PATTERN</replaceable>…</command></term>
+
+          <listitem>
+            <para>Reload one or more units if they support it. If not, stop and then start them instead. If the units
+            are not running yet, they will be started.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><command>try-reload-or-restart <replaceable>PATTERN</replaceable>…</command></term>
+
+          <listitem>
+            <para>Reload one or more units if they support it. If not, stop and then start them instead. This does
+            nothing if the units are not running.</para>
+            <!-- Note that we don't document force-reload here, as that is just compatibility support, and we generally
+                 don't document that. -->
+
+                 <xi:include href="version-info.xml" xpointer="v229"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><command>isolate <replaceable>UNIT</replaceable></command></term>
+
+          <listitem>
+            <para>Start the unit specified on the command line and its dependencies
+            and stop all others, unless they have
+            <option>IgnoreOnIsolate=yes</option> (see
+            <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
+            If a unit name with no extension is given, an extension of
+            <literal>.target</literal> will be assumed.</para>
+
+            <para>This command is dangerous, since it will immediately stop processes that are not enabled in
+            the new target, possibly including the graphical environment or terminal you are currently using.
+            </para>
+
+            <para>Note that this operation is allowed only on units where
+            <option>AllowIsolate=</option> is enabled. See
+            <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+            for details.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><command>kill <replaceable>PATTERN</replaceable>…</command></term>
+
+          <listitem>
+            <para>Send a UNIX process signal to one or more processes of the unit. Use
+            <option>--kill-whom=</option> to select which process to send the signal to. Use
+            <option>--signal=</option> to select the signal to send. Combine with
+            <option>--kill-value=</option> to enqueue a POSIX Realtime Signal with an associated
+            value.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><command>clean <replaceable>PATTERN</replaceable>…</command></term>
+
+          <listitem>
+            <para>Remove the configuration, state, cache, logs or runtime data of the specified units. Use
+            <option>--what=</option> to select which kind of resource to remove. For service units this may
+            be used to remove the directories configured with <varname>ConfigurationDirectory=</varname>,
+            <varname>StateDirectory=</varname>, <varname>CacheDirectory=</varname>,
+            <varname>LogsDirectory=</varname> and <varname>RuntimeDirectory=</varname>, see
+            <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+            for details. It may also be used to clear the file descriptor store as enabled via
+            <varname>FileDescriptorStoreMax=</varname>, see
+            <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+            for details.  For timer units this may be used to clear out the persistent timestamp data if
+            <varname>Persistent=</varname> is used and <option>--what=state</option> is selected, see
+            <citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry>. This
+            command only applies to units that use either of these settings. If <option>--what=</option> is
+            not specified, the cache and runtime data as well as the file descriptor store are removed (as
+            these three types of resources are generally redundant and reproducible on the next invocation of
+            the unit). Note that the specified units must be stopped to invoke this operation.</para>
+
+            <xi:include href="version-info.xml" xpointer="v243"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><command>freeze <replaceable>PATTERN</replaceable>…</command></term>
+
+          <listitem>
+            <para>Freeze one or more units specified on the
+            command line using cgroup freezer</para>
+
+            <para>Freezing the unit will cause all processes contained within the cgroup corresponding to the unit
+            to be suspended. Being suspended means that unit's processes won't be scheduled to run on CPU until thawed.
+            Note that this command is supported only on systems that use unified cgroup hierarchy. Unit is automatically
+            thawed just before we execute a job against the unit, e.g. before the unit is stopped.</para>
+
+            <xi:include href="version-info.xml" xpointer="v246"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><command>thaw <replaceable>PATTERN</replaceable>…</command></term>
+
+          <listitem>
+            <para>Thaw (unfreeze) one or more units specified on the
+            command line.</para>
+
+            <para>This is the inverse operation to the <command>freeze</command> command and resumes the execution of
+            processes in the unit's cgroup.</para>
+
+            <xi:include href="version-info.xml" xpointer="v246"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><command>set-property <replaceable>UNIT</replaceable> <replaceable>PROPERTY</replaceable>=<replaceable>VALUE</replaceable>…</command></term>
+
+          <listitem>
+            <para>Set the specified unit properties at runtime where
+            this is supported. This allows changing configuration
+            parameter properties such as resource control settings at
+            runtime. Not all properties may be changed at runtime, but
+            many resource control settings (primarily those in
+            <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>)
+            may. The changes are applied immediately, and stored on disk
+            for future boots, unless <option>--runtime</option> is
+            passed, in which case the settings only apply until the
+            next reboot. The syntax of the property assignment follows
+            closely the syntax of assignments in unit files.</para>
+
+            <para>Example: <command>systemctl set-property foobar.service CPUWeight=200</command></para>
+
+            <para>If the specified unit appears to be inactive, the
+            changes will be only stored on disk as described
+            previously hence they will be effective when the unit will
+            be started.</para>
+
+            <para>Note that this command allows changing multiple properties at the same time, which is
+            preferable over setting them individually.</para>
+
+            <para>Example: <command>systemctl set-property foobar.service CPUWeight=200 MemoryMax=2G IPAccounting=yes</command></para>
+
+            <para>Like with unit file configuration settings, assigning an empty setting usually resets a
+            property to its defaults.</para>
+
+            <para>Example: <command>systemctl set-property avahi-daemon.service IPAddressDeny=</command></para>
+
+            <xi:include href="version-info.xml" xpointer="v206"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term>
+            <command>bind</command>
+            <replaceable>UNIT</replaceable>
+            <replaceable>PATH</replaceable>
+            [<replaceable>PATH</replaceable>]
+          </term>
+
+          <listitem><para>Bind-mounts a file or directory from the host into the specified unit's mount
+          namespace. The first path argument is the source file or directory on the host, the second path
+          argument is the destination file or directory in the unit's mount namespace. When the latter is
+          omitted, the destination path in the unit's mount namespace is the same as the source path on the
+          host. When combined with the <option>--read-only</option> switch, a ready-only bind mount is
+          created. When combined with the <option>--mkdir</option> switch, the destination path is first
+          created before the mount is applied.</para>
+
+          <para>Note that this option is currently only supported for units that run within a mount namespace
+          (e.g.: with <option>RootImage=</option>, <option>PrivateMounts=</option>, etc.). This command
+          supports bind-mounting directories, regular files, device nodes, <constant>AF_UNIX</constant>
+          socket nodes, as well as FIFOs.  The bind mount is ephemeral, and it is undone as soon as the
+          current unit process exists. Note that the namespace mentioned here, where the bind mount will be
+          added to, is the one where the main service process runs. Other processes (those exececuted by
+          <option>ExecReload=</option>, <option>ExecStartPre=</option>, etc.) run in distinct namespaces.
+          </para>
+
+          <para>If supported by the kernel, any prior mount on the selected target will be replaced by the
+          new mount. If not supported, any prior mount will be over-mounted, but remain pinned and
+          inaccessible.</para>
+
+          <xi:include href="version-info.xml" xpointer="v248"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term>
+            <command>mount-image</command>
+            <replaceable>UNIT</replaceable>
+            <replaceable>IMAGE</replaceable>
+            [<replaceable>PATH</replaceable>
+            [<replaceable>PARTITION_NAME</replaceable>:<replaceable>MOUNT_OPTIONS</replaceable>]]
+          </term>
+
+          <listitem><para>Mounts an image from the host into the specified unit's mount namespace. The first
+          path argument is the source image on the host, the second path argument is the destination
+          directory in the unit's mount namespace (i.e. inside
+          <option>RootImage=</option>/<option>RootDirectory=</option>). The following argument, if any, is
+          interpreted as a colon-separated tuple of partition name and comma-separated list of mount options
+          for that partition. The format is the same as the service <option>MountImages=</option>
+          setting. When combined with the <option>--read-only</option> switch, a ready-only mount is
+          created. When combined with the <option>--mkdir</option> switch, the destination path is first
+          created before the mount is applied.</para>
+
+          <para>Note that this option is currently only supported for units that run within a mount namespace
+          (i.e. with <option>RootImage=</option>, <option>PrivateMounts=</option>, etc.). Note that the
+          namespace mentioned here where the image mount will be added to, is the one where the main service
+          process runs. Note that the namespace mentioned here, where the bind mount will be
+          added to, is the one where the main service process runs. Other processes (those exececuted by
+          <option>ExecReload=</option>, <option>ExecStartPre=</option>, etc.) run in distinct namespaces.
+          </para>
+
+          <para>If supported by the kernel, any prior mount on the selected target will be replaced by the
+          new mount. If not supported, any prior mount will be over-mounted, but remain pinned and
+          inaccessible.</para>
+
+          <para>Example:
+          <programlisting>systemctl mount-image foo.service /tmp/img.raw /var/lib/image root:ro,nosuid</programlisting>
+          <programlisting>systemctl mount-image --mkdir bar.service /tmp/img.raw /var/lib/baz/img</programlisting>
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v248"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><command>service-log-level</command> <replaceable>SERVICE</replaceable> [<replaceable>LEVEL</replaceable>]</term>
+
+          <listitem><para>If the <replaceable>LEVEL</replaceable> argument is not given, print the current
+          log level as reported by service <replaceable>SERVICE</replaceable>.</para>
+
+          <para>If the optional argument <replaceable>LEVEL</replaceable> is provided, then change the
+          current log level of the service to <replaceable>LEVEL</replaceable>. The log level should be a
+          typical syslog log level, i.e. a value in the range 0…7 or one of the strings
+          <constant>emerg</constant>, <constant>alert</constant>, <constant>crit</constant>,
+          <constant>err</constant>, <constant>warning</constant>, <constant>notice</constant>,
+          <constant>info</constant>, <constant>debug</constant>; see <citerefentry
+          project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+          for details.</para>
+
+          <para>The service must have the appropriate
+          <varname>BusName=<replaceable>destination</replaceable></varname> property and also implement the
+          generic
+          <citerefentry><refentrytitle>org.freedesktop.LogControl1</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+          interface. (<filename>systemctl</filename> will use the generic D-Bus protocol to access the
+          <interfacename>org.freedesktop.LogControl1.LogLevel</interfacename> interface for the D-Bus name
+          <replaceable>destination</replaceable>.)</para>
+
+          <xi:include href="version-info.xml" xpointer="v247"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><command>service-log-target</command> <replaceable>SERVICE</replaceable> [<replaceable>TARGET</replaceable>]</term>
+
+          <listitem><para>If the <replaceable>TARGET</replaceable> argument is not given, print the current
+          log target as reported by service <replaceable>SERVICE</replaceable>.</para>
+
+          <para>If the optional argument <replaceable>TARGET</replaceable> is provided, then change the
+          current log target of the service to <replaceable>TARGET</replaceable>. The log target should be
+          one of the strings <constant>console</constant> (for log output to the service's standard error
+          stream), <constant>kmsg</constant> (for log output to the kernel log buffer),
+          <constant>journal</constant> (for log output to
+          <citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+          using the native journal protocol), <constant>syslog</constant> (for log output to the classic
+          syslog socket <filename>/dev/log</filename>), <constant>null</constant> (for no log output
+          whatsoever) or <constant>auto</constant> (for an automatically determined choice, typically
+          equivalent to <constant>console</constant> if the service is invoked interactively, and
+          <constant>journal</constant> or <constant>syslog</constant> otherwise).</para>
+
+          <para>For most services, only a small subset of log targets make sense. In particular, most
+          "normal" services should only implement <constant>console</constant>, <constant>journal</constant>,
+          and <constant>null</constant>. Anything else is only appropriate for low-level services that
+          are active in very early boot before proper logging is established.</para>
+
+          <para>The service must have the appropriate
+          <varname>BusName=<replaceable>destination</replaceable></varname> property and also implement the
+          generic
+          <citerefentry><refentrytitle>org.freedesktop.LogControl1</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+          interface. (<filename>systemctl</filename> will use the generic D-Bus protocol to access the
+          <interfacename>org.freedesktop.LogControl1.LogLevel</interfacename> interface for the D-Bus name
+          <replaceable>destination</replaceable>.)</para>
+
+          <xi:include href="version-info.xml" xpointer="v247"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><command>reset-failed [<replaceable>PATTERN</replaceable>…]</command></term>
+
+          <listitem>
+            <para>Reset the <literal>failed</literal> state of the specified units, or if no unit name is passed, reset
+            the state of all units. When a unit fails in some way (i.e. process exiting with non-zero error code,
+            terminating abnormally or timing out), it will automatically enter the <literal>failed</literal> state and
+            its exit code and status is recorded for introspection by the administrator until the service is
+            stopped/re-started or reset with this command.</para>
+
+            <para>In addition to resetting the <literal>failed</literal> state of a unit it also resets various other
+            per-unit properties: the start rate limit counter of all unit types is reset to zero, as is the restart
+            counter of service units. Thus, if a unit's start limit (as configured with
+            <varname>StartLimitIntervalSec=</varname>/<varname>StartLimitBurst=</varname>) is hit and the unit refuses
+            to be started again, use this command to make it startable again.</para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><command>whoami [<replaceable>PID</replaceable>…]</command></term>
+
+          <listitem><para>Returns the units the processes referenced by the given PIDs belong to (one per
+          line). If no PID is specified returns the unit the <command>systemctl</command> command is invoked
+          in.</para>
+
+          <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+        </varlistentry>
+
+      </variablelist>
+    </refsect2>
+
+    <refsect2>
+      <title>Unit File Commands</title>
+
+      <variablelist>
+        <varlistentry>
+          <term><command>list-unit-files</command> <optional><replaceable>PATTERN…</replaceable></optional></term>
+
+          <listitem>
+            <para>List unit files installed on the system, in combination with their enablement state (as
+            reported by <command>is-enabled</command>). If one or more <replaceable>PATTERN</replaceable>s
+            are specified, only unit files whose name matches one of them are shown (patterns matching unit
+            file system paths are not supported).</para>
+
+            <para>Unlike <command>list-units</command> this command will list template units in addition to
+            explicitly instantiated units.</para>
+
+            <xi:include href="version-info.xml" xpointer="v233"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><command>enable <replaceable>UNIT</replaceable>…</command></term>
+          <term><command>enable <replaceable>PATH</replaceable>…</command></term>
+
+          <listitem>
+            <para>Enable one or more units or unit instances. This will create a set of symlinks, as encoded in the
+            [Install] sections of the indicated unit files. After the symlinks have been created,
+            the system manager configuration is reloaded (in a way equivalent to <command>daemon-reload</command>), in
+            order to ensure the changes are taken into account immediately. Note that this does
+            <emphasis>not</emphasis> have the effect of also starting any of the units being enabled. If this is
+            desired, combine this command with the <option>--now</option> switch, or invoke <command>start</command>
+            with appropriate arguments later. Note that in case of unit instance enablement (i.e. enablement of units of
+            the form <filename>foo@bar.service</filename>), symlinks named the same as instances are created in the
+            unit configuration directory, however they point to the single template unit file they are instantiated
+            from.</para>
+
+            <para>This command expects either valid unit names (in which case various unit file directories are
+            automatically searched for unit files with appropriate names), or absolute paths to unit files (in which
+            case these files are read directly). If a specified unit file is located outside of the usual unit file
+            directories, an additional symlink is created, linking it into the unit configuration path, thus ensuring
+            it is found when requested by commands such as <command>start</command>. The file system where the linked
+            unit files are located must be accessible when systemd is started (e.g. anything underneath
+            <filename>/home/</filename> or <filename>/var/</filename> is not allowed, unless those directories are
+            located on the root file system).</para>
+
+            <para>This command will print the file system operations executed. This output may be suppressed by passing
+            <option>--quiet</option>.
+            </para>
+
+            <para>Note that this operation creates only the symlinks suggested in the [Install]
+            section of the unit files. While this command is the recommended way to manipulate the unit configuration
+            directory, the administrator is free to make additional changes manually by placing or removing symlinks
+            below this directory. This is particularly useful to create configurations that deviate from the suggested
+            default installation. In this case, the administrator must make sure to invoke
+            <command>daemon-reload</command> manually as necessary, in order to ensure the changes are taken into
+            account.
+            </para>
+
+            <para>When using this operation on units without install information, a warning about it is shown.
+            <option>--no-warn</option> can be used to suppress the warning.</para>
+
+            <para>Enabling units should not be confused with starting (activating) units, as done by the
+            <command>start</command> command. Enabling and starting units is orthogonal: units may be enabled without
+            being started and started without being enabled. Enabling simply hooks the unit into various suggested
+            places (for example, so that the unit is automatically started on boot or when a particular kind of
+            hardware is plugged in). Starting actually spawns the daemon process (in case of service units), or binds
+            the socket (in case of socket units), and so on.</para>
+
+            <para>Depending on whether <option>--system</option>, <option>--user</option>, <option>--runtime</option>,
+            or <option>--global</option> is specified, this enables the unit for the system, for the calling user only,
+            for only this boot of the system, or for all future logins of all users.  Note that in the last case, no
+            systemd daemon configuration is reloaded.</para>
+
+            <para>Using <command>enable</command> on masked units is not supported and results in an error.</para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><command>disable <replaceable>UNIT</replaceable>…</command></term>
+
+          <listitem>
+            <para>Disables one or more units. This removes all symlinks to the unit files backing the specified units
+            from the unit configuration directory, and hence undoes any changes made by <command>enable</command> or
+            <command>link</command>. Note that this removes <emphasis>all</emphasis> symlinks to matching unit files,
+            including manually created symlinks, and not just those actually created by <command>enable</command> or
+            <command>link</command>. Note that while <command>disable</command> undoes the effect of
+            <command>enable</command>, the two commands are otherwise not symmetric, as <command>disable</command> may
+            remove more symlinks than a prior <command>enable</command> invocation of the same unit created.</para>
+
+            <para>This command expects valid unit names only, it does not accept paths to unit files.</para>
+
+            <para>In addition to the units specified as arguments, all units are disabled that are listed in the
+            <varname>Also=</varname> setting contained in the [Install] section of any of the unit
+            files being operated on.</para>
+
+            <para>This command implicitly reloads the system manager configuration after completing the operation. Note
+            that this command does not implicitly stop the units that are being disabled. If this is desired, either
+            combine this command with the <option>--now</option> switch, or invoke the <command>stop</command> command
+            with appropriate arguments later.</para>
+
+            <para>This command will print information about the file system operations (symlink removals)
+            executed. This output may be suppressed by passing <option>--quiet</option>.
+            </para>
+
+            <para>If a unit gets disabled but its triggering units are still active, a warning containing
+            the names of the triggering units is shown. <option>--no-warn</option> can be used to suppress
+            the warning.</para>
+
+            <para>When this command is used with <option>--user</option>, the units being operated on might
+            still be enabled in global scope, and thus get started automatically even after a successful
+            disablement in user scope. In this case, a warning about it is shown, which can be suppressed
+            using <option>--no-warn</option>.</para>
+
+            <para>This command honors <option>--system</option>, <option>--user</option>, <option>--runtime</option>,
+            <option>--global</option> and <option>--no-warn</option> in a similar way as <command>enable</command>.</para>
+
+            <xi:include href="version-info.xml" xpointer="v238"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><command>reenable <replaceable>UNIT</replaceable>…</command></term>
+
+          <listitem>
+            <para>Reenable one or more units, as specified on the command line. This is a combination of
+            <command>disable</command> and <command>enable</command> and is useful to reset the symlinks a unit file is
+            enabled with to the defaults configured in its [Install] section. This command expects
+            a unit name only, it does not accept paths to unit files.</para>
+
+            <xi:include href="version-info.xml" xpointer="v238"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><command>preset <replaceable>UNIT</replaceable>…</command></term>
+
+          <listitem>
+            <para>Reset the enable/disable status one or more unit files, as specified on
+            the command line, to the defaults configured in the preset policy files. This
+            has the same effect as <command>disable</command> or
+            <command>enable</command>, depending how the unit is listed in the preset
+            files.</para>
+
+            <para>Use <option>--preset-mode=</option> to control whether units shall be
+            enabled and disabled, or only enabled, or only disabled.</para>
+
+            <para>If the unit carries no install information, it will be silently ignored
+            by this command. <replaceable>UNIT</replaceable> must be the real unit name,
+            any alias names are ignored silently.</para>
+
+            <para>For more information on the preset policy format, see
+            <citerefentry><refentrytitle>systemd.preset</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+            </para>
+
+            <xi:include href="version-info.xml" xpointer="v238"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><command>preset-all</command></term>
+
+          <listitem>
+            <para>Resets all installed unit files to the defaults
+            configured in the preset policy file (see above).</para>
+
+            <para>Use <option>--preset-mode=</option> to control
+            whether units shall be enabled and disabled, or only
+            enabled, or only disabled.</para>
+
+            <xi:include href="version-info.xml" xpointer="v215"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><command>is-enabled <replaceable>UNIT</replaceable>…</command></term>
+
+          <listitem>
+            <para>Checks whether any of the specified unit files are
+            enabled (as with <command>enable</command>). Returns an
+            exit code of 0 if at least one is enabled, non-zero
+            otherwise. Prints the current enable status (see table).
+            To suppress this output, use <option>--quiet</option>.
+            To show installation targets, use <option>--full</option>.
+            </para>
+
+            <table>
+              <title>
+                <command>is-enabled</command> output
+              </title>
+
+              <tgroup cols='3'>
+                <thead>
+                  <row>
+                    <entry>Name</entry>
+                    <entry>Description</entry>
+                    <entry>Exit Code</entry>
+                  </row>
+                </thead>
+                <tbody>
+                  <row>
+                    <entry><literal>enabled</literal></entry>
+                    <entry morerows='1'>Enabled via <filename>.wants/</filename>, <filename>.requires/</filename> or <varname>Alias=</varname> symlinks (permanently in <filename>/etc/systemd/system/</filename>, or transiently in <filename>/run/systemd/system/</filename>).</entry>
+                    <entry morerows='1'>0</entry>
+                  </row>
+                  <row>
+                    <entry><literal>enabled-runtime</literal></entry>
+                  </row>
+                  <row>
+                    <entry><literal>linked</literal></entry>
+                    <entry morerows='1'>Made available through one or more symlinks to the unit file (permanently in <filename>/etc/systemd/system/</filename> or transiently in <filename>/run/systemd/system/</filename>), even though the unit file might reside outside of the unit file search path.</entry>
+                    <entry morerows='1'>&gt; 0</entry>
+                  </row>
+                  <row>
+                    <entry><literal>linked-runtime</literal></entry>
+                  </row>
+                  <row>
+                    <entry><literal>alias</literal></entry>
+                    <entry>The name is an alias (symlink to another unit file).</entry>
+                    <entry>0</entry>
+                  </row>
+                  <row>
+                    <entry><literal>masked</literal></entry>
+                    <entry morerows='1'>Completely disabled, so that any start operation on it fails (permanently in <filename>/etc/systemd/system/</filename> or transiently in <filename>/run/systemd/systemd/</filename>).</entry>
+                    <entry morerows='1'>&gt; 0</entry>
+                  </row>
+                  <row>
+                    <entry><literal>masked-runtime</literal></entry>
+                  </row>
+                  <row>
+                    <entry><literal>static</literal></entry>
+                    <entry>The unit file is not enabled, and has no provisions for enabling in the [Install] unit file section.</entry>
+                    <entry>0</entry>
+                  </row>
+                  <row>
+                    <entry><literal>indirect</literal></entry>
+                    <entry>The unit file itself is not enabled, but it has a non-empty <varname>Also=</varname> setting in the [Install] unit file section, listing other unit files that might be enabled, or it has an alias under a different name through a symlink that is not specified in <varname>Also=</varname>. For template unit files, an instance different than the one specified in <varname>DefaultInstance=</varname> is enabled.</entry>
+                    <entry>0</entry>
+                  </row>
+                  <row>
+                    <entry><literal>disabled</literal></entry>
+                    <entry>The unit file is not enabled, but contains an [Install] section with installation instructions.</entry>
+                    <entry>&gt; 0</entry>
+                  </row>
+                  <row>
+                    <entry><literal>generated</literal></entry>
+                    <entry>The unit file was generated dynamically via a generator tool. See <citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>. Generated unit files may not be enabled, they are enabled implicitly by their generator.</entry>
+                    <entry>0</entry>
+                  </row>
+                  <row>
+                    <entry><literal>transient</literal></entry>
+                    <entry>The unit file has been created dynamically with the runtime API. Transient units may not be enabled.</entry>
+                    <entry>0</entry>
+                  </row>
+                  <row>
+                    <entry><literal>bad</literal></entry>
+                    <entry>The unit file is invalid or another error occurred. Note that <command>is-enabled</command> will not actually return this state, but print an error message instead. However the unit file listing printed by <command>list-unit-files</command> might show it.</entry>
+                    <entry>&gt; 0</entry>
+                  </row>
+                  <row>
+                    <entry><literal>not-found</literal></entry>
+                    <entry>The unit file doesn't exist.</entry>
+                    <entry>4</entry>
+                  </row>
+                </tbody>
+              </tgroup>
+            </table>
+
+              <xi:include href="version-info.xml" xpointer="v238"/>
+
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><command>mask <replaceable>UNIT</replaceable>…</command></term>
+
+          <listitem>
+            <para>Mask one or more units, as specified on the command line. This will link these unit files
+            to <filename>/dev/null</filename>, making it impossible to start them. This is a stronger version
+            of <command>disable</command>, since it prohibits all kinds of activation of the unit, including
+            enablement and manual activation. Use this option with care. This honors the
+            <option>--runtime</option> option to only mask temporarily until the next reboot of the
+            system. The <option>--now</option> option may be used to ensure that the units are also
+            stopped. This command expects valid unit names only, it does not accept unit file paths.</para>
+
+            <para>Note that this will create a symlink under the unit's name in
+            <filename>/etc/systemd/system/</filename> (in case <option>--runtime</option> is not specified)
+            or <filename>/run/systemd/system/</filename> (in case <option>--runtime</option> is
+            specified). If a matching unit file already exists under these directories this operation will
+            hence fail. This means that the operation is primarily useful to mask units shipped by the vendor
+            (as those are shipped in <filename>/usr/lib/systemd/system/</filename> and not the aforementioned
+            two directories), but typically doesn't work for units created locally (as those are typically
+            placed precisely in the two aforementioned directories). Similar restrictions apply for
+            <option>--user</option> mode, in which case the directories are below the user's home directory
+            however.</para>
+
+            <para>If a unit gets masked but its triggering units are still active, a warning containing
+            the names of the triggering units is shown. <option>--no-warn</option> can be used to suppress
+            the warning.</para>
+
+            <xi:include href="version-info.xml" xpointer="v238"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><command>unmask <replaceable>UNIT</replaceable>…</command></term>
+
+          <listitem>
+            <para>Unmask one or more unit files, as specified on the command line. This will undo the effect of
+            <command>mask</command>. This command expects valid unit names only, it does not accept unit file
+            paths.</para>
+
+            <xi:include href="version-info.xml" xpointer="v238"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><command>link <replaceable>PATH</replaceable>…</command></term>
+
+          <listitem>
+            <para>Link a unit file that is not in the unit file search path into the unit file search path. This
+            command expects an absolute path to a unit file. The effect of this may be undone with
+            <command>disable</command>. The effect of this command is that a unit file is made available for commands
+            such as <command>start</command>, even though it is not installed directly in the unit search path. The
+            file system where the linked unit files are located must be accessible when systemd is started
+            (e.g. anything underneath <filename>/home/</filename> or <filename>/var/</filename> is not allowed, unless
+            those directories are located on the root file system).</para>
+
+            <xi:include href="version-info.xml" xpointer="v233"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><command>revert <replaceable>UNIT</replaceable>…</command></term>
+
+          <listitem>
+            <para>Revert one or more unit files to their vendor versions. This command removes drop-in configuration
+            files that modify the specified units, as well as any user-configured unit file that overrides a matching
+            vendor supplied unit file. Specifically, for a unit <literal>foo.service</literal> the matching directories
+            <literal>foo.service.d/</literal> with all their contained files are removed, both below the persistent and
+            runtime configuration directories (i.e. below <filename>/etc/systemd/system</filename> and
+            <filename>/run/systemd/system</filename>); if the unit file has a vendor-supplied version (i.e. a unit file
+            located below <filename>/usr/</filename>) any matching persistent or runtime unit file that overrides it is
+            removed, too. Note that if a unit file has no vendor-supplied version (i.e. is only defined below
+            <filename>/etc/systemd/system</filename> or <filename>/run/systemd/system</filename>, but not in a unit
+            file stored below <filename>/usr/</filename>), then it is not removed. Also, if a unit is masked, it is
+            unmasked.</para>
+
+            <para>Effectively, this command may be used to undo all changes made with <command>systemctl
+            edit</command>, <command>systemctl set-property</command> and <command>systemctl mask</command> and puts
+            the original unit file with its settings back in effect.</para>
+
+            <xi:include href="version-info.xml" xpointer="v230"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><command>add-wants <replaceable>TARGET</replaceable>
+          <replaceable>UNIT</replaceable>…</command></term>
+          <term><command>add-requires <replaceable>TARGET</replaceable>
+          <replaceable>UNIT</replaceable>…</command></term>
+
+          <listitem>
+            <para>Adds <literal>Wants=</literal> or <literal>Requires=</literal>
+            dependencies, respectively, to the specified
+            <replaceable>TARGET</replaceable> for one or more units. </para>
+
+            <para>This command honors <option>--system</option>,
+            <option>--user</option>, <option>--runtime</option> and
+            <option>--global</option> in a way similar to
+            <command>enable</command>.</para>
+
+            <xi:include href="version-info.xml" xpointer="v217"/>
+
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><command>edit <replaceable>UNIT</replaceable>…</command></term>
+
+          <listitem>
+            <para>Edit a drop-in snippet or a whole replacement file if
+            <option>--full</option> is specified, to extend or override the
+            specified unit.</para>
+
+            <para>Depending on whether <option>--system</option> (the default),
+            <option>--user</option>, or <option>--global</option> is specified,
+            this command creates a drop-in file for each unit either for the system,
+            for the calling user, or for all futures logins of all users. Then,
+            the editor (see the "Environment" section below) is invoked on
+            temporary files which will be written to the real location if the
+            editor exits successfully.</para>
+
+            <para>If <option>--drop-in=</option> is specified, the given drop-in file name
+            will be used instead of the default <filename>override.conf</filename>.</para>
+
+            <para>If <option>--full</option> is specified, this will copy the
+            original units instead of creating drop-in files.</para>
+
+            <para>If <option>--force</option> is specified and any units do
+            not already exist, new unit files will be opened for editing.</para>
+
+            <para>If <option>--runtime</option> is specified, the changes will
+            be made temporarily in <filename>/run/</filename> and they will be
+            lost on the next reboot.</para>
+
+            <para>If the temporary file is empty upon exit, the modification of
+            the related unit is canceled.</para>
+
+            <para>After the units have been edited, systemd configuration is
+            reloaded (in a way that is equivalent to <command>daemon-reload</command>).
+            </para>
+
+            <para>Note that this command cannot be used to remotely edit units
+            and that you cannot temporarily edit units which are in
+            <filename>/etc/</filename>, since they take precedence over
+            <filename>/run/</filename>.</para>
+
+            <xi:include href="version-info.xml" xpointer="v218"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><command>get-default</command></term>
+
+          <listitem>
+            <para>Return the default target to boot into. This returns
+            the target unit name <filename>default.target</filename>
+            is aliased (symlinked) to.</para>
+
+            <xi:include href="version-info.xml" xpointer="v205"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><command>set-default <replaceable>TARGET</replaceable></command></term>
+
+          <listitem>
+            <para>Set the default target to boot into. This sets
+            (symlinks) the <filename>default.target</filename> alias
+            to the given target unit.</para>
+
+            <xi:include href="version-info.xml" xpointer="v205"/>
+          </listitem>
+        </varlistentry>
+
+      </variablelist>
+    </refsect2>
+
+    <refsect2>
+      <title>Machine Commands</title>
+
+      <variablelist>
+        <varlistentry>
+          <term><command>list-machines</command> <optional><replaceable>PATTERN</replaceable>…</optional></term>
+
+          <listitem>
+            <para>List the host and all running local containers with
+            their state. If one or more
+            <replaceable>PATTERN</replaceable>s are specified, only
+            containers matching one of them are shown.
+            </para>
+
+            <xi:include href="version-info.xml" xpointer="v212"/>
+          </listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+
+    <refsect2>
+      <title>Job Commands</title>
+
+      <variablelist>
+        <varlistentry>
+          <term><command>list-jobs <optional><replaceable>PATTERN…</replaceable></optional></command></term>
+
+          <listitem>
+            <para>List jobs that are in progress. If one or more
+            <replaceable>PATTERN</replaceable>s are specified, only
+            jobs for units matching one of them are shown.</para>
+
+            <para>When combined with <option>--after</option> or <option>--before</option> the list is augmented with
+            information on which other job each job is waiting for, and which other jobs are waiting for it, see
+            above.</para>
+
+            <xi:include href="version-info.xml" xpointer="v233"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><command>cancel <optional><replaceable>JOB</replaceable>…</optional></command></term>
+
+          <listitem>
+            <para>Cancel one or more jobs specified on the command line
+            by their numeric job IDs. If no job ID is specified, cancel
+            all pending jobs.</para>
+
+            <xi:include href="version-info.xml" xpointer="v233"/>
+          </listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+
+    <refsect2>
+      <title>Environment Commands</title>
+
+      <para><command>systemd</command> supports an environment block that is passed to processes the manager
+      spawns. The names of the variables can contain ASCII letters, digits, and the underscore
+      character. Variable names cannot be empty or start with a digit. In variable values, most characters
+      are allowed, but the whole sequence must be valid UTF-8. (Note that control characters like newline
+      (<constant>NL</constant>), tab (<constant>TAB</constant>), or the escape character
+      (<constant>ESC</constant>), <emphasis>are</emphasis> valid ASCII and thus valid UTF-8). The total
+      length of the environment block is limited to <constant>_SC_ARG_MAX</constant> value defined by
+      <citerefentry project='man-pages'><refentrytitle>sysconf</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+      </para>
+
+      <variablelist>
+        <varlistentry>
+          <term><command>show-environment</command></term>
+
+          <listitem>
+            <para>Dump the systemd manager environment block. This is the environment
+            block that is passed to all processes the manager spawns. The environment
+            block will be dumped in straightforward form suitable for sourcing into
+            most shells. If no special characters or whitespace is present in the variable
+            values, no escaping is performed, and the assignments have the form
+            <literal>VARIABLE=value</literal>. If whitespace or characters which have
+            special meaning to the shell are present, dollar-single-quote escaping is
+            used, and assignments have the form <literal>VARIABLE=$'value'</literal>.
+            This syntax is known to be supported by
+            <citerefentry project='die-net'><refentrytitle>bash</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+            <citerefentry project='die-net'><refentrytitle>zsh</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+            <citerefentry project='die-net'><refentrytitle>ksh</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+            and
+            <citerefentry project='die-net'><refentrytitle>busybox</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s
+            <citerefentry project='die-net'><refentrytitle>ash</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+            but not
+            <citerefentry project='die-net'><refentrytitle>dash</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+            or
+            <citerefentry project='die-net'><refentrytitle>fish</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
+            </para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><command>set-environment <replaceable>VARIABLE=VALUE</replaceable>…</command></term>
+
+          <listitem>
+            <para>Set one or more systemd manager environment variables, as specified on the command
+            line. This command will fail if variable names and values do not conform to the rules listed
+            above.</para>
+
+            <xi:include href="version-info.xml" xpointer="v233"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><command>unset-environment <replaceable>VARIABLE</replaceable>…</command></term>
+
+          <listitem>
+            <para>Unset one or more systemd manager environment
+            variables. If only a variable name is specified, it will be
+            removed regardless of its value. If a variable and a value
+            are specified, the variable is only removed if it has the
+            specified value.</para>
+
+            <xi:include href="version-info.xml" xpointer="v233"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term>
+            <command>import-environment</command>
+            <replaceable>VARIABLE…</replaceable>
+          </term>
+
+          <listitem>
+            <para>Import all, one or more environment variables set on the client into the systemd manager
+            environment block. If a list of environment variable names is passed, client-side values are then
+            imported into the manager's environment block. If any names are not valid environment variable
+            names or have invalid values according to the rules described above, an error is raised. If no
+            arguments are passed, the entire environment block inherited by the <command>systemctl</command>
+            process is imported. In this mode, any inherited invalid environment variables are quietly
+            ignored.</para>
+
+            <para>Importing of the full inherited environment block (calling this command without any
+            arguments) is deprecated. A shell will set dozens of variables which only make sense locally and
+            are only meant for processes which are descendants of the shell. Such variables in the global
+            environment block are confusing to other processes.</para>
+
+            <xi:include href="version-info.xml" xpointer="v209"/>
+          </listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+
+    <refsect2>
+      <title>Manager State Commands</title>
+
+      <variablelist>
+        <varlistentry>
+          <term><command>daemon-reload</command></term>
+
+          <listitem>
+            <para>Reload the systemd manager configuration. This will
+            rerun all generators (see
+            <citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>),
+            reload all unit files, and recreate the entire dependency
+            tree. While the daemon is being reloaded, all sockets
+            systemd listens on behalf of user configuration will stay
+            accessible.</para>
+
+            <para>This command should not be confused with the
+            <command>reload</command> command.</para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><command>daemon-reexec</command></term>
+
+          <listitem>
+            <para>Reexecute the systemd manager. This will serialize the
+            manager state, reexecute the process and deserialize the
+            state again. This command is of little use except for
+            debugging and package upgrades. Sometimes, it might be
+            helpful as a heavy-weight <command>daemon-reload</command>.
+            While the daemon is being reexecuted, all sockets systemd listening
+            on behalf of user configuration will stay accessible.
+            </para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry id='log-level'>
+          <term><command>log-level</command> [<replaceable>LEVEL</replaceable>]</term>
+
+          <listitem><para>If no argument is given, print the current log level of the manager. If an
+          optional argument <replaceable>LEVEL</replaceable> is provided, then the command changes the
+          current log level of the manager to <replaceable>LEVEL</replaceable> (accepts the same values as
+          <option>--log-level=</option> described in
+          <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>).
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v244"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><command>log-target</command> [<replaceable>TARGET</replaceable>]</term>
+
+          <listitem><para>If no argument is given, print the current log target of the manager. If an
+          optional argument <replaceable>TARGET</replaceable> is provided, then the command changes the
+          current log target of the manager to <replaceable>TARGET</replaceable> (accepts the same values as
+          <option>--log-target=</option>, described in
+          <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>).
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v244"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><command>service-watchdogs</command> [yes|no]</term>
+
+          <listitem><para>If no argument is given, print the current state of service runtime watchdogs of
+          the manager. If an optional boolean argument is provided, then globally enables or disables the
+          service runtime watchdogs (<option>WatchdogSec=</option>) and emergency actions (e.g.
+          <option>OnFailure=</option> or <option>StartLimitAction=</option>); see
+          <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+          The hardware watchdog is not affected by this setting.</para>
+
+          <xi:include href="version-info.xml" xpointer="v244"/></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+
+    <refsect2>
+      <title>System Commands</title>
+
+      <variablelist>
+        <varlistentry>
+          <term><command>is-system-running</command></term>
+
+          <listitem>
+            <para>Checks whether the system is operational. This
+            returns success (exit code 0) when the system is fully up
+            and running, specifically not in startup, shutdown or
+            maintenance mode, and with no failed services. Failure is
+            returned otherwise (exit code non-zero). In addition, the
+            current state is printed in a short string to standard
+            output, see the table below. Use <option>--quiet</option> to
+            suppress this output.</para>
+
+            <para>Use <option>--wait</option> to wait until the boot
+            process is completed before printing the current state and
+            returning the appropriate error status. If <option>--wait</option>
+            is in use, states <varname>initializing</varname> or
+            <varname>starting</varname> will not be reported, instead
+            the command will block until a later state (such as
+            <varname>running</varname> or <varname>degraded</varname>)
+            is reached.</para>
+
+            <table>
+              <title><command>is-system-running</command> output</title>
+              <tgroup cols='3'>
+                <colspec colname='name'/>
+                <colspec colname='description'/>
+                <colspec colname='exit-code'/>
+                <thead>
+                  <row>
+                    <entry>Name</entry>
+                    <entry>Description</entry>
+                    <entry>Exit Code</entry>
+                  </row>
+                </thead>
+                <tbody>
+                  <row>
+                    <entry><varname>initializing</varname></entry>
+                    <entry><para>Early bootup, before
+                    <filename>basic.target</filename> is reached
+                    or the <varname>maintenance</varname> state entered.
+                    </para></entry>
+                    <entry>&gt; 0</entry>
+                  </row>
+                  <row>
+                    <entry><varname>starting</varname></entry>
+                    <entry><para>Late bootup, before the job queue
+                    becomes idle for the first time, or one of the
+                    rescue targets are reached.</para></entry>
+                    <entry>&gt; 0</entry>
+                  </row>
+                  <row>
+                    <entry><varname>running</varname></entry>
+                    <entry><para>The system is fully
+                    operational.</para></entry>
+                    <entry>0</entry>
+                  </row>
+                  <row>
+                    <entry><varname>degraded</varname></entry>
+                    <entry><para>The system is operational but one or more
+                    units failed.</para></entry>
+                    <entry>&gt; 0</entry>
+                  </row>
+                  <row>
+                    <entry><varname>maintenance</varname></entry>
+                    <entry><para>The rescue or emergency target is
+                    active.</para></entry>
+                    <entry>&gt; 0</entry>
+                  </row>
+                  <row>
+                    <entry><varname>stopping</varname></entry>
+                    <entry><para>The manager is shutting
+                    down.</para></entry>
+                    <entry>&gt; 0</entry>
+                  </row>
+                  <row>
+                    <entry><varname>offline</varname></entry>
+                    <entry><para>The manager is not
+                    running. Specifically, this is the operational
+                    state if an incompatible program is running as
+                    system manager (PID 1).</para></entry>
+                    <entry>&gt; 0</entry>
+                  </row>
+                  <row>
+                    <entry><varname>unknown</varname></entry>
+                    <entry><para>The operational state could not be
+                    determined, due to lack of resources or another
+                    error cause.</para></entry>
+                    <entry>&gt; 0</entry>
+                  </row>
+                </tbody>
+              </tgroup>
+            </table>
+
+              <xi:include href="version-info.xml" xpointer="v215"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><command>default</command></term>
+
+          <listitem>
+            <para>Enter default mode. This is equivalent to <command>systemctl isolate default.target</command>. This
+            operation is blocking by default, use <option>--no-block</option> to request asynchronous behavior.</para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><command>rescue</command></term>
+
+          <listitem>
+            <para>Enter rescue mode. This is equivalent to <command>systemctl isolate rescue.target</command>. This
+            operation is blocking by default, use <option>--no-block</option> to request asynchronous behavior.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><command>emergency</command></term>
+
+          <listitem>
+            <para>Enter emergency mode. This is equivalent to <command>systemctl isolate
+            emergency.target</command>. This operation is blocking by default, use <option>--no-block</option> to
+            request asynchronous behavior.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><command>halt</command></term>
+
+          <listitem>
+            <para>Shut down and halt the system. This is mostly equivalent to <command>systemctl start halt.target
+            --job-mode=replace-irreversibly --no-block</command>, but also prints a wall message to all users. This command is
+            asynchronous; it will return after the halt operation is enqueued, without waiting for it to complete. Note
+            that this operation will simply halt the OS kernel after shutting down, leaving the hardware powered
+            on. Use <command>systemctl poweroff</command> for powering off the system (see below).</para>
+
+            <para>If combined with <option>--force</option>, shutdown of all running services is skipped, however all
+            processes are killed and all file systems are unmounted or mounted read-only, immediately followed by the
+            system halt.  If <option>--force</option> is specified twice, the operation is immediately executed without
+            terminating any processes or unmounting any file systems. This may result in data loss. Note that when
+            <option>--force</option> is specified twice the halt operation is executed by <command>systemctl</command>
+            itself, and the system manager is not contacted. This means the command should succeed even when the system
+            manager has crashed.</para>
+
+            <para>If combined with <option>--when=</option>, shutdown will be scheduled after the given timestamp.
+            And <option>--when=cancel</option> will cancel the shutdown.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><command>poweroff</command></term>
+
+          <listitem>
+            <para>Shut down and power-off the system. This is mostly equivalent to <command>systemctl start
+            poweroff.target --job-mode=replace-irreversibly --no-block</command>, but also prints a wall message to all
+            users. This command is asynchronous; it will return after the power-off operation is enqueued, without
+            waiting for it to complete.</para>
+
+            <para>This command honors <option>--force</option> and <option>--when=</option> in a similar way
+            as <command>halt</command>.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><command>reboot</command></term>
+
+          <listitem>
+            <para>Shut down and reboot the system.</para>
+
+            <para>This command mostly equivalent to <command>systemctl start reboot.target
+            --job-mode=replace-irreversibly --no-block</command>, but also prints a wall message to all
+            users. This command is asynchronous; it will return after the reboot operation is enqueued,
+            without waiting for it to complete.</para>
+
+            <para>If the switch <option>--reboot-argument=</option> is given, it will be passed as the optional
+            argument to the <citerefentry><refentrytitle>reboot</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+            system call.</para>
+
+            <para>Options <option>--boot-loader-entry=</option>, <option>--boot-loader-menu=</option>, and
+            <option>--firmware-setup</option> can be used to select what to do <emphasis>after</emphasis> the
+            reboot. See the descriptions of those options for details.</para>
+
+            <para>This command honors <option>--force</option> and <option>--when=</option> in a similar way
+            as <command>halt</command>.</para>
+
+            <para>If a new kernel has been loaded via <command>kexec --load</command>, a
+            <command>kexec</command> will be performed instead of a reboot, unless
+            <literal>SYSTEMCTL_SKIP_AUTO_KEXEC=1</literal> has been set. If a new root file system has
+            been set up on <literal>/run/nextroot/</literal>, a <command>soft-reboot</command> will be
+            performed instead of a reboot, unless <literal>SYSTEMCTL_SKIP_AUTO_SOFT_REBOOT=1</literal> has
+            been set.</para>
+
+            <xi:include href="version-info.xml" xpointer="v246"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><command>kexec</command></term>
+
+          <listitem>
+            <para>Shut down and reboot the system via <command>kexec</command>. This command will load a
+            kexec kernel if one wasn't loaded yet or fail. A kernel may be loaded earlier by a separate step,
+            this is particularly useful if a custom initrd or additional kernel command line options are
+            desired. The <option>--force</option> can be used to continue without a kexec kernel, i.e. to
+            perform a normal reboot. The final reboot step is equivalent to
+            <command>systemctl start kexec.target --job-mode=replace-irreversibly --no-block</command>.
+            </para>
+
+            <para>To load a kernel, an enumeration is performed following the
+            <ulink url="https://uapi-group.org/specifications/specs/boot_loader_specification">Boot Loader Specification</ulink>,
+            and the default boot entry is loaded. For this step to succeed, the system must be using UEFI
+            and the boot loader entries must be configured appropriately. <command>bootctl list</command>
+            may be used to list boot entries, see
+            <citerefentry><refentrytitle>bootctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
+            </para>
+
+            <para>This command is asynchronous; it will return after the reboot operation is enqueued,
+            without waiting for it to complete.</para>
+
+            <para>This command honors <option>--force</option> and <option>--when=</option> similarly
+            to <command>halt</command>.</para>
+
+            <para>If a new kernel has been loaded via <command>kexec --load</command>, a
+            <command>kexec</command> will be performed when <command>reboot</command> is invoked, unless
+            <literal>SYSTEMCTL_SKIP_AUTO_KEXEC=1</literal> has been set.</para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><command>soft-reboot</command></term>
+
+          <listitem>
+            <para>Shut down and reboot userspace. This is equivalent to <command>systemctl start
+            soft-reboot.target --job-mode=replace-irreversibly --no-block</command>. This command is
+            asynchronous; it will return after the reboot operation is enqueued, without waiting for it to
+            complete.</para>
+
+            <para>This command honors <option>--force</option> and <option>--when=</option> in a similar way
+            as <command>halt</command>.</para>
+
+            <para>This operation only reboots userspace, leaving the kernel running. See
+            <citerefentry><refentrytitle>systemd-soft-reboot.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+            for details.</para>
+
+            <para>If a new root file system has been set up on <literal>/run/nextroot/</literal>, a
+            <command>soft-reboot</command> will be performed when <command>reboot</command> is invoked,
+            unless <literal>SYSTEMCTL_SKIP_AUTO_SOFT_REBOOT=1</literal> has been set.</para>
+
+            <xi:include href="version-info.xml" xpointer="v254"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><command>exit</command> <optional><replaceable>EXIT_CODE</replaceable></optional></term>
+
+          <listitem>
+            <para>Ask the service manager to quit. This is only supported for user service managers (i.e. in
+            conjunction with the <option>--user</option> option) or in containers and is equivalent to
+            <command>poweroff</command> otherwise. This command is asynchronous; it will return after the exit
+            operation is enqueued, without waiting for it to complete.</para>
+
+            <para>The service manager will exit with the specified exit code, if
+            <replaceable>EXIT_CODE</replaceable> is passed.</para>
+
+            <xi:include href="version-info.xml" xpointer="v227"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><command>switch-root</command> <optional><replaceable>ROOT</replaceable> <optional><replaceable>INIT</replaceable></optional></optional></term>
+
+          <listitem>
+            <para>Switches to a different root directory and executes a new system manager process below it.
+            This is intended for use in the initrd, and will transition from the initrd's system manager
+            process (a.k.a. "init" process, PID 1) to the main system manager process which is loaded from
+            the actual host root files system. This call takes two arguments: the directory that is to become
+            the new root directory, and the path to the new system manager binary below it to execute as PID
+            1.  If both are omitted or the former is an empty string it defaults to
+            <filename>/sysroot/</filename>. If the latter is omitted or is an empty string, a systemd binary
+            will automatically be searched for and used as service manager. If the system manager path is
+            omitted, equal to the empty string or identical to the path to the systemd binary, the state of
+            the initrd's system manager process is passed to the main system manager, which allows later
+            introspection of the state of the services involved in the initrd boot phase.</para>
+
+            <xi:include href="version-info.xml" xpointer="v209"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><command>suspend</command></term>
+
+          <listitem>
+            <para>Suspend the system. This will trigger activation of the special target unit
+            <filename>suspend.target</filename>. This command is asynchronous, and will return after the suspend
+            operation is successfully enqueued. It will not wait for the suspend/resume cycle to complete.</para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><command>hibernate</command></term>
+
+          <listitem>
+            <para>Hibernate the system. This will trigger activation of the special target unit
+            <filename>hibernate.target</filename>. This command is asynchronous, and will return after the hibernation
+            operation is successfully enqueued. It will not wait for the hibernate/thaw cycle to complete.</para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><command>hybrid-sleep</command></term>
+
+          <listitem>
+            <para>Hibernate and suspend the system. This will trigger activation of the special target unit
+            <filename>hybrid-sleep.target</filename>. This command is asynchronous, and will return after the hybrid
+            sleep operation is successfully enqueued. It will not wait for the sleep/wake-up cycle to complete.</para>
+
+            <xi:include href="version-info.xml" xpointer="v196"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><command>suspend-then-hibernate</command></term>
+
+          <listitem>
+            <para>Suspend the system and hibernate it after the delay specified in <filename>systemd-sleep.conf</filename>.
+            This will trigger activation of the special target unit <filename>suspend-then-hibernate.target</filename>.
+            This command is asynchronous, and will return after the hybrid sleep operation is successfully enqueued.
+            It will not wait for the sleep/wake-up or hibernate/thaw cycle to complete.</para>
+
+          <xi:include href="version-info.xml" xpointer="v240"/>
+          </listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+
+    <refsect2>
+      <title>Parameter Syntax</title>
+
+      <para>Unit commands listed above take either a single unit name (designated as <replaceable>UNIT</replaceable>),
+      or multiple unit specifications (designated as <replaceable>PATTERN</replaceable>…). In the first case, the
+      unit name with or without a suffix must be given. If the suffix is not specified (unit name is "abbreviated"),
+      systemctl will append a suitable suffix, <literal>.service</literal> by default, and a type-specific suffix in
+      case of commands which operate only on specific unit types. For example,
+      <programlisting># systemctl start sshd</programlisting> and
+      <programlisting># systemctl start sshd.service</programlisting>
+      are equivalent, as are
+      <programlisting># systemctl isolate default</programlisting>
+      and
+      <programlisting># systemctl isolate default.target</programlisting>
+      Note that (absolute) paths to device nodes are automatically converted to device unit names, and other (absolute)
+      paths to mount unit names.
+      <programlisting># systemctl status /dev/sda
+# systemctl status /home</programlisting>
+      are equivalent to:
+      <programlisting># systemctl status dev-sda.device
+# systemctl status home.mount</programlisting>
+      In the second case, shell-style globs will be matched against the primary names of all units currently in memory;
+      literal unit names, with or without a suffix, will be treated as in the first case. This means that literal unit
+      names always refer to exactly one unit, but globs may match zero units and this is not considered an
+      error.</para>
+
+      <para>Glob patterns use
+      <citerefentry project='man-pages'><refentrytitle>fnmatch</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      so normal shell-style globbing rules are used, and
+      <literal>*</literal>, <literal>?</literal>,
+      <literal>[]</literal> may be used. See
+      <citerefentry project='man-pages'><refentrytitle>glob</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+      for more details. The patterns are matched against the primary names of
+      units currently in memory, and patterns which do not match anything
+      are silently skipped. For example:
+      <programlisting># systemctl stop sshd@*.service</programlisting>
+      will stop all <filename>sshd@.service</filename> instances. Note that alias names of units, and units that aren't
+      in memory are not considered for glob expansion.
+      </para>
+
+      <para>For unit file commands, the specified <replaceable>UNIT</replaceable> should be the name of the unit file
+      (possibly abbreviated, see above), or the absolute path to the unit file:
+      <programlisting># systemctl enable foo.service</programlisting>
+      or
+      <programlisting># systemctl link /path/to/foo.service</programlisting>
+      </para>
+    </refsect2>
+
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>The following options are understood:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><option>-t</option></term>
+        <term><option>--type=</option></term>
+
+        <listitem>
+          <para>The argument is a comma-separated list of unit types such as <option>service</option> and
+          <option>socket</option>. When units are listed with <command>list-units</command>,
+          <command>list-dependencies</command>, <command>show</command>, or <command>status</command>,
+          only units of the specified types will be shown. By default, units of all types are shown.</para>
+
+          <para>As a special case, if one of the arguments is <option>help</option>, a list of allowed values
+          will be printed and the program will exit.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--state=</option></term>
+
+        <listitem>
+          <para>The argument is a comma-separated list of unit LOAD, SUB, or ACTIVE states. When listing
+          units with <command>list-units</command>, <command>list-dependencies</command>, <command>show</command>
+          or <command>status</command>, show only those in the specified states. Use <option>--state=failed</option>
+          or <option>--failed</option> to show only failed units.</para>
+
+          <para>As a special case, if one of the arguments is <option>help</option>, a list of allowed values
+          will be printed and the program will exit.</para>
+
+          <xi:include href="version-info.xml" xpointer="v206"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-p</option></term>
+        <term><option>--property=</option></term>
+
+        <listitem>
+          <para>When showing unit/job/manager properties with the
+          <command>show</command> command, limit display to properties
+          specified in the argument. The argument should be a
+          comma-separated list of property names, such as
+          <literal>MainPID</literal>. Unless specified, all known
+          properties are shown. If specified more than once, all
+          properties with the specified names are shown. Shell
+          completion is implemented for property names.</para>
+
+          <para>For the manager itself,
+          <command>systemctl show</command>
+          will show all available properties, most of which are derived or closely match the options described in
+          <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+          </para>
+
+          <para>Properties for units vary by unit type, so showing any
+          unit (even a non-existent one) is a way to list properties
+          pertaining to this type. Similarly, showing any job will list
+          properties pertaining to all jobs. Properties for units are
+          documented in
+          <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+          and the pages for individual unit types
+          <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+          <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+          etc.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-P</option></term>
+
+        <listitem>
+          <para>Equivalent to <option>--value</option> <option>--property=</option>, i.e. shows the
+          value of the property without the property name or <literal>=</literal>. Note that using
+          <option>-P</option> once will also affect all properties listed with
+          <option>-p</option>/<option>--property=</option>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v246"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-a</option></term>
+        <term><option>--all</option></term>
+
+        <listitem>
+          <para>When listing units with <command>list-units</command>, also show inactive units and
+          units which are following other units. When showing unit/job/manager properties, show all
+          properties regardless whether they are set or not.</para>
+
+          <para>To list all units installed in the file system, use the
+          <command>list-unit-files</command> command instead.</para>
+
+          <para>When listing units with <command>list-dependencies</command>, recursively show
+          dependencies of all dependent units (by default only dependencies of target units are
+          shown).</para>
+
+          <para>When used with <command>status</command>, show journal messages in full, even if they include
+          unprintable characters or are very long. By default, fields with unprintable characters are
+          abbreviated as "blob data". (Note that the pager may escape unprintable characters again.)</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-r</option></term>
+        <term><option>--recursive</option></term>
+
+        <listitem>
+          <para>When listing units, also show units of local
+          containers. Units of local containers will be prefixed with
+          the container name, separated by a single colon character
+          (<literal>:</literal>).</para>
+
+          <xi:include href="version-info.xml" xpointer="v212"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--reverse</option></term>
+
+        <listitem>
+          <para>Show reverse dependencies between units with
+          <command>list-dependencies</command>, i.e. follow
+          dependencies of type <varname>WantedBy=</varname>,
+          <varname>RequiredBy=</varname>, <varname>UpheldBy=</varname>,
+          <varname>PartOf=</varname>, <varname>BoundBy=</varname>,
+          instead of <varname>Wants=</varname> and similar.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v203"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--after</option></term>
+
+        <listitem>
+          <para>With <command>list-dependencies</command>, show the
+          units that are ordered before the specified unit. In other
+          words, recursively list units following the
+          <varname>After=</varname> dependency.</para>
+
+          <para>Note that any <varname>After=</varname> dependency is
+          automatically mirrored to create a
+          <varname>Before=</varname> dependency. Temporal dependencies
+          may be specified explicitly, but are also created implicitly
+          for units which are <varname>WantedBy=</varname> targets
+          (see
+          <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>),
+          and as a result of other directives (for example
+          <varname>RequiresMountsFor=</varname>). Both explicitly
+          and implicitly introduced dependencies are shown with
+          <command>list-dependencies</command>.</para>
+
+          <para>When passed to the <command>list-jobs</command> command, for each printed job show which other jobs are
+          waiting for it. May be combined with <option>--before</option> to show both the jobs waiting for each job as
+          well as all jobs each job is waiting for.</para>
+
+          <xi:include href="version-info.xml" xpointer="v203"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--before</option></term>
+
+        <listitem>
+          <para>With <command>list-dependencies</command>, show the
+          units that are ordered after the specified unit. In other
+          words, recursively list units following the
+          <varname>Before=</varname> dependency.</para>
+
+          <para>When passed to the <command>list-jobs</command> command, for each printed job show which other jobs it
+          is waiting for. May be combined with <option>--after</option> to show both the jobs waiting for each job as
+          well as all jobs each job is waiting for.</para>
+
+          <xi:include href="version-info.xml" xpointer="v212"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--with-dependencies</option></term>
+
+        <listitem>
+          <para>When used with <command>status</command>,
+          <command>cat</command>, <command>list-units</command>, and
+          <command>list-unit-files</command>, those commands print all
+          specified units and the dependencies of those units.</para>
+
+          <para>Options <option>--reverse</option>,
+          <option>--after</option>, <option>--before</option>
+          may be used to change what types of dependencies
+          are shown.</para>
+
+          <xi:include href="version-info.xml" xpointer="v245"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-l</option></term>
+        <term><option>--full</option></term>
+
+        <listitem>
+          <para>Do not ellipsize unit names, process tree entries,
+          journal output, or truncate unit descriptions in the output
+          of <command>status</command>, <command>list-units</command>,
+          <command>list-jobs</command>, and
+          <command>list-timers</command>.</para>
+          <para>Also, show installation targets in the output of
+          <command>is-enabled</command>.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--value</option></term>
+
+        <listitem>
+          <para>When printing properties with <command>show</command>, only print the value, and skip the
+          property name and <literal>=</literal>. Also see option <option>-P</option> above.</para>
+
+        <xi:include href="version-info.xml" xpointer="v230"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--show-types</option></term>
+
+        <listitem>
+          <para>When showing sockets, show the type of the socket.</para>
+
+        <xi:include href="version-info.xml" xpointer="v202"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--job-mode=</option></term>
+
+        <listitem>
+        <para>When queuing a new job, this option controls how to deal with
+        already queued jobs. It takes one of <literal>fail</literal>,
+        <literal>replace</literal>,
+        <literal>replace-irreversibly</literal>,
+        <literal>isolate</literal>,
+        <literal>ignore-dependencies</literal>,
+        <literal>ignore-requirements</literal>,
+        <literal>flush</literal>,
+        <literal>triggering</literal>, or
+        <literal>restart-dependencies</literal>. Defaults to
+        <literal>replace</literal>, except when the
+        <command>isolate</command> command is used which implies the
+        <literal>isolate</literal> job mode.</para>
+
+        <para>If <literal>fail</literal> is specified and a requested
+        operation conflicts with a pending job (more specifically:
+        causes an already pending start job to be reversed into a stop
+        job or vice versa), cause the operation to fail.</para>
+
+        <para>If <literal>replace</literal> (the default) is
+        specified, any conflicting pending job will be replaced, as
+        necessary.</para>
+
+        <para>If <literal>replace-irreversibly</literal> is specified,
+        operate like <literal>replace</literal>, but also mark the new
+        jobs as irreversible. This prevents future conflicting
+        transactions from replacing these jobs (or even being enqueued
+        while the irreversible jobs are still pending). Irreversible
+        jobs can still be cancelled using the <command>cancel</command>
+        command. This job mode should be used on any transaction which
+        pulls in <filename>shutdown.target</filename>.</para>
+
+        <para><literal>isolate</literal> is only valid for start
+        operations and causes all other units to be stopped when the
+        specified unit is started. This mode is always used when the
+        <command>isolate</command> command is used.</para>
+
+        <para><literal>flush</literal> will cause all queued jobs to
+        be canceled when the new job is enqueued.</para>
+
+        <para>If <literal>ignore-dependencies</literal> is specified,
+        then all unit dependencies are ignored for this new job and
+        the operation is executed immediately. If passed, no required
+        units of the unit passed will be pulled in, and no ordering
+        dependencies will be honored. This is mostly a debugging and
+        rescue tool for the administrator and should not be used by
+        applications.</para>
+
+        <para><literal>ignore-requirements</literal> is similar to
+        <literal>ignore-dependencies</literal>, but only causes the
+        requirement dependencies to be ignored, the ordering
+        dependencies will still be honored.</para>
+
+        <para><literal>triggering</literal> may only be used with
+        <command>systemctl stop</command>. In this mode, the specified
+        unit and any active units that trigger it are stopped. See the
+        discussion of
+        <varname>Triggers=</varname> in <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for more information about triggering units.</para>
+
+        <para><literal>restart-dependencies</literal> may only be used with
+        <command>systemctl start</command>. In this mode, dependencies of
+        the specified unit will receive restart propagation, as if a restart
+        job had been enqueued for the unit.</para>
+
+        <xi:include href="version-info.xml" xpointer="v209"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-T</option></term>
+        <term><option>--show-transaction</option></term>
+
+        <listitem>
+          <para>When enqueuing a unit job (for example as effect of a <command>systemctl start</command>
+          invocation or similar), show brief information about all jobs enqueued, covering both the requested
+          job and any added because of unit dependencies. Note that the output will only include jobs
+          immediately part of the transaction requested. It is possible that service start-up program code
+          run as effect of the enqueued jobs might request further jobs to be pulled in. This means that
+          completion of the listed jobs might ultimately entail more jobs than the listed ones.</para>
+
+        <xi:include href="version-info.xml" xpointer="v242"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--fail</option></term>
+
+        <listitem>
+          <para>Shorthand for <option>--job-mode=</option>fail.</para>
+          <para>When used with the <command>kill</command> command,
+          if no units were killed, the operation results in an error.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v227"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--check-inhibitors=</option></term>
+
+        <listitem>
+          <para>When system shutdown or sleep state is requested, this option controls checking of inhibitor
+          locks. It takes one of <literal>auto</literal>, <literal>yes</literal> or
+          <literal>no</literal>. Defaults to <literal>auto</literal>, which will behave like
+          <literal>yes</literal> for interactive invocations (i.e. from a TTY) and <literal>no</literal> for
+          non-interactive invocations. <literal>yes</literal> lets the request respect inhibitor locks.
+          <literal>no</literal> lets the request ignore inhibitor locks.</para>
+
+          <para>Applications can establish inhibitor locks to prevent certain important operations (such as
+          CD burning) from being interrupted by system shutdown or sleep. Any user may take these locks and
+          privileged users may override these locks. If any locks are taken, shutdown and sleep state
+          requests will normally fail (unless privileged). However, if <literal>no</literal> is specified or
+          <literal>auto</literal> is specified on a non-interactive requests, the operation will be
+          attempted. If locks are present, the operation may require additional privileges.</para>
+
+          <para>Option <option>--force</option> provides another way to override inhibitors.</para>
+
+          <xi:include href="version-info.xml" xpointer="v248"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-i</option></term>
+
+        <listitem>
+          <para>Shortcut for <option>--check-inhibitors=no</option>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v198"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--dry-run</option></term>
+
+        <listitem>
+          <para>Just print what would be done. Currently supported by verbs
+          <command>halt</command>, <command>poweroff</command>, <command>reboot</command>,
+          <command>kexec</command>, <command>suspend</command>, <command>hibernate</command>,
+          <command>hybrid-sleep</command>, <command>suspend-then-hibernate</command>,
+          <command>default</command>, <command>rescue</command>,
+          <command>emergency</command>, and <command>exit</command>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v236"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-q</option></term>
+        <term><option>--quiet</option></term>
+
+        <listitem>
+          <para>Suppress printing of the results of various commands
+          and also the hints about truncated log lines. This does not
+          suppress output of commands for which the printed output is
+          the only result (like <command>show</command>). Errors are
+          always printed.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--no-warn</option></term>
+
+        <listitem>
+          <para>Don't generate the warnings shown by default in the following cases:
+          <itemizedlist>
+            <listitem>
+              <para>when <command>systemctl</command> is invoked without procfs mounted on
+              <filename>/proc/</filename>,</para>
+            </listitem>
+            <listitem>
+              <para>when using <command>enable</command> or <command>disable</command> on units without
+              install information (i.e. don't have or have an empty [Install] section),</para>
+            </listitem>
+            <listitem>
+              <para>when using <command>disable</command> combined with <option>--user</option> on units
+              that are enabled in global scope,</para>
+            </listitem>
+            <listitem>
+              <para>when a <command>stop</command>-ped, <command>disable</command>-d, or <command>mask</command>-ed
+              unit still has active triggering units.</para>
+            </listitem>
+          </itemizedlist>
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v253"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--no-block</option></term>
+
+        <listitem>
+          <para>Do not synchronously wait for the requested operation
+          to finish. If this is not specified, the job will be
+          verified, enqueued and <command>systemctl</command> will
+          wait until the unit's start-up is completed. By passing this
+          argument, it is only verified and enqueued. This option may not be
+          combined with <option>--wait</option>.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--wait</option></term>
+
+        <listitem>
+          <para>Synchronously wait for started units to terminate again.
+          This option may not be combined with <option>--no-block</option>.
+          Note that this will wait forever if any given unit never terminates
+          (by itself or by getting stopped explicitly); particularly services
+          which use <literal>RemainAfterExit=yes</literal>.</para>
+
+          <para>When used with <command>is-system-running</command>, wait
+          until the boot process is completed before returning.</para>
+
+          <xi:include href="version-info.xml" xpointer="v232"/>
+        </listitem>
+      </varlistentry>
+
+      <xi:include href="user-system-options.xml" xpointer="user" />
+      <xi:include href="user-system-options.xml" xpointer="system" />
+
+      <varlistentry>
+        <term><option>--failed</option></term>
+
+        <listitem>
+          <para>List units in failed state. This is equivalent to
+          <option>--state=failed</option>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v233"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--no-wall</option></term>
+
+        <listitem>
+          <para>Do not send wall message before halt, power-off and reboot.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--global</option></term>
+
+        <listitem>
+          <para>When used with <command>enable</command> and
+          <command>disable</command>, operate on the global user
+          configuration directory, thus enabling or disabling a unit
+          file globally for all future logins of all users.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--no-reload</option></term>
+
+        <listitem>
+          <para>When used with <command>enable</command> and
+          <command>disable</command>, do not implicitly reload daemon
+          configuration after executing the changes.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--no-ask-password</option></term>
+
+        <listitem>
+          <para>When used with <command>start</command> and related
+          commands, disables asking for passwords. Background services
+          may require input of a password or passphrase string, for
+          example to unlock system hard disks or cryptographic
+          certificates. Unless this option is specified and the
+          command is invoked from a terminal,
+          <command>systemctl</command> will query the user on the
+          terminal for the necessary secrets. Use this option to
+          switch this behavior off. In this case, the password must be
+          supplied by some other means (for example graphical password
+          agents) or the service might fail. This also disables
+          querying the user for authentication for privileged
+          operations.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--kill-whom=</option></term>
+
+        <listitem>
+          <para>When used with <command>kill</command>, choose which processes to send a UNIX process signal
+          to. Must be one of <option>main</option>, <option>control</option> or <option>all</option> to
+          select whether to kill only the main process, the control process or all processes of the unit. The
+          main process of the unit is the one that defines the life-time of it. A control process of a unit
+          is one that is invoked by the manager to induce state changes of it. For example, all processes
+          started due to the <varname>ExecStartPre=</varname>, <varname>ExecStop=</varname> or
+          <varname>ExecReload=</varname> settings of service units are control processes. Note that there is
+          only one control process per unit at a time, as only one state change is executed at a time. For
+          services of type <varname>Type=forking</varname>, the initial process started by the manager for
+          <varname>ExecStart=</varname> is a control process, while the process ultimately forked off by that
+          one is then considered the main process of the unit (if it can be determined). This is different
+          for service units of other types, where the process forked off by the manager for
+          <varname>ExecStart=</varname> is always the main process itself. A service unit consists of zero or
+          one main process, zero or one control process plus any number of additional processes. Not all unit
+          types manage processes of these types however. For example, for mount units, control processes are
+          defined (which are the invocations of <filename>&MOUNT_PATH;</filename> and
+          <filename>&UMOUNT_PATH;</filename>), but no main process is defined. If omitted, defaults to
+          <option>all</option>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v252"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--kill-value=</option><replaceable>INT</replaceable></term>
+
+        <listitem><para>If used with the <command>kill</command> command, enqueues a signal along with the
+        specified integer value parameter to the specified process(es). This operation is only available for
+        POSIX Realtime Signals (i.e. <option>--signal=SIGRTMIN+…</option> or
+        <option>--signal=SIGRTMAX-…</option>), and ensures the signals are generated via the <citerefentry
+        project='man-pages'><refentrytitle>sigqueue</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+        system call, rather than <citerefentry
+        project='man-pages'><refentrytitle>kill</refentrytitle><manvolnum>3</manvolnum></citerefentry>. The
+        specified value must be a 32-bit signed integer, and may be specified either in decimal, in
+        hexadecimal (if prefixed with <literal>0x</literal>), octal (if prefixed with <literal>0o</literal>)
+        or binary (if prefixed with <literal>0b</literal>)</para>
+
+        <para>If this option is used the signal will only be enqueued on the control or main process of the
+        unit, never on other processes belonging to the unit, i.e. <option>--kill-whom=all</option> will only
+        affect main and control processes but no other processes.</para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+      </varlistentry>
+
+      <xi:include href="standard-options.xml" xpointer="signal" />
+
+      <varlistentry>
+        <term><option>--what=</option></term>
+
+        <listitem>
+          <para>Select what type of per-unit resources to remove when the <command>clean</command> command is
+          invoked, see above. Takes one of <constant>configuration</constant>, <constant>state</constant>,
+          <constant>cache</constant>, <constant>logs</constant>, <constant>runtime</constant>,
+          <constant>fdstore</constant> to select the type of resource. This option may be specified more than
+          once, in which case all specified resource types are removed. Also accepts the special value
+          <constant>all</constant> as a shortcut for specifying all six resource types. If this option is not
+          specified defaults to the combination of <constant>cache</constant>, <constant>runtime</constant>
+          and <constant>fdstore</constant>, i.e. the three kinds of resources that are generally considered
+          to be redundant and can be reconstructed on next invocation. Note that the explicit removal of the
+          <constant>fdstore</constant> resource type is only useful if the
+          <varname>FileDescriptorStorePreserve=</varname> option is enabled, since the file descriptor store
+          is otherwise cleaned automatically when the unit is stopped.</para>
+
+        <xi:include href="version-info.xml" xpointer="v243"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-f</option></term>
+        <term><option>--force</option></term>
+
+        <listitem>
+          <para>When used with <command>enable</command>, overwrite
+          any existing conflicting symlinks.</para>
+
+          <para>When used with <command>edit</command>, create all of the
+          specified units which do not already exist.</para>
+
+          <para>When used with <command>halt</command>, <command>poweroff</command>, <command>reboot</command> or
+          <command>kexec</command>, execute the selected operation without shutting down all units. However, all
+          processes will be killed forcibly and all file systems are unmounted or remounted read-only. This is hence a
+          drastic but relatively safe option to request an immediate reboot. If <option>--force</option> is specified
+          twice for these operations (with the exception of <command>kexec</command>), they will be executed
+          immediately, without terminating any processes or unmounting any file systems. Warning: specifying
+          <option>--force</option> twice with any of these operations might result in data loss. Note that when
+          <option>--force</option> is specified twice the selected operation is executed by
+          <command>systemctl</command> itself, and the system manager is not contacted. This means the command should
+          succeed even when the system manager has crashed.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--message=</option></term>
+
+        <listitem>
+          <para>When used with <command>halt</command>, <command>poweroff</command> or <command>reboot</command>, set a
+          short message explaining the reason for the operation. The message will be logged together with the default
+          shutdown message.</para>
+
+        <xi:include href="version-info.xml" xpointer="v225"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--now</option></term>
+
+        <listitem>
+          <para>When used with <command>enable</command>, the units
+          will also be started. When used with <command>disable</command> or
+          <command>mask</command>, the units will also be stopped. The start
+          or stop operation is only carried out when the respective enable or
+          disable operation has been successful.</para>
+
+        <xi:include href="version-info.xml" xpointer="v220"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--root=</option></term>
+
+        <listitem>
+          <para>When used with
+          <command>enable</command>/<command>disable</command>/<command>is-enabled</command>
+          (and related commands), use the specified root path when looking for unit
+          files. If this option is present, <command>systemctl</command> will operate on
+          the file system directly, instead of communicating with the <command>systemd</command>
+          daemon to carry out changes.</para>
+        </listitem>
+
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--image=<replaceable>image</replaceable></option></term>
+
+        <listitem><para>Takes a path to a disk image file or block device node. If specified, all operations
+        are applied to file system in the indicated disk image. This option is similar to
+        <option>--root=</option>, but operates on file systems stored in disk images or block devices. The
+        disk image should either contain just a file system or a set of file systems within a GPT partition
+        table, following the <ulink url="https://uapi-group.org/specifications/specs/discoverable_partitions_specification">Discoverable Partitions
+        Specification</ulink>. For further information on supported disk images, see
+        <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s
+        switch of the same name.</para>
+
+        <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+      </varlistentry>
+
+      <xi:include href="standard-options.xml" xpointer="image-policy-open" />
+
+      <varlistentry>
+        <term><option>--runtime</option></term>
+
+        <listitem>
+          <para>When used with <command>enable</command>,
+          <command>disable</command>, <command>edit</command>,
+          (and related commands), make changes only temporarily, so
+          that they are lost on the next reboot. This will have the
+          effect that changes are not made in subdirectories of
+          <filename>/etc/</filename> but in <filename>/run/</filename>,
+          with identical immediate effects, however, since the latter
+          is lost on reboot, the changes are lost too.</para>
+
+          <para>Similarly, when used with
+          <command>set-property</command>, make changes only
+          temporarily, so that they are lost on the next
+          reboot.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--preset-mode=</option></term>
+
+        <listitem>
+          <para>Takes one of <literal>full</literal> (the default),
+          <literal>enable-only</literal>,
+          <literal>disable-only</literal>. When used with the
+          <command>preset</command> or <command>preset-all</command>
+          commands, controls whether units shall be disabled and
+          enabled according to the preset rules, or only enabled, or
+          only disabled.</para>
+
+        <xi:include href="version-info.xml" xpointer="v215"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-n</option></term>
+        <term><option>--lines=</option></term>
+
+        <listitem>
+          <para>When used with <command>status</command>, controls the number of journal lines to show,
+          counting from the most recent ones. Takes a positive integer argument, or 0 to disable journal
+          output. Defaults to 10.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-o</option></term>
+        <term><option>--output=</option></term>
+
+        <listitem>
+          <para>When used with <command>status</command>, controls the
+          formatting of the journal entries that are shown. For the
+          available choices, see
+          <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
+          Defaults to <literal>short</literal>.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--firmware-setup</option></term>
+
+        <listitem>
+          <para>When used with the <command>reboot</command>, <command>poweroff</command>, or
+          <command>halt</command> command, indicate to the system's firmware to reboot into the firmware
+          setup interface for the next boot. Note that this functionality is not available on all systems.
+          </para>
+
+        <xi:include href="version-info.xml" xpointer="v220"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--boot-loader-menu=<replaceable>timeout</replaceable></option></term>
+
+        <listitem>
+          <para>When used with the <command>reboot</command>, <command>poweroff</command>, or
+          <command>halt</command> command, indicate to the system's boot loader to show the boot loader menu
+          on the following boot. Takes a time value as parameter — indicating the menu timeout. Pass zero
+          in order to disable the menu timeout. Note that not all boot loaders support this functionality.
+          </para>
+
+        <xi:include href="version-info.xml" xpointer="v242"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--boot-loader-entry=<replaceable>ID</replaceable></option></term>
+
+        <listitem>
+          <para>When used with the <command>reboot</command>, <command>poweroff</command>, or
+          <command>halt</command> command, indicate to the system's boot loader to boot into a specific
+          boot loader entry on the following boot. Takes a boot loader entry identifier as argument,
+          or <literal>help</literal> in order to list available entries. Note that not all boot loaders
+          support this functionality.</para>
+
+        <xi:include href="version-info.xml" xpointer="v242"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--reboot-argument=</option></term>
+
+        <listitem>
+          <para>This switch is used with <command>reboot</command>. The value is architecture and firmware specific. As an example, <literal>recovery</literal>
+            might be used to trigger system recovery, and <literal>fota</literal> might be used to trigger a
+            <quote>firmware over the air</quote> update.</para>
+
+        <xi:include href="version-info.xml" xpointer="v246"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--plain</option></term>
+
+        <listitem>
+          <para>When used with <command>list-dependencies</command>,
+          <command>list-units</command> or <command>list-machines</command>,
+          the output is printed as a list instead of a tree, and the bullet
+          circles are omitted.</para>
+
+        <xi:include href="version-info.xml" xpointer="v203"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--timestamp=</option></term>
+
+        <listitem>
+          <para>Change the format of printed timestamps. The following values may be used:
+          </para>
+
+          <variablelist>
+            <varlistentry>
+              <term><option>pretty</option> (this is the default)</term>
+              <listitem><para><literal>Day YYYY-MM-DD HH:MM:SS TZ</literal></para>
+
+              <xi:include href="version-info.xml" xpointer="v248"/></listitem>
+            </varlistentry>
+          </variablelist>
+
+          <variablelist>
+            <varlistentry>
+              <term><option>unix</option></term>
+              <listitem><para><literal>@seconds-since-the-epoch</literal></para>
+
+              <xi:include href="version-info.xml" xpointer="v251"/></listitem>
+            </varlistentry>
+          </variablelist>
+
+          <variablelist>
+            <varlistentry>
+              <term><option>us</option></term>
+              <term><option>μs</option></term>
+              <listitem><para><literal>Day YYYY-MM-DD HH:MM:SS.UUUUUU TZ</literal></para>
+
+              <xi:include href="version-info.xml" xpointer="v248"/></listitem>
+            </varlistentry>
+          </variablelist>
+
+          <variablelist>
+            <varlistentry>
+              <term><option>utc</option></term>
+              <listitem><para><literal>Day YYYY-MM-DD HH:MM:SS UTC</literal></para>
+
+              <xi:include href="version-info.xml" xpointer="v248"/></listitem>
+            </varlistentry>
+          </variablelist>
+
+          <variablelist>
+            <varlistentry>
+              <term><option>us+utc</option></term>
+              <term><option>μs+utc</option></term>
+              <listitem><para><literal>Day YYYY-MM-DD HH:MM:SS.UUUUUU UTC</literal></para>
+
+              <xi:include href="version-info.xml" xpointer="v248"/></listitem>
+            </varlistentry>
+          </variablelist>
+
+            <xi:include href="version-info.xml" xpointer="v247"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--mkdir</option></term>
+
+        <listitem><para>When used with <command>bind</command>, creates the destination file or directory before
+        applying the bind mount. Note that even though the name of this option suggests that it is suitable only for
+        directories, this option also creates the destination file node to mount over if the object to mount is not
+        a directory, but a regular file, device node, socket or FIFO.</para>
+
+        <xi:include href="version-info.xml" xpointer="v248"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--marked</option></term>
+
+        <listitem><para>Only allowed with <command>reload-or-restart</command>. Enqueues restart jobs for all
+        units that have the <literal>needs-restart</literal> mark, and reload jobs for units that have the
+        <literal>needs-reload</literal> mark. When a unit marked for reload does not support reload, restart
+        will be queued. Those properties can be set using <command>set-property Markers=…</command>.</para>
+
+        <para>Unless <option>--no-block</option> is used, <command>systemctl</command> will wait for the
+        queued jobs to finish.</para>
+
+        <xi:include href="version-info.xml" xpointer="v248"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--read-only</option></term>
+
+        <listitem><para>When used with <command>bind</command>, creates a read-only bind mount.</para>
+
+        <xi:include href="version-info.xml" xpointer="v248"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--drop-in=</option><replaceable>NAME</replaceable></term>
+
+        <listitem><para>When used with <command>edit</command>, use <replaceable>NAME</replaceable> as the
+        drop-in file name instead of <filename>override.conf</filename>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v253"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--when=</option></term>
+
+        <listitem>
+          <para>When used with <command>halt</command>, <command>poweroff</command>, <command>reboot</command>
+          or <command>kexec</command>, schedule the action to be performed at the given timestamp,
+          which should adhere to the syntax documented in <citerefentry
+          project='man-pages'><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+          section "PARSING TIMESTAMPS". Specially, if <literal>show</literal> is given, the currently scheduled
+          action will be shown, which can be canceled by passing an empty string or <literal>cancel</literal>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/>
+        </listitem>
+      </varlistentry>
+
+      <xi:include href="user-system-options.xml" xpointer="host" />
+      <xi:include href="user-system-options.xml" xpointer="machine" />
+
+      <xi:include href="standard-options.xml" xpointer="no-pager" />
+      <xi:include href="standard-options.xml" xpointer="legend" />
+      <xi:include href="standard-options.xml" xpointer="help" />
+      <xi:include href="standard-options.xml" xpointer="version" />
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Exit status</title>
+
+    <para>On success, 0 is returned, a non-zero failure code otherwise.</para>
+
+    <para><command>systemctl</command> uses the return codes defined by LSB, as defined in
+    <ulink url="http://refspecs.linuxbase.org/LSB_3.0.0/LSB-PDA/LSB-PDA/iniscrptact.html">LSB 3.0.0</ulink>.
+    </para>
+
+    <table>
+      <title>LSB return codes</title>
+
+      <tgroup cols='3'>
+        <thead>
+          <row>
+            <entry>Value</entry>
+            <entry>Description in LSB</entry>
+            <entry>Use in systemd</entry>
+          </row>
+        </thead>
+        <tbody>
+          <row>
+            <entry><constant>0</constant></entry>
+            <entry>"program is running or service is OK"</entry>
+            <entry>unit is active</entry>
+          </row>
+          <row>
+            <entry><constant>1</constant></entry>
+            <entry>"program is dead and <filename>/var/run</filename> pid file exists"</entry>
+            <entry>unit <emphasis>not</emphasis> failed (used by <command>is-failed</command>)</entry>
+          </row>
+          <row>
+            <entry><constant>2</constant></entry>
+            <entry>"program is dead and <filename>/var/lock</filename> lock file exists"</entry>
+            <entry>unused</entry>
+          </row>
+          <row>
+            <entry><constant>3</constant></entry>
+            <entry>"program is not running"</entry>
+            <entry>unit is not active</entry>
+          </row>
+          <row>
+            <entry><constant>4</constant></entry>
+            <entry>"program or service status is unknown"</entry>
+            <entry>no such unit</entry>
+          </row>
+        </tbody>
+      </tgroup>
+    </table>
+
+    <para>The mapping of LSB service states to systemd unit states is imperfect, so it is better to
+    not rely on those return values but to look for specific unit states and substates instead.
+    </para>
+  </refsect1>
+
+  <refsect1>
+    <title>Environment</title>
+
+    <variablelist class='environment-variables'>
+      <varlistentry>
+        <term><varname>$SYSTEMD_EDITOR</varname></term>
+
+        <listitem><para>Editor to use when editing units; overrides
+        <varname>$EDITOR</varname> and <varname>$VISUAL</varname>. If neither
+        <varname>$SYSTEMD_EDITOR</varname> nor <varname>$EDITOR</varname> nor
+        <varname>$VISUAL</varname> are present or if it is set to an empty
+        string or if their execution failed, systemctl will try to execute well
+        known editors in this order:
+        <citerefentry project='die-net'><refentrytitle>editor</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+        <citerefentry project='die-net'><refentrytitle>nano</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+        <citerefentry project='die-net'><refentrytitle>vim</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+        <citerefentry project='die-net'><refentrytitle>vi</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v218"/></listitem>
+      </varlistentry>
+      <xi:include href="common-variables.xml" xpointer="log-level"/>
+      <xi:include href="common-variables.xml" xpointer="log-color"/>
+      <xi:include href="common-variables.xml" xpointer="log-time"/>
+      <xi:include href="common-variables.xml" xpointer="log-location"/>
+      <xi:include href="common-variables.xml" xpointer="log-target"/>
+      <xi:include href="common-variables.xml" xpointer="pager"/>
+      <xi:include href="common-variables.xml" xpointer="less"/>
+      <xi:include href="common-variables.xml" xpointer="lesscharset"/>
+      <xi:include href="common-variables.xml" xpointer="lesssecure"/>
+      <xi:include href="common-variables.xml" xpointer="colors"/>
+      <xi:include href="common-variables.xml" xpointer="urlify"/>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>loginctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>machinectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>wall</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.preset</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>glob</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-ac-power.xml b/man/systemd-ac-power.xml
new file mode 100644
index 0000000..58aa706
--- /dev/null
+++ b/man/systemd-ac-power.xml
@@ -0,0 +1,83 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd-ac-power" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd-ac-power</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-ac-power</refentrytitle>
+    <manvolnum>1</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-ac-power</refname>
+    <refpurpose>Report whether we are connected to an external power source</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <cmdsynopsis>
+      <command>systemd-ac-power</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+    </cmdsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>systemd-ac-power</command> may be used to check whether the system
+    is running on AC power or not. By default it will simply return success (if we
+    can detect that we are running on AC power) or failure, with no output.
+    This can be useful for example to debug <varname>ConditionACPower=</varname> (see
+    <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>).</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>The following options are understood:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><option>-v</option></term>
+        <term><option>--verbose</option></term>
+
+        <listitem><para>Show result as text instead of just returning success or failure.</para>
+
+        <xi:include href="version-info.xml" xpointer="v253"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--low</option></term>
+
+        <listitem><para>Instead of showing AC power state, show low battery state. In this case will return
+        zero if all batteries are currently discharging and below 5% of maximum charge. Returns non-zero
+        otherwise.</para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+      </varlistentry>
+
+      <xi:include href="standard-options.xml" xpointer="help" />
+      <xi:include href="standard-options.xml" xpointer="version" />
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Exit status</title>
+
+    <para>On success (running on AC power), 0 is returned, a non-zero failure code otherwise.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-analyze.xml b/man/systemd-analyze.xml
new file mode 100644
index 0000000..35ad843
--- /dev/null
+++ b/man/systemd-analyze.xml
@@ -0,0 +1,1594 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd-analyze" conditional='ENABLE_ANALYZE'
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd-analyze</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-analyze</refentrytitle>
+    <manvolnum>1</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-analyze</refname>
+    <refpurpose>Analyze and debug system manager</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <cmdsynopsis>
+      <command>systemd-analyze</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg>time</arg>
+    </cmdsynopsis>
+    <cmdsynopsis>
+      <command>systemd-analyze</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="plain">blame</arg>
+    </cmdsynopsis>
+    <cmdsynopsis>
+      <command>systemd-analyze</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="plain">critical-chain</arg>
+      <arg choice="opt" rep="repeat"><replaceable>UNIT</replaceable></arg>
+    </cmdsynopsis>
+
+    <cmdsynopsis>
+      <command>systemd-analyze</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="plain">dump</arg>
+      <arg choice="opt" rep="repeat"><replaceable>PATTERN</replaceable></arg>
+    </cmdsynopsis>
+
+    <cmdsynopsis>
+      <command>systemd-analyze</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="plain">plot</arg>
+      <arg choice="opt">>file.svg</arg>
+    </cmdsynopsis>
+    <cmdsynopsis>
+      <command>systemd-analyze</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="plain">dot</arg>
+      <arg choice="opt" rep="repeat"><replaceable>PATTERN</replaceable></arg>
+      <arg choice="opt">>file.dot</arg>
+    </cmdsynopsis>
+
+    <cmdsynopsis>
+      <command>systemd-analyze</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="plain">unit-files</arg>
+    </cmdsynopsis>
+    <cmdsynopsis>
+      <command>systemd-analyze</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="plain">unit-paths</arg>
+    </cmdsynopsis>
+    <cmdsynopsis>
+      <command>systemd-analyze</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="plain">exit-status</arg>
+      <arg choice="opt" rep="repeat"><replaceable>STATUS</replaceable></arg>
+    </cmdsynopsis>
+    <cmdsynopsis>
+      <command>systemd-analyze</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="plain">capability</arg>
+      <arg choice="opt" rep="repeat"><replaceable>CAPABILITY</replaceable></arg>
+    </cmdsynopsis>
+    <cmdsynopsis>
+      <command>systemd-analyze</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="plain">condition</arg>
+      <arg choice="plain"><replaceable>CONDITION</replaceable>…</arg>
+    </cmdsynopsis>
+    <cmdsynopsis>
+      <command>systemd-analyze</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="plain">syscall-filter</arg>
+      <arg choice="opt"><replaceable>SET</replaceable>…</arg>
+    </cmdsynopsis>
+    <cmdsynopsis>
+      <command>systemd-analyze</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="plain">filesystems</arg>
+      <arg choice="opt"><replaceable>SET</replaceable>…</arg>
+    </cmdsynopsis>
+    <cmdsynopsis>
+      <command>systemd-analyze</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="plain">calendar</arg>
+      <arg choice="plain" rep="repeat"><replaceable>SPEC</replaceable></arg>
+    </cmdsynopsis>
+    <cmdsynopsis>
+      <command>systemd-analyze</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="plain">timestamp</arg>
+      <arg choice="plain" rep="repeat"><replaceable>TIMESTAMP</replaceable></arg>
+    </cmdsynopsis>
+    <cmdsynopsis>
+      <command>systemd-analyze</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="plain">timespan</arg>
+      <arg choice="plain" rep="repeat"><replaceable>SPAN</replaceable></arg>
+    </cmdsynopsis>
+    <cmdsynopsis>
+      <command>systemd-analyze</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="plain">cat-config</arg>
+      <arg choice="plain" rep="repeat"><replaceable>NAME</replaceable>|<replaceable>PATH</replaceable></arg>
+    </cmdsynopsis>
+    <cmdsynopsis>
+      <command>systemd-analyze</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="plain">compare-versions</arg>
+      <arg choice="plain"><replaceable>VERSION1</replaceable></arg>
+      <arg choice="opt"><replaceable>OP</replaceable></arg>
+      <arg choice="plain"><replaceable>VERSION2</replaceable></arg>
+    </cmdsynopsis>
+    <cmdsynopsis>
+      <command>systemd-analyze</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="plain">verify</arg>
+      <arg choice="plain" rep="repeat"><replaceable>FILE</replaceable></arg>
+    </cmdsynopsis>
+    <cmdsynopsis>
+      <command>systemd-analyze</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="plain">security</arg>
+      <arg choice="opt" rep="repeat"><replaceable>UNIT</replaceable></arg>
+    </cmdsynopsis>
+    <cmdsynopsis>
+      <command>systemd-analyze</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="plain">inspect-elf</arg>
+      <arg choice="plain" rep="repeat"><replaceable>FILE</replaceable></arg>
+    </cmdsynopsis>
+    <cmdsynopsis>
+      <command>systemd-analyze</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="plain">malloc</arg>
+      <arg choice="opt" rep="repeat"><replaceable>D-BUS SERVICE</replaceable></arg>
+    </cmdsynopsis>
+    <cmdsynopsis>
+      <command>systemd-analyze</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="plain">fdstore</arg>
+      <arg choice="plain" rep="repeat"><replaceable>UNIT</replaceable></arg>
+    </cmdsynopsis>
+    <cmdsynopsis>
+      <command>systemd-analyze</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="plain">image-policy</arg>
+      <arg choice="plain" rep="repeat"><replaceable>POLICY</replaceable></arg>
+    </cmdsynopsis>
+    <cmdsynopsis>
+      <command>systemd-analyze</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="plain">pcrs</arg>
+      <arg choice="opt" rep="repeat"><replaceable>PCR</replaceable></arg>
+    </cmdsynopsis>
+    <cmdsynopsis>
+      <command>systemd-analyze</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="plain">srk</arg> &gt;<arg choice="plain"><replaceable>FILE</replaceable></arg>
+    </cmdsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>systemd-analyze</command> may be used to determine
+    system boot-up performance statistics and retrieve other state and
+    tracing information from the system and service manager, and to
+    verify the correctness of unit files. It is also used to access
+    special functions useful for advanced system manager debugging.</para>
+
+    <para>If no command is passed, <command>systemd-analyze
+    time</command> is implied.</para>
+
+    <refsect2>
+      <title><command>systemd-analyze time</command></title>
+
+      <para>This command prints the time spent in the kernel before userspace has been reached, the time
+      spent in the initrd before normal system userspace has been reached, and the time normal system
+      userspace took to initialize. Note that these measurements simply measure the time passed up to the
+      point where all system services have been spawned, but not necessarily until they fully finished
+      initialization or the disk is idle.</para>
+
+      <example>
+        <title><command>Show how long the boot took</command></title>
+
+        <programlisting># in a container
+$ systemd-analyze time
+Startup finished in 296ms (userspace)
+multi-user.target reached after 275ms in userspace
+
+# on a real machine
+$ systemd-analyze time
+Startup finished in 2.584s (kernel) + 19.176s (initrd) + 47.847s (userspace) = 1min 9.608s
+multi-user.target reached after 47.820s in userspace
+</programlisting>
+      </example>
+    </refsect2>
+
+    <refsect2>
+      <title><command>systemd-analyze blame</command></title>
+
+      <para>This command prints a list of all running units, ordered by the time they took to initialize.
+      This information may be used to optimize boot-up times. Note that the output might be misleading as the
+      initialization of one service might be slow simply because it waits for the initialization of another
+      service to complete.  Also note: <command>systemd-analyze blame</command> doesn't display results for
+      services with <varname>Type=simple</varname>, because systemd considers such services to be started
+      immediately, hence no measurement of the initialization delays can be done. Also note that this command
+      only shows the time units took for starting up, it does not show how long unit jobs spent in the
+      execution queue. In particular it shows the time units spent in <literal>activating</literal> state,
+      which is not defined for units such as device units that transition directly from
+      <literal>inactive</literal> to <literal>active</literal>. This command hence gives an impression of the
+      performance of program code, but cannot accurately reflect latency introduced by waiting for
+      hardware and similar events.</para>
+
+      <example>
+        <title><command>Show which units took the most time during boot</command></title>
+
+        <programlisting>$ systemd-analyze blame
+         32.875s pmlogger.service
+         20.905s systemd-networkd-wait-online.service
+         13.299s dev-vda1.device
+         ...
+            23ms sysroot.mount
+            11ms initrd-udevadm-cleanup-db.service
+             3ms sys-kernel-config.mount
+        </programlisting>
+      </example>
+    </refsect2>
+
+    <refsect2>
+      <title><command>systemd-analyze critical-chain <optional><replaceable>UNIT</replaceable>...</optional></command></title>
+
+      <para>This command prints a tree of the time-critical chain of units (for each of the specified
+      <replaceable>UNIT</replaceable>s or for the default target otherwise). The time after the unit is
+      active or started is printed after the "@" character. The time the unit takes to start is printed after
+      the "+" character. Note that the output might be misleading as the initialization of services might
+      depend on socket activation and because of the parallel execution of units. Also, similarly to the
+      <command>blame</command> command, this only takes into account the time units spent in
+      <literal>activating</literal> state, and hence does not cover units that never went through an
+      <literal>activating</literal> state (such as device units that transition directly from
+      <literal>inactive</literal> to <literal>active</literal>). Moreover it does not show information on
+      jobs (and in particular not jobs that timed out).</para>
+
+      <example>
+        <title><command>systemd-analyze critical-chain</command></title>
+
+      <programlisting>$ systemd-analyze critical-chain
+multi-user.target @47.820s
+└─pmie.service @35.968s +548ms
+  └─pmcd.service @33.715s +2.247s
+    └─network-online.target @33.712s
+      └─systemd-networkd-wait-online.service @12.804s +20.905s
+        └─systemd-networkd.service @11.109s +1.690s
+          └─systemd-udevd.service @9.201s +1.904s
+            └─systemd-tmpfiles-setup-dev.service @7.306s +1.776s
+              └─kmod-static-nodes.service @6.976s +177ms
+                └─systemd-journald.socket
+                  └─system.slice
+                    └─-.slice
+</programlisting>
+      </example>
+    </refsect2>
+
+    <refsect2>
+      <title><command>systemd-analyze dump [<replaceable>pattern</replaceable>…]</command></title>
+
+      <para>Without any parameter, this command outputs a (usually very long) human-readable serialization of
+      the complete service manager state. Optional glob pattern may be specified, causing the output to be
+      limited to units whose names match one of the patterns. The output format is subject to change without
+      notice and should not be parsed by applications. This command is rate limited for unprivileged users.</para>
+
+      <example>
+        <title>Show the internal state of user manager</title>
+
+        <programlisting>$ systemd-analyze --user dump
+Timestamp userspace: Thu 2019-03-14 23:28:07 CET
+Timestamp finish: Thu 2019-03-14 23:28:07 CET
+Timestamp generators-start: Thu 2019-03-14 23:28:07 CET
+Timestamp generators-finish: Thu 2019-03-14 23:28:07 CET
+Timestamp units-load-start: Thu 2019-03-14 23:28:07 CET
+Timestamp units-load-finish: Thu 2019-03-14 23:28:07 CET
+-> Unit proc-timer_list.mount:
+        Description: /proc/timer_list
+        ...
+-> Unit default.target:
+        Description: Main user target
+...
+</programlisting>
+      </example>
+    </refsect2>
+
+    <refsect2>
+      <title><command>systemd-analyze malloc [<replaceable>D-Bus service</replaceable>…]</command></title>
+
+      <para>This command can be used to request the output of the internal memory state (as returned by
+      <citerefentry project='man-pages'><refentrytitle>malloc_info</refentrytitle><manvolnum>3</manvolnum></citerefentry>)
+      of a D-Bus service. If no service is specified, the query will be sent to
+      <filename>org.freedesktop.systemd1</filename> (the system or user service manager). The output format
+      is not guaranteed to be stable and should not be parsed by applications.</para>
+
+      <para>The service must implement the <filename>org.freedesktop.MemoryAllocation1</filename> interface.
+      In the systemd suite, it is currently only implemented by the manager.</para>
+    </refsect2>
+
+    <refsect2>
+      <title><command>systemd-analyze plot</command></title>
+
+      <para>This command prints either an SVG graphic, detailing which system services have been started at what
+      time, highlighting the time they spent on initialization, or the raw time data in JSON or table format.</para>
+
+      <example>
+        <title><command>Plot a bootchart</command></title>
+
+        <programlisting>$ systemd-analyze plot >bootup.svg
+$ eog bootup.svg&amp;
+</programlisting>
+      </example>
+
+      <para>Note that this plot is based on the most recent per-unit timing data of loaded units. This means
+      that if a unit gets started, then stopped and then started again the information shown will cover the
+      most recent start cycle, not the first one. Thus it's recommended to consult this information only
+      shortly after boot, so that this distinction doesn't matter. Moreover, units that are not referenced by
+      any other unit through a dependency might be unloaded by the service manager once they terminate (and
+      did not fail). Such units will not show up in the plot.</para>
+    </refsect2>
+
+    <refsect2>
+      <title><command>systemd-analyze dot [<replaceable>pattern</replaceable>...]</command></title>
+
+      <para>This command generates textual dependency graph description in dot format for further processing
+      with the GraphViz
+      <citerefentry project='die-net'><refentrytitle>dot</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+      tool. Use a command line like <command>systemd-analyze dot | dot -Tsvg >systemd.svg</command> to
+      generate a graphical dependency tree. Unless <option>--order</option> or <option>--require</option> is
+      passed, the generated graph will show both ordering and requirement dependencies. Optional pattern
+      globbing style specifications (e.g. <filename>*.target</filename>) may be given at the end. A unit
+      dependency is included in the graph if any of these patterns match either the origin or destination
+      node.</para>
+
+      <example>
+        <title>Plot all dependencies of any unit whose name starts with <literal>avahi-daemon</literal>
+        </title>
+
+        <programlisting>$ systemd-analyze dot 'avahi-daemon.*' | dot -Tsvg >avahi.svg
+$ eog avahi.svg</programlisting>
+      </example>
+
+      <example>
+        <title>Plot the dependencies between all known target units</title>
+
+        <programlisting>$ systemd-analyze dot --to-pattern='*.target' --from-pattern='*.target' \
+      | dot -Tsvg >targets.svg
+$ eog targets.svg</programlisting>
+      </example>
+    </refsect2>
+
+    <refsect2>
+      <title><command>systemd-analyze unit-paths</command></title>
+
+      <para>This command outputs a list of all directories from which unit files, <filename>.d</filename>
+      overrides, and <filename>.wants</filename>, <filename>.requires</filename> symlinks may be
+      loaded. Combine with <option>--user</option> to retrieve the list for the user manager instance, and
+      <option>--global</option> for the global configuration of user manager instances.</para>
+
+      <example>
+        <title><command>Show all paths for generated units</command></title>
+
+        <programlisting>$ systemd-analyze unit-paths | grep '^/run'
+/run/systemd/system.control
+/run/systemd/transient
+/run/systemd/generator.early
+/run/systemd/system
+/run/systemd/system.attached
+/run/systemd/generator
+/run/systemd/generator.late
+</programlisting>
+      </example>
+
+      <para>Note that this verb prints the list that is compiled into <command>systemd-analyze</command>
+      itself, and does not communicate with the running manager. Use
+      <programlisting>systemctl [--user] [--global] show -p UnitPath --value</programlisting>
+      to retrieve the actual list that the manager uses, with any empty directories omitted.</para>
+    </refsect2>
+
+    <refsect2>
+      <title><command>systemd-analyze exit-status <optional><replaceable>STATUS</replaceable>...</optional></command></title>
+
+      <para>This command prints a list of exit statuses along with their "class", i.e. the source of the
+      definition (one of <literal>glibc</literal>, <literal>systemd</literal>, <literal>LSB</literal>, or
+      <literal>BSD</literal>), see the Process Exit Codes section in
+      <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+      If no additional arguments are specified, all known statuses are shown. Otherwise, only the
+      definitions for the specified codes are shown.</para>
+
+      <example>
+        <title><command>Show some example exit status names</command></title>
+
+        <programlisting>$ systemd-analyze exit-status 0 1 {63..65}
+NAME    STATUS CLASS
+SUCCESS 0      glibc
+FAILURE 1      glibc
+-       63     -
+USAGE   64     BSD
+DATAERR 65     BSD
+</programlisting>
+      </example>
+    </refsect2>
+
+    <refsect2>
+      <title><command>systemd-analyze capability <optional><replaceable>CAPABILITY</replaceable>...</optional></command></title>
+
+      <para>This command prints a list of Linux capabilities along with their numeric IDs. See <citerefentry
+      project='man-pages'><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+      for details. If no argument is specified the full list of capabilities known to the service manager and
+      the kernel is shown. Capabilities defined by the kernel but not known to the service manager are shown
+      as <literal>cap_???</literal>. Optionally, if arguments are specified they may refer to specific
+      cabilities by name or numeric ID, in which case only the indicated capabilities are shown in the
+      table.</para>
+
+      <example>
+        <title><command>Show some example capability names</command></title>
+
+        <programlisting>$ systemd-analyze capability 0 1 {30..32}
+NAME              NUMBER
+cap_chown              0
+cap_dac_override       1
+cap_audit_control     30
+cap_setfcap           31
+cap_mac_override      32</programlisting>
+      </example>
+    </refsect2>
+
+    <refsect2>
+      <title><command>systemd-analyze condition <replaceable>CONDITION</replaceable>...</command></title>
+
+      <para>This command will evaluate <varname index="false">Condition*=...</varname> and
+      <varname index="false">Assert*=...</varname> assignments, and print their values, and
+      the resulting value of the combined condition set. See
+      <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+      for a list of available conditions and asserts.</para>
+
+      <example>
+        <title>Evaluate conditions that check kernel versions</title>
+
+        <programlisting>$ systemd-analyze condition 'ConditionKernelVersion = ! &lt;4.0' \
+        'ConditionKernelVersion = &gt;=5.1' \
+        'ConditionACPower=|false' \
+        'ConditionArchitecture=|!arm' \
+        'AssertPathExists=/etc/os-release'
+test.service: AssertPathExists=/etc/os-release succeeded.
+Asserts succeeded.
+test.service: ConditionArchitecture=|!arm succeeded.
+test.service: ConditionACPower=|false failed.
+test.service: ConditionKernelVersion=&gt;=5.1 succeeded.
+test.service: ConditionKernelVersion=!&lt;4.0 succeeded.
+Conditions succeeded.</programlisting>
+      </example>
+    </refsect2>
+
+    <refsect2>
+      <title><command>systemd-analyze syscall-filter <optional><replaceable>SET</replaceable>...</optional></command></title>
+
+      <para>This command will list system calls contained in the specified system call set
+      <replaceable>SET</replaceable>, or all known sets if no sets are specified. Argument
+      <replaceable>SET</replaceable> must include the <literal>@</literal> prefix.</para>
+    </refsect2>
+
+    <refsect2>
+      <title><command>systemd-analyze filesystems <optional><replaceable>SET</replaceable>...</optional></command></title>
+
+      <para>This command will list filesystems in the specified filesystem set
+      <replaceable>SET</replaceable>, or all known sets if no sets are specified. Argument
+      <replaceable>SET</replaceable> must include the <literal>@</literal> prefix.</para>
+    </refsect2>
+
+    <refsect2>
+      <title><command>systemd-analyze calendar <replaceable>EXPRESSION</replaceable>...</command></title>
+
+      <para>This command will parse and normalize repetitive calendar time events, and will calculate when
+      they elapse next. This takes the same input as the <varname>OnCalendar=</varname> setting in
+      <citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      following the syntax described in
+      <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry>. By
+      default, only the next time the calendar expression will elapse is shown; use
+      <option>--iterations=</option> to show the specified number of next times the expression
+      elapses. Each time the expression elapses forms a timestamp, see the <command>timestamp</command>
+      verb below.</para>
+
+      <example>
+        <title>Show leap days in the near future</title>
+
+        <programlisting>$ systemd-analyze calendar --iterations=5 '*-2-29 0:0:0'
+  Original form: *-2-29 0:0:0
+Normalized form: *-02-29 00:00:00
+    Next elapse: Sat 2020-02-29 00:00:00 UTC
+       From now: 11 months 15 days left
+       Iter. #2: Thu 2024-02-29 00:00:00 UTC
+       From now: 4 years 11 months left
+       Iter. #3: Tue 2028-02-29 00:00:00 UTC
+       From now: 8 years 11 months left
+       Iter. #4: Sun 2032-02-29 00:00:00 UTC
+       From now: 12 years 11 months left
+       Iter. #5: Fri 2036-02-29 00:00:00 UTC
+       From now: 16 years 11 months left
+</programlisting>
+      </example>
+    </refsect2>
+
+    <refsect2>
+      <title><command>systemd-analyze timestamp <replaceable>TIMESTAMP</replaceable>...</command></title>
+
+      <para>This command parses a timestamp (i.e. a single point in time) and outputs the normalized form and
+      the difference between this timestamp and now. The timestamp should adhere to the syntax documented in
+      <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      section "PARSING TIMESTAMPS".</para>
+
+      <example>
+        <title>Show parsing of timestamps</title>
+
+        <programlisting>$ systemd-analyze timestamp yesterday now tomorrow
+  Original form: yesterday
+Normalized form: Mon 2019-05-20 00:00:00 CEST
+       (in UTC): Sun 2019-05-19 22:00:00 UTC
+   UNIX seconds: @15583032000
+       From now: 1 day 9h ago
+
+  Original form: now
+Normalized form: Tue 2019-05-21 09:48:39 CEST
+       (in UTC): Tue 2019-05-21 07:48:39 UTC
+   UNIX seconds: @1558424919.659757
+       From now: 43us ago
+
+  Original form: tomorrow
+Normalized form: Wed 2019-05-22 00:00:00 CEST
+       (in UTC): Tue 2019-05-21 22:00:00 UTC
+   UNIX seconds: @15584760000
+       From now: 14h left
+</programlisting>
+      </example>
+    </refsect2>
+
+    <refsect2>
+      <title><command>systemd-analyze timespan <replaceable>EXPRESSION</replaceable>...</command></title>
+
+      <para>This command parses a time span (i.e. a difference between two timestamps) and outputs the
+      normalized form and the equivalent value in microseconds. The time span should adhere to the syntax
+      documented in
+      <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      section "PARSING TIME SPANS". Values without units are parsed as seconds.</para>
+
+      <example>
+        <title>Show parsing of timespans</title>
+
+        <programlisting>$ systemd-analyze timespan 1s 300s '1year 0.000001s'
+Original: 1s
+      μs: 1000000
+   Human: 1s
+
+Original: 300s
+      μs: 300000000
+   Human: 5min
+
+Original: 1year 0.000001s
+      μs: 31557600000001
+   Human: 1y 1us
+</programlisting>
+      </example>
+    </refsect2>
+
+    <refsect2>
+      <title><command>systemd-analyze cat-config</command>
+      <replaceable>NAME</replaceable>|<replaceable>PATH</replaceable>...</title>
+
+      <para>This command is similar to <command>systemctl cat</command>, but operates on config files. It
+      will copy the contents of a config file and any drop-ins to standard output, using the usual systemd
+      set of directories and rules for precedence. Each argument must be either an absolute path including
+      the prefix (such as <filename>/etc/systemd/logind.conf</filename> or
+      <filename>/usr/lib/systemd/logind.conf</filename>), or a name relative to the prefix (such as
+      <filename>systemd/logind.conf</filename>).</para>
+
+      <example>
+        <title>Showing logind configuration</title>
+        <programlisting>$ systemd-analyze cat-config systemd/logind.conf
+# /etc/systemd/logind.conf
+...
+[Login]
+NAutoVTs=8
+...
+
+# /usr/lib/systemd/logind.conf.d/20-test.conf
+... some override from another package
+
+# /etc/systemd/logind.conf.d/50-override.conf
+... some administrator override
+        </programlisting>
+      </example>
+    </refsect2>
+
+    <refsect2>
+      <title><command>systemd-analyze compare-versions
+      <replaceable>VERSION1</replaceable>
+      <optional><replaceable>OP</replaceable></optional>
+      <replaceable>VERSION2</replaceable></command></title>
+
+      <para>This command has two distinct modes of operation, depending on whether the operator
+      <replaceable>OP</replaceable> is specified.</para>
+
+      <para>In the first mode — when <replaceable>OP</replaceable> is not specified — it will compare the two
+      version strings and print either <literal><replaceable>VERSION1</replaceable> &lt;
+      <replaceable>VERSION2</replaceable></literal>, or <literal><replaceable>VERSION1</replaceable> ==
+      <replaceable>VERSION2</replaceable></literal>, or <literal><replaceable>VERSION1</replaceable> &gt;
+      <replaceable>VERSION2</replaceable></literal> as appropriate.</para>
+
+      <para>The exit status is <constant>0</constant> if the versions are equal, <constant>11</constant> if
+      the version of the right is smaller, and <constant>12</constant> if the version of the left is
+      smaller. (This matches the convention used by <command>rpmdev-vercmp</command>.)</para>
+
+      <para>In the second mode — when <replaceable>OP</replaceable> is specified — it will compare the two
+      version strings using the operation <replaceable>OP</replaceable> and return <constant>0</constant>
+      (success) if they condition is satisfied, and <constant>1</constant> (failure)
+      otherwise. <constant>OP</constant> may be <command>lt</command>, <command>le</command>,
+      <command>eq</command>, <command>ne</command>, <command>ge</command>, <command>gt</command>. In this
+      mode, no output is printed.
+      (This matches the convention used by
+      <citerefentry project='die-net'><refentrytitle>dpkg</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+      <option>--compare-versions</option>.)</para>
+
+      <example>
+        <title>Compare versions of a package</title>
+
+        <programlisting>
+$ systemd-analyze compare-versions systemd-250~rc1.fc36.aarch64 systemd-251.fc36.aarch64
+systemd-250~rc1.fc36.aarch64 &lt; systemd-251.fc36.aarch64
+$ echo $?
+12
+
+$ systemd-analyze compare-versions 1 lt 2; echo $?
+0
+$ systemd-analyze compare-versions 1 ge 2; echo $?
+1
+        </programlisting>
+      </example>
+    </refsect2>
+
+    <refsect2>
+      <title><command>systemd-analyze verify <replaceable>FILE</replaceable>...</command></title>
+
+      <para>This command will load unit files and print warnings if any errors are detected. Files specified
+      on the command line will be loaded, but also any other units referenced by them. A unit's name on disk
+      can be overridden by specifying an alias after a colon; see below for an example. The full unit search
+      path is formed by combining the directories for all command line arguments, and the usual unit load
+      paths. The variable <varname>$SYSTEMD_UNIT_PATH</varname> is supported, and may be used to replace or
+      augment the compiled in set of unit load paths; see
+      <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>. All
+      units files present in the directories containing the command line arguments will be used in preference
+      to the other paths.</para>
+
+      <para>The following errors are currently detected:</para>
+      <itemizedlist>
+        <listitem><para>unknown sections and directives,</para></listitem>
+
+        <listitem><para>missing dependencies which are required to start the given unit,</para></listitem>
+
+        <listitem><para>man pages listed in <varname>Documentation=</varname> which are not found in the
+        system,</para></listitem>
+
+        <listitem><para>commands listed in <varname>ExecStart=</varname> and similar which are not found in
+        the system or not executable.</para></listitem>
+      </itemizedlist>
+
+      <example>
+        <title>Misspelt directives</title>
+
+        <programlisting>$ cat ./user.slice
+[Unit]
+WhatIsThis=11
+Documentation=man:nosuchfile(1)
+Requires=different.service
+
+[Service]
+Description=x
+
+$ systemd-analyze verify ./user.slice
+[./user.slice:9] Unknown lvalue 'WhatIsThis' in section 'Unit'
+[./user.slice:13] Unknown section 'Service'. Ignoring.
+Error: org.freedesktop.systemd1.LoadFailed:
+   Unit different.service failed to load:
+   No such file or directory.
+Failed to create user.slice/start: Invalid argument
+user.slice: man nosuchfile(1) command failed with code 16
+        </programlisting>
+      </example>
+
+      <example>
+        <title>Missing service units</title>
+
+        <programlisting>$ tail ./a.socket ./b.socket
+==> ./a.socket &lt;==
+[Socket]
+ListenStream=100
+
+==> ./b.socket &lt;==
+[Socket]
+ListenStream=100
+Accept=yes
+
+$ systemd-analyze verify ./a.socket ./b.socket
+Service a.service not loaded, a.socket cannot be started.
+Service b@0.service not loaded, b.socket cannot be started.
+        </programlisting>
+      </example>
+
+      <example>
+        <title>Aliasing a unit</title>
+
+        <programlisting>$ cat /tmp/source
+[Unit]
+Description=Hostname printer
+
+[Service]
+Type=simple
+ExecStart=/usr/bin/echo %H
+MysteryKey=true
+
+$ systemd-analyze verify /tmp/source
+Failed to prepare filename /tmp/source: Invalid argument
+
+$ systemd-analyze verify /tmp/source:alias.service
+alias.service:7: Unknown key name 'MysteryKey' in section 'Service', ignoring.
+        </programlisting>
+      </example>
+
+    </refsect2>
+
+    <refsect2>
+      <title><command>systemd-analyze security <optional><replaceable>UNIT</replaceable>...</optional></command></title>
+
+      <para>This command analyzes the security and sandboxing settings of one or more specified service
+      units. If at least one unit name is specified the security settings of the specified service units are
+      inspected and a detailed analysis is shown. If no unit name is specified, all currently loaded,
+      long-running service units are inspected and a terse table with results shown. The command checks for
+      various security-related service settings, assigning each a numeric "exposure level" value, depending
+      on how important a setting is. It then calculates an overall exposure level for the whole unit, which
+      is an estimation in the range 0.0…10.0 indicating how exposed a service is security-wise. High exposure
+      levels indicate very little applied sandboxing. Low exposure levels indicate tight sandboxing and
+      strongest security restrictions. Note that this only analyzes the per-service security features systemd
+      itself implements. This means that any additional security mechanisms applied by the service code
+      itself are not accounted for. The exposure level determined this way should not be misunderstood: a
+      high exposure level neither means that there is no effective sandboxing applied by the service code
+      itself, nor that the service is actually vulnerable to remote or local attacks. High exposure levels do
+      indicate however that most likely the service might benefit from additional settings applied to
+      them.</para>
+
+      <para>Please note that many of the security and sandboxing settings individually can be circumvented —
+      unless combined with others. For example, if a service retains the privilege to establish or undo mount
+      points many of the sandboxing options can be undone by the service code itself. Due to that is
+      essential that each service uses the most comprehensive and strict sandboxing and security settings
+      possible. The tool will take into account some of these combinations and relationships between the
+      settings, but not all. Also note that the security and sandboxing settings analyzed here only apply to
+      the operations executed by the service code itself. If a service has access to an IPC system (such as
+      D-Bus) it might request operations from other services that are not subject to the same
+      restrictions. Any comprehensive security and sandboxing analysis is hence incomplete if the IPC access
+      policy is not validated too.</para>
+
+      <example>
+      <title>Analyze <filename index="false">systemd-logind.service</filename></title>
+
+      <programlisting>$ systemd-analyze security --no-pager systemd-logind.service
+  NAME                DESCRIPTION                              EXPOSURE
+✗ PrivateNetwork=     Service has access to the host's network      0.5
+✗ User=/DynamicUser=  Service runs as root user                     0.4
+✗ DeviceAllow=        Service has no device ACL                     0.2
+✓ IPAddressDeny=      Service blocks all IP address ranges
+...
+→ Overall exposure level for systemd-logind.service: 4.1 OK 🙂
+</programlisting>
+      </example>
+    </refsect2>
+
+    <refsect2>
+      <title><command>systemd-analyze inspect-elf <replaceable>FILE</replaceable>...</command></title>
+
+      <para>This command will load the specified files, and if they are ELF objects (executables,
+      libraries, core files, etc.) it will parse the embedded packaging metadata, if any, and print
+      it in a table or json format. See the <ulink url="https://systemd.io/COREDUMP_PACKAGE_METADATA/">
+      Packaging Metadata</ulink> documentation for more information.</para>
+
+      <example>
+        <title>Print information about a core file as JSON</title>
+
+        <programlisting>$ systemd-analyze inspect-elf --json=pretty \
+        core.fsverity.1000.f77dac5dc161402aa44e15b7dd9dcf97.58561.1637106137000000
+{
+        "elfType" : "coredump",
+        "elfArchitecture" : "AMD x86-64",
+        "/home/bluca/git/fsverity-utils/fsverity" : {
+                "type" : "deb",
+                "name" : "fsverity-utils",
+                "version" : "1.3-1",
+                "buildId" : "7c895ecd2a271f93e96268f479fdc3c64a2ec4ee"
+        },
+        "/home/bluca/git/fsverity-utils/libfsverity.so.0" : {
+                "type" : "deb",
+                "name" : "fsverity-utils",
+                "version" : "1.3-1",
+                "buildId" : "b5e428254abf14237b0ae70ed85fffbb98a78f88"
+        }
+}
+        </programlisting>
+      </example>
+    </refsect2>
+
+    <refsect2>
+      <title><command>systemd-analyze fdstore <replaceable>UNIT</replaceable>...</command></title>
+
+      <para>Lists the current contents of the specified service unit's file descriptor store. This shows
+      names, inode types, device numbers, inode numbers, paths and open modes of the open file
+      descriptors. The specified units must have <varname>FileDescriptorStoreMax=</varname> enabled, see
+      <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
+      details.</para>
+
+      <example>
+        <title>Table output</title>
+        <programlisting>$ systemd-analyze fdstore systemd-journald.service
+FDNAME TYPE DEVNO   INODE RDEVNO PATH             FLAGS
+stored sock 0:8   4218620 -      socket:[4218620] ro
+stored sock 0:8   4213198 -      socket:[4213198] ro
+stored sock 0:8   4213190 -      socket:[4213190] ro
+…</programlisting>
+      </example>
+
+      <para>Note: the "DEVNO" column refers to the major/minor numbers of the device node backing the file
+      system the file descriptor's inode is on. The "RDEVNO" column refers to the major/minor numbers of the
+      device node itself if the file descriptor refers to one. Compare with corresponding
+      <varname>.st_dev</varname> and <varname>.st_rdev</varname> fields in <type>struct stat</type> (see
+      <citerefentry
+      project='man-pages'><refentrytitle>stat</refentrytitle><manvolnum>2</manvolnum></citerefentry> for
+      details). The listed inode numbers in the "INODE" column are on the file system indicated by
+      "DEVNO".</para>
+    </refsect2>
+
+    <refsect2>
+      <title><command>systemd-analyze image-policy <replaceable>POLICY</replaceable>…</command></title>
+
+      <para>This command analyzes the specified image policy string, as per
+      <citerefentry><refentrytitle>systemd.image-policy</refentrytitle><manvolnum>7</manvolnum></citerefentry>. The
+      policy is normalized and simplified. For each currently defined partition identifier (as per the <ulink
+      url="https://uapi-group.org/specifications/specs/discoverable_partitions_specification">Discoverable
+      Partitions Specification</ulink>) the effect of the image policy string is shown in tabular form.</para>
+
+      <example>
+        <title>Example Output</title>
+
+        <programlisting>$ systemd-analyze image-policy swap=encrypted:usr=read-only-on+verity:root=encrypted
+Analyzing policy: root=encrypted:usr=verity+read-only-on:swap=encrypted
+       Long form: root=encrypted:usr=verity+read-only-on:swap=encrypted:=unused+absent
+
+PARTITION       MODE        READ-ONLY GROWFS
+root            encrypted   -         -
+usr             verity      yes       -
+home            ignore      -         -
+srv             ignore      -         -
+esp             ignore      -         -
+xbootldr        ignore      -         -
+swap            encrypted   -         -
+root-verity     ignore      -         -
+usr-verity      unprotected yes       -
+root-verity-sig ignore      -         -
+usr-verity-sig  ignore      -         -
+tmp             ignore      -         -
+var             ignore      -         -
+default         ignore      -         -</programlisting>
+      </example>
+    </refsect2>
+
+    <refsect2>
+      <title><command>systemd-analyze pcrs <optional><replaceable>PCR</replaceable>…</optional></command></title>
+
+      <para>This command shows the known TPM2 PCRs along with their identifying names and current values.</para>
+
+      <example>
+        <title>Example Output</title>
+
+        <programlisting>$ systemd-analyze pcrs
+NR NAME                SHA256
+ 0 platform-code       bcd2eb527108bbb1f5528409bcbe310aa9b74f687854cc5857605993f3d9eb11
+ 1 platform-config     b60622856eb7ce52637b80f30a520e6e87c347daa679f3335f4f1a600681bb01
+ 2 external-code       1471262403e9a62f9c392941300b4807fbdb6f0bfdd50abfab752732087017dd
+ 3 external-config     3d458cfe55cc03ea1f443f1562beec8df51c75e14a9fcf9a7234a13f198e7969
+ 4 boot-loader-code    939f7fa1458e1f7ce968874d908e524fc0debf890383d355e4ce347b7b78a95c
+ 5 boot-loader-config  864c61c5ea5ecbdb6951e6cb6d9c1f4b4eac79772f7fe13b8bece569d83d3768
+ 6 -                   3d458cfe55cc03ea1f443f1562beec8df51c75e14a9fcf9a7234a13f198e7969
+ 7 secure-boot-policy  9c905bd9b9891bfb889b90a54c4b537b889cfa817c4389cc25754823a9443255
+ 8 -                   0000000000000000000000000000000000000000000000000000000000000000
+ 9 kernel-initrd       9caa29b128113ef42aa53d421f03437be57211e5ebafc0fa8b5d4514ee37ff0c
+10 ima                 5ea9e3dab53eb6b483b6ec9e3b2c712bea66bca1b155637841216e0094387400
+11 kernel-boot         0000000000000000000000000000000000000000000000000000000000000000
+12 kernel-config       627ffa4b405e911902fe1f1a8b0164693b31acab04f805f15bccfe2209c7eace
+13 sysexts             0000000000000000000000000000000000000000000000000000000000000000
+14 shim-policy         0000000000000000000000000000000000000000000000000000000000000000
+15 system-identity     0000000000000000000000000000000000000000000000000000000000000000
+16 debug               0000000000000000000000000000000000000000000000000000000000000000
+17 -                   ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+18 -                   ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+19 -                   ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+20 -                   ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+21 -                   ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+22 -                   ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+23 application-support 0000000000000000000000000000000000000000000000000000000000000000</programlisting>
+      </example>
+    </refsect2>
+
+    <refsect2>
+      <title><command>systemd-analyze srk &gt; <replaceable>FILE</replaceable></command></title>
+
+      <para>This command reads the Storage Root Key (SRK) from the TPM2 device, and writes it in marshalled
+      TPM2B_PUBLIC format to stdout. Example:</para>
+
+      <programlisting>systemd-analyze srk &gt; srk.tpm2b_public</programlisting>
+    </refsect2>
+
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>The following options are understood:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><option>--system</option></term>
+
+        <listitem><para>Operates on the system systemd instance. This
+        is the implied default.</para>
+
+        <xi:include href="version-info.xml" xpointer="v209"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--user</option></term>
+
+        <listitem><para>Operates on the user systemd
+        instance.</para>
+
+        <xi:include href="version-info.xml" xpointer="v186"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--global</option></term>
+
+        <listitem><para>Operates on the system-wide configuration for
+        user systemd instance.</para>
+
+        <xi:include href="version-info.xml" xpointer="v238"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--order</option></term>
+        <term><option>--require</option></term>
+
+        <listitem><para>When used in conjunction with the
+        <command>dot</command> command (see above), selects which
+        dependencies are shown in the dependency graph. If
+        <option>--order</option> is passed, only dependencies of type
+        <varname>After=</varname> or <varname>Before=</varname> are
+        shown. If <option>--require</option> is passed, only
+        dependencies of type <varname>Requires=</varname>,
+        <varname>Requisite=</varname>,
+        <varname>Wants=</varname> and <varname>Conflicts=</varname>
+        are shown. If neither is passed, this shows dependencies of
+        all these types.</para>
+
+        <xi:include href="version-info.xml" xpointer="v198"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--from-pattern=</option></term>
+        <term><option>--to-pattern=</option></term>
+
+        <listitem><para>When used in conjunction with the
+        <command>dot</command> command (see above), this selects which
+        relationships are shown in the dependency graph. Both options
+        require a
+        <citerefentry project='man-pages'><refentrytitle>glob</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+        pattern as an argument, which will be matched against the
+        left-hand and the right-hand, respectively, nodes of a
+        relationship.</para>
+
+        <para>Each of these can be used more than once, in which case
+        the unit name must match one of the values. When tests for
+        both sides of the relation are present, a relation must pass
+        both tests to be shown. When patterns are also specified as
+        positional arguments, they must match at least one side of the
+        relation. In other words, patterns specified with those two
+        options will trim the list of edges matched by the positional
+        arguments, if any are given, and fully determine the list of
+        edges shown otherwise.</para>
+
+        <xi:include href="version-info.xml" xpointer="v201"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--fuzz=</option><replaceable>timespan</replaceable></term>
+
+        <listitem><para>When used in conjunction with the
+        <command>critical-chain</command> command (see above), also
+        show units, which finished <replaceable>timespan</replaceable>
+        earlier, than the latest unit in the same level. The unit of
+        <replaceable>timespan</replaceable> is seconds unless
+        specified with a different unit, e.g.
+        "50ms".</para>
+
+        <xi:include href="version-info.xml" xpointer="v203"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--man=no</option></term>
+
+        <listitem><para>Do not invoke
+        <citerefentry project='man-pages'><refentrytitle>man</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+        to verify the existence of man pages listed in <varname>Documentation=</varname>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v235"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--generators</option></term>
+
+        <listitem><para>Invoke unit generators, see
+        <citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
+        Some generators require root privileges. Under a normal user, running with
+        generators enabled will generally result in some warnings.</para>
+
+        <xi:include href="version-info.xml" xpointer="v235"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--recursive-errors=<replaceable>MODE</replaceable></option></term>
+
+        <listitem><para>Control verification of units and their dependencies and whether
+        <command>systemd-analyze verify</command> exits with a non-zero process exit status or not. With
+        <command>yes</command>, return a non-zero process exit status when warnings arise during verification
+        of either the specified unit or any of its associated dependencies. With <command>no</command>,
+        return a non-zero process exit status when warnings arise during verification of only the specified
+        unit. With <command>one</command>, return a non-zero process exit status when warnings arise during
+        verification of either the specified unit or its immediate dependencies. If this option is not
+        specified, zero is returned as the exit status regardless whether warnings arise during verification
+        or not.</para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--root=<replaceable>PATH</replaceable></option></term>
+
+        <listitem><para>With <command>cat-files</command> and <command>verify</command>,
+        operate on files underneath the specified root path <replaceable>PATH</replaceable>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--image=<replaceable>PATH</replaceable></option></term>
+
+        <listitem><para>With <command>cat-files</command> and <command>verify</command>,
+        operate on files inside the specified image path <replaceable>PATH</replaceable>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+
+      <xi:include href="standard-options.xml" xpointer="image-policy-open" />
+
+      <varlistentry>
+        <term><option>--offline=<replaceable>BOOL</replaceable></option></term>
+
+        <listitem><para>With <command>security</command>, perform an offline security review
+        of the specified unit files, i.e. does not have to rely on PID 1 to acquire security
+        information for the files like the <command>security</command> verb when used by itself does.
+        This means that <option>--offline=</option> can be used with <option>--root=</option> and
+        <option>--image=</option> as well. If a unit's overall exposure level is above that set by
+        <option>--threshold=</option> (default value is 100), <option>--offline=</option> will return
+        an error.</para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--profile=<replaceable>PATH</replaceable></option></term>
+
+        <listitem><para>With <command>security</command> <option>--offline=</option>, takes into
+        consideration the specified portable profile when assessing unit settings.
+        The profile can be passed by name, in which case the well-known system locations will
+        be searched, or it can be the full path to a specific drop-in file.</para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--threshold=<replaceable>NUMBER</replaceable></option></term>
+
+        <listitem><para>With <command>security</command>, allow the user to set a custom value
+        to compare the overall exposure level with, for the specified unit files. If a unit's
+        overall exposure level, is greater than that set by the user, <command>security</command>
+        will return an error. <option>--threshold=</option> can be used with <option>--offline=</option>
+        as well and its default value is 100.</para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--security-policy=<replaceable>PATH</replaceable></option></term>
+
+        <listitem><para>With <command>security</command>, allow the user to define a custom set of
+        requirements formatted as a JSON file against which to compare the specified unit file(s)
+        and determine their overall exposure level to security threats.</para>
+
+        <table>
+          <title>Accepted Assessment Test Identifiers</title>
+
+          <tgroup cols='1'>
+            <colspec colname='directive' />
+            <thead>
+              <row>
+                <entry>Assessment Test Identifier</entry>
+              </row>
+            </thead>
+            <tbody>
+              <row>
+                <entry>UserOrDynamicUser</entry>
+              </row>
+              <row>
+                <entry>SupplementaryGroups</entry>
+              </row>
+              <row>
+                <entry>PrivateMounts</entry>
+              </row>
+              <row>
+                <entry>PrivateDevices</entry>
+              </row>
+              <row>
+                <entry>PrivateTmp</entry>
+              </row>
+              <row>
+                <entry>PrivateNetwork</entry>
+              </row>
+              <row>
+                <entry>PrivateUsers</entry>
+              </row>
+              <row>
+                <entry>ProtectControlGroups</entry>
+              </row>
+              <row>
+                <entry>ProtectKernelModules</entry>
+              </row>
+              <row>
+                <entry>ProtectKernelTunables</entry>
+              </row>
+              <row>
+                <entry>ProtectKernelLogs</entry>
+              </row>
+              <row>
+                <entry>ProtectClock</entry>
+              </row>
+              <row>
+                <entry>ProtectHome</entry>
+              </row>
+              <row>
+                <entry>ProtectHostname</entry>
+              </row>
+              <row>
+                <entry>ProtectSystem</entry>
+              </row>
+              <row>
+                <entry>RootDirectoryOrRootImage</entry>
+              </row>
+              <row>
+                <entry>LockPersonality</entry>
+              </row>
+              <row>
+                <entry>MemoryDenyWriteExecute</entry>
+              </row>
+              <row>
+                <entry>NoNewPrivileges</entry>
+              </row>
+              <row>
+                <entry>CapabilityBoundingSet_CAP_SYS_ADMIN</entry>
+              </row>
+              <row>
+                <entry>CapabilityBoundingSet_CAP_SET_UID_GID_PCAP</entry>
+              </row>
+              <row>
+                <entry>CapabilityBoundingSet_CAP_SYS_PTRACE</entry>
+              </row>
+              <row>
+                <entry>CapabilityBoundingSet_CAP_SYS_TIME</entry>
+              </row>
+              <row>
+                <entry>CapabilityBoundingSet_CAP_NET_ADMIN</entry>
+              </row>
+              <row>
+                <entry>CapabilityBoundingSet_CAP_SYS_RAWIO</entry>
+              </row>
+              <row>
+                <entry>CapabilityBoundingSet_CAP_SYS_MODULE</entry>
+              </row>
+              <row>
+                <entry>CapabilityBoundingSet_CAP_AUDIT</entry>
+              </row>
+              <row>
+                <entry>CapabilityBoundingSet_CAP_SYSLOG</entry>
+              </row>
+              <row>
+                <entry>CapabilityBoundingSet_CAP_SYS_NICE_RESOURCE</entry>
+              </row>
+              <row>
+                <entry>CapabilityBoundingSet_CAP_MKNOD</entry>
+              </row>
+              <row>
+                <entry>CapabilityBoundingSet_CAP_CHOWN_FSETID_SETFCAP</entry>
+              </row>
+              <row>
+                <entry>CapabilityBoundingSet_CAP_DAC_FOWNER_IPC_OWNER</entry>
+              </row>
+              <row>
+                <entry>CapabilityBoundingSet_CAP_KILL</entry>
+              </row>
+              <row>
+                <entry>CapabilityBoundingSet_CAP_NET_BIND_SERVICE_BROADCAST_RAW</entry>
+              </row>
+              <row>
+                <entry>CapabilityBoundingSet_CAP_SYS_BOOT</entry>
+              </row>
+              <row>
+                <entry>CapabilityBoundingSet_CAP_MAC</entry>
+              </row>
+              <row>
+                <entry>CapabilityBoundingSet_CAP_LINUX_IMMUTABLE</entry>
+              </row>
+              <row>
+                <entry>CapabilityBoundingSet_CAP_IPC_LOCK</entry>
+              </row>
+              <row>
+                <entry>CapabilityBoundingSet_CAP_SYS_CHROOT</entry>
+              </row>
+              <row>
+                <entry>CapabilityBoundingSet_CAP_BLOCK_SUSPEND</entry>
+              </row>
+              <row>
+                <entry>CapabilityBoundingSet_CAP_WAKE_ALARM</entry>
+              </row>
+              <row>
+                <entry>CapabilityBoundingSet_CAP_LEASE</entry>
+              </row>
+              <row>
+                <entry>CapabilityBoundingSet_CAP_SYS_TTY_CONFIG</entry>
+              </row>
+              <row>
+                <entry>CapabilityBoundingSet_CAP_BPF</entry>
+              </row>
+              <row>
+                <entry>UMask</entry>
+              </row>
+              <row>
+                <entry>KeyringMode</entry>
+              </row>
+              <row>
+                <entry>ProtectProc</entry>
+              </row>
+              <row>
+                <entry>ProcSubset</entry>
+              </row>
+              <row>
+                <entry>NotifyAccess</entry>
+              </row>
+              <row>
+                <entry>RemoveIPC</entry>
+              </row>
+              <row>
+                <entry>Delegate</entry>
+              </row>
+              <row>
+                <entry>RestrictRealtime</entry>
+              </row>
+              <row>
+                <entry>RestrictSUIDSGID</entry>
+              </row>
+              <row>
+                <entry>RestrictNamespaces_user</entry>
+              </row>
+              <row>
+                <entry>RestrictNamespaces_mnt</entry>
+              </row>
+              <row>
+                <entry>RestrictNamespaces_ipc</entry>
+              </row>
+              <row>
+                <entry>RestrictNamespaces_pid</entry>
+              </row>
+              <row>
+                <entry>RestrictNamespaces_cgroup</entry>
+              </row>
+              <row>
+                <entry>RestrictNamespaces_uts</entry>
+              </row>
+              <row>
+                <entry>RestrictNamespaces_net</entry>
+              </row>
+              <row>
+                <entry>RestrictAddressFamilies_AF_INET_INET6</entry>
+              </row>
+              <row>
+                <entry>RestrictAddressFamilies_AF_UNIX</entry>
+              </row>
+              <row>
+                <entry>RestrictAddressFamilies_AF_NETLINK</entry>
+              </row>
+              <row>
+                <entry>RestrictAddressFamilies_AF_PACKET</entry>
+              </row>
+              <row>
+                <entry>RestrictAddressFamilies_OTHER</entry>
+              </row>
+              <row>
+                <entry>SystemCallArchitectures</entry>
+              </row>
+              <row>
+                <entry>SystemCallFilter_swap</entry>
+              </row>
+              <row>
+                <entry>SystemCallFilter_obsolete</entry>
+              </row>
+              <row>
+                <entry>SystemCallFilter_clock</entry>
+              </row>
+              <row>
+                <entry>SystemCallFilter_cpu_emulation</entry>
+              </row>
+              <row>
+                <entry>SystemCallFilter_debug</entry>
+              </row>
+              <row>
+                <entry>SystemCallFilter_mount</entry>
+              </row>
+              <row>
+                <entry>SystemCallFilter_module</entry>
+              </row>
+              <row>
+                <entry>SystemCallFilter_raw_io</entry>
+              </row>
+              <row>
+                <entry>SystemCallFilter_reboot</entry>
+              </row>
+              <row>
+                <entry>SystemCallFilter_privileged</entry>
+              </row>
+              <row>
+                <entry>SystemCallFilter_resources</entry>
+              </row>
+              <row>
+                <entry>IPAddressDeny</entry>
+              </row>
+              <row>
+                <entry>DeviceAllow</entry>
+              </row>
+              <row>
+                <entry>AmbientCapabilities</entry>
+              </row>
+            </tbody>
+          </tgroup>
+        </table>
+
+        <para>See example "JSON Policy" below.</para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--json=<replaceable>MODE</replaceable></option></term>
+
+        <listitem><para>With the <command>security</command> command, generate a JSON formatted
+        output of the security analysis table. The format is a JSON array with objects
+        containing the following fields: <varname>set</varname> which indicates if the setting has
+        been enabled or not, <varname>name</varname> which is what is used to refer to the setting,
+        <varname>json_field</varname> which is the JSON compatible identifier of the setting,
+        <varname>description</varname> which is an outline of the setting state, and
+        <varname>exposure</varname> which is a number in the range 0.0…10.0, where a higher value
+        corresponds to a higher security threat. The JSON version of the table is printed to standard
+        output. The <replaceable>MODE</replaceable> passed to the option can be one of three:
+        <option>off</option> which is the default, <option>pretty</option> and <option>short</option>
+        which respectively output a prettified or shorted JSON version of the security table.
+
+        With the <command>plot</command> command, generate a JSON formatted output of the raw time data.
+        The format is a JSON array with objects containing the following fields: <varname>name</varname>
+        which is the unit name, <varname>activated</varname> which is the time after startup the
+        service was activated, <varname>activating</varname> which is how long after startup the service
+        was initially started, <varname>time</varname> which is how long the service took to activate
+        from when it was initially started, <varname>deactivated</varname> which is the time after startup
+        that the service was deactivated, <varname>deactivating</varname> which is the time after startup
+        that the service was initially told to deactivate.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--iterations=<replaceable>NUMBER</replaceable></option></term>
+
+        <listitem><para>When used with the <command>calendar</command> command, show the specified number of
+        iterations the specified calendar expression will elapse next. Defaults to 1.</para>
+
+        <xi:include href="version-info.xml" xpointer="v242"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--base-time=<replaceable>TIMESTAMP</replaceable></option></term>
+
+        <listitem><para>When used with the <command>calendar</command> command, show next iterations relative
+        to the specified point in time. If not specified defaults to the current time.</para>
+
+        <xi:include href="version-info.xml" xpointer="v244"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--unit=<replaceable>UNIT</replaceable></option></term>
+
+        <listitem><para>When used with the <command>condition</command> command, evaluate all the
+        <varname index="false">Condition*=...</varname> and <varname index="false">Assert*=...</varname>
+        assignments in the specified unit file. The full unit search path is formed by combining the
+        directories for the specified unit with the usual unit load paths. The variable
+        <varname>$SYSTEMD_UNIT_PATH</varname> is supported, and may be used to replace or augment the
+        compiled in set of unit load paths; see
+        <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>. All
+        units files present in the directory containing the specified unit will be used in preference to the
+        other paths.</para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--table</option></term>
+
+        <listitem><para>When used with the <command>plot</command> command, the raw time data is output in a table.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v253"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--no-legend</option></term>
+
+        <listitem><para>When used with the <command>plot</command> command in combination with either
+        <option>--table</option> or <option>--json=</option>, no legends or hints are included in the output.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v253"/></listitem>
+      </varlistentry>
+
+      <xi:include href="user-system-options.xml" xpointer="host" />
+      <xi:include href="user-system-options.xml" xpointer="machine" />
+
+      <varlistentry>
+        <term><option>-q</option></term>
+        <term><option>--quiet</option></term>
+
+        <listitem><para>Suppress hints and other non-essential output.</para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--tldr</option></term>
+
+        <listitem><para>With <command>cat-config</command>, only print the "interesting" parts of the
+        configuration files, skipping comments and empty lines and section headers followed only by
+        comments and empty lines.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+
+      <xi:include href="standard-options.xml" xpointer="help" />
+      <xi:include href="standard-options.xml" xpointer="version" />
+      <xi:include href="standard-options.xml" xpointer="no-pager" />
+    </variablelist>
+
+  </refsect1>
+
+  <refsect1>
+    <title>Exit status</title>
+
+    <para>For most commands, 0 is returned on success, and a non-zero failure code otherwise.</para>
+
+    <para>With the verb <command>compare-versions</command>, in the two-argument form,
+    <constant>12</constant>, <constant>0</constant>, <constant>11</constant> is returned if the second
+    version string is respectively larger, equal, or smaller to the first. In the three-argument form,
+    <constant>0</constant> or <constant>1</constant> if the condition is respectively true or false.</para>
+  </refsect1>
+
+  <xi:include href="common-variables.xml" />
+
+  <refsect1>
+    <title>Examples</title>
+
+    <example>
+      <title>JSON Policy</title>
+
+      <para>The JSON file passed as a path parameter to <option>--security-policy=</option> has a top-level
+      JSON object, with keys being the assessment test identifiers mentioned above. The values in the file
+      should be JSON objects with one or more of the following fields: <option>description_na</option>
+      (string), <option>description_good</option> (string), <option>description_bad</option> (string),
+      <option>weight</option> (unsigned integer), and <option>range</option> (unsigned integer). If any of
+      these fields corresponding to a specific id of the unit file is missing from the JSON object, the
+      default built-in field value corresponding to that same id is used for security analysis as default.
+      The weight and range fields are used in determining the overall exposure level of the unit files: the
+      value of each setting is assigned a badness score, which is multiplied by the policy weight and divided
+      by the policy range to determine the overall exposure that the setting implies. The computed badness is
+      summed across all settings in the unit file, normalized to the 1…100 range, and used to determine the
+      overall exposure level of the unit.  By allowing users to manipulate these fields, the 'security' verb
+      gives them the option to decide for themself which ids are more important and hence should have a
+      greater effect on the exposure level. A weight of <literal>0</literal> means the setting will not be
+      checked.</para>
+
+      <programlisting>
+{
+  "PrivateDevices":
+    {
+    "description_good": "Service has no access to hardware devices",
+    "description_bad": "Service potentially has access to hardware devices",
+    "weight": 1000,
+    "range": 1
+    },
+  "PrivateMounts":
+    {
+    "description_good": "Service cannot install system mounts",
+    "description_bad": "Service may install system mounts",
+    "weight": 1000,
+    "range": 1
+    },
+  "PrivateNetwork":
+    {
+    "description_good": "Service has no access to the host's network",
+    "description_bad": "Service has access to the host's network",
+    "weight": 2500,
+    "range": 1
+    },
+  "PrivateTmp":
+    {
+    "description_good": "Service has no access to other software's temporary files",
+    "description_bad": "Service has access to other software's temporary files",
+    "weight": 1000,
+    "range": 1
+    },
+  "PrivateUsers":
+    {
+    "description_good": "Service does not have access to other users",
+    "description_bad": "Service has access to other users",
+    "weight": 1000,
+    "range": 1
+    }
+}
+      </programlisting>
+    </example>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-ask-password-console.service.xml b/man/systemd-ask-password-console.service.xml
new file mode 100644
index 0000000..03b7317
--- /dev/null
+++ b/man/systemd-ask-password-console.service.xml
@@ -0,0 +1,67 @@
+<?xml version="1.0"?>
+<!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+<refentry id="systemd-ask-password-console.service">
+
+  <refentryinfo>
+    <title>systemd-ask-password-console.service</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-ask-password-console.service</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-ask-password-console.service</refname>
+    <refname>systemd-ask-password-console.path</refname>
+    <refname>systemd-ask-password-wall.service</refname>
+    <refname>systemd-ask-password-wall.path</refname>
+    <refpurpose>Query the user for system passwords on the
+    console and via wall</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>systemd-ask-password-console.service</filename></para>
+    <para><filename>systemd-ask-password-console.path</filename></para>
+    <para><filename>systemd-ask-password-wall.service</filename></para>
+    <para><filename>systemd-ask-password-wall.path</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><filename>systemd-ask-password-console.service</filename> is
+    a system service that queries the user for system passwords (such
+    as hard disk encryption keys and SSL certificate passphrases) on
+    the console. It is intended to be used during boot to ensure
+    proper handling of passwords necessary for boot.
+    <filename>systemd-ask-password-wall.service</filename> is a system
+    service that informs all logged in users for system passwords via
+    <citerefentry project='man-pages'><refentrytitle>wall</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
+    It is intended to be used after boot to ensure that users are
+    properly notified.</para>
+
+    <para>See the <ulink url="https://systemd.io/PASSWORD_AGENTS/">developer
+    documentation</ulink> for more information about the system password logic.
+    </para>
+
+    <para>Note that these services invoke
+    <citerefentry><refentrytitle>systemd-tty-ask-password-agent</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    with either the <command>--watch --console</command> or
+    <command>--watch --wall</command> command line parameters.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-tty-ask-password-agent</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>wall</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-ask-password.xml b/man/systemd-ask-password.xml
new file mode 100644
index 0000000..5bae448
--- /dev/null
+++ b/man/systemd-ask-password.xml
@@ -0,0 +1,268 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd-ask-password"
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd-ask-password</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-ask-password</refentrytitle>
+    <manvolnum>1</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-ask-password</refname>
+    <refpurpose>Query the user for a system password</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <cmdsynopsis>
+      <command>systemd-ask-password <arg choice="opt" rep="repeat">OPTIONS</arg> <arg choice="opt">MESSAGE</arg></command>
+    </cmdsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>systemd-ask-password</command> may be used to query
+    a system password or passphrase from the user, using a question
+    message specified on the command line. When run from a TTY it will
+    query a password on the TTY and print it to standard output. When
+    run with no TTY or with <option>--no-tty</option> it will use the
+    system-wide query mechanism, which allows active users to respond via
+    several agents, listed below.</para>
+
+    <para>The purpose of this tool is to query system-wide passwords
+    — that is passwords not attached to a specific user account.
+    Examples include: unlocking encrypted hard disks when they are
+    plugged in or at boot, entering an SSL certificate passphrase for
+    web and VPN servers.</para>
+
+    <para>Existing agents are:
+    <itemizedlist>
+
+      <listitem><para>A boot-time password agent asking the user for
+      passwords using
+      <citerefentry project='die-net'><refentrytitle>plymouth</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      </para></listitem>
+
+      <listitem><para>A boot-time password agent querying the user
+      directly on the console —
+      <citerefentry><refentrytitle>systemd-ask-password-console.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      </para></listitem>
+
+      <listitem><para>An agent requesting password input via a
+      <citerefentry project='man-pages'><refentrytitle>wall</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+      message —
+      <citerefentry><refentrytitle>systemd-ask-password-wall.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      </para></listitem>
+
+      <listitem><para>A TTY agent that is temporarily spawned during
+      <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+      invocations,</para></listitem>
+
+      <listitem><para>A command line agent which can be started
+      temporarily to process queued password
+      requests — <command>systemd-tty-ask-password-agent --query</command>.
+      </para></listitem>
+    </itemizedlist></para>
+
+    <para>Answering system-wide password queries is a privileged operation, hence
+    all the agents listed above (except for the last one), run as privileged
+    system services. The last one also needs elevated privileges, so
+    should be run through
+    <citerefentry project='die-net'><refentrytitle>sudo</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    or similar.</para>
+
+    <para>Additional password agents may be implemented according to
+    the <ulink url="https://systemd.io/PASSWORD_AGENTS/">systemd Password Agent
+    Specification</ulink>.</para>
+
+    <para>If a password is queried on a TTY, the user may press TAB to
+    hide the asterisks normally shown for each character typed.
+    Pressing Backspace as first key achieves the same effect.</para>
+
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>The following options are understood:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><option>--icon=</option></term>
+
+        <listitem><para>Specify an icon name alongside the password
+        query, which may be used in all agents supporting graphical
+        display. The icon name should follow the <ulink
+        url="https://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html">XDG
+        Icon Naming Specification</ulink>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--id=</option></term>
+        <listitem><para>Specify an identifier for this password
+        query. This identifier is freely choosable and allows
+        recognition of queries by involved agents. It should include
+        the subsystem doing the query and the specific object the
+        query is done for. Example:
+        <literal>--id=cryptsetup:/dev/sda5</literal>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v227"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--keyname=</option></term>
+        <listitem><para>Configure a kernel keyring key name to use as
+        cache for the password. If set, then the tool will try to push
+        any collected passwords into the kernel keyring of the root
+        user, as a key of the specified name. If combined with
+        <option>--accept-cached</option>, it will also try to retrieve
+        such cached passwords from the key in the kernel keyring
+        instead of querying the user right away. By using this option,
+        the kernel keyring may be used as effective cache to avoid
+        repeatedly asking users for passwords, if there are multiple
+        objects that may be unlocked with the same password. The
+        cached key will have a timeout of 2.5min set, after which it
+        will be purged from the kernel keyring. Note that it is
+        possible to cache multiple passwords under the same keyname,
+        in which case they will be stored as <constant>NUL</constant>-separated list of
+        passwords. Use
+        <citerefentry project='die-net'><refentrytitle>keyctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+        to access the cached key via the kernel keyring
+        directly. Example: <literal>--keyname=cryptsetup</literal></para>
+
+        <xi:include href="version-info.xml" xpointer="v227"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--credential=</option></term>
+        <listitem><para>Configure a credential to read the password from – if it exists. This may be used in
+        conjunction with the <varname>ImportCredential=</varname>, <varname>LoadCredential=</varname> and
+        <varname>SetCredential=</varname> settings in unit files. See
+        <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
+        details. If not specified, defaults to <literal>password</literal>. This option has no effect if no
+        credentials directory is passed to the program (i.e. <varname>$CREDENTIALS_DIRECTORY</varname> is not
+        set) or if the no credential of the specified name exists.</para>
+
+        <xi:include href="version-info.xml" xpointer="v249"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--timeout=</option></term>
+
+        <listitem><para>Specify the query timeout in seconds. Defaults
+        to 90s. A timeout of 0 waits indefinitely. </para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--echo=yes|no|masked</option></term>
+
+        <listitem><para>Controls whether to echo user input. Takes a boolean or the special string
+        <literal>masked</literal>, the default being the latter. If enabled the typed characters are echoed
+        literally, which is useful for prompting for usernames and other non-protected data. If disabled the
+        typed characters are not echoed in any form, the user will not get feedback on their input. If set to
+        <literal>masked</literal>, an asterisk (<literal>*</literal>) is echoed for each character
+        typed. In this mode, if the user hits the tabulator key (<literal>↹</literal>), echo is turned
+        off. (Alternatively, if the user hits the backspace key (<literal>⌫</literal>) while no data has
+        been entered otherwise, echo is turned off, too).</para>
+
+        <xi:include href="version-info.xml" xpointer="v249"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--echo</option></term>
+        <term><option>-e</option></term>
+
+        <listitem><para>Equivalent to <option>--echo=yes</option>, see above.</para>
+
+        <xi:include href="version-info.xml" xpointer="v217"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--emoji=yes|no|auto</option></term>
+
+        <listitem><para>Controls whether or not to prefix the query with a
+        lock and key emoji (🔐), if the TTY settings permit this. The default
+        is <literal>auto</literal>, which defaults to <literal>yes</literal>,
+        unless <option>--echo=yes</option> is given.</para>
+
+        <xi:include href="version-info.xml" xpointer="v249"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--no-tty</option></term>
+
+        <listitem><para>Never ask for password on current TTY even if
+        one is available. Always use agent system.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--accept-cached</option></term>
+
+        <listitem><para>If passed, accept cached passwords, i.e.
+        passwords previously entered.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--multiple</option></term>
+
+        <listitem><para>When used in conjunction with
+        <option>--accept-cached</option> accept multiple passwords.
+        This will output one password per line.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--no-output</option></term>
+
+        <listitem><para>Do not print passwords to standard output.  This is useful if you want to store a
+        password in kernel keyring with <option>--keyname=</option> but do not want it to show up on screen
+        or in logs.</para>
+
+        <xi:include href="version-info.xml" xpointer="v230"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-n</option></term>
+
+        <listitem><para>By default, when the acquired password is written to standard output it is suffixed
+        by a newline character. This may be turned off with the <option>-n</option> switch, similarly to the
+        switch of the same name of the <citerefentry
+        project='man-pages'><refentrytitle>echo</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+        command.</para>
+
+        <xi:include href="version-info.xml" xpointer="v249"/></listitem>
+      </varlistentry>
+
+      <xi:include href="standard-options.xml" xpointer="help" />
+    </variablelist>
+
+  </refsect1>
+
+  <refsect1>
+    <title>Exit status</title>
+
+    <para>On success, 0 is returned, a non-zero failure code
+    otherwise.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-ask-password-console.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-tty-ask-password-agent</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry project='die-net'><refentrytitle>keyctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry project='die-net'><refentrytitle>plymouth</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>wall</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-backlight@.service.xml b/man/systemd-backlight@.service.xml
new file mode 100644
index 0000000..431b27b
--- /dev/null
+++ b/man/systemd-backlight@.service.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0"?>
+<!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+<refentry id="systemd-backlight@.service" conditional='ENABLE_BACKLIGHT'
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd-backlight@.service</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-backlight@.service</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-backlight@.service</refname>
+    <refname>systemd-backlight</refname>
+    <refpurpose>Load and save the display backlight brightness at boot and shutdown</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>systemd-backlight@.service</filename></para>
+    <para><filename>/usr/lib/systemd/systemd-backlight</filename> save [backlight|leds]:DEVICE</para>
+    <para><filename>/usr/lib/systemd/systemd-backlight</filename> load [backlight|leds]:DEVICE</para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><filename>systemd-backlight@.service</filename> is a service that restores the display backlight
+    brightness at early boot and saves it at shutdown. On disk, the backlight brightness is stored in
+    <filename>/var/lib/systemd/backlight/</filename>. During loading, if the udev property
+    <option>ID_BACKLIGHT_CLAMP</option> is not set to false, the brightness is clamped to a value of at least
+    1 or 5% of maximum brightness, whichever is greater. The percentage can be adjusted by specifying a
+    percentage (needs to be suffixed with <literal>%</literal>, e.g. <literal>30%</literal>) to the property
+    <option>ID_BACKLIGHT_CLAMP</option>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Kernel Command Line</title>
+
+    <para><filename>systemd-backlight</filename> understands the
+    following kernel command line parameter:</para>
+
+    <variablelist class='kernel-commandline-options'>
+      <varlistentry>
+        <term><varname>systemd.restore_state=</varname></term>
+
+        <listitem><para>Takes a boolean argument. Defaults to
+        <literal>1</literal>. If <literal>0</literal>, does not
+        restore the backlight settings on boot. However, settings will
+        still be stored on shutdown. </para>
+
+        <xi:include href="version-info.xml" xpointer="v209"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-battery-check.service.xml b/man/systemd-battery-check.service.xml
new file mode 100644
index 0000000..8be5484
--- /dev/null
+++ b/man/systemd-battery-check.service.xml
@@ -0,0 +1,91 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd-battery-check.service" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd-battery-check</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-battery-check.service</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-battery-check.service</refname>
+    <refname>systemd-battery-check</refname>
+    <refpurpose>Check battery level whether there's enough charge, and power off if not</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>systemd-battery-check.service</filename></para>
+    <cmdsynopsis>
+      <command>/usr/lib/systemd/systemd-battery-check</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+    </cmdsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>This service checks the presence of an external power supply and the battery level during the early
+    boot stage to determine whether there is sufficient power to carry on with the booting process.</para>
+
+    <para><command>systemd-battery-check</command> returns success if the device is connected to an AC power
+    source or if the battery charge is greater than 5%. It returns failure otherwise.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>The following options are understood by <command>systemd-battery-check</command>:</para>
+
+    <variablelist>
+      <xi:include href="standard-options.xml" xpointer="help" />
+      <xi:include href="standard-options.xml" xpointer="version" />
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Exit status</title>
+
+    <para>
+      On success (running on AC power or battery capacity greater than 5%), 0 is returned, a non-zero failure
+      code otherwise.
+    </para>
+  </refsect1>
+
+  <refsect1>
+    <title>Kernel Command Line</title>
+
+    <para>The following variables are understood:</para>
+
+    <variablelist class='kernel-commandline-options'>
+      <varlistentry>
+        <term><varname>systemd.battery-check=<replaceable>BOOL</replaceable></varname></term>
+
+        <listitem>
+          <para>Takes a boolean. If specified with false, <command>systemd-battery-check</command> command
+          will return immediately with exit status 0 without checking battery capacity and AC power
+          existence, and the service <filename>systemd-battery-check.service</filename> will succeed. This
+          may be useful when the command wrongly detects and reports battery capacity percentage or AC power
+          existence, or when you want to boot the system forcibly.</para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-binfmt.service.xml b/man/systemd-binfmt.service.xml
new file mode 100644
index 0000000..15453fa
--- /dev/null
+++ b/man/systemd-binfmt.service.xml
@@ -0,0 +1,71 @@
+<?xml version="1.0"?>
+<!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+<refentry id="systemd-binfmt.service" conditional='ENABLE_BINFMT'
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd-binfmt.service</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-binfmt.service</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-binfmt.service</refname>
+    <refname>systemd-binfmt</refname>
+    <refpurpose>Configure additional binary formats for executables at boot</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>systemd-binfmt.service</filename></para>
+    <para><filename>/usr/lib/systemd/systemd-binfmt</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><filename>systemd-binfmt.service</filename> is an early boot
+    service that registers additional binary formats for executables
+    in the kernel.</para>
+
+    <para>See
+    <citerefentry><refentrytitle>binfmt.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for information about the configuration of this service.</para>
+  </refsect1>
+
+  <refsect1><title>Options</title>
+    <variablelist>
+
+      <varlistentry>
+        <term><option>--unregister</option></term>
+        <listitem><para>If passed, instead of registering configured binary formats in the kernel, the
+        reverse operation is executed: all currently registered binary formats are unregistered from the
+        kernel.</para>
+
+        <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+      </varlistentry>
+
+      <xi:include href="standard-options.xml" xpointer="cat-config" />
+      <xi:include href="standard-options.xml" xpointer="tldr" />
+      <xi:include href="standard-options.xml" xpointer="no-pager" />
+      <xi:include href="standard-options.xml" xpointer="help" />
+      <xi:include href="standard-options.xml" xpointer="version" />
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>binfmt.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry project='die-net'><refentrytitle>wine</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-bless-boot-generator.xml b/man/systemd-bless-boot-generator.xml
new file mode 100644
index 0000000..173d5ae
--- /dev/null
+++ b/man/systemd-bless-boot-generator.xml
@@ -0,0 +1,48 @@
+<?xml version="1.0"?>
+<!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+<refentry id="systemd-bless-boot-generator" conditional='ENABLE_BOOTLOADER'>
+
+  <refentryinfo>
+    <title>systemd-bless-boot-generator</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-bless-boot-generator</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-bless-boot-generator</refname>
+    <refpurpose>Pull <filename>systemd-bless-boot.service</filename> into the initial boot transaction when boot counting is in effect</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>/usr/lib/systemd/system-generators/systemd-bless-boot-generator</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><filename>systemd-bless-boot-generator</filename> is a generator that pulls
+    <filename>systemd-bless-boot.service</filename> into the initial boot transaction when boot counting, as
+    implemented by <citerefentry><refentrytitle>systemd-boot</refentrytitle><manvolnum>7</manvolnum></citerefentry>, is
+    enabled.</para>
+
+    <para><filename>systemd-bless-boot-generator</filename> implements
+    <citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-bless-boot.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-boot</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-bless-boot.service.xml b/man/systemd-bless-boot.service.xml
new file mode 100644
index 0000000..66454d1
--- /dev/null
+++ b/man/systemd-bless-boot.service.xml
@@ -0,0 +1,121 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd-bless-boot.service" conditional='ENABLE_BOOTLOADER'
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd-bless-boot.service</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-bless-boot.service</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-bless-boot.service</refname>
+    <refname>systemd-bless-boot</refname>
+    <refpurpose>Mark current boot process as successful</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>systemd-bless-boot.service</filename></para>
+    <para><filename>/usr/lib/systemd/systemd-bless-boot</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><filename>systemd-bless-boot.service</filename> is a system service that marks the current boot process as
+    successful. It's automatically pulled into the initial transaction when
+    <citerefentry><refentrytitle>systemd-bless-boot-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    detects that <citerefentry><refentrytitle>systemd-boot</refentrytitle><manvolnum>7</manvolnum></citerefentry> style
+    boot counting is used.</para>
+
+    <para>Internally, the service operates based on the <varname>LoaderBootCountPath</varname> EFI variable (of the
+    vendor UUID <constant>4a67b082-0a4c-41cf-b6c7-440b29bb8c4</constant>), which is passed from the boot loader to the
+    OS. It contains a file system path (relative to the EFI system partition) of the <ulink
+    url="https://uapi-group.org/specifications/specs/boot_loader_specification">Boot Loader Specification</ulink> compliant boot loader entry
+    file or unified kernel image file that was used to boot up the
+    system. <command>systemd-bless-boot.service</command> removes the two 'tries done' and 'tries left' numeric boot
+    counters from the filename, which indicates to future invocations of the boot loader that the entry has completed
+    booting successfully at least once. (This service will hence rename the boot loader entry file or unified kernel
+    image file on the first successful boot.)</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>The <filename>/usr/lib/systemd/systemd-bless-boot</filename> executable may also be invoked from the
+    command line, taking one of the following command arguments:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><option>status</option></term>
+
+        <listitem><para>The current status of the boot loader entry file or unified kernel image file is shown. This
+        outputs one of <literal>good</literal>, <literal>bad</literal>, <literal>indeterminate</literal>,
+        <literal>clean</literal>, depending on the state and previous invocations of the command. The string
+        <literal>indeterminate</literal> is shown initially after boot, before it has been marked as "good" or
+        "bad". The string <literal>good</literal> is shown after the boot was marked as "good" with the
+        <option>good</option> command below, and "bad" conversely after the <option>bad</option> command was
+        invoked. The string <literal>clean</literal> is returned when boot counting is currently not in effect.</para>
+
+        <para>This command is implied if no command argument is specified.</para>
+
+        <xi:include href="version-info.xml" xpointer="v240"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>good</option></term>
+
+        <listitem><para>When invoked, the current boot loader entry file or unified kernel image file will be marked as
+        "good", executing the file rename operation described above. This command is intended to be invoked at the end
+        of a successful boot. The <filename>systemd-bless-boot.service</filename> unit invokes this
+        command.</para>
+
+        <xi:include href="version-info.xml" xpointer="v240"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>bad</option></term>
+
+        <listitem><para>When called the 'tries left' counter in the boot loader entry file name or unified kernel image
+        file name is set to zero, marking the boot loader entry or kernel image as "bad", so that the boot loader won't
+        consider it anymore on future boots (at least as long as there are other entries available that are not marked
+        "bad" yet). This command is normally not executed, but can be used to instantly put an end to the boot counting
+        logic if a problem is detected and persistently mark the boot entry as bad.</para>
+
+        <xi:include href="version-info.xml" xpointer="v240"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>indeterminate</option></term>
+
+        <listitem><para>This command undoes any marking of the current boot loader entry file or unified kernel image
+        file as good or bad. This is implemented by renaming the boot loader entry file or unified kernel image file
+        back to the path encoded in the <varname>LoaderBootCountPath</varname> EFI variable.</para>
+
+        <xi:include href="version-info.xml" xpointer="v240"/></listitem>
+      </varlistentry>
+
+      <xi:include href="standard-options.xml" xpointer="help" />
+      <xi:include href="standard-options.xml" xpointer="version" />
+
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-boot</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-boot-check-no-failures.service.xml b/man/systemd-boot-check-no-failures.service.xml
new file mode 100644
index 0000000..39a2aa8
--- /dev/null
+++ b/man/systemd-boot-check-no-failures.service.xml
@@ -0,0 +1,52 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd-boot-check-no-failures.service"
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd-boot-check-no-failures.service</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-boot-check-no-failures.service</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-boot-check-no-failures.service</refname>
+    <refname>systemd-boot-check-no-failures</refname>
+    <refpurpose>verify that the system booted up cleanly</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>systemd-boot-check-no-failures.service</filename></para>
+    <para><filename>/usr/lib/systemd/system-boot-check-no-failures</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><filename>systemd-boot-check-no-failures.service</filename> is a system service that checks whether the
+    system booted up successfully. This service implements a very minimal test only: whether there are any failed units on
+    the system. This service is disabled by default. When enabled, it is ordered before
+    <filename>boot-complete.target</filename>, thus ensuring the target cannot be reached when the system booted up
+    with failed services.</para>
+
+    <para>Note that due the simple nature of this check this service is probably not suitable for deployment in most
+    scenarios. It is primarily useful only as example for developing more fine-grained checks to order before
+    <filename>boot-complete.target</filename>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-boot-random-seed.service.xml b/man/systemd-boot-random-seed.service.xml
new file mode 100644
index 0000000..87e2e27
--- /dev/null
+++ b/man/systemd-boot-random-seed.service.xml
@@ -0,0 +1,101 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd-boot-random-seed.service" conditional='ENABLE_BOOTLOADER'
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd-boot-random-seed.service</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-boot-random-seed.service</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-boot-random-seed.service</refname>
+    <refpurpose>Refresh boot loader random seed at boot</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>systemd-boot-random-seed.service</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><filename>systemd-boot-random-seed.service</filename> is a system service that automatically
+    refreshes the boot loader random seed stored in the EFI System Partition (ESP), from the Linux kernel
+    entropy pool. The boot loader random seed is primarily consumed and updated by
+    <citerefentry><refentrytitle>systemd-boot</refentrytitle><manvolnum>7</manvolnum></citerefentry> from the
+    UEFI environment (or
+    <citerefentry><refentrytitle>systemd-stub</refentrytitle><manvolnum>7</manvolnum></citerefentry> if the
+    former is not used, but the latter is), and passed as initial RNG seed to the OS. It is an effective way
+    to ensure the OS comes up with a random pool that is fully initialized.</para>
+
+    <para>The service also automatically generates a 'system token' to store in an EFI variable in the
+    system's NVRAM. The boot loader may then combine the on-disk random seed and the system token by
+    cryptographic hashing, and pass it to the OS it boots as initialization seed for its entropy pool. Note:
+    the random seed stored in the ESP is refreshed on <emphasis>every</emphasis> reboot ensuring that
+    multiple subsequent boots will boot with different seeds. On the other hand, the system token is
+    generated randomly <emphasis>once</emphasis>, and then persistently stored in the system's EFI variable
+    storage, ensuring the same disk image won't result in the same series of boot loader seed values if used
+    on multiple systems in parallel.</para>
+
+    <para>The <filename>systemd-boot-random-seed.service</filename> unit invokes the <command>bootctl
+    random-seed</command> command, which updates the random seed in the ESP, and initializes the system
+    token if it's not initialized yet. The service is conditionalized so that it is run only when a boot
+    loader is used that implements the <ulink url="https://systemd.io/BOOT_LOADER_INTERFACE">Boot Loader
+    Interface</ulink>.</para> <para>For further details see
+    <citerefentry><refentrytitle>bootctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, regarding
+    the command this service invokes.</para>
+
+    <para>Note the relationship between <filename>systemd-boot-random-seed.service</filename> and
+    <citerefentry><refentrytitle>systemd-random-seed</refentrytitle><manvolnum>8</manvolnum></citerefentry>. The
+    former maintains the random seed consumed and updated by the boot environment (i.e. by
+    <citerefentry><refentrytitle>systemd-boot</refentrytitle><manvolnum>7</manvolnum></citerefentry> or
+    <citerefentry><refentrytitle>systemd-stub</refentrytitle><manvolnum>7</manvolnum></citerefentry>), the
+    latter maintains a random seed consumed and updated by the OS itself. The former ensures that the OS has
+    a filled entropy pool already during earliest boot when regular disk access is not available yet
+    (i.e. when the OS random seed cannot be loaded yet). The latter is processed much later, once writable
+    disk access is available. Thus it cannot be used to seed the initial boot phase, but typically has much
+    higher quality of entropy. Both files are consumed and updated at boot, but at different
+    times. Specifically:</para>
+
+    <orderedlist>
+      <listitem><para>In UEFI mode, the
+      <citerefentry><refentrytitle>systemd-boot</refentrytitle><manvolnum>7</manvolnum></citerefentry> or
+      <citerefentry><refentrytitle>systemd-stub</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+      components load the boot loader random seed from the ESP, hash it with available entropy and the system
+      token, and then update it on disk. A derived seed is passed to the kernel which writes it to its
+      entropy pool.</para></listitem>
+
+      <listitem><para>In userspace the <filename>systemd-random-seed.service</filename> service loads the OS
+      random seed, writes it to the kernel entropy pool, and then updates it on disk with a new value derived
+      from the kernel entropy pool.</para></listitem>
+
+      <listitem><para>In userspace the <filename>systemd-boot-random-seed.service</filename> service updates
+      the boot loader random seed with a new value derived from the kernel entropy pool.</para></listitem>
+    </orderedlist>
+
+    <para>This logic should ensure that the kernel's entropy pool is seeded during earliest bool already, if
+    possible, but the highest quality entropy is propagated back to both on-disk seeds.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>random</refentrytitle><manvolnum>4</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>bootctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-boot</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-stub</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-random-seed.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-boot.xml b/man/systemd-boot.xml
new file mode 100644
index 0000000..2b0ea9b
--- /dev/null
+++ b/man/systemd-boot.xml
@@ -0,0 +1,650 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd-boot" conditional='ENABLE_BOOTLOADER'
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+  <refentryinfo>
+    <title>systemd-boot</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-boot</refentrytitle>
+    <manvolnum>7</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-boot</refname>
+    <refname>sd-boot</refname>
+    <refpurpose>A simple UEFI boot manager</refpurpose>
+  </refnamediv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>systemd-boot</command> (short: <command>sd-boot</command>) is a simple UEFI boot
+    manager. It provides a textual menu to select the entry to boot and an editor for the kernel command
+    line. <command>systemd-boot</command> supports systems with UEFI firmware only.</para>
+
+    <para><command>systemd-boot</command> loads boot entry information from the EFI system partition (ESP),
+    usually mounted at <filename>/efi/</filename>, <filename>/boot/</filename>, or
+    <filename>/boot/efi/</filename> during OS runtime, as well as from the Extended Boot Loader partition
+    (XBOOTLDR) if it exists (usually mounted to <filename>/boot/</filename>). Configuration file fragments,
+    kernels, initrds and other EFI images to boot generally need to reside on the ESP or the Extended Boot
+    Loader partition. Linux kernels must be built with <option>CONFIG_EFI_STUB</option> to be able to be
+    directly executed as an EFI image. During boot <command>systemd-boot</command> automatically assembles a
+    list of boot entries from the following sources:</para>
+
+    <itemizedlist>
+      <listitem><para>Boot entries defined with <ulink
+      url="https://uapi-group.org/specifications/specs/boot_loader_specification">Boot Loader Specification</ulink> Type #1
+      description files located in <filename>/loader/entries/</filename> on the ESP and the Extended Boot
+      Loader Partition. These usually describe Linux kernel images with associated initrd images, but
+      alternatively may also describe other arbitrary EFI executables.</para></listitem>
+
+      <listitem><para>Unified kernel images, <ulink url="https://uapi-group.org/specifications/specs/boot_loader_specification">Boot
+      Loader Specification</ulink> Type #2, which are executable EFI binaries in
+      <filename>/EFI/Linux/</filename> on the ESP and the Extended Boot Loader Partition.</para></listitem>
+
+      <listitem><para>The Microsoft Windows EFI boot manager, if installed.</para></listitem>
+
+      <listitem><para>The Apple macOS boot manager, if installed.</para></listitem>
+
+      <listitem><para>The EFI Shell binary, if installed.</para></listitem>
+
+      <listitem><para>A <literal>Reboot Into Firmware Interface option</literal>, if supported by the UEFI
+      firmware.</para></listitem>
+
+      <listitem><para>Secure Boot variables enrollment if the UEFI firmware is in setup-mode and files are provided
+      on the ESP.</para></listitem>
+    </itemizedlist>
+
+    <para><command>systemd-boot</command> supports the following features:</para>
+
+    <itemizedlist>
+      <listitem><para>Basic boot manager configuration changes (such as timeout
+      configuration, default boot entry selection, …) may be made directly from the boot loader UI at
+      boot-time, as well as during system runtime with EFI variables.</para></listitem>
+
+      <listitem><para>The boot manager integrates with the <command>systemctl</command> command to implement
+      features such as <command>systemctl reboot --boot-loader-entry=…</command> (for rebooting into a
+      specific boot menu entry, i.e. "reboot into Windows") and <command>systemctl reboot
+      --boot-loader-menu=…</command> (for rebooting into the boot loader menu), by implementing the <ulink
+      url="https://systemd.io/BOOT_LOADER_INTERFACE">Boot Loader Interface</ulink>. See
+      <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> for
+      details.</para></listitem>
+
+      <listitem><para>An EFI variable set by the boot loader informs the OS about the EFI System Partition used
+      during boot. This is then used to automatically mount the correct EFI System Partition to
+      <filename>/efi/</filename> or <filename>/boot/</filename> during OS runtime. See
+      <citerefentry><refentrytitle>systemd-gpt-auto-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+      for details.</para></listitem>
+
+      <listitem><para>The boot manager provides information about the boot time spent in UEFI firmware using
+      the <ulink url="https://systemd.io/BOOT_LOADER_INTERFACE">Boot Loader Interface</ulink>. This
+      information can be displayed using
+      <citerefentry><refentrytitle>systemd-analyze</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
+      </para></listitem>
+
+      <listitem><para>The boot manager implements boot counting and automatic fallback to older, working boot
+      entries on failure. See <ulink url="https://systemd.io/AUTOMATIC_BOOT_ASSESSMENT">Automatic Boot
+      Assessment</ulink>.</para></listitem>
+
+      <listitem><para>The boot manager optionally reads a random seed from the ESP partition, combines it
+      with a 'system token' stored in a persistent EFI variable and derives a random seed to use by the OS as
+      entropy pool initialization, providing a full entropy pool during early boot.</para></listitem>
+
+      <listitem><para>The boot manager allows for Secure Boot variables to be enrolled if the UEFI firmware is
+      in setup-mode. Additionally, variables can be automatically enrolled if configured.</para></listitem>
+    </itemizedlist>
+
+    <para><citerefentry><refentrytitle>bootctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    may be used from a running system to locate the ESP and the Extended Boot Loader Partition, list
+    available entries, and install <command>systemd-boot</command> itself.</para>
+
+    <para><citerefentry><refentrytitle>kernel-install</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    may be used to copy kernel images onto the ESP or the Extended Boot Loader Partition and to generate
+    description files compliant with the Boot Loader
+    Specification.</para>
+
+    <para><citerefentry><refentrytitle>systemd-stub</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+    may be used as UEFI boot stub for executed kernels, which is useful to show graphical boot splashes
+    before transitioning into the Linux world. It is also capable of automatically picking up auxiliary
+    credential files (for boot parameterization) and system extension images, as companion files to the
+    booted kernel images.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Key bindings</title>
+    <para>The following keys may be used in the boot menu:</para>
+
+    <!-- Developer commands Q/v/Ctrl+l deliberately not advertised. -->
+
+    <variablelist>
+      <varlistentry>
+        <term><keycap>↑</keycap> (Up)</term>
+        <term><keycap>↓</keycap> (Down)</term>
+        <term><keycap>j</keycap></term>
+        <term><keycap>k</keycap></term>
+        <term><keycap>PageUp</keycap></term>
+        <term><keycap>PageDown</keycap></term>
+        <term><keycap>Home</keycap></term>
+        <term><keycap>End</keycap></term>
+        <listitem><para>Navigate up/down in the entry list</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><keycap>↵</keycap> (Enter)</term>
+        <term><keycap>→</keycap> (Right)</term>
+        <listitem><para>Boot selected entry</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><keycap>d</keycap></term>
+        <listitem><para>Make selected entry the default</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><keycap>e</keycap></term>
+        <listitem><para>Edit the kernel command line for selected entry</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><keycap>+</keycap></term>
+        <term><keycap>t</keycap></term>
+        <listitem><para>Increase the timeout before default entry is booted</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><keycap>-</keycap></term>
+        <term><keycap>T</keycap></term>
+        <listitem><para>Decrease the timeout</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><keycap>r</keycap></term>
+        <listitem><para>Change screen resolution, skipping any unsupported modes.</para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><keycap>R</keycap></term>
+        <listitem><para>Reset screen resolution to firmware or configuration file default.</para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><keycap>p</keycap></term>
+        <listitem><para>Print status</para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><keycap>h</keycap></term>
+        <term><keycap>?</keycap></term>
+        <term><keycap>F1</keycap></term>
+        <listitem><para>Show a help screen</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><keycap>f</keycap></term>
+        <listitem><para>Reboot into firmware interface.</para>
+
+        <para>For compatibility with the keybindings of several firmware implementations this operation
+        may also be reached with <keycap>F2</keycap>, <keycap>F10</keycap>, <keycap>Del</keycap> and
+        <keycap>Esc</keycap>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><keycombo><keycap>Shift</keycap><keycap>o</keycap></keycombo></term>
+        <listitem><para>Power off the system.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><keycombo><keycap>Shift</keycap><keycap>b</keycap></keycombo></term>
+        <listitem><para>Reboot the system.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+    </variablelist>
+
+    <para>The following keys may be pressed during bootup or in the boot menu to directly boot a specific
+    entry:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><keycap>l</keycap></term>
+        <listitem><para>Linux</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><keycap>w</keycap></term>
+        <listitem><para>Windows</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><keycap>a</keycap></term>
+        <listitem><para>macOS</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><keycap>s</keycap></term>
+        <listitem><para>EFI shell</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><keycap>1</keycap></term>
+        <term><keycap>2</keycap></term>
+        <term><keycap>3</keycap></term>
+        <term><keycap>4</keycap></term>
+        <term><keycap>5</keycap></term>
+        <term><keycap>6</keycap></term>
+        <term><keycap>7</keycap></term>
+        <term><keycap>8</keycap></term>
+        <term><keycap>9</keycap></term>
+        <listitem><para>Boot entry number 1 … 9</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+    </variablelist>
+
+    <para>The boot menu is shown when a non-zero menu timeout has been configured. If the menu timeout has
+    been set to zero, it is sufficient to press any key — before the boot loader initializes — to bring up
+    the boot menu, except for the keys listed immediately above as they directly boot into the selected boot
+    menu item. Note that depending on the firmware implementation the time window where key presses are
+    accepted before the boot loader initializes might be short. If the window is missed, reboot and try
+    again, possibly pressing a suitable key (e.g. the space bar) continuously; on most systems it should be
+    possible to hit the time window after a few attempts. To avoid this problem, consider setting a non-zero
+    timeout, thus showing the boot menu unconditionally. Some desktop environments might offer an option to
+    directly boot into the boot menu, to avoid the problem altogether. Alternatively, use the command line
+    <command>systemctl reboot --boot-loader-menu=0</command> from the shell.</para>
+
+    <para>In the editor, most keys simply insert themselves, but the following keys
+    may be used to perform additional actions:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><keycap>←</keycap> (Left)</term>
+        <term><keycap>→</keycap> (Right)</term>
+        <term><keycap>Home</keycap></term>
+        <term><keycap>End</keycap></term>
+        <listitem><para>Navigate left/right</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><keycap>Esc</keycap></term>
+        <term><keycombo><keycap>Ctrl</keycap><keycap>c</keycap></keycombo></term>
+        <listitem><para>Abort the edit and quit the editor</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><keycombo><keycap>Ctrl</keycap><keycap>k</keycap></keycombo></term>
+        <listitem><para>Clear the command line forwards</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><keycombo><keycap>Ctrl</keycap><keycap>w</keycap></keycombo></term>
+        <term><keycombo><keycap>Alt</keycap><keycap>Backspace</keycap></keycombo></term>
+        <listitem><para>Delete word backwards</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><keycombo><keycap>Ctrl</keycap><keycap>Del</keycap></keycombo></term>
+        <term><keycombo><keycap>Alt</keycap><keycap>d</keycap></keycombo></term>
+        <listitem><para>Delete word forwards</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><keycap>↵</keycap> (Enter)</term>
+        <listitem><para>Boot entry with the edited command line</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+    </variablelist>
+
+    <para>Note that unless configured otherwise in the UEFI firmware, systemd-boot will
+    use the US keyboard layout, so key labels might not match for keys like +/-.
+    </para>
+  </refsect1>
+
+  <refsect1>
+    <title>Files</title>
+
+    <para>The files <command>systemd-boot</command> processes generally reside on the UEFI ESP which is
+    usually mounted to <filename>/efi/</filename>, <filename>/boot/</filename> or
+    <filename>/boot/efi/</filename> during OS runtime. It also processes files on the Extended Boot Loader
+    partition which is typically mounted to <filename>/boot/</filename>, if it
+    exists.</para>
+
+    <para><command>systemd-boot</command> reads runtime configuration such as the boot timeout and default
+    entry from <filename>/loader/loader.conf</filename> on the ESP (in combination with data read from EFI
+    variables). See
+    <citerefentry><refentrytitle>loader.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+
+    <para>Boot entry description files following the <ulink
+    url="https://uapi-group.org/specifications/specs/boot_loader_specification">Boot Loader Specification</ulink> are read from
+    <filename>/loader/entries/</filename> on the ESP and the Extended Boot Loader partition.</para>
+
+    <para>Unified kernel boot entries following the <ulink
+    url="https://uapi-group.org/specifications/specs/boot_loader_specification">Boot Loader Specification</ulink> are read from
+    <filename>/EFI/Linux/</filename> on the ESP and the Extended Boot Loader partition.</para>
+
+    <para>Optionally, a random seed for early boot entropy pool provisioning is stored in
+    <filename>/loader/random-seed</filename> in the ESP.</para>
+
+    <para>During initialization, <command>sd-boot</command> automatically loads all driver files placed in
+    the <filename>/EFI/systemd/drivers/</filename> directory of the ESP. The files placed there must have an
+    extension of the EFI architecture ID followed by <filename>.efi</filename> (e.g. for x86-64 this means a
+    suffix of <filename>x64.efi</filename>). This may be used to automatically load file system drivers and
+    similar, to extend the native firmware support.</para>
+
+    <para>Enrollment of Secure Boot variables can be performed manually or automatically if files are available
+    under <filename>/loader/keys/<replaceable>NAME</replaceable>/{db,KEK,PK}.auth</filename>, <replaceable>NAME</replaceable>
+    being the display name for the set of variables in the menu. If one of the sets is named <filename>auto</filename>
+    then it might be enrolled automatically depending on whether <literal>secure-boot-enroll</literal> is set
+    to force or not.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>EFI Variables</title>
+
+    <para>The following EFI variables are defined, set and read by <command>systemd-boot</command>, under the
+    vendor UUID <literal>4a67b082-0a4c-41cf-b6c7-440b29bb8c4f</literal>, for communication between the boot
+    loader and the OS:</para>
+
+    <variablelist class='efi-variables'>
+      <varlistentry>
+        <term><varname>LoaderBootCountPath</varname></term>
+        <listitem><para>If boot counting is enabled, contains the path to the file in whose name the boot counters are
+        encoded. Set by the boot
+        loader. <citerefentry><refentrytitle>systemd-bless-boot.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        uses this information to mark a boot as successful as determined by the successful activation of the
+        <filename>boot-complete.target</filename> target unit.</para>
+
+        <xi:include href="version-info.xml" xpointer="v240"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>LoaderConfigTimeout</varname></term>
+        <term><varname>LoaderConfigTimeoutOneShot</varname></term>
+        <listitem><para>The menu timeout in seconds. Read by the boot loader. <varname>LoaderConfigTimeout</varname>
+        is maintained persistently, while <varname>LoaderConfigTimeoutOneShot</varname> is a one-time override which is
+        read once (in which case it takes precedence over <varname>LoaderConfigTimeout</varname>) and then
+        removed. <varname>LoaderConfigTimeout</varname> may be manipulated with the
+        <keycap>t</keycap>/<keycap>T</keycap> keys, see above.</para>
+
+        <xi:include href="version-info.xml" xpointer="v240"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>LoaderConfigConsoleMode</varname></term>
+        <listitem><para>The numerical menu console mode. Read by the boot loader. <varname>LoaderConfigConsoleMode</varname>
+        is maintained persistently. <varname>LoaderConfigConsoleMode</varname> may be manipulated with the
+        <keycap>r</keycap>/<keycap>R</keycap> keys, see above.</para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>LoaderDevicePartUUID</varname></term>
+
+        <listitem><para>Contains the partition UUID of the EFI System Partition the boot loader was run from. Set by
+        the boot
+        loader. <citerefentry><refentrytitle>systemd-gpt-auto-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        uses this information to automatically find the disk booted from, in order to discover various other partitions
+        on the same disk automatically.</para>
+
+        <xi:include href="version-info.xml" xpointer="v240"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>LoaderEntries</varname></term>
+
+        <listitem><para>A list of the identifiers of all discovered boot loader entries. Set by the boot
+        loader.</para>
+
+        <xi:include href="version-info.xml" xpointer="v240"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>LoaderEntryDefault</varname></term>
+        <term><varname>LoaderEntryOneShot</varname></term>
+
+        <listitem><para>The identifier of the default boot loader entry. Set primarily by the OS and read by the boot
+        loader. <varname>LoaderEntryOneShot</varname> sets the default entry for the next boot only, while
+        <varname>LoaderEntryDefault</varname> sets it persistently for all future
+        boots. <citerefentry><refentrytitle>bootctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s
+        <option>set-default</option> and <option>set-oneshot</option> commands make use of these variables. The boot
+        loader modifies <varname>LoaderEntryDefault</varname> on request, when the <keycap>d</keycap> key is used, see
+        above.</para>
+
+        <xi:include href="version-info.xml" xpointer="v240"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>LoaderEntryLastBooted</varname></term>
+
+        <listitem><para>The identifier of the boot loader entry last attempted. Set and read by the boot loader,
+        only when <filename>/loader/loader.conf</filename> has default set to <literal>@saved</literal>. See
+        <citerefentry><refentrytitle>loader.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+
+        <para> The boot loader will ensure <varname>LoaderEntryLastBooted</varname> is up-to date for every boot,
+        updating it as needed and will omit changing it all together when <varname>LoaderEntryOneShot</varname>
+        is set.</para>
+
+        <para>The boot loader reads the variable, which takes higher priority than
+        <varname>LoaderEntryDefault</varname>. The variable is ignored when <varname>LoaderEntryOneShot</varname>
+        is set.</para>
+
+        <para><varname>LoaderEntryLastBooted</varname> cannot be used as indication that the last boot was
+        successful or not.</para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>LoaderEntrySelected</varname></term>
+
+        <listitem><para>The identifier of the boot loader entry currently being booted. Set by the boot
+        loader.</para>
+
+        <xi:include href="version-info.xml" xpointer="v240"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>LoaderFeatures</varname></term>
+
+        <listitem><para>A set of flags indicating the features the boot loader supports. Set by the boot loader. Use
+        <citerefentry><refentrytitle>bootctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> to view this
+        data.</para>
+
+        <xi:include href="version-info.xml" xpointer="v240"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>LoaderFirmwareInfo</varname></term>
+        <term><varname>LoaderFirmwareType</varname></term>
+
+        <listitem><para>Brief firmware information. Set by the boot loader. Use
+        <citerefentry><refentrytitle>bootctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> to view this
+        data.</para>
+
+        <xi:include href="version-info.xml" xpointer="v240"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>LoaderImageIdentifier</varname></term>
+
+        <listitem><para>The path of executable of the boot loader used for the current boot, relative to the EFI System
+        Partition's root directory. Set by the boot loader. Use
+        <citerefentry><refentrytitle>bootctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> to view this
+        data.</para>
+
+        <xi:include href="version-info.xml" xpointer="v240"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>LoaderInfo</varname></term>
+
+        <listitem><para>Brief information about the boot loader. Set by the boot loader. Use
+        <citerefentry><refentrytitle>bootctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> to view this
+        data.</para>
+
+        <xi:include href="version-info.xml" xpointer="v240"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>LoaderTimeExecUSec</varname></term>
+        <term><varname>LoaderTimeInitUSec</varname></term>
+        <term><varname>LoaderTimeMenuUsec</varname></term>
+
+        <listitem><para>Information about the time spent in various parts of the boot loader. Set by the boot
+        loader. Use <citerefentry><refentrytitle>systemd-analyze</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+        to view this data. </para>
+
+        <xi:include href="version-info.xml" xpointer="v240"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>LoaderSystemToken</varname></term>
+
+        <listitem><para>A binary random data field, that is used for generating the random seed to pass to
+        the OS (see above). Note that this random data is generally only generated once, during OS
+        installation, and is then never updated again.</para>
+
+        <xi:include href="version-info.xml" xpointer="v243"/></listitem>
+      </varlistentry>
+    </variablelist>
+
+    <para>Many of these variables are defined by the <ulink
+    url="https://systemd.io/BOOT_LOADER_INTERFACE">Boot Loader Interface</ulink>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Boot Counting</title>
+
+    <para><command>systemd-boot</command> implements a simple boot counting mechanism on top of the <ulink
+    url="https://uapi-group.org/specifications/specs/boot_loader_specification">Boot Loader Specification</ulink>, for automatic and unattended
+    fallback to older kernel versions/boot loader entries when a specific entry continuously fails. Any boot loader
+    entry file and unified kernel image file that contains a <literal>+</literal> followed by one or two numbers (if
+    two they need to be separated by a <literal>-</literal>), before the <filename>.conf</filename> or
+    <filename>.efi</filename> suffix is subject to boot counting: the first of the two numbers ('tries left') is
+    decreased by one on every boot attempt, the second of the two numbers ('tries done') is increased by one (if 'tries
+    done' is absent it is considered equivalent to 0). Depending on the current value of these two counters the boot
+    entry is considered to be in one of three states:</para>
+
+    <orderedlist>
+      <listitem><para>If the 'tries left' counter of an entry is greater than zero the entry is considered to be in
+      'indeterminate' state. This means the entry has not completed booting successfully yet, but also hasn't been
+      determined not to work.</para></listitem>
+
+      <listitem><para>If the 'tries left' counter of an entry is zero it is considered to be in 'bad' state. This means
+      no further attempts to boot this item will be made (that is, unless all other boot entries are also in 'bad'
+      state), as all attempts to boot this entry have not completed successfully.</para></listitem>
+
+      <listitem><para>If the 'tries left' and 'tries done' counters of an entry are absent it is considered to be in
+      'good' state. This means further boot counting for the entry is turned off, as it successfully booted at least
+      once. The
+      <citerefentry><refentrytitle>systemd-bless-boot.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+      service moves the currently booted entry from 'indeterminate' into 'good' state when a boot attempt completed
+      successfully.</para></listitem>
+    </orderedlist>
+
+    <para>Generally, when new entries are added to the boot loader, they first start out in 'indeterminate' state,
+    i.e. with a 'tries left' counter greater than zero. The boot entry remains in this state until either it managed to
+    complete a full boot successfully at least once (in which case it will be in 'good' state) — or the 'tries left'
+    counter reaches zero (in which case it will be in 'bad' state).</para>
+
+    <para>Example: let's say a boot loader entry file <filename>foo.conf</filename> is set up for 3 boot tries. The
+    installer will hence create it under the name <filename>foo+3.conf</filename>. On first boot, the boot loader will
+    rename it to <filename>foo+2-1.conf</filename>. If that boot does not complete successfully, the boot loader will
+    rename it to <filename>foo+1-2.conf</filename> on the following boot. If that fails too, it will finally be renamed
+    <filename>foo+0-3.conf</filename> by the boot loader on next boot, after which it will be considered 'bad'. If the
+    boot succeeds however the entry file will be renamed to <filename>foo.conf</filename> by the OS, so that it is
+    considered 'good' from then on.</para>
+
+    <para>The boot menu takes the 'tries left' counter into account when sorting the menu entries: entries in 'bad'
+    state are ordered at the beginning of the list, and entries in 'good' or 'indeterminate' at the end. The user can
+    freely choose to boot any entry of the menu, including those already marked 'bad'. If the menu entry to boot is
+    automatically determined, this means that 'good' or 'indeterminate' entries are generally preferred (as the bottom
+    item of the menu is the one booted by default), and 'bad' entries will only be considered if there are no 'good' or
+    'indeterminate' entries left.</para>
+
+    <para>The <citerefentry><refentrytitle>kernel-install</refentrytitle><manvolnum>8</manvolnum></citerefentry> kernel
+    install framework optionally sets the initial 'tries left' counter to the value specified in
+    <filename>/etc/kernel/tries</filename> when a boot loader entry is first created.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Using <command>systemd-boot</command> in virtual machines</title>
+
+    <para>When using qemu with OVMF (UEFI Firmware for virtual machines) the <option>-kernel</option> switch
+    works not only for linux kernels, but for any EFI binary, including sd-boot and unified linux
+    kernels. Example command line for loading <command>systemd-boot</command> on x64:</para>
+
+    <para>
+      <command>qemu-system-x86_64 <replaceable>[ ... ]</replaceable>
+      -kernel /usr/lib/systemd/boot/efi/systemd-bootx64.efi</command>
+    </para>
+
+    <para>systemd-boot will detect that it was started directly instead of being loaded from ESP and will
+    search for the ESP in that case, taking into account boot order information from the hypervisor (if
+    available).</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>bootctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>loader.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-bless-boot.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-boot-random-seed.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>kernel-install</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-stub</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <ulink url="https://uapi-group.org/specifications/specs/boot_loader_specification">Boot Loader Specification</ulink>,
+      <ulink url="https://systemd.io/BOOT_LOADER_INTERFACE">Boot Loader Interface</ulink>,
+      <ulink url="https://systemd.io/TPM2_PCR_MEASUREMENTS">TPM2 PCR Measurements Made by systemd</ulink>
+    </para>
+  </refsect1>
+</refentry>
diff --git a/man/systemd-bsod.service.xml b/man/systemd-bsod.service.xml
new file mode 100644
index 0000000..9f54b40
--- /dev/null
+++ b/man/systemd-bsod.service.xml
@@ -0,0 +1,75 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd-bsod.service" conditional='HAVE_QRENCODE' xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd-bsod</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-bsod.service</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-bsod.service</refname>
+    <refname>systemd-bsod</refname>
+    <refpurpose>Displays boot-time emergency log message in full screen.</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>systemd-bsod.service</filename></para>
+    <cmdsynopsis>
+      <command>systemd-bsod</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+    </cmdsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><filename>systemd-bsod.service</filename> is used to display a blue screen which contains a message
+    relating to a boot failure, including a QR code which can be scanned to get helpful information about the
+    failure.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>The following options are understood by <command>systemd-bsod</command>:</para>
+
+    <variablelist>
+      <xi:include href="standard-options.xml" xpointer="help" />
+      <xi:include href="standard-options.xml" xpointer="version" />
+
+      <varlistentry>
+        <term><option>-c</option></term>
+        <term><option>--continuous</option></term>
+
+        <listitem><para>When specified, <command>systemd-bsod</command> waits continuously for changes in the
+        journal if it doesn't find any emergency messages on the initial attempt.</para>
+
+         <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+    </variablelist>
+
+  </refsect1>
+
+  <refsect1>
+    <title>Exit status</title>
+
+    <para>On success (displaying the journal message successfully), 0 is returned, a non-zero failure code otherwise.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-cat.xml b/man/systemd-cat.xml
new file mode 100644
index 0000000..8d59ce2
--- /dev/null
+++ b/man/systemd-cat.xml
@@ -0,0 +1,173 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd-cat"
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd-cat</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-cat</refentrytitle>
+    <manvolnum>1</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-cat</refname>
+    <refpurpose>Connect a pipeline or program's output with the journal</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <cmdsynopsis>
+      <command>systemd-cat <arg choice="opt" rep="repeat">OPTIONS</arg> <arg>COMMAND</arg> <arg choice="opt" rep="repeat">ARGUMENTS</arg></command>
+    </cmdsynopsis>
+    <cmdsynopsis>
+      <command>systemd-cat <arg choice="opt" rep="repeat">OPTIONS</arg></command>
+    </cmdsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>systemd-cat</command> may be used to connect the
+    standard input and output of a process to the journal, or as a
+    filter tool in a shell pipeline to pass the output the previous
+    pipeline element generates to the journal.</para>
+
+    <para>If no parameter is passed, <command>systemd-cat</command>
+    will write everything it reads from standard input (stdin) to the
+    journal.</para>
+
+    <para>If parameters are passed, they are executed as command line
+    with standard output (stdout) and standard error output (stderr)
+    connected to the journal, so that all it writes is stored in the
+    journal.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>The following options are understood:</para>
+
+    <variablelist>
+      <xi:include href="standard-options.xml" xpointer="help" />
+      <xi:include href="standard-options.xml" xpointer="version" />
+
+      <varlistentry>
+        <term><option>-t</option></term>
+        <term><option>--identifier=</option></term>
+
+        <listitem><para>Specify a short string that is used to
+        identify the logging tool. If not specified, no identification
+        string is written to the journal.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-p</option></term>
+        <term><option>--priority=</option></term>
+
+        <listitem><para>Specify the default priority level for the
+        logged messages. Pass one of
+        <literal>emerg</literal>,
+        <literal>alert</literal>,
+        <literal>crit</literal>,
+        <literal>err</literal>,
+        <literal>warning</literal>,
+        <literal>notice</literal>,
+        <literal>info</literal>,
+        <literal>debug</literal>, or a
+        value between 0 and 7 (corresponding to the same named
+        levels). These priority values are the same as defined by
+        <citerefentry project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+        Defaults to <literal>info</literal>. Note that this simply
+        controls the default, individual lines may be logged with
+        different levels if they are prefixed accordingly. For details,
+        see <option>--level-prefix=</option> below.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--stderr-priority=</option></term>
+
+        <listitem><para>Specifies the default priority level for
+        messages from the process's standard error output (stderr).
+        Usage of this option is the same as the
+        <option>--priority=</option> option, above, and both can be
+        used at once. When both are used, <option>--priority=</option>
+        will specify the default priority for standard output (stdout).
+        </para>
+
+        <para>If <option>--stderr-priority=</option> is not specified,
+        messages from stderr will still be logged, with the same
+        default priority level as stdout.</para>
+
+        <para>Also, note that when stdout and stderr use the same
+        default priority, the messages will be strictly ordered,
+        because one channel is used for both. When the default priority
+        differs, two channels are used, and so stdout messages will not
+        be strictly ordered with respect to stderr messages - though
+        they will tend to be approximately ordered.</para>
+
+        <xi:include href="version-info.xml" xpointer="v241"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--level-prefix=</option></term>
+
+        <listitem><para>Controls whether lines read are parsed for syslog priority level prefixes. If enabled
+        (the default), a line prefixed with a priority prefix such as <literal>&lt;5&gt;</literal> is logged
+        at priority 5 (<literal>notice</literal>), and similarly for the other priority levels. Takes a
+        boolean argument.</para></listitem>
+      </varlistentry>
+
+    </variablelist>
+
+  </refsect1>
+
+  <refsect1>
+    <title>Exit status</title>
+
+    <para>On success, 0 is returned, a non-zero failure code
+    otherwise.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Examples</title>
+
+    <example>
+      <title>Invoke a program</title>
+
+      <para>This calls <filename index="false">/bin/ls</filename>
+      with standard output and error connected to the journal:</para>
+
+      <programlisting># systemd-cat ls</programlisting>
+    </example>
+
+    <example>
+      <title>Usage in a shell pipeline</title>
+
+      <para>This builds a shell pipeline also invoking
+      <filename>/bin/ls</filename> and writes the output it generates
+      to the journal:</para>
+
+      <programlisting># ls | systemd-cat</programlisting>
+    </example>
+
+    <para>Even though the two examples have very similar effects, the first is preferable, since only one
+    process is running at a time and both stdout and stderr are captured, while in the second example, only
+    stdout is captured.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>logger</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-cgls.xml b/man/systemd-cgls.xml
new file mode 100644
index 0000000..27332c5
--- /dev/null
+++ b/man/systemd-cgls.xml
@@ -0,0 +1,162 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd-cgls"
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd-cgls</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-cgls</refentrytitle>
+    <manvolnum>1</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-cgls</refname>
+    <refpurpose>Recursively show control group contents</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <cmdsynopsis>
+      <command>systemd-cgls</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="opt" rep="repeat">CGROUP</arg>
+    </cmdsynopsis>
+    <cmdsynopsis>
+      <command>systemd-cgls</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="plain"><option>--unit</option>|<option>--user-unit</option></arg>
+      <arg choice="opt" rep="repeat">UNIT</arg>
+    </cmdsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>systemd-cgls</command> recursively shows the
+    contents of the selected Linux control group hierarchy in a tree.
+    If arguments are specified, shows all member processes of the
+    specified control groups plus all their subgroups and their
+    members. The control groups may either be specified by their full
+    file paths or are assumed in the systemd control group hierarchy.
+    If no argument is specified and the current working directory is
+    beneath the control group mount point
+    <filename>/sys/fs/cgroup/</filename>, shows the contents of the
+    control group the working directory refers to. Otherwise, the full
+    systemd control group hierarchy is shown.</para>
+
+    <para>By default, empty control groups are not shown.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>The following options are understood:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><option>--all</option></term>
+
+        <listitem><para>Do not hide empty control groups in the
+        output.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-l</option></term>
+        <term><option>--full</option></term>
+
+        <listitem><para>Do not ellipsize process tree members.</para>
+
+        <xi:include href="version-info.xml" xpointer="v198"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-u</option></term>
+        <term><option>--unit</option></term>
+
+        <listitem><para>Show cgroup subtrees for the specified units.</para>
+
+        <xi:include href="version-info.xml" xpointer="v233"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--user-unit</option></term>
+
+        <listitem><para>Show cgroup subtrees for the specified user units.</para>
+
+        <xi:include href="version-info.xml" xpointer="v233"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-k</option></term>
+
+        <listitem><para>Include kernel threads in output.
+        </para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-M <replaceable>MACHINE</replaceable></option></term>
+        <term><option>--machine=<replaceable>MACHINE</replaceable></option></term>
+
+        <listitem><para>Limit control groups shown to the part
+        corresponding to the container
+        <replaceable>MACHINE</replaceable>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v203"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-x</option></term>
+        <term><option>--xattr=</option></term>
+
+        <listitem><para>Controls whether to include information about extended attributes of the listed
+        control groups in the output. With the long option, expects a boolean value. Defaults to no.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-c</option></term>
+        <term><option>--cgroup-id=</option></term>
+
+        <listitem><para>Controls whether to include the numeric ID of the listed control groups in the
+        output. With the long option, expects a boolean value. Defaults to no.</para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+
+      <xi:include href="standard-options.xml" xpointer="help" />
+      <xi:include href="standard-options.xml" xpointer="version" />
+      <xi:include href="standard-options.xml" xpointer="no-pager" />
+    </variablelist>
+
+  </refsect1>
+
+  <refsect1>
+    <title>Exit status</title>
+
+    <para>On success, 0 is returned, a non-zero failure code
+    otherwise.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-cgtop</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>ps</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-cgtop.xml b/man/systemd-cgtop.xml
new file mode 100644
index 0000000..ddad82e
--- /dev/null
+++ b/man/systemd-cgtop.xml
@@ -0,0 +1,377 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd-cgtop"
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd-cgtop</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-cgtop</refentrytitle>
+    <manvolnum>1</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-cgtop</refname>
+    <refpurpose>Show top control groups by their resource usage</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <cmdsynopsis>
+      <command>systemd-cgtop</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="opt">GROUP</arg>
+    </cmdsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>systemd-cgtop</command> shows the top control
+    groups of the local Linux control group hierarchy, ordered by
+    their CPU, memory, or disk I/O load. The display is refreshed in
+    regular intervals (by default every 1s), similar in style to
+    <citerefentry project='man-pages'><refentrytitle>top</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
+    If a control group path is specified, shows only the services of
+    the specified control group.</para>
+
+    <para>If <command>systemd-cgtop</command> is not connected to a
+    tty, no column headers are printed and the default is to only run
+    one iteration. The <option>--iterations=</option> argument, if
+    given, is honored. This mode is suitable for scripting.</para>
+
+    <para>Resource usage is only accounted for control groups with the appropriate controllers turned on:
+    <literal>cpu</literal> controller for CPU usage, <literal>memory</literal> controller for memory usage,
+    and <literal>io</literal> controller for disk I/O consumption. If resource monitoring for these resources
+    is required, it is recommended to add the <varname>CPUAccounting=1</varname>,
+    <varname>MemoryAccounting=1</varname> and <varname>IOAccounting=1</varname> settings in the unit files in
+    question. See
+    <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for details.</para>
+
+    <para>The CPU load value can be between 0 and 100 times the number of
+    processors the system has. For example, if the system has 8 processors,
+    the CPU load value is going to be between 0% and 800%. The number of
+    processors can be found in <literal>/proc/cpuinfo</literal>.</para>
+
+    <para>To emphasize: unless <literal>CPUAccounting=1</literal>, <literal>MemoryAccounting=1</literal>, and
+    <literal>IOAccounting=1</literal> are enabled for the services in question, no resource accounting will
+    be available for system services and the data shown by <command>systemd-cgtop</command> will be
+    incomplete.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>The following options are understood:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><option>-p</option></term>
+        <term><option>--order=path</option></term>
+
+        <listitem><para>Order by control group
+        path name.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-t</option></term>
+        <term><option>--order=tasks</option></term>
+
+        <listitem><para>Order by number of tasks/processes in the control group.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-c</option></term>
+        <term><option>--order=cpu</option></term>
+
+        <listitem><para>Order by CPU load.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-m</option></term>
+        <term><option>--order=memory</option></term>
+
+        <listitem><para>Order by memory usage.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-i</option></term>
+        <term><option>--order=io</option></term>
+
+        <listitem><para>Order by disk I/O load.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-b</option></term>
+        <term><option>--batch</option></term>
+
+        <listitem><para>Run in "batch" mode: do not accept input and
+        run until the iteration limit set with
+        <option>--iterations=</option> is exhausted or until killed.
+        This mode could be useful for sending output from
+        <command>systemd-cgtop</command> to other programs or to a
+        file.</para>
+
+        <xi:include href="version-info.xml" xpointer="v188"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-r</option></term>
+        <term><option>--raw</option></term>
+
+        <listitem><para>Format byte counts (as in memory usage and I/O metrics) and CPU time
+        with raw numeric values rather than human-readable
+        numbers.</para>
+
+        <xi:include href="version-info.xml" xpointer="v221"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--cpu=percentage</option></term>
+        <term><option>--cpu=time</option></term>
+
+        <listitem><para>Controls whether the CPU usage is shown as
+        percentage or time. By default, the CPU usage is shown as
+        percentage. This setting may also be toggled at runtime by
+        pressing the <keycap>%</keycap> key.</para>
+
+        <xi:include href="version-info.xml" xpointer="v226"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-P</option></term>
+
+        <listitem><para>Count only userspace processes instead of all
+        tasks. By default, all tasks are counted: each kernel thread
+        and each userspace thread individually. With this setting,
+        kernel threads are excluded from the count and each userspace
+        process only counts as one task, regardless of how many
+        threads it consists of. This setting may also be toggled at
+        runtime by pressing the <keycap>P</keycap> key. This option
+        may not be combined with
+        <option>-k</option>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v227"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-k</option></term>
+
+        <listitem><para>Count only userspace processes and kernel
+        threads instead of all tasks. By default, all tasks are
+        counted: each kernel thread and each userspace thread
+        individually. With this setting, kernel threads are included in
+        the count and each userspace process only counts as one task,
+        regardless of how many threads it consists of. This setting may
+        also be toggled at runtime by pressing the <keycap>k</keycap>
+        key. This option may not be combined with
+        <option>-P</option>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v226"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--recursive=</option></term>
+
+        <listitem><para>Controls whether the number of processes shown
+        for a control group shall include all processes that are
+        contained in any of the child control groups as well. Takes a
+        boolean argument, which defaults to <literal>yes</literal>. If
+        enabled, the processes in child control groups are included, if
+        disabled, only the processes in the control group itself are
+        counted. This setting may also be toggled at runtime by
+        pressing the <keycap>r</keycap> key. Note that this setting
+        only applies to process counting, i.e. when the
+        <option>-P</option> or <option>-k</option> options are
+        used. It has not effect if all tasks are counted, in which
+        case the counting is always recursive.</para>
+
+        <xi:include href="version-info.xml" xpointer="v226"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-n</option></term>
+        <term><option>--iterations=</option></term>
+
+        <listitem><para>Perform only this many iterations. A value of
+        0 indicates that the program should run
+        indefinitely.</para>
+
+        <xi:include href="version-info.xml" xpointer="v188"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-1</option></term>
+
+        <listitem><para>A shortcut for <option>--iterations=1</option>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v238"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-d</option></term>
+        <term><option>--delay=</option></term>
+
+        <listitem><para>Specify refresh delay in seconds (or if one of
+        <literal>ms</literal>, <literal>us</literal>,
+        <literal>min</literal> is specified as unit in this time
+        unit). This setting may also be increased and decreased at
+        runtime by pressing the <keycap>+</keycap> and
+        <keycap>-</keycap> keys.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--depth=</option></term>
+
+        <listitem><para>Maximum control group tree traversal depth.
+        Specifies how deep <command>systemd-cgtop</command> shall
+        traverse the control group hierarchies. If 0 is specified,
+        only the root group is monitored. For 1, only the first level
+        of control groups is monitored, and so on. Defaults to
+        3.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-M <replaceable>MACHINE</replaceable></option></term>
+        <term><option>--machine=<replaceable>MACHINE</replaceable></option></term>
+
+        <listitem><para>Limit control groups shown to the part
+        corresponding to the container
+        <replaceable>MACHINE</replaceable>.
+        This option may not be used when a control group path is specified.</para>
+
+        <xi:include href="version-info.xml" xpointer="v227"/></listitem>
+      </varlistentry>
+
+      <xi:include href="standard-options.xml" xpointer="help" />
+      <xi:include href="standard-options.xml" xpointer="version" />
+    </variablelist>
+
+  </refsect1>
+
+  <refsect1>
+    <title>Keys</title>
+
+    <para><command>systemd-cgtop</command> is an interactive tool and
+    may be controlled via user input using the following keys:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><keycap>h</keycap></term>
+
+        <listitem><para>Shows a short help text.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><keycap function="space"/></term>
+
+        <listitem><para>Immediately refresh output.</para>
+
+        <xi:include href="version-info.xml" xpointer="v226"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><keycap>q</keycap></term>
+
+        <listitem><para>Terminate the program.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><keycap>p</keycap></term>
+        <term><keycap>t</keycap></term>
+        <term><keycap>c</keycap></term>
+        <term><keycap>m</keycap></term>
+        <term><keycap>i</keycap></term>
+
+        <listitem><para>Sort the control groups by path, number of
+        tasks, CPU load, memory usage, or I/O load, respectively.  This
+        setting may also be controlled using the
+        <option>--order=</option> command line
+        switch.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><keycap>%</keycap></term>
+
+        <listitem><para>Toggle between showing CPU time as time or
+        percentage. This setting may also be controlled using the
+        <option>--cpu=</option> command line switch.</para>
+
+        <xi:include href="version-info.xml" xpointer="v201"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><keycap>+</keycap></term>
+        <term><keycap>-</keycap></term>
+
+        <listitem><para>Increase or decrease refresh delay,
+        respectively. This setting may also be controlled using the
+        <option>--delay=</option> command line
+        switch.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><keycap>P</keycap></term>
+
+        <listitem><para>Toggle between counting all tasks, or only
+        userspace processes. This setting may also be controlled using
+        the <option>-P</option> command line switch (see
+        above).</para>
+
+        <xi:include href="version-info.xml" xpointer="v227"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><keycap>k</keycap></term>
+
+        <listitem><para>Toggle between counting all tasks, or only
+        userspace processes and kernel threads. This setting may also
+        be controlled using the <option>-k</option> command line
+        switch (see above).</para>
+
+        <xi:include href="version-info.xml" xpointer="v226"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><keycap>r</keycap></term>
+
+        <listitem><para>Toggle between recursively including or
+        excluding processes in child control groups in control group
+        process counts. This setting may also be controlled using the
+        <option>--recursive=</option> command line switch. This key is
+        not available if all tasks are counted, it is only available
+        if processes are counted, as enabled with the
+        <keycap>P</keycap> or <keycap>k</keycap>
+        keys.</para>
+
+        <xi:include href="version-info.xml" xpointer="v226"/></listitem>
+      </varlistentry>
+
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Exit status</title>
+
+    <para>On success, 0 is returned, a non-zero failure code
+    otherwise.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-cgls</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>top</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-coredump.xml b/man/systemd-coredump.xml
new file mode 100644
index 0000000..762873a
--- /dev/null
+++ b/man/systemd-coredump.xml
@@ -0,0 +1,498 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd-coredump" conditional='ENABLE_COREDUMP'
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd-coredump</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-coredump</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-coredump</refname>
+    <refname>systemd-coredump.socket</refname>
+    <refname>systemd-coredump@.service</refname>
+    <refpurpose>Acquire, save and process core dumps</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>/usr/lib/systemd/systemd-coredump</filename></para>
+    <para><filename>/usr/lib/systemd/systemd-coredump</filename> <option>--backtrace</option></para>
+    <para><filename>systemd-coredump@.service</filename></para>
+    <para><filename>systemd-coredump.socket</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+    <para><filename>systemd-coredump@.service</filename> is a system service to process core dumps. It will
+    log a summary of the event to
+    <citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+    including information about the process identifier, owner, the signal that killed the process, and the
+    stack trace if possible. It may also save the core dump for later processing. See the "Information about
+    the crashed process" section below.</para>
+
+    <para>The behavior of a specific program upon reception of a signal is governed by a few
+    factors which are described in detail in
+    <citerefentry project='man-pages'><refentrytitle>core</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+    In particular, the core dump will only be processed when the related resource limits are sufficient.
+    </para>
+
+    <para>Core dumps can be written to the journal or saved as a file. In both cases, they can be retrieved
+    for further processing, for example in
+    <citerefentry project='man-pages'><refentrytitle>gdb</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
+    See <citerefentry><refentrytitle>coredumpctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+    in particular the <command>list</command> and <command>debug</command> verbs.</para>
+
+    <para>By default, <command>systemd-coredump</command> will log the core dump to the journal, including a
+    backtrace if possible, and store the core dump (an image of the memory contents of the process) itself in
+    an external file in <filename>/var/lib/systemd/coredump</filename>. These core dumps are deleted after a
+    few days by default; see <filename>/usr/lib/tmpfiles.d/systemd.conf</filename> for details. Note that the
+    removal of core files from the file system and the purging of journal entries are independent, and the
+    core file may be present without the journal entry, and journal entries may point to since-removed core
+    files. Some metadata is attached to core files in the form of extended attributes, so the core files are
+    useful for some purposes even without the full metadata available in the journal entry.</para>
+
+    <para>For further details see <ulink url="https://systemd.io/COREDUMP">systemd Coredump
+    Handling</ulink>.</para>
+
+    <refsect2>
+      <title>Invocation of <command>systemd-coredump</command></title>
+
+      <para>The <command>systemd-coredump</command> executable does the actual work. It is invoked twice:
+      once as the handler by the kernel, and the second time in the
+      <filename>systemd-coredump@.service</filename> to actually write the data to the journal and process
+      and save the core file.</para>
+
+      <para>When the kernel invokes <command>systemd-coredump</command> to handle a core dump, it runs in
+      privileged mode, and will connect to the socket created by the
+      <filename>systemd-coredump.socket</filename> unit, which in turn will spawn an unprivileged
+      <filename>systemd-coredump@.service</filename> instance to process the core dump. Hence
+      <filename>systemd-coredump.socket</filename> and <filename>systemd-coredump@.service</filename> are
+      helper units which do the actual processing of core dumps and are subject to normal service
+      management.</para>
+
+      <para>It is also possible to invoke <command>systemd-coredump</command> with
+      <option>--backtrace</option> option. In this case, <command>systemd-coredump</command> expects a
+      journal entry in the journal
+      <ulink url="https://systemd.io/JOURNAL_EXPORT_FORMATS#journal-export-format">Journal Export Format</ulink>
+      on standard input. The entry should contain a <varname>MESSAGE=</varname> field and any additional
+      metadata fields the caller deems reasonable. <command>systemd-coredump</command> will append additional
+      metadata fields in the same way it does for core dumps received from the kernel. In this mode, no core
+      dump is stored in the journal.</para>
+    </refsect2>
+  </refsect1>
+
+  <refsect1>
+    <title>Configuration</title>
+    <para>For programs started by <command>systemd</command>, process resource limits can be set by directive
+    <varname>LimitCORE=</varname>, see
+    <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+    </para>
+
+    <para>In order to be used by the kernel to handle core dumps,
+    <command>systemd-coredump</command> must be configured in
+    <citerefentry project='man-pages'><refentrytitle>sysctl</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    parameter <varname>kernel.core_pattern</varname>. The syntax of this parameter is explained in
+    <citerefentry project='man-pages'><refentrytitle>core</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+    systemd installs the file <filename>/usr/lib/sysctl.d/50-coredump.conf</filename> which configures
+    <varname>kernel.core_pattern</varname> accordingly. This file may be masked or overridden to use a different
+    setting following normal
+    <citerefentry><refentrytitle>sysctl.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    rules. If the sysctl configuration is modified, it must be updated in the kernel before it
+    takes effect, see
+    <citerefentry project='man-pages'><refentrytitle>sysctl</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    and
+    <citerefentry><refentrytitle>systemd-sysctl</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+    </para>
+
+    <para>In order to be used in the <option>--backtrace</option> mode, an appropriate backtrace
+    handler must be installed on the sender side. For example, in case of
+    <citerefentry project='die-net'><refentrytitle>python</refentrytitle><manvolnum>1</manvolnum></citerefentry>, this
+    means a <varname>sys.excepthook</varname> must be installed, see
+    <ulink url="https://github.com/systemd/systemd-coredump-python">systemd-coredump-python</ulink>.
+    </para>
+
+    <para>The behavior of <command>systemd-coredump</command> itself is configured through the configuration file
+    <filename>/etc/systemd/coredump.conf</filename> and corresponding snippets
+    <filename>/etc/systemd/coredump.conf.d/*.conf</filename>, see
+    <citerefentry><refentrytitle>coredump.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>. A new
+    instance of <command>systemd-coredump</command> is invoked upon receiving every core dump. Therefore, changes
+    in these files will take effect the next time a core dump is received.</para>
+
+    <para>Resources used by core dump files are restricted in two ways. Parameters like maximum size of acquired
+    core dumps and files can be set in files <filename>/etc/systemd/coredump.conf</filename> and snippets mentioned
+    above. In addition the storage time of core dump files is restricted by <command>systemd-tmpfiles</command>,
+    corresponding settings are by default in <filename>/usr/lib/tmpfiles.d/systemd.conf</filename>. The default is
+    to delete core dumps after a few days; see the above file for details.</para>
+
+    <refsect2>
+      <title>Disabling coredump processing</title>
+
+      <para>To disable potentially resource-intensive processing by <command>systemd-coredump</command>, set
+      <programlisting>Storage=none
+ProcessSizeMax=0</programlisting> in
+      <citerefentry><refentrytitle>coredump.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+      </para>
+    </refsect2>
+  </refsect1>
+
+  <refsect1>
+    <title>Information about the crashed process</title>
+
+    <para><citerefentry><refentrytitle>coredumpctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> can
+    be used to retrieve saved core dumps independently of their location, to display information, and to
+    process them e.g. by passing to the GNU debugger (gdb).</para>
+
+    <para>Data stored in the journal can be also viewed with
+    <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> as usual
+    (or from any other process, using the
+    <citerefentry><refentrytitle>sd-journal</refentrytitle><manvolnum>3</manvolnum></citerefentry> API).
+    The relevant messages have <constant>MESSAGE_ID=fc2e22bc6ee647b6b90729ab34a250b1</constant>:</para>
+    <programlisting>$ journalctl MESSAGE_ID=fc2e22bc6ee647b6b90729ab34a250b1 -o verbose
+…
+MESSAGE_ID=fc2e22bc6ee647b6b90729ab34a250b1
+COREDUMP_PID=552351
+COREDUMP_UID=1000
+COREDUMP_GID=1000
+COREDUMP_SIGNAL_NAME=SIGSEGV
+COREDUMP_SIGNAL=11
+COREDUMP_TIMESTAMP=1614342930000000
+COREDUMP_COMM=Web Content
+COREDUMP_EXE=/usr/lib64/firefox/firefox
+COREDUMP_USER_UNIT=app-gnome-firefox-552136.scope
+COREDUMP_CMDLINE=/usr/lib64/firefox/firefox -contentproc -childID 5 -isForBrowser …
+COREDUMP_CGROUP=/user.slice/user-1000.slice/user@1000.service/app.slice/app-….scope
+COREDUMP_FILENAME=/var/lib/systemd/coredump/core.Web….552351.….zst
+…
+    </programlisting>
+
+    <para>The following fields are saved (if known) with the journal entry</para>
+
+    <variablelist class='journal-directives'>
+      <varlistentry>
+        <term><varname>COREDUMP_UID=</varname></term>
+        <term><varname>COREDUMP_PID=</varname></term>
+        <term><varname>COREDUMP_GID=</varname></term>
+        <listitem><para>The process number (PID), owner user number (UID), and group number (GID) of the
+        crashed process.</para>
+
+        <para>When the crashed process was part of a container (or in a process or user namespace in
+        general), those are the values as seen <emphasis>outside</emphasis>, in the namespace where
+        <filename>systemd-coredump</filename> is running.</para>
+
+        <xi:include href="version-info.xml" xpointer="v248"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>COREDUMP_TIMESTAMP=</varname></term>
+        <listitem><para>The time of the crash as reported by the kernel (in μs since the epoch).</para>
+
+        <xi:include href="version-info.xml" xpointer="v248"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>COREDUMP_RLIMIT=</varname></term>
+        <listitem><para>The core file size soft resource limit, see
+        <citerefentry project='man-pages'><refentrytitle>getrlimit</refentrytitle><manvolnum>2</manvolnum></citerefentry>.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v248"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>COREDUMP_UNIT=</varname></term>
+        <term><varname>COREDUMP_SLICE=</varname></term>
+        <listitem><para>The system unit and slice names.</para>
+
+        <para>When the crashed process was in container, those are the units names
+        <emphasis>outside</emphasis>, in the main system manager.</para>
+
+        <xi:include href="version-info.xml" xpointer="v248"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>COREDUMP_CGROUP=</varname></term>
+
+        <listitem><para>The primary cgroup of the unit of the crashed process.</para>
+
+        <para>When the crashed process was in a container, this is the full path, as seen outside of the
+        container.</para>
+
+        <xi:include href="version-info.xml" xpointer="v248"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>COREDUMP_PROC_CGROUP=</varname></term>
+        <listitem><para>Control group information in the format used in
+        <filename>/proc/self/cgroup</filename>. On systems with the unified cgroup hierarchy, this is a
+        single path prefixed with <literal>0::</literal>, and multiple paths prefixed with controller numbers
+        on legacy systems.</para>
+
+        <para>When the crashed process was in a container, this is the full path, as seen outside of the
+        container.</para>
+
+        <xi:include href="version-info.xml" xpointer="v248"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>COREDUMP_OWNER_UID=</varname></term>
+        <term><varname>COREDUMP_USER_UNIT=</varname></term>
+        <term><varname>COREDUMP_SESSION=</varname></term>
+        <listitem><para>The numerical UID of the user owning the login session or systemd user unit of the
+        crashed process, the user manager unit, and the session identifier. All three fields are only present
+        for user processes.</para>
+
+        <para>When the crashed process was in container, those are the values <emphasis>outside</emphasis>,
+        in the main system.</para>
+
+        <xi:include href="version-info.xml" xpointer="v248"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>COREDUMP_SIGNAL_NAME=</varname></term>
+        <term><varname>COREDUMP_SIGNAL=</varname></term>
+
+        <listitem><para>The terminating signal name (with the <literal>SIG</literal> prefix
+        <footnote><para><citerefentry
+        project='man-pages'><refentrytitle>kill</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+        expects signal names <emphasis>without</emphasis> the prefix; <citerefentry
+        project='man-pages'><refentrytitle>kill</refentrytitle><manvolnum>2</manvolnum></citerefentry> uses
+        the prefix; all systemd tools accept signal names both with and without the prefix.
+        </para></footnote>) and numerical value. (Both are included because signal numbers vary by
+        architecture.)</para>
+
+        <xi:include href="version-info.xml" xpointer="v248"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>COREDUMP_CWD=</varname></term>
+        <term><varname>COREDUMP_ROOT=</varname></term>
+
+        <listitem><para>The current working directory and root directory of the crashed process.</para>
+
+        <para>When the crashed process is in a container, those paths are relative to the root of the
+        container's mount namespace.</para>
+
+        <xi:include href="version-info.xml" xpointer="v248"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>COREDUMP_OPEN_FDS=</varname></term>
+
+        <listitem><para>Information about open file descriptors, in the following format:</para>
+        <programlisting><replaceable>fd</replaceable>:<replaceable>/path/to/file</replaceable>
+pos:     ...
+flags:   ...
+...
+
+<replaceable>fd</replaceable>:<replaceable>/path/to/file</replaceable>
+pos:     ...
+flags:   ...
+...
+        </programlisting>
+
+        <para>The first line contains the file descriptor number <replaceable>fd</replaceable> and the path,
+        while subsequent lines show the contents of
+        <filename>/proc/<replaceable>pid</replaceable>/fdinfo/<replaceable>fd</replaceable></filename>.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v248"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>COREDUMP_EXE=</varname></term>
+
+        <listitem><para>The destination of the <filename>/proc/<replaceable>pid</replaceable>/exe</filename>
+        symlink.</para>
+
+        <para>When the crashed process is in a container, that path is relative to the root of the
+        container's mount namespace.</para>
+
+        <xi:include href="version-info.xml" xpointer="v248"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>COREDUMP_CMDLINE=</varname></term>
+        <term><varname>COREDUMP_COMM=</varname></term>
+        <term><varname>COREDUMP_ENVIRON=</varname></term>
+        <term><varname>COREDUMP_PROC_AUXV=</varname></term>
+        <term><varname>COREDUMP_PROC_LIMITS=</varname></term>
+        <term><varname>COREDUMP_PROC_MAPS=</varname></term>
+        <term><varname>COREDUMP_PROC_MOUNTINFO=</varname></term>
+        <term><varname>COREDUMP_PROC_STATUS=</varname></term>
+
+        <listitem><para>Fields that map the per-process entries in the <filename>/proc/</filename>
+        filesystem: <filename>/proc/<replaceable>pid</replaceable>/cmdline</filename> (the command line of
+        the crashed process), <filename>/proc/<replaceable>pid</replaceable>/comm</filename> (the command
+        name associated with the process), <filename>/proc/<replaceable>pid</replaceable>/environ</filename>
+        (the environment block of the crashed process),
+        <filename>/proc/<replaceable>pid</replaceable>/auxv</filename> (the auxiliary vector of the crashed
+        process, see <citerefentry
+        project='man-pages'><refentrytitle>getauxval</refentrytitle><manvolnum>3</manvolnum></citerefentry>),
+        <filename>/proc/<replaceable>pid</replaceable>/limits</filename> (the soft and hard resource limits),
+        <filename>/proc/<replaceable>pid</replaceable>/maps</filename> (memory regions visible to the process
+        and their access permissions), <filename>/proc/<replaceable>pid</replaceable>/mountinfo</filename>
+        (mount points in the process's mount namespace),
+        <filename>/proc/<replaceable>pid</replaceable>/status</filename> (various metadata about the
+        process).</para>
+
+        <para>See
+        <citerefentry project='man-pages'><refentrytitle>proc</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for more information.</para>
+
+        <xi:include href="version-info.xml" xpointer="v248"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>COREDUMP_HOSTNAME=</varname></term>
+
+        <listitem><para>The system hostname.</para>
+
+        <para>When the crashed process was in container, this is the container hostname.</para>
+
+        <xi:include href="version-info.xml" xpointer="v248"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>COREDUMP_CONTAINER_CMDLINE=</varname></term>
+
+        <listitem><para>For processes running in a container, the command line of the process spawning the
+        container (the first parent process with a different mount namespace).</para>
+
+        <xi:include href="version-info.xml" xpointer="v248"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>COREDUMP=</varname></term>
+
+        <listitem><para>When the core is stored in the journal, the core image itself.</para>
+
+        <xi:include href="version-info.xml" xpointer="v248"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>COREDUMP_FILENAME=</varname></term>
+
+        <listitem><para>When the core is stored externally, the path to the core file.</para>
+
+        <xi:include href="version-info.xml" xpointer="v248"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>COREDUMP_TRUNCATED=</varname></term>
+
+        <listitem><para>Set to <literal>1</literal> when the saved coredump was truncated. (A partial core
+        image may still be processed by some tools, though obviously not all information is available.)
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v248"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>COREDUMP_PACKAGE_NAME=</varname></term>
+        <term><varname>COREDUMP_PACKAGE_VERSION=</varname></term>
+        <term><varname>COREDUMP_PACKAGE_JSON=</varname></term>
+
+        <listitem><para>If the executable contained .package metadata ELF notes, they will be
+        parsed and attached. The <varname>package</varname> and <varname>packageVersion</varname>
+        of the 'main' ELF module (ie: the executable) will be appended individually. The
+        JSON-formatted content of all modules will be appended as a single JSON object, each with
+        the module name as the key. For more information about this metadata format and content, see
+        <ulink url="https://systemd.io/COREDUMP_PACKAGE_METADATA/">the coredump metadata spec</ulink>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v249"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>MESSAGE=</varname></term>
+
+        <listitem><para>The message generated by <command>systemd-coredump</command> that includes the
+        backtrace if it was successfully generated. When <command>systemd-coredump</command> is invoked with
+        <option>--backtrace</option>, this field is provided by the caller.</para>
+
+        <xi:include href="version-info.xml" xpointer="v248"/></listitem>
+      </varlistentry>
+    </variablelist>
+
+    <para>Various other fields exist in the journal entry, but pertain to the logging process,
+    i.e. <command>systemd-coredump</command>, not the crashed process. See
+    <citerefentry><refentrytitle>systemd.journal-fields</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
+    </para>
+
+    <para>The following fields are saved (if known) with the external file listed in
+    <varname>COREDUMP_FILENAME=</varname> as extended attributes:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><varname>user.coredump.pid</varname></term>
+        <term><varname>user.coredump.uid</varname></term>
+        <term><varname>user.coredump.gid</varname></term>
+        <term><varname>user.coredump.signal</varname></term>
+        <term><varname>user.coredump.timestamp</varname></term>
+        <term><varname>user.coredump.rlimit</varname></term>
+        <term><varname>user.coredump.hostname</varname></term>
+        <term><varname>user.coredump.comm</varname></term>
+        <term><varname>user.coredump.exe</varname></term>
+
+        <listitem><para>Those are the same as <varname>COREDUMP_PID=</varname>,
+        <varname>COREDUMP_UID=</varname>, <varname>COREDUMP_GID=</varname>,
+        <varname>COREDUMP_SIGNAL=</varname>, <varname>COREDUMP_TIMESTAMP=</varname>,
+        <varname>COREDUMP_RLIMIT=</varname>, <varname>COREDUMP_HOSTNAME=</varname>,
+        <varname>COREDUMP_COMM=</varname>, and <varname>COREDUMP_EXE=</varname>, described above.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v248"/></listitem>
+      </varlistentry>
+    </variablelist>
+
+    <para>Those can be viewed using
+    <citerefentry project='man-pages'><refentrytitle>getfattr</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
+    For the core file described in the journal entry shown above:
+    <programlisting>$ getfattr --absolute-names -d /var/lib/systemd/coredump/core.Web….552351.….zst
+# file: /var/lib/systemd/coredump/core.Web….552351.….zst
+user.coredump.pid="552351"
+user.coredump.uid="1000"
+user.coredump.gid="1000"
+user.coredump.signal="11"
+user.coredump.timestamp="1614342930000000"
+user.coredump.comm="Web Content"
+user.coredump.exe="/usr/lib64/firefox/firefox"
+…
+</programlisting>
+    </para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>coredump.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>coredumpctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-tmpfiles</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>core</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sysctl.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-sysctl.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <ulink url="https://systemd.io/COREDUMP">systemd Coredump Handling</ulink>
+    </para>
+  </refsect1>
+</refentry>
diff --git a/man/systemd-creds.xml b/man/systemd-creds.xml
new file mode 100644
index 0000000..0c9a985
--- /dev/null
+++ b/man/systemd-creds.xml
@@ -0,0 +1,493 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd-creds"
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd-creds</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-creds</refentrytitle>
+    <manvolnum>1</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-creds</refname>
+    <refpurpose>Lists, shows, encrypts and decrypts service credentials</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <cmdsynopsis>
+      <command>systemd-creds</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="plain">COMMAND</arg>
+      <arg choice="opt" rep="repeat">ARGS</arg>
+    </cmdsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>systemd-creds</command> is a tool for listing, showing, encrypting and decrypting unit
+    credentials. Credentials are limited-size binary or textual objects that may be passed to unit
+    processes. They are primarily used for passing cryptographic keys (both public and private) or
+    certificates, user account information or identity information from the host to services.</para>
+
+    <para>Credentials are configured in unit files via the <varname>ImportCredential=</varname>,
+    <varname>LoadCredential=</varname>, <varname>SetCredential=</varname>,
+    <varname>LoadCredentialEncrypted=</varname>, and <varname>SetCredentialEncrypted=</varname> settings, see
+    <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
+    details.</para>
+
+    <para>For further information see <ulink url="https://systemd.io/CREDENTIALS">System and Service
+    Credentials</ulink> documentation.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Commands</title>
+
+    <para>The following commands are understood:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><command>list</command></term>
+
+        <listitem><para>Show a list of credentials passed into the current execution context. This command
+        shows the files in the directory referenced by the <varname>$CREDENTIALS_DIRECTORY</varname>
+        environment variable, and is intended to be executed from within service context.</para>
+
+        <para>Along with each credential name, the size and security state is shown. The latter is one of
+        <literal>secure</literal> (in case the credential is backed by unswappable memory,
+        i.e. <literal>ramfs</literal>), <literal>weak</literal> (in case it is backed by any other type of
+        memory), or <literal>insecure</literal> (if having any access mode that is not 0400, i.e. if readable
+        by anyone but the owner).</para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>cat</command> <replaceable>credential...</replaceable></term>
+
+        <listitem><para>Show contents of specified credentials passed into the current execution
+        context. Takes one or more credential names, whose contents shall be written to standard
+        output.</para>
+
+        <para>When combined with <option>--json=</option> or <option>--transcode=</option> the output is
+        transcoded in simple ways before outputting.</para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>setup</command></term>
+
+        <listitem><para>Generates a host encryption key for credentials, if one has not been generated
+        already. This ensures the <filename>/var/lib/systemd/credential.secret</filename> file is initialized
+        with a random secret key if it doesn't exist yet. This secret key is used when encrypting/decrypting
+        credentials with <command>encrypt</command> or <command>decrypt</command>, and is only accessible to
+        the root user. Note that there's typically no need to invoke this command explicitly as it is
+        implicitly called when <command>encrypt</command> is invoked, and credential host key encryption
+        selected.</para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>encrypt</command> <replaceable>input|-</replaceable> <replaceable>output|-</replaceable></term>
+
+        <listitem><para>Loads the specified (unencrypted plaintext) input credential file, encrypts it and
+        writes the (encrypted ciphertext) output to the specified target credential file. The resulting file
+        may be referenced in the <varname>LoadCredentialEncrypted=</varname> setting in unit files, or its
+        contents used literally in <varname>SetCredentialEncrypted=</varname> settings.</para>
+
+        <para>Takes two file system paths. The file name part of the output path is embedded as name in the
+        encrypted credential, to ensure encrypted credentials cannot be renamed and reused for different
+        purposes without this being noticed. The credential name to embed may be overridden with the
+        <option>--name=</option> setting. The input or output paths may be specified as <literal>-</literal>,
+        in which case the credential data is read from/written to standard input and standard output. If the
+        output path is specified as <literal>-</literal> the credential name cannot be derived from the file
+        system path, and thus should be specified explicitly via the <option>--name=</option> switch.</para>
+
+        <para>The credential data is encrypted and authenticated symmetrically with one of the following
+        encryption keys:</para>
+
+        <orderedlist>
+          <listitem><para>A secret key automatically derived from the system's TPM2 chip. This encryption key
+          is not stored on the host system and thus decryption is only possible with access to the original
+          TPM2 chip. Or in other words, the credential secured in this way can only be decrypted again by the
+          local machine.</para></listitem>
+
+          <listitem><para>A secret key stored in the <filename>/var/lib/systemd/credential.secret</filename>
+          file which is only accessible to the root user. This "host" encryption key is stored on the host
+          file system, and thus decryption is possible with access to the host file system and sufficient
+          privileges. The key is automatically generated when needed, but can also be created explicitly with
+          the <command>setup</command> command, see above.</para></listitem>
+
+          <listitem><para>A combination of the above: an encryption key derived from both the TPM2 chip and
+          the host file system. This means decryption requires both access to the original TPM2 chip and the
+          OS installation. This is the default mode of operation if a TPM2 chip is available and
+          <filename>/var/lib/systemd/</filename> resides on persistent media.</para></listitem>
+        </orderedlist>
+
+        <para>Which of the three keys shall be used for encryption may be configured with the
+        <option>--with-key=</option> switch. Depending on the use-case for the encrypted credential the key
+        to use may differ. For example, for credentials that shall be accessible from the initrd, encryption
+        with the host key is not appropriate, since access to the host key is typically not available from
+        the initrd. Thus, for such credentials only the TPM2 key should be used.</para>
+
+        <para>Encrypted credentials are always encoded in Base64.</para>
+
+        <para>Use <command>decrypt</command> (see below) to undo the encryption operation, and acquire the
+        decrypted plaintext credential from the encrypted ciphertext credential.</para>
+
+        <para>The credential data is encrypted using AES256-GCM, i.e. providing both confidentiality and
+        integrity, keyed by a SHA256 hash of one or both of the secret keys described above.</para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>decrypt</command> <replaceable>input|-</replaceable>
+        <optional><replaceable>output|-</replaceable></optional></term>
+
+        <listitem><para>Undoes the effect of the <command>encrypt</command> operation: loads the specified
+        (encrypted ciphertext) input credential file, decrypts and authenticates it and writes the (decrypted
+        plaintext) output to the specified target credential file.</para>
+
+        <para>Takes one or two file system paths. The file name part of the input path is compared with the
+        credential name embedded in the encrypted file. If it does not match decryption fails. This is done
+        in order to ensure that encrypted credentials are not re-purposed without this being detected. The
+        credential name to compare with the embedded credential name may also be overridden with the
+        <option>--name=</option> switch. If the input path is specified as <literal>-</literal>, the
+        encrypted credential is read from standard input. If only one path is specified or the output path
+        specified as <literal>-</literal>, the decrypted credential is written to standard output. In this
+        mode, the expected name embedded in the credential cannot be derived from the path and should be
+        specified explicitly with <option>--name=</option>.</para>
+
+        <para>Decrypting credentials requires access to the original TPM2 chip and/or credentials host key,
+        see above. Information about which keys are required is embedded in the encrypted credential data,
+        and thus decryption is entirely automatic.</para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>has-tpm2</command></term>
+
+        <listitem><para>Reports whether the system is equipped with a TPM2 device usable for protecting
+        credentials. If a TPM2 device has been discovered, is supported, and is being used by firmware,
+        by the OS kernel drivers and by userspace (i.e. systemd) this prints <literal>yes</literal> and exits
+        with exit status zero. If no such device is discovered/supported/used, prints
+        <literal>no</literal>. Otherwise prints <literal>partial</literal>. In either of these two cases
+        exits with non-zero exit status. It also shows four lines indicating separately whether firmware,
+        drivers, the system and the kernel discovered/support/use TPM2.</para>
+
+        <para>Combine with <option>--quiet</option> to suppress the output.</para>
+
+        <xi:include href="version-info.xml" xpointer="v251"/></listitem>
+      </varlistentry>
+
+      <xi:include href="standard-options.xml" xpointer="help" />
+      <xi:include href="standard-options.xml" xpointer="version" />
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <variablelist>
+
+      <varlistentry>
+        <term><option>--system</option></term>
+
+        <listitem><para>When specified with the <command>list</command> and <command>cat</command> commands
+        operates on the credentials passed to system as a whole instead of on those passed to the current
+        execution context. This is useful in container environments where credentials may be passed in from
+        the container manager.</para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--transcode=</option></term>
+
+        <listitem><para>When specified with the <command>cat</command> or <command>decrypt</command>
+        commands, transcodes the output before showing it. Takes one of <literal>base64</literal>,
+        <literal>unbase64</literal>, <literal>hex</literal> or <literal>unhex</literal> as argument, in order
+        to encode/decode the credential data with Base64 or as series of hexadecimal values.</para>
+
+        <para>Note that this has no effect on the <command>encrypt</command> command, as encrypted
+        credentials are unconditionally encoded in Base64.</para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--newline=</option></term>
+
+        <listitem><para>When specified with <command>cat</command> or <command>decrypt</command> controls
+        whether to add a trailing newline character to the end of the output if it doesn't end in one,
+        anyway. Takes one of <literal>auto</literal>, <literal>yes</literal> or <literal>no</literal>. The
+        default mode of <literal>auto</literal> will suffix the output with a single newline character only
+        when writing credential data to a TTY.</para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--pretty</option></term>
+        <term><option>-p</option></term>
+
+        <listitem><para>When specified with <command>encrypt</command> controls whether to show the encrypted
+        credential as <varname>SetCredentialEncrypted=</varname> setting that may be pasted directly into a
+        unit file. Has effect only when used together with <option>--name=</option> and <literal>-</literal>
+        as the output file.</para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--name=</option><replaceable>name</replaceable></term>
+
+        <listitem><para>When specified with the <command>encrypt</command> command controls the credential
+        name to embed in the encrypted credential data. If not specified the name is chosen automatically
+        from the filename component of the specified output path. If specified as empty string no
+        credential name is embedded in the encrypted credential, and no verification of credential name is
+        done when the credential is decrypted.</para>
+
+        <para>When specified with the <command>decrypt</command> command control the credential name to
+        validate the credential name embedded in the encrypted credential with. If not specified the name is
+        chosen automatically from the filename component of the specified input path. If no credential name
+        is embedded in the encrypted credential file (i.e. the <option>--name=</option> with an empty string
+        was used when encrypted) the specified name has no effect as no credential name validation is
+        done.</para>
+
+        <para>Embedding the credential name in the encrypted credential is done in order to protect against
+        reuse of credentials for purposes they weren't originally intended for, under the assumption the
+        credential name is chosen carefully to encode its intended purpose.</para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--timestamp=</option><replaceable>timestamp</replaceable></term>
+
+        <listitem><para>When specified with the <command>encrypt</command> command controls the timestamp to
+        embed into the encrypted credential. Defaults to the current time. Takes a timestamp specification in
+        the format described in
+        <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
+
+        <para>When specified with the <command>decrypt</command> command controls the timestamp to use to
+        validate the "not-after" timestamp that was configured with <option>--not-after=</option> during
+        encryption. If not specified defaults to the current system time.</para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--not-after=</option><replaceable>timestamp</replaceable></term>
+
+        <listitem><para>When specified with the <command>encrypt</command> command controls the time when the
+        credential shall not be used anymore. This embeds the specified timestamp in the encrypted
+        credential. During decryption the timestamp is checked against the current system clock, and if the
+        timestamp is in the past the decryption will fail. By default no such timestamp is set. Takes a
+        timestamp specification in the format described in
+        <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--with-key=</option></term>
+        <term><option>-H</option></term>
+        <term><option>-T</option></term>
+
+        <listitem><para>When specified with the <command>encrypt</command> command controls the
+        encryption/signature key to use. Takes one of <literal>host</literal>, <literal>tpm2</literal>,
+        <literal>host+tpm2</literal>, <literal>tpm2-absent</literal>, <literal>auto</literal>,
+        <literal>auto-initrd</literal>. See above for details on the three key types. If set to
+        <literal>auto</literal> (which is the default) the TPM2 key is used if a TPM2 device is found and not
+        running in a container. The host key is used if <filename>/var/lib/systemd/</filename> is on
+        persistent media. This means on typical systems the encryption is by default bound to both the TPM2
+        chip and the OS installation, and both need to be available to decrypt the credential again. If
+        <literal>auto</literal> is selected but neither TPM2 is available (or running in container) nor
+        <filename>/var/lib/systemd/</filename> is on persistent media, encryption will fail. If set to
+        <literal>tpm2-absent</literal> a fixed zero length key is used (thus, in this mode no confidentiality
+        nor authenticity are provided!). This logic is useful to cover for systems that lack a TPM2 chip but
+        where credentials shall be generated. Note that decryption of such credentials is refused on systems
+        that have a TPM2 chip and where UEFI SecureBoot is enabled (this is done so that such a locked down
+        system cannot be tricked into loading a credential generated this way that lacks authentication
+        information). If set to <literal>auto-initrd</literal> a TPM2 key is used if a TPM2 is found. If not
+        a fixed zero length key is used, equivalent to <literal>tpm2-absent</literal> mode. This option is
+        particularly useful to generate credentials files that are encrypted/authenticated against TPM2 where
+        available but still work on systems lacking support for this.</para>
+
+        <para>The <option>-H</option> switch is a shortcut for <option>--with-key=host</option>. Similar,
+        <option>-T</option> is a shortcut for <option>--with-key=tpm2</option>.</para>
+
+        <para>When encrypting credentials that shall be used in the initrd (where
+        <filename>/var/lib/systemd/</filename> is typically not available) make sure to use
+        <option>--with-key=auto-initrd</option> mode, to disable binding against the host secret.</para>
+
+        <para>This switch has no effect on the <command>decrypt</command> command, as information on which
+        key to use for decryption is included in the encrypted credential already.</para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--tpm2-device=</option><replaceable>PATH</replaceable></term>
+
+        <listitem><para>Controls the TPM2 device to use. Expects a device node path referring to the TPM2
+        chip (e.g. <filename>/dev/tpmrm0</filename>). Alternatively the special value <literal>auto</literal>
+        may be specified, in order to automatically determine the device node of a suitable TPM2 device (of
+        which there must be exactly one). The special value <literal>list</literal> may be used to enumerate
+        all suitable TPM2 devices currently discovered.</para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--tpm2-pcrs=</option><arg rep="repeat">PCR</arg></term>
+
+        <listitem><para>Configures the TPM2 PCRs (Platform Configuration Registers) to bind the encryption
+        key to. Takes a <literal>+</literal> separated list of numeric PCR indexes in the range 0…23. If not
+        used, defaults to PCR 7 only. If an empty string is specified, binds the encryption key to no PCRs at
+        all. For details about the PCRs available, see the documentation of the switch of the same name for
+        <citerefentry><refentrytitle>systemd-cryptenroll</refentrytitle><manvolnum>1</manvolnum></citerefentry>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--tpm2-public-key=</option><arg>PATH</arg></term>
+        <term><option>--tpm2-public-key-pcrs=</option><arg rep="repeat">PCR</arg></term>
+
+        <listitem><para>Configures a TPM2 signed PCR policy to bind encryption to, for use with the
+        <command>encrypt</command> command. The <option>--tpm2-public-key=</option> option accepts a path to
+        a PEM encoded RSA public key, to bind the encryption to. If this is not specified explicitly, but a
+        file <filename>tpm2-pcr-public-key.pem</filename> exists in one of the directories
+        <filename>/etc/systemd/</filename>, <filename>/run/systemd/</filename>,
+        <filename>/usr/lib/systemd/</filename> (searched in this order), it is automatically used. The
+        <option>--tpm2-public-key-pcrs=</option> option takes a list of TPM2 PCR indexes to bind to (same
+        syntax as <option>--tpm2-pcrs=</option> described above). If not specified defaults to 11 (i.e. this
+        binds the policy to any unified kernel image for which a PCR signature can be provided).</para>
+
+        <para>Note the difference between <option>--tpm2-pcrs=</option> and
+        <option>--tpm2-public-key-pcrs=</option>: the former binds decryption to the current, specific PCR
+        values; the latter binds decryption to any set of PCR values for which a signature by the specified
+        public key can be provided. The latter is hence more useful in scenarios where software updates shall
+        be possible without losing access to all previously encrypted secrets.</para>
+
+        <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--tpm2-signature=</option><arg>PATH</arg></term>
+
+        <listitem><para>Takes a path to a TPM2 PCR signature file as generated by the
+        <citerefentry><refentrytitle>systemd-measure</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+        tool and that may be used to allow the <command>decrypt</command> command to decrypt credentials that
+        are bound to specific signed PCR values. If this is not specified explicitly, and a credential
+        with a signed PCR policy is attempted to be decrypted, a suitable signature file
+        <filename>tpm2-pcr-signature.json</filename> is searched for in <filename>/etc/systemd/</filename>,
+        <filename>/run/systemd/</filename>, <filename>/usr/lib/systemd/</filename> (in this order) and
+        used.</para>
+
+        <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--quiet</option></term>
+        <term><option>-q</option></term>
+
+        <listitem><para>When used with <command>has-tpm2</command> suppresses the output, and only returns an
+        exit status indicating support for TPM2.</para>
+
+        <xi:include href="version-info.xml" xpointer="v251"/></listitem>
+      </varlistentry>
+
+      <xi:include href="standard-options.xml" xpointer="no-pager" />
+      <xi:include href="standard-options.xml" xpointer="no-legend" />
+      <xi:include href="standard-options.xml" xpointer="json" />
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Exit status</title>
+
+    <para>On success, 0 is returned.</para>
+
+    <para>In case of the <command>has-tpm2</command> command returns 0 if a TPM2 device is discovered,
+    supported and used by firmware, driver, and userspace (i.e. systemd). Otherwise returns the OR
+    combination of the value 1 (in case firmware support is missing), 2 (in case driver support is missing)
+    and 4 (in case userspace support is missing). If no TPM2 support is available at all, value 7 is hence
+    returned.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Examples</title>
+
+    <example>
+      <title>Encrypt a password for use as credential</title>
+
+      <para>The following command line encrypts the specified password <literal>hunter2</literal>, writing the result
+      to a file <filename>password.cred</filename>.</para>
+
+      <programlisting># echo -n hunter2 | systemd-creds encrypt - password.cred</programlisting>
+
+      <para>This decrypts the file <filename>password.cred</filename> again, revealing the literal password:</para>
+
+      <programlisting># systemd-creds decrypt password.cred
+hunter2</programlisting>
+    </example>
+
+    <example>
+      <title>Encrypt a password and include it in a unit file</title>
+
+      <para>The following command line prompts the user for a password and generates a
+      <varname>SetCredentialEncrypted=</varname> line from it for a credential named
+      <literal>mysql-password</literal>, suitable for inclusion in a unit file.</para>
+
+      <programlisting># systemd-ask-password -n | systemd-creds encrypt --name=mysql-password -p - -
+🔐 Password: ****
+SetCredentialEncrypted=mysql-password: \
+        k6iUCUh0RJCQyvL8k8q1UyAAAAABAAAADAAAABAAAAASfFsBoPLIm/dlDoGAAAAAAAAAA \
+        NAAAAAgAAAAAH4AILIOZ3w6rTzYsBy9G7liaCAd4i+Kpvs8mAgArzwuKxd0ABDjgSeO5k \
+        mKQc58zM94ZffyRmuNeX1lVHE+9e2YD87KfRFNoDLS7F3YmCb347gCiSk2an9egZ7Y0Xs \
+        700Kr6heqQswQEemNEc62k9RJnEl2q7SbcEYguegnPQUATgAIAAsAAAASACA/B90W7E+6 \
+        yAR9NgiIJvxr9bpElztwzB5lUJAxtMBHIgAQACCaSV9DradOZz4EvO/LSaRyRSq2Hj0ym \
+        gVJk/dVzE8Uxj8H3RbsT7rIBH02CIgm/Gv1ukSXO3DMHmVQkDG0wEciyageTfrVEer8z5 \
+        9cUQfM5ynSaV2UjeUWEHuz4fwDsXGLB9eELXLztzUU9nsAyLvs3ZRR+eEK/A==</programlisting>
+
+      <para>The generated line can be pasted 1:1 into a unit file, and will ensure the acquired password will
+      be made available in the <varname>$CREDENTIALS_DIRECTORY</varname><filename>/mysql-password</filename>
+      credential file for the started service.</para>
+
+      <para>Utilizing the unit file drop-in logic this can be used to securely pass a password credential to
+      a unit. A similar, more comprehensive set of commands to insert a password into a service
+      <filename>xyz.service</filename>:</para>
+
+      <programlisting># mkdir -p /etc/systemd/system/xyz.service.d
+# systemd-ask-password -n | ( echo "[Service]" &amp;&amp; systemd-creds encrypt --name=mysql-password -p - - ) >/etc/systemd/system/xyz.service.d/50-password.conf
+# systemctl daemon-reload
+# systemctl restart xyz.service</programlisting>
+    </example>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-measure</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-cryptenroll.xml b/man/systemd-cryptenroll.xml
new file mode 100644
index 0000000..8fd885c
--- /dev/null
+++ b/man/systemd-cryptenroll.xml
@@ -0,0 +1,657 @@
+<?xml version="1.0"?>
+<!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+<refentry id="systemd-cryptenroll" xmlns:xi="http://www.w3.org/2001/XInclude" conditional='HAVE_LIBCRYPTSETUP'>
+
+  <refentryinfo>
+    <title>systemd-cryptenroll</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-cryptenroll</refentrytitle>
+    <manvolnum>1</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-cryptenroll</refname>
+    <refpurpose>Enroll PKCS#11, FIDO2, TPM2 token/devices to LUKS2 encrypted volumes</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <cmdsynopsis>
+      <command>systemd-cryptenroll</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="opt">DEVICE</arg>
+    </cmdsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>systemd-cryptenroll</command> is a tool for enrolling hardware security tokens and devices
+    into a LUKS2 encrypted volume, which may then be used to unlock the volume during boot. Specifically, it
+    supports tokens and credentials of the following kind to be enrolled:</para>
+
+    <orderedlist>
+      <listitem><para>PKCS#11 security tokens and smartcards that may carry an RSA key pair (e.g. various
+      YubiKeys)</para></listitem>
+
+      <listitem><para>FIDO2 security tokens that implement the <literal>hmac-secret</literal> extension (most
+      FIDO2 keys, including YubiKeys)</para></listitem>
+
+      <listitem><para>TPM2 security devices</para></listitem>
+
+      <listitem><para>Regular passphrases</para></listitem>
+
+      <listitem><para>Recovery keys. These are similar to regular passphrases, however are randomly generated
+      on the computer and thus generally have higher entropy than user-chosen passphrases. Their character
+      set has been designed to ensure they are easy to type in, while having high entropy. They may also be
+      scanned off screen using QR codes. Recovery keys may be used for unlocking LUKS2 volumes wherever
+      passphrases are accepted. They are intended to be used in combination with an enrolled hardware
+      security token, as a recovery option when the token is lost.</para></listitem>
+    </orderedlist>
+
+    <para>In addition, the tool may be used to enumerate currently enrolled security tokens and wipe a subset
+    of them. The latter may be combined with the enrollment operation of a new security token, in order to
+    update or replace enrollments.</para>
+
+    <para>The tool supports only LUKS2 volumes, as it stores token meta-information in the LUKS2 JSON token
+    area, which is not available in other encryption formats.</para>
+
+    <refsect2>
+      <title>TPM2 PCRs and policies</title>
+
+      <para>PCRs allow binding of the encryption of secrets to specific software versions and system state,
+      so that the enrolled key is only accessible (may be "unsealed") if specific trusted software and/or
+      configuration is used. Such bindings may be created with the option <option>--tpm2-pcrs=</option>
+      described below.</para>
+
+      <para>Secrets may also be bound indirectly: a signed policy for a state of some combination of PCR
+      values is provided, and the secret is bound to the public part of the key used to sign this policy.
+      This means that the owner of a key can generate a sequence of signed policies, for specific software
+      versions and system states, and the secret can be decrypted as long as the machine state matches one of
+      those policies. For example, a vendor may provide such a policy for each kernel+initrd update, allowing
+      users to encrypt secrets so that they can be decrypted when running any kernel+initrd signed by the
+      vendor. Such bindings may be created with the options <option>--tpm2-public-key=</option>,
+      <option>--tpm2-public-key-pcrs=</option>, <option>--tpm2-signature=</option> described below.
+      </para>
+
+      <para>See <ulink url="https://uapi-group.org/specifications/specs/linux_tpm_pcr_registry/">Linux TPM
+      PCR Registry</ulink> for an authoritative list of PCRs and how they are updated. The table below
+      contains a quick reference, describing in particular the PCRs modified by systemd.</para>
+
+      <table>
+        <title>Well-known PCR Definitions</title>
+
+        <!-- See: https://trustedcomputinggroup.org/resource/pc-client-specific-platform-firmware-profile-specification/ -->
+        <!-- See: https://github.com/rhboot/shim/blob/main/README.tpm -->
+        <!-- See: https://www.gnu.org/software/grub/manual/grub/html_node/Measured-Boot.html -->
+        <!-- See: https://sourceforge.net/p/linux-ima/wiki/Home/ -->
+        <!-- See: https://github.com/tianocore-docs/edk2-TrustedBootChain/blob/main/4_Other_Trusted_Boot_Chains.md -->
+        <!-- See: https://wiki.archlinux.org/title/Trusted_Platform_Module#Accessing_PCR_registers -->
+
+        <tgroup cols='3' align='left' colsep='1' rowsep='1'>
+          <colspec colname="pcr" />
+          <colspec colname="name" />
+          <colspec colname="definition" />
+
+          <thead>
+            <row>
+              <entry>PCR</entry>
+              <entry>name</entry>
+              <entry>Explanation</entry>
+            </row>
+          </thead>
+
+          <tbody>
+            <row>
+              <entry>0</entry>
+              <entry>platform-code</entry>
+              <entry>Core system firmware executable code; changes on firmware updates</entry>
+            </row>
+
+            <row>
+              <entry>1</entry>
+              <entry>platform-config</entry>
+              <entry>Core system firmware data/host platform configuration; typically contains serial and model numbers, changes on basic hardware/CPU/RAM replacements</entry>
+            </row>
+
+            <row>
+              <entry>2</entry>
+              <entry>external-code</entry>
+              <entry>Extended or pluggable executable code; includes option ROMs on pluggable hardware</entry>
+            </row>
+
+            <row>
+              <entry>3</entry>
+              <entry>external-config</entry>
+              <entry>Extended or pluggable firmware data; includes information about pluggable hardware</entry>
+            </row>
+
+            <row>
+              <entry>4</entry>
+              <entry>boot-loader-code</entry>
+              <entry>Boot loader and additional drivers, PE binaries invoked by the boot loader; changes on boot loader updates. <citerefentry><refentrytitle>sd-stub</refentrytitle><manvolnum>7</manvolnum></citerefentry> measures system extension images read from the ESP here too (see <citerefentry><refentrytitle>systemd-sysext</refentrytitle><manvolnum>8</manvolnum></citerefentry>).</entry>
+            </row>
+
+            <row>
+              <entry>5</entry>
+              <entry>boot-loader-config</entry>
+              <entry>GPT/Partition table; changes when the partitions are added, modified, or removed</entry>
+            </row>
+
+            <row>
+              <entry>7</entry>
+              <entry>secure-boot-policy</entry>
+              <entry>Secure Boot state; changes when UEFI SecureBoot mode is enabled/disabled, or firmware certificates (PK, KEK, db, dbx, …) changes.</entry>
+            </row>
+
+            <row>
+              <entry>9</entry>
+              <entry>kernel-initrd</entry>
+              <entry>The Linux kernel measures all initrds it receives into this PCR.</entry>
+              <!-- Strictly speaking only Linux >= 5.17 using the LOAD_FILE2 protocol, see https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f046fff8bc4c4d8f8a478022e76e40b818f692df -->
+            </row>
+
+            <row>
+              <entry>10</entry>
+              <entry>ima</entry>
+              <entry>The IMA project measures its runtime state into this PCR.</entry>
+            </row>
+
+            <row>
+              <entry>11</entry>
+              <entry>kernel-boot</entry>
+              <entry><citerefentry><refentrytitle>systemd-stub</refentrytitle><manvolnum>7</manvolnum></citerefentry> measures the ELF kernel image, embedded initrd and other payload of the PE image it is placed in into this PCR. <citerefentry><refentrytitle>systemd-pcrphase.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> measures boot phase strings into this PCR at various milestones of the boot process.</entry>
+            </row>
+
+            <row>
+              <entry>12</entry>
+              <entry>kernel-config</entry>
+              <entry><citerefentry><refentrytitle>systemd-boot</refentrytitle><manvolnum>7</manvolnum></citerefentry> measures the kernel command line into this PCR. <citerefentry><refentrytitle>systemd-stub</refentrytitle><manvolnum>7</manvolnum></citerefentry> measures any manually specified kernel command line (i.e. a kernel command line that overrides the one embedded in the unified PE image) and loaded credentials into this PCR.</entry>
+            </row>
+
+            <row>
+              <entry>13</entry>
+              <entry>sysexts</entry>
+              <entry><citerefentry><refentrytitle>systemd-stub</refentrytitle><manvolnum>7</manvolnum></citerefentry> measures any <citerefentry><refentrytitle>systemd-sysext</refentrytitle><manvolnum>8</manvolnum></citerefentry> images it passes to the booted kernel into this PCR.</entry>
+            </row>
+
+            <row>
+              <entry>14</entry>
+              <entry>shim-policy</entry>
+              <entry>The shim project measures its "MOK" certificates and hashes into this PCR.</entry>
+            </row>
+
+            <row>
+              <entry>15</entry>
+              <entry>system-identity</entry>
+              <entry><citerefentry><refentrytitle>systemd-cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry> optionally measures the volume key of activated LUKS volumes into this PCR. <citerefentry><refentrytitle>systemd-pcrmachine.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> measures the <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry> into this PCR. <citerefentry><refentrytitle>systemd-pcrfs@.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> measures mount points, file system UUIDs, labels, partition UUIDs of the root and <filename>/var/</filename> filesystems into this PCR.</entry>
+            </row>
+
+            <row>
+              <entry>16</entry>
+              <entry>debug</entry>
+              <entry>Debug</entry>
+            </row>
+
+            <row>
+              <entry>23</entry>
+              <entry>application-support</entry>
+              <entry>Application Support</entry>
+            </row>
+          </tbody>
+        </tgroup>
+      </table>
+
+      <para>In general, encrypted volumes would be bound to some combination of PCRs 7, 11, and 14 (if
+      shim/MOK is used). In order to allow firmware and OS version updates, it is typically not advisable to
+      use PCRs such as 0 and 2, since the program code they cover should already be covered indirectly
+      through the certificates measured into PCR 7. Validation through certificates hashes is typically
+      preferable over validation through direct measurements as it is less brittle in context of OS/firmware
+      updates: the measurements will change on every update, but signatures should remain unchanged. See the
+      <ulink url="https://uapi-group.org/specifications/specs/linux_tpm_pcr_registry/">Linux TPM PCR
+      Registry</ulink> for more discussion.</para>
+    </refsect2>
+  </refsect1>
+
+  <refsect1>
+    <title>Limitations</title>
+
+    <para>Note that currently when enrolling a new key of one of the five supported types listed above, it is
+    required to first provide a passphrase, a recovery key or a FIDO2 token. It's currently not supported to
+    unlock a device with a TPM2/PKCS#11 key in order to enroll a new TPM2/PKCS#11 key. Thus, if in future key
+    roll-over is desired it's generally recommended to ensure a passphrase, a recovery key or a FIDO2 token
+    is always enrolled.</para>
+
+    <para>Also note that support for enrolling multiple FIDO2 tokens is currently limited. When multiple FIDO2
+    tokens are enrolled, <command>systemd-cryptseup</command> will perform pre-flight requests to attempt to
+    identify which of the enrolled tokens are currently plugged in. However, this is not possible for FIDO2
+    tokens with user verification (UV, usually via biometrics), in which case it will fall back to attempting
+    each enrolled token one by one. This will result in multiple prompts for PIN and user verification. This
+    limitation does not apply to PKCS#11 tokens.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Compatibility</title>
+
+    <para>Security technology both in systemd and in the general industry constantly evolves. In order to
+    provide best security guarantees, the way TPM2, FIDO2, PKCS#11 devices are enrolled is regularly updated
+    in newer versions of systemd. Whenever this happens the following compatibility guarantees are given:</para>
+
+    <itemizedlist>
+      <listitem><para>Old enrollments continue to be supported and may be unlocked with newer versions of
+      <citerefentry><refentrytitle>systemd-cryptsetup@.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para></listitem>
+
+      <listitem><para>The opposite is not guaranteed however: it might not be possible to unlock volumes with
+      enrollments done with a newer version of <command>systemd-cryptenroll</command> with an older version
+      of <command>systemd-cryptsetup</command>.</para></listitem>
+    </itemizedlist>
+
+    <para>That said, it is generally recommended to use matching versions of
+    <command>systemd-cryptenroll</command> and <command>systemd-cryptsetup</command>, since this is best
+    tested and supported.</para>
+
+    <para>It might be advisable to re-enroll existing enrollments to take benefit of newer security features,
+    as they are added to systemd.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>The following options are understood:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><option>--password</option></term>
+
+        <listitem><para>Enroll a regular password/passphrase. This command is mostly equivalent to
+        <command>cryptsetup luksAddKey</command>, however may be combined with
+        <option>--wipe-slot=</option> in one call, see below.</para>
+
+        <xi:include href="version-info.xml" xpointer="v248"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--recovery-key</option></term>
+
+        <listitem><para>Enroll a recovery key. Recovery keys are mostly identical to passphrases, but are
+        computer-generated instead of being chosen by a human, and thus have a guaranteed high entropy. The
+        key uses a character set that is easy to type in, and may be scanned off screen via a QR code.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v248"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--unlock-key-file=</option><replaceable>PATH</replaceable></term>
+
+        <listitem><para>Use a file instead of a password/passphrase read from stdin to unlock the volume.
+        Expects the PATH to the file containing your key to unlock the volume. Currently there is nothing like
+        <option>--key-file-offset=</option> or <option>--key-file-size=</option> so this file has to only
+        contain the full key.</para>
+
+        <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--unlock-fido2-device=</option><replaceable>PATH</replaceable></term>
+
+        <listitem><para>Use a FIDO2 device instead of a password/passphrase read from stdin to unlock the
+        volume. Expects a <filename>hidraw</filename> device referring to the FIDO2 device (e.g.
+        <filename>/dev/hidraw1</filename>). Alternatively the special value <literal>auto</literal> may be
+        specified, in order to automatically determine the device node of a currently plugged in security
+        token (of which there must be exactly one). This automatic discovery is unsupported if
+        <option>--fido2-device=</option> option is also specified.</para>
+
+        <xi:include href="version-info.xml" xpointer="v253"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--pkcs11-token-uri=</option><replaceable>URI</replaceable></term>
+
+        <listitem><para>Enroll a PKCS#11 security token or smartcard (e.g. a YubiKey). Expects a PKCS#11
+        smartcard URI referring to the token. Alternatively the special value <literal>auto</literal> may
+        be specified, in order to automatically determine the URI of a currently plugged in security token
+        (of which there must be exactly one). The special value <literal>list</literal> may be used to
+        enumerate all suitable PKCS#11 tokens currently plugged in. The security token must contain an RSA
+        key pair which is used to encrypt the randomly generated key that is used to unlock the LUKS2
+        volume. The encrypted key is then stored in the LUKS2 JSON token header area.</para>
+
+        <para>In order to unlock a LUKS2 volume with an enrolled PKCS#11 security token, specify the
+        <option>pkcs11-uri=</option> option in the respective <filename>/etc/crypttab</filename> line:</para>
+
+        <programlisting>myvolume /dev/sda1 - pkcs11-uri=auto</programlisting>
+
+        <para>See
+        <citerefentry><refentrytitle>crypttab</refentrytitle><manvolnum>5</manvolnum></citerefentry> for a
+        more comprehensive example of a <command>systemd-cryptenroll</command> invocation and its matching
+        <filename>/etc/crypttab</filename> line.</para>
+
+        <xi:include href="version-info.xml" xpointer="v248"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--fido2-credential-algorithm=</option><replaceable>STRING</replaceable></term>
+        <listitem><para>Specify COSE algorithm used in credential generation. The default value is
+        <literal>es256</literal>. Supported values are <literal>es256</literal>, <literal>rs256</literal>
+        and <literal>eddsa</literal>.</para>
+
+        <para><literal>es256</literal> denotes ECDSA over NIST P-256 with SHA-256. <literal>rs256</literal>
+        denotes 2048-bit RSA with PKCS#1.5 padding and SHA-256. <literal>eddsa</literal> denotes
+        EDDSA over Curve25519 with SHA-512.</para>
+
+        <para>Note that your authenticator may not support some algorithms.</para>
+
+        <xi:include href="version-info.xml" xpointer="v251"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--fido2-device=</option><replaceable>PATH</replaceable></term>
+
+        <listitem><para>Enroll a FIDO2 security token that implements the <literal>hmac-secret</literal>
+        extension (e.g. a YubiKey). Expects a <filename>hidraw</filename> device referring to the FIDO2
+        device (e.g. <filename>/dev/hidraw1</filename>). Alternatively the special value
+        <literal>auto</literal> may be specified, in order to automatically determine the device node of a
+        currently plugged in security token (of which there must be exactly one). This automatic discovery
+        is unsupported if <option>--unlock-fido2-device=</option> option is also specified. The special value
+        <literal>list</literal> may be used to enumerate all suitable FIDO2 tokens currently plugged in. Note
+        that many hardware security tokens that implement FIDO2 also implement the older PKCS#11
+        standard. Typically FIDO2 is preferable, given it's simpler to use and more modern.</para>
+
+        <para>In order to unlock a LUKS2 volume with an enrolled FIDO2 security token, specify the
+        <option>fido2-device=</option> option in the respective <filename>/etc/crypttab</filename> line:</para>
+
+        <programlisting>myvolume /dev/sda1 - fido2-device=auto</programlisting>
+
+        <para>See
+        <citerefentry><refentrytitle>crypttab</refentrytitle><manvolnum>5</manvolnum></citerefentry> for a
+        more comprehensive example of a <command>systemd-cryptenroll</command> invocation and its matching
+        <filename>/etc/crypttab</filename> line.</para>
+
+        <xi:include href="version-info.xml" xpointer="v248"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--fido2-with-client-pin=</option><replaceable>BOOL</replaceable></term>
+
+        <listitem><para>When enrolling a FIDO2 security token, controls whether to require the user to enter
+        a PIN when unlocking the volume (the FIDO2 <literal>clientPin</literal> feature). Defaults to
+        <literal>yes</literal>. (Note: this setting is without effect if the security token does not support
+        the <literal>clientPin</literal> feature at all, or does not allow enabling or disabling
+        it.)</para>
+
+        <xi:include href="version-info.xml" xpointer="v249"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--fido2-with-user-presence=</option><replaceable>BOOL</replaceable></term>
+
+        <listitem><para>When enrolling a FIDO2 security token, controls whether to require the user to
+        verify presence (tap the token, the FIDO2 <literal>up</literal> feature) when unlocking the volume.
+        Defaults to <literal>yes</literal>. (Note: this setting is without effect if the security token does not support
+        the <literal>up</literal> feature at all, or does not allow enabling or disabling it.)
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v249"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--fido2-with-user-verification=</option><replaceable>BOOL</replaceable></term>
+
+        <listitem><para>When enrolling a FIDO2 security token, controls whether to require user verification
+        when unlocking the volume (the FIDO2 <literal>uv</literal> feature). Defaults to
+        <literal>no</literal>. (Note: this setting is without effect if the security token does not support
+        the <literal>uv</literal> feature at all, or does not allow enabling or disabling it.)</para>
+
+        <xi:include href="version-info.xml" xpointer="v249"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--tpm2-device=</option><replaceable>PATH</replaceable></term>
+
+        <listitem><para>Enroll a TPM2 security chip. Expects a device node path referring to the TPM2 chip
+        (e.g. <filename>/dev/tpmrm0</filename>). Alternatively the special value <literal>auto</literal> may
+        be specified, in order to automatically determine the device node of a currently discovered TPM2
+        device (of which there must be exactly one). The special value <literal>list</literal> may be used to
+        enumerate all suitable TPM2 devices currently discovered.</para>
+
+        <para>In order to unlock a LUKS2 volume with an enrolled TPM2 security chip, specify the
+        <option>tpm2-device=</option> option in the respective <filename>/etc/crypttab</filename> line:</para>
+
+        <programlisting>myvolume /dev/sda1 - tpm2-device=auto</programlisting>
+
+        <para>See
+        <citerefentry><refentrytitle>crypttab</refentrytitle><manvolnum>5</manvolnum></citerefentry> for a
+        more comprehensive example of a <command>systemd-cryptenroll</command> invocation and its matching
+        <filename>/etc/crypttab</filename> line.</para>
+
+        <para>Use <option>--tpm2-pcrs=</option> (see below) to configure which TPM2 PCR indexes to bind the
+        enrollment to.</para>
+
+        <xi:include href="version-info.xml" xpointer="v248"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--tpm2-device-key=</option><replaceable>PATH</replaceable></term>
+
+        <listitem><para>Enroll a TPM2 security chip using its public key. Expects a path referring to the
+        TPM2 public key in TPM2B_PUBLIC format. This cannot be used with <option>--tpm2-device=</option>, as
+        it performs the same operation, but without connecting to the TPM2 security chip; instead the
+        enrollment is calculated using the provided TPM2 key. This is useful in situations where the TPM2
+        security chip is not available at the time of enrollment.</para>
+
+        <para>The key, in most cases, should be the Storage Root Key (SRK) from a local TPM2 security
+        chip. If a key from a different handle (not the SRK) is used, you must specify its handle index using
+        <option>--tpm2-seal-key-handle=</option>.</para>
+
+        <para>The
+        <citerefentry><refentrytitle>systemd-tpm2-setup.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        service writes the SRK to <filename>/run/systemd/tpm2-srk-public-key.tpm2b_public</filename>
+        automatically during boot, in the correct format.</para>
+
+        <para>Alternatively, you may use <command>systemd-analyze srk</command> to retrieve the SRK from the
+        TPM2 security chip explicitly. See
+        <citerefentry><refentrytitle>systemd-analyze</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+        for details. Example:</para>
+
+        <programlisting>systemd-analyze srk &gt; srk.tpm2b_public</programlisting>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--tpm2-seal-key-handle=</option><replaceable>HANDLE</replaceable></term>
+
+        <listitem><para>Configures which parent key to use for sealing, using the TPM handle (index) of the
+        key. This is used to "seal" (encrypt) a secret and must be used later to "unseal" (decrypt) the
+        secret. Expects a hexadecimal 32bit integer, optionally prefixed with
+        <literal>0x</literal>. Allowable values are any handle index in the persistent
+        (<literal>0x81000000</literal>-<literal>0x81ffffff</literal>) or transient
+        (<literal>0x80000000</literal>-<literal>0x80ffffff</literal>) ranges. Since transient handles are
+        lost after a TPM reset, and may be flushed during TPM context switching, they should not be used
+        except for very specific use cases, e.g. testing.</para>
+
+        <para>The default is the Storage Root Key (SRK) handle index <literal>0x81000001</literal>. A value
+        of 0 will use the default. For the SRK handle, a new key will be created and stored in the TPM if one
+        does not already exist; for any other handle, the key must already exist in the TPM at the specified
+        handle index.</para>
+
+        <para>This should not be changed unless you know what you are doing.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--tpm2-pcrs=</option><arg rep="repeat">PCR</arg></term>
+
+        <listitem><para>Configures the TPM2 PCRs (Platform Configuration Registers) to bind to when
+        enrollment is requested via <option>--tpm2-device=</option>. Takes a list of PCR entries, where each
+        entry starts with a name or numeric index in the range 0…23, optionally followed by
+        <literal>:</literal> and a hash algorithm name (specifying the PCR bank), optionally followed by
+        <literal>=</literal> and a hash digest value. Multiple PCR entries are separated by
+        <literal>+</literal>. If not specified, the default is to use PCR 7 only. If an empty string is
+        specified, binds the enrollment to no PCRs at all. See the table above for a list of available
+        PCRs.</para>
+
+        <para>Example: <option>--tpm2-pcrs=boot-loader-code+platform-config+boot-loader-config</option>
+        specifies that PCR registers 4, 1, and 5 should be used.</para>
+        <para>Example: <option>--tpm2-pcrs=7:sha256</option> specifies that PCR register 7 from the SHA256
+        bank should be used.</para>
+        <para>Example: <option>--tpm2-pcrs=4:sha1=3a3f780f11a4b49969fcaa80cd6e3957c33b2275</option>
+        specifies that PCR register 4 from the SHA1 bank should be used, and a hash digest value of
+        3a3f780f11a4b49969fcaa80cd6e3957c33b2275 will be used instead of reading the current PCR
+        value.</para>
+
+        <xi:include href="version-info.xml" xpointer="v248"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--tpm2-with-pin=</option><replaceable>BOOL</replaceable></term>
+
+        <listitem><para>When enrolling a TPM2 device, controls whether to require the user to enter a PIN
+        when unlocking the volume in addition to PCR binding, based on TPM2 policy authentication. Defaults
+        to <literal>no</literal>. Despite being called PIN, any character can be used, not just numbers.
+        </para>
+
+        <para>Note that incorrect PIN entry when unlocking increments the TPM dictionary attack lockout
+        mechanism, and may lock out users for a prolonged time, depending on its configuration. The lockout
+        mechanism is a global property of the TPM, <command>systemd-cryptenroll</command> does not control or
+        configure the lockout mechanism. You may use tpm2-tss tools to inspect or configure the dictionary
+        attack lockout, with <citerefentry
+        project='mankier'><refentrytitle>tpm2_getcap</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+        and <citerefentry
+        project='mankier'><refentrytitle>tpm2_dictionarylockout</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+        commands, respectively.</para>
+
+        <xi:include href="version-info.xml" xpointer="v251"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--tpm2-public-key=</option><arg>PATH</arg></term>
+        <term><option>--tpm2-public-key-pcrs=</option><arg rep="repeat">PCR</arg></term>
+        <term><option>--tpm2-signature=</option><arg>PATH</arg></term>
+
+        <listitem><para>Configures a TPM2 signed PCR policy to bind encryption to. The
+        <option>--tpm2-public-key=</option> option accepts a path to a PEM encoded RSA public key, to bind
+        the encryption to. If this is not specified explicitly, but a file
+        <filename>tpm2-pcr-public-key.pem</filename> exists in one of the directories
+        <filename>/etc/systemd/</filename>, <filename>/run/systemd/</filename>,
+        <filename>/usr/lib/systemd/</filename> (searched in this order), it is automatically used. The
+        <option>--tpm2-public-key-pcrs=</option> option takes a list of TPM2 PCR indexes to bind to (same
+        syntax as <option>--tpm2-pcrs=</option> described above). If not specified defaults to 11 (i.e. this
+        binds the policy to any unified kernel image for which a PCR signature can be provided).</para>
+
+        <para>Note the difference between <option>--tpm2-pcrs=</option> and
+        <option>--tpm2-public-key-pcrs=</option>: the former binds decryption to the current, specific PCR
+        values; the latter binds decryption to any set of PCR values for which a signature by the specified
+        public key can be provided. The latter is hence more useful in scenarios where software updates shell
+        be possible without losing access to all previously encrypted LUKS2 volumes. Like with
+        <option>--tpm2-pcrs=</option>, names defined in the table above can also be used to specify the
+        registers, for instance
+        <option>--tpm2-public-key-pcrs=boot-loader-code+system-identity</option>.</para>
+
+        <para>The <option>--tpm2-signature=</option> option takes a path to a TPM2 PCR signature file as
+        generated by the
+        <citerefentry><refentrytitle>systemd-measure</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+        tool. If this is not specified explicitly, a suitable signature file
+        <filename>tpm2-pcr-signature.json</filename> is searched for in <filename>/etc/systemd/</filename>,
+        <filename>/run/systemd/</filename>, <filename>/usr/lib/systemd/</filename> (in this order) and used.
+        If a signature file is specified or found it is used to verify if the volume can be unlocked with it
+        given the current PCR state, before the new slot is written to disk. This is intended as safety net
+        to ensure that access to a volume is not lost if a public key is enrolled for which no valid
+        signature for the current PCR state is available. If the supplied signature does not unlock the
+        current PCR state and public key combination, no slot is enrolled and the operation will fail. If no
+        signature file is specified or found no such safety verification is done.</para>
+
+        <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--tpm2-pcrlock=</option><arg>PATH</arg></term>
+
+        <listitem><para>Configures a TPM2 pcrlock policy to bind encryption to. Expects a path to a pcrlock
+        policy file as generated by the
+        <citerefentry><refentrytitle>systemd-pcrlock</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+        tool. If a TPM2 device is enrolled and this option is not used but a file
+        <filename>pcrlock.json</filename> is found in <filename>/run/systemd/</filename> or
+        <filename>/var/lib/systemd/</filename> it is automatically used. Assign an empty string to turn this
+        behaviour off.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--wipe-slot=</option><arg rep="repeat">SLOT</arg></term>
+
+        <listitem><para>Wipes one or more LUKS2 key slots. Takes a comma separated list of numeric slot
+        indexes, or the special strings <literal>all</literal> (for wiping all key slots),
+        <literal>empty</literal> (for wiping all key slots that are unlocked by an empty passphrase),
+        <literal>password</literal> (for wiping all key slots that are unlocked by a traditional passphrase),
+        <literal>recovery</literal> (for wiping all key slots that are unlocked by a recovery key),
+        <literal>pkcs11</literal> (for wiping all key slots that are unlocked by a PKCS#11 token),
+        <literal>fido2</literal> (for wiping all key slots that are unlocked by a FIDO2 token),
+        <literal>tpm2</literal> (for wiping all key slots that are unlocked by a TPM2 chip), or any
+        combination of these strings or numeric indexes, in which case all slots matching either are
+        wiped. As safety precaution an operation that wipes all slots without exception (so that the volume
+        cannot be unlocked at all anymore, unless the volume key is known) is refused.</para>
+
+        <para>This switch may be used alone, in which case only the requested wipe operation is executed. It
+        may also be used in combination with any of the enrollment options listed above, in which case the
+        enrollment is completed first, and only when successful the wipe operation executed — and the newly
+        added slot is always excluded from the wiping. Combining enrollment and slot wiping may thus be used to
+        update existing enrollments:</para>
+
+        <programlisting>systemd-cryptenroll /dev/sda1 --wipe-slot=tpm2 --tpm2-device=auto</programlisting>
+
+        <para>The above command will enroll the TPM2 chip, and then wipe all previously created TPM2
+        enrollments on the LUKS2 volume, leaving only the newly created one. Combining wiping and enrollment
+        may also be used to replace enrollments of different types, for example for changing from a PKCS#11
+        enrollment to a FIDO2 one:</para>
+
+        <programlisting>systemd-cryptenroll /dev/sda1 --wipe-slot=pkcs11 --fido2-device=auto</programlisting>
+
+        <para>Or for replacing an enrolled empty password by TPM2:</para>
+
+        <programlisting>systemd-cryptenroll /dev/sda1 --wipe-slot=empty --tpm2-device=auto</programlisting>
+
+        <xi:include href="version-info.xml" xpointer="v248"/>
+        </listitem>
+      </varlistentry>
+
+      <xi:include href="standard-options.xml" xpointer="help" />
+      <xi:include href="standard-options.xml" xpointer="version" />
+    </variablelist>
+
+  </refsect1>
+
+  <refsect1>
+    <title>Exit status</title>
+
+    <para>On success, 0 is returned, a non-zero failure code otherwise.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Examples</title>
+
+    <para><citerefentry><refentrytitle>crypttab</refentrytitle><manvolnum>5</manvolnum></citerefentry> and
+    <citerefentry><refentrytitle>systemd-measure</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    contain various examples employing <command>systemd-cryptenroll</command>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-cryptsetup@.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>crypttab</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry project='die-net'><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-measure</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+     </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-cryptsetup-generator.xml b/man/systemd-cryptsetup-generator.xml
new file mode 100644
index 0000000..43f6363
--- /dev/null
+++ b/man/systemd-cryptsetup-generator.xml
@@ -0,0 +1,239 @@
+<?xml version="1.0"?>
+<!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+<refentry id="systemd-cryptsetup-generator" conditional='HAVE_LIBCRYPTSETUP'
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd-cryptsetup-generator</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-cryptsetup-generator</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-cryptsetup-generator</refname>
+    <refpurpose>Unit generator for <filename>/etc/crypttab</filename></refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>/usr/lib/systemd/system-generators/systemd-cryptsetup-generator</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><filename>systemd-cryptsetup-generator</filename> is a
+    generator that translates <filename>/etc/crypttab</filename> into
+    native systemd units early at boot and when configuration of the
+    system manager is reloaded. This will create
+    <citerefentry><refentrytitle>systemd-cryptsetup@.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    units as necessary.</para>
+
+    <para><filename>systemd-cryptsetup-generator</filename> implements
+    <citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Kernel Command Line</title>
+
+    <para><filename>systemd-cryptsetup-generator</filename>
+    understands the following kernel command line parameters:</para>
+
+    <variablelist class='kernel-commandline-options'>
+      <varlistentry>
+        <term><varname>luks=</varname></term>
+        <term><varname>rd.luks=</varname></term>
+
+        <listitem><para>Takes a boolean argument. Defaults to <literal>yes</literal>. If
+        <literal>no</literal>, disables the generator entirely. <varname>rd.luks=</varname> is honored only
+        in the initrd while <varname>luks=</varname> is honored by both the main system and in the initrd.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v186"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>luks.crypttab=</varname></term>
+        <term><varname>rd.luks.crypttab=</varname></term>
+
+        <listitem><para>Takes a boolean argument. Defaults to <literal>yes</literal>. If
+        <literal>no</literal>, causes the generator to ignore any devices configured in
+        <filename>/etc/crypttab</filename> (<varname>luks.uuid=</varname> will still work however).
+        <varname>rd.luks.crypttab=</varname> is honored only in initrd while
+        <varname>luks.crypttab=</varname> is honored by both the main system and in the initrd.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v186"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>luks.uuid=</varname></term>
+        <term><varname>rd.luks.uuid=</varname></term>
+
+        <listitem><para>Takes a LUKS superblock UUID as argument. This will activate the specified device as
+        part of the boot process as if it was listed in <filename>/etc/crypttab</filename>. This option may
+        be specified more than once in order to set up multiple devices. <varname>rd.luks.uuid=</varname> is
+        honored only in the initrd, while <varname>luks.uuid=</varname> is honored by both the main system
+        and in the initrd.</para>
+
+        <para>If <filename>/etc/crypttab</filename> contains entries with the same UUID, then the name,
+        keyfile and options specified there will be used. Otherwise, the device will have the name
+        <literal>luks-UUID</literal>.</para>
+
+        <para>If <filename>/etc/crypttab</filename> exists, only those UUIDs specified on the kernel command
+        line will be activated in the initrd or the real root.</para>
+
+        <xi:include href="version-info.xml" xpointer="v186"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>luks.name=</varname></term>
+        <term><varname>rd.luks.name=</varname></term>
+
+        <listitem><para>Takes a LUKS super block UUID followed by an
+        <literal>=</literal> and a name. This implies
+        <varname>rd.luks.uuid=</varname> or
+        <varname>luks.uuid=</varname> and will additionally make the
+        LUKS device given by the UUID appear under the provided
+        name.</para>
+
+        <para>This parameter is the analogue of the first <citerefentry><refentrytitle>crypttab</refentrytitle>
+        <manvolnum>5</manvolnum></citerefentry> field <replaceable>volume-name</replaceable>.</para>
+
+        <para><varname>rd.luks.name=</varname> is honored only in the initrd, while
+        <varname>luks.name=</varname> is honored by both the main system and in the initrd.</para>
+
+        <xi:include href="version-info.xml" xpointer="v218"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>luks.data=</varname></term>
+        <term><varname>rd.luks.data=</varname></term>
+
+        <listitem><para>Takes a LUKS super block UUID followed by a <literal>=</literal> and a block device
+        specification for device hosting encrypted data.</para>
+
+        <para>For those entries specified with <varname>rd.luks.uuid=</varname> or
+        <varname>luks.uuid=</varname>, the data device will be set to the one specified by
+        <varname>rd.luks.data=</varname> or <varname>luks.data=</varname> of the corresponding UUID.</para>
+
+        <para>LUKS data device parameter is useful for specifying encrypted data devices with detached headers specified in
+        <varname>luks.options</varname> entry containing <literal>header=</literal> argument. For example,
+        <varname>rd.luks.uuid=</varname>b40f1abf-2a53-400a-889a-2eccc27eaa40
+        <varname>rd.luks.options=</varname>b40f1abf-2a53-400a-889a-2eccc27eaa40=header=/path/to/luks.hdr
+        <varname>rd.luks.data=</varname>b40f1abf-2a53-400a-889a-2eccc27eaa40=/dev/sdx.
+        Hence, in this case, we will attempt to unlock LUKS device assembled from data device <literal>/dev/sdx</literal>
+        and LUKS header (metadata) put in <literal>/path/to/luks.hdr</literal> file. This syntax is for now
+        only supported on a per-device basis, i.e. you have to specify LUKS device UUID.</para>
+
+        <para>This parameter is the analogue of the second <citerefentry><refentrytitle>crypttab</refentrytitle>
+        <manvolnum>5</manvolnum></citerefentry> field <replaceable>encrypted-device</replaceable>.</para>
+
+        <para><varname>rd.luks.data=</varname> is honored only in the initrd, while
+        <varname>luks.data=</varname> is honored by both the main system and in the initrd.</para>
+
+        <xi:include href="version-info.xml" xpointer="v247"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>luks.key=</varname></term>
+        <term><varname>rd.luks.key=</varname></term>
+
+        <listitem><para>Takes a password file name as argument or a
+        LUKS super block UUID followed by a <literal>=</literal> and a
+        password file name.</para>
+
+        <para>For those entries specified with
+        <varname>rd.luks.uuid=</varname> or
+        <varname>luks.uuid=</varname>, the password file will be set
+        to the one specified by <varname>rd.luks.key=</varname> or
+        <varname>luks.key=</varname> of the corresponding UUID, or the
+        password file that was specified without a UUID.</para>
+
+        <para>It is also possible to specify an external device which
+        should be mounted before we attempt to unlock the LUKS device.
+        systemd-cryptsetup will use password file stored on that
+        device. Device containing password file is specified by
+        appending colon and a device identifier to the password file
+        path. For example,
+        <varname>rd.luks.uuid=</varname>b40f1abf-2a53-400a-889a-2eccc27eaa40
+        <varname>rd.luks.key=</varname>b40f1abf-2a53-400a-889a-2eccc27eaa40=/keyfile:LABEL=keydev.
+        Hence, in this case, we will attempt to mount file system
+        residing on the block device with label <literal>keydev</literal>.
+        This syntax is for now only supported on a per-device basis,
+        i.e. you have to specify LUKS device UUID.</para>
+
+        <para>This parameter is the analogue of the third <citerefentry><refentrytitle>crypttab</refentrytitle>
+        <manvolnum>5</manvolnum></citerefentry> field <replaceable>key-file</replaceable>.</para>
+
+        <para><varname>rd.luks.key=</varname> is honored only in the initrd, while
+        <varname>luks.key=</varname> is honored by both the main system and in the initrd.</para>
+
+        <xi:include href="version-info.xml" xpointer="v202"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>luks.options=</varname></term>
+        <term><varname>rd.luks.options=</varname></term>
+
+        <listitem><para>Takes a LUKS super block UUID followed by an
+        <literal>=</literal> and a string of options separated by
+        commas as argument. This will override the options for the
+        given UUID.</para>
+        <para>If only a list of options, without a UUID, is
+        specified, they apply to any UUIDs not specified elsewhere,
+        and without an entry in
+        <filename>/etc/crypttab</filename>.</para>
+
+        <para>This parameter is the analogue of the fourth <citerefentry><refentrytitle>crypttab</refentrytitle>
+        <manvolnum>5</manvolnum></citerefentry> field <replaceable>options</replaceable>.</para>
+
+        <para>It is possible to specify an external device which
+        should be mounted before we attempt to unlock the LUKS device.
+        systemd-cryptsetup will assemble LUKS device by combining
+        data device specified in <varname>luks.data</varname> with
+        detached LUKS header found in <literal>header=</literal>
+        argument. For example,
+        <varname>rd.luks.uuid=</varname>b40f1abf-2a53-400a-889a-2eccc27eaa40
+        <varname>rd.luks.options=</varname>b40f1abf-2a53-400a-889a-2eccc27eaa40=header=/luks.hdr:LABEL=hdrdev
+        <varname>rd.luks.data=</varname>b40f1abf-2a53-400a-889a-2eccc27eaa40=/dev/sdx.
+        Hence, in this case, we will attempt to mount file system
+        residing on the block device with label <literal>hdrdev</literal>, and look
+        for <literal>luks.hdr</literal> on that file system. Said header will be used
+        to unlock (decrypt) encrypted data stored on /dev/sdx.
+        This syntax is for now only supported on a per-device basis,
+        i.e. you have to specify LUKS device UUID.</para>
+
+        <para><varname>rd.luks.options=</varname> is honored only by initial
+        RAM disk (initrd) while <varname>luks.options=</varname> is
+        honored by both the main system and in the initrd.</para>
+
+        <xi:include href="version-info.xml" xpointer="v208"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>crypttab</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-cryptsetup@.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-cryptenroll</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry project='die-net'><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-cryptsetup.xml b/man/systemd-cryptsetup.xml
new file mode 100644
index 0000000..1d3a313
--- /dev/null
+++ b/man/systemd-cryptsetup.xml
@@ -0,0 +1,119 @@
+<?xml version="1.0"?>
+<!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+<refentry id="systemd-cryptsetup" conditional='HAVE_LIBCRYPTSETUP'>
+
+  <refentryinfo>
+    <title>systemd-cryptsetup</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-cryptsetup</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-cryptsetup</refname>
+    <refname>systemd-cryptsetup@.service</refname>
+    <!-- <refname>system-systemd\x2dcryptsetup.slice</refname> — this causes meson to go haywire because it
+         thinks this is a (windows) path. Let's just not create the alias for this name, and only include it
+         in the synopsis. -->
+    <refpurpose>Full disk decryption logic</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <cmdsynopsis>
+      <command>systemd-cryptsetup</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="plain">attach</arg>
+      <arg choice="plain">VOLUME</arg>
+      <arg choice="plain">SOURCE-DEVICE</arg>
+      <arg choice="opt">KEY-FILE</arg>
+      <arg choice="opt">CONFIG</arg>
+    </cmdsynopsis>
+
+    <cmdsynopsis>
+      <command>systemd-cryptsetup</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="plain">detach</arg>
+      <arg choice="plain">VOLUME</arg>
+    </cmdsynopsis>
+
+    <para><filename>systemd-cryptsetup@.service</filename></para>
+    <para><filename>system-systemd\x2dcryptsetup.slice</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><filename>systemd-cryptsetup</filename> is used to set up (with <command>attach</command>) and tear
+    down (with <command>detach</command>) access to an encrypted block device. It is primarily used via
+    <filename>systemd-cryptsetup@.service</filename> during early boot, but may also be be called manually.
+    The positional arguments <parameter>VOLUME</parameter>, <parameter>SOURCEDEVICE</parameter>,
+    <parameter>KEY-FILE</parameter>, and <parameter>CRYPTTAB-OPTIONS</parameter> have the same meaning as the
+    fields in <citerefentry><refentrytitle>crypttab</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+    </para>
+
+    <para><filename>systemd-cryptsetup@.service</filename> is a service responsible for providing access to
+    encrypted block devices. It is instantiated for each device that requires decryption.</para>
+
+    <para><filename>systemd-cryptsetup@.service</filename> instances are part of the
+    <filename>system-systemd\x2dcryptsetup.slice</filename> slice, which is destroyed only very late in the
+    shutdown procedure. This allows the encrypted devices to remain up until filesystems have been unmounted.
+    </para>
+
+    <para><filename>systemd-cryptsetup@.service</filename> will ask
+    for hard disk passwords via the <ulink
+    url="https://systemd.io/PASSWORD_AGENTS/">password agent logic</ulink>, in
+    order to query the user for the password using the right mechanism at boot
+    and during runtime.</para>
+
+    <para>At early boot and when the system manager configuration is reloaded, <filename>/etc/crypttab</filename> is
+    translated into <filename>systemd-cryptsetup@.service</filename> units by
+    <citerefentry><refentrytitle>systemd-cryptsetup-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
+
+    <para>In order to unlock a volume a password or binary key is required.
+    <filename>systemd-cryptsetup@.service</filename> tries to acquire a suitable password or binary key via
+    the following mechanisms, tried in order:</para>
+
+    <orderedlist>
+      <listitem><para>If a key file is explicitly configured (via the third column in
+      <filename>/etc/crypttab</filename>), a key read from it is used. If a PKCS#11 token, FIDO2 token or
+      TPM2 device is configured (using the <varname>pkcs11-uri=</varname>, <varname>fido2-device=</varname>,
+      <varname>tpm2-device=</varname> options) the key is decrypted before use.</para></listitem>
+
+      <listitem><para>If no key file is configured explicitly this way, a key file is automatically loaded
+      from <filename>/etc/cryptsetup-keys.d/<replaceable>volume</replaceable>.key</filename> and
+      <filename>/run/cryptsetup-keys.d/<replaceable>volume</replaceable>.key</filename>, if present. Here
+      too, if a PKCS#11/FIDO2/TPM2 token/device is configured, any key found this way is decrypted before
+      use.</para></listitem>
+
+      <listitem><para>If the <varname>try-empty-password</varname> option is specified then unlocking the
+      volume with an empty password is attempted.</para></listitem>
+
+      <listitem><para>The kernel keyring is then checked for a suitable cached password from previous
+      attempts.</para></listitem>
+
+      <listitem><para>Finally, the user is queried for a password, possibly multiple times, unless
+      the <varname>headless</varname> option is set.</para></listitem>
+    </orderedlist>
+
+    <para>If no suitable key may be acquired via any of the mechanisms describes above, volume activation fails.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-cryptsetup-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>crypttab</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-cryptenroll</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry project='die-net'><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <ulink url="https://systemd.io/TPM2_PCR_MEASUREMENTS">TPM2 PCR Measurements Made by systemd</ulink>
+     </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-debug-generator.xml b/man/systemd-debug-generator.xml
new file mode 100644
index 0000000..65de9ca
--- /dev/null
+++ b/man/systemd-debug-generator.xml
@@ -0,0 +1,85 @@
+<?xml version="1.0"?>
+<!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [
+<!ENTITY % entities SYSTEM "custom-entities.ent" >
+%entities;
+]>
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+<refentry id="systemd-debug-generator">
+
+  <refentryinfo>
+    <title>systemd-debug-generator</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-debug-generator</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-debug-generator</refname>
+    <refpurpose>Generator for enabling a runtime debug shell and
+    masking specific units at boot</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>/usr/lib/systemd/system-generators/systemd-debug-generator</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><filename>systemd-debug-generator</filename> is a generator
+    that reads the kernel command line and understands three
+    options:</para>
+
+    <para>If the <option>systemd.mask=</option> or <option>rd.systemd.mask=</option>
+    option is specified and followed by a unit name, this unit is
+    masked for the runtime (i.e. for this session — from boot to shutdown), similarly to the effect of
+    <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s
+    <command>mask</command> command. This is useful to boot with
+    certain units removed from the initial boot transaction for
+    debugging system startup. May be specified more than once.
+    <option>rd.systemd.mask=</option> is honored only by initial
+    RAM disk (initrd) while <option>systemd.mask=</option> is
+    honored only in the main system.</para>
+
+    <para>If the <option>systemd.wants=</option> or
+    <option>rd.systemd.wants=</option> option is specified
+    and followed by a unit name, a start job for this unit is added to
+    the initial transaction. This is useful to start one or more
+    additional units at boot. May be specified more than once.
+    <option>rd.systemd.wants=</option> is honored only by initial
+    RAM disk (initrd) while <option>systemd.wants=</option> is
+    honored only in the main system.</para>
+
+    <para>If the <option>systemd.debug_shell</option> or
+    <option>rd.systemd.debug_shell</option> option is
+    specified, the debug shell service
+    <literal>debug-shell.service</literal> is pulled into the boot
+    transaction and a debug shell will be spawned during early boot.
+    By default, <filename>&DEBUGTTY;</filename> is used, but a specific tty can also be set,
+    either with or without the <filename>/dev/</filename> prefix.
+    Note that the shell may also be turned on persistently by enabling it with
+    <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s
+    <command>enable</command> command.
+    <option>rd.systemd.debug_shell=</option> is honored only by initial
+    RAM disk (initrd) while <option>systemd.debug_shell</option> is
+    honored only in the main system.</para>
+
+    <para><filename>systemd-debug-generator</filename> implements
+    <citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>kernel-command-line</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-delta.xml b/man/systemd-delta.xml
new file mode 100644
index 0000000..dd72061
--- /dev/null
+++ b/man/systemd-delta.xml
@@ -0,0 +1,180 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd-delta"
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd-delta</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-delta</refentrytitle>
+    <manvolnum>1</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-delta</refname>
+    <refpurpose>Find overridden configuration files</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <cmdsynopsis>
+      <command>systemd-delta</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="opt" rep="repeat"><replaceable>PREFIX</replaceable><optional>/<replaceable>SUFFIX</replaceable></optional>|<replaceable>SUFFIX</replaceable></arg>
+    </cmdsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>systemd-delta</command> may be used to identify and
+    compare configuration files that override other configuration
+    files. Files in <filename>/etc/</filename> have highest priority,
+    files in <filename>/run/</filename> have the second highest
+    priority, …, files in <filename>/usr/lib/</filename> have lowest
+    priority. Files in a directory with higher priority override files
+    with the same name in directories of lower priority. In addition,
+    certain configuration files can have <literal>.d</literal>
+    directories which contain "drop-in" files with configuration
+    snippets which augment the main configuration file. "Drop-in"
+    files can be overridden in the same way by placing files with the
+    same name in a directory of higher priority (except that, in case
+    of "drop-in" files, both the "drop-in" file name and the name of
+    the containing directory, which corresponds to the name of the
+    main configuration file, must match). For a fuller explanation,
+    see
+    <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+    </para>
+
+    <para>The command line argument will be split into a prefix and a
+    suffix. Either is optional. The prefix must be one of the
+    directories containing configuration files
+    (<filename>/etc/</filename>, <filename>/run/</filename>,
+    <filename>/usr/lib/</filename>, …). If it is given, only
+    overriding files contained in this directory will be shown.
+    Otherwise, all overriding files will be shown. The suffix must be
+    a name of a subdirectory containing configuration files like
+    <filename>tmpfiles.d</filename>, <filename>sysctl.d</filename> or
+    <filename>systemd/system</filename>. If it is given, only
+    configuration files in this subdirectory (across all configuration
+    paths) will be analyzed. Otherwise, all configuration files will
+    be analyzed. If the command line argument is not given at all, all
+    configuration files will be analyzed. See below for some
+    examples.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>The following options are understood:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><option>-t</option></term>
+        <term><option>--type=</option></term>
+
+        <listitem><para>When listing the differences, only list those
+        that are asked for. The list itself is a comma-separated list
+        of desired difference types.</para>
+
+        <para>Recognized types are:
+
+          <variablelist>
+            <varlistentry>
+              <term><varname>masked</varname></term>
+
+              <listitem><para>Show masked files</para></listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><varname>equivalent</varname></term>
+
+              <listitem><para>Show overridden files that while
+              overridden, do not differ in content.</para></listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><varname>redirected</varname></term>
+
+              <listitem><para>Show files that are redirected to
+              another.</para></listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><varname>overridden</varname></term>
+
+              <listitem><para>Show overridden, and changed
+              files.</para></listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><varname>extended</varname></term>
+
+              <listitem><para>Show <filename>*.conf</filename> files
+              in drop-in directories for units.</para>
+
+              <xi:include href="version-info.xml" xpointer="v205"/></listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><varname>unchanged</varname></term>
+
+              <listitem><para>Show unmodified files
+              too.</para></listitem>
+            </varlistentry>
+          </variablelist>
+        </para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--diff=</option></term>
+
+        <listitem><para>When showing modified files, when a file is
+        overridden show a diff as well. This option takes a boolean
+        argument. If omitted, it defaults to
+        <option>true</option>.</para></listitem>
+      </varlistentry>
+
+      <xi:include href="standard-options.xml" xpointer="help" />
+      <xi:include href="standard-options.xml" xpointer="version" />
+      <xi:include href="standard-options.xml" xpointer="no-pager" />
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Examples</title>
+
+    <para>To see all local configuration:</para>
+    <programlisting>systemd-delta</programlisting>
+
+    <para>To see all runtime configuration:</para>
+    <programlisting>systemd-delta /run</programlisting>
+
+    <para>To see all system unit configuration changes:</para>
+    <programlisting>systemd-delta systemd/system</programlisting>
+
+    <para>To see all runtime "drop-in" changes for system units:</para>
+    <programlisting>systemd-delta --type=extended /run/systemd/system</programlisting>
+  </refsect1>
+
+  <refsect1>
+    <title>Exit status</title>
+
+    <para>On success, 0 is returned, a non-zero failure code
+    otherwise.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-detect-virt.xml b/man/systemd-detect-virt.xml
new file mode 100644
index 0000000..e1caa4f
--- /dev/null
+++ b/man/systemd-detect-virt.xml
@@ -0,0 +1,328 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd-detect-virt"
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd-detect-virt</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-detect-virt</refentrytitle>
+    <manvolnum>1</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-detect-virt</refname>
+    <refpurpose>Detect execution in a virtualized environment</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <cmdsynopsis>
+      <command>systemd-detect-virt</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+    </cmdsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>systemd-detect-virt</command> detects execution in
+    a virtualized environment. It identifies the virtualization
+    technology and can distinguish full machine virtualization from
+    container virtualization. <filename>systemd-detect-virt</filename>
+    exits with a return value of 0 (success) if a virtualization
+    technology is detected, and non-zero (error) otherwise. By default,
+    any type of virtualization is detected, and the options
+    <option>--container</option> and <option>--vm</option> can be used
+    to limit what types of virtualization are detected.</para>
+
+    <para>When executed without <option>--quiet</option> will print a
+    short identifier for the detected virtualization technology. The
+    following technologies are currently identified:</para>
+
+    <table>
+      <title>Known virtualization technologies (both
+      VM, i.e. full hardware virtualization,
+      and container, i.e. shared kernel virtualization)</title>
+      <tgroup cols='3' align='left' colsep='1' rowsep='1'>
+        <colspec colname="type" />
+        <colspec colname="id" />
+        <colspec colname="product" />
+        <thead>
+          <row>
+            <entry>Type</entry>
+            <entry>ID</entry>
+            <entry>Product</entry>
+          </row>
+        </thead>
+        <tbody>
+          <row>
+            <entry valign="top" morerows="16">VM</entry>
+            <entry><varname>qemu</varname></entry>
+            <entry>QEMU software virtualization, without KVM</entry>
+          </row>
+
+          <row>
+            <entry><varname>kvm</varname></entry>
+            <entry>Linux KVM kernel virtual machine, in combination with QEMU. Not used for other virtualizers using the KVM interfaces, such as Oracle VirtualBox or Amazon EC2 Nitro, see below.</entry>
+          </row>
+
+          <row>
+            <entry><varname>amazon</varname></entry>
+            <entry>Amazon EC2 Nitro using Linux KVM</entry>
+          </row>
+
+          <row>
+            <entry><varname>zvm</varname></entry>
+            <entry>s390 z/VM</entry>
+          </row>
+
+          <row>
+            <entry><varname>vmware</varname></entry>
+            <entry>VMware Workstation or Server, and related products</entry>
+          </row>
+
+          <row>
+            <entry><varname>microsoft</varname></entry>
+            <entry>Hyper-V, also known as Viridian or Windows Server Virtualization</entry>
+          </row>
+
+          <row>
+            <entry><varname>oracle</varname></entry>
+            <entry>Oracle VM VirtualBox (historically marketed by innotek and Sun Microsystems), for legacy and KVM hypervisor</entry>
+          </row>
+
+          <row>
+            <entry><varname>powervm</varname></entry>
+            <entry>IBM PowerVM hypervisor — comes as firmware with some IBM POWER servers</entry>
+          </row>
+
+          <row>
+            <entry><varname>xen</varname></entry>
+            <entry>Xen hypervisor (only domU, not dom0)</entry>
+          </row>
+
+          <row>
+            <entry><varname>bochs</varname></entry>
+            <entry>Bochs Emulator</entry>
+          </row>
+
+          <row>
+            <entry><varname>uml</varname></entry>
+            <entry>User-mode Linux</entry>
+          </row>
+
+          <row>
+            <entry><varname>parallels</varname></entry>
+            <entry>Parallels Desktop, Parallels Server</entry>
+          </row>
+
+          <row>
+            <entry><varname>bhyve</varname></entry>
+            <entry>bhyve, FreeBSD hypervisor</entry>
+          </row>
+
+          <row>
+            <entry><varname>qnx</varname></entry>
+            <entry>QNX hypervisor</entry>
+          </row>
+
+          <row>
+            <entry><varname>acrn</varname></entry>
+            <entry><ulink url="https://projectacrn.org">ACRN hypervisor</ulink></entry>
+          </row>
+
+          <row>
+            <entry><varname>apple</varname></entry>
+            <entry><ulink url="https://developer.apple.com/documentation/virtualization">Apple virtualization framework</ulink></entry>
+          </row>
+
+          <row>
+            <entry><varname>sre</varname></entry>
+            <entry><ulink url="https://www.lockheedmartin.com/en-us/products/Hardened-Security-for-Intel-Processors.html">LMHS SRE hypervisor</ulink></entry>
+          </row>
+
+          <row>
+            <entry><varname>google</varname></entry>
+            <entry><ulink url="https://cloud.google.com/compute">Google Compute Engine</ulink></entry>
+          </row>
+
+          <row>
+            <entry valign="top" morerows="9">Container</entry>
+            <entry><varname>openvz</varname></entry>
+            <entry>OpenVZ/Virtuozzo</entry>
+          </row>
+
+          <row>
+            <entry><varname>lxc</varname></entry>
+            <entry>Linux container implementation by LXC</entry>
+          </row>
+
+          <row>
+            <entry><varname>lxc-libvirt</varname></entry>
+            <entry>Linux container implementation by libvirt</entry>
+          </row>
+
+          <row>
+            <entry><varname>systemd-nspawn</varname></entry>
+            <entry>systemd's minimal container implementation, see <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry></entry>
+          </row>
+
+          <row>
+            <entry><varname>docker</varname></entry>
+            <entry>Docker container manager</entry>
+          </row>
+
+          <row>
+            <entry><varname>podman</varname></entry>
+            <entry><ulink url="https://podman.io">Podman</ulink> container manager</entry>
+          </row>
+
+          <row>
+            <entry><varname>rkt</varname></entry>
+            <entry>rkt app container runtime</entry>
+          </row>
+
+          <row>
+            <entry><varname>wsl</varname></entry>
+            <entry><ulink url="https://docs.microsoft.com/en-us/windows/wsl/about">Windows Subsystem for Linux</ulink></entry>
+          </row>
+
+          <row>
+            <entry><varname>proot</varname></entry>
+            <entry><ulink url="https://proot-me.github.io/">proot</ulink> userspace chroot/bind mount emulation</entry>
+          </row>
+
+          <row>
+            <entry><varname>pouch</varname></entry>
+            <entry><ulink url="https://github.com/alibaba/pouch">Pouch</ulink> Container Engine</entry>
+          </row>
+        </tbody>
+      </tgroup>
+    </table>
+
+    <para>If multiple virtualization solutions are used, only the
+    "innermost" is detected and identified. That means if both
+    machine and container virtualization are used in
+    conjunction, only the latter will be identified (unless
+    <option>--vm</option> is passed).</para>
+    <para> Windows Subsystem for Linux is not a Linux container,
+    but an environment for running Linux userspace applications on
+    top of the Windows kernel using a Linux-compatible interface.
+    WSL is categorized as a container for practical purposes.
+    Multiple WSL environments share the same kernel and services
+    should generally behave like when being run in a container.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>The following options are understood:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><option>-c</option></term>
+        <term><option>--container</option></term>
+
+        <listitem><para>Only detects container virtualization (i.e.
+        shared kernel virtualization).</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-v</option></term>
+        <term><option>--vm</option></term>
+
+        <listitem><para>Only detects hardware virtualization.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-r</option></term>
+        <term><option>--chroot</option></term>
+
+        <listitem><para>Detect whether invoked in a
+        <citerefentry><refentrytitle>chroot</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+        environment. In this mode, no output is written, but the return
+        value indicates whether the process was invoked in a
+        <function>chroot()</function>
+        environment or not.</para>
+
+        <xi:include href="version-info.xml" xpointer="v228"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--private-users</option></term>
+
+        <listitem><para>Detect whether invoked in a user namespace.  In this mode, no
+        output is written, but the return value indicates whether the process was invoked
+        inside of a user namespace or not. See
+        <citerefentry project='man-pages'><refentrytitle>user_namespaces</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+        for more information.</para>
+
+        <xi:include href="version-info.xml" xpointer="v232"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--cvm</option></term>
+
+        <listitem><para>Detect whether invoked in a confidential virtual machine.
+        The result of this detection may be used to disable features that should
+        not be used in confidential VMs. It must not be used to release security
+        sensitive information. The latter must only be released after attestation
+        of the confidential environment.</para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-q</option></term>
+        <term><option>--quiet</option></term>
+
+        <listitem><para>Suppress output of the virtualization
+        technology identifier.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--list</option></term>
+
+        <listitem><para>Output all currently known and detectable container and VM environments.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--list-cvm</option></term>
+
+        <listitem><para>Output all currently known and detectable confidential virtualization technologies.</para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+      </varlistentry>
+
+      <xi:include href="standard-options.xml" xpointer="help" />
+      <xi:include href="standard-options.xml" xpointer="version" />
+    </variablelist>
+
+  </refsect1>
+
+  <refsect1>
+    <title>Exit status</title>
+
+    <para>If a virtualization technology is detected, 0 is returned, a
+    non-zero code otherwise.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>chroot</refentrytitle><manvolnum>2</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>namespaces</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-dissect.xml b/man/systemd-dissect.xml
new file mode 100644
index 0000000..a17111c
--- /dev/null
+++ b/man/systemd-dissect.xml
@@ -0,0 +1,553 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd-dissect" conditional='HAVE_BLKID'
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd-dissect</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-dissect</refentrytitle>
+    <manvolnum>1</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-dissect</refname>
+    <refname>mount.ddi</refname>
+    <refpurpose>Dissect Discoverable Disk Images (DDIs)</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <cmdsynopsis>
+      <command>systemd-dissect <arg choice="opt" rep="repeat">OPTIONS</arg> <arg choice="plain"><replaceable>IMAGE</replaceable></arg></command>
+    </cmdsynopsis>
+    <cmdsynopsis>
+      <command>systemd-dissect <arg choice="opt" rep="repeat">OPTIONS</arg> <option>--mount</option> <arg choice="plain"><replaceable>IMAGE</replaceable></arg> <arg choice="plain"><replaceable>PATH</replaceable></arg></command>
+    </cmdsynopsis>
+    <cmdsynopsis>
+      <command>systemd-dissect <arg choice="opt" rep="repeat">OPTIONS</arg> <option>--umount</option> <arg choice="plain"><replaceable>PATH</replaceable></arg></command>
+    </cmdsynopsis>
+    <cmdsynopsis>
+      <command>systemd-dissect <arg choice="opt" rep="repeat">OPTIONS</arg> <option>--attach</option> <arg choice="plain"><replaceable>IMAGE</replaceable></arg></command>
+    </cmdsynopsis>
+    <cmdsynopsis>
+      <command>systemd-dissect <arg choice="opt" rep="repeat">OPTIONS</arg> <option>--detach</option> <arg choice="plain"><replaceable>PATH</replaceable></arg></command>
+    </cmdsynopsis>
+    <cmdsynopsis>
+      <command>systemd-dissect <arg choice="opt" rep="repeat">OPTIONS</arg> <option>--list</option> <arg choice="plain"><replaceable>IMAGE</replaceable></arg></command>
+    </cmdsynopsis>
+    <cmdsynopsis>
+      <command>systemd-dissect <arg choice="opt" rep="repeat">OPTIONS</arg> <option>--mtree</option> <arg choice="plain"><replaceable>IMAGE</replaceable></arg></command>
+    </cmdsynopsis>
+    <cmdsynopsis>
+      <command>systemd-dissect <arg choice="opt" rep="repeat">OPTIONS</arg> <option>--with</option> <arg choice="plain"><replaceable>IMAGE</replaceable></arg> <arg choice="opt" rep="repeat"><replaceable>COMMAND</replaceable></arg></command>
+    </cmdsynopsis>
+    <cmdsynopsis>
+      <command>systemd-dissect <arg choice="opt" rep="repeat">OPTIONS</arg> <option>--copy-from</option> <arg choice="plain"><replaceable>IMAGE</replaceable></arg> <arg choice="plain"><replaceable>PATH</replaceable></arg> <arg choice="opt"><replaceable>TARGET</replaceable></arg></command>
+    </cmdsynopsis>
+    <cmdsynopsis>
+      <command>systemd-dissect <arg choice="opt" rep="repeat">OPTIONS</arg> <option>--copy-to</option> <arg choice="plain"><replaceable>IMAGE</replaceable></arg> <arg choice="opt"><replaceable>SOURCE</replaceable></arg> <arg choice="plain"><replaceable>PATH</replaceable></arg></command>
+    </cmdsynopsis>
+    <cmdsynopsis>
+      <command>systemd-dissect <arg choice="opt" rep="repeat">OPTIONS</arg> <option>--discover</option></command>
+    </cmdsynopsis>
+    <cmdsynopsis>
+      <command>systemd-dissect <arg choice="opt" rep="repeat">OPTIONS</arg> <option>--validate</option> <arg choice="plain"><replaceable>IMAGE</replaceable></arg></command>
+    </cmdsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>systemd-dissect</command> is a tool for introspecting and interacting with file system OS
+    disk images, specifically Discoverable Disk Images (DDIs). It supports four different operations:</para>
+
+    <orderedlist>
+      <listitem><para>Show general OS image information, including the image's
+      <citerefentry><refentrytitle>os-release</refentrytitle><manvolnum>5</manvolnum></citerefentry> data,
+      machine ID, partition information and more.</para></listitem>
+
+      <listitem><para>Mount an OS image to a local directory. In this mode it will dissect the OS image and
+      mount the included partitions according to their designation onto a directory and possibly
+      sub-directories.</para></listitem>
+
+      <listitem><para>Unmount an OS image from a local directory. In this mode it will recursively unmount
+      the mounted partitions and remove the underlying loop device, including all the partition sub-devices.
+      </para></listitem>
+
+      <listitem><para>Copy files and directories in and out of an OS image.</para></listitem>
+    </orderedlist>
+
+    <para>The tool may operate on three types of OS images:</para>
+
+    <orderedlist>
+      <listitem><para>OS disk images containing a GPT partition table envelope, with partitions marked
+      according to the <ulink url="https://uapi-group.org/specifications/specs/discoverable_partitions_specification">Discoverable Partitions
+      Specification</ulink>.</para></listitem>
+
+      <listitem><para>OS disk images containing just a plain file-system without an enveloping partition
+      table. (This file system is assumed to be the root file system of the OS.)</para></listitem>
+
+      <listitem><para>OS disk images containing a GPT or MBR partition table, with a single
+      partition only. (This partition is assumed to contain the root file system of the OS.)</para></listitem>
+    </orderedlist>
+
+    <para>OS images may use any kind of Linux-supported file systems. In addition they may make use of LUKS
+    disk encryption, and contain Verity integrity information. Note that qualifying OS images may be booted
+    with <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s
+    <option>--image=</option> switch, and be used as root file system for system service using the
+    <varname>RootImage=</varname> unit file setting, see
+    <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+
+    <para>Note that the partition table shown when invoked without command switch (as listed below) does not
+    necessarily show all partitions included in the image, but just the partitions that are understood and
+    considered part of an OS disk image. Specifically, partitions of unknown types are ignored, as well as
+    duplicate partitions (i.e. more than one per partition type), as are root and <filename>/usr/</filename>
+    partitions of architectures not compatible with the local system. In other words: this tool will display
+    what it operates with when mounting the image. To display the complete list of partitions use a tool such
+    as <citerefentry
+    project='man-pages'><refentrytitle>fdisk</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
+
+    <para>The <command>systemd-dissect</command> command may be invoked as <command>mount.ddi</command> in
+    which case it implements the <citerefentry
+    project='man-pages'><refentrytitle>mount</refentrytitle><manvolnum>8</manvolnum></citerefentry> "external
+    helper" interface. This ensures disk images compatible with <command>systemd-dissect</command> can be
+    mounted directly by <command>mount</command> and <citerefentry
+    project='man-pages'><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry>. For
+    details see below.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Commands</title>
+
+    <para>If neither of the command switches listed below are passed the specified disk image is opened and
+    general information about the image and the contained partitions and their use is shown.</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><option>--mount</option></term>
+        <term><option>-m</option></term>
+
+        <listitem><para>Mount the specified OS image to the specified directory. This will dissect the image,
+        determine the OS root file system — as well as possibly other partitions — and mount them to the
+        specified directory. If the OS image contains multiple partitions marked with the <ulink
+        url="https://uapi-group.org/specifications/specs/discoverable_partitions_specification">Discoverable Partitions Specification</ulink>
+        multiple nested mounts are established. This command expects two arguments: a path to an image file
+        and a path to a directory where to mount the image.</para>
+
+        <para>To unmount an OS image mounted like this use the <option>--umount</option> operation.</para>
+
+        <para>When the OS image contains LUKS encrypted or Verity integrity protected file systems
+        appropriate volumes are automatically set up and marked for automatic disassembly when the image is
+        unmounted.</para>
+
+        <para>The OS image may either be specified as path to an OS image stored in a regular file or may
+        refer to block device node (in the latter case the block device must be the "whole" device, i.e. not
+        a partition device). (The other supported commands described here support this, too.)</para>
+
+        <para>All mounted file systems are checked with the appropriate <citerefentry
+        project='man-pages'><refentrytitle>fsck</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        implementation in automatic fixing mode, unless explicitly turned off (<option>--fsck=no</option>) or
+        read-only operation is requested (<option>--read-only</option>).</para>
+
+        <para>Note that this functionality is also available in <citerefentry
+        project='man-pages'><refentrytitle>mount</refentrytitle><manvolnum>8</manvolnum></citerefentry> via a
+        command such as <command>mount -t ddi myimage.raw targetdir/</command>, as well as in <citerefentry
+        project='man-pages'><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry>. For
+        details, see below.</para>
+
+        <xi:include href="version-info.xml" xpointer="v247"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-M</option></term>
+
+        <listitem><para>This is a shortcut for <option>--mount --mkdir</option>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v247"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--umount</option></term>
+        <term><option>-u</option></term>
+
+        <listitem><para>Unmount an OS image from the specified directory. This command expects one argument:
+        a directory where an OS image was mounted.</para>
+
+        <para>All mounted partitions will be recursively unmounted, and the underlying loop device will be
+        removed, along with all its partition sub-devices.</para>
+
+        <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-U</option></term>
+
+        <listitem><para>This is a shortcut for <option>--umount --rmdir</option>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--attach</option></term>
+
+        <listitem><para>Attach the specified disk image to an automatically allocated loopback block device,
+        and print the path to the loopback block device to standard output. This is similar to an invocation
+        of <command>losetup --find --show</command>, but will validate the image as DDI before attaching, and
+        derive the correct sector size to use automatically. Moreover, it ensures the per-partition block
+        devices are created before returning. Takes a path to a disk image file.</para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--detach</option></term>
+
+        <listitem><para>Detach the specified disk image from a loopback block device. This undoes the effect
+        of <option>--attach</option> above. This expects either a path to a loopback block device as an
+        argument, or the path to the backing image file. In the latter case it will automatically determine
+        the right device to detach.</para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--list</option></term>
+        <term><option>-l</option></term>
+
+        <listitem><para>Prints the paths of all the files and directories in the specified OS image or
+        directory to standard output.</para>
+
+        <xi:include href="version-info.xml" xpointer="v253"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--mtree</option></term>
+
+        <listitem><para>Generates a BSD
+        <citerefentry project='die-net'><refentrytitle>mtree</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        compatible file manifest of the specified disk image or directory. This is useful for comparing image
+        contents in detail, including inode information and other metadata. While the generated manifest will
+        contain detailed inode information, it currently excludes extended attributes, file system
+        capabilities, MAC labels,
+        <citerefentry project='man-pages'><refentrytitle>chattr</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+        file flags,
+        <citerefentry project='url'><refentrytitle url='https://btrfs.readthedocs.io/en/latest/btrfs-man5.html'>btrfs</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        subvolume information, and various other file metadata. File content information is shown via a
+        SHA256 digest. Additional fields might be added in future. Note that inode information such as link
+        counts, inode numbers and timestamps is excluded from the output on purpose, as it typically
+        complicates reproducibility.</para>
+
+        <xi:include href="version-info.xml" xpointer="v253"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--with</option></term>
+
+        <listitem><para>Runs the specified command with the specified OS image mounted. This will mount the
+        image to a temporary directory, switch the current working directory to it, and invoke the specified
+        command line as child process. Once the process ends it will unmount the image again, and remove the
+        temporary directory. If no command is specified a shell is invoked. The image is mounted writable,
+        use <option>--read-only</option> to switch to read-only operation. The invoked process will have the
+        <varname>$SYSTEMD_DISSECT_ROOT</varname> environment variable set, containing the absolute path name
+        of the temporary mount point, i.e. the same directory that is set as the current working
+        directory. It will also have the <varname>$SYSTEMD_DISSECT_DEVICE</varname> environment variable set,
+        containing the absolute path name of the loop device the image was attached to.</para>
+
+        <xi:include href="version-info.xml" xpointer="v253"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--copy-from</option></term>
+        <term><option>-x</option></term>
+
+        <listitem><para>Copies a file or directory from the specified OS image or directory into the
+        specified location on the host file system. Expects three arguments: a path to an image file or
+        directory, a source path (relative to the image's root directory) and a destination path (relative to
+        the current working directory, or an absolute path, both outside of the image). If the destination
+        path is omitted or specified as dash (<literal>-</literal>), the specified file is written to
+        standard output. If the source path in the image file system refers to a regular file it is copied to
+        the destination path. In this case access mode, extended attributes and timestamps are copied as
+        well, but file ownership is not. If the source path in the image refers to a directory, it is copied
+        to the destination path, recursively with all containing files and directories. In this case the file
+        ownership is copied too.</para>
+
+        <xi:include href="version-info.xml" xpointer="v247"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--copy-to</option></term>
+        <term><option>-a</option></term>
+
+        <listitem><para>Copies a file or directory from the specified location in the host file system into
+        the specified OS image or directory. Expects three arguments: a path to an image file or directory, a
+        source path (relative to the current working directory, or an absolute path, both outside of the
+        image) and a destination path (relative to the image's root directory). If the source path is omitted
+        or specified as dash (<literal>-</literal>), the data to write is read from standard input. If the
+        source path in the host file system refers to a regular file, it is copied to the destination path.
+        In this case access mode, extended attributes and timestamps are copied as well, but file ownership
+        is not. If the source path in the host file system refers to a directory it is copied to the
+        destination path, recursively with all containing files and directories. In this case the file
+        ownership is copied too.</para>
+
+        <para>As with <option>--mount</option> file system checks are implicitly run before the copy
+        operation begins.</para>
+
+        <xi:include href="version-info.xml" xpointer="v247"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--discover</option></term>
+
+        <listitem><para>Show a list of DDIs in well-known directories. This will show machine, portable
+        service and system/configuration extension disk images in the usual directories
+        <filename>/usr/lib/machines/</filename>, <filename>/usr/lib/portables/</filename>,
+        <filename>/usr/lib/confexts/</filename>, <filename>/var/lib/machines/</filename>,
+        <filename>/var/lib/portables/</filename>, <filename>/var/lib/extensions/</filename> and so
+        on.</para>
+
+        <xi:include href="version-info.xml" xpointer="v253"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--validate</option></term>
+
+        <listitem><para>Validates the partition arrangement of a disk image (DDI), and ensures it matches the
+        image policy specified via <option>--image-policy=</option>, if one is specified. This parses the
+        partition table and probes the file systems in the image, but does not attempt to mount them (nor to
+        set up disk encryption/authentication via LUKS/Verity). It does this taking the configured image
+        dissection policy into account. Since this operation does not mount file systems, this command –
+        unlike all other commands implemented by this tool – requires no privileges other than the ability to
+        access the specified file. Prints "OK" and returns zero if the image appears to be in order and
+        matches the specified image dissection policy. Otherwise prints an error message and returns
+        non-zero.</para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+      </varlistentry>
+
+      <xi:include href="standard-options.xml" xpointer="help" />
+      <xi:include href="standard-options.xml" xpointer="version" />
+    </variablelist>
+
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>The following options are understood:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><option>--read-only</option></term>
+        <term><option>-r</option></term>
+
+        <listitem><para>Operate in read-only mode. By default <option>--mount</option> will establish
+        writable mount points. If this option is specified they are established in read-only mode
+        instead.</para>
+
+        <xi:include href="version-info.xml" xpointer="v247"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--fsck=no</option></term>
+
+        <listitem><para>Turn off automatic file system checking. By default when an image is accessed for
+        writing (by <option>--mount</option> or <option>--copy-to</option>) the file systems contained in the
+        OS image are automatically checked using the appropriate <citerefentry
+        project='man-pages'><refentrytitle>fsck</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        command, in automatic fixing mode. This behavior may be switched off using
+        <option>--fsck=no</option>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v247"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--growfs=no</option></term>
+
+        <listitem><para>Turn off automatic growing of accessed file systems to their partition size, if
+        marked for that in the GPT partition table. By default when an image is accessed for writing (by
+        <option>--mount</option> or <option>--copy-to</option>) the file systems contained in the OS image
+        are automatically grown to their partition sizes, if bit 59 in the GPT partition flags is set for
+        partition types that are defined by the <ulink
+        url="https://uapi-group.org/specifications/specs/discoverable_partitions_specification">Discoverable Partitions Specification</ulink>. This
+        behavior may be switched off using <option>--growfs=no</option>. File systems are grown automatically
+        on access if all of the following conditions are met:</para>
+        <orderedlist>
+          <listitem><para>The file system is mounted writable</para></listitem>
+          <listitem><para>The file system currently is smaller than the partition it is contained in (and thus can be grown)</para></listitem>
+          <listitem><para>The image contains a GPT partition table</para></listitem>
+          <listitem><para>The file system is stored on a partition defined by the Discoverable Partitions Specification</para></listitem>
+          <listitem><para>Bit 59 of the GPT partition flags for this partition is set, as per specification</para></listitem>
+          <listitem><para>The <option>--growfs=no</option> option is not passed.</para></listitem>
+        </orderedlist>
+
+          <xi:include href="version-info.xml" xpointer="v249"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--mkdir</option></term>
+
+        <listitem><para>If combined with <option>--mount</option> the directory to mount the OS image to is
+        created if it is missing. Note that the directory is not automatically removed when the disk image is
+        unmounted again.</para>
+
+        <xi:include href="version-info.xml" xpointer="v247"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--rmdir</option></term>
+
+        <listitem><para>If combined with <option>--umount</option> the specified directory where the OS image
+        is mounted is removed after unmounting the OS image.</para>
+
+        <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--discard=</option></term>
+
+        <listitem><para>Takes one of <literal>disabled</literal>, <literal>loop</literal>,
+        <literal>all</literal>, <literal>crypto</literal>. If <literal>disabled</literal> the image is
+        accessed with empty block discarding turned off. If <literal>loop</literal> discarding is enabled if
+        operating on a regular file. If <literal>crypt</literal> discarding is enabled even on encrypted file
+        systems. If <literal>all</literal> discarding is unconditionally enabled.</para>
+
+        <xi:include href="version-info.xml" xpointer="v247"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--in-memory</option></term>
+
+        <listitem><para>If specified an in-memory copy of the specified disk image is used. This may be used
+        to operate with write-access on a (possibly read-only) image, without actually modifying the original
+        file. This may also be used in order to operate on a disk image without keeping the originating file
+        system busy, in order to allow it to be unmounted.</para>
+
+        <xi:include href="version-info.xml" xpointer="v253"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--root-hash=</option></term>
+        <term><option>--root-hash-sig=</option></term>
+        <term><option>--verity-data=</option></term>
+
+        <listitem><para>Configure various aspects of Verity data integrity for the OS image. Option
+        <option>--root-hash=</option> specifies a hex-encoded top-level Verity hash to use for setting up the
+        Verity integrity protection. Option <option>--root-hash-sig=</option> specifies the path to a file
+        containing a PKCS#7 signature for the hash. This signature is passed to the kernel during activation,
+        which will match it against signature keys available in the kernel keyring.  Option
+        <option>--verity-data=</option> specifies a path to a file with the Verity data to use for the OS
+        image, in case it is stored in a detached file. It is recommended to embed the Verity data directly
+        in the image, using the Verity mechanisms in the <ulink
+        url="https://uapi-group.org/specifications/specs/discoverable_partitions_specification">Discoverable Partitions Specification</ulink>.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v247"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--loop-ref=</option></term>
+
+        <listitem><para>Configures the "reference" string the kernel shall report as backing file for the
+        loopback block device. While this is supposed to be a path or filename referencing the backing file,
+        this is not enforced and the kernel accepts arbitrary free-form strings, chosen by the user. Accepts
+        arbitrary strings up to a length of 63 characters. This sets the kernel's
+        <literal>.lo_file_name</literal> field for the block device. Note this is distinct from the
+        <filename>/sys/class/block/loopX/loop/backing_file</filename> attribute file that always reports a
+        path referring to the actual backing file. The latter is subject to mount namespace translation, the
+        former is not.</para>
+
+        <para>This setting is particularly useful in combination with the <option>--attach</option> command,
+        as it allows later referencing the allocated loop device via
+        <filename>/dev/disk/by-loop-ref/…</filename> symlinks. Example: first, set up the loopback device
+        via <command>systemd-dissect attach --loop-ref=quux foo.raw</command>, and then reference it in a
+        command via the specified filename: <command>cfdisk /dev/disk/by-loop-ref/quux</command>.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--mtree-hash=no</option></term>
+
+        <listitem><para>If combined with <option>--mtree</option>, turns off inclusion of file hashes in the
+        mtree output. This makes the <option>--mtree</option> faster when operating on large images.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+      </varlistentry>
+
+      <xi:include href="standard-options.xml" xpointer="image-policy-open" />
+      <xi:include href="standard-options.xml" xpointer="no-pager" />
+      <xi:include href="standard-options.xml" xpointer="no-legend" />
+      <xi:include href="standard-options.xml" xpointer="json" />
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Exit status</title>
+
+    <para>On success, 0 is returned, a non-zero failure code otherwise. If the <option>--with</option>
+    command is used the exit status of the invoked command is propagated.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Invocation as <command>/sbin/mount.ddi</command></title>
+
+    <para>The <command>systemd-dissect</command> executable may be symlinked to
+    <filename>/sbin/mount.ddi</filename>. If invoked through that it implements <citerefentry
+    project='man-pages'><refentrytitle>mount</refentrytitle><manvolnum>8</manvolnum></citerefentry>'s
+    "external helper" interface for the (pseudo) file system type <literal>ddi</literal>. This means
+    conformant disk images may be mounted directly via</para>
+
+    <programlisting># mount -t ddi myimage.raw targetdir/</programlisting>
+
+    <para>in a fashion mostly equivalent to:</para>
+
+    <programlisting># systemd-dissect --mount myimage.raw targetdir/</programlisting>
+
+    <para>Note that since a single DDI may contain multiple file systems it should later be unmounted with
+    <command>umount -R targetdir/</command>, for recursive operation.</para>
+
+    <para>This functionality is particularly useful to mount DDIs automatically at boot via simple
+    <filename>/etc/fstab</filename> entries. For example:</para>
+
+    <programlisting>/path/to/myimage.raw /images/myimage/ ddi defaults 0 0</programlisting>
+
+    <para>When invoked this way the mount options <literal>ro</literal>, <literal>rw</literal>,
+    <literal>discard</literal>, <literal>nodiscard</literal> map to the corresponding options listed above
+    (i.e. <option>--read-only</option>, <option>--discard=all</option>,
+    <option>--discard=disabled</option>). Mount options are <emphasis>not</emphasis> generically passed on to
+    the file systems inside the images.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Examples</title>
+
+    <example>
+      <title>Generate a tarball from an OS disk image</title>
+
+      <programlisting># systemd-dissect --with foo.raw tar cz . >foo.tar.gz</programlisting>
+    </example>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <ulink url="https://uapi-group.org/specifications/specs/discoverable_partitions_specification">Discoverable Partitions Specification</ulink>,
+      <citerefentry project='man-pages'><refentrytitle>mount</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>umount</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>fdisk</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-environment-d-generator.xml b/man/systemd-environment-d-generator.xml
new file mode 100644
index 0000000..a85ef49
--- /dev/null
+++ b/man/systemd-environment-d-generator.xml
@@ -0,0 +1,53 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [
+<!ENTITY % entities SYSTEM "custom-entities.ent" >
+%entities;
+]>
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+<refentry id="systemd-environment-d-generator" conditional='ENABLE_ENVIRONMENT_D'>
+
+  <refentryinfo>
+    <title>systemd-environment-d-generator</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-environment-d-generator</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-environment-d-generator</refname>
+    <refname>30-systemd-environment-d-generator</refname>
+    <refpurpose>Load variables specified by <filename>environment.d</filename>
+    </refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>&USER_ENV_GENERATOR_DIR;/30-systemd-environment-d-generator</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><filename>systemd-environment-d-generator</filename> is a
+    <citerefentry><refentrytitle>systemd.environment-generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+    that reads environment configuration specified by
+    <citerefentry><refentrytitle>environment.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    configuration files and passes it to the
+    <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    user manager instance.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.environment-generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-escape.xml b/man/systemd-escape.xml
new file mode 100644
index 0000000..4e4130f
--- /dev/null
+++ b/man/systemd-escape.xml
@@ -0,0 +1,198 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd-escape"
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd-escape</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-escape</refentrytitle>
+    <manvolnum>1</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-escape</refname>
+    <refpurpose>Escape strings for usage in systemd unit names</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <cmdsynopsis>
+      <command>systemd-escape</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="opt" rep="repeat">STRING</arg>
+    </cmdsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>systemd-escape</command> may be used to escape
+    strings for inclusion in systemd unit names. The command may be
+    used to escape and to undo escaping of strings.</para>
+
+    <para>The command takes any number of strings on the command line,
+    and will process them individually, one after another. It will
+    output them separated by spaces to stdout.</para>
+
+    <para>By default, this command will escape the strings passed,
+    unless <option>--unescape</option> is passed which results in the
+    inverse operation being applied. If <option>--mangle</option> is given, a
+    special mode of escaping is applied instead, which assumes the
+    string is already escaped but will escape everything that
+    appears obviously non-escaped.</para>
+
+    <para>For details on the escaping and unescaping algorithms see the relevant section in
+    <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>The following options are understood:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><option>--suffix=</option></term>
+
+        <listitem><para>Appends the specified unit type suffix to the
+        escaped string. Takes one of the unit types supported by
+        systemd, such as <literal>service</literal> or
+        <literal>mount</literal>. May not be used in conjunction with
+        <option>--template=</option>, <option>--unescape</option> or
+        <option>--mangle</option>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v216"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--template=</option></term>
+
+        <listitem><para>Inserts the escaped strings in a unit name
+        template. Takes a unit name template such as
+        <filename>foobar@.service</filename>. With
+        <option>--unescape</option>, expects instantiated unit names
+        for this template and extracts and unescapes just the instance
+        part. May not be used in conjunction with
+        <option>--suffix=</option>,
+        <option>--instance</option> or
+        <option>--mangle</option>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v216"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--path</option></term>
+        <term><option>-p</option></term>
+
+        <listitem><para>When escaping or unescaping a string, assume it refers to a file system path. This
+        simplifies the path (leading, trailing, and duplicate <literal>/</literal> characters are removed,
+        no-op path <literal>.</literal> components are removed, and for absolute paths, leading
+        <literal>..</literal> components are removed). After the simplification, the path must not contain
+        <literal>..</literal>.</para>
+
+        <para>This is particularly useful for generating strings suitable for unescaping with the
+        <literal>%f</literal> specifier in unit files, see
+        <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v216"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--unescape</option></term>
+        <term><option>-u</option></term>
+
+        <listitem><para>Instead of escaping the specified strings,
+        undo the escaping, reversing the operation. May not be used in
+        conjunction with <option>--suffix=</option> or
+        <option>--mangle</option>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v216"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--mangle</option></term>
+        <term><option>-m</option></term>
+
+        <listitem><para>Like <option>--escape</option>, but only
+        escape characters that are obviously not escaped yet, and
+        possibly automatically append an appropriate unit type suffix
+        to the string. May not be used in conjunction with
+        <option>--suffix=</option>, <option>--template=</option> or
+        <option>--unescape</option>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v216"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--instance</option></term>
+
+        <listitem><para>With <option>--unescape</option>, unescape
+        and print only the instance part of an instantiated unit name
+        template. Results in an error for an uninstantiated template
+        like <filename>ssh@.service</filename> or a non-template name
+        like <filename>ssh.service</filename>.
+        Must be used in conjunction with <option>--unescape</option>
+        and may not be used in conjunction with
+        <option>--template</option>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v240"/></listitem>
+      </varlistentry>
+
+      <xi:include href="standard-options.xml" xpointer="help" />
+      <xi:include href="standard-options.xml" xpointer="version" />
+    </variablelist>
+
+  </refsect1>
+
+  <refsect1>
+    <title>Examples</title>
+
+    <para>To escape a single string:</para>
+    <programlisting>$ systemd-escape 'Hallöchen, Meister'
+Hall\xc3\xb6chen\x2c\x20Meister</programlisting>
+
+    <para>To undo escaping on a single string:</para>
+    <programlisting>$ systemd-escape -u 'Hall\xc3\xb6chen\x2c\x20Meister'
+Hallöchen, Meister</programlisting>
+
+    <para>To generate the mount unit for a path:</para>
+    <programlisting>$ systemd-escape -p --suffix=mount "/tmp//waldi/foobar/"
+tmp-waldi-foobar.mount</programlisting>
+
+    <para>To generate instance names of three strings:</para>
+    <programlisting>$ systemd-escape --template=systemd-nspawn@.service 'My Container 1' 'containerb' 'container/III'
+systemd-nspawn@My\x20Container\x201.service systemd-nspawn@containerb.service systemd-nspawn@container-III.service</programlisting>
+
+    <para>To extract the instance part of an instantiated unit:</para>
+    <programlisting>$ systemd-escape -u --instance 'systemd-nspawn@My\x20Container\x201.service'
+My Container 1</programlisting>
+
+    <para>To extract the instance part of an instance of a particular template:</para>
+    <programlisting>$ systemd-escape -u --template=systemd-nspawn@.service 'systemd-nspawn@My\x20Container\x201.service'
+My Container 1</programlisting>
+  </refsect1>
+
+  <refsect1>
+    <title>Exit status</title>
+
+    <para>On success, 0 is returned, a non-zero failure code
+    otherwise.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-firstboot.xml b/man/systemd-firstboot.xml
new file mode 100644
index 0000000..e07e157
--- /dev/null
+++ b/man/systemd-firstboot.xml
@@ -0,0 +1,462 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd-firstboot" conditional='ENABLE_FIRSTBOOT'
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd-firstboot</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-firstboot</refentrytitle>
+    <manvolnum>1</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-firstboot</refname>
+    <refname>systemd-firstboot.service</refname>
+    <refpurpose>Initialize basic system settings on or before the first boot-up of a system</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <cmdsynopsis>
+      <command>systemd-firstboot</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+    </cmdsynopsis>
+
+    <para><filename>systemd-firstboot.service</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>systemd-firstboot</command> initializes basic system settings interactively during the
+    first boot, or non-interactively on an offline system image. The service is started during boot if
+    <varname>ConditionFirstBoot=yes</varname> is met, which essentially means that <filename>/etc/</filename>
+    is unpopulated, see
+    <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
+    details.</para>
+
+    <para>The following settings may be configured:</para>
+
+    <itemizedlist>
+      <listitem><para>The machine ID of the system</para></listitem>
+
+      <listitem><para>The system locale, more specifically the two
+      locale variables <varname>LANG=</varname> and
+      <varname>LC_MESSAGES</varname></para></listitem>
+
+      <listitem><para>The system keyboard map</para></listitem>
+
+      <listitem><para>The system time zone</para></listitem>
+
+      <listitem><para>The system hostname</para></listitem>
+
+      <listitem><para>The kernel command line used when installing kernel images</para></listitem>
+
+      <listitem><para>The root user's password and shell</para></listitem>
+    </itemizedlist>
+
+    <para>Each of the fields may either be queried interactively by
+    users, set non-interactively on the tool's command line, or be
+    copied from a host system that is used to set up the system
+    image.</para>
+
+    <para>If a setting is already initialized, it will not be
+    overwritten and the user will not be prompted for the
+    setting.</para>
+
+    <para>Note that this tool operates directly on the file system and
+    does not involve any running system services, unlike
+    <citerefentry project='man-pages'><refentrytitle>localectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>timedatectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    or
+    <citerefentry><refentrytitle>hostnamectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
+    This allows <command>systemd-firstboot</command> to operate on
+    mounted but not booted disk images and in early boot. It is not
+    recommended to use <command>systemd-firstboot</command> on the
+    running system after it has been set up.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>The following options are understood:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><option>--root=<replaceable>root</replaceable></option></term>
+        <listitem><para>Takes a directory path as an argument. All
+        paths will be prefixed with the given alternate
+        <replaceable>root</replaceable> path, including config search
+        paths. This is useful to operate on a system image mounted to
+        the specified directory instead of the host system itself.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v216"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--image=<replaceable>path</replaceable></option></term>
+        <listitem><para>Takes a path to a disk image file or block device node. If specified all operations
+        are applied to file system in the indicated disk image. This is similar to <option>--root=</option>
+        but operates on file systems stored in disk images or block devices. The disk image should either
+        contain just a file system or a set of file systems within a GPT partition table, following the
+        <ulink url="https://uapi-group.org/specifications/specs/discoverable_partitions_specification">Discoverable Partitions
+        Specification</ulink>. For further information on supported disk images, see
+        <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s
+        switch of the same name.</para>
+
+        <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--locale=<replaceable>LOCALE</replaceable></option></term>
+        <term><option>--locale-messages=<replaceable>LOCALE</replaceable></option></term>
+
+        <listitem><para>Sets the system locale, more specifically the
+        <varname>LANG=</varname> and <varname>LC_MESSAGES</varname>
+        settings. The argument should be a valid locale identifier,
+        such as <literal>de_DE.UTF-8</literal>. This controls the
+        <citerefentry project='man-pages'><refentrytitle>locale.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        configuration file.</para>
+
+        <xi:include href="version-info.xml" xpointer="v216"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--keymap=<replaceable>KEYMAP</replaceable></option></term>
+
+        <listitem><para>Sets the system keyboard layout. The argument should be a valid keyboard map,
+        such as <literal>de-latin1</literal>. This controls the <literal>KEYMAP</literal> entry in the
+        <citerefentry project='man-pages'><refentrytitle>vconsole.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        configuration file.</para>
+
+        <xi:include href="version-info.xml" xpointer="v236"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--timezone=<replaceable>TIMEZONE</replaceable></option></term>
+
+        <listitem><para>Sets the system time zone. The argument should
+        be a valid time zone identifier, such as
+        <literal>Europe/Berlin</literal>. This controls the
+        <citerefentry><refentrytitle>localtime</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        symlink.</para>
+
+        <xi:include href="version-info.xml" xpointer="v216"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--hostname=<replaceable>HOSTNAME</replaceable></option></term>
+
+        <listitem><para>Sets the system hostname. The argument should
+        be a hostname, compatible with DNS. This controls the
+        <citerefentry><refentrytitle>hostname</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        configuration file.</para>
+
+        <xi:include href="version-info.xml" xpointer="v216"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--setup-machine-id</option></term>
+
+        <listitem><para>Initialize the system's machine ID to a random ID. This controls the
+        <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry> file.
+        </para>
+
+        <para>This option only works in combination with <option>--root=</option> or
+        <option>--image=</option>. On a running system, <filename>machine-id</filename> is written by the
+        manager with help from
+        <citerefentry><refentrytitle>systemd-machine-id-commit.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v216"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--machine-id=<replaceable>ID</replaceable></option></term>
+
+        <listitem><para>Set the system's machine ID to the specified value. The same restrictions apply
+        as to <option>--setup-machine-id</option>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v216"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--root-password=<replaceable>PASSWORD</replaceable></option></term>
+        <term><option>--root-password-file=<replaceable>PATH</replaceable></option></term>
+        <term><option>--root-password-hashed=<replaceable>HASHED_PASSWORD</replaceable></option></term>
+
+        <listitem><para>Sets the password of the system's root user. This creates/modifies the
+        <citerefentry project='die-net'><refentrytitle>passwd</refentrytitle><manvolnum>5</manvolnum></citerefentry> and
+        <citerefentry project='die-net'><refentrytitle>shadow</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        files. This setting exists in three forms: <option>--root-password=</option> accepts the password to
+        set directly on the command line, <option>--root-password-file=</option> reads it from a file and
+        <option>--root-password-hashed=</option> accepts an already hashed password on the command line. See
+        <citerefentry project='die-net'><refentrytitle>shadow</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for more information on the format of the hashed password. Note that it is not recommended to specify
+        plaintext passwords on the command line, as other users might be able to see them simply by invoking
+        <citerefentry project='die-net'><refentrytitle>ps</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v216"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--root-shell=<replaceable>SHELL</replaceable></option></term>
+
+        <listitem><para>Sets the shell of the system's root user. This creates/modifies the
+        <citerefentry project='die-net'><refentrytitle>passwd</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        file.</para>
+
+        <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--kernel-command-line=<replaceable>CMDLINE</replaceable></option></term>
+
+        <listitem><para>Sets the system's kernel command line. This controls the
+        <filename>/etc/kernel/cmdline</filename> file which is used by
+        <citerefentry><refentrytitle>kernel-install</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--prompt-locale</option></term>
+        <term><option>--prompt-keymap</option></term>
+        <term><option>--prompt-timezone</option></term>
+        <term><option>--prompt-hostname</option></term>
+        <term><option>--prompt-root-password</option></term>
+        <term><option>--prompt-root-shell</option></term>
+
+        <listitem><para>Prompt the user interactively for a specific
+        basic setting. Note that any explicit configuration settings
+        specified on the command line take precedence, and the user is
+        not prompted for it.</para>
+
+        <xi:include href="version-info.xml" xpointer="v216"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--prompt</option></term>
+
+        <listitem><para>Query the user for locale, keymap, timezone, hostname,
+        root's password, and root's shell. This is equivalent to specifying
+        <option>--prompt-locale</option>,
+        <option>--prompt-keymap</option>,
+        <option>--prompt-timezone</option>,
+        <option>--prompt-hostname</option>,
+        <option>--prompt-root-password</option>,
+        <option>--prompt-root-shell</option> in combination.</para>
+
+        <xi:include href="version-info.xml" xpointer="v216"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--copy-locale</option></term>
+        <term><option>--copy-keymap</option></term>
+        <term><option>--copy-timezone</option></term>
+        <term><option>--copy-root-password</option></term>
+        <term><option>--copy-root-shell</option></term>
+
+        <listitem><para>Copy a specific basic setting from the host.
+        This only works in combination with <option>--root=</option> or <option>--image=</option>.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v216"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--copy</option></term>
+
+        <listitem><para>Copy locale, keymap, time zone, root password and shell from the host. This is
+        equivalent to specifying
+        <option>--copy-locale</option>,
+        <option>--copy-keymap</option>,
+        <option>--copy-timezone</option>,
+        <option>--copy-root-password</option>,
+        <option>--copy-root-shell</option> in combination.</para>
+
+        <xi:include href="version-info.xml" xpointer="v216"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--force</option></term>
+
+        <listitem><para>Write configuration even if the relevant files already exist. Without this option,
+        <command>systemd-firstboot</command> doesn't modify or replace existing files. Note that when
+        configuring the root account, even with this option, <command>systemd-firstboot</command> only
+        modifies the entry of the <literal>root</literal> user, leaving other entries in
+        <filename>/etc/passwd</filename> and <filename>/etc/shadow</filename> intact.</para>
+
+        <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--reset</option></term>
+
+        <listitem><para>If specified, all existing files that are configured by
+        <command>systemd-firstboot</command> are removed. Note that the files are removed regardless of
+        whether they'll be configured with a new value or not. This operation ensures that the next boot of
+        the image will be considered a first boot, and <command>systemd-firstboot</command> will prompt again
+        to configure each of the removed files.</para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--delete-root-password</option></term>
+
+        <listitem><para>Removes the password of the system's root user, enabling login as root without a
+        password unless the root account is locked. Note that this is extremely insecure and hence this
+        option should not be used lightly.</para>
+
+        <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--welcome=</option></term>
+
+        <listitem><para>Takes a boolean argument. By default when prompting the user for configuration
+        options a brief welcome text is shown before the first question is asked. Pass false to this option
+        to turn off the welcome text.</para>
+
+        <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+      </varlistentry>
+
+      <xi:include href="standard-options.xml" xpointer="help" />
+      <xi:include href="standard-options.xml" xpointer="version" />
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Credentials</title>
+
+    <para><command>systemd-firstboot</command> supports the service credentials logic as implemented by
+    <varname>ImportCredential=</varname>/<varname>LoadCredential=</varname>/<varname>SetCredential=</varname>
+    (see <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
+    details). The following credentials are used when passed in:</para>
+
+    <variablelist class='system-credentials'>
+      <varlistentry>
+        <term><varname>passwd.hashed-password.root</varname></term>
+        <term><varname>passwd.plaintext-password.root</varname></term>
+
+        <listitem><para>A hashed or plaintext version of the root password to use, in place of prompting the
+        user. These credentials are equivalent to the same ones defined for the
+        <citerefentry><refentrytitle>systemd-sysusers.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        service.</para>
+
+        <xi:include href="version-info.xml" xpointer="v249"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>passwd.shell.root</varname></term>
+
+        <listitem><para>Specifies the shell binary to use for the specified account.
+        Equivalent to the credential of the same name defined for the
+        <citerefentry><refentrytitle>systemd-sysusers.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        service.</para>
+
+        <xi:include href="version-info.xml" xpointer="v249"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>firstboot.locale</varname></term>
+        <term><varname>firstboot.locale-messages</varname></term>
+
+        <listitem><para>These credentials specify the locale settings to set during first boot, in place of
+        prompting the user.</para>
+
+        <xi:include href="version-info.xml" xpointer="v249"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>firstboot.keymap</varname></term>
+
+        <listitem><para>This credential specifies the keyboard setting to set during first boot, in place of
+        prompting the user.</para>
+
+        <para>Note the relationship to the <varname>vconsole.keymap</varname> credential understood by
+        <citerefentry><refentrytitle>systemd-vconsole-setup.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>:
+        both ultimately affect the same setting, but <varname>firstboot.keymap</varname> is written into
+        <filename>/etc/vconsole.conf</filename> on first boot (if not already configured), and then read from
+        there by <command>systemd-vconsole-setup</command>, while <varname>vconsole.keymap</varname> is read
+        on every boot, and is not persisted to disk (but any configuration in
+        <filename>vconsole.conf</filename> will take precedence if present).</para>
+
+        <xi:include href="version-info.xml" xpointer="v249"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>firstboot.timezone</varname></term>
+
+        <listitem><para>This credential specifies the system timezone setting to set during first boot, in
+        place of prompting the user.</para>
+
+        <xi:include href="version-info.xml" xpointer="v249"/></listitem>
+      </varlistentry>
+    </variablelist>
+
+    <para>Note that by default the <filename>systemd-firstboot.service</filename> unit file is set up to
+    inherit the listed credentials
+    from the service manager. Thus, when invoking a container with an unpopulated <filename>/etc/</filename>
+    for the first time it is possible to configure the root user's password to be <literal>systemd</literal>
+    like this:</para>
+
+    <para><programlisting># systemd-nspawn --image=… --set-credential=firstboot.locale:de_DE.UTF-8 …</programlisting></para>
+
+    <para>Note that these credentials are only read and applied during the first boot process. Once they are
+    applied they remain applied for subsequent boots, and the credentials are not considered anymore.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Exit status</title>
+
+    <para>On success, 0 is returned, a non-zero failure code
+    otherwise.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Kernel Command Line</title>
+
+    <variablelist class='kernel-commandline-options'>
+      <varlistentry>
+        <term><varname>systemd.firstboot=</varname></term>
+
+        <listitem><para>Takes a boolean argument, defaults to on. If off, <filename>systemd-firstboot.service</filename>
+        won't interactively query the user for basic settings at first boot, even if those settings are not
+        initialized yet.</para>
+
+        <xi:include href="version-info.xml" xpointer="v233"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>locale.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>vconsole.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>localtime</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>hostname</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry project='die-net'><refentrytitle>shadow</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-machine-id-setup</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>localectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>timedatectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>hostnamectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-fsck@.service.xml b/man/systemd-fsck@.service.xml
new file mode 100644
index 0000000..78c661b
--- /dev/null
+++ b/man/systemd-fsck@.service.xml
@@ -0,0 +1,125 @@
+<?xml version="1.0"?>
+<!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+<refentry id="systemd-fsck@.service" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd-fsck@.service</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-fsck@.service</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-fsck@.service</refname>
+    <refname>systemd-fsck-root.service</refname>
+    <refname>systemd-fsck-usr.service</refname>
+    <refname>systemd-fsck</refname>
+    <refpurpose>File system checker logic</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>systemd-fsck@.service</filename></para>
+    <para><filename>systemd-fsck-root.service</filename></para>
+    <para><filename>systemd-fsck-usr.service</filename></para>
+    <para><filename>/usr/lib/systemd/systemd-fsck</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><filename>systemd-fsck@.service</filename>, <filename>systemd-fsck-root.service</filename>, and
+    <filename>systemd-fsck-usr.service</filename> are services responsible for file system checks. They are
+    instantiated for each device that is configured for file system checking.
+    <filename>systemd-fsck-root.service</filename> and <filename>systemd-fsck-usr.service</filename> are
+    responsible for file system checks on the root and /usr file system, respectively, but only if the root
+    filesystem was not checked in the initrd. <filename>systemd-fsck@.service</filename> is used for all
+    other file systems and for the root file system in the initrd.</para>
+
+    <para>These services are started at boot if <option>passno</option> in <filename>/etc/fstab</filename>
+    for the file system is set to a value greater than zero, but only if it is also configured to be
+    mounted at boot (i.e. without <literal>noauto</literal> option). The file system check for root is
+    performed before the other file systems. Other file systems may be checked in parallel, except when
+    they are on the same rotating disk.</para>
+
+    <para><filename>systemd-fsck</filename> does not know any details
+    about specific filesystems, and simply executes file system
+    checkers specific to each filesystem type
+    (<filename>fsck.<replaceable>type</replaceable></filename>). These checkers will decide if
+    the filesystem should actually be checked based on the time since
+    last check, number of mounts, unclean unmount, etc.</para>
+
+    <para><filename>systemd-fsck-root.service</filename> and <filename>systemd-fsck-usr.service</filename>
+    will activate <filename>reboot.target</filename> if <command>fsck</command> returns the "System
+    should reboot" condition, or <filename>emergency.target</filename> if <command>fsck</command>
+    returns the "Filesystem errors left uncorrected" condition.</para>
+
+    <para><filename>systemd-fsck@.service</filename> will fail if
+    <command>fsck</command> returns with either "System should reboot"
+    or "Filesystem errors left uncorrected" conditions. For filesystems
+    listed in <filename>/etc/fstab</filename> without <literal>nofail</literal>
+    or <literal>noauto</literal> options, <literal>local-fs.target</literal>
+    will then activate <filename>emergency.target</filename>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Kernel Command Line</title>
+
+    <para><command>systemd-fsck</command> understands these kernel
+    command line parameters:</para>
+
+    <variablelist class='kernel-commandline-options'>
+      <varlistentry>
+        <term><varname>fsck.mode=</varname></term>
+
+        <listitem><para>One of <literal>auto</literal>,
+        <literal>force</literal>, <literal>skip</literal>. Controls
+        the mode of operation. The default is <literal>auto</literal>,
+        and ensures that file system checks are done when the file
+        system checker deems them necessary. <literal>force</literal>
+        unconditionally results in full file system checks.
+        <literal>skip</literal> skips any file system
+        checks.</para>
+
+        <xi:include href="version-info.xml" xpointer="v186"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>fsck.repair=</varname></term>
+
+        <listitem><para>One of <literal>preen</literal>,
+        <literal>yes</literal>, <literal>no</literal>. Controls the
+        mode of operation. The default is <literal>preen</literal>,
+        and will automatically repair problems that can be safely
+        fixed. <literal>yes</literal> will answer yes to all
+        questions by fsck and <literal>no</literal> will answer no to
+        all questions. </para>
+
+        <xi:include href="version-info.xml" xpointer="v213"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>fsck</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-quotacheck.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry project='url'><refentrytitle url='https://btrfs.readthedocs.io/en/latest/fsck.btrfs.html'>fsck.btrfs</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>fsck.cramfs</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>fsck.ext4</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>fsck.fat</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>fsck.hfsplus</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>fsck.minix</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>fsck.ntfs</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>fsck.xfs</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-fstab-generator.xml b/man/systemd-fstab-generator.xml
new file mode 100644
index 0000000..d767f38
--- /dev/null
+++ b/man/systemd-fstab-generator.xml
@@ -0,0 +1,333 @@
+<?xml version="1.0"?>
+<!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+<refentry id="systemd-fstab-generator" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd-fstab-generator</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-fstab-generator</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-fstab-generator</refname>
+    <refpurpose>Unit generator for /etc/fstab</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>/usr/lib/systemd/system-generators/systemd-fstab-generator</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><filename>systemd-fstab-generator</filename> is a generator
+    that translates <filename>/etc/fstab</filename> (see
+    <citerefentry project='man-pages'><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for details) into native systemd units early at boot and when
+    configuration of the system manager is reloaded. This will
+    instantiate mount and swap units as necessary.</para>
+
+    <para>The <varname>passno</varname> field is treated like a simple
+    boolean, and the ordering information is discarded. However, if
+    the root file system is checked, it is checked before all the
+    other file systems.</para>
+
+    <para>See
+    <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    and
+    <citerefentry><refentrytitle>systemd.swap</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for more information about special <filename>/etc/fstab</filename>
+    mount options this generator understands.</para>
+
+    <para>One special topic is handling of symbolic links. Historical init
+    implementations supported symlinks in <filename>/etc/fstab</filename>.
+    Because mount units will refuse mounts where the target is a symbolic link,
+    this generator will resolve any symlinks as far as possible when processing
+    <filename>/etc/fstab</filename> in order to enhance backwards compatibility.
+    If a symlink target does not exist at the time that this generator runs, it
+    is assumed that the symlink target is the final target of the mount.</para>
+
+    <para><filename>systemd-fstab-generator</filename> implements
+    <citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Kernel Command Line</title>
+
+    <para><filename>systemd-fstab-generator</filename> understands the
+    following kernel command line parameters:</para>
+
+    <variablelist class='kernel-commandline-options'>
+
+      <varlistentry>
+        <term><varname>fstab=</varname></term>
+        <term><varname>rd.fstab=</varname></term>
+
+        <listitem><para>Takes a boolean argument. Defaults to <literal>yes</literal>. If
+        <literal>no</literal>, causes the generator to ignore any mounts or swap devices configured in
+        <filename>/etc/fstab</filename>. <varname>rd.fstab=</varname> is honored only in the initrd, while
+        <varname>fstab=</varname> is honored by both the main system and the initrd.</para>
+
+        <xi:include href="version-info.xml" xpointer="v186"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>root=</varname></term>
+
+        <listitem><para>Configures the operating system's root filesystem to mount when running in the
+        initrd. This accepts a device node path (usually <filename>/dev/disk/by-uuid/…</filename> or
+        <filename>/dev/disk/by-label/…</filename> or similar), or the special values <literal>gpt-auto</literal>,
+        <literal>fstab</literal>, and <literal>tmpfs</literal>.</para>
+
+        <para>Use <literal>gpt-auto</literal> to explicitly request automatic root file system discovery via
+        <citerefentry><refentrytitle>systemd-gpt-auto-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
+
+        <para>Use <literal>fstab</literal> to explicitly request automatic root file system discovery via
+        the initrd <filename>/etc/fstab</filename> rather than via kernel command line.</para>
+
+        <para>Use <literal>tmpfs</literal> in order to mount a <citerefentry
+        project='man-pages'><refentrytitle>tmpfs</refentrytitle><manvolnum>5</manvolnum></citerefentry> file
+        system as root file system of the OS. This is useful in combination with
+        <varname>mount.usr=</varname> (see below) in order to combine a volatile root file system with a
+        separate, immutable <filename>/usr/</filename> file system. Also see
+        <varname>systemd.volatile=</varname> below.</para>
+
+        <xi:include href="version-info.xml" xpointer="v217"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>rootfstype=</varname></term>
+
+        <listitem><para>Takes the root filesystem type that will be
+        passed to the mount command. <varname>rootfstype=</varname> is
+        honored by the initrd.</para>
+
+        <xi:include href="version-info.xml" xpointer="v217"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>rootflags=</varname></term>
+
+        <listitem><para>Takes the root filesystem mount options to use. <varname>rootflags=</varname> is
+        honored by the initrd.</para>
+
+        <para>Note that unlike most kernel command line options this setting does not override settings made
+        in configuration files (specifically: the mount option string in
+        <filename>/etc/fstab</filename>). See
+        <citerefentry><refentrytitle>systemd-remount-fs.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v217"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>mount.usr=</varname></term>
+
+        <listitem><para>Takes the <filename>/usr/</filename> filesystem
+        to be mounted by the initrd. If
+        <varname>mount.usrfstype=</varname> or
+        <varname>mount.usrflags=</varname> is set, then
+        <varname>mount.usr=</varname> will default to the value set in
+        <varname>root=</varname>.</para>
+
+        <para>Otherwise, this parameter defaults to the
+        <filename>/usr/</filename> entry found in
+        <filename>/etc/fstab</filename> on the root filesystem.</para>
+
+        <para><varname>mount.usr=</varname> is honored by the initrd.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v217"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>mount.usrfstype=</varname></term>
+
+        <listitem><para>Takes the <filename>/usr/</filename> filesystem
+        type that will be passed to the mount command. If
+        <varname>mount.usr=</varname> or
+        <varname>mount.usrflags=</varname> is set, then
+        <varname>mount.usrfstype=</varname> will default to the value
+        set in <varname>rootfstype=</varname>.</para>
+
+        <para>Otherwise, this value will be read from the
+        <filename>/usr/</filename> entry in
+        <filename>/etc/fstab</filename> on the root filesystem.</para>
+
+        <para><varname>mount.usrfstype=</varname> is honored by the
+        initrd.</para>
+
+        <xi:include href="version-info.xml" xpointer="v217"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>mount.usrflags=</varname></term>
+
+        <listitem><para>Takes the <filename>/usr/</filename> filesystem
+        mount options to use. If <varname>mount.usr=</varname> or
+        <varname>mount.usrfstype=</varname> is set, then
+        <varname>mount.usrflags=</varname> will default to the value
+        set in <varname>rootflags=</varname>.</para>
+
+        <para>Otherwise, this value will be read from the
+        <filename>/usr/</filename> entry in
+        <filename>/etc/fstab</filename> on the root filesystem.</para>
+
+        <para><varname>mount.usrflags=</varname> is honored by the
+        initrd.</para>
+
+        <xi:include href="version-info.xml" xpointer="v217"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>roothash=</varname></term>
+        <term><varname>usrhash=</varname></term>
+
+        <listitem><para>These options are primarily read by
+        <citerefentry><refentrytitle>systemd-veritysetup-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>. When
+        set this indicates that the root file system (or <filename>/usr/</filename>) shall be mounted from
+        Verity volumes with the specified hashes. If these kernel command line options are set the root (or
+        <filename>/usr/</filename>) file system is thus mounted from a device mapper volume
+        <filename>/dev/mapper/root</filename> (or <filename>/dev/mapper/usr</filename>).</para>
+
+        <xi:include href="version-info.xml" xpointer="v251"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>systemd.volatile=</varname></term>
+
+        <listitem><para>Controls whether the system shall boot up in volatile mode. Takes a boolean argument or the
+        special value <option>state</option>.</para>
+
+        <para>If false (the default), this generator makes no changes to the mount tree and the system is booted up in
+        normal mode.</para>
+
+        <para>If true the generator ensures
+        <citerefentry><refentrytitle>systemd-volatile-root.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        is run in the initrd. This service changes the mount table before transitioning to the host system,
+        so that a volatile memory file system (<literal>tmpfs</literal>) is used as root directory, with only
+        <filename>/usr/</filename> mounted into it from the configured root file system, in read-only mode.
+        This way the system operates in fully stateless mode, with all configuration and state reset at boot
+        and lost at shutdown, as <filename>/etc/</filename> and <filename>/var/</filename> will be served
+        from the (initially unpopulated) volatile memory file system.</para>
+
+        <para>If set to <option>state</option> the generator will leave the root directory mount point unaltered,
+        however will mount a <literal>tmpfs</literal> file system to <filename>/var/</filename>. In this mode the normal
+        system configuration (i.e. the contents of <literal>/etc/</literal>) is in effect (and may be modified during
+        system runtime), however the system state (i.e. the contents of <literal>/var/</literal>) is reset at boot and
+        lost at shutdown.</para>
+
+        <para>If this setting is set to <literal>overlay</literal> the root file system is set up as
+        <literal>overlayfs</literal> mount combining the read-only root directory with a writable
+        <literal>tmpfs</literal>, so that no modifications are made to disk, but the file system may be modified
+        nonetheless with all changes being lost at reboot.</para>
+
+        <para>Note that in none of these modes the root directory, <filename>/etc/</filename>, <filename>/var/</filename>
+        or any other resources stored in the root file system are physically removed. It's thus safe to boot a system
+        that is normally operated in non-volatile mode temporarily into volatile mode, without losing data.</para>
+
+        <para>Note that with the exception of <literal>overlay</literal> mode, enabling this setting will
+        only work correctly on operating systems that can boot up with only <filename>/usr/</filename>
+        mounted, and are able to automatically populate <filename>/etc/</filename>, and also
+        <filename>/var/</filename> in case of <literal>systemd.volatile=yes</literal>.</para>
+
+        <para>Also see <varname>root=tmpfs</varname> above, for a method to combine a
+        <literal>tmpfs</literal> file system with a regular <filename>/usr/</filename> file system (as
+        configured via <varname>mount.usr=</varname>). The main distinction between
+        <varname>systemd.volatile=yes</varname>, and <varname>root=tmpfs</varname> in combination
+        <varname>mount.usr=</varname> is that the former operates on top of a regular root file system and
+        temporarily obstructs the files and directories above its <filename>/usr/</filename> subdirectory,
+        while the latter does not hide any files, but simply mounts a unpopulated tmpfs as root file system
+        and combines it with a user picked <filename>/usr/</filename> file system.</para>
+
+        <xi:include href="version-info.xml" xpointer="v233"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>systemd.swap=</varname></term>
+
+        <listitem><para>Takes a boolean argument or enables the option if specified
+        without an argument. If disabled, causes the generator to ignore
+        any swap devices configured in <filename>/etc/fstab</filename>.
+        Defaults to enabled.</para>
+
+        <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>systemd.mount-extra=<replaceable>WHAT</replaceable>:<replaceable>WHERE</replaceable>[:<replaceable>FSTYPE</replaceable>[:<replaceable>OPTIONS</replaceable>]]</varname></term>
+        <term><varname>rd.systemd.mount-extra=<replaceable>WHAT</replaceable>:<replaceable>WHERE</replaceable>[:<replaceable>FSTYPE</replaceable>[:<replaceable>OPTIONS</replaceable>]]</varname></term>
+
+        <listitem>
+          <para>Specifies the mount unit. Takes at least two and at most four fields separated with a colon
+          (<literal>:</literal>). Each field is handled as the corresponding fstab field. This option can be
+          specified multiple times. <varname>rd.systemd.mount-extra=</varname> is honored only in the initrd,
+          while <varname>systemd.mount-extra=</varname> is honored by both the main system and the initrd.
+          In the initrd, the mount point (and also source path if the mount is bind mount) specified in
+          <varname>systemd.mount-extra=</varname> is prefixed with <filename>/sysroot/</filename>.</para>
+          <para>Example:
+          <programlisting>
+systemd.mount-extra=/dev/sda1:/mount-point:ext4:rw,noatime</programlisting>
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v254"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>systemd.swap-extra=<replaceable>WHAT</replaceable>[:<replaceable>OPTIONS</replaceable>]</varname></term>
+        <term><varname>rd.systemd.swap-extra=<replaceable>WHAT</replaceable>[:<replaceable>OPTIONS</replaceable>]</varname></term>
+
+        <listitem>
+          <para>Specifies the swap unit. Takes the block device to be used as a swap device, and optionally
+          takes mount options followed by a colon (<literal>:</literal>). This option can be specified
+          multiple times. <varname>rd.systemd.swap-extra=</varname> is honored only in the initrd, while
+          <varname>systemd.swap-extra=</varname> is honored by both the main system and the initrd.</para>
+          <para>Example:
+          <programlisting>
+systemd.swap-extra=/dev/sda2:x-systemd.makefs</programlisting>
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v254"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>System Credentials</title>
+
+    <variablelist class='system-credentials'>
+      <varlistentry>
+        <term><varname>fstab.extra</varname></term>
+
+        <listitem><para>This credential may contain addition mounts to establish, in the same format as
+        <citerefentry
+        project='man-pages'><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry>, with
+        one mount per line. It is read in addition to <filename>/etc/fstab</filename>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.swap</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-cryptsetup-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-gpt-auto-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>kernel-command-line</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <ulink url="https://systemd.io/ENVIRONMENT/">Known Environment Variables</ulink>
+    </para>
+  </refsect1>
+</refentry>
diff --git a/man/systemd-getty-generator.xml b/man/systemd-getty-generator.xml
new file mode 100644
index 0000000..91751c3
--- /dev/null
+++ b/man/systemd-getty-generator.xml
@@ -0,0 +1,121 @@
+<?xml version="1.0"?>
+<!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+<refentry id="systemd-getty-generator" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd-getty-generator</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-getty-generator</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-getty-generator</refname>
+    <refpurpose>Generator for enabling getty instances on the
+    console</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>/usr/lib/systemd/system-generators/systemd-getty-generator</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><filename>systemd-getty-generator</filename> is a generator that automatically instantiates
+    <filename>serial-getty@.service</filename> on the kernel consoles, if they can function as ttys and are
+    not provided by the virtual console subsystem. It will also instantiate
+    <filename>serial-getty@.service</filename> instances for virtualizer consoles, if execution in a
+    virtualized environment is detected. If execution in a container environment is detected, it will instead
+    enable <filename>console-getty.service</filename> for <filename>/dev/console</filename>, and
+    <filename>container-getty@.service</filename> instances for additional container pseudo TTYs as requested
+    by the container manager (see <ulink url="https://systemd.io/CONTAINER_INTERFACE"><filename>Container
+    Interface</filename></ulink>). This should ensure that the user is shown a login prompt at the right
+    place, regardless of which environment the system is started in. For example, it is sufficient to
+    redirect the kernel console with a kernel command line argument such as <varname>console=</varname> to
+    get both kernel messages and a getty prompt on a serial TTY. See <ulink
+    url="https://docs.kernel.org/admin-guide/kernel-parameters.html">The kernel's command-line
+    parameters</ulink> for more information on the <varname>console=</varname> kernel parameter.</para>
+
+    <para><filename>systemd-getty-generator</filename> implements
+    <citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
+
+    <para>Further information about configuration of gettys can be
+    found in
+    <ulink url="https://0pointer.de/blog/projects/serial-console.html">systemd
+    for Administrators, Part XVI: Gettys on Serial Consoles (and
+    Elsewhere)</ulink>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Kernel Command Line</title>
+
+    <para><filename>systemd-getty-generator</filename> understands the following
+    <citerefentry><refentrytitle>kernel-command-line</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+    parameters:</para>
+
+    <variablelist class='kernel-commandline-options'>
+      <varlistentry>
+        <term><varname>systemd.getty_auto=</varname></term>
+
+        <listitem><para>this options take an optional boolean argument, and default to yes.
+        The generator is enabled by default, and a false value may be used to disable it.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Environment</title>
+
+    <variablelist class='environment-variables'>
+      <varlistentry>
+        <term><varname>$SYSTEMD_GETTY_AUTO</varname></term>
+
+        <listitem><para>This variable takes an optional boolean argument, and default to yes.
+        The generator is enabled by default, and a false value may be used to disable it.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>System Credentials</title>
+
+    <variablelist class='system-credentials'>
+      <varlistentry>
+        <term><varname>getty.ttys.serial</varname></term>
+        <term><varname>getty.ttys.container</varname></term>
+
+        <listitem><para>These system credentials may be used to spawn additional login prompts on selected
+        TTYs. The two credentials should contain a newline-separated list of TTY names to spawn instances of
+        <filename>serial-getty@.service</filename> (in case of <varname>getty.ttys.serial</varname>) and
+        <filename>container-getty@.service</filename> (in case of <varname>getty.ttys.container</varname>)
+        on.</para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>kernel-command-line</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.system-credentials</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>agetty</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-gpt-auto-generator.xml b/man/systemd-gpt-auto-generator.xml
new file mode 100644
index 0000000..db51076
--- /dev/null
+++ b/man/systemd-gpt-auto-generator.xml
@@ -0,0 +1,329 @@
+<?xml version="1.0"?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd-gpt-auto-generator" conditional='HAVE_BLKID'
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd-gpt-auto-generator</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-gpt-auto-generator</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-gpt-auto-generator</refname>
+    <refpurpose>Generator for automatically discovering and mounting root, <filename>/home/</filename>,
+    <filename>/srv/</filename>, <filename>/var/</filename> and <filename>/var/tmp/</filename> partitions, as
+    well as discovering and enabling swap partitions, based on GPT partition type GUIDs</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>/usr/lib/systemd/system-generators/systemd-gpt-auto-generator</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><filename>systemd-gpt-auto-generator</filename> is a unit generator that automatically discovers
+    the root partition, <filename>/home/</filename>, <filename>/srv/</filename>, <filename>/var/</filename>,
+    <filename>/var/tmp/</filename>, the EFI System Partition, the Extended Boot Loader Partition, and swap
+    partitions and creates mount and swap units for them, based on the partition type GUIDs of GUID partition
+    tables (GPT). See <ulink url="https://uefi.org/specifications">UEFI Specification</ulink>, chapter 5 for
+    more details. It implements the <ulink
+    url="https://uapi-group.org/specifications/specs/discoverable_partitions_specification">Discoverable
+    Partitions Specification</ulink>.</para>
+
+    <para>Note that this generator has no effect on non-GPT systems. It will also not create mount point
+    configuration for directories which already contain files or if the mount point is explicitly configured
+    in <citerefentry
+    project='man-pages'><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry>. If
+    the units this generator creates are overridden, for example by units in directories with higher
+    precedence, drop-ins and additional dependencies created by this generator might still be used.</para>
+
+    <para>This generator will only look for the root partition on the same physical disk where the EFI System
+    Partition (ESP) is located. Note that support from the boot loader is required: the EFI variable
+    <varname>LoaderDevicePartUUID</varname> of the <constant>4a67b082-0a4c-41cf-b6c7-440b29bb8c4f</constant>
+    vendor UUID is used to determine from which partition, and hence the disk, from which the system was
+    booted. If the boot loader does not set this variable, this generator will not be able to detect the root
+    partition. See the <ulink url="https://systemd.io/BOOT_LOADER_INTERFACE">Boot Loader Interface</ulink>
+    for details.</para>
+
+    <para>Similarly, this generator will only look for the other partitions on the same physical disk as the
+    root partition. In this case, boot loader support is not required. These partitions will not be searched
+    for on systems where the root file system is distributed on multiple disks, for example via btrfs RAID.
+    </para>
+
+    <para><filename>systemd-gpt-auto-generator</filename> is useful for centralizing file system
+    configuration in the partition table and making configuration in <filename>/etc/fstab</filename> or on
+    the kernel command line unnecessary.</para>
+
+    <para>This generator looks for the partitions based on their
+    partition type GUID. The following partition type GUIDs are
+    identified:</para>
+
+    <table>
+      <title>Partition Type GUIDs</title>
+      <tgroup cols='3' align='left' colsep='1' rowsep='1'>
+        <colspec colname="guid" />
+        <colspec colname="name" />
+        <colspec colname="where" />
+        <colspec colname="explanation" />
+        <thead>
+          <row>
+            <entry>Partition Type GUID</entry>
+            <entry>Name</entry>
+            <entry>Mount Point</entry>
+            <entry>Explanation</entry>
+          </row>
+        </thead>
+        <tbody>
+          <row>
+            <entry><constant>SD_GPT_ROOT_X86_64</constant> <constant>4f68bce3-e8cd-4db1-96e7-fbcaf984b709</constant></entry>
+            <entry><filename>Root Partition (x86-64)</filename></entry>
+            <entry><filename>/</filename></entry>
+            <entry>The first partition with this type UUID, located on the same disk as the ESP, is used as the root file system <filename>/</filename> on AMD64 / 64-bit x86 systems.</entry>
+          </row>
+          <row>
+            <entry><constant>SD_GPT_ROOT_ARM64</constant> <constant>b921b045-1df0-41c3-af44-4c6f280d3fae</constant></entry>
+            <entry><filename>Root Partition (64-bit ARM)</filename></entry>
+            <entry><filename>/</filename></entry>
+            <entry>The first partition with this type UUID, located on the same disk as the ESP, is used as the root file system <filename>/</filename> on AArch64 / 64-bit ARM systems.</entry>
+          </row>
+          <row>
+            <entry>
+              <constant>SD_GPT_ROOT_ALPHA</constant> <constant>SD_GPT_ROOT_ARC</constant> <constant>SD_GPT_ROOT_ARM</constant> <constant>SD_GPT_ROOT_ARM64</constant> <constant>SD_GPT_ROOT_IA64</constant> <constant>SD_GPT_ROOT_LOONGARCH64</constant> <constant>SD_GPT_ROOT_MIPS</constant> <constant>SD_GPT_ROOT_MIPS64</constant> <constant>SD_GPT_ROOT_MIPS_LE</constant> <constant>SD_GPT_ROOT_MIPS64_LE</constant> <constant>SD_GPT_ROOT_PARISC</constant> <constant>SD_GPT_ROOT_PPC</constant> <constant>SD_GPT_ROOT_PPC64</constant> <constant>SD_GPT_ROOT_PPC64_LE</constant> <constant>SD_GPT_ROOT_RISCV32</constant> <constant>SD_GPT_ROOT_RISCV64</constant> <constant>SD_GPT_ROOT_S390</constant> <constant>SD_GPT_ROOT_S390X</constant> <constant>SD_GPT_ROOT_TILEGX</constant> <constant>SD_GPT_ROOT_X86</constant> <constant>SD_GPT_ROOT_X86_64</constant> <constant>SD_GPT_USR_ALPHA</constant> <constant>SD_GPT_USR_ARC</constant> <constant>SD_GPT_USR_ARM</constant> <constant>SD_GPT_USR_IA64</constant> <constant>SD_GPT_USR_LOONGARCH64</constant> <constant>SD_GPT_USR_MIPS_LE</constant> <constant>SD_GPT_USR_MIPS64_LE</constant> <constant>SD_GPT_USR_PARISC</constant> <constant>SD_GPT_USR_PPC</constant> <constant>SD_GPT_USR_PPC64</constant> <constant>SD_GPT_USR_PPC64_LE</constant> <constant>SD_GPT_USR_RISCV32</constant> <constant>SD_GPT_USR_RISCV64</constant> <constant>SD_GPT_USR_S390</constant> <constant>SD_GPT_USR_S390X</constant> <constant>SD_GPT_USR_TILEGX</constant> <constant>SD_GPT_USR_X86</constant>
+            </entry>
+            <entry>root partitions for other architectures</entry>
+            <entry><filename>/</filename></entry>
+            <entry>The first partition with the type UUID matching the architecture, located on the same disk as the ESP, is used as the root file system <filename>/</filename>. For the full list and constant values, see <ulink url="https://uapi-group.org/specifications/specs/discoverable_partitions_specification">Discoverable Partitions Specification</ulink>.</entry>
+          </row>
+          <row>
+            <entry><constant>SD_GPT_HOME</constant> <constant>933ac7e1-2eb4-4f13-b844-0e14e2aef915</constant></entry>
+            <entry>Home Partition</entry>
+            <entry><filename>/home/</filename></entry>
+            <entry>The first partition with this type UUID on the same disk as the ESP is mounted to <filename>/home/</filename>.</entry>
+          </row>
+          <row>
+            <entry><constant>SD_GPT_SRV</constant> <constant>3b8f8425-20e0-4f3b-907f-1a25a76f98e8</constant></entry>
+            <entry>Server Data Partition</entry>
+            <entry><filename>/srv/</filename></entry>
+            <entry>The first partition with this type UUID on the same disk as the ESP is mounted to <filename>/srv/</filename>.</entry>
+          </row>
+          <row>
+            <entry><constant>SD_GPT_VAR</constant> <constant>4d21b016-b534-45c2-a9fb-5c16e091fd2d</constant></entry>
+            <entry>Variable Data Partition</entry>
+            <entry><filename>/var/</filename></entry>
+            <entry>The first partition with this type UUID on the same disk as the ESP is mounted to <filename>/var/</filename> — under the condition its partition UUID matches the first 128 bit of the HMAC-SHA256 of the GPT type uuid of this partition keyed by the machine ID of the installation stored in <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</entry>
+          </row>
+          <row>
+            <entry><constant>SD_GPT_TMP</constant> <constant>7ec6f557-3bc5-4aca-b293-16ef5df639d1</constant></entry>
+            <entry>Temporary Data Partition</entry>
+            <entry><filename>/var/tmp/</filename></entry>
+            <entry>The first partition with this type UUID on the same disk as the ESP is mounted to <filename>/var/tmp/</filename>.</entry>
+          </row>
+          <row>
+            <entry><constant>SD_GPT_SWAP</constant> <constant>0657fd6d-a4ab-43c4-84e5-0933c84b4f4f</constant></entry>
+            <entry>Swap</entry>
+            <entry>n/a</entry>
+            <entry>All partitions with this type UUID on the same disk as the ESP are used as swap.</entry>
+          </row>
+          <row>
+            <entry><constant>SD_GPT_ESP</constant> <constant>c12a7328-f81f-11d2-ba4b-00a0c93ec93b</constant></entry>
+            <entry>EFI System Partition (ESP)</entry>
+            <entry><filename>/efi/</filename> or <filename>/boot/</filename></entry>
+            <entry>The first partition with this type UUID located on the same disk as the root partition is mounted to <filename>/boot/</filename> or <filename>/efi/</filename>, see below.</entry>
+          </row>
+          <row>
+            <entry><constant>SD_GPT_XBOOTLDR</constant> <constant>bc13c2ff-59e6-4262-a352-b275fd6f7172</constant></entry>
+            <entry>Extended Boot Loader Partition</entry>
+            <entry><filename>/boot/</filename></entry>
+            <entry>The first partition with this type UUID located on the same disk as the root partition is mounted to <filename>/boot/</filename>, see below.</entry>
+          </row>
+        </tbody>
+      </tgroup>
+    </table>
+
+    <para>This generator understands the following attribute flags for partitions:</para>
+
+    <table>
+      <title>Partition Attribute Flags</title>
+      <tgroup cols='3' align='left' colsep='1' rowsep='1'>
+        <colspec colname="flag" />
+        <colspec colname="where" />
+        <colspec colname="explanation" />
+        <thead>
+          <row>
+            <entry>Flag</entry>
+            <entry>Applicable to</entry>
+            <entry>Explanation</entry>
+          </row>
+        </thead>
+        <tbody>
+          <row>
+            <entry><constant>SD_GPT_FLAG_READ_ONLY</constant> <constant>0x1000000000000000</constant></entry>
+            <entry><filename>/</filename>, <filename>/home/</filename>, <filename>/srv/</filename>, <filename>/var/</filename>, <filename>/var/tmp/</filename>, Extended Boot Loader Partition</entry>
+            <entry>Partition is mounted read-only</entry>
+          </row>
+
+          <row>
+            <entry><constant>SD_GPT_FLAG_NO_AUTO</constant> <constant>0x8000000000000000</constant></entry>
+            <entry><filename>/</filename>, <filename>/home/</filename>, <filename>/srv/</filename>, <filename>/var/</filename>, <filename>/var/tmp/</filename>, Extended Boot Loader Partition</entry>
+            <entry>Partition is not mounted automatically</entry>
+          </row>
+
+          <row>
+            <entry><constant>SD_GPT_FLAG_NO_BLOCK_IO_PROTOCOL</constant> <constant>0x0000000000000002</constant></entry>
+            <entry>EFI System Partition (ESP)</entry>
+            <entry>Partition is not mounted automatically</entry>
+          </row>
+        </tbody>
+      </tgroup>
+    </table>
+
+    <para>The <filename>/home/</filename>, <filename>/srv/</filename>, <filename>/var/</filename>,
+    <filename>/var/tmp/</filename> and swap partitions may be encrypted in LUKS format. In this case, a
+    device mapper device is set up under the names <filename>/dev/mapper/home</filename>,
+    <filename>/dev/mapper/srv</filename>, <filename>/dev/mapper/var</filename>,
+    <filename>/dev/mapper/tmp</filename> or <filename>/dev/mapper/swap</filename>. Note that this might
+    create conflicts if the same partition is listed in <filename>/etc/crypttab</filename> with a different
+    device mapper device name.</para>
+
+    <para>When systemd is running in the initrd the <filename>/</filename> partition may be encrypted with
+    LUKS as well. In this case, a device mapper device is set up under the name
+    <filename>/dev/mapper/root</filename>, and a <filename>sysroot.mount</filename> is set up that mounts the
+    device under <filename>/sysroot</filename>. For more information, see
+    <citerefentry><refentrytitle>bootup</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
+    </para>
+
+    <para>The root partition can be specified by symlinking <filename>/run/systemd/volatile-root</filename>
+    to <filename>/dev/block/$major:$minor</filename>. This is especially useful if the root mount has been
+    replaced by some form of volatile file system (overlayfs).
+    </para>
+
+    <para>Mount and automount units for the EFI System Partition (ESP) and Extended Boot Loader Partition
+    (XBOOTLDR) are generated on EFI systems. If the disk contains an XBOOTLDR partition, as defined in the
+    <ulink url="https://uapi-group.org/specifications/specs/boot_loader_specification">Boot Loader
+    Specification</ulink>, it is made available at <filename>/boot/</filename>. This generator creates an
+    automount unit; the mount will only be activated on-demand when accessed. The mount point will be created
+    if necessary.</para>
+
+    <para>The ESP is mounted to <filename>/boot/</filename> if that directory exists and is not used for
+    XBOOTLDR, and otherwise to <filename>/efi/</filename>. Same as for <filename>/boot/</filename>, an
+    automount unit is used. The mount point will be created if necessary.</para>
+
+    <para>No configuration is created for mount points that are configured in <citerefentry
+    project='man-pages'><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry> or when
+    the target directory contains files.</para>
+
+    <para>When using this generator in conjunction with btrfs file
+    systems, make sure to set the correct default subvolumes on them,
+    using <command>btrfs subvolume set-default</command>.</para>
+
+    <para>If the system was booted via
+    <citerefentry><refentrytitle>systemd-stub</refentrytitle><manvolnum>7</manvolnum></citerefentry> and the
+    stub reported to userspace that the kernel image was measured to a TPM2 PCR, then any discovered root and
+    <filename>/var/</filename> volume identifiers (and volume encryption key in case it is encrypted) will be
+    automatically measured into PCR 15 on activation, via
+    <citerefentry><refentrytitle>systemd-pcrfs@.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
+
+    <para><filename>systemd-gpt-auto-generator</filename> implements
+    <citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Kernel Command Line</title>
+
+    <para><filename>systemd-gpt-auto-generator</filename> understands the following kernel command line
+    parameters:</para>
+
+    <variablelist class='kernel-commandline-options'>
+
+      <varlistentry>
+        <term><varname>systemd.gpt_auto</varname></term>
+        <term><varname>rd.systemd.gpt_auto</varname></term>
+
+        <listitem><para>Those options take an optional boolean argument, and default to yes.
+        The generator is enabled by default, and a false value may be used to disable it
+        (e.g. <literal>systemd.gpt_auto=0</literal>).
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v242"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>systemd.image_policy=</varname></term>
+        <term><varname>rd.systemd.image_policy=</varname></term>
+
+        <listitem><para>Takes an image dissection policy string as argument (as per
+        <citerefentry><refentrytitle>systemd.image-policy</refentrytitle><manvolnum>7</manvolnum></citerefentry>),
+        and allows enforcing a policy on dissection and use of the automatically discovered GPT partition
+        table entries.</para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>root=</varname></term>
+        <term><varname>rootfstype=</varname></term>
+        <term><varname>rootflags=</varname></term>
+
+        <listitem><para>When <varname>root=</varname> is used with the special value
+        <literal>gpt-auto</literal> (or if the parameter is not used at all), automatic discovery of the root
+        partition based on the GPT partition type is enabled. Any other value disables this
+        logic.</para>
+
+        <para>The <varname>rootfstype=</varname> and <varname>rootflags=</varname> are used to select the
+        file system type and options when the root file system is automatically discovered.</para>
+
+        <xi:include href="version-info.xml" xpointer="v242"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>rw</varname></term>
+        <term><varname>ro</varname></term>
+
+        <listitem><para>Mount the root partition read-write or read-only <emphasis>initially</emphasis>.</para>
+
+        <para>Note that unlike most kernel command line options these settings do not override configuration
+        in the file system, and the file system may be remounted later. See
+        <citerefentry><refentrytitle>systemd-remount-fs.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v242"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>systemd.swap=</varname></term>
+
+        <listitem><para>Takes a boolean argument or enables the option if specified without an argument.
+        If disabled, automatic discovery of swap partition(s) based on GPT partition type is disabled.
+        Defaults to enabled.</para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.swap</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-cryptsetup@.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-pcrfs@.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry project='die-net'><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry project='url'><refentrytitle url='https://btrfs.readthedocs.io/en/latest/btrfs.html'>btrfs</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-hibernate-resume-generator.xml b/man/systemd-hibernate-resume-generator.xml
new file mode 100644
index 0000000..9771350
--- /dev/null
+++ b/man/systemd-hibernate-resume-generator.xml
@@ -0,0 +1,100 @@
+<?xml version="1.0"?>
+<!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+<refentry id="systemd-hibernate-resume-generator" conditional='ENABLE_HIBERNATE'
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd-hibernate-resume-generator</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-hibernate-resume-generator</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-hibernate-resume-generator</refname>
+    <refpurpose>Unit generator for resume= kernel parameter</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>/usr/lib/systemd/system-generators/systemd-hibernate-resume-generator</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>systemd-hibernate-resume-generator</command> is a
+    generator that initiates the procedure to resume the system from hibernation.
+    It creates the
+    <citerefentry><refentrytitle>systemd-hibernate-resume.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    unit according to the value of <option>resume=</option> parameter
+    specified on the kernel command line, or the value of EFI variable
+    <varname>HibernateLocation</varname>, which will instruct the kernel
+    to resume the system from the hibernation image on that device.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Kernel Command Line</title>
+
+    <para><filename>systemd-hibernate-resume-generator</filename>
+    understands the following kernel command line parameters:</para>
+
+    <variablelist class='kernel-commandline-options'>
+
+      <varlistentry>
+        <term><varname>resume=</varname></term>
+
+        <listitem><para>Takes a path to the resume device. Both
+        persistent block device paths like
+        <filename index="false">/dev/disk/by-foo/bar</filename> and
+        <citerefentry project='man-pages'><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry>-style
+        specifiers like <literal>FOO=bar</literal> are
+        supported.</para>
+
+        <xi:include href="version-info.xml" xpointer="v217"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>resume_offset=</varname></term>
+
+        <listitem><para>Takes the page offset of the swap space from the resume device.
+        Defaults to <literal>0</literal>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>resumeflags=</varname></term>
+
+        <listitem><para>Takes the resume device mount options to
+        use. Defaults <varname>rootflags=</varname> if not specified.</para>
+
+        <xi:include href="version-info.xml" xpointer="v243"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>noresume</varname></term>
+
+        <listitem><para>Do not try to resume from hibernation. If this parameter is
+        present, <varname>resume=</varname> is ignored.</para>
+
+        <xi:include href="version-info.xml" xpointer="v240"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-hibernate-resume.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>kernel-command-line</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-hibernate-resume.service.xml b/man/systemd-hibernate-resume.service.xml
new file mode 100644
index 0000000..964c2bd
--- /dev/null
+++ b/man/systemd-hibernate-resume.service.xml
@@ -0,0 +1,53 @@
+<?xml version="1.0"?>
+<!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+<refentry id="systemd-hibernate-resume.service" conditional='ENABLE_HIBERNATE'>
+
+  <refentryinfo>
+    <title>systemd-hibernate-resume.service</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-hibernate-resume.service</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-hibernate-resume.service</refname>
+    <refname>systemd-hibernate-resume</refname>
+    <refpurpose>Resume from hibernation</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>systemd-hibernate-resume.service</filename></para>
+    <para><filename>/usr/lib/systemd/systemd-hibernate-resume</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><filename>systemd-hibernate-resume.service</filename> initiates the resume from hibernation.</para>
+
+    <para><command>systemd-hibernate-resume</command> only supports the in-kernel hibernation
+    implementation, see <ulink url="https://docs.kernel.org/power/swsusp.html">Swap suspend</ulink>.
+    Internally, it works by writing the major:minor of specified device node to
+    <filename>/sys/power/resume</filename>, along with the offset in memory pages
+    (<filename>/sys/power/resume_offset</filename>) if supported.</para>
+
+    <para>Failing to initiate a resume is not an error condition. It may mean that there was
+    no resume image (e. g. if the system has been simply powered off and not hibernated).
+    In such cases, the boot is ordinarily continued.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-hibernate-resume-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-homed.service.xml b/man/systemd-homed.service.xml
new file mode 100644
index 0000000..e14752b
--- /dev/null
+++ b/man/systemd-homed.service.xml
@@ -0,0 +1,117 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd-homed.service" conditional='ENABLE_HOMED'
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd-homed.service</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-homed.service</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-homed.service</refname>
+    <refname>systemd-homed</refname>
+    <refpurpose>Home Area/User Account Manager</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>systemd-homed.service</filename></para>
+    <para><filename>/usr/lib/systemd/systemd-homed</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>systemd-homed</command> is a system service that may be used to create, remove, change or
+    inspect home areas (directories and network mounts and real or loopback block devices with a filesystem,
+    optionally encrypted).</para>
+
+    <para>Most of <command>systemd-homed</command>'s functionality is accessible through the
+    <citerefentry><refentrytitle>homectl</refentrytitle><manvolnum>1</manvolnum></citerefentry> command.</para>
+
+    <para>See the <ulink url="https://systemd.io/HOME_DIRECTORY">Home Directories</ulink> documentation for
+    details about the format and design of home areas managed by
+    <filename>systemd-homed.service</filename>.</para>
+
+    <para>Each home directory managed by <filename>systemd-homed.service</filename> synthesizes a local user
+    and group. These are made available to the system using the <ulink
+    url="https://systemd.io/USER_GROUP_API">User/Group Record Lookup API via Varlink</ulink>, and thus may be
+    browsed with
+    <citerefentry><refentrytitle>userdbctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Key Management</title>
+
+    <para>User records are cryptographically signed with a public/private key pair (the signature is part of
+    the JSON record itself). For a user to be permitted to log in locally the public key matching the
+    signature of their user record must be installed. For a user record to be modified locally the private
+    key matching the signature must be installed locally, too. The keys are stored in the
+    <filename>/var/lib/systemd/home/</filename> directory:</para>
+
+    <variablelist>
+
+      <varlistentry>
+        <term><filename>/var/lib/systemd/home/local.private</filename></term>
+
+        <listitem><para>The private key of the public/private key pair used for local records. Currently,
+        only a single such key may be installed.</para>
+
+        <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>/var/lib/systemd/home/local.public</filename></term>
+
+        <listitem><para>The public key of the public/private key pair used for local records. Currently,
+        only a single such key may be installed.</para>
+
+        <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>/var/lib/systemd/home/*.public</filename></term>
+
+        <listitem><para>Additional public keys. Any users whose user records are signed with any of these keys
+        are permitted to log in locally. An arbitrary number of keys may be installed this
+        way.</para>
+
+        <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+      </varlistentry>
+    </variablelist>
+
+    <para>All key files listed above are in PEM format.</para>
+
+    <para>In order to migrate a home directory from a host <literal>foobar</literal> to another host
+    <literal>quux</literal> it is hence sufficient to copy
+    <filename>/var/lib/systemd/home/local.public</filename> from the host <literal>foobar</literal> to
+    <literal>quux</literal>, maybe calling the file on the destination <filename
+    index="false">/var/lib/systemd/home/foobar.public</filename>, reflecting the origin of the key. If the
+    user record should be modifiable on <literal>quux</literal> the pair
+    <filename>/var/lib/systemd/home/local.public</filename> and
+    <filename>/var/lib/systemd/home/local.private</filename> need to be copied from <literal>foobar</literal>
+    to <literal>quux</literal>, and placed under the identical paths there, as currently only a single
+    private key is supported per host. Note of course that the latter means that user records
+    generated/signed before the key pair is copied in, lose their validity.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>homed.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>homectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>pam_systemd_home</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>userdbctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>org.freedesktop.home1</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+</refentry>
diff --git a/man/systemd-hostnamed.service.xml b/man/systemd-hostnamed.service.xml
new file mode 100644
index 0000000..0e42f67
--- /dev/null
+++ b/man/systemd-hostnamed.service.xml
@@ -0,0 +1,82 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd-hostnamed.service" conditional='ENABLE_HOSTNAMED'>
+
+  <refentryinfo>
+    <title>systemd-hostnamed.service</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-hostnamed.service</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-hostnamed.service</refname>
+    <refname>systemd-hostnamed</refname>
+    <refpurpose>Daemon to control system hostname from programs</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>systemd-hostnamed.service</filename></para>
+    <para><filename>/usr/lib/systemd/systemd-hostnamed</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><filename>systemd-hostnamed.service</filename> is a system service that may be used to change the
+    system's hostname and related machine metadata from user programs. It is automatically activated on
+    request and terminates itself when unused.</para>
+
+    <para>It currently offers access to five variables:
+    <itemizedlist>
+      <listitem><para>The current hostname (Example: <literal>dhcp-192-168-47-11</literal>)</para>
+      </listitem>
+
+      <listitem><para>The static (configured) hostname (Example:
+      <literal>lennarts-computer</literal>)</para></listitem>
+
+      <listitem><para>The pretty hostname (Example: <literal>Lennart's Computer</literal>)</para>
+      </listitem>
+
+      <listitem><para>A suitable icon name for the local host (Example:
+      <literal>computer-laptop</literal>)</para></listitem>
+
+      <listitem><para>A chassis type (Example: <literal>tablet</literal>)</para>
+      </listitem>
+    </itemizedlist></para>
+
+    <para>The static hostname is stored in <filename>/etc/hostname</filename>, see
+    <citerefentry><refentrytitle>hostname</refentrytitle><manvolnum>5</manvolnum></citerefentry> for more
+    information. The pretty hostname, chassis type, and icon name are stored in
+    <filename>/etc/machine-info</filename>, see
+    <citerefentry><refentrytitle>machine-info</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+
+    <para>The tool
+    <citerefentry><refentrytitle>hostnamectl</refentrytitle><manvolnum>1</manvolnum></citerefentry> is a
+    command line client to this service.</para>
+
+    <para>See
+    <citerefentry><refentrytitle>org.freedesktop.hostname1</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    and
+    <citerefentry><refentrytitle>org.freedesktop.LogControl1</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for a description of the D-Bus API.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>hostname</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>machine-info</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>hostnamectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sethostname</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-hwdb.xml b/man/systemd-hwdb.xml
new file mode 100644
index 0000000..de71f1d
--- /dev/null
+++ b/man/systemd-hwdb.xml
@@ -0,0 +1,90 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd-hwdb" conditional="ENABLE_HWDB"
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd-hwdb</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-hwdb</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-hwdb</refname><refpurpose>hardware database management tool</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <cmdsynopsis>
+      <command>systemd-hwdb <optional>options</optional> update</command>
+    </cmdsynopsis>
+    <cmdsynopsis>
+      <command>systemd-hwdb <optional>options</optional> query <replaceable>modalias</replaceable></command>
+    </cmdsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1><title>Description</title>
+    <para><command>systemd-hwdb</command> expects a command and command
+    specific arguments.  It manages the binary hardware database.</para>
+  </refsect1>
+
+  <refsect1><title>Options</title>
+    <variablelist>
+      <varlistentry>
+        <term><option>--usr</option></term>
+        <listitem>
+          <para>Generate in /usr/lib/udev instead of /etc/udev.</para>
+
+        <xi:include href="version-info.xml" xpointer="v219"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><option>-r</option></term>
+        <term><option>--root=<replaceable>PATH</replaceable></option></term>
+        <listitem>
+          <para>Alternate root path in the filesystem.</para>
+
+        <xi:include href="version-info.xml" xpointer="v219"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><option>-s</option></term>
+        <term><option>--strict</option></term>
+        <listitem>
+          <para>When updating, return non-zero exit value on any parsing error.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/>
+        </listitem>
+      </varlistentry>
+
+      <xi:include href="standard-options.xml" xpointer="help" />
+    </variablelist>
+
+    <refsect2><title>systemd-hwdb
+      <arg choice="opt"><replaceable>options</replaceable></arg>
+      update</title>
+      <para>Update the binary database.</para>
+    </refsect2>
+
+    <refsect2><title>systemd-hwdb
+      <arg choice="opt"><replaceable>options</replaceable></arg>
+      query
+      <arg><replaceable>MODALIAS</replaceable></arg>
+    </title>
+      <para>Query database and print result.</para>
+    </refsect2>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para><citerefentry>
+        <refentrytitle>hwdb</refentrytitle><manvolnum>7</manvolnum>
+    </citerefentry></para>
+  </refsect1>
+</refentry>
diff --git a/man/systemd-id128.xml b/man/systemd-id128.xml
new file mode 100644
index 0000000..d9378b6
--- /dev/null
+++ b/man/systemd-id128.xml
@@ -0,0 +1,211 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd-id128" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd-id128</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-id128</refentrytitle>
+    <manvolnum>1</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-id128</refname>
+    <refpurpose>Generate and print sd-128 identifiers</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <cmdsynopsis>
+      <command>systemd-id128</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="plain">new</arg>
+    </cmdsynopsis>
+
+    <cmdsynopsis>
+      <command>systemd-id128</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="plain">machine-id</arg>
+    </cmdsynopsis>
+
+    <cmdsynopsis>
+      <command>systemd-id128</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="plain">boot-id</arg>
+    </cmdsynopsis>
+
+    <cmdsynopsis>
+      <command>systemd-id128</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="plain">invocation-id</arg>
+    </cmdsynopsis>
+
+    <cmdsynopsis>
+      <command>systemd-id128</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="plain">show</arg>
+      <arg choice="opt" rep="repeat">NAME|UUID</arg>
+    </cmdsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>id128</command> may be used to conveniently print
+    <citerefentry><refentrytitle>sd-id128</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    UUIDs. What identifier is printed depends on the specific verb.</para>
+
+    <para>With <command>new</command>, a new random identifier will be generated.</para>
+
+    <para>With <command>machine-id</command>, the identifier of the current machine will be
+    printed. See
+    <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+    </para>
+
+    <para>With <command>boot-id</command>, the identifier of the current boot will be
+    printed.</para>
+
+    <para>With <command>invocation-id</command>, the identifier of the current service invocation
+    will be printed. This is available in systemd services. See
+    <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+    </para>
+
+    <para>With <command>show</command>, well-known IDs are printed (for now, only GPT partition type UUIDs),
+    along with brief identifier strings. When no arguments are specified, all known IDs are shown. When
+    arguments are specified, they may be the identifiers or ID values of one or more known IDs, which are
+    then printed with their name, or arbitrary IDs, which are then printed with a placeholder name. Combine
+    with <option>--uuid</option> to list the IDs in UUID style, i.e. the way GPT partition type UUIDs are
+    usually shown.</para>
+
+    <para><command>machine-id</command>, <command>boot-id</command>, and <command>show</command> may be
+    combined with the <option>--app-specific=<replaceable>app-id</replaceable></option> switch to generate
+    application-specific IDs. See
+    <citerefentry><refentrytitle>sd_id128_get_machine</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    for the discussion when this is useful. Support for <command>show --app-specific=</command> was added in
+    version 255.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>The following options are understood:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><option>-p</option></term>
+        <term><option>--pretty</option></term>
+
+        <listitem><para>Generate output as programming language snippets.</para>
+
+        <xi:include href="version-info.xml" xpointer="v240"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-P</option></term>
+        <term><option>--value</option></term>
+
+        <listitem><para>Only print the value. May be combined with
+        <option>-u</option>/<option>--uuid</option>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-a <replaceable>app-id</replaceable></option></term>
+        <term><option>--app-specific=<replaceable>app-id</replaceable></option></term>
+
+        <listitem><para>With this option, identifiers will be printed that are the result of hashing the
+        application identifier <replaceable>app-id</replaceable> and another ID. The
+        <replaceable>app-id</replaceable> argument must be a valid sd-id128 string identifying the
+        application. When used with <command>machine-id</command>, the other ID will be the machine ID as
+        described in
+        <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>, when
+        used with <command>boot-id</command>, the other ID will be the boot ID, and when used with
+        <command>show</command>, the other ID or IDs should be specified via the positional arguments.</para>
+
+        <xi:include href="version-info.xml" xpointer="v240"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-u</option></term>
+        <term><option>--uuid</option></term>
+
+        <listitem><para>Generate output as a UUID formatted in the "canonical representation", with five
+        groups of digits separated by hyphens. See the Wikipedia entry for
+        <ulink url="https://en.wikipedia.org/wiki/Universally_unique_identifier#Format">Universally Unique Identifiers</ulink>
+        for more discussion.</para>
+
+        <xi:include href="version-info.xml" xpointer="v244"/></listitem>
+      </varlistentry>
+
+      <xi:include href="standard-options.xml" xpointer="help" />
+      <xi:include href="standard-options.xml" xpointer="version" />
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Exit status</title>
+
+    <para>On success 0 is returned, and a non-zero failure code otherwise.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Examples</title>
+
+    <example>
+      <title>Show a well-known UUID</title>
+      <programlisting>
+$ systemd-id128 show --value user-home
+773f91ef66d449b5bd83d683bf40ad16
+
+$ systemd-id128 show --value --uuid user-home
+773f91ef-66d4-49b5-bd83-d683bf40ad16
+
+$ systemd-id128 show 773f91ef-66d4-49b5-bd83-d683bf40ad16
+NAME      ID
+user-home 773f91ef66d449b5bd83d683bf40ad16
+      </programlisting>
+    </example>
+
+    <example>
+      <title>Generate an application-specific UUID</title>
+
+      <programlisting>
+$ systemd-id128 machine-id -u
+3a9d668b-4db7-4939-8a4a-5e78a03bffb7
+
+$ systemd-id128 new -u
+1fb8f24b-02df-458d-9659-cc8ace68e28a
+
+$ systemd-id128 machine-id -u -a 1fb8f24b-02df-458d-9659-cc8ace68e28a
+47b82cb1-5339-43da-b2a6-1c350aef1bd1
+
+$ systemd-id128 -Pu show 3a9d668b-4db7-4939-8a4a-5e78a03bffb7 \
+    -a 1fb8f24b-02df-458d-9659-cc8ace68e28a
+47b82cb1-5339-43da-b2a6-1c350aef1bd1
+      </programlisting>
+
+      <para>On a given machine with the ID 3a9d668b-4db7-4939-8a4a-5e78a03bffb7, for the application
+      1fb8f24b-02df-458d-9659-cc8ace68e28a, we generate an application-specific machine ID
+      (47b82cb1-5339-43da-b2a6-1c350aef1bd1). If we want to later recreate the same calculation on a
+      different machine, we need to specify both IDs explicitly as parameters to <command>show</command>.
+      </para>
+    </example>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-id128</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_id128_get_machine</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-importd.service.xml b/man/systemd-importd.service.xml
new file mode 100644
index 0000000..1e3c17b
--- /dev/null
+++ b/man/systemd-importd.service.xml
@@ -0,0 +1,56 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd-importd.service" conditional='ENABLE_IMPORTD'>
+
+  <refentryinfo>
+    <title>systemd-importd.service</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-importd.service</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-importd.service</refname>
+    <refname>systemd-importd</refname>
+    <refpurpose>VM and container image import and export service</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>systemd-importd.service</filename></para>
+    <para><filename>/usr/lib/systemd/systemd-importd</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>systemd-importd</command> is a system service that allows importing, exporting and downloading of
+    system images suitable for running as VM or containers. It is a companion service for
+    <citerefentry><refentrytitle>systemd-machined.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, and provides the implementation for
+    <citerefentry><refentrytitle>machinectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s
+    <command>pull-raw</command>, <command>pull-tar</command>, <command>import-raw</command>,
+    <command>import-tar</command>, <command>import-fs</command>, <command>export-raw</command>, and <command>export-tar</command> commands.</para>
+
+    <para>See
+    <citerefentry><refentrytitle>org.freedesktop.import1</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    and
+    <citerefentry><refentrytitle>org.freedesktop.LogControl1</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for a description of the D-Bus API.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>machinectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-machined.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-inhibit.xml b/man/systemd-inhibit.xml
new file mode 100644
index 0000000..72276b2
--- /dev/null
+++ b/man/systemd-inhibit.xml
@@ -0,0 +1,154 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd-inhibit"
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd-inhibit</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-inhibit</refentrytitle>
+    <manvolnum>1</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-inhibit</refname>
+    <refpurpose>Execute a program with an inhibition lock taken</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <cmdsynopsis>
+      <command>systemd-inhibit <arg choice="opt" rep="repeat">OPTIONS</arg> <arg>COMMAND</arg> <arg choice="opt" rep="repeat">ARGUMENTS</arg></command>
+    </cmdsynopsis>
+    <cmdsynopsis>
+      <command>systemd-inhibit <arg choice="opt" rep="repeat">OPTIONS</arg> --list</command>
+    </cmdsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>systemd-inhibit</command> may be used to execute a
+    program with a shutdown, sleep, or idle inhibitor lock taken. The
+    lock will be acquired before the specified command line is
+    executed and released afterwards.</para>
+
+    <para>Inhibitor locks may be used to block or delay system sleep
+    and shutdown requests from the user, as well as automatic idle
+    handling of the OS. This is useful to avoid system suspends while
+    an optical disc is being recorded, or similar operations that
+    should not be interrupted.</para>
+
+    <para>For more information see the <ulink
+    url="https://www.freedesktop.org/wiki/Software/systemd/inhibit">Inhibitor
+    Lock Developer Documentation</ulink>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>The following options are understood:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><option>--what=</option></term>
+
+        <listitem><para>Takes a colon-separated list of one or more
+        operations to inhibit:
+        <literal>shutdown</literal>,
+        <literal>sleep</literal>,
+        <literal>idle</literal>,
+        <literal>handle-power-key</literal>,
+        <literal>handle-suspend-key</literal>,
+        <literal>handle-hibernate-key</literal>,
+        <literal>handle-lid-switch</literal>,
+        for inhibiting reboot/power-off/halt/kexec/soft-reboot,
+        suspending/hibernating, the automatic idle detection, or the
+        low-level handling of the power/sleep key and the lid switch,
+        respectively. If omitted, defaults to
+        <literal>idle:sleep:shutdown</literal>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--who=</option></term>
+
+        <listitem><para>Takes a short, human-readable descriptive
+        string for the program taking the lock. If not passed,
+        defaults to the command line string.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--why=</option></term>
+
+        <listitem><para>Takes a short, human-readable descriptive
+        string for the reason for taking the lock. Defaults to
+        "Unknown reason".</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--mode=</option></term>
+
+        <listitem><para>Takes either <literal>block</literal> or
+        <literal>delay</literal> and describes how the lock is
+        applied. If <literal>block</literal> is used (the default),
+        the lock prohibits any of the requested operations without
+        time limit, and only privileged users may override it. If
+        <literal>delay</literal> is used, the lock can only delay the
+        requested operations for a limited time. If the time elapses,
+        the lock is ignored and the operation executed. The time limit
+        may be specified in
+        <citerefentry><refentrytitle>logind.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+        Note that <literal>delay</literal> is only available for
+        <literal>sleep</literal> and
+        <literal>shutdown</literal>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--list</option></term>
+
+        <listitem><para>Lists all active inhibition locks instead of
+        acquiring one.</para></listitem>
+      </varlistentry>
+
+      <xi:include href="standard-options.xml" xpointer="no-pager" />
+      <xi:include href="standard-options.xml" xpointer="no-legend" />
+      <xi:include href="standard-options.xml" xpointer="help" />
+      <xi:include href="standard-options.xml" xpointer="version" />
+    </variablelist>
+
+  </refsect1>
+
+  <refsect1>
+    <title>Exit status</title>
+
+    <para>Returns the exit status of the executed program.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Example</title>
+
+    <programlisting># systemd-inhibit wodim foobar.iso</programlisting>
+
+    <para>This burns the ISO image
+    <filename>foobar.iso</filename> on a CD using
+    <citerefentry project='man-pages'><refentrytitle>wodim</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+    and inhibits system sleeping, shutdown and idle while
+    doing so.</para>
+  </refsect1>
+
+  <xi:include href="common-variables.xml" />
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>logind.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-initctl.service.xml b/man/systemd-initctl.service.xml
new file mode 100644
index 0000000..b435800
--- /dev/null
+++ b/man/systemd-initctl.service.xml
@@ -0,0 +1,49 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd-initctl.service" conditional='HAVE_SYSV_COMPAT'>
+
+  <refentryinfo>
+    <title>systemd-initctl.service</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-initctl.service</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-initctl.service</refname>
+    <refname>systemd-initctl.socket</refname>
+    <refname>systemd-initctl</refname>
+    <refpurpose>/dev/initctl compatibility</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>systemd-initctl.service</filename></para>
+    <para><filename>systemd-initctl.socket</filename></para>
+    <para><filename>/usr/lib/systemd/systemd-initctl</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><filename>systemd-initctl</filename> is a system service
+    that implements compatibility with the
+    <filename>/dev/initctl</filename> FIFO file system object, as
+    implemented by the SysV init system.
+    <filename>systemd-initctl</filename> is automatically activated on
+    request and terminates itself when it is unused.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-integritysetup-generator.xml b/man/systemd-integritysetup-generator.xml
new file mode 100644
index 0000000..3e788f1
--- /dev/null
+++ b/man/systemd-integritysetup-generator.xml
@@ -0,0 +1,48 @@
+<?xml version="1.0"?>
+<!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+<refentry id="systemd-integritysetup-generator" conditional='HAVE_LIBCRYPTSETUP'>
+
+  <refentryinfo>
+    <title>systemd-integritysetup-generator</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-integritysetup-generator</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-integritysetup-generator</refname>
+    <refpurpose>Unit generator for integrity protected block devices</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>/usr/lib/systemd/system-generators/systemd-integritysetup-generator</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>systemd-integritysetup-generator</command> is a generator that translates
+    <filename>/etc/integritytab</filename> entries into native systemd units early at boot. This will create
+    <citerefentry><refentrytitle>systemd-integritysetup@.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    units as necessary.</para>
+
+    <para><command>systemd-integritysetup-generator</command> implements
+    <citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-integritysetup@.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry project='die-net'><refentrytitle>integritysetup</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-integritysetup@.service.xml b/man/systemd-integritysetup@.service.xml
new file mode 100644
index 0000000..5a37858
--- /dev/null
+++ b/man/systemd-integritysetup@.service.xml
@@ -0,0 +1,105 @@
+<?xml version="1.0"?>
+<!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+<refentry id="systemd-integritysetup@.service" conditional='HAVE_LIBCRYPTSETUP'
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd-integritysetup@.service</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-integritysetup@.service</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-integritysetup@.service</refname>
+    <refname>systemd-integritysetup</refname>
+    <refpurpose>Disk integrity protection logic</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>systemd-integritysetup@.service</filename></para>
+    <para><filename>/usr/lib/systemd/systemd-integritysetup</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><filename>systemd-integritysetup@.service</filename> is a service responsible for setting up integrity
+    protected block devices. It should be instantiated for each device that requires integrity
+    protection.</para>
+
+    <para>At early boot and when the system manager configuration is reloaded, entries from
+    <citerefentry><refentrytitle>integritytab</refentrytitle><manvolnum>5</manvolnum></citerefentry> are
+    converted into <filename>systemd-integritysetup@.service</filename> units by
+    <citerefentry><refentrytitle>systemd-integritysetup-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
+
+    <para><filename>systemd-integritysetup@.service</filename> calls <command>systemd-integritysetup</command>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Commands</title>
+
+    <para>The following commands are understood by <command>systemd-integritysetup</command>:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term>
+          <option>attach</option>
+          <replaceable>volume</replaceable>
+          <replaceable>device</replaceable>
+          [<replaceable>key-file|-</replaceable>]
+          [<replaceable>option(s)|-</replaceable>]
+        </term>
+
+        <listitem><para>Create a block device <replaceable>volume</replaceable> using
+        <replaceable>device</replaceable>. See
+        <citerefentry><refentrytitle>integritytab</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        and
+        <ulink url="https://docs.kernel.org/admin-guide/device-mapper/dm-integrity.html">
+          Kernel dm-integrity</ulink> documentation for details.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term>
+          <option>detach</option>
+          <replaceable>volume</replaceable>
+        </term>
+
+        <listitem><para>Detach (destroy) the block device
+        <replaceable>volume</replaceable>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term>
+          <option>help</option>
+        </term>
+
+        <listitem><para>Print short information about command syntax.</para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>integritytab</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-integritysetup-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry project='die-net'><refentrytitle>integritysetup</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+     </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-journal-gatewayd.service.xml b/man/systemd-journal-gatewayd.service.xml
new file mode 100644
index 0000000..45adc2a
--- /dev/null
+++ b/man/systemd-journal-gatewayd.service.xml
@@ -0,0 +1,362 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd-journal-gatewayd.service" conditional='HAVE_MICROHTTPD'
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd-journal-gatewayd.service</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-journal-gatewayd.service</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-journal-gatewayd.service</refname>
+    <refname>systemd-journal-gatewayd.socket</refname>
+    <refname>systemd-journal-gatewayd</refname>
+    <refpurpose>HTTP server for journal events</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>systemd-journal-gatewayd.service</filename></para>
+    <para><filename>systemd-journal-gatewayd.socket</filename></para>
+    <cmdsynopsis>
+      <command>/usr/lib/systemd/systemd-journal-gatewayd</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+    </cmdsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>systemd-journal-gatewayd</command> serves journal
+    events over the network. Clients must connect using
+    HTTP. The server listens on port 19531 by default.
+    If <option>--cert=</option> is specified, the server expects
+    HTTPS connections.</para>
+
+    <para>The program is started by
+    <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    and expects to receive a single socket. Use
+    <command>systemctl start systemd-journal-gatewayd.socket</command> to start
+    the service, and <command>systemctl enable systemd-journal-gatewayd.socket</command>
+    to have it started on boot.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>The following options are understood:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><option>--cert=</option></term>
+
+        <listitem><para>Specify the path to a file or <constant>AF_UNIX</constant> stream socket to read the
+        server certificate from. The certificate must be in PEM format. This option switches
+        <command>systemd-journal-gatewayd</command> into HTTPS mode and must be used together with
+        <option>--key=</option>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v198"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--key=</option></term>
+
+        <listitem><para>Specify the path to a file or <constant>AF_UNIX</constant> stream socket to read the
+        secret server key corresponding to the certificate specified with <option>--cert=</option> from. The
+        key must be in PEM format.</para>
+
+        <xi:include href="version-info.xml" xpointer="v198"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--trust=</option></term>
+
+        <listitem><para>Specify the path to a file or <constant>AF_UNIX</constant> stream socket to read a CA
+        certificate from. The certificate must be in PEM format.</para>
+
+        <xi:include href="version-info.xml" xpointer="v236"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--system</option></term>
+        <term><option>--user</option></term>
+
+        <listitem><para>Limit served entries to entries from system
+        services and the kernel, or to entries from services of
+        current user. This has the same meaning as
+        <option>--system</option> and <option>--user</option> options
+        for
+        <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>. If
+        neither is specified, all accessible entries are served.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v249"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-m</option></term>
+        <term><option>--merge</option></term>
+
+        <listitem><para>Serve entries interleaved from all available
+        journals, including other machines. This has the same meaning
+        as <option>--merge</option> option for
+        <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v249"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-D <replaceable>DIR</replaceable></option></term>
+        <term><option>--directory=<replaceable>DIR</replaceable></option></term>
+
+        <listitem><para>Takes a directory path as argument. If
+        specified, <command>systemd-journal-gatewayd</command> will serve the
+        specified journal directory <replaceable>DIR</replaceable> instead of
+        the default runtime and system journal paths.</para>
+
+        <xi:include href="version-info.xml" xpointer="v232"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--file=<replaceable>GLOB</replaceable></option></term>
+
+        <listitem><para>Takes a file glob as an argument. Serve
+        entries from the specified journal files matching
+        <replaceable>GLOB</replaceable> instead of the default runtime
+        and system journal paths. May be specified multiple times, in
+        which case files will be suitably interleaved. This has the same meaning as
+        <option>--file=</option> option for
+        <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v249"/></listitem>
+      </varlistentry>
+
+      <xi:include href="standard-options.xml" xpointer="help" />
+      <xi:include href="standard-options.xml" xpointer="version" />
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Supported URLs</title>
+
+    <para>The following URLs are recognized:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><uri>/browse</uri></term>
+
+        <listitem><para>Interactive browsing.</para>
+
+        <xi:include href="version-info.xml" xpointer="v197"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><uri>/entries[?option1&amp;option2=value…]</uri></term>
+
+        <listitem><para>Retrieval of events in various formats.</para>
+
+        <para>The <option>Accept:</option> part of the HTTP header
+        determines the format. Supported values are described below.
+        </para>
+
+        <para>The <option>Range:</option> part of the HTTP header
+        determines the range of events returned. Supported values are
+        described below.
+        </para>
+
+        <para>GET parameters can be used to modify what events are
+        returned. Supported parameters are described below.</para>
+
+        <xi:include href="version-info.xml" xpointer="v197"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><uri>/machine</uri></term>
+
+        <listitem><para>Return a JSON structure describing the machine.</para>
+
+        <para>Example:
+        <programlisting>{ "machine_id" : "8cf7ed9d451ea194b77a9f118f3dc446",
+  "boot_id" : "3d3c9efaf556496a9b04259ee35df7f7",
+  "hostname" : "fedora",
+  "os_pretty_name" : "Fedora 19 (Rawhide)",
+  "virtualization" : "kvm",
+  …}</programlisting>
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v197"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><uri>/fields/<replaceable>FIELD_NAME</replaceable></uri></term>
+
+        <listitem><para>Return a list of values of this field present in the logs.</para>
+
+        <xi:include href="version-info.xml" xpointer="v197"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Accept header</title>
+
+    <para>
+      <option>Accept: <replaceable>format</replaceable></option>
+    </para>
+
+    <para>Recognized formats:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><constant>text/plain</constant></term>
+
+        <listitem><para>The default. Plaintext syslog-like output,
+        one line per journal entry
+        (like <command>journalctl --output short</command>).</para>
+
+        <xi:include href="version-info.xml" xpointer="v197"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><constant>application/json</constant></term>
+
+        <listitem><para>Entries are formatted as JSON data structures,
+        one per line
+        (like <command>journalctl --output json</command>).
+        See <ulink url="https://systemd.io/JOURNAL_EXPORT_FORMATS#journal-json-format">Journal JSON Format</ulink>
+        for more information.</para>
+
+        <xi:include href="version-info.xml" xpointer="v197"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><constant>text/event-stream</constant></term>
+
+        <listitem><para>Entries are formatted as JSON data structures,
+        wrapped in a format suitable for <ulink
+        url="https://developer.mozilla.org/en-US/docs/Server-sent_events/Using_server-sent_events">
+        Server-Sent Events</ulink>
+        (like <command>journalctl --output json-sse</command>).
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v229"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><constant>application/vnd.fdo.journal</constant></term>
+
+        <listitem><para>Entries are serialized into a binary (but mostly text-based) stream suitable for
+        backups and network transfer (like <command>journalctl --output export</command>).  See <ulink
+        url="https://systemd.io/JOURNAL_EXPORT_FORMATS#journal-export-format">Journal Export Format</ulink>
+        for more information.</para>
+
+        <xi:include href="version-info.xml" xpointer="v197"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Range header</title>
+
+    <para>
+      <option>Range: entries=<replaceable>cursor</replaceable>[[:<replaceable>num_skip</replaceable>]:<replaceable>num_entries</replaceable>]</option>
+    </para>
+
+    <para>where
+      <replaceable>cursor</replaceable> is a cursor string,
+      <replaceable>num_skip</replaceable> is an integer,
+      <replaceable>num_entries</replaceable> is an unsigned integer.
+    </para>
+
+    <para>Range defaults to all available events.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>URL GET parameters</title>
+
+    <para>Following parameters can be used as part of the URL:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><uri>follow</uri></term>
+
+        <listitem><para>wait for new events
+        (like <command>journalctl --follow</command>, except that
+        the number of events returned is not limited).</para>
+
+        <xi:include href="version-info.xml" xpointer="v197"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><uri>discrete</uri></term>
+
+        <listitem><para>Test that the specified cursor refers to an
+        entry in the journal. Returns just this entry.</para>
+
+        <xi:include href="version-info.xml" xpointer="v197"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><uri>boot</uri></term>
+
+        <listitem><para>Limit events to the current boot of the system
+        (like <command>journalctl -b</command>).</para>
+
+        <xi:include href="version-info.xml" xpointer="v197"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><uri><replaceable>KEY</replaceable>=<replaceable>match</replaceable></uri></term>
+
+        <listitem><para>Match journal fields. See
+        <citerefentry><refentrytitle>systemd.journal-fields</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v197"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Examples</title>
+    <para>Retrieve events from this boot from local journal in
+    <ulink url="https://systemd.io/JOURNAL_EXPORT_FORMATS#journal-export-format">Journal Export Format</ulink>:
+    <programlisting>curl --silent -H'Accept: application/vnd.fdo.journal' \
+       'http://localhost:19531/entries?boot'</programlisting>
+    </para>
+
+    <para>Listen for core dumps:
+    <programlisting>curl 'http://localhost:19531/entries?follow&amp;MESSAGE_ID=fc2e22bc6ee647b6b90729ab34a250b1'</programlisting></para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.journal-fields</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-journal-remote.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-journal-upload.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-journal-remote.service.xml b/man/systemd-journal-remote.service.xml
new file mode 100644
index 0000000..aa96e52
--- /dev/null
+++ b/man/systemd-journal-remote.service.xml
@@ -0,0 +1,378 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [
+<!ENTITY % entities SYSTEM "custom-entities.ent" >
+%entities;
+]>
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd-journal-remote" conditional='HAVE_MICROHTTPD'
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd-journal-remote.service</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-journal-remote.service</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-journal-remote.service</refname>
+    <refname>systemd-journal-remote.socket</refname>
+    <refname>systemd-journal-remote</refname>
+    <refpurpose>Receive journal messages over the network</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>systemd-journal-remote.service</filename></para>
+    <para><filename>systemd-journal-remote.socket</filename></para>
+    <cmdsynopsis>
+      <command>/usr/lib/systemd/systemd-journal-remote</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="opt" rep="norepeat">-o/--output=<replaceable>DIR</replaceable>|<replaceable>FILE</replaceable></arg>
+      <arg choice="opt" rep="repeat">SOURCES</arg>
+    </cmdsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>systemd-journal-remote</command> is a command to receive serialized journal
+    events and store them to journal files. Input streams are in the
+    <ulink url="https://systemd.io/JOURNAL_EXPORT_FORMATS#journal-export-format">Journal Export Format</ulink>,
+    i.e. like the output from <command>journalctl --output=export</command>. For transport over the
+    network, this serialized stream is usually carried over an HTTPS connection.</para>
+
+    <para><filename>systemd-journal-remote.service</filename> is a system service that uses
+    <command>systemd-journal-remote</command> to listen for connections.
+    <filename>systemd-journal-remote.socket</filename> configures the network address that
+    <filename>systemd-journal-remote.service</filename> listens on. By default this is port 19532.
+    What connections are accepted and how the received data is stored can be configured through the
+    <citerefentry><refentrytitle>journal-remote.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    configuration file.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Sources</title>
+
+    <para>
+      Sources can be either "active"
+      (<command>systemd-journal-remote</command> requests and pulls
+      the data), or "passive"
+      (<command>systemd-journal-remote</command> waits for a
+      connection and then receives events pushed by the other side).
+    </para>
+
+    <para>
+      <command>systemd-journal-remote</command> can read more than one
+      event stream at a time. They will be interleaved in the output
+      file. In case of "active" connections, each "source" is one
+      stream, and in case of "passive" connections, each connection can
+      result in a separate stream. Sockets can be configured in
+      "accept" mode (i.e. only one connection), or "listen" mode (i.e.
+      multiple connections, each resulting in a stream).
+    </para>
+
+    <para>
+      When there are no more connections, and no more can be created
+      (there are no listening sockets), then
+      <command>systemd-journal-remote</command> will exit.
+    </para>
+
+    <para>Active sources can be specified in the following
+    ways:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><arg choice="opt" rep="repeat">SOURCES</arg></term>
+
+        <listitem><para>When <option>-</option> is given as a
+        positional argument, events will be read from standard input.
+        Other positional arguments will be treated as filenames
+        to open and read from.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--url=<replaceable>ADDRESS</replaceable></option></term>
+
+        <listitem><para>With the
+        <option>--url=<replaceable>ADDRESS</replaceable></option> option,
+        events will be retrieved using HTTP from
+        <replaceable>ADDRESS</replaceable>. This URL should refer to the
+        root of a remote
+        <citerefentry><refentrytitle>systemd-journal-gatewayd</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        instance, e.g. http://some.host:19531/ or
+        https://some.host:19531/.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--getter='<replaceable>PROG</replaceable> <arg choice="opt" rep="repeat">OPTIONS</arg>'</option></term>
+
+        <listitem><para>Program to invoke to retrieve data. The journal
+        event stream must be generated on standard output.</para>
+
+        <para>Examples:</para>
+
+        <programlisting>--getter='curl "-HAccept: application/vnd.fdo.journal" https://some.host:19531/'</programlisting>
+
+        <programlisting>--getter='wget --header="Accept: application/vnd.fdo.journal" -O- https://some.host:19531/'</programlisting>
+
+        <xi:include href="version-info.xml" xpointer="v239"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+
+    <para>Passive sources can be specified in the following
+    ways:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><option>--listen-raw=<replaceable>ADDRESS</replaceable></option></term>
+
+        <listitem><para><replaceable>ADDRESS</replaceable> must be an
+        address suitable for <option>ListenStream=</option> (cf.
+        <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
+        <command>systemd-journal-remote</command> will listen on this
+        socket for connections. Each connection is expected to be a
+        stream of journal events.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--listen-http=<replaceable>ADDRESS</replaceable></option></term>
+        <term><option>--listen-https=<replaceable>ADDRESS</replaceable></option></term>
+
+        <listitem><para><replaceable>ADDRESS</replaceable> must be
+        either a negative integer, in which case it will be
+        interpreted as the (negated) file descriptor number, or an
+        address suitable for <option>ListenStream=</option> (c.f.
+        <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
+        In the first case, the server listens on port 19532 by default,
+        and the matching file descriptor must be inherited through
+        <varname>$LISTEN_FDS</varname>/<varname>$LISTEN_PID</varname>.
+        In the second case, an HTTP or HTTPS server will be spawned on
+        this port, respectively for <option>--listen-http=</option> and
+        <option>--listen-https=</option>. Currently, only POST requests
+        to <filename>/upload</filename> with <literal>Content-Type:
+        application/vnd.fdo.journal</literal> are supported.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>$LISTEN_FDS</varname></term>
+
+        <listitem><para><command>systemd-journal-remote</command>
+        supports the
+        <varname>$LISTEN_FDS</varname>/<varname>$LISTEN_PID</varname>
+        protocol. Open sockets inherited through socket activation
+        behave like those opened with <option>--listen-raw=</option>
+        described above, unless they are specified as an argument in
+        <option>--listen-http=-<replaceable>n</replaceable></option>
+        or
+        <option>--listen-https=-<replaceable>n</replaceable></option>
+        above. In the latter case, an HTTP or HTTPS server will be
+        spawned using this descriptor and connections must be made
+        over the HTTP protocol.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--key=</option></term>
+
+        <listitem><para>Takes a path to a SSL secret key file in PEM format. Defaults to
+        <filename>&CERTIFICATE_ROOT;/private/journal-remote.pem</filename>. This option can be used with
+        <option>--listen-https=</option>. If the path refers to an <constant>AF_UNIX</constant> stream socket
+        in the file system a connection is made to it and the key read from it.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--cert=</option></term>
+
+        <listitem><para> Takes a path to a SSL certificate file in PEM format. Defaults to
+        <filename>&CERTIFICATE_ROOT;/certs/journal-remote.pem</filename>. This option can be used with
+        <option>--listen-https=</option>. If the path refers to an <constant>AF_UNIX</constant> stream socket
+        in the file system a connection is made to it and the certificate read from it.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--trust=</option></term>
+
+        <listitem><para> Takes a path to a SSL CA certificate file in PEM format, or <option>all</option>. If
+        <option>all</option> is set, then certificate checking will be disabled. Defaults to
+        <filename>&CERTIFICATE_ROOT;/ca/trusted.pem</filename>. This option can be used with
+        <option>--listen-https=</option>. If the path refers to an <constant>AF_UNIX</constant> stream socket
+        in the file system a connection is made to it and the certificate read from it.</para>
+
+ <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--gnutls-log=</option></term>
+
+        <listitem><para>
+          Takes a comma separated list of gnutls logging categories.
+          This option can be used with <option>--listen-http=</option> or
+          <option>--listen-https=</option>.
+        </para>
+
+          <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Sinks</title>
+
+    <para>The location of the output journal can be specified
+    with <option>-o</option> or <option>--output=</option>.
+    </para>
+
+    <variablelist>
+      <varlistentry>
+        <term><option>-o <replaceable>FILE</replaceable></option></term>
+        <term><option>--output=<replaceable>FILE</replaceable></option></term>
+
+        <listitem><para>Will write to this journal file. The filename
+        must end with <filename>.journal</filename>. The file will be
+        created if it does not exist. If necessary (journal file full,
+        or corrupted), the file will be renamed following normal
+        journald rules and a new journal file will be created in its
+        stead.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-o <replaceable>DIR</replaceable></option></term>
+        <term><option>--output=<replaceable>DIR</replaceable></option></term>
+
+        <listitem><para>Will create journal files underneath directory
+        <replaceable>DIR</replaceable>. The directory must exist. If
+        necessary (journal files over size, or corrupted), journal
+        files will be rotated following normal journald rules. Names
+        of files underneath <replaceable>DIR</replaceable> will be
+        generated using the rules described below.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+    </variablelist>
+
+    <para>If <option>--output=</option> is not used, the output
+    directory <filename>/var/log/journal/remote/</filename> will be
+    used.  In case the output file is not specified, journal files
+    will be created underneath the selected directory. Files will be
+    called
+    <filename>remote-<replaceable>hostname</replaceable>.journal</filename>,
+    where the <replaceable>hostname</replaceable> part is the
+    escaped hostname of the source endpoint of the connection, or the
+    numerical address if the hostname cannot be determined.</para>
+
+    <para>In the case that "active" sources are given by the positional
+    arguments or <option>--getter=</option> option, the output file name
+    must always be given explicitly.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>The following options are understood:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><option>--split-mode</option></term>
+
+        <listitem><para>One of <constant>none</constant> or
+        <constant>host</constant>. For the first, only one output
+        journal file is used. For the latter, a separate output file
+        is used, based on the hostname of the other endpoint of a
+        connection.</para>
+
+        <para>In the case that "active" sources are given by the positional
+        arguments or <option>--getter=</option> option, the output file name must
+        always be given explicitly and only <constant>none</constant>
+        is allowed.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--compress</option> [<replaceable>BOOL</replaceable>]</term>
+
+        <listitem><para>If this is set to <literal>yes</literal> then compress
+        the data in the journal using XZ. The default is <literal>yes</literal>.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--seal</option> [<replaceable>BOOL</replaceable>]</term>
+
+        <listitem><para>If this is set to <literal>yes</literal> then
+        periodically sign the data in the journal using Forward Secure Sealing.
+        The default is <literal>no</literal>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <xi:include href="standard-options.xml" xpointer="help" />
+      <xi:include href="standard-options.xml" xpointer="version" />
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Examples</title>
+    <para>Copy local journal events to a different journal directory:
+    <programlisting>
+journalctl -o export | systemd-journal-remote -o /tmp/dir/foo.journal -
+    </programlisting>
+    </para>
+
+    <para>Retrieve all available events from a remote
+    <citerefentry><refentrytitle>systemd-journal-gatewayd</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    instance and store them in
+    <filename>/var/log/journal/remote/remote-some.host.journal</filename>:
+    <programlisting>
+systemd-journal-remote --url http://some.host:19531/
+    </programlisting>
+    </para>
+
+    <para>Retrieve current boot events and wait for new events from a remote
+    <citerefentry><refentrytitle>systemd-journal-gatewayd</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    instance, and store them in
+    <filename>/var/log/journal/remote/remote-some.host.journal</filename>:
+    <programlisting>
+systemd-journal-remote --url http://some.host:19531/entries?boot&amp;follow
+    </programlisting>
+    </para>
+</refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>journal-remote.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-journal-gatewayd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-journal-upload.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+</refentry>
diff --git a/man/systemd-journal-upload.service.xml b/man/systemd-journal-upload.service.xml
new file mode 100644
index 0000000..fead24c
--- /dev/null
+++ b/man/systemd-journal-upload.service.xml
@@ -0,0 +1,329 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [
+<!ENTITY % entities SYSTEM "custom-entities.ent" >
+%entities;
+]>
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd-journal-upload" conditional='HAVE_MICROHTTPD'
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd-journal-upload.service</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-journal-upload.service</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-journal-upload.service</refname>
+    <refname>systemd-journal-upload</refname>
+    <refpurpose>Send journal messages over the network</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>systemd-journal-upload.service</filename></para>
+    <cmdsynopsis>
+      <command>/usr/lib/systemd/systemd-journal-upload</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="opt" rep="norepeat">-u/--url=<replaceable>URL</replaceable></arg>
+      <arg choice="opt" rep="repeat">SOURCES</arg>
+    </cmdsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>systemd-journal-upload</command> will upload journal entries to the URL specified
+    with <option>--url=</option>. This program reads journal entries from one or more journal files,
+    similarly to
+    <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
+    Unless limited by one of the options specified below, all journal entries accessible to the user
+    the program is running as will be uploaded, and then the program will wait and send new entries
+    as they become available.</para>
+    
+    <para><command>systemd-journal-upload</command> transfers the raw content of journal file and
+    uses HTTP as a transport protocol.</para> 
+    
+    <para><filename>systemd-journal-upload.service</filename> is a system service that uses
+    <command>systemd-journal-upload</command> to upload journal entries to a server. It uses the
+    configuration in
+    <citerefentry><refentrytitle>journal-upload.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+    At least the <varname>URL=</varname> option must be specified.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <variablelist>
+      <varlistentry>
+        <term><option>-u</option></term>
+        <term><option>--url=<optional>https://</optional><replaceable>URL</replaceable>[:<replaceable>PORT</replaceable>]</option></term>
+        <term><option>--url=<optional>http://</optional><replaceable>URL</replaceable>[:<replaceable>PORT</replaceable>]</option></term>
+
+        <listitem><para>Upload to the specified
+        address. <replaceable>URL</replaceable> may specify either
+        just the hostname or both the protocol and
+        hostname. <constant>https</constant> is the default.
+        The port number may be specified after a colon (<literal>:</literal>),
+        otherwise <constant>19532</constant> will be used by default.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--system</option></term>
+        <term><option>--user</option></term>
+
+        <listitem><para>Limit uploaded entries to entries from system
+        services and the kernel, or to entries from services of
+        current user. This has the same meaning as
+        <option>--system</option> and <option>--user</option> options
+        for
+        <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>. If
+        neither is specified, all accessible entries are uploaded.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-m</option></term>
+        <term><option>--merge</option></term>
+
+        <listitem><para>Upload entries interleaved from all available
+        journals, including other machines. This has the same meaning
+        as <option>--merge</option> option for
+        <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--namespace=<replaceable>NAMESPACE</replaceable></option></term>
+
+        <listitem><para>Takes a journal namespace identifier string as argument. Upload
+        entries from the specified journal namespace
+        <replaceable>NAMESPACE</replaceable> instead of the default namespace. This has the same meaning as
+        <option>--namespace=</option> option for
+        <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-D</option></term>
+        <term><option>--directory=<replaceable>DIR</replaceable></option></term>
+
+        <listitem><para>Takes a directory path as argument. Upload
+        entries from the specified journal directory
+        <replaceable>DIR</replaceable> instead of the default runtime
+        and system journal paths. This has the same meaning as
+        <option>--directory=</option> option for
+        <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--file=<replaceable>GLOB</replaceable></option></term>
+
+        <listitem><para>Takes a file glob as an argument. Upload
+        entries from the specified journal files matching
+        <replaceable>GLOB</replaceable> instead of the default runtime
+        and system journal paths. May be specified multiple times, in
+        which case files will be suitably interleaved. This has the same meaning as
+        <option>--file=</option> option for
+        <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--cursor=</option></term>
+
+        <listitem><para>Upload entries from the location in the
+        journal specified by the passed cursor. This has the same
+        meaning as <option>--cursor=</option> option for
+        <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--after-cursor=</option></term>
+
+        <listitem><para>Upload entries from the location in the
+        journal <emphasis>after</emphasis> the location specified by
+        the this cursor.  This has the same meaning as
+        <option>--after-cursor=</option> option for
+        <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--save-state</option><optional>=<replaceable>PATH</replaceable></optional></term>
+
+        <listitem><para>Upload entries from the location in the
+        journal <emphasis>after</emphasis> the location specified by
+        the cursor saved in file at <replaceable>PATH</replaceable>
+        (<filename>/var/lib/systemd/journal-upload/state</filename> by default).
+        After an entry is successfully uploaded, update this file
+        with the cursor of that entry.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--follow</option><optional>=<replaceable>BOOL</replaceable></optional></term>
+
+        <listitem><para>
+          If set to yes, then <command>systemd-journal-upload</command> waits for input.
+        </para>
+
+          <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--key=</option></term>
+
+        <listitem><para>
+          Takes a path to a SSL key file in PEM format, or <option>-</option>.
+          If <option>-</option> is set, then client certificate authentication checking
+          will be disabled.
+          Defaults to <filename>&CERTIFICATE_ROOT;/private/journal-upload.pem</filename>.
+        </para>
+
+          <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--cert=</option></term>
+
+        <listitem><para>
+          Takes a path to a SSL certificate file in PEM format, or <option>-</option>.
+          If <option>-</option> is set, then client certificate authentication checking
+          will be disabled.
+          Defaults to <filename>&CERTIFICATE_ROOT;/certs/journal-upload.pem</filename>.
+        </para>
+
+          <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--trust=</option></term>
+
+        <listitem><para>
+          Takes a path to a SSL CA certificate file in PEM format, or <option>-</option>/<option>all</option>.
+          If <option>-</option>/<option>all</option> is set, then certificate checking will be disabled.
+          Defaults to <filename>&CERTIFICATE_ROOT;/ca/trusted.pem</filename>.
+        </para>
+
+          <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <xi:include href="standard-options.xml" xpointer="help" />
+      <xi:include href="standard-options.xml" xpointer="version" />
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Exit status</title>
+
+    <para>On success, 0 is returned; otherwise, a non-zero
+    failure code is returned.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Examples</title>
+    <example>
+      <title>Setting up certificates for authentication</title>
+
+      <para>Certificates signed by a trusted authority are used to
+      verify that the server to which messages are uploaded is
+      legitimate, and vice versa, that the client is trusted.</para>
+
+      <para>A suitable set of certificates can be generated with
+      <command>openssl</command>. Note, 2048 bits of key length
+      is minimally recommended to use for security reasons:</para>
+
+      <programlisting>openssl req -newkey rsa:2048 -days 3650 -x509 -nodes \
+      -out ca.pem -keyout ca.key -subj '/CN=Certificate authority/'
+
+cat &gt;ca.conf &lt;&lt;EOF
+[ ca ]
+default_ca = this
+
+[ this ]
+new_certs_dir = .
+certificate = ca.pem
+database = ./index
+private_key = ca.key
+serial = ./serial
+default_days = 3650
+default_md = default
+policy = policy_anything
+
+[ policy_anything ]
+countryName             = optional
+stateOrProvinceName     = optional
+localityName            = optional
+organizationName        = optional
+organizationalUnitName  = optional
+commonName              = supplied
+emailAddress            = optional
+EOF
+
+touch index
+echo 0001 &gt;serial
+
+SERVER=server
+CLIENT=client
+
+openssl req -newkey rsa:2048 -nodes -out $SERVER.csr -keyout $SERVER.key -subj "/CN=$SERVER/"
+openssl ca -batch -config ca.conf -notext -in $SERVER.csr -out $SERVER.pem
+
+openssl req -newkey rsa:2048 -nodes -out $CLIENT.csr -keyout $CLIENT.key -subj "/CN=$CLIENT/"
+openssl ca -batch -config ca.conf -notext -in $CLIENT.csr -out $CLIENT.pem
+</programlisting>
+
+      <para>Generated files <filename>ca.pem</filename>,
+      <filename>server.pem</filename>, and
+      <filename>server.key</filename> should be installed on server,
+      and <filename>ca.pem</filename>,
+      <filename>client.pem</filename>, and
+      <filename>client.key</filename> on the client. The location of
+      those files can be specified using
+      <varname>TrustedCertificateFile=</varname>,
+      <varname>ServerCertificateFile=</varname>,
+      and <varname>ServerKeyFile=</varname> in
+      <filename>/etc/systemd/journal-remote.conf</filename> and
+      <filename>/etc/systemd/journal-upload.conf</filename>,
+      respectively. The default locations can be queried by using
+      <command>systemd-journal-remote --help</command> and
+      <command>systemd-journal-upload --help</command>.</para>
+    </example>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>journal-upload.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-journal-remote.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-journal-gatewayd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+</refentry>
diff --git a/man/systemd-journald.service.xml b/man/systemd-journald.service.xml
new file mode 100644
index 0000000..31435b2
--- /dev/null
+++ b/man/systemd-journald.service.xml
@@ -0,0 +1,374 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd-journald.service"
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd-journald.service</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-journald.service</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-journald.service</refname>
+    <refname>systemd-journald.socket</refname>
+    <refname>systemd-journald-dev-log.socket</refname>
+    <refname>systemd-journald-audit.socket</refname>
+    <refname>systemd-journald@.service</refname>
+    <refname>systemd-journald@.socket</refname>
+    <refname>systemd-journald-varlink@.socket</refname>
+    <refname>systemd-journald</refname>
+    <refpurpose>Journal service</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>systemd-journald.service</filename></para>
+    <para><filename>systemd-journald.socket</filename></para>
+    <para><filename>systemd-journald-dev-log.socket</filename></para>
+    <para><filename>systemd-journald-audit.socket</filename></para>
+    <para><filename>systemd-journald@.service</filename></para>
+    <para><filename>systemd-journald@.socket</filename></para>
+    <para><filename>systemd-journald-varlink@.socket</filename></para>
+    <para><filename>/usr/lib/systemd/systemd-journald</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><filename>systemd-journald</filename> is a system service
+    that collects and stores logging data. It creates and maintains
+    structured, indexed journals based on logging information that is
+    received from a variety of sources:</para>
+
+    <itemizedlist>
+      <listitem><para>Kernel log messages, via kmsg</para></listitem>
+
+      <listitem><para>Simple system log messages, via the <filename>libc</filename> <citerefentry
+      project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+      call</para></listitem>
+
+      <listitem><para>Structured system log messages via the native Journal API, see
+      <citerefentry><refentrytitle>sd_journal_print</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+      and <ulink url="https://systemd.io/JOURNAL_NATIVE_PROTOCOL">Native Journal
+      Protocol</ulink></para></listitem>
+
+      <listitem><para>Standard output and standard error of service units. For further details see
+      below.</para></listitem>
+
+      <listitem><para>Audit records, originating from the kernel audit subsystem</para></listitem>
+    </itemizedlist>
+
+    <para>The daemon will implicitly collect numerous metadata fields
+    for each log messages in a secure and unfakeable way. See
+    <citerefentry><refentrytitle>systemd.journal-fields</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+    for more information about the collected metadata.
+    </para>
+
+    <para>Log data collected by the journal is primarily text-based but can also include binary data where
+    necessary. Individual fields making up a log record stored in the journal may be up to 2⁶⁴-1 bytes in size.</para>
+
+    <para>The journal service stores log data either persistently below <filename>/var/log/journal</filename> or in a
+    volatile way below <filename>/run/log/journal/</filename> (in the latter case it is lost at reboot). By default, log
+    data is stored persistently if <filename>/var/log/journal/</filename> exists during boot, with an implicit fallback
+    to volatile storage otherwise. Use <varname>Storage=</varname> in
+    <citerefentry><refentrytitle>journald.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> to configure
+    where log data is placed, independently of the existence of <filename>/var/log/journal/</filename>.</para>
+
+    <para>Note that journald will initially use volatile storage, until a call to
+    <command>journalctl --flush</command> (or sending <constant>SIGUSR1</constant> to journald) will cause
+    it to switch to persistent logging (under the conditions mentioned above). This is done automatically
+    on boot via <literal>systemd-journal-flush.service</literal>.</para>
+
+    <para>On systems where <filename>/var/log/journal/</filename> does not exist yet but where persistent logging is
+    desired (and the default <filename>journald.conf</filename> is used), it is sufficient to create the directory, and
+    ensure it has the correct access modes and ownership:</para>
+
+    <programlisting>mkdir -p /var/log/journal
+systemd-tmpfiles --create --prefix /var/log/journal</programlisting>
+
+    <para>See
+    <citerefentry><refentrytitle>journald.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for information about the configuration of this service.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Stream logging</title>
+
+    <para>The systemd service manager invokes all service processes with standard output and standard error connected
+    to the journal by default. This behaviour may be altered via the
+    <varname>StandardOutput=</varname>/<varname>StandardError=</varname> unit file settings, see
+    <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> for details. The
+    journal converts the log byte stream received this way into individual log records, splitting the stream at newline
+    (<literal>\n</literal>, ASCII <constant>10</constant>) and <constant>NUL</constant> bytes.</para>
+
+    <para>If <filename>systemd-journald.service</filename> is stopped, the stream connections associated with all
+    services are terminated. Further writes to those streams by the service will result in <constant>EPIPE</constant>
+    errors. In order to react gracefully in this case it is recommended that programs logging to standard output/error
+    ignore such errors. If the <constant>SIGPIPE</constant> UNIX signal handler is not blocked or turned off, such
+    write attempts will also result in such process signals being generated, see
+    <citerefentry project='man-pages'><refentrytitle>signal</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
+    To mitigate this issue, systemd service manager explicitly turns off the <constant>SIGPIPE</constant>
+    signal for all invoked processes by default (this may be changed for each unit individually via the
+    <varname>IgnoreSIGPIPE=</varname> option, see
+    <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
+    details). After the standard output/standard error streams have been terminated they may not be recovered
+    until the services they are associated with are restarted. Note that during normal operation,
+    <filename>systemd-journald.service</filename> stores copies of the file descriptors for those streams in
+    the service manager. If <filename>systemd-journald.service</filename> is restarted using
+    <command>systemctl restart</command> or equivalent operation instead of a pair of separate
+    <command>systemctl stop</command> and <command>systemctl start</command> commands (or equivalent
+    operations), these stream connections are not terminated and survive the restart. It is thus safe to
+    restart <filename>systemd-journald.service</filename>, but stopping it is not recommended.</para>
+
+    <para>Note that the log record metadata for records transferred via such standard output/error streams reflect the
+    metadata of the peer the stream was originally created for. If the stream connection is passed on to other
+    processes (such as further child processes forked off the main service process), the log records will not reflect
+    their metadata, but will continue to describe the original process. This is different from the other logging
+    transports listed above, which are inherently record based and where the metadata is always associated with the
+    individual record.</para>
+
+    <para>In addition to the implicit standard output/error logging of services, stream logging is also available
+    via the <citerefentry><refentrytitle>systemd-cat</refentrytitle><manvolnum>1</manvolnum></citerefentry> command
+    line tool.</para>
+
+    <para>Currently, the number of parallel log streams <filename>systemd-journald</filename> will accept is limited to
+    4096. When this limit is reached further log streams may be established but will receive
+    <constant>EPIPE</constant> right from the beginning.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Journal Namespaces</title>
+
+    <para>Journal 'namespaces' are both a mechanism for logically isolating the log stream of projects
+    consisting of one or more services from the rest of the system and a mechanism for improving
+    performance. Multiple journal namespaces may exist simultaneously, each defining its own, independent log
+    stream managed by its own instance of <command>systemd-journald</command>. Namespaces are independent of
+    each other, both in the data store and in the IPC interface. By default only a single 'default' namespace
+    exists, managed by <filename>systemd-journald.service</filename> (and its associated socket
+    units). Additional namespaces are created by starting an instance of the
+    <filename>systemd-journald@.service</filename> service template. The instance name is the namespace
+    identifier, which is a short string used for referencing the journal namespace. Service units may be
+    assigned to a specific journal namespace through the <varname>LogNamespace=</varname> unit file setting,
+    see <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
+    details. The <option>--namespace=</option> switch of
+    <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> may be
+    used to view the log stream of a specific namespace. If the switch is not used the log stream of the
+    default namespace is shown, i.e. log data from other namespaces is not visible.</para>
+
+    <para>Services associated with a specific log namespace may log via syslog, the native logging protocol
+    of the journal and via stdout/stderr; the logging from all three transports is associated with the
+    namespace.</para>
+
+    <para>By default only the default namespace will collect kernel and audit log messages.</para>
+
+    <para>The <command>systemd-journald</command> instance of the default namespace is configured through
+    <filename>/etc/systemd/journald.conf</filename> (see below), while the other instances are configured
+    through <filename>/etc/systemd/journald@<replaceable>NAMESPACE</replaceable>.conf</filename>. The journal
+    log data for the default namespace is placed in
+    <filename>/var/log/journal/<replaceable>MACHINE_ID</replaceable></filename> (see below) while the data
+    for the other namespaces is located in
+    <filename>/var/log/journal/<replaceable>MACHINE_ID</replaceable>.<replaceable>NAMESPACE</replaceable></filename>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Signals</title>
+
+    <variablelist>
+      <varlistentry>
+        <term>SIGUSR1</term>
+
+        <listitem><para>Request that journal data from <filename>/run/</filename> is flushed to
+        <filename>/var/</filename> in order to make it persistent (if this is enabled). This must be used
+        after <filename>/var/</filename> is mounted, as otherwise log data from <filename>/run/</filename> is
+        never flushed to <filename>/var/</filename> regardless of the configuration. Use the
+        <command>journalctl --flush</command> command to request flushing of the journal files, and wait for
+        the operation to complete. See
+        <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> for
+        details.</para>
+
+        <xi:include href="version-info.xml" xpointer="v186"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term>SIGUSR2</term>
+
+        <listitem><para>Request immediate rotation of the journal files. Use the <command>journalctl
+        --rotate</command> command to request journal file rotation, and wait for the operation to
+        complete.</para>
+
+        <xi:include href="version-info.xml" xpointer="v186"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term>SIGRTMIN+1</term>
+
+        <listitem><para>Request that all unwritten log data is written to disk. Use the <command>journalctl
+        --sync</command> command to trigger journal synchronization, and wait for the operation to
+        complete.</para>
+
+        <xi:include href="version-info.xml" xpointer="v228"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Kernel Command Line</title>
+
+    <para>A few configuration parameters from
+    <filename>journald.conf</filename> may be overridden on the kernel
+    command line:</para>
+
+    <variablelist class='kernel-commandline-options'>
+      <varlistentry>
+        <term><varname>systemd.journald.forward_to_syslog=</varname></term>
+        <term><varname>systemd.journald.forward_to_kmsg=</varname></term>
+        <term><varname>systemd.journald.forward_to_console=</varname></term>
+        <term><varname>systemd.journald.forward_to_wall=</varname></term>
+
+        <listitem><para>Enables/disables forwarding of collected log
+        messages to syslog, the kernel log buffer, the system console
+        or wall.
+        </para>
+
+        <para>See
+        <citerefentry><refentrytitle>journald.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for information about these settings.</para>
+
+        <xi:include href="version-info.xml" xpointer="v186"/>
+        </listitem>
+
+      </varlistentry>
+    </variablelist>
+
+    <para>Note that these kernel command line options are only honoured by the default namespace, see
+    above.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Access Control</title>
+
+    <para>Journal files are, by default, owned and readable by the
+    <literal>systemd-journal</literal> system group but are not
+    writable. Adding a user to this group thus enables them to read
+    the journal files.</para>
+
+    <para>By default, each user, with a UID outside the range of system users,
+    dynamic service users, and the nobody user, will get their own set of
+    journal files in <filename>/var/log/journal/</filename>. See
+    <ulink url="https://systemd.io/UIDS-GIDS">Users, Groups, UIDs and GIDs on systemd systems</ulink>
+    for more details about UID ranges. These journal
+    files will not be owned by the user, however, in order to avoid
+    that the user can write to them directly. Instead, file system
+    ACLs are used to ensure the user gets read access only.</para>
+
+    <para>Additional users and groups may be granted access to journal
+    files via file system access control lists (ACL). Distributions
+    and administrators may choose to grant read access to all members
+    of the <literal>wheel</literal> and <literal>adm</literal> system
+    groups with a command such as the following:</para>
+
+    <programlisting># setfacl -Rnm g:wheel:rx,d:g:wheel:rx,g:adm:rx,d:g:adm:rx /var/log/journal/</programlisting>
+
+    <para>Note that this command will update the ACLs both for
+    existing journal files and for future journal files created in the
+    <filename>/var/log/journal/</filename> directory.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Files</title>
+
+    <variablelist>
+      <varlistentry>
+        <term><filename>/etc/systemd/journald.conf</filename></term>
+
+        <listitem><para>Configure <command>systemd-journald</command> behavior. See
+        <citerefentry><refentrytitle>journald.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v206"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>/run/log/journal/<replaceable>machine-id</replaceable>/*.journal</filename></term>
+        <term><filename>/run/log/journal/<replaceable>machine-id</replaceable>/*.journal~</filename></term>
+        <term><filename>/var/log/journal/<replaceable>machine-id</replaceable>/*.journal</filename></term>
+        <term><filename>/var/log/journal/<replaceable>machine-id</replaceable>/*.journal~</filename></term>
+
+        <listitem><para><command>systemd-journald</command> writes entries to files in
+        <filename>/run/log/journal/<replaceable>machine-id</replaceable>/</filename>
+        or
+        <filename>/var/log/journal/<replaceable>machine-id</replaceable>/</filename>
+        with the <literal>.journal</literal> suffix. If the daemon is
+        stopped uncleanly, or if the files are found to be corrupted,
+        they are renamed using the <literal>.journal~</literal>
+        suffix, and <command>systemd-journald</command> starts writing
+        to a new file. <filename>/run/</filename> is used when
+        <filename>/var/log/journal</filename> is not available, or
+        when <option>Storage=volatile</option> is set in the
+        <citerefentry><refentrytitle>journald.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        configuration file.</para>
+
+        <para>When <filename>systemd-journald</filename> ceases writing to a journal file,
+        it will be renamed to <literal><replaceable>original-name</replaceable>@<replaceable>suffix.journal</replaceable></literal>
+        (or <literal><replaceable>original-name</replaceable>@<replaceable>suffix.journal~</replaceable></literal>).
+        Such files are "archived" and will not be written to any more.</para>
+
+        <para>In general, it is safe to read or copy any journal file (active or archived).
+        <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+        and the functions in the
+        <citerefentry><refentrytitle>sd-journal</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+        library should be able to read all entries that have been fully written.</para>
+
+        <para><filename>systemd-journald</filename> will automatically remove the oldest
+        archived journal files to limit disk use. See <varname>SystemMaxUse=</varname>
+        and related settings in
+        <citerefentry><refentrytitle>journald.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v206"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>/dev/kmsg</filename></term>
+        <term><filename>/dev/log</filename></term>
+        <term><filename>/run/systemd/journal/dev-log</filename></term>
+        <term><filename>/run/systemd/journal/socket</filename></term>
+        <term><filename>/run/systemd/journal/stdout</filename></term>
+
+        <listitem><para>Sockets and other file node paths that <command>systemd-journald</command> will
+        listen on and are visible in the file system. In addition to these,
+        <command>systemd-journald</command> can listen for audit events using <citerefentry
+        project='man-pages'><refentrytitle>netlink</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+        depending on whether <literal>systemd-journald-audit.socket</literal> is enabled or
+        not.</para>
+
+        <xi:include href="version-info.xml" xpointer="v228"/></listitem>
+      </varlistentry>
+    </variablelist>
+
+    <para>If journal namespacing is used these paths are slightly altered to include a namespace identifier, see above.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>journald.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.journal-fields</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-journal</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-coredump</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>setfacl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_journal_print</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <command>pydoc systemd.journal</command>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-localed.service.xml b/man/systemd-localed.service.xml
new file mode 100644
index 0000000..b0a4a9f
--- /dev/null
+++ b/man/systemd-localed.service.xml
@@ -0,0 +1,61 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd-localed.service" conditional='ENABLE_LOCALED'>
+
+  <refentryinfo>
+    <title>systemd-localed.service</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-localed.service</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-localed.service</refname>
+    <refname>systemd-localed</refname>
+    <refpurpose>Locale bus mechanism</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>systemd-localed.service</filename></para>
+    <para><filename>/usr/lib/systemd/systemd-localed</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><filename>systemd-localed.service</filename> is a system service
+    that may be used as mechanism to change the system locale
+    settings, as well as the console key mapping and default X11 key
+    mapping. <filename>systemd-localed</filename> is automatically
+    activated on request and terminates itself when it is
+    unused.</para>
+
+    <para>The tool
+    <citerefentry project='man-pages'><refentrytitle>localectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    is a command line client to this service.</para>
+
+    <para>See
+    <citerefentry><refentrytitle>org.freedesktop.locale1</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    and
+    <citerefentry><refentrytitle>org.freedesktop.LogControl1</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for a description of the D-Bus API.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>locale.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>vconsole.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>localectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry project='mankier'><refentrytitle>loadkeys</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-logind.service.xml b/man/systemd-logind.service.xml
new file mode 100644
index 0000000..622ad95
--- /dev/null
+++ b/man/systemd-logind.service.xml
@@ -0,0 +1,111 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd-logind.service" conditional='ENABLE_LOGIND'>
+
+  <refentryinfo>
+    <title>systemd-logind.service</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-logind.service</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-logind.service</refname>
+    <refname>systemd-logind</refname>
+    <refpurpose>Login manager</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>systemd-logind.service</filename></para>
+    <para><filename>/usr/lib/systemd/systemd-logind</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>systemd-logind</command> is a system service that
+    manages user logins. It is responsible for:</para>
+
+    <itemizedlist>
+      <listitem><para>Keeping track of users and sessions, their processes and their idle state. This is implemented by
+      allocating a systemd slice unit for each user below <filename>user.slice</filename>, and a scope unit below it
+      for each concurrent session of a user. Also, a per-user service manager is started as system service instance of
+      <filename>user@.service</filename> for each logged in user.</para></listitem>
+
+      <listitem><para>Generating and managing session IDs. If auditing is available and an audit session ID is already set for
+      a session, then this ID is reused as the session ID. Otherwise, an independent session counter is
+      used.</para></listitem>
+
+      <listitem><para>Providing <ulink
+      url="https://www.freedesktop.org/wiki/Software/polkit">polkit</ulink>-based access for users for
+      operations such as system shutdown or sleep</para>
+      </listitem>
+
+      <listitem><para>Implementing a shutdown/sleep inhibition logic for applications</para></listitem>
+
+      <listitem><para>Handling of power/sleep hardware keys</para></listitem>
+
+      <listitem><para>Multi-seat management</para></listitem>
+
+      <listitem><para>Session switch management</para></listitem>
+
+      <listitem><para>Device access management for users</para></listitem>
+
+      <listitem><para>Automatic spawning of text logins (gettys) on virtual console activation and user
+      runtime directory management</para></listitem>
+
+      <listitem><para>Scheduled shutdown</para></listitem>
+
+      <listitem><para>Sending "wall" messages</para></listitem>
+    </itemizedlist>
+
+    <para>User sessions are registered with logind via the
+    <citerefentry><refentrytitle>pam_systemd</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    PAM module.</para>
+
+    <para>See
+    <citerefentry><refentrytitle>logind.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for information about the configuration of this service.</para>
+
+    <para>See
+    <citerefentry><refentrytitle>sd-login</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    for information about the basic concepts of logind
+    such as users, sessions and seats.</para>
+
+    <para>See
+    <citerefentry><refentrytitle>org.freedesktop.login1</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    and
+    <citerefentry><refentrytitle>org.freedesktop.LogControl1</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for information about the D-Bus APIs <filename>systemd-logind</filename> provides.</para>
+
+    <para>For more information on the inhibition logic see the <ulink
+    url="https://www.freedesktop.org/wiki/Software/systemd/inhibit">Inhibitor
+    Lock Developer Documentation</ulink>.</para>
+
+    <para>If you are interested in writing a display manager that makes use of logind, please have look at
+    <ulink url="https://www.freedesktop.org/wiki/Software/systemd/writing-display-managers">Writing Display
+    Managers</ulink>.
+    If you are interested in writing a desktop environment that makes use of logind, please have look at
+    <ulink url="https://www.freedesktop.org/wiki/Software/systemd/writing-desktop-environments">Writing
+    Desktop Environments</ulink>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-user-sessions.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>loginctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>logind.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>pam_systemd</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-login</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-machine-id-commit.service.xml b/man/systemd-machine-id-commit.service.xml
new file mode 100644
index 0000000..cffc3e5
--- /dev/null
+++ b/man/systemd-machine-id-commit.service.xml
@@ -0,0 +1,74 @@
+<?xml version="1.0"?>
+<!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!--
+  SPDX-License-Identifier: LGPL-2.1-or-later
+
+  Copyright © 2014 Didier Roche
+-->
+<refentry id="systemd-machine-id-commit.service">
+
+  <refentryinfo>
+    <title>systemd-machine-id-commit.service</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-machine-id-commit.service</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-machine-id-commit.service</refname>
+    <refpurpose>Commit a transient machine ID to disk</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>systemd-machine-id-commit.service</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><filename>systemd-machine-id-commit.service</filename> is an
+    early boot service responsible for committing transient
+    <filename>/etc/machine-id</filename> files to a writable disk file
+    system. See
+    <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for more information about machine IDs.</para>
+
+    <para>This service is started after
+    <filename>local-fs.target</filename> in case
+    <filename>/etc/machine-id</filename> is a mount point of its own
+    (usually from a memory file system such as
+    <literal>tmpfs</literal>) and /etc is writable. The service will
+    invoke <command>systemd-machine-id-setup --commit</command>, which
+    writes the current transient machine ID to disk and unmount the
+    <filename>/etc/machine-id</filename> file in a race-free manner to
+    ensure that file is always valid and accessible for other
+    processes. See
+    <citerefentry><refentrytitle>systemd-machine-id-setup</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    for details.</para>
+
+    <para>The main use case of this service are systems where
+    <filename>/etc/machine-id</filename> is read-only and initially
+    not initialized. In this case, the system manager will generate a
+    transient machine ID file on a memory file system, and mount it
+    over <filename>/etc/machine-id</filename>, during the early boot
+    phase. This service is then invoked in a later boot phase, as soon
+    as <filename>/etc/</filename> has been remounted writable and the
+    ID may thus be committed to disk to make it permanent.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-machine-id-setup</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-firstboot</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-machine-id-setup.xml b/man/systemd-machine-id-setup.xml
new file mode 100644
index 0000000..d1a77bd
--- /dev/null
+++ b/man/systemd-machine-id-setup.xml
@@ -0,0 +1,164 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd-machine-id-setup"
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd-machine-id-setup</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-machine-id-setup</refentrytitle>
+    <manvolnum>1</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-machine-id-setup</refname>
+    <refpurpose>Initialize the machine ID in /etc/machine-id</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <cmdsynopsis>
+      <command>systemd-machine-id-setup</command>
+    </cmdsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>systemd-machine-id-setup</command> may be used by
+    system installer tools to initialize the machine ID stored in
+    <filename>/etc/machine-id</filename> at install time, with a
+    provisioned or randomly generated ID. See
+    <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for more information about this file.</para>
+
+    <para>If the tool is invoked without the <option>--commit</option>
+    switch, <filename>/etc/machine-id</filename> is initialized with a
+    valid, new machine ID if it is missing or empty. The new machine
+    ID will be acquired in the following fashion:</para>
+
+    <orderedlist>
+      <listitem><para>If a valid D-Bus machine ID is already
+      configured for the system, the D-Bus machine ID is copied and
+      used to initialize the machine ID in
+      <filename>/etc/machine-id</filename>.</para></listitem>
+
+      <listitem><para>If run inside a KVM virtual machine and a UUID
+      is configured (via the <option>-uuid</option>
+      option), this UUID is used to initialize the machine ID. The
+      caller must ensure that the UUID passed is sufficiently unique
+      and is different for every booted instance of the
+      VM.</para></listitem>
+
+      <listitem><para>Similarly, if run inside a Linux container environment and a UUID is configured for the
+      container, this is used to initialize the machine ID. For details, see the documentation of the <ulink
+      url="https://systemd.io/CONTAINER_INTERFACE">Container Interface</ulink>.</para></listitem>
+
+      <listitem><para>Otherwise, a new ID is randomly
+      generated.</para></listitem>
+    </orderedlist>
+
+    <para>The <option>--commit</option> switch may be used to commit a
+    transient machined ID to disk, making it persistent. For details,
+    see below.</para>
+
+    <para>Use
+    <citerefentry><refentrytitle>systemd-firstboot</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    to initialize the machine ID on mounted (but not booted) system
+    images.</para>
+
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>The following options are understood:</para>
+
+    <variablelist>
+
+      <varlistentry>
+        <term><option>--root=<replaceable>path</replaceable></option></term>
+        <listitem><para>Takes a directory path as argument. All paths operated on will be prefixed with the
+        given alternate <replaceable>root</replaceable> path, including the path for
+        <filename>/etc/machine-id</filename> itself.</para>
+
+        <xi:include href="version-info.xml" xpointer="v212"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--image=<replaceable>path</replaceable></option></term>
+        <listitem><para>Takes a path to a device node or regular file as argument. This is similar to
+        <option>--root=</option> as described above, but operates on a disk image instead of a directory
+        tree.</para>
+
+        <xi:include href="version-info.xml" xpointer="v249"/></listitem>
+      </varlistentry>
+
+      <xi:include href="standard-options.xml" xpointer="image-policy-open" />
+
+      <varlistentry>
+        <term><option>--commit</option></term>
+        <listitem><para>Commit a transient machine ID to disk. This
+        command may be used to convert a transient machine ID into a
+        persistent one. A transient machine ID file is one that was
+        bind mounted from a memory file system (usually
+        <literal>tmpfs</literal>) to
+        <filename>/etc/machine-id</filename> during the early phase of
+        the boot process. This may happen because
+        <filename>/etc/</filename> is initially read-only and was
+        missing a valid machine ID file at that point.</para>
+
+        <para>This command will execute no operation if
+        <filename>/etc/machine-id</filename> is not mounted from a
+        memory file system, or if <filename>/etc/</filename> is
+        read-only. The command will write the current transient
+        machine ID to disk and unmount the
+        <filename>/etc/machine-id</filename> mount point in a
+        race-free manner to ensure that this file is always valid and
+        accessible for other processes.</para>
+
+        <para>This command is primarily used by the
+        <citerefentry><refentrytitle>systemd-machine-id-commit.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        early boot service.</para>
+
+        <xi:include href="version-info.xml" xpointer="v227"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--print</option></term>
+
+        <listitem><para>Print the machine ID generated or committed after the operation is complete.</para>
+
+        <xi:include href="version-info.xml" xpointer="v231"/></listitem>
+      </varlistentry>
+
+      <xi:include href="standard-options.xml" xpointer="help" />
+      <xi:include href="standard-options.xml" xpointer="version" />
+    </variablelist>
+
+  </refsect1>
+
+  <refsect1>
+    <title>Exit status</title>
+
+    <para>On success, 0 is returned, a non-zero failure code
+    otherwise.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-machine-id-commit.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry project='dbus'><refentrytitle>dbus-uuidgen</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-firstboot</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-machined.service.xml b/man/systemd-machined.service.xml
new file mode 100644
index 0000000..48bf6c5
--- /dev/null
+++ b/man/systemd-machined.service.xml
@@ -0,0 +1,139 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd-machined.service" conditional='ENABLE_MACHINED'>
+
+  <refentryinfo>
+    <title>systemd-machined.service</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-machined.service</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-machined.service</refname>
+    <refname>systemd-machined</refname>
+    <refpurpose>Virtual machine and container registration manager</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>systemd-machined.service</filename></para>
+    <para><filename>/usr/lib/systemd/systemd-machined</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>systemd-machined</command> is a system service that keeps track of locally running virtual
+    machines and containers.</para>
+
+    <para><command>systemd-machined</command> is useful for registering and keeping track of both OS
+    containers (containers that share the host kernel but run a full init system of their own and behave in
+    most regards like a full virtual operating system rather than just one virtualized app) and full virtual
+    machines (virtualized hardware running normal operating systems and possibly different kernels).</para>
+
+    <para><command>systemd-machined</command> should <emphasis>not</emphasis> be used for registering/keeping
+    track of application sandbox containers. A <emphasis>machine</emphasis> in the context of
+    <command>systemd-machined</command> is supposed to be an abstract term covering both OS containers and
+    full virtual machines, but not application sandboxes.</para>
+
+    <para>Machines registered with machined are exposed in various ways in the system. For example:
+    <itemizedlist>
+      <listitem><para>Tools like
+      <citerefentry project='man-pages'><refentrytitle>ps</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+      will show to which machine a specific process belongs in a column of
+      its own, and so will
+      <ulink url="https://help.gnome.org/users/gnome-system-monitor/">gnome-system-monitor</ulink> or
+      <citerefentry><refentrytitle>systemd-cgls</refentrytitle><manvolnum>1</manvolnum></citerefentry>.</para>
+      </listitem>
+
+      <listitem><para>systemd's various tools
+      (<citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>loginctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>hostnamectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>timedatectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>localectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>machinectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, ...)
+      support the <option>-M</option> switch to operate on local containers instead of the host system.
+      </para></listitem>
+
+      <listitem><para><command>systemctl list-machines</command> will show the system state of all local
+      containers, connecting to the container's init system for that.</para></listitem>
+
+      <listitem><para>systemctl's <option>--recursive</option> switch has the effect of not only showing the
+      locally running services, but recursively showing the services of all registered containers.</para></listitem>
+
+      <listitem><para>The <command>machinectl</command> command provides access to a number of useful
+      operations on registered containers, such as introspecting them, rebooting, shutting them down, and
+      getting a login prompt on them.</para></listitem>
+
+      <listitem><para>The
+      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry> library
+      exposes the
+      <citerefentry><refentrytitle>sd_bus_open_system_machine</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+      call to connect to the system bus of any registered container.</para></listitem>
+
+      <listitem><para>The
+      <citerefentry><refentrytitle>nss-mymachines</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+      module makes sure all registered containers can be resolved via normal glibc
+      <citerefentry project='man-pages'><refentrytitle>gethostbyname</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+      or
+      <citerefentry project='man-pages'><refentrytitle>getaddrinfo</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+      calls.</para></listitem>
+    </itemizedlist></para>
+
+    <para>See
+    <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    for some examples on how to run containers with OS tools.</para>
+
+    <para>If you are interested in writing a VM or container manager that makes use of machined, please have
+    look at <ulink url="https://www.freedesktop.org/wiki/Software/systemd/writing-vm-managers">Writing
+    Virtual Machine or Container Managers</ulink>. Also see the <ulink
+    url="https://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface">New Control Group
+    Interfaces</ulink>.</para>
+
+    <para>The daemon provides both a C library interface
+    (which is shared with <citerefentry><refentrytitle>systemd-logind.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>)
+    as well as a D-Bus interface.
+    The library interface may be used to introspect and watch the state of virtual machines/containers.
+    The bus interface provides the same but in addition may also be used to register or terminate
+    machines.
+    For more information please consult
+    <citerefentry><refentrytitle>sd-login</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    and
+    <citerefentry><refentrytitle>org.freedesktop.machine1</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    and
+    <citerefentry><refentrytitle>org.freedesktop.LogControl1</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+    </para>
+
+    <para>A small companion daemon
+    <citerefentry><refentrytitle>systemd-importd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    is also available, which implements importing, exporting, and downloading of container and VM images.
+    </para>
+
+    <para>For each container registered with <filename>systemd-machined.service</filename> that employs user
+    namespacing, users/groups are synthesized for the used UIDs/GIDs. These are made available to the system
+    using the <ulink url="https://systemd.io/USER_GROUP_API">User/Group Record Lookup API via
+    Varlink</ulink>, and thus may be resolved with
+    <citerefentry><refentrytitle>userdbctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> or the
+    usual glibc NSS calls.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>machinectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>nss-mymachines</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-makefs@.service.xml b/man/systemd-makefs@.service.xml
new file mode 100644
index 0000000..51409ba
--- /dev/null
+++ b/man/systemd-makefs@.service.xml
@@ -0,0 +1,103 @@
+<?xml version="1.0"?>
+<!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+<refentry id="systemd-makefs@.service">
+
+  <refentryinfo>
+    <title>systemd-makefs@.service</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-makefs@.service</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-makefs@.service</refname>
+    <refname>systemd-mkswap@.service</refname>
+    <refname>systemd-growfs@.service</refname>
+    <refname>systemd-growfs-root.service</refname>
+    <refname>systemd-makefs</refname>
+    <refname>systemd-growfs</refname>
+    <refpurpose>Creating and growing file systems on demand</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>systemd-makefs@<replaceable>device</replaceable>.service</filename></para>
+    <para><filename>systemd-mkswap@<replaceable>device</replaceable>.service</filename></para>
+    <para><filename>systemd-growfs@<replaceable>mountpoint</replaceable>.service</filename></para>
+    <para><filename>systemd-growfs-root.service</filename></para>
+    <para><filename>/usr/lib/systemd/systemd-makefs</filename></para>
+    <para><filename>/usr/lib/systemd/systemd-growfs</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><filename>systemd-makefs@.service</filename>,
+    <filename>systemd-mkswap@.service</filename>,
+    <filename>systemd-growfs@.service</filename>, and
+    <filename>systemd-growfs-root.service</filename> are used to implement the
+    <option>x-systemd.makefs</option> and <option>x-systemd.growfs</option> options
+    in <citerefentry project='man-pages'><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    see <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+    They are instantiated for each device for which the file system or swap structure
+    needs to be initialized, and for each mount point where the file system needs to
+    be grown.</para>
+
+    <para>These services are started at boot, either right before or right after the
+    mount point or swap device are used.</para>
+
+    <para><filename>systemd-makefs</filename> knows very little about specific file
+    systems and swap devices, and after checking that the block device does not already
+    contain a file system or other content, it will execute binaries specific to
+    each filesystem type (<filename>/sbin/mkfs.<replaceable>type</replaceable></filename>
+    or <filename>/sbin/mkswap</filename>). For certain file system types (currently
+    ext2/ext3/<citerefentry project='man-pages'><refentrytitle>ext4</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    <citerefentry project='url'><refentrytitle url='https://btrfs.readthedocs.io/en/latest/btrfs-man5.html'>btrfs</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    <citerefentry project='man-pages'><refentrytitle>xfs</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    f2fs, vfat) and for swap devices, it will configure reasonable defaults and set
+    the file system label and UUID based on the device name.</para>
+
+    <para><filename>systemd-growfs</filename> knows very little about specific file
+    systems and swap devices, and will instruct the kernel to grow the mounted
+    filesystem to full size of the underlying block device. Nevertheless, it needs
+    to know the
+    <citerefentry project='man-pages'><refentrytitle>ioctl</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+    number specific to each file system, so only certain types are supported.
+    Currently:
+    <citerefentry project='man-pages'><refentrytitle>ext4</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    <citerefentry project='url'><refentrytitle url='https://btrfs.readthedocs.io/en/latest/btrfs-man5.html'>btrfs</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    <citerefentry project='man-pages'><refentrytitle>xfs</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    <!-- yes, that's what the man page is called. -->
+    and dm-crypt partitions (see
+    <citerefentry project='die-net'><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry>).
+    </para>
+
+    <para>If the creation of a file system or swap device fails, the mount point or
+    swap is failed too. If the growing of a file system fails, a warning is emitted.
+    </para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-repart</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry project='url'><refentrytitle url='https://btrfs.readthedocs.io/en/latest/mkfs.btrfs.html'>mkfs.btrfs</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>mkfs.cramfs</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>mkfs.ext4</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>mkfs.fat</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>mkfs.hfsplus</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>mkfs.minix</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>mkfs.ntfs</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>mkfs.xfs</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-measure.xml b/man/systemd-measure.xml
new file mode 100644
index 0000000..ff3abc4
--- /dev/null
+++ b/man/systemd-measure.xml
@@ -0,0 +1,388 @@
+<?xml version="1.0"?>
+<!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+<refentry id="systemd-measure" xmlns:xi="http://www.w3.org/2001/XInclude" conditional='ENABLE_BOOTLOADER'>
+
+  <refentryinfo>
+    <title>systemd-measure</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-measure</refentrytitle>
+    <manvolnum>1</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-measure</refname>
+    <refpurpose>Pre-calculate and sign expected TPM2 PCR values for booted unified kernel images</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <cmdsynopsis>
+      <command>/usr/lib/systemd/systemd-measure <arg choice="opt" rep="repeat">OPTIONS</arg></command>
+    </cmdsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>Note: this command is experimental for now. While it is likely to become a regular component of
+    systemd, it might still change in behaviour and interface.</para>
+
+    <para><command>systemd-measure</command> is a tool that may be used to pre-calculate and sign the
+    expected TPM2 PCR 11 values that should be seen when a Linux <ulink
+    url="https://uapi-group.org/specifications/specs/unified_kernel_image/">Unified Kernel Image
+    (UKI)</ulink> based on
+    <citerefentry><refentrytitle>systemd-stub</refentrytitle><manvolnum>7</manvolnum></citerefentry> is
+    booted up. It accepts paths to the ELF kernel image file, initrd image file, devicetree file, kernel
+    command line file,
+    <citerefentry><refentrytitle>os-release</refentrytitle><manvolnum>5</manvolnum></citerefentry> file, boot
+    splash file, and TPM2 PCR PEM public key file that make up the unified kernel image, and determines the
+    PCR values expected to be in place after booting the image. Calculation starts with a zero-initialized
+    PCR 11, and is executed in a fashion compatible with what <filename>systemd-stub</filename> does at boot.
+    The result may optionally be signed cryptographically, to allow TPM2 policies that can only be unlocked
+    if a certain set of kernels is booted, for which such a PCR signature can be provided.</para>
+
+    <para>It usually doesn't make sense to call this tool directly when constructing a UKI. Instead,
+    <citerefentry><refentrytitle>ukify</refentrytitle><manvolnum>1</manvolnum></citerefentry> should be used;
+    it will invoke <command>systemd-measure</command> and take care of embedding the resulting measurements
+    into the UKI.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Commands</title>
+
+    <para>The following commands are understood:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><command>status</command></term>
+
+        <listitem><para>This is the default command if none is specified. This queries the local system's
+        TPM2 PCR 11+12+13 values and displays them. The data is written in a similar format as the
+        <command>calculate</command> command below, and may be used to quickly compare expectation with
+        reality.</para>
+
+        <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>calculate</command></term>
+
+        <listitem><para>Pre-calculate the expected values seen in PCR register 11 after boot-up of a unified
+        kernel image consisting of the components specified with <option>--linux=</option>,
+        <option>--osrel=</option>, <option>--cmdline=</option>, <option>--initrd=</option>,
+        <option>--splash=</option>, <option>--dtb=</option>, <option>--uname=</option>,
+        <option>--sbat=</option>, <option>--pcrpkey=</option> see below. Only <option>--linux=</option> is
+        mandatory. (Alternatively, specify <option>--current</option> to use the current values of PCR
+        register 11 instead.)</para>
+
+        <xi:include href="version-info.xml" xpointer="v252"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>sign</command></term>
+
+        <listitem><para>As with the <command>calculate</command> command, pre-calculate the expected value
+        seen in TPM2 PCR register 11 after boot-up of a unified kernel image. Then, cryptographically sign
+        the resulting values with the private/public key pair (RSA) configured via
+        <option>--private-key=</option> and <option>--public-key=</option>. This will write a JSON object to
+        standard output that contains signatures for all specified PCR banks (see the
+        <option>--bank=</option> option below), which may be used to unlock encrypted credentials (see
+        <citerefentry><refentrytitle>systemd-creds</refentrytitle><manvolnum>1</manvolnum></citerefentry>) or
+        LUKS volumes (see
+        <citerefentry><refentrytitle>systemd-cryptsetup@.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>).
+        This allows binding secrets to a set of kernels for which such PCR 11 signatures can be
+        provided.</para>
+
+        <para>Note that a TPM2 device must be available for this signing to take place, even though the
+        result is not tied to any TPM2 device or its state.</para>
+
+        <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>The following options are understood:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><option>--linux=<replaceable>PATH</replaceable></option></term>
+        <term><option>--osrel=<replaceable>PATH</replaceable></option></term>
+        <term><option>--cmdline=<replaceable>PATH</replaceable></option></term>
+        <term><option>--initrd=<replaceable>PATH</replaceable></option></term>
+        <term><option>--splash=<replaceable>PATH</replaceable></option></term>
+        <term><option>--dtb=<replaceable>PATH</replaceable></option></term>
+        <term><option>--uname=<replaceable>PATH</replaceable></option></term>
+        <term><option>--sbat=<replaceable>PATH</replaceable></option></term>
+        <term><option>--pcrpkey=<replaceable>PATH</replaceable></option></term>
+
+        <listitem><para>When used with the <command>calculate</command> or <command>sign</command> verb,
+        configures the files to read the unified kernel image components from. Each option corresponds with
+        the equally named section in the unified kernel PE file. The <option>--linux=</option> switch expects
+        the path to the ELF kernel file that the unified PE kernel will wrap. All switches except
+        <option>--linux=</option> are optional. Each option may be used at most once.</para>
+
+        <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--current</option></term>
+        <listitem><para>When used with the <command>calculate</command> or <command>sign</command> verb,
+        takes the PCR 11 values currently in effect for the system (which should typically reflect the hashes
+        of the currently booted kernel). This can be used in place of <option>--linux=</option> and the other
+        switches listed above.</para>
+
+        <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--bank=<replaceable>DIGEST</replaceable></option></term>
+
+        <listitem><para>Controls the PCR banks to pre-calculate the PCR values for – in case
+        <command>calculate</command> or <command>sign</command> is invoked –, or the banks to show in the
+        <command>status</command> output. May be used more then once to specify multiple banks. If not
+        specified, defaults to the four banks <literal>sha1</literal>, <literal>sha256</literal>,
+        <literal>sha384</literal>, <literal>sha512</literal>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--private-key=<replaceable>PATH</replaceable></option></term>
+        <term><option>--public-key=<replaceable>PATH</replaceable></option></term>
+
+        <listitem><para>These switches take paths to a pair of PEM encoded RSA key files, for use with
+        the <command>sign</command> command.</para>
+
+        <para>Note the difference between the <option>--pcrpkey=</option> and <option>--public-key=</option>
+        switches. The former selects the data to include in the <literal>.pcrpkey</literal> PE section of the
+        unified kernel image, the latter picks the public key of the key pair used to sign the resulting PCR
+        11 values. The former is the key that the booted system will likely use to lock disk and credential
+        encryption to, the latter is the key used for unlocking such resources again. Hence, typically the
+        same PEM key should be supplied in both cases.</para>
+
+        <para>If the <option>--public-key=</option> is not specified but <option>--private-key=</option> is
+        specified the public key is automatically derived from the private key.</para>
+
+        <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--tpm2-device=</option><replaceable>PATH</replaceable></term>
+
+        <listitem><para>Controls which TPM2 device to use. Expects a device node path referring to the TPM2
+        chip (e.g. <filename>/dev/tpmrm0</filename>). Alternatively the special value <literal>auto</literal>
+        may be specified, in order to automatically determine the device node of a suitable TPM2 device (of
+        which there must be exactly one). The special value <literal>list</literal> may be used to enumerate
+        all suitable TPM2 devices currently discovered.</para>
+
+        <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--phase=</option><replaceable>PHASE</replaceable></term>
+
+        <listitem><para>Controls which boot phases to calculate expected PCR 11 values for. This takes a
+        series of colon-separated strings that encode boot "paths" for entering a specific phase of the boot
+        process. Each of the specified strings is measured by the
+        <filename>systemd-pcrphase-initrd.service</filename>,
+        <filename>systemd-pcrphase-sysinit.service</filename>, and
+        <citerefentry><refentrytitle>systemd-pcrphase.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        into PCR 11 during different milestones of the boot process. This switch may be specified multiple
+        times to calculate PCR values for multiple boot phases at once. If not used defaults to
+        <literal>enter-initrd</literal>, <literal>enter-initrd:leave-initrd</literal>,
+        <literal>enter-initrd:leave-initrd:sysinit</literal>,
+        <literal>enter-initrd:leave-initrd:sysinit:ready</literal>, i.e. calculates expected PCR values for
+        the boot phase in the initrd, during early boot, during later boot, and during system runtime, but
+        excluding the phases before the initrd or when shutting down. This setting is honoured both by
+        <command>calculate</command> and <command>sign</command>. When used with the latter it's particularly
+        useful for generating PCR signatures that can only be used for unlocking resources during specific
+        parts of the boot process.</para>
+
+        <para>For further details about PCR boot phases, see
+        <citerefentry><refentrytitle>systemd-pcrphase.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--append=</option><replaceable>PATH</replaceable></term>
+
+        <listitem><para>When generating a PCR JSON signature (via the <command>sign</command> command),
+        combine it with a previously generated PCR JSON signature, and output it as one. The specified path
+        must refer to a regular file that contains a valid JSON PCR signature object. The specified file is
+        not modified. It will be read first, then the newly generated signature appended to it, and the
+        resulting object is written to standard output. Use this to generate a single JSON object consisting
+        from signatures made with a number of signing keys (for example, to have one key per boot phase). The
+        command will suppress duplicates: if a specific signature is already included in a JSON signature
+        object it is not added a second time.</para>
+
+        <xi:include href="version-info.xml" xpointer="v253"/></listitem>
+      </varlistentry>
+
+      <xi:include href="standard-options.xml" xpointer="json" />
+      <xi:include href="standard-options.xml" xpointer="no-pager" />
+      <xi:include href="standard-options.xml" xpointer="help" />
+      <xi:include href="standard-options.xml" xpointer="version" />
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Examples</title>
+
+    <example>
+      <title>Generate a unified kernel image, and calculate the expected TPM PCR 11 value</title>
+
+      <programlisting>$ ukify --output=vmlinux.efi \
+     --os-release=@os-release.txt \
+     --cmdline=@cmdline.txt \
+     --splash=splash.bmp \
+     --devicetree=devicetree.dtb \
+     --measure \
+     vmlinux initrd.cpio
+11:sha1=d775a7b4482450ac77e03ee19bda90bd792d6ec7
+11:sha256=bc6170f9ce28eb051ab465cd62be8cf63985276766cf9faf527ffefb66f45651
+11:sha384=1cf67dff4757e61e5...7f49ad720be02fd07263e1f93061243aec599d1ee4b4
+11:sha512=8e79acd3ddbbc8282...0c3e8ec0c714821032038f525f744960bcd082d937da
+</programlisting>
+
+      <para><citerefentry><refentrytitle>ukify</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+      internally calls <command>systemd-measure</command>. The output with hashes is from
+      <command>systemd-measure</command>.</para>
+    </example>
+
+    <example>
+      <title>Generate a private/public key pair, a unified kernel image, and a TPM PCR 11 signature for
+      it, and embed the signature and the public key in the image</title>
+
+      <programlisting>$ openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out tpm2-pcr-private.pem
+..+.+++++++++......+.........+......+.......+....+.....+.+...+..........
+$ openssl rsa -pubout -in tpm2-pcr-private.pem -out tpm2-pcr-public.pem
+# systemd-measure sign \
+     --linux=vmlinux \
+     --osrel=os-release.txt \
+     --cmdline=cmdline.txt \
+     --initrd=initrd.cpio \
+     --splash=splash.bmp \
+     --dtb=devicetree.dtb \
+     --pcrpkey=tpm2-pcr-public.pem \
+     --bank=sha1 \
+     --bank=sha256 \
+     --private-key=tpm2-pcr-private.pem \
+     --public-key=tpm2-pcr-public.pem >tpm2-pcr-signature.json
+# ukify --output=vmlinuz.efi \
+     --os-release=@os-release.txt \
+     --cmdline=@cmdline.txt \
+     --splash=splash.bmp \
+     --devicetree=devicetree.dtb \
+     --pcr-private-key=tpm2-pcr-private.pem \
+     --pcr-public-key=tpm2-pcr-public.pem \
+     --pcr-banks=sha1,sha256 \
+     vmlinux initrd.cpio</programlisting>
+
+     <para>Later on, enroll the signed PCR policy on a LUKS volume:</para>
+
+     <programlisting># systemd-cryptenroll --tpm2-device=auto \
+     --tpm2-public-key=tpm2-pcr-public.pem \
+     --tpm2-signature=tpm2-pcr-signature.json \
+     /dev/sda5</programlisting>
+
+     <para>And then unlock the device with the signature:</para>
+
+     <programlisting># systemd-cryptsetup attach \
+     volume5 /dev/sda5 - \
+     tpm2-device=auto,tpm2-signature=/path/to/tpm2-pcr-signature.json</programlisting>
+
+     <para>Note that when the generated unified kernel image <filename>vmlinux.efi</filename> is booted, the
+     signature and public key files will be placed at locations <command>systemd-cryptenroll</command> and
+     <command>systemd-cryptsetup</command> will look for anyway, and thus these paths do not actually need to
+     be specified.</para>
+    </example>
+
+    <example>
+      <title>Introduce a second public key, signing the same kernel PCR measurements, but only for the initrd boot phase</title>
+
+      <para>This example extends the previous one, but we now introduce a second signing key that is only
+      used to sign PCR policies restricted to the initrd boot phase. This can be used to lock down root
+      volumes in a way that they can only be unlocked before the transition to the host system. Thus we have
+      two classes of secrets or credentials: one that can be unlocked during the entire runtime, and the
+      other that can only be used in the initrd.</para>
+
+      <programlisting>$ openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out tpm2-pcr-private.pem
+.+........+.+........+.......+...+...+........+....+......+..+..........
+$ openssl rsa -pubout -in tpm2-pcr-private.pem -out tpm2-pcr-public.pem
+$ openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out tpm2-pcr-initrd-private.pem
+..+.......++........+........+......+........+....+.....+.+..+..........
+$ openssl rsa -pubout -in tpm2-pcr-initrd-private.pem -out tpm2-pcr-initrd-public.pem
+# ukify --output vmlinux-1.2.3.efi \
+     --os-release=@os-release.txt \
+     --cmdline=@cmdline.txt \
+     --splash=splash.bmp \
+     --devicetree=devicetree.dtb \
+     --pcr-private-key=tpm2-pcr-private.pem \
+     --pcr-public-key=tpm2-pcr-public.pem \
+     --phases=enter-initrd,enter-initrd:leave-initrd,enter-initrd:leave-initrd:sysinit,enter-initrd:leave-initrd:sysinit:ready \
+     --pcr-banks=sha1,sha256 \
+     --pcr-private-key=tpm2-pcr-initrd-private.pem \
+     --pcr-public-key=tpm2-pcr-initrd-public.pem \
+     --phases=enter-initrd \
+     vmlinux-1.2.3 initrd.cpio \
+     --uname=1.2.3
++ /usr/lib/systemd/systemd-measure sign --linux=vmlinux-1.2.3 \
+--osrel=os-release.txt --cmdline=cmdline.txt --dtb=devicetree.dtb \
+--splash=splash.bmp --initrd=initrd.cpio --bank=sha1 --bank=sha256 \
+--private-key=tpm2-pcr-private.pem --public-key=tpm2-pcr-public.pem \
+--phase=enter-initrd --phase=enter-initrd:leave-initrd \
+--phase=enter-initrd:leave-initrd:sysinit \
+--phase=enter-initrd:leave-initrd:sysinit:ready
++ /usr/lib/systemd/systemd-measure sign --linux=vmlinux-1.2.3 \
+--osrel=os-release.txt --cmdline=cmdline.txt --dtb=devicetree.dtb \
+--splash=splash.bmp --initrd=initrd.cpio --bank=sha1 --bank=sha256 \
+--private-key=tpm2-pcr-initrd-private.pem \
+--public-key=tpm2-pcr-initrd-public.pem \
+--phase=enter-initrd
+Wrote unsigned vmlinux-1.2.3.efi
+      </programlisting>
+
+      <para><command>ukify</command> prints out both invocations of <command>systemd-measure</command> as
+      informative output (the lines starting with <literal>+</literal>); this allows us to see how
+      <command>systemd-measure</command> is called. It then merges the output of both invocations into the
+      <literal>.pcrsig</literal> section. <command>systemd-measure</command> may also do this merge itself
+      using the <option>--append=</option> option.</para>
+
+      <para>Note that in this example the <literal>.pcrpkey</literal> PE section contains the key specified
+      by the first <option>--pcr-private-key=</option> option, covering all boot phases. The
+      <literal>.pcrpkey</literal> section is used in the default policies of
+      <command>systemd-cryptenroll</command> and <command>systemd-creds</command>. To use the stricter policy
+      bound to <filename>tpm-pcr-initrd-public.pem</filename>, specify <option>--tpm2-public-key=</option> on
+      the command line of those tools.</para>
+    </example>
+  </refsect1>
+
+  <refsect1>
+    <title>Exit status</title>
+
+    <para>On success, 0 is returned, a non-zero failure code otherwise.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-stub</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>ukify</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-creds</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-cryptsetup@.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-pcrphase.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+     </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-modules-load.service.xml b/man/systemd-modules-load.service.xml
new file mode 100644
index 0000000..fc51716
--- /dev/null
+++ b/man/systemd-modules-load.service.xml
@@ -0,0 +1,73 @@
+<?xml version="1.0"?>
+<!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+<refentry id="systemd-modules-load.service" conditional='HAVE_KMOD'
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd-modules-load.service</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-modules-load.service</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-modules-load.service</refname>
+    <refname>systemd-modules-load</refname>
+    <refpurpose>Load kernel modules at boot</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>systemd-modules-load.service</filename></para>
+    <para><filename>/usr/lib/systemd/systemd-modules-load</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><filename>systemd-modules-load.service</filename> is an early boot service that loads kernel
+    modules. It reads static configuration from files in <filename>/usr/</filename> and
+    <filename>/etc/</filename>, but also runtime configuration from <filename>/run/</filename> and the kernel
+    command line (see below).</para>
+
+    <para>See
+    <citerefentry><refentrytitle>modules-load.d</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
+    information about the configuration format of this service and paths where configuration files can be
+    created.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Kernel Command Line</title>
+
+    <para><filename>systemd-modules-load.service</filename>
+    understands the following kernel command line parameters:</para>
+
+    <variablelist class='kernel-commandline-options'>
+
+      <varlistentry>
+        <term><varname>modules_load=</varname></term>
+        <term><varname>rd.modules_load=</varname></term>
+
+        <listitem><para>Takes a comma-separated list of kernel modules to statically load during early boot.
+        The option prefixed with <literal>rd.</literal> is read in the initrd only.</para>
+
+        <xi:include href="version-info.xml" xpointer="v187"/></listitem>
+      </varlistentry>
+
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>modules-load.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-mount.xml b/man/systemd-mount.xml
new file mode 100644
index 0000000..d92ef18
--- /dev/null
+++ b/man/systemd-mount.xml
@@ -0,0 +1,408 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd-mount"
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd-mount</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-mount</refentrytitle>
+    <manvolnum>1</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-mount</refname>
+    <refname>systemd-umount</refname>
+    <refpurpose>Establish and destroy transient mount or auto-mount points</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <cmdsynopsis>
+      <command>systemd-mount</command>
+      <arg choice="opt" rep="repeat"><replaceable>OPTIONS</replaceable></arg>
+      <arg choice="plain"><replaceable>WHAT</replaceable></arg>
+      <arg choice="opt"><replaceable>WHERE</replaceable></arg>
+    </cmdsynopsis>
+    <cmdsynopsis>
+      <command>systemd-mount</command>
+      <arg choice="opt" rep="repeat"><replaceable>OPTIONS</replaceable></arg>
+      <arg choice="plain"><option>--tmpfs</option></arg>
+      <arg choice="opt"><replaceable>NAME</replaceable></arg>
+      <arg choice="plain"><replaceable>WHERE</replaceable></arg>
+    </cmdsynopsis>
+    <cmdsynopsis>
+      <command>systemd-mount</command>
+      <arg choice="opt" rep="repeat"><replaceable>OPTIONS</replaceable></arg>
+      <arg choice="plain"><option>--list</option></arg>
+    </cmdsynopsis>
+    <cmdsynopsis>
+      <command>systemd-mount</command>
+      <arg choice="opt" rep="repeat"><replaceable>OPTIONS</replaceable></arg>
+      <arg choice="plain"><option>--umount</option></arg>
+      <arg choice="plain" rep="repeat"><replaceable>WHAT|WHERE</replaceable></arg>
+    </cmdsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>systemd-mount</command> may be used to create and start a transient <filename>.mount</filename> or
+    <filename>.automount</filename> unit of the file system <replaceable>WHAT</replaceable> on the mount point
+    <replaceable>WHERE</replaceable>.</para>
+
+    <para>In many ways, <command>systemd-mount</command> is similar to the lower-level
+    <citerefentry project='man-pages'><refentrytitle>mount</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    command, however instead of executing the mount operation directly and immediately,
+    <command>systemd-mount</command> schedules it through the service manager job queue, so that it may pull
+    in further dependencies (such as parent mounts, or a file system checker to execute a priori), and may
+    make use of the auto-mounting logic.</para>
+
+    <para>The command takes either one or two arguments. If only one argument is specified it should refer to
+    a block device or regular file containing a file system (e.g. <literal>/dev/sdb1</literal> or
+    <literal>/path/to/disk.img</literal>). The block device or image file is then probed for a file system
+    label and other metadata, and is mounted to a directory below <filename>/run/media/system/</filename>
+    whose name is generated from the file system label. In this mode the block device or image file must
+    exist at the time of invocation of the command, so that it may be probed. If the device is found to be a
+    removable block device (e.g. a USB stick), an automount point is created instead of a regular mount point
+    (i.e. the <option>--automount=</option> option is implied, see below). If the option
+    <option>--tmpfs</option> is specified, then the argument is interpreted as the path where the new
+    temporary file system shall be mounted.</para>
+
+    <para>If two arguments are specified, the first indicates the mount source (the
+    <replaceable>WHAT</replaceable>) and the second indicates the path to mount it on (the
+    <replaceable>WHERE</replaceable>). In this mode no probing of the source is attempted, and a backing
+    device node doesn't have to exist. However, if this mode is combined with <option>--discover</option>,
+    device node probing for additional metadata is enabled, and – much like in the single-argument case
+    discussed above – the specified device has to exist at the time of invocation of the command.</para>
+
+    <para>Use the <option>--list</option> command to show a terse table of all local, known block devices with file
+    systems that may be mounted with this command.</para>
+
+    <para><command>systemd-umount</command> can be used to unmount a mount or automount point. It is the same
+    as <command>systemd-mount</command> <option>--umount</option>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>The following options are understood:</para>
+
+    <variablelist>
+
+      <varlistentry>
+        <term><option>--no-block</option></term>
+
+        <listitem>
+          <para>Do not synchronously wait for the requested operation to finish. If this is not specified, the job will
+          be verified, enqueued and <command>systemd-mount</command> will wait until the mount or automount unit's
+          start-up is completed. By passing this argument, it is only verified and enqueued.</para>
+
+          <xi:include href="version-info.xml" xpointer="v232"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-l</option></term>
+        <term><option>--full</option></term>
+
+        <listitem>
+          <para>Do not ellipsize the output when <option>--list</option> is specified.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/>
+        </listitem>
+      </varlistentry>
+
+      <xi:include href="standard-options.xml" xpointer="no-pager"/>
+      <xi:include href="standard-options.xml" xpointer="no-legend" />
+      <xi:include href="standard-options.xml" xpointer="no-ask-password"/>
+
+      <varlistentry>
+        <term><option>--quiet</option></term>
+        <term><option>-q</option></term>
+
+        <listitem><para>Suppresses additional informational output while running.</para>
+
+        <xi:include href="version-info.xml" xpointer="v232"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--discover</option></term>
+
+        <listitem><para>Enable probing of the mount source. This switch is implied if a single argument is specified on
+        the command line. If passed, additional metadata is read from the device to enhance the unit to create. For
+        example, a descriptive string for the transient units is generated from the file system label and device
+        model. Moreover if a removable block device (e.g. USB stick) is detected an automount unit instead of a regular
+        mount unit is created, with a short idle timeout, in order to ensure the file-system is placed in a clean
+        state quickly after each access.</para>
+
+        <xi:include href="version-info.xml" xpointer="v232"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--type=</option></term>
+        <term><option>-t</option></term>
+
+        <listitem><para>Specifies the file system type to mount (e.g. <literal>vfat</literal> or
+        <literal>ext4</literal>). If omitted or set to <literal>auto</literal>, the file system type is
+        determined automatically.</para>
+
+        <xi:include href="version-info.xml" xpointer="v232"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--options=</option></term>
+        <term><option>-o</option></term>
+
+        <listitem><para>Additional mount options for the mount point.</para>
+
+        <xi:include href="version-info.xml" xpointer="v232"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--owner=<replaceable>USER</replaceable></option></term>
+
+        <listitem><para>Let the specified user <replaceable>USER</replaceable> own the mounted file system.
+        This is done by appending <option>uid=</option> and <option>gid=</option> options to the list
+        of mount options. Only certain file systems support this option.</para>
+
+        <xi:include href="version-info.xml" xpointer="v237"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--fsck=</option></term>
+
+        <listitem><para>Takes a boolean argument, defaults to on. Controls whether to run a file system check
+        immediately before the mount operation. In the automount case (see <option>--automount=</option> below) the
+        check will be run the moment the first access to the device is made, which might slightly delay the
+        access.</para>
+
+        <xi:include href="version-info.xml" xpointer="v232"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--description=</option></term>
+
+        <listitem><para>Provide a description for the mount or automount unit. See <varname>Description=</varname> in
+        <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v232"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--property=</option></term>
+        <term><option>-p</option></term>
+
+        <listitem><para>Sets a unit property for the mount unit that is created. This takes an assignment in the same
+        format as <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s
+        <command>set-property</command> command.</para>
+
+        <xi:include href="version-info.xml" xpointer="v232"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--automount=</option></term>
+
+        <listitem><para>Takes a boolean argument. Controls whether to create an automount point or a regular mount
+        point. If true an automount point is created that is backed by the actual file system at the time of first
+        access. If false a plain mount point is created that is backed by the actual file system immediately. Automount
+        points have the benefit that the file system stays unmounted and hence in clean state until it is first
+        accessed. In automount mode the <option>--timeout-idle-sec=</option> switch (see below) may be used to ensure
+        the mount point is unmounted automatically after the last access and an idle period passed.</para>
+
+        <para>If this switch is not specified it defaults to false. If not specified and <option>--discover</option> is
+        used (or only a single argument passed, which implies <option>--discover</option>, see above), and the file
+        system block device is detected to be removable, it is set to true, in order to increase the chance that the
+        file system is in a fully clean state if the device is unplugged abruptly.</para>
+
+        <xi:include href="version-info.xml" xpointer="v232"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-A</option></term>
+
+        <listitem><para>Equivalent to <option>--automount=yes</option>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v232"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--timeout-idle-sec=</option></term>
+
+        <listitem><para>Takes a time value that controls the idle timeout in automount mode. If set to
+        <literal>infinity</literal> (the default) no automatic unmounts are done. Otherwise the file system backing the
+        automount point is detached after the last access and the idle timeout passed. See
+        <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry> for details on
+        the time syntax supported. This option has no effect if only a regular mount is established, and automounting
+        is not used.</para>
+
+        <para>Note that if <option>--discover</option> is used (or only a single argument passed, which implies
+        <option>--discover</option>, see above), and the file system block device is detected to be removable,
+        <option>--timeout-idle-sec=1s</option> is implied.</para>
+
+        <xi:include href="version-info.xml" xpointer="v232"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--automount-property=</option></term>
+
+        <listitem><para>Similar to <option>--property=</option>, but applies additional properties to the automount
+        unit created, instead of the mount unit.</para>
+
+        <xi:include href="version-info.xml" xpointer="v232"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--bind-device</option></term>
+
+        <listitem><para>This option only has an effect in automount mode,
+        and controls whether the automount unit shall be bound to the backing device's lifetime. If set, the
+        automount unit will be stopped automatically when the backing device vanishes. By default the automount unit
+        stays around, and subsequent accesses will block until backing device is replugged. This option has no effect
+        in case of non-device mounts, such as network or virtual file system mounts.</para>
+
+        <para>Note that if <option>--discover</option> is used (or only a single argument passed, which implies
+        <option>--discover</option>, see above), and the file system block device is detected to be removable, this
+        option is implied.</para>
+
+        <xi:include href="version-info.xml" xpointer="v232"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--list</option></term>
+
+        <listitem><para>Instead of establishing a mount or automount point, print a terse list of block devices
+        containing file systems that may be mounted with <literal>systemd-mount</literal>, along with useful metadata
+        such as labels, etc.</para>
+
+        <xi:include href="version-info.xml" xpointer="v232"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-u</option></term>
+        <term><option>--umount</option></term>
+
+        <listitem><para>Stop the mount and automount units corresponding to the specified mount points
+        <replaceable>WHERE</replaceable> or the devices <replaceable>WHAT</replaceable>.
+        <command>systemd-mount</command> with this option or <command>systemd-umount</command> can take multiple arguments
+        which can be mount points, devices, <filename>/etc/fstab</filename> style node names, or backing files
+        corresponding to loop devices, like
+        <command>systemd-mount --umount /path/to/umount /dev/sda1 UUID=xxxxxx-xxxx LABEL=xxxxx /path/to/disk.img</command>.
+        Note that when <option>-H</option> or <option>-M</option> is specified, only absolute paths to mount points are
+        supported.</para>
+
+        <xi:include href="version-info.xml" xpointer="v233"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-G</option></term>
+        <term><option>--collect</option></term>
+
+        <listitem><para>Unload the transient unit after it completed, even if it failed. Normally, without this option,
+        all mount units that mount and failed are kept in memory until the user explicitly resets their failure state with
+        <command>systemctl reset-failed</command> or an equivalent command. On the other hand, units that stopped
+        successfully are unloaded immediately. If this option is turned on the "garbage collection" of units is more
+        aggressive, and unloads units regardless if they exited successfully or failed. This option is a shortcut for
+        <command>--property=CollectMode=inactive-or-failed</command>, see the explanation for
+        <varname>CollectMode=</varname> in
+        <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> for further
+        information.</para>
+
+        <xi:include href="version-info.xml" xpointer="v236"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-T</option></term>
+        <term><option>--tmpfs</option></term>
+
+        <listitem>
+          <para>Create and mount a new <constant>tmpfs</constant> file system on
+          <replaceable>WHERE</replaceable>, with an optional <replaceable>NAME</replaceable> that defaults to
+          <literal>tmpfs</literal>.</para>
+
+          <para>The file system is mounted with the top-level directory mode determined by the
+          <citerefentry><refentrytitle>umask</refentrytitle><manvolnum>2</manvolnum></citerefentry> setting
+          of the caller, i.e. <constant>rwxrwxrwx</constant> masked by the umask of the caller. This matches
+          what
+          <citerefentry project='man-pages'><refentrytitle>mkdir</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+          does, but is different from the kernel default of <literal>rwxrwxrwxt</literal>, i.e. a
+          world-writable directory with the sticky bit set.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/>
+        </listitem>
+      </varlistentry>
+
+      <xi:include href="user-system-options.xml" xpointer="user" />
+      <xi:include href="user-system-options.xml" xpointer="system" />
+      <xi:include href="user-system-options.xml" xpointer="host" />
+      <xi:include href="user-system-options.xml" xpointer="machine" />
+
+      <xi:include href="standard-options.xml" xpointer="help" />
+      <xi:include href="standard-options.xml" xpointer="version" />
+    </variablelist>
+
+  </refsect1>
+
+  <refsect1>
+    <title>Exit status</title>
+
+    <para>On success, 0 is returned, a non-zero failure
+    code otherwise.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>The udev Database</title>
+
+    <para>If <option>--discover</option> is used, <command>systemd-mount</command> honors a couple of additional udev
+    properties of block devices:</para>
+
+    <variablelist class='udev-directives'>
+      <varlistentry>
+        <term><varname>SYSTEMD_MOUNT_OPTIONS=</varname></term>
+
+        <listitem><para>The mount options to use, if <option>--options=</option> is not used.</para>
+
+        <xi:include href="version-info.xml" xpointer="v232"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SYSTEMD_MOUNT_WHERE=</varname></term>
+
+        <listitem><para>The file system path to place the mount point at, instead of the automatically generated
+        one.</para>
+
+        <xi:include href="version-info.xml" xpointer="v232"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Example</title>
+
+    <para>Use a udev rule like the following to automatically mount all USB storage plugged in:</para>
+
+    <programlisting>ACTION=="add", SUBSYSTEMS=="usb", SUBSYSTEM=="block", ENV{ID_FS_USAGE}=="filesystem", \
+        RUN{program}+="/usr/bin/systemd-mount --no-block --automount=yes --collect $devnode"</programlisting>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>mount</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.automount</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-run</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-network-generator.service.xml b/man/systemd-network-generator.service.xml
new file mode 100644
index 0000000..c01f701
--- /dev/null
+++ b/man/systemd-network-generator.service.xml
@@ -0,0 +1,129 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd-network-generator.service" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd-network-generator.service</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-network-generator.service</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-network-generator.service</refname>
+    <refname>systemd-network-generator</refname>
+    <refpurpose>Generate network configuration from the kernel command line</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>systemd-network-generator.service</filename></para>
+    <para><filename>/usr/lib/systemd/systemd-network-generator</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><filename>systemd-network-generator.service</filename> is a system service that translates
+    <varname>ip=</varname> and related settings on the kernel command line (see below) into
+    <citerefentry><refentrytitle>systemd.network</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>systemd.netdev</refentrytitle><manvolnum>5</manvolnum></citerefentry>, and
+    <citerefentry><refentrytitle>systemd.link</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    configuration files understood by
+    <citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    and
+    <citerefentry><refentrytitle>systemd-udevd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+    </para>
+
+    <para>Files are generated in <filename>/run/systemd/network/</filename>.</para>
+
+    <para>Note: despite the name, this generator executes as a normal systemd service and is
+    <emphasis>not</emphasis> an implementation of the
+    <citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+    concept.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Kernel command line options</title>
+
+    <para>This tool understands the following options:</para>
+
+    <variablelist class='kernel-commandline-options'>
+      <varlistentry>
+        <term><varname>ip=</varname></term>
+        <term><varname>nameserver=</varname></term>
+        <term><varname>rd.route=</varname></term>
+        <term><varname>rd.peerdns=</varname></term>
+        <listitem>
+          <para>Translated into
+          <citerefentry><refentrytitle>systemd.network</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+          files.</para>
+
+          <para>In addition to the parameters <citerefentry
+          project='man-pages'><refentrytitle>dracut.cmdline</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+          defines the <varname>ip=</varname> option accepts the special value
+          <literal>link-local</literal>. If selected, the network interfaces will be configured for
+          link-local addressing (IPv4LL, IPv6LL) only, DHCP or IPv6RA will not be enabled.</para>
+
+          <xi:include href="version-info.xml" xpointer="v245"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ifname=</varname></term>
+        <term><varname>net.ifname-policy=</varname></term>
+        <listitem>
+          <para>Translated into
+          <citerefentry><refentrytitle>systemd.link</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+          files.</para>
+
+          <xi:include href="version-info.xml" xpointer="v245"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>vlan=</varname></term>
+        <term><varname>bond=</varname></term>
+        <term><varname>bridge=</varname></term>
+        <term><varname>bootdev=</varname></term>
+        <listitem>
+          <para>Translated into
+          <citerefentry><refentrytitle>systemd.netdev</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+          files.</para>
+
+          <xi:include href="version-info.xml" xpointer="v245"/>
+        </listitem>
+      </varlistentry>
+
+      <!-- unsupported:
+           team=<teammaster>:<teamslaves>
+           bootdev=
+           BOOTIF=
+           bootdev=
+           bootdev=
+           bootdev=
+      -->
+    </variablelist>
+
+    <para>See
+    <citerefentry project='man-pages'><refentrytitle>dracut.cmdline</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+    and
+    <citerefentry><refentrytitle>systemd-udevd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    for option syntax and details.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>dracut</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-networkd-wait-online.service.xml b/man/systemd-networkd-wait-online.service.xml
new file mode 100644
index 0000000..06f837a
--- /dev/null
+++ b/man/systemd-networkd-wait-online.service.xml
@@ -0,0 +1,194 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd-networkd-wait-online.service" conditional='ENABLE_NETWORKD'
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd-networkd-wait-online.service</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-networkd-wait-online.service</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-networkd-wait-online.service</refname>
+    <refname>systemd-networkd-wait-online@.service</refname>
+    <refname>systemd-networkd-wait-online</refname>
+    <refpurpose>Wait for network to come online</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>systemd-networkd-wait-online.service</filename></para>
+    <para><filename>systemd-networkd-wait-online@.service</filename></para>
+    <para><filename>/usr/lib/systemd/systemd-networkd-wait-online</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>systemd-networkd-wait-online</command> is a
+    oneshot system service (see <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>), that waits for the network to be
+    configured. By default, it will wait for all links it is aware of
+    and which are managed by
+    <citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    to be fully configured or failed, and for at least one link to be online. Here, online means that
+    the link's operational state is equal or higher than <literal>degraded</literal>. The threshold
+    can be configured by <option>--operational-state=</option> option.</para>
+
+    <para>The service <filename>systemd-networkd-wait-online.service</filename> invokes
+    <command>systemd-networkd-wait-online</command> without any options. Thus, it waits for all managed
+    interfaces to be configured or failed, and for at least one to be online.</para>
+
+    <para>The service <filename>systemd-networkd-wait-online@.service</filename> takes an interface
+    name, and invokes <command>systemd-networkd-wait-online</command> with <option>-i</option> and the
+    specified interface name. Thus, wait for the specified interface to be configured and online. For
+    example, <filename>systemd-networkd-wait-online@eth0.service</filename> waits for
+    <filename>eth0</filename> to be configured by <command>systemd-networkd</command> and online.
+    </para>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>The following options are understood:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><option>-i</option> <replaceable>INTERFACE</replaceable><optional>:<replaceable>MIN_OPERSTATE</replaceable><optional>:<replaceable>MAX_OPERSTATE</replaceable></optional></optional></term>
+        <term><option>--interface=</option><replaceable>INTERFACE</replaceable><optional>:<replaceable>MIN_OPERSTATE</replaceable><optional>:<replaceable>MAX_OPERSTATE</replaceable></optional></optional></term>
+
+        <listitem><para>Network interface to wait for before deciding if the system is online. This
+        is useful when a system has several interfaces which will be configured, but a particular
+        one is necessary to access some network resources. When used, all other interfaces are ignored.
+        This option may be used more than once to wait for multiple network interfaces. When this
+        option is specified multiple times, then <command>systemd-networkd-wait-online</command> waits
+        for all specified interfaces to be online. Optionally, required minimum and maximum operational
+        states can be specified after a colon <literal>:</literal>. Please see
+        <citerefentry><refentrytitle>networkctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+        for possible operational states. If the operational state is not specified here, then
+        the value from <varname>RequiredForOnline=</varname> in the corresponding
+        <filename>.network</filename> file is used if present, and <literal>degraded</literal> otherwise.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v213"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--ignore=</option><replaceable>INTERFACE</replaceable></term>
+
+        <listitem><para>Network interfaces to be ignored when deciding
+        if the system is online. By default, only the loopback
+        interface is ignored. This option may be used more than once
+        to ignore multiple network interfaces. </para>
+
+        <xi:include href="version-info.xml" xpointer="v219"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-o</option> <replaceable>MIN_OPERSTATE</replaceable><optional>:<replaceable>MAX_OPERSTATE</replaceable></optional></term>
+        <term><option>--operational-state=</option><replaceable>MIN_OPERSTATE</replaceable><optional>:<replaceable>MAX_OPERSTATE</replaceable></optional></term>
+
+        <listitem><para>Takes a minimum operational state and an optional maximum operational state.
+        Please see <citerefentry><refentrytitle>networkctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+        for possible operational states. If set, the specified value overrides
+        <varname>RequiredForOnline=</varname> settings in <filename>.network</filename> files.
+        But this does not override operational states specified in <option>--interface=</option> option.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v242"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-4</option></term>
+        <term><option>--ipv4</option></term>
+
+        <listitem><para>Waiting for an IPv4 address of each network interface to be configured. If this
+        option is specified with <option>--any</option>, then
+        <command>systemd-networkd-wait-online</command> exits with success when at least one interface
+        becomes online and has an IPv4 address. If the required minimum operational state is
+        below <literal>routable</literal>, then each link (or at least one link with
+        <option>--any</option>) must have an IPv4 link-local or routable address. If the required
+        minimum operational state is <literal>routable</literal>, then each link must have an IPv4
+        routable address.</para>
+        <para>If neither <option>--ipv4</option> nor
+        <option>--ipv6</option> is specified, then the value from
+        <varname>RequiredFamilyForOnline=</varname> in the corresponding <filename>.network</filename>
+        file is used if present.</para>
+
+        <xi:include href="version-info.xml" xpointer="v249"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-6</option></term>
+        <term><option>--ipv6</option></term>
+
+        <listitem><para>Waiting for an IPv6 address of each network interface to be configured. If this
+        option is specified with <option>--any</option>, then
+        <command>systemd-networkd-wait-online</command> exits with success when at least one interface
+        becomes online and has an IPv6 address. If the required minimum operational state is
+        below <literal>routable</literal>, then each link (or at least one link with
+        <option>--any</option>) must have an IPv6 link-local or routable address. If the required
+        minimum operational state is <literal>routable</literal>, then each link must have an IPv6
+        routable address.</para>
+        <para>If neither <option>--ipv4</option> nor
+        <option>--ipv6</option> is specified, then the value from
+        <varname>RequiredFamilyForOnline=</varname> in the corresponding <filename>.network</filename>
+        file is used if present.</para>
+
+        <xi:include href="version-info.xml" xpointer="v249"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--any</option></term>
+
+        <listitem><para>Even if several interfaces are in configuring state,
+        <command>systemd-networkd-wait-online</command> exits with success when at least one interface
+        becomes online. When this option is specified with <option>--interface=</option>, then
+        <command>systemd-networkd-wait-online</command> waits for one of the specified interfaces to be
+        online. This option is useful when some interfaces may not have carrier on boot.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v242"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--timeout=</option><replaceable>SECS</replaceable></term>
+
+        <listitem><para>Fail the service if the network is not online
+        by the time the timeout elapses. A timeout of 0 disables the
+        timeout. Defaults to 120 seconds. </para>
+
+        <xi:include href="version-info.xml" xpointer="v219"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-q</option></term>
+        <term><option>--quiet</option></term>
+
+        <listitem><para>Suppress log messages.</para>
+
+        <xi:include href="version-info.xml" xpointer="v242"/></listitem>
+      </varlistentry>
+
+      <xi:include href="standard-options.xml" xpointer="help" />
+      <xi:include href="standard-options.xml" xpointer="version" />
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>networkctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-networkd.service.xml b/man/systemd-networkd.service.xml
new file mode 100644
index 0000000..12cd4c3
--- /dev/null
+++ b/man/systemd-networkd.service.xml
@@ -0,0 +1,97 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd-networkd.service" conditional='ENABLE_NETWORKD'>
+
+  <refentryinfo>
+    <title>systemd-networkd.service</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-networkd.service</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-networkd.service</refname>
+    <refname>systemd-networkd</refname>
+    <refpurpose>Network manager</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>systemd-networkd.service</filename></para>
+    <para><filename>/usr/lib/systemd/systemd-networkd</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>systemd-networkd</command> is a system service that
+    manages networks. It detects and configures network devices as
+    they appear, as well as creating virtual network devices.</para>
+
+    <para>To configure low-level link settings independently of
+    networks, see
+    <citerefentry><refentrytitle>systemd.link</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+
+    <para><command>systemd-networkd</command> will create network devices based
+    on the configuration in
+    <citerefentry><refentrytitle>systemd.netdev</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    files, respecting the [Match] sections in those files.</para>
+
+    <para><command>systemd-networkd</command> will manage network addresses and
+    routes for any link for which it finds a <filename>.network</filename> file
+    with an appropriate [Match] section, see
+    <citerefentry><refentrytitle>systemd.network</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+    For those links, it will flush existing network addresses and routes when
+    bringing up the device. Any links not matched by one of the
+    <filename>.network</filename> files will be ignored. It is also possible to
+    explicitly tell <filename>systemd-networkd</filename> to ignore a link by
+    using <varname>Unmanaged=yes</varname> option, see
+    <citerefentry><refentrytitle>systemd.network</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+    </para>
+
+    <para>When <filename>systemd-networkd</filename> exits, it generally leaves existing network devices and
+    configuration intact. This makes it possible to transition from the initrd and to restart the service
+    without breaking connectivity. This also means that when configuration is updated and
+    <filename>systemd-networkd</filename> is restarted, netdev interfaces for which configuration was removed
+    will not be dropped, and may need to be cleaned up manually.</para>
+
+    <para><command>systemd-networkd</command> may be introspected and controlled at runtime using
+    <citerefentry><refentrytitle>networkctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
+    </para>
+  </refsect1>
+
+  <refsect1><title>Configuration Files</title>
+    <para>The configuration files are read from the files located in the
+    system network directory <filename>/usr/lib/systemd/network</filename>,
+    the volatile runtime network directory
+    <filename>/run/systemd/network</filename> and the local administration
+    network directory <filename>/etc/systemd/network</filename>.</para>
+
+    <para>Networks are configured in <filename>.network</filename>
+    files, see
+    <citerefentry><refentrytitle>systemd.network</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    and virtual network devices are configured in
+    <filename>.netdev</filename> files, see
+    <citerefentry><refentrytitle>systemd.netdev</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+    </para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>networkctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.link</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.network</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.netdev</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-networkd-wait-online.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-network-generator.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-notify.xml b/man/systemd-notify.xml
new file mode 100644
index 0000000..0222978
--- /dev/null
+++ b/man/systemd-notify.xml
@@ -0,0 +1,282 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd-notify"
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd-notify</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-notify</refentrytitle>
+    <manvolnum>1</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-notify</refname>
+    <refpurpose>Notify service manager about start-up completion and other daemon status changes</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <cmdsynopsis>
+      <command>systemd-notify <arg choice="opt" rep="repeat">OPTIONS</arg> <arg choice="opt" rep="repeat">VARIABLE=VALUE</arg></command>
+    </cmdsynopsis>
+    <cmdsynopsis>
+      <command>systemd-notify --exec <arg choice="opt" rep="repeat">OPTIONS</arg> <arg choice="opt" rep="repeat">VARIABLE=VALUE</arg> ; <arg rep="repeat">CMDLINE</arg></command>
+    </cmdsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>systemd-notify</command> may be called by service scripts to notify the invoking service
+    manager about status changes. It can be used to send arbitrary information, encoded in an
+    environment-block-like list of strings. Most importantly, it can be used for start-up completion
+    notification.</para>
+
+    <para>This is mostly just a wrapper around <function>sd_notify()</function> and makes this functionality
+    available to shell scripts. For details see
+    <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+    </para>
+
+    <para>The command line may carry a list of environment variables to send as part of the status
+    update.</para>
+
+    <para>Note that systemd will refuse reception of status updates from this command unless
+    <varname>NotifyAccess=</varname> is appropriately set for the service unit this command is called
+    from. See
+    <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
+    details.</para>
+
+    <para>Note that <function>sd_notify()</function> notifications may be attributed to units correctly only
+    if either the sending process is still around at the time the service manager processes the message, or
+    if the sending process is explicitly runtime-tracked by the service manager. The latter is the case if
+    the service manager originally forked off the process, i.e. on all processes that match
+    <varname>NotifyAccess=</varname><option>main</option> or
+    <varname>NotifyAccess=</varname><option>exec</option>. Conversely, if an auxiliary process of the unit
+    sends an <function>sd_notify()</function> message and immediately exits, the service manager might not be
+    able to properly attribute the message to the unit, and thus will ignore it, even if
+    <varname>NotifyAccess=</varname><option>all</option> is set for it. To address this
+    <command>systemd-notify</command> will wait until the notification message has been processed by the
+    service manager. When <option>--no-block</option> is used, this synchronization for reception of
+    notifications is disabled, and hence the aforementioned race may occur if the invoking process is not the
+    service manager or spawned by the service manager.</para>
+
+    <para><command>systemd-notify</command> will first attempt to invoke <function>sd_notify()</function>
+    pretending to have the PID of the parent process of <command>systemd-notify</command> (i.e. the invoking
+    process). This will only succeed when invoked with sufficient privileges.  On failure, it will then fall
+    back to invoking it under its own PID. This behaviour is useful in order that when the tool is invoked
+    from a shell script the shell process — and not the <command>systemd-notify</command> process — appears
+    as sender of the message, which in turn is helpful if the shell process is the main process of a service,
+    due to the limitations of <varname>NotifyAccess=</varname><option>all</option>. Use the
+    <option>--pid=</option> switch to tweak this behaviour.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>The following options are understood:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><option>--ready</option></term>
+
+        <listitem><para>Inform the invoking service manager about service start-up or configuration reload
+        completion. This is equivalent to <command>systemd-notify READY=1</command>. For details about the
+        semantics of this option see
+        <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--reloading</option></term>
+
+        <listitem><para>Inform the invoking service manager about the beginning of a configuration reload
+        cycle. This is equivalent to <command>systemd-notify RELOADING=1</command> (but implicitly also sets
+        a <varname>MONOTONIC_USEC=</varname> field as required for <varname>Type=notify-reload</varname>
+        services, see
+        <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for details). For details about the semantics of this option see
+        <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v253"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--stopping</option></term>
+
+        <listitem><para>Inform the invoking service manager about the beginning of the shutdown phase of the
+        service. This is equivalent to <command>systemd-notify STOPPING=1</command>. For details about the
+        semantics of this option see
+        <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v253"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--pid=</option></term>
+
+        <listitem><para>Inform the service manager about the main PID of the service. Takes a PID as
+        argument. If the argument is specified as <literal>auto</literal> or omitted, the PID of the process
+        that invoked <command>systemd-notify</command> is used, except if that's the service manager. If the
+        argument is specified as <literal>self</literal>, the PID of the <command>systemd-notify</command>
+        command itself is used, and if <literal>parent</literal> is specified the calling process' PID is
+        used — even if it is the service manager. The latter is equivalent to <command>systemd-notify
+        MAINPID=$PID</command>. For details about the semantics of this option see
+        <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para>
+
+        <para>If this switch is used in an <command>systemd-notify</command> invocation from a process that
+        shall become the new main process of a service — and which is not the process forked off by the
+        service manager (or the current main process) —, then it is essential to set
+        <varname>NotifyAccess=all</varname> in the service unit file, or otherwise the notification will be
+        ignored for security reasons. See
+        <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for details.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--uid=</option><replaceable>USER</replaceable></term>
+
+        <listitem><para>Set the user ID to send the notification from. Takes a UNIX user name or numeric UID. When
+        specified the notification message will be sent with the specified UID as sender, in place of the user the
+        command was invoked as. This option requires sufficient privileges in order to be able manipulate the user
+        identity of the process.</para>
+
+        <xi:include href="version-info.xml" xpointer="v237"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--status=</option></term>
+
+        <listitem><para>Send a free-form human readable status string for the daemon to the service
+        manager. This option takes the status string as argument. This is equivalent to
+        <command>systemd-notify STATUS=…</command>. For details about the semantics of this option see
+        <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>. This
+        information is shown in
+        <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s
+        <command>status</command> output, among other places.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--booted</option></term>
+
+        <listitem><para>Returns 0 if the system was booted up with systemd, non-zero otherwise. If this
+        option is passed, no message is sent. This option is hence unrelated to the other options. For
+        details about the semantics of this option, see
+        <citerefentry><refentrytitle>sd_booted</refentrytitle><manvolnum>3</manvolnum></citerefentry>. An
+        alternate way to check for this state is to call
+        <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> with
+        the <command>is-system-running</command> command. It will return <literal>offline</literal> if the
+        system was not booted with systemd.  </para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--no-block</option></term>
+
+        <listitem><para>Do not synchronously wait for the requested operation to finish.  Use of this option
+        is only recommended when <command>systemd-notify</command> is spawned by the service manager, or when
+        the invoking process is directly spawned by the service manager and has enough privileges to allow
+        <command>systemd-notify</command> to send the notification on its behalf. Sending notifications with
+        this option set is prone to race conditions in all other cases.</para>
+
+        <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--exec</option></term>
+
+        <listitem><para>If specified <command>systemd-notify</command> will execute another command line
+        after it completed its operation, replacing its own process. If used, the list of assignments to
+        include in the message sent must be followed by a <literal>;</literal> character (as separate
+        argument), followed by the command line to execute. This permits "chaining" of commands, i.e. issuing
+        one operation, followed immediately by another, without changing PIDs.</para>
+
+        <para>Note that many shells interpret <literal>;</literal> as their own separator for command lines,
+        hence when <command>systemd-notify</command> is invoked from a shell the semicolon must usually be
+        escaped as <literal>\;</literal>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--fd=</option></term>
+
+        <listitem><para>Send a file descriptor along with the notification message. This is useful when
+        invoked in services that have the <varname>FileDescriptorStoreMax=</varname> setting enabled, see
+        <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for details. The specified file descriptor must be passed to <command>systemd-notify</command> when
+        invoked. This option may be used multiple times to pass multiple file descriptors in a single
+        notification message.</para>
+
+        <para>To use this functionality from a
+        <citerefentry project='man-pages'><refentrytitle>bash</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+        shell, use an expression like the following:</para>
+        <programlisting>systemd-notify --fd=4 --fd=5 4&lt;/some/file 5&lt;/some/other/file</programlisting>
+
+        <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--fdname=</option></term>
+
+        <listitem><para>Set a name to assign to the file descriptors passed via <option>--fd=</option> (see
+        above). This controls the <literal>FDNAME=</literal> field. This setting may only be specified once,
+        and applies to all file descriptors passed. Invoke this tool multiple times in case multiple file
+        descriptors with different file descriptor names shall be submitted.</para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+      </varlistentry>
+
+      <xi:include href="standard-options.xml" xpointer="help" />
+      <xi:include href="standard-options.xml" xpointer="version" />
+    </variablelist>
+
+  </refsect1>
+
+  <refsect1>
+    <title>Exit status</title>
+
+    <para>On success, 0 is returned, a non-zero failure code
+    otherwise.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Example</title>
+
+    <example>
+      <title>Start-up Notification and Status Updates</title>
+
+      <para>A simple shell daemon that sends start-up notifications after having set up its communication
+      channel. During runtime it sends further status updates to the init system:</para>
+
+      <programlisting>#!/bin/sh
+
+mkfifo /tmp/waldo
+systemd-notify --ready --status="Waiting for data…"
+
+while : ; do
+        read -r a &lt; /tmp/waldo
+        systemd-notify --status="Processing $a"
+
+        # Do something with $a …
+
+        systemd-notify --status="Waiting for data…"
+done</programlisting>
+    </example>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_booted</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+</refentry>
diff --git a/man/systemd-nspawn.xml b/man/systemd-nspawn.xml
new file mode 100644
index 0000000..e1e6d84
--- /dev/null
+++ b/man/systemd-nspawn.xml
@@ -0,0 +1,1908 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [
+<!ENTITY % entities SYSTEM "custom-entities.ent" >
+%entities;
+]>
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd-nspawn"
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd-nspawn</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-nspawn</refentrytitle>
+    <manvolnum>1</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-nspawn</refname>
+    <refpurpose>Spawn a command or OS in a light-weight container</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <cmdsynopsis>
+      <command>systemd-nspawn</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="opt"><replaceable>COMMAND</replaceable>
+      <arg choice="opt" rep="repeat">ARGS</arg>
+      </arg>
+    </cmdsynopsis>
+    <cmdsynopsis>
+      <command>systemd-nspawn</command>
+      <arg choice="plain">--boot</arg>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="opt" rep="repeat">ARGS</arg>
+    </cmdsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>systemd-nspawn</command> may be used to run a command or OS in a light-weight namespace
+    container. In many ways it is similar to <citerefentry
+    project='man-pages'><refentrytitle>chroot</refentrytitle><manvolnum>1</manvolnum></citerefentry>, but more powerful
+    since it fully virtualizes the file system hierarchy, as well as the process tree, the various IPC subsystems and
+    the host and domain name.</para>
+
+    <para><command>systemd-nspawn</command> may be invoked on any directory tree containing an operating system tree,
+    using the <option>--directory=</option> command line option. By using the <option>--machine=</option> option an OS
+    tree is automatically searched for in a couple of locations, most importantly in
+    <filename>/var/lib/machines/</filename>, the suggested directory to place OS container images installed on the
+    system.</para>
+
+    <para>In contrast to <citerefentry
+    project='man-pages'><refentrytitle>chroot</refentrytitle><manvolnum>1</manvolnum></citerefentry> <command>systemd-nspawn</command>
+    may be used to boot full Linux-based operating systems in a container.</para>
+
+    <para><command>systemd-nspawn</command> limits access to various kernel interfaces in the container to read-only,
+    such as <filename>/sys/</filename>, <filename>/proc/sys/</filename> or <filename>/sys/fs/selinux/</filename>. The
+    host's network interfaces and the system clock may not be changed from within the container. Device nodes may not
+    be created. The host system cannot be rebooted and kernel modules may not be loaded from within the
+    container.</para>
+
+    <para>Use a tool like <citerefentry
+    project='mankier'><refentrytitle>dnf</refentrytitle><manvolnum>8</manvolnum></citerefentry>, <citerefentry
+    project='die-net'><refentrytitle>debootstrap</refentrytitle><manvolnum>8</manvolnum></citerefentry>, or
+    <citerefentry project='archlinux'><refentrytitle>pacman</refentrytitle><manvolnum>8</manvolnum></citerefentry> to
+    set up an OS directory tree suitable as file system hierarchy for <command>systemd-nspawn</command> containers. See
+    the Examples section below for details on suitable invocation of these commands.</para>
+
+    <para>As a safety check <command>systemd-nspawn</command> will verify the existence of
+    <filename>/usr/lib/os-release</filename> or <filename>/etc/os-release</filename> in the container tree before
+    booting a container (see
+    <citerefentry><refentrytitle>os-release</refentrytitle><manvolnum>5</manvolnum></citerefentry>).  It might be
+    necessary to add this file to the container tree manually if the OS of the container is too old to contain this
+    file out-of-the-box.</para>
+
+    <para><command>systemd-nspawn</command> may be invoked directly from the interactive command line or run as system
+    service in the background. In this mode each container instance runs as its own service instance; a default
+    template unit file <filename>systemd-nspawn@.service</filename> is provided to make this easy, taking the container
+    name as instance identifier. Note that different default options apply when <command>systemd-nspawn</command> is
+    invoked by the template unit file than interactively on the command line. Most importantly the template unit file
+    makes use of the <option>--boot</option> option which is not the default in case <command>systemd-nspawn</command>
+    is invoked from the interactive command line. Further differences with the defaults are documented along with the
+    various supported options below.</para>
+
+    <para>The <citerefentry><refentrytitle>machinectl</refentrytitle><manvolnum>1</manvolnum></citerefentry> tool may
+    be used to execute a number of operations on containers. In particular it provides easy-to-use commands to run
+    containers as system services using the <filename>systemd-nspawn@.service</filename> template unit
+    file.</para>
+
+    <para>Along with each container a settings file with the <filename>.nspawn</filename> suffix may exist, containing
+    additional settings to apply when running the container. See
+    <citerefentry><refentrytitle>systemd.nspawn</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
+    details. Settings files override the default options used by the <filename>systemd-nspawn@.service</filename>
+    template unit file, making it usually unnecessary to alter this template file directly.</para>
+
+    <para>Note that <command>systemd-nspawn</command> will mount file systems private to the container to
+    <filename>/dev/</filename>, <filename>/run/</filename> and similar. These will not be visible outside of the
+    container, and their contents will be lost when the container exits.</para>
+
+    <para>Note that running two <command>systemd-nspawn</command> containers from the same directory tree will not make
+    processes in them see each other. The PID namespace separation of the two containers is complete and the containers
+    will share very few runtime objects except for the underlying file system. Rather use
+    <citerefentry><refentrytitle>machinectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s
+    <command>login</command> or <command>shell</command> commands to request an additional login session in a running
+    container.</para>
+
+    <para><command>systemd-nspawn</command> implements the <ulink
+    url="https://systemd.io/CONTAINER_INTERFACE">Container Interface</ulink> specification.</para>
+
+    <para>While running, containers invoked with <command>systemd-nspawn</command> are registered with the
+    <citerefentry><refentrytitle>systemd-machined</refentrytitle><manvolnum>8</manvolnum></citerefentry> service that
+    keeps track of running containers, and provides programming interfaces to interact with them.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>If option <option>--boot</option> is specified, the arguments
+    are used as arguments for the init program. Otherwise,
+    <replaceable>COMMAND</replaceable> specifies the program to launch
+    in the container, and the remaining arguments are used as
+    arguments for this program. If <option>--boot</option> is not used and
+    no arguments are specified, a shell is launched in the
+    container.</para>
+
+    <para>The following options are understood:</para>
+
+    <variablelist>
+
+      <varlistentry>
+        <term><option>-q</option></term>
+        <term><option>--quiet</option></term>
+
+        <listitem><para>Turns off any status output by the tool
+        itself. When this switch is used, the only output from nspawn
+        will be the console output of the container OS
+        itself.</para>
+
+        <xi:include href="version-info.xml" xpointer="v209"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--settings=</option><replaceable>MODE</replaceable></term>
+
+        <listitem><para>Controls whether
+        <command>systemd-nspawn</command> shall search for and use
+        additional per-container settings from
+        <filename>.nspawn</filename> files. Takes a boolean or the
+        special values <option>override</option> or
+        <option>trusted</option>.</para>
+
+        <para>If enabled (the default), a settings file named after the
+        machine (as specified with the <option>--machine=</option>
+        setting, or derived from the directory or image file name)
+        with the suffix <filename>.nspawn</filename> is searched in
+        <filename>/etc/systemd/nspawn/</filename> and
+        <filename>/run/systemd/nspawn/</filename>. If it is found
+        there, its settings are read and used. If it is not found
+        there, it is subsequently searched in the same directory as the
+        image file or in the immediate parent of the root directory of
+        the container. In this case, if the file is found, its settings
+        will be also read and used, but potentially unsafe settings
+        are ignored. Note that in both these cases, settings on the
+        command line take precedence over the corresponding settings
+        from loaded <filename>.nspawn</filename> files, if both are
+        specified. Unsafe settings are considered all settings that
+        elevate the container's privileges or grant access to
+        additional resources such as files or directories of the
+        host. For details about the format and contents of
+        <filename>.nspawn</filename> files, consult
+        <citerefentry><refentrytitle>systemd.nspawn</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+
+        <para>If this option is set to <option>override</option>, the
+        file is searched, read and used the same way, however, the order of
+        precedence is reversed: settings read from the
+        <filename>.nspawn</filename> file will take precedence over
+        the corresponding command line options, if both are
+        specified.</para>
+
+        <para>If this option is set to <option>trusted</option>, the
+        file is searched, read and used the same way, but regardless
+        of being found in <filename>/etc/systemd/nspawn/</filename>,
+        <filename>/run/systemd/nspawn/</filename> or next to the image
+        file or container root directory, all settings will take
+        effect, however, command line arguments still take precedence
+        over corresponding settings.</para>
+
+        <para>If disabled, no <filename>.nspawn</filename> file is read
+        and no settings except the ones on the command line are in
+        effect.</para>
+
+        <xi:include href="version-info.xml" xpointer="v226"/></listitem>
+      </varlistentry>
+
+    </variablelist>
+
+    <refsect2>
+    <title>Image Options</title>
+
+    <variablelist>
+
+      <varlistentry>
+        <term><option>-D</option></term>
+        <term><option>--directory=</option></term>
+
+        <listitem><para>Directory to use as file system root for the
+        container.</para>
+
+        <para>If neither <option>--directory=</option>, nor
+        <option>--image=</option> is specified the directory is
+        determined by searching for a directory named the same as the
+        machine name specified with <option>--machine=</option>. See
+        <citerefentry><refentrytitle>machinectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+        section "Files and Directories" for the precise search path.</para>
+
+        <para>If neither <option>--directory=</option>,
+        <option>--image=</option>, nor <option>--machine=</option>
+        are specified, the current directory will
+        be used. May not be specified together with
+        <option>--image=</option>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--template=</option></term>
+
+        <listitem><para>Directory or <literal>btrfs</literal> subvolume to use as template for the
+        container's root directory. If this is specified and the container's root directory (as configured by
+        <option>--directory=</option>) does not yet exist it is created as <literal>btrfs</literal> snapshot
+        (if supported) or plain directory (otherwise) and populated from this template tree. Ideally, the
+        specified template path refers to the root of a <literal>btrfs</literal> subvolume, in which case a
+        simple copy-on-write snapshot is taken, and populating the root directory is instant. If the
+        specified template path does not refer to the root of a <literal>btrfs</literal> subvolume (or not
+        even to a <literal>btrfs</literal> file system at all), the tree is copied (though possibly in a
+        'reflink' copy-on-write scheme — if the file system supports that), which can be substantially more
+        time-consuming. Note that the snapshot taken is of the specified directory or subvolume, including
+        all subdirectories and subvolumes below it, but excluding any sub-mounts. May not be specified
+        together with <option>--image=</option> or <option>--ephemeral</option>.</para>
+
+        <para>Note that this switch leaves hostname, machine ID and
+        all other settings that could identify the instance
+        unmodified.</para>
+
+        <xi:include href="version-info.xml" xpointer="v219"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-x</option></term>
+        <term><option>--ephemeral</option></term>
+
+        <listitem><para>If specified, the container is run with a temporary snapshot of its file system that is removed
+        immediately when the container terminates. May not be specified together with
+        <option>--template=</option>.</para>
+        <para>Note that this switch leaves hostname, machine ID and all other settings that could identify
+        the instance unmodified. Please note that — as with <option>--template=</option> — taking the
+        temporary snapshot is more efficient on file systems that support subvolume snapshots or 'reflinks'
+        natively (<literal>btrfs</literal> or new <literal>xfs</literal>) than on more traditional file
+        systems that do not (<literal>ext4</literal>). Note that the snapshot taken is of the specified
+        directory or subvolume, including all subdirectories and subvolumes below it, but excluding any
+        sub-mounts.</para>
+
+        <para>With this option no modifications of the container image are retained. Use
+        <option>--volatile=</option> (described below) for other mechanisms to restrict persistency of
+        container images during runtime.</para>
+
+        <xi:include href="version-info.xml" xpointer="v219"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-i</option></term>
+        <term><option>--image=</option></term>
+
+        <listitem><para>Disk image to mount the root directory for the
+        container from. Takes a path to a regular file or to a block
+        device node. The file or block device must contain
+        either:</para>
+
+        <itemizedlist>
+          <listitem><para>An MBR partition table with a single
+          partition of type 0x83 that is marked
+          bootable.</para></listitem>
+
+          <listitem><para>A GUID partition table (GPT) with a single
+          partition of type
+          0fc63daf-8483-4772-8e79-3d69d8477de4.</para></listitem>
+
+          <listitem><para>A GUID partition table (GPT) with a marked
+          root partition which is mounted as the root directory of the
+          container. Optionally, GPT images may contain a home and/or
+          a server data partition which are mounted to the appropriate
+          places in the container. All these partitions must be
+          identified by the partition types defined by the <ulink
+          url="https://uapi-group.org/specifications/specs/discoverable_partitions_specification">Discoverable
+          Partitions Specification</ulink>.</para></listitem>
+
+          <listitem><para>No partition table, and a single file system spanning the whole image.</para></listitem>
+        </itemizedlist>
+
+        <para>On GPT images, if an EFI System Partition (ESP) is discovered, it is automatically mounted to
+        <filename>/efi</filename> (or <filename>/boot</filename> as fallback) in case a directory by this name exists
+        and is empty.</para>
+
+        <para>Partitions encrypted with LUKS are automatically decrypted. Also, on GPT images dm-verity data integrity
+        hash partitions are set up if the root hash for them is specified using the <option>--root-hash=</option>
+        option.</para>
+
+        <para>Single file system images (i.e. file systems without a surrounding partition table) can be opened using
+        dm-verity if the integrity data is passed using the <option>--root-hash=</option> and
+        <option>--verity-data=</option> (and optionally <option>--root-hash-sig=</option>) options.</para>
+
+        <para>Any other partitions, such as foreign partitions or swap partitions are not mounted. May not be specified
+        together with <option>--directory=</option>, <option>--template=</option>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v211"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--image-policy=<replaceable>policy</replaceable></option></term>
+
+        <listitem><para>Takes an image policy string as argument, as per
+        <citerefentry><refentrytitle>systemd.image-policy</refentrytitle><manvolnum>7</manvolnum></citerefentry>. The
+        policy is enforced when operating on the disk image specified via <option>--image=</option>, see
+        above. If not specified defaults to
+        <literal>root=verity+signed+encrypted+unprotected+absent:usr=verity+signed+encrypted+unprotected+absent:home=encrypted+unprotected+absent:srv=encrypted+unprotected+absent:esp=unprotected+absent:xbootldr=unprotected+absent:tmp=encrypted+unprotected+absent:var=encrypted+unprotected+absent</literal>,
+        i.e. all recognized file systems in the image are used, but not the swap partition.</para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--oci-bundle=</option></term>
+
+        <listitem><para>Takes the path to an OCI runtime bundle to invoke, as specified in the <ulink
+        url="https://github.com/opencontainers/runtime-spec/blob/master/spec.md">OCI Runtime Specification</ulink>. In
+        this case no <filename>.nspawn</filename> file is loaded, and the root directory and various settings are read
+        from the OCI runtime JSON data (but data passed on the command line takes precedence).</para>
+
+        <xi:include href="version-info.xml" xpointer="v242"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--read-only</option></term>
+
+        <listitem><para>Mount the container's root file system (and any other file systems container in the container
+        image) read-only. This has no effect on additional mounts made with <option>--bind=</option>,
+        <option>--tmpfs=</option> and similar options. This mode is implied if the container image file or directory is
+        marked read-only itself. It is also implied if <option>--volatile=</option> is used. In this case the container
+        image on disk is strictly read-only, while changes are permitted but kept non-persistently in memory only. For
+        further details, see below.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--volatile</option></term>
+        <term><option>--volatile=</option><replaceable>MODE</replaceable></term>
+
+        <listitem><para>Boots the container in volatile mode. When no mode parameter is passed or when mode is
+        specified as <option>yes</option>, full volatile mode is enabled. This means the root directory is mounted as a
+        mostly unpopulated <literal>tmpfs</literal> instance, and <filename>/usr/</filename> from the OS tree is
+        mounted into it in read-only mode (the system thus starts up with read-only OS image, but pristine state and
+        configuration, any changes are lost on shutdown). When the mode parameter is specified as
+        <option>state</option>, the OS tree is mounted read-only, but <filename>/var/</filename> is mounted as a
+        writable <literal>tmpfs</literal> instance into it (the system thus starts up with read-only OS resources and
+        configuration, but pristine state, and any changes to the latter are lost on shutdown). When the mode parameter
+        is specified as <option>overlay</option> the read-only root file system is combined with a writable
+        <filename>tmpfs</filename> instance through <literal>overlayfs</literal>, so that it appears at it normally
+        would, but any changes are applied to the temporary file system only and lost when the container is
+        terminated. When the mode parameter is specified as <option>no</option> (the default), the whole OS tree is
+        made available writable (unless <option>--read-only</option> is specified, see above).</para>
+
+        <para>Note that if one of the volatile modes is chosen, its effect is limited to the root file system
+        (or <filename>/var/</filename> in case of <option>state</option>), and any other mounts placed in the
+        hierarchy are unaffected — regardless if they are established automatically (e.g. the EFI system
+        partition that might be mounted to <filename>/efi/</filename> or <filename>/boot/</filename>) or
+        explicitly (e.g. through an additional command line option such as <option>--bind=</option>, see
+        below). This means, even if <option>--volatile=overlay</option> is used changes to
+        <filename>/efi/</filename> or <filename>/boot/</filename> are prohibited in case such a partition
+        exists in the container image operated on, and even if <option>--volatile=state</option> is used the
+        hypothetical file <filename index="false">/etc/foobar</filename> is potentially writable if
+        <option>--bind=/etc/foobar</option> if used to mount it from outside the read-only container
+        <filename>/etc/</filename> directory.</para>
+
+        <para>The <option>--ephemeral</option> option is closely related to this setting, and provides similar
+        behaviour by making a temporary, ephemeral copy of the whole OS image and executing that. For further details,
+        see above.</para>
+
+        <para>The <option>--tmpfs=</option> and <option>--overlay=</option> options provide similar functionality, but
+        for specific sub-directories of the OS image only. For details, see below.</para>
+
+        <para>This option provides similar functionality for containers as the <literal>systemd.volatile=</literal>
+        kernel command line switch provides for host systems. See
+        <citerefentry><refentrytitle>kernel-command-line</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
+        details.</para>
+
+        <para>Note that setting this option to <option>yes</option> or <option>state</option> will only work
+        correctly with operating systems in the container that can boot up with only
+        <filename>/usr/</filename> mounted, and are able to automatically populate <filename>/var/</filename>
+        (and <filename>/etc/</filename> in case of <literal>--volatile=yes</literal>). Specifically, this
+        means that operating systems that follow the historic split of <filename>/bin/</filename> and
+        <filename>/lib/</filename> (and related directories) from <filename>/usr/</filename> (i.e. where the
+        former are not symlinks into the latter) are not supported by <literal>--volatile=yes</literal> as
+        container payload. The <option>overlay</option> option does not require any particular preparations
+        in the OS, but do note that <literal>overlayfs</literal> behaviour differs from regular file systems
+        in a number of ways, and hence compatibility is limited.</para>
+
+        <xi:include href="version-info.xml" xpointer="v216"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--root-hash=</option></term>
+
+        <listitem><para>Takes a data integrity (dm-verity) root hash specified in hexadecimal. This option enables data
+        integrity checks using dm-verity, if the used image contains the appropriate integrity data (see above). The
+        specified hash must match the root hash of integrity data, and is usually at least 256 bits (and hence 64
+        formatted hexadecimal characters) long (in case of SHA256 for example). If this option is not specified, but
+        the image file carries the <literal>user.verity.roothash</literal> extended file attribute (see <citerefentry
+        project='man-pages'><refentrytitle>xattr</refentrytitle><manvolnum>7</manvolnum></citerefentry>), then the root
+        hash is read from it, also as formatted hexadecimal characters. If the extended file attribute is not found (or
+        is not supported by the underlying file system), but a file with the <filename>.roothash</filename> suffix is
+        found next to the image file, bearing otherwise the same name (except if the image has the
+        <filename>.raw</filename> suffix, in which case the root hash file must not have it in its name), the root hash
+        is read from it and automatically used, also as formatted hexadecimal characters.</para>
+
+        <para>Note that this configures the root hash for the root file system. Disk images may also contain
+        separate file systems for the <filename>/usr/</filename> hierarchy, which may be Verity protected as
+        well. The root hash for this protection may be configured via the
+        <literal>user.verity.usrhash</literal> extended file attribute or via a <filename>.usrhash</filename>
+        file adjacent to the disk image, following the same format and logic as for the root hash for the
+        root file system described here. Note that there's currently no switch to configure the root hash for
+        the <filename>/usr/</filename> from the command line.</para>
+
+        <para>Also see the <varname>RootHash=</varname> option in
+        <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v233"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--root-hash-sig=</option></term>
+
+        <listitem><para>Takes a PKCS7 signature of the <option>--root-hash=</option> option.
+        The semantics are the same as for the <varname>RootHashSignature=</varname> option, see
+        <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--verity-data=</option></term>
+
+        <listitem><para>Takes the path to a data integrity (dm-verity) file. This option enables data integrity checks
+        using dm-verity, if a root-hash is passed and if the used image itself does not contain the integrity data.
+        The integrity data must be matched by the root hash. If this option is not specified, but a file with the
+        <filename>.verity</filename> suffix is found next to the image file, bearing otherwise the same name (except if
+        the image has the <filename>.raw</filename> suffix, in which case the verity data file must not have it in its name),
+        the verity data is read from it and automatically used.</para>
+
+        <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--pivot-root=</option></term>
+
+        <listitem><para>Pivot the specified directory to <filename>/</filename> inside the container, and either unmount the
+        container's old root, or pivot it to another specified directory. Takes one of: a path argument — in which case the
+        specified path will be pivoted to <filename>/</filename> and the old root will be unmounted; or a colon-separated pair
+        of new root path and pivot destination for the old root. The new root path will be pivoted to <filename>/</filename>,
+        and the old <filename>/</filename> will be pivoted to the other directory. Both paths must be absolute, and are resolved
+        in the container's file system namespace.</para>
+
+        <para>This is for containers which have several bootable directories in them; for example, several
+        <ulink url="https://ostree.readthedocs.io/en/latest/">OSTree</ulink> deployments. It emulates the
+        behavior of the boot loader and the initrd which normally select which directory to mount as the root
+        and start the container's PID 1 in.</para>
+
+        <xi:include href="version-info.xml" xpointer="v233"/></listitem>
+      </varlistentry>
+    </variablelist>
+
+    </refsect2><refsect2>
+    <title>Execution Options</title>
+
+    <variablelist>
+      <varlistentry>
+        <term><option>-a</option></term>
+        <term><option>--as-pid2</option></term>
+
+        <listitem><para>Invoke the shell or specified program as process ID (PID) 2 instead of PID 1 (init). By
+        default, if neither this option nor <option>--boot</option> is used, the selected program is run as the process
+        with PID 1, a mode only suitable for programs that are aware of the special semantics that the process with
+        PID 1 has on UNIX. For example, it needs to reap all processes reparented to it, and should implement
+        <command>sysvinit</command> compatible signal handling (specifically: it needs to reboot on SIGINT, reexecute
+        on SIGTERM, reload configuration on SIGHUP, and so on). With <option>--as-pid2</option> a minimal stub init
+        process is run as PID 1 and the selected program is executed as PID 2 (and hence does not need to implement any
+        special semantics). The stub init process will reap processes as necessary and react appropriately to
+        signals. It is recommended to use this mode to invoke arbitrary commands in containers, unless they have been
+        modified to run correctly as PID 1. Or in other words: this switch should be used for pretty much all commands,
+        except when the command refers to an init or shell implementation, as these are generally capable of running
+        correctly as PID 1. This option may not be combined with <option>--boot</option>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v229"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-b</option></term>
+        <term><option>--boot</option></term>
+
+        <listitem><para>Automatically search for an init program and invoke it as PID 1, instead of a shell or a user
+        supplied program. If this option is used, arguments specified on the command line are used as arguments for the
+        init program. This option may not be combined with <option>--as-pid2</option>.</para>
+
+        <para>The following table explains the different modes of invocation and relationship to
+        <option>--as-pid2</option> (see above):</para>
+
+        <table>
+          <title>Invocation Mode</title>
+          <tgroup cols='2' align='left' colsep='1' rowsep='1'>
+            <colspec colname="switch" />
+            <colspec colname="explanation" />
+            <thead>
+              <row>
+                <entry>Switch</entry>
+                <entry>Explanation</entry>
+              </row>
+            </thead>
+            <tbody>
+              <row>
+                <entry>Neither <option>--as-pid2</option> nor <option>--boot</option> specified</entry>
+                <entry>The passed parameters are interpreted as the command line, which is executed as PID 1 in the container.</entry>
+              </row>
+
+              <row>
+                <entry><option>--as-pid2</option> specified</entry>
+                <entry>The passed parameters are interpreted as the command line, which is executed as PID 2 in the container. A stub init process is run as PID 1.</entry>
+              </row>
+
+              <row>
+                <entry><option>--boot</option> specified</entry>
+                <entry>An init program is automatically searched for and run as PID 1 in the container. The passed parameters are used as invocation parameters for this process.</entry>
+              </row>
+
+            </tbody>
+          </tgroup>
+        </table>
+
+        <para>Note that <option>--boot</option> is the default mode of operation if the
+        <filename>systemd-nspawn@.service</filename> template unit file is used.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--chdir=</option></term>
+
+        <listitem><para>Change to the specified working directory before invoking the process in the container. Expects
+        an absolute path in the container's file system namespace.</para>
+
+        <xi:include href="version-info.xml" xpointer="v229"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-E <replaceable>NAME</replaceable>[=<replaceable>VALUE</replaceable>]</option></term>
+        <term><option>--setenv=<replaceable>NAME</replaceable>[=<replaceable>VALUE</replaceable>]</option></term>
+
+        <listitem><para>Specifies an environment variable to pass to the init process in the container. This
+        may be used to override the default variables or to set additional variables. It may be used more
+        than once to set multiple variables. When <literal>=</literal> and <replaceable>VALUE</replaceable>
+        are omitted, the value of the variable with the same name in the program environment will be used.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v209"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-u</option></term>
+        <term><option>--user=</option></term>
+
+        <listitem><para>After transitioning into the container, change to the specified user defined in the
+        container's user database. Like all other systemd-nspawn features, this is not a security feature and
+        provides protection against accidental destructive operations only.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--kill-signal=</option></term>
+
+        <listitem><para>Specify the process signal to send to the container's PID 1 when nspawn itself receives
+        <constant>SIGTERM</constant>, in order to trigger an orderly shutdown of the container. Defaults to
+        <constant>SIGRTMIN+3</constant> if <option>--boot</option> is used (on systemd-compatible init systems
+        <constant>SIGRTMIN+3</constant> triggers an orderly shutdown). If <option>--boot</option> is not used and this
+        option is not specified the container's processes are terminated abruptly via <constant>SIGKILL</constant>. For
+        a list of valid signals, see <citerefentry
+        project='man-pages'><refentrytitle>signal</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v220"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--notify-ready=</option></term>
+
+        <listitem><para>Configures support for notifications from the container's init process.
+        <option>--notify-ready=</option> takes a boolean (<option>no</option> and  <option>yes</option>).
+        With option <option>no</option> systemd-nspawn notifies systemd
+        with a <literal>READY=1</literal> message when the init process is created.
+        With option <option>yes</option> systemd-nspawn waits for the
+        <literal>READY=1</literal> message from the init process in the container
+        before sending its own to systemd. For more details about notifications
+        see <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v231"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--suppress-sync=</option></term>
+
+        <listitem><para>Expects a boolean argument. If true, turns off any form of on-disk file system
+        synchronization for the container payload. This means all system calls such as <citerefentry
+        project='man-pages'><refentrytitle>sync</refentrytitle><manvolnum>2</manvolnum></citerefentry>,
+        <function>fsync()</function>, <function>syncfs()</function>, … will execute no operation, and the
+        <constant>O_SYNC</constant>/<constant>O_DSYNC</constant> flags to <citerefentry
+        project='man-pages'><refentrytitle>open</refentrytitle><manvolnum>2</manvolnum></citerefentry> and
+        related calls will be made unavailable. This is potentially dangerous, as assumed data integrity
+        guarantees to the container payload are not actually enforced (i.e. data assumed to have been written
+        to disk might be lost if the system is shut down abnormally). However, this can dramatically improve
+        container runtime performance – as long as these guarantees are not required or desirable, for
+        example because any data written by the container is of temporary, redundant nature, or just an
+        intermediary artifact that will be further processed and finalized by a later step in a
+        pipeline. Defaults to false.</para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+    </variablelist>
+
+    </refsect2><refsect2>
+    <title>System Identity Options</title>
+
+    <variablelist>
+      <varlistentry>
+        <term><option>-M</option></term>
+        <term><option>--machine=</option></term>
+
+        <listitem><para>Sets the machine name for this container. This
+        name may be used to identify this container during its runtime
+        (for example in tools like
+        <citerefentry><refentrytitle>machinectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+        and similar), and is used to initialize the container's
+        hostname (which the container can choose to override,
+        however). If not specified, the last component of the root
+        directory path of the container is used, possibly suffixed
+        with a random identifier in case <option>--ephemeral</option>
+        mode is selected. If the root directory selected is the host's
+        root directory the host's hostname is used as default
+        instead.</para>
+
+        <xi:include href="version-info.xml" xpointer="v202"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--hostname=</option></term>
+
+        <listitem><para>Controls the hostname to set within the container, if different from the machine name. Expects
+        a valid hostname as argument. If this option is used, the kernel hostname of the container will be set to this
+        value, otherwise it will be initialized to the machine name as controlled by the <option>--machine=</option>
+        option described above. The machine name is used for various aspect of identification of the container from the
+        outside, the kernel hostname configurable with this option is useful for the container to identify itself from
+        the inside. It is usually a good idea to keep both forms of identification synchronized, in order to avoid
+        confusion. It is hence recommended to avoid usage of this option, and use <option>--machine=</option>
+        exclusively. Note that regardless whether the container's hostname is initialized from the name set with
+        <option>--hostname=</option> or the one set with <option>--machine=</option>, the container can later override
+        its kernel hostname freely on its own as well.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--uuid=</option></term>
+
+        <listitem><para>Set the specified UUID for the container. The
+        init system will initialize
+        <filename>/etc/machine-id</filename> from this if this file is
+        not set yet. Note that this option takes effect only if
+        <filename>/etc/machine-id</filename> in the container is
+        unpopulated.</para></listitem>
+      </varlistentry>
+    </variablelist>
+
+    </refsect2><refsect2>
+    <title>Property Options</title>
+
+    <variablelist>
+      <varlistentry>
+        <term><option>-S</option></term>
+        <term><option>--slice=</option></term>
+
+        <listitem><para>Make the container part of the specified slice, instead of the default
+        <filename>machine.slice</filename>. This applies only if the machine is run in its own scope unit, i.e. if
+        <option>--keep-unit</option> isn't used.</para>
+
+        <xi:include href="version-info.xml" xpointer="v206"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--property=</option></term>
+
+        <listitem><para>Set a unit property on the scope unit to register for the machine. This applies only if the
+        machine is run in its own scope unit, i.e. if <option>--keep-unit</option> isn't used. Takes unit property
+        assignments in the same format as <command>systemctl set-property</command>. This is useful to set memory
+        limits and similar for the container.</para>
+
+        <xi:include href="version-info.xml" xpointer="v220"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--register=</option></term>
+
+        <listitem><para>Controls whether the container is registered with
+        <citerefentry><refentrytitle>systemd-machined</refentrytitle><manvolnum>8</manvolnum></citerefentry>.  Takes a
+        boolean argument, which defaults to <literal>yes</literal>.  This option should be enabled when the container
+        runs a full Operating System (more specifically: a system and service manager as PID 1), and is useful to
+        ensure that the container is accessible via
+        <citerefentry><refentrytitle>machinectl</refentrytitle><manvolnum>1</manvolnum></citerefentry> and shown by
+        tools such as <citerefentry
+        project='man-pages'><refentrytitle>ps</refentrytitle><manvolnum>1</manvolnum></citerefentry>.  If the container
+        does not run a service manager, it is recommended to set this option to
+        <literal>no</literal>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v209"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--keep-unit</option></term>
+
+        <listitem><para>Instead of creating a transient scope unit to run the container in, simply use the service or
+        scope unit <command>systemd-nspawn</command> has been invoked in. If <option>--register=yes</option> is set
+        this unit is registered with
+        <citerefentry><refentrytitle>systemd-machined</refentrytitle><manvolnum>8</manvolnum></citerefentry>. This
+        switch should be used if <command>systemd-nspawn</command> is invoked from within a service unit, and the
+        service unit's sole purpose is to run a single <command>systemd-nspawn</command> container. This option is not
+        available if run from a user session.</para>
+        <para>Note that passing <option>--keep-unit</option> disables the effect of <option>--slice=</option> and
+        <option>--property=</option>. Use <option>--keep-unit</option> and <option>--register=no</option> in
+        combination to disable any kind of unit allocation or registration with
+        <command>systemd-machined</command>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v209"/></listitem>
+      </varlistentry>
+    </variablelist>
+
+    </refsect2><refsect2>
+    <title>User Namespacing Options</title>
+
+    <variablelist>
+      <varlistentry>
+        <term><option>--private-users=</option></term>
+
+        <listitem><para>Controls user namespacing. If enabled, the container will run with its own private set of UNIX
+        user and group ids (UIDs and GIDs). This involves mapping the private UIDs/GIDs used in the container (starting
+        with the container's root user 0 and up) to a range of UIDs/GIDs on the host that are not used for other
+        purposes (usually in the range beyond the host's UID/GID 65536). The parameter may be specified as follows:</para>
+
+        <orderedlist>
+          <listitem><para>If one or two colon-separated numbers are specified, user namespacing is turned on. The first
+          parameter specifies the first host UID/GID to assign to the container, the second parameter specifies the
+          number of host UIDs/GIDs to assign to the container. If the second parameter is omitted, 65536 UIDs/GIDs are
+          assigned.</para></listitem>
+
+          <listitem><para>If the parameter is <literal>yes</literal>, user namespacing is turned on. The
+          UID/GID range to use is determined automatically from the file ownership of the root directory of
+          the container's directory tree. To use this option, make sure to prepare the directory tree in
+          advance, and ensure that all files and directories in it are owned by UIDs/GIDs in the range you'd
+          like to use. Also, make sure that used file ACLs exclusively reference UIDs/GIDs in the appropriate
+          range. In this mode, the number of UIDs/GIDs assigned to the container is 65536, and the owner
+          UID/GID of the root directory must be a multiple of 65536.</para></listitem>
+
+          <listitem><para>If the parameter is <literal>no</literal>, user namespacing is turned off. This is
+          the default.</para>
+          </listitem>
+
+          <listitem><para>If the parameter is <literal>identity</literal>, user namespacing is employed with
+          an identity mapping for the first 65536 UIDs/GIDs. This is mostly equivalent to
+          <option>--private-users=0:65536</option>. While it does not provide UID/GID isolation, since all
+          host and container UIDs/GIDs are chosen identically it does provide process capability isolation,
+          and hence is often a good choice if proper user namespacing with distinct UID maps is not
+          appropriate.</para></listitem>
+
+          <listitem><para>The special value <literal>pick</literal> turns on user namespacing. In this case
+          the UID/GID range is automatically chosen. As first step, the file owner UID/GID of the root
+          directory of the container's directory tree is read, and it is checked that no other container is
+          currently using it. If this check is successful, the UID/GID range determined this way is used,
+          similarly to the behavior if <literal>yes</literal> is specified. If the check is not successful
+          (and thus the UID/GID range indicated in the root directory's file owner is already used elsewhere)
+          a new – currently unused – UID/GID range of 65536 UIDs/GIDs is randomly chosen between the host
+          UID/GIDs of 524288 and 1878982656, always starting at a multiple of 65536, and, if possible,
+          consistently hashed from the machine name. This setting implies
+          <option>--private-users-ownership=auto</option> (see below), which possibly has the effect that the
+          files and directories in the container's directory tree will be owned by the appropriate users of
+          the range picked. Using this option makes user namespace behavior fully automatic. Note that the
+          first invocation of a previously unused container image might result in picking a new UID/GID range
+          for it, and thus in the (possibly expensive) file ownership adjustment operation. However,
+          subsequent invocations of the container will be cheap (unless of course the picked UID/GID range is
+          assigned to a different use by then).</para></listitem>
+        </orderedlist>
+
+        <para>It is recommended to assign at least 65536 UIDs/GIDs to each container, so that the usable UID/GID range in the
+        container covers 16 bit. For best security, do not assign overlapping UID/GID ranges to multiple containers. It is
+        hence a good idea to use the upper 16 bit of the host 32-bit UIDs/GIDs as container identifier, while the lower 16
+        bit encode the container UID/GID used. This is in fact the behavior enforced by the
+        <option>--private-users=pick</option> option.</para>
+
+        <para>When user namespaces are used, the GID range assigned to each container is always chosen identical to the
+        UID range.</para>
+
+        <para>In most cases, using <option>--private-users=pick</option> is the recommended option as it enhances
+        container security massively and operates fully automatically in most cases.</para>
+
+        <para>Note that the picked UID/GID range is not written to <filename>/etc/passwd</filename> or
+        <filename>/etc/group</filename>. In fact, the allocation of the range is not stored persistently anywhere,
+        except in the file ownership of the files and directories of the container.</para>
+
+        <para>Note that when user namespacing is used file ownership on disk reflects this, and all of the container's
+        files and directories are owned by the container's effective user and group IDs. This means that copying files
+        from and to the container image requires correction of the numeric UID/GID values, according to the UID/GID
+        shift applied.</para>
+
+        <xi:include href="version-info.xml" xpointer="v220"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--private-users-ownership=</option></term>
+
+        <listitem><para>Controls how to adjust the container image's UIDs and GIDs to match the UID/GID range
+        chosen with <option>--private-users=</option>, see above. Takes one of <literal>off</literal> (to
+        leave the image as is), <literal>chown</literal> (to recursively <function>chown()</function> the
+        container's directory tree as needed), <literal>map</literal> (in order to use transparent ID mapping
+        mounts) or <literal>auto</literal> for automatically using <literal>map</literal> where available and
+        <literal>chown</literal> where not.</para>
+
+        <para>If <literal>chown</literal> is selected, all files and directories in the container's directory
+        tree will be adjusted so that they are owned by the appropriate UIDs/GIDs selected for the container
+        (see above).  This operation is potentially expensive, as it involves iterating through the full
+        directory tree of the container. Besides actual file ownership, file ACLs are adjusted as
+        well.</para>
+
+        <para>Typically <literal>map</literal> is the best choice, since it transparently maps UIDs/GIDs in
+        memory as needed without modifying the image, and without requiring an expensive recursive adjustment
+        operation. However, it is not available for all file systems, currently.</para>
+
+        <para>The <option>--private-users-ownership=auto</option> option is implied if
+        <option>--private-users=pick</option> is used. This option has no effect if user namespacing is not
+        used.</para>
+
+        <xi:include href="version-info.xml" xpointer="v230"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-U</option></term>
+
+        <listitem><para>If the kernel supports the user namespaces feature, equivalent to
+        <option>--private-users=pick --private-users-ownership=auto</option>, otherwise equivalent to
+        <option>--private-users=no</option>.</para>
+
+        <para>Note that <option>-U</option> is the default if the
+        <filename>systemd-nspawn@.service</filename> template unit file is used.</para>
+
+        <para>Note: it is possible to undo the effect of <option>--private-users-ownership=chown</option> (or
+        <option>-U</option>) on the file system by redoing the operation with the first UID of 0:</para>
+
+        <programlisting>systemd-nspawn … --private-users=0 --private-users-ownership=chown</programlisting>
+
+        <xi:include href="version-info.xml" xpointer="v230"/>
+        </listitem>
+      </varlistentry>
+
+    </variablelist>
+
+    </refsect2><refsect2>
+    <title>Networking Options</title>
+
+    <variablelist>
+
+      <varlistentry>
+        <term><option>--private-network</option></term>
+
+        <listitem><para>Disconnect networking of the container from
+        the host. This makes all network interfaces unavailable in the
+        container, with the exception of the loopback device and those
+        specified with <option>--network-interface=</option> and
+        configured with <option>--network-veth</option>. If this
+        option is specified, the <constant>CAP_NET_ADMIN</constant> capability will be
+        added to the set of capabilities the container retains. The
+        latter may be disabled by using <option>--drop-capability=</option>.
+        If this option is not specified (or implied by one of the options
+        listed below), the container will have full access to the host network.
+        </para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--network-interface=</option></term>
+
+        <listitem><para>Assign the specified network interface to the container. Either takes a single
+        interface name, referencing the name on the host, or a colon-separated pair of interfaces, in which
+        case the first one references the name on the host, and the second one the name in the container.
+        When the container terminates, the interface is moved back to the calling namespace and renamed to
+        its original name.  Note that <option>--network-interface=</option> implies
+        <option>--private-network</option>. This option may be used more than once to add multiple network
+        interfaces to the container.</para>
+
+        <para>Note that any network interface specified this way must already exist at the time the container
+        is started. If the container shall be started automatically at boot via a
+        <filename>systemd-nspawn@.service</filename> unit file instance, it might hence make sense to add a
+        unit file drop-in to the service instance
+        (e.g. <filename>/etc/systemd/system/systemd-nspawn@foobar.service.d/50-network.conf</filename>) with
+        contents like the following:</para>
+
+        <programlisting>[Unit]
+Wants=sys-subsystem-net-devices-ens1.device
+After=sys-subsystem-net-devices-ens1.device</programlisting>
+
+        <para>This will make sure that activation of the container service will be delayed until the
+        <literal>ens1</literal> network interface has shown up. This is required since hardware probing is
+        fully asynchronous, and network interfaces might be discovered only later during the boot process,
+        after the container would normally be started without these explicit dependencies.</para>
+
+        <xi:include href="version-info.xml" xpointer="v209"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--network-macvlan=</option></term>
+
+        <listitem><para>Create a <literal>macvlan</literal> interface of the specified Ethernet network
+        interface and add it to the container. Either takes a single interface name, referencing the name
+        on the host, or a colon-separated pair of interfaces, in which case the first one references the name
+        on the host, and the second one the name in the container. A <literal>macvlan</literal> interface is
+        a virtual interface that adds a second MAC address to an existing physical Ethernet link. If the
+        container interface name is not defined, the interface in the container will be named after the
+        interface on the host, prefixed with <literal>mv-</literal>. Note that
+        <option>--network-macvlan=</option> implies <option>--private-network</option>. This option may be
+        used more than once to add multiple network interfaces to the container.</para>
+
+        <para>As with <option>--network-interface=</option>, the underlying Ethernet network interface must
+        already exist at the time the container is started, and thus similar unit file drop-ins as described
+        above might be useful.</para>
+
+        <xi:include href="version-info.xml" xpointer="v211"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--network-ipvlan=</option></term>
+
+        <listitem><para>Create an <literal>ipvlan</literal> interface of the specified Ethernet network
+        interface and add it to the container. Either takes a single interface name, referencing the name on
+        the host, or a colon-separated pair of interfaces, in which case the first one references the name
+        on the host, and the second one the name in the container. An <literal>ipvlan</literal> interface is
+        a virtual interface,
+        similar to a <literal>macvlan</literal> interface, which uses the same MAC address as the underlying
+        interface. If the container interface name is not defined, the interface in the container will be
+        named after the interface on the host, prefixed
+        with <literal>iv-</literal>.  Note that <option>--network-ipvlan=</option> implies
+        <option>--private-network</option>. This option may be used more than once to add multiple network
+        interfaces to the container.</para>
+
+        <para>As with <option>--network-interface=</option>, the underlying Ethernet network interface must
+        already exist at the time the container is started, and thus similar unit file drop-ins as described
+        above might be useful.</para>
+
+        <xi:include href="version-info.xml" xpointer="v219"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-n</option></term>
+        <term><option>--network-veth</option></term>
+
+        <listitem><para>Create a virtual Ethernet link (<literal>veth</literal>) between host and container. The host
+        side of the Ethernet link will be available as a network interface named after the container's name (as
+        specified with <option>--machine=</option>), prefixed with <literal>ve-</literal>. The container side of the
+        Ethernet link will be named <literal>host0</literal>. The <option>--network-veth</option> option implies
+        <option>--private-network</option>.</para>
+
+        <para>Note that
+        <citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        includes by default a network file <filename>/usr/lib/systemd/network/80-container-ve.network</filename>
+        matching the host-side interfaces created this way, which contains settings to enable automatic address
+        provisioning on the created virtual link via DHCP, as well as automatic IP routing onto the host's external
+        network interfaces. It also contains <filename>/usr/lib/systemd/network/80-container-host0.network</filename>
+        matching the container-side interface created this way, containing settings to enable client side address
+        assignment via DHCP. In case <filename>systemd-networkd</filename> is running on both the host and inside the
+        container, automatic IP communication from the container to the host is thus available, with further
+        connectivity to the external network.</para>
+
+        <para>Note that <option>--network-veth</option> is the default if the
+        <filename>systemd-nspawn@.service</filename> template unit file is used.</para>
+
+        <para>Note that on Linux network interface names may have a length of 15 characters at maximum, while
+        container names may have a length up to 64 characters. As this option derives the host-side interface
+        name from the container name the name is possibly truncated. Thus, care needs to be taken to ensure
+        that interface names remain unique in this case, or even better container names are generally not
+        chosen longer than 12 characters, to avoid the truncation. If the name is truncated,
+        <command>systemd-nspawn</command> will automatically append a 4-digit hash value to the name to
+        reduce the chance of collisions. However, the hash algorithm is not collision-free. (See
+        <citerefentry><refentrytitle>systemd.net-naming-scheme</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+        for details on older naming algorithms for this interface). Alternatively, the
+        <option>--network-veth-extra=</option> option may be used, which allows free configuration of the
+        host-side interface name independently of the container name — but might require a bit more
+        additional configuration in case bridging in a fashion similar to <option>--network-bridge=</option>
+        is desired.</para>
+
+        <xi:include href="version-info.xml" xpointer="v209"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--network-veth-extra=</option></term>
+
+        <listitem><para>Adds an additional virtual Ethernet link
+        between host and container. Takes a colon-separated pair of
+        host interface name and container interface name. The latter
+        may be omitted in which case the container and host sides will
+        be assigned the same name. This switch is independent of
+        <option>--network-veth</option>, and — in contrast — may be
+        used multiple times, and allows configuration of the network
+        interface names. Note that <option>--network-bridge=</option>
+        has no effect on interfaces created with
+        <option>--network-veth-extra=</option>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v228"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--network-bridge=</option></term>
+
+        <listitem><para>Adds the host side of the Ethernet link created with <option>--network-veth</option>
+        to the specified Ethernet bridge interface. Expects a valid network interface name of a bridge device
+        as argument. Note that <option>--network-bridge=</option> implies <option>--network-veth</option>. If
+        this option is used, the host side of the Ethernet link will use the <literal>vb-</literal> prefix
+        instead of <literal>ve-</literal>. Regardless of the used naming prefix the same network interface
+        name length limits imposed by Linux apply, along with the complications this creates (for details see
+        above).</para>
+
+        <para>As with <option>--network-interface=</option>, the underlying bridge network interface must
+        already exist at the time the container is started, and thus similar unit file drop-ins as described
+        above might be useful.</para>
+
+        <xi:include href="version-info.xml" xpointer="v209"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--network-zone=</option></term>
+
+        <listitem><para>Creates a virtual Ethernet link (<literal>veth</literal>) to the container and adds it to an
+        automatically managed Ethernet bridge interface. The bridge interface is named after the passed argument,
+        prefixed with <literal>vz-</literal>. The bridge interface is automatically created when the first container
+        configured for its name is started, and is automatically removed when the last container configured for its
+        name exits. Hence, each bridge interface configured this way exists only as long as there's at least one
+        container referencing it running. This option is very similar to <option>--network-bridge=</option>, besides
+        this automatic creation/removal of the bridge device.</para>
+
+        <para>This setting makes it easy to place multiple related containers on a common, virtual Ethernet-based
+        broadcast domain, here called a "zone". Each container may only be part of one zone, but each zone may contain
+        any number of containers. Each zone is referenced by its name. Names may be chosen freely (as long as they form
+        valid network interface names when prefixed with <literal>vz-</literal>), and it is sufficient to pass the same
+        name to the <option>--network-zone=</option> switch of the various concurrently running containers to join
+        them in one zone.</para>
+
+        <para>Note that
+        <citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        includes by default a network file <filename>/usr/lib/systemd/network/80-container-vz.network</filename>
+        matching the bridge interfaces created this way, which contains settings to enable automatic address
+        provisioning on the created virtual network via DHCP, as well as automatic IP routing onto the host's external
+        network interfaces. Using <option>--network-zone=</option> is hence in most cases fully automatic and
+        sufficient to connect multiple local containers in a joined broadcast domain to the host, with further
+        connectivity to the external network.</para>
+
+        <xi:include href="version-info.xml" xpointer="v230"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--network-namespace-path=</option></term>
+
+        <listitem><para>Takes the path to a file representing a kernel
+        network namespace that the container shall run in. The specified path
+        should refer to a (possibly bind-mounted) network namespace file, as
+        exposed by the kernel below <filename>/proc/$PID/ns/net</filename>.
+        This makes the container enter the given network namespace. One of the
+        typical use cases is to give a network namespace under
+        <filename>/run/netns</filename> created by <citerefentry
+        project='man-pages'><refentrytitle>ip-netns</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+        for example, <option>--network-namespace-path=/run/netns/foo</option>.
+        Note that this option cannot be used together with other
+        network-related options, such as <option>--private-network</option>
+        or <option>--network-interface=</option>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v236"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-p</option></term>
+        <term><option>--port=</option></term>
+
+        <listitem><para>If private networking is enabled, maps an IP
+        port on the host onto an IP port on the container. Takes a
+        protocol specifier (either <literal>tcp</literal> or
+        <literal>udp</literal>), separated by a colon from a host port
+        number in the range 1 to 65535, separated by a colon from a
+        container port number in the range from 1 to 65535. The
+        protocol specifier and its separating colon may be omitted, in
+        which case <literal>tcp</literal> is assumed. The container
+        port number and its colon may be omitted, in which case the
+        same port as the host port is implied. This option is only
+        supported if private networking is used, such as with
+        <option>--network-veth</option>, <option>--network-zone=</option>
+        <option>--network-bridge=</option>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v219"/></listitem>
+      </varlistentry>
+    </variablelist>
+
+    </refsect2><refsect2>
+    <title>Security Options</title>
+
+    <variablelist>
+      <varlistentry>
+        <term><option>--capability=</option></term>
+
+        <listitem><para>List one or more additional capabilities to grant the container.  Takes a
+        comma-separated list of capability names, see <citerefentry
+        project='man-pages'><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+        for more information. Note that the following capabilities will be granted in any way:
+        <constant>CAP_AUDIT_CONTROL</constant>, <constant>CAP_AUDIT_WRITE</constant>,
+        <constant>CAP_CHOWN</constant>, <constant>CAP_DAC_OVERRIDE</constant>,
+        <constant>CAP_DAC_READ_SEARCH</constant>, <constant>CAP_FOWNER</constant>,
+        <constant>CAP_FSETID</constant>, <constant>CAP_IPC_OWNER</constant>, <constant>CAP_KILL</constant>,
+        <constant>CAP_LEASE</constant>, <constant>CAP_LINUX_IMMUTABLE</constant>,
+        <constant>CAP_MKNOD</constant>, <constant>CAP_NET_BIND_SERVICE</constant>,
+        <constant>CAP_NET_BROADCAST</constant>, <constant>CAP_NET_RAW</constant>,
+        <constant>CAP_SETFCAP</constant>, <constant>CAP_SETGID</constant>, <constant>CAP_SETPCAP</constant>,
+        <constant>CAP_SETUID</constant>, <constant>CAP_SYS_ADMIN</constant>,
+        <constant>CAP_SYS_BOOT</constant>, <constant>CAP_SYS_CHROOT</constant>,
+        <constant>CAP_SYS_NICE</constant>, <constant>CAP_SYS_PTRACE</constant>,
+        <constant>CAP_SYS_RESOURCE</constant>, <constant>CAP_SYS_TTY_CONFIG</constant>. Also
+        <constant>CAP_NET_ADMIN</constant> is retained if <option>--private-network</option> is specified.
+        If the special value <literal>all</literal> is passed, all capabilities are retained.</para>
+
+        <para>If the special value of <literal>help</literal> is passed, the program will print known
+        capability names and exit.</para>
+
+        <para>This option sets the bounding set of capabilities which
+        also limits the ambient capabilities as given with the
+        <option>--ambient-capability=</option>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v186"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--drop-capability=</option></term>
+
+        <listitem><para>Specify one or more additional capabilities to
+        drop for the container. This allows running the container with
+        fewer capabilities than the default (see
+        above).</para>
+
+        <para>If the special value of <literal>help</literal> is passed, the program will print known
+        capability names and exit.</para>
+
+        <para>This option sets the bounding set of capabilities which
+        also limits the ambient capabilities as given with the
+        <option>--ambient-capability=</option>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v209"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--ambient-capability=</option></term>
+
+        <listitem><para>Specify one or more additional capabilities to
+        pass in the inheritable and ambient set to the program started
+        within the container. The value <literal>all</literal> is not
+        supported for this setting.</para>
+
+        <para>All capabilities specified here must be in the set
+        allowed with the <option>--capability=</option> and
+        <option>--drop-capability=</option> options. Otherwise, an
+        error message will be shown.</para>
+
+        <para>This option cannot be combined with the boot mode of the
+        container (as requested via <option>--boot</option>).</para>
+
+        <para>If the special value of <literal>help</literal> is
+        passed, the program will print known capability names and
+        exit.</para>
+
+        <xi:include href="version-info.xml" xpointer="v248"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--no-new-privileges=</option></term>
+
+        <listitem><para>Takes a boolean argument. Specifies the value of the
+        <constant>PR_SET_NO_NEW_PRIVS</constant> flag for the container payload. Defaults to off. When turned
+        on the payload code of the container cannot acquire new privileges, i.e. the "setuid" file bit as
+        well as file system capabilities will not have an effect anymore. See <citerefentry
+        project='man-pages'><refentrytitle>prctl</refentrytitle><manvolnum>2</manvolnum></citerefentry> for
+        details about this flag. </para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--system-call-filter=</option></term> <listitem><para>Alter the system call filter
+        applied to containers. Takes a space-separated list of system call names or group names (the latter
+        prefixed with <literal>@</literal>, as listed by the <command>syscall-filter</command> command of
+        <citerefentry><refentrytitle>systemd-analyze</refentrytitle><manvolnum>1</manvolnum></citerefentry>). Passed
+        system calls will be permitted. The list may optionally be prefixed by <literal>~</literal>, in which
+        case all listed system calls are prohibited. If this command line option is used multiple times the
+        configured lists are combined. If both a positive and a negative list (that is one system call list
+        without and one with the <literal>~</literal> prefix) are configured, the negative list takes
+        precedence over the positive list. Note that <command>systemd-nspawn</command> always implements a
+        system call allow list (as opposed to a deny list!), and this command line option hence adds or
+        removes entries from the default allow list, depending on the <literal>~</literal> prefix. Note that
+        the applied system call filter is also altered implicitly if additional capabilities are passed using
+        the <command>--capabilities=</command>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v235"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-Z</option></term>
+        <term><option>--selinux-context=</option></term>
+
+        <listitem><para>Sets the SELinux security context to be used
+        to label processes in the container.</para>
+
+        <xi:include href="version-info.xml" xpointer="v209"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-L</option></term>
+        <term><option>--selinux-apifs-context=</option></term>
+
+        <listitem><para>Sets the SELinux security context to be used
+        to label files in the virtual API file systems in the
+        container.</para>
+
+        <xi:include href="version-info.xml" xpointer="v209"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+
+    </refsect2><refsect2>
+    <title>Resource Options</title>
+
+    <variablelist>
+
+      <varlistentry>
+        <term><option>--rlimit=</option></term>
+
+        <listitem><para>Sets the specified POSIX resource limit for the container payload. Expects an assignment of the
+        form
+        <literal><replaceable>LIMIT</replaceable>=<replaceable>SOFT</replaceable>:<replaceable>HARD</replaceable></literal>
+        or <literal><replaceable>LIMIT</replaceable>=<replaceable>VALUE</replaceable></literal>, where
+        <replaceable>LIMIT</replaceable> should refer to a resource limit type, such as
+        <constant>RLIMIT_NOFILE</constant> or <constant>RLIMIT_NICE</constant>. The <replaceable>SOFT</replaceable> and
+        <replaceable>HARD</replaceable> fields should refer to the numeric soft and hard resource limit values. If the
+        second form is used, <replaceable>VALUE</replaceable> may specify a value that is used both as soft and hard
+        limit. In place of a numeric value the special string <literal>infinity</literal> may be used to turn off
+        resource limiting for the specific type of resource. This command line option may be used multiple times to
+        control limits on multiple limit types. If used multiple times for the same limit type, the last use
+        wins. For details about resource limits see <citerefentry
+        project='man-pages'><refentrytitle>setrlimit</refentrytitle><manvolnum>2</manvolnum></citerefentry>. By default
+        resource limits for the container's init process (PID 1) are set to the same values the Linux kernel originally
+        passed to the host init system. Note that some resource limits are enforced on resources counted per user, in
+        particular <constant>RLIMIT_NPROC</constant>. This means that unless user namespacing is deployed
+        (i.e. <option>--private-users=</option> is used, see above), any limits set will be applied to the resource
+        usage of the same user on all local containers as well as the host. This means particular care needs to be
+        taken with these limits as they might be triggered by possibly less trusted code. Example:
+        <literal>--rlimit=RLIMIT_NOFILE=8192:16384</literal>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--oom-score-adjust=</option></term>
+
+        <listitem><para>Changes the OOM ("Out Of Memory") score adjustment value for the container payload. This controls
+        <filename>/proc/self/oom_score_adj</filename> which influences the preference with which this container is
+        terminated when memory becomes scarce. For details see <citerefentry
+        project='man-pages'><refentrytitle>proc</refentrytitle><manvolnum>5</manvolnum></citerefentry>. Takes an
+        integer in the range -1000…1000.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--cpu-affinity=</option></term>
+
+        <listitem><para>Controls the CPU affinity of the container payload. Takes a comma separated list of CPU numbers
+        or number ranges (the latter's start and end value separated by dashes). See <citerefentry
+        project='man-pages'><refentrytitle>sched_setaffinity</refentrytitle><manvolnum>2</manvolnum></citerefentry> for
+        details.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--personality=</option></term>
+
+        <listitem><para>Control the architecture ("personality")
+        reported by
+        <citerefentry project='man-pages'><refentrytitle>uname</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+        in the container. Currently, only <literal>x86</literal> and
+        <literal>x86-64</literal> are supported. This is useful when
+        running a 32-bit container on a 64-bit host. If this setting
+        is not used, the personality reported in the container is the
+        same as the one reported on the host.</para>
+
+        <xi:include href="version-info.xml" xpointer="v209"/></listitem>
+      </varlistentry>
+    </variablelist>
+
+    </refsect2><refsect2>
+    <title>Integration Options</title>
+
+    <variablelist>
+      <varlistentry>
+        <term><option>--resolv-conf=</option></term>
+
+        <listitem><para>Configures how <filename>/etc/resolv.conf</filename> inside of the container shall be
+        handled (i.e. DNS configuration synchronization from host to container). Takes one of
+        <literal>off</literal>, <literal>copy-host</literal>, <literal>copy-static</literal>,
+        <literal>copy-uplink</literal>, <literal>copy-stub</literal>, <literal>replace-host</literal>,
+        <literal>replace-static</literal>, <literal>replace-uplink</literal>,
+        <literal>replace-stub</literal>, <literal>bind-host</literal>, <literal>bind-static</literal>,
+        <literal>bind-uplink</literal>, <literal>bind-stub</literal>, <literal>delete</literal> or
+        <literal>auto</literal>.</para>
+
+        <para>If set to <literal>off</literal> the <filename>/etc/resolv.conf</filename> file in the
+        container is left as it is included in the image, and neither modified nor bind mounted over.</para>
+
+        <para>If set to <literal>copy-host</literal>, the <filename>/etc/resolv.conf</filename> file from the
+        host is copied into the container, unless the file exists already and is not a regular file (e.g. a
+        symlink). Similarly, if <literal>replace-host</literal> is used the file is copied, replacing any
+        existing inode, including symlinks. Similarly, if <literal>bind-host</literal> is used, the file is
+        bind mounted from the host into the container.</para>
+
+        <para>If set to <literal>copy-static</literal>, <literal>replace-static</literal> or
+        <literal>bind-static</literal> the static <filename>resolv.conf</filename> file supplied with
+        <citerefentry><refentrytitle>systemd-resolved.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        (specifically: <filename>/usr/lib/systemd/resolv.conf</filename>) is copied or bind mounted into the
+        container.</para>
+
+        <para>If set to <literal>copy-uplink</literal>, <literal>replace-uplink</literal> or
+        <literal>bind-uplink</literal> the uplink <filename>resolv.conf</filename> file managed by
+        <filename>systemd-resolved.service</filename> (specifically:
+        <filename>/run/systemd/resolve/resolv.conf</filename>) is copied or bind mounted into the
+        container.</para>
+
+        <para>If set to <literal>copy-stub</literal>, <literal>replace-stub</literal> or
+        <literal>bind-stub</literal> the stub <filename>resolv.conf</filename> file managed by
+        <filename>systemd-resolved.service</filename> (specifically:
+        <filename>/run/systemd/resolve/stub-resolv.conf</filename>) is copied or bind mounted into the
+        container.</para>
+
+        <para>If set to <literal>delete</literal> the <filename>/etc/resolv.conf</filename> file in the
+        container is deleted if it exists.</para>
+
+        <para>Finally, if set to <literal>auto</literal> the file is left as it is if private networking is
+        turned on (see <option>--private-network</option>). Otherwise, if
+        <filename>systemd-resolved.service</filename> is running its stub <filename>resolv.conf</filename>
+        file is used, and if not the host's <filename>/etc/resolv.conf</filename> file. In the latter cases
+        the file is copied if the image is writable, and bind mounted otherwise.</para>
+
+        <para>It's recommended to use <literal>copy-…</literal> or <literal>replace-…</literal> if the
+        container shall be able to make changes to the DNS configuration on its own, deviating from the
+        host's settings. Otherwise <literal>bind</literal> is preferable, as it means direct changes to
+        <filename>/etc/resolv.conf</filename> in the container are not allowed, as it is a read-only bind
+        mount (but note that if the container has enough privileges, it might simply go ahead and unmount the
+        bind mount anyway). Note that both if the file is bind mounted and if it is copied no further
+        propagation of configuration is generally done after the one-time early initialization (this is
+        because the file is usually updated through copying and renaming). Defaults to
+        <literal>auto</literal>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--timezone=</option></term>
+
+        <listitem><para>Configures how <filename>/etc/localtime</filename> inside of the container
+        (i.e. local timezone synchronization from host to container) shall be handled. Takes one of
+        <literal>off</literal>, <literal>copy</literal>, <literal>bind</literal>, <literal>symlink</literal>,
+        <literal>delete</literal> or <literal>auto</literal>. If set to <literal>off</literal> the
+        <filename>/etc/localtime</filename> file in the container is left as it is included in the image, and
+        neither modified nor bind mounted over. If set to <literal>copy</literal> the
+        <filename>/etc/localtime</filename> file of the host is copied into the container. Similarly, if
+        <literal>bind</literal> is used, the file is bind mounted from the host into the container. If set to
+        <literal>symlink</literal>, a symlink is created pointing from <filename>/etc/localtime</filename> in
+        the container to the timezone file in the container that matches the timezone setting on the host. If
+        set to <literal>delete</literal>, the file in the container is deleted, should it exist. If set to
+        <literal>auto</literal> and the <filename>/etc/localtime</filename> file of the host is a symlink,
+        then <literal>symlink</literal> mode is used, and <literal>copy</literal> otherwise, except if the
+        image is read-only in which case <literal>bind</literal> is used instead. Defaults to
+        <literal>auto</literal>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--link-journal=</option></term>
+
+        <listitem><para>Control whether the container's journal shall
+        be made visible to the host system. If enabled, allows viewing
+        the container's journal files from the host (but not vice
+        versa). Takes one of <literal>no</literal>,
+        <literal>host</literal>, <literal>try-host</literal>,
+        <literal>guest</literal>, <literal>try-guest</literal>,
+        <literal>auto</literal>. If <literal>no</literal>, the journal
+        is not linked. If <literal>host</literal>, the journal files
+        are stored on the host file system (beneath
+        <filename>/var/log/journal/<replaceable>machine-id</replaceable></filename>)
+        and the subdirectory is bind-mounted into the container at the
+        same location. If <literal>guest</literal>, the journal files
+        are stored on the guest file system (beneath
+        <filename>/var/log/journal/<replaceable>machine-id</replaceable></filename>)
+        and the subdirectory is symlinked into the host at the same
+        location. <literal>try-host</literal> and
+        <literal>try-guest</literal> do the same but do not fail if
+        the host does not have persistent journaling enabled, or if
+        the container is in the <option>--ephemeral</option> mode. If
+        <literal>auto</literal> (the default), and the right
+        subdirectory of <filename>/var/log/journal</filename> exists,
+        it will be bind mounted into the container. If the
+        subdirectory does not exist, no linking is performed.
+        Effectively, booting a container once with
+        <literal>guest</literal> or <literal>host</literal> will link
+        the journal persistently if further on the default of
+        <literal>auto</literal> is used.</para>
+
+        <para>Note that <option>--link-journal=try-guest</option> is the default if the
+        <filename>systemd-nspawn@.service</filename> template unit file is used.</para>
+
+        <xi:include href="version-info.xml" xpointer="v187"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-j</option></term>
+
+        <listitem><para>Equivalent to
+        <option>--link-journal=try-guest</option>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v187"/></listitem>
+      </varlistentry>
+
+    </variablelist>
+
+    </refsect2><refsect2>
+    <title>Mount Options</title>
+
+    <variablelist>
+
+      <varlistentry>
+        <term><option>--bind=</option></term>
+        <term><option>--bind-ro=</option></term>
+
+        <listitem><para>Bind mount a file or directory from the host into the container. Takes one of: a path
+        argument — in which case the specified path will be mounted from the host to the same path in the container, or
+        a colon-separated pair of paths — in which case the first specified path is the source in the host, and the
+        second path is the destination in the container, or a colon-separated triple of source path, destination path
+        and mount options. The source path may optionally be prefixed with a <literal>+</literal> character. If so, the
+        source path is taken relative to the image's root directory. This permits setting up bind mounts within the
+        container image. The source path may be specified as empty string, in which case a temporary directory below
+        the host's <filename>/var/tmp/</filename> directory is used. It is automatically removed when the container is
+        shut down. If the source path is not absolute, it is resolved relative to the current working directory.
+        The <option>--bind-ro=</option> option creates read-only bind mounts. Backslash escapes are interpreted,
+        so <literal>\:</literal> may be used to embed colons in either path. This option may be specified
+        multiple times for creating multiple independent bind mount points.</para>
+
+        <para>Mount options are comma-separated. <option>rbind</option> and <option>norbind</option> control whether
+        to create a recursive or a regular bind mount. Defaults to <option>rbind</option>. <option>noidmap</option>,
+        <option>idmap</option>, and <option>rootidmap</option> control ID mapping.</para>
+
+        <para>Using <option>idmap</option> or <option>rootidmap</option> requires support by the source filesystem
+        for user/group ID mapped mounts. Defaults to <option>noidmap</option>. With <option>x</option> being the container's UID range
+        offset, <option>y</option> being the length of the container's UID range, and <option>p</option> being the
+        owner UID of the bind mount source inode on the host:
+
+        <itemizedlist>
+          <listitem><para>If <option>noidmap</option> is used, any user <option>z</option> in the range
+          <option>0 … y</option> seen from inside of the container is mapped to <option>x + z</option> in the
+          <option>x … x + y</option> range on the host. Other host users are mapped to
+          <option>nobody</option> inside the container.</para></listitem>
+
+          <listitem><para>If <option>idmap</option> is used, any user <option>z</option> in the UID range
+          <option>0 … y</option> as seen from inside the container is mapped to the same <option>z</option>
+          in the same <option>0 … y</option> range on the host. Other host users are mapped to
+          <option>nobody</option> inside the container.</para></listitem>
+
+          <listitem><para>If <option>rootidmap</option> is used, the user <option>0</option> seen from inside
+          of the container is mapped to <option>p</option> on the host. Other host users are mapped to
+          <option>nobody</option> inside the container.</para></listitem>
+        </itemizedlist></para>
+
+        <para>Whichever ID mapping option is used, the same mapping will be used for users and groups IDs. If
+        <option>rootidmap</option> is used, the group owning the bind mounted directory will have no effect.</para>
+
+        <para>Note that when this option is used in combination with <option>--private-users</option>, the resulting
+        mount points will be owned by the <constant>nobody</constant> user. That's because the mount and its files and
+        directories continue to be owned by the relevant host users and groups, which do not exist in the container,
+        and thus show up under the wildcard UID 65534 (nobody). If such bind mounts are created, it is recommended to
+        make them read-only, using <option>--bind-ro=</option>. Alternatively you can use the "idmap" mount option to
+        map the filesystem IDs.</para>
+
+        <xi:include href="version-info.xml" xpointer="v198"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--bind-user=</option></term>
+
+        <listitem><para>Binds the home directory of the specified user on the host into the container. Takes
+        the name of an existing user on the host as argument. May be used multiple times to bind multiple
+        users into the container. This does three things:</para>
+
+        <orderedlist>
+          <listitem><para>The user's home directory is bind mounted from the host into
+          <filename>/run/host/home/</filename>.</para></listitem>
+
+          <listitem><para>An additional UID/GID mapping is added that maps the host user's UID/GID to a
+          container UID/GID, allocated from the 60514…60577 range.</para></listitem>
+
+          <listitem><para>A JSON user and group record is generated in <filename>/run/userdb/</filename> that
+          describes the mapped user. It contains a minimized representation of the host's user record,
+          adjusted to the UID/GID and home directory path assigned to the user in the container. The
+          <citerefentry><refentrytitle>nss-systemd</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+          glibc NSS module will pick up these records from there and make them available in the container's
+          user/group databases.</para></listitem>
+        </orderedlist>
+
+        <para>The combination of the three operations above ensures that it is possible to log into the
+        container using the same account information as on the host. The user is only mapped transiently,
+        while the container is running, and the mapping itself does not result in persistent changes to the
+        container (except maybe for log messages generated at login time, and similar). Note that in
+        particular the UID/GID assignment in the container is not made persistently. If the user is mapped
+        transiently, it is best to not allow the user to make persistent changes to the container. If the
+        user leaves files or directories owned by the user, and those UIDs/GIDs are reused during later
+        container invocations (possibly with a different <option>--bind-user=</option> mapping), those files
+        and directories will be accessible to the "new" user.</para>
+
+        <para>The user/group record mapping only works if the container contains systemd 249 or newer, with
+        <command>nss-systemd</command> properly configured in <filename>nsswitch.conf</filename>. See
+        <citerefentry><refentrytitle>nss-systemd</refentrytitle><manvolnum>8</manvolnum></citerefentry> for
+        details.</para>
+
+        <para>Note that the user record propagated from the host into the container will contain the UNIX
+        password hash of the user, so that seamless logins in the container are possible. If the container is
+        less trusted than the host it's hence important to use a strong UNIX password hash function
+        (e.g. yescrypt or similar, with the <literal>$y$</literal> hash prefix).</para>
+
+        <para>When binding a user from the host into the container checks are executed to ensure that the
+        username is not yet known in the container. Moreover, it is checked that the UID/GID allocated for it
+        is not currently defined in the user/group databases of the container. Both checks directly access
+        the container's <filename>/etc/passwd</filename> and <filename>/etc/group</filename>, and thus might
+        not detect existing accounts in other databases.</para>
+
+        <para>This operation is only supported in combination with
+        <option>--private-users=</option>/<option>-U</option>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v249"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--inaccessible=</option></term>
+
+        <listitem><para>Make the specified path inaccessible in the container. This over-mounts the specified path
+        (which must exist in the container) with a file node of the same type that is empty and has the most
+        restrictive access mode supported. This is an effective way to mask files, directories and other file system
+        objects from the container payload. This option may be used more than once in case all specified paths are
+        masked.</para>
+
+        <xi:include href="version-info.xml" xpointer="v242"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--tmpfs=</option></term>
+
+        <listitem><para>Mount a tmpfs file system into the container.  Takes a single absolute path argument that
+        specifies where to mount the tmpfs instance to (in which case the directory access mode will be chosen as 0755,
+        owned by root/root), or optionally a colon-separated pair of path and mount option string that is used for
+        mounting (in which case the kernel default for access mode and owner will be chosen, unless otherwise
+        specified). Backslash escapes are interpreted in the path, so <literal>\:</literal> may be used to embed colons
+        in the path.</para>
+
+        <para>Note that this option cannot be used to replace the root file system of the container with a temporary
+        file system. However, the <option>--volatile=</option> option described below provides similar
+        functionality, with a focus on implementing stateless operating system images.</para>
+
+        <xi:include href="version-info.xml" xpointer="v214"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--overlay=</option></term>
+        <term><option>--overlay-ro=</option></term>
+
+        <listitem><para>Combine multiple directory trees into one overlay file system and mount it into the
+        container. Takes a list of colon-separated paths to the directory trees to combine and the
+        destination mount point.</para>
+
+        <para>Backslash escapes are interpreted in the paths, so <literal>\:</literal> may be used to embed
+        colons in the paths.</para>
+
+        <para>If three or more paths are specified, then the last specified path is the destination mount
+        point in the container, all paths specified before refer to directory trees on the host and are
+        combined in the specified order into one overlay file system. The left-most path is hence the lowest
+        directory tree, the second-to-last path the highest directory tree in the stacking order. If
+        <option>--overlay-ro=</option> is used instead of <option>--overlay=</option>, a read-only overlay
+        file system is created. If a writable overlay file system is created, all changes made to it are
+        written to the highest directory tree in the stacking order, i.e. the second-to-last specified.
+        </para>
+
+        <para>If only two paths are specified, then the second specified path is used both as the top-level
+        directory tree in the stacking order as seen from the host, as well as the mount point for the
+        overlay file system in the container. At least two paths have to be specified.</para>
+
+        <para>The source paths may optionally be prefixed with <literal>+</literal> character. If so they are
+        taken relative to the image's root directory. The uppermost source path may also be specified as an
+        empty string, in which case a temporary directory below the host's <filename>/var/tmp/</filename> is
+        used. The directory is removed automatically when the container is shut down. This behaviour is
+        useful in order to make read-only container directories writable while the container is running. For
+        example, use <literal>--overlay=+/var::/var</literal> in order to automatically overlay a writable
+        temporary directory on a read-only <filename>/var/</filename> directory. If a source path is not
+        absolute, it is resolved relative to the current working directory.</para>
+
+        <para>For details about overlay file systems, see <ulink
+        url="https://docs.kernel.org/filesystems/overlayfs.html">Overlay Filesystem</ulink>.
+        Note that the semantics of overlay file systems are substantially different from normal file systems,
+        in particular regarding reported device and inode information. Device and inode information may
+        change for a file while it is being written to, and processes might see out-of-date versions of files
+        at times. Note that this switch automatically derives the <literal>workdir=</literal> mount option
+        for the overlay file system from the top-level directory tree, making it a sibling of it. It is hence
+        essential that the top-level directory tree is not a mount point itself (since the working directory
+        must be on the same file system as the top-most directory tree). Also note that the
+        <literal>lowerdir=</literal> mount option receives the paths to stack in the opposite order of this
+        switch.</para>
+
+        <para>Note that this option cannot be used to replace the root file system of the container with an overlay
+        file system. However, the <option>--volatile=</option> option described above provides similar functionality,
+        with a focus on implementing stateless operating system images.</para>
+
+        <xi:include href="version-info.xml" xpointer="v220"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect2>
+
+  <refsect2>
+    <title>Input/Output Options</title>
+
+    <variablelist>
+      <varlistentry>
+        <term><option>--console=</option><replaceable>MODE</replaceable></term>
+
+        <listitem><para>Configures how to set up standard input, output and error output for the container
+        payload, as well as the <filename>/dev/console</filename> device for the container. Takes one of
+        <option>interactive</option>, <option>read-only</option>, <option>passive</option>,
+        <option>pipe</option> or <option>autopipe</option>. If <option>interactive</option>, a pseudo-TTY is
+        allocated and made available as <filename>/dev/console</filename> in the container. It is then
+        bi-directionally connected to the standard input and output passed to
+        <command>systemd-nspawn</command>. <option>read-only</option> is similar but only the output of the
+        container is propagated and no input from the caller is read. If <option>passive</option>, a pseudo
+        TTY is allocated, but it is not connected anywhere. In <option>pipe</option> mode no pseudo TTY is
+        allocated, but the standard input, output and error output file descriptors passed to
+        <command>systemd-nspawn</command> are passed on — as they are — to the container payload, see the
+        following paragraph. Finally, <option>autopipe</option> mode operates like
+        <option>interactive</option> when <command>systemd-nspawn</command> is invoked on a terminal, and
+        like <option>pipe</option> otherwise. Defaults to <option>interactive</option> if
+        <command>systemd-nspawn</command> is invoked from a terminal, and <option>read-only</option>
+        otherwise.</para>
+
+        <para>In <option>pipe</option> mode, <filename>/dev/console</filename> will not exist in the
+        container. This means that the container payload generally cannot be a full init system as init
+        systems tend to require <filename>/dev/console</filename> to be available. On the other hand, in this
+        mode container invocations can be used within shell pipelines. This is because intermediary pseudo
+        TTYs do not permit independent bidirectional propagation of the end-of-file (EOF) condition, which is
+        necessary for shell pipelines to work correctly. <emphasis>Note that the <option>pipe</option> mode
+        should be used carefully</emphasis>, as passing arbitrary file descriptors to less trusted container
+        payloads might open up unwanted interfaces for access by the container payload. For example, if a
+        passed file descriptor refers to a TTY of some form, APIs such as <constant>TIOCSTI</constant> may be
+        used to synthesize input that might be used for escaping the container. Hence <option>pipe</option>
+        mode should only be used if the payload is sufficiently trusted or when the standard
+        input/output/error output file descriptors are known safe, for example pipes.</para>
+
+        <xi:include href="version-info.xml" xpointer="v242"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--pipe</option></term>
+        <term><option>-P</option></term>
+
+        <listitem><para>Equivalent to <option>--console=pipe</option>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v242"/></listitem>
+      </varlistentry>
+    </variablelist>
+
+    </refsect2>
+    <refsect2>
+      <title>Credentials</title>
+
+      <variablelist>
+        <varlistentry>
+          <term><option>--load-credential=</option><replaceable>ID</replaceable>:<replaceable>PATH</replaceable></term>
+          <term><option>--set-credential=</option><replaceable>ID</replaceable>:<replaceable>VALUE</replaceable></term>
+
+          <listitem><para>Pass a credential to the container. These two options correspond to the
+          <varname>LoadCredential=</varname> and <varname>SetCredential=</varname> settings in unit files. See
+          <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
+          details about these concepts, as well as the syntax of the option's arguments.</para>
+
+          <para>Note: when <command>systemd-nspawn</command> runs as systemd system service it can propagate
+          the credentials it received via <varname>LoadCredential=</varname>/<varname>SetCredential=</varname>
+          to the container payload. A systemd service manager running as PID 1 in the container can further
+          propagate them to the services it itself starts. It is thus possible to easily propagate credentials
+          from a parent service manager to a container manager service and from there into its payload. This
+          can even be done recursively.</para>
+
+          <para>In order to embed binary data into the credential data for <option>--set-credential=</option>,
+          use C-style escaping (i.e. <literal>\n</literal> to embed a newline, or <literal>\x00</literal> to
+          embed a <constant>NUL</constant> byte). Note that the invoking shell might already apply unescaping
+          once, hence this might require double escaping!.</para>
+
+          <para>The
+          <citerefentry><refentrytitle>systemd-sysusers.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+          and
+          <citerefentry><refentrytitle>systemd-firstboot</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+          services read credentials configured this way for the purpose of configuring the container's root
+          user's password and shell, as well as system locale, keymap and timezone during the first boot
+          process of the container. This is particularly useful in combination with
+          <option>--volatile=yes</option> where every single boot appears as first boot, since configuration
+          applied to <filename>/etc/</filename> is lost on container reboot cycles. See the respective man
+          pages for details. Example:</para>
+
+          <programlisting># systemd-nspawn -i image.raw \
+          --volatile=yes \
+          --set-credential=firstboot.locale:de_DE.UTF-8 \
+          --set-credential=passwd.hashed-password.root:'$y$j9T$yAuRJu1o5HioZAGDYPU5d.$F64ni6J2y2nNQve90M/p0ZP0ECP/qqzipNyaY9fjGpC' \
+          -b</programlisting>
+
+          <para>The above command line will invoke the specified image file <filename>image.raw</filename> in
+          volatile mode, i.e. with empty <filename>/etc/</filename> and <filename>/var/</filename>.  The
+          container payload will recognize this as a first boot, and will invoke
+          <filename>systemd-firstboot.service</filename>, which then reads the two passed credentials to
+          configure the system's initial locale and root password.</para>
+
+          <xi:include href="version-info.xml" xpointer="v247"/>
+          </listitem>
+        </varlistentry>
+      </variablelist>
+
+    </refsect2><refsect2>
+    <title>Other</title>
+
+    <variablelist>
+      <xi:include href="standard-options.xml" xpointer="no-pager" />
+      <xi:include href="standard-options.xml" xpointer="help" />
+      <xi:include href="standard-options.xml" xpointer="version" />
+    </variablelist>
+   </refsect2>
+  </refsect1>
+
+  <xi:include href="common-variables.xml" />
+
+  <refsect1>
+    <title>Examples</title>
+
+    <example>
+      <title>Download a
+      <ulink url="https://getfedora.org">Fedora</ulink> image and start a shell in it</title>
+
+      <programlisting># machinectl pull-raw --verify=no \
+      https://download.fedoraproject.org/pub/fedora/linux/releases/&fedora_latest_version;/Cloud/x86_64/images/Fedora-Cloud-Base-&fedora_latest_version;-&fedora_cloud_release;.x86_64.raw.xz \
+      Fedora-Cloud-Base-&fedora_latest_version;-&fedora_cloud_release;.x86-64
+# systemd-nspawn -M Fedora-Cloud-Base-&fedora_latest_version;-&fedora_cloud_release;.x86-64</programlisting>
+
+      <para>This downloads an image using
+      <citerefentry><refentrytitle>machinectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+      and opens a shell in it.</para>
+    </example>
+
+    <example>
+      <title>Build and boot a minimal Fedora distribution in a container</title>
+
+      <programlisting># dnf -y --releasever=&fedora_latest_version; --installroot=/var/lib/machines/f&fedora_latest_version; \
+      --repo=fedora --repo=updates --setopt=install_weak_deps=False install \
+      passwd dnf fedora-release vim-minimal util-linux systemd systemd-networkd
+# systemd-nspawn -bD /var/lib/machines/f&fedora_latest_version;</programlisting>
+
+      <para>This installs a minimal Fedora distribution into the
+      directory <filename index="false">/var/lib/machines/f&fedora_latest_version;</filename>
+      and then boots that OS in a namespace container. Because the installation
+      is located underneath the standard <filename>/var/lib/machines/</filename>
+      directory, it is also possible to start the machine using
+      <command>systemd-nspawn -M f&fedora_latest_version;</command>.</para>
+    </example>
+
+    <example>
+      <title>Spawn a shell in a container of a minimal Debian unstable distribution</title>
+
+      <programlisting># debootstrap unstable ~/debian-tree/
+# systemd-nspawn -D ~/debian-tree/</programlisting>
+
+      <para>This installs a minimal Debian unstable distribution into
+      the directory <filename>~/debian-tree/</filename> and then
+      spawns a shell from this image in a namespace container.</para>
+
+      <para><command>debootstrap</command> supports
+      <ulink url="https://www.debian.org">Debian</ulink>,
+      <ulink url="https://www.ubuntu.com">Ubuntu</ulink>,
+      and <ulink url="https://www.tanglu.org">Tanglu</ulink>
+      out of the box, so the same command can be used to install any of those. For other
+      distributions from the Debian family, a mirror has to be specified, see
+      <citerefentry project='die-net'><refentrytitle>debootstrap</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+      </para>
+    </example>
+
+    <example>
+      <title>Boot a minimal
+      <ulink url="https://www.archlinux.org">Arch Linux</ulink> distribution in a container</title>
+
+      <programlisting># pacstrap -c ~/arch-tree/ base
+# systemd-nspawn -bD ~/arch-tree/</programlisting>
+
+      <para>This installs a minimal Arch Linux distribution into the
+      directory <filename>~/arch-tree/</filename> and then boots an OS
+      in a namespace container in it.</para>
+    </example>
+
+    <example>
+      <title>Install the
+      <ulink url="https://software.opensuse.org/distributions/tumbleweed">OpenSUSE Tumbleweed</ulink>
+      rolling distribution</title>
+
+      <programlisting># zypper --root=/var/lib/machines/tumbleweed ar -c \
+      https://download.opensuse.org/tumbleweed/repo/oss tumbleweed
+# zypper --root=/var/lib/machines/tumbleweed refresh
+# zypper --root=/var/lib/machines/tumbleweed install --no-recommends \
+      systemd shadow zypper openSUSE-release vim
+# systemd-nspawn -M tumbleweed passwd root
+# systemd-nspawn -M tumbleweed -b</programlisting>
+    </example>
+
+    <example>
+      <title>Boot into an ephemeral snapshot of the host system</title>
+
+      <programlisting># systemd-nspawn -D / -xb</programlisting>
+
+      <para>This runs a copy of the host system in a snapshot which is removed immediately when the container
+      exits. All file system changes made during runtime will be lost on shutdown, hence.</para>
+    </example>
+
+    <example>
+      <title>Run a container with SELinux sandbox security contexts</title>
+
+      <programlisting># chcon system_u:object_r:svirt_sandbox_file_t:s0:c0,c1 -R /srv/container
+# systemd-nspawn -L system_u:object_r:svirt_sandbox_file_t:s0:c0,c1 \
+      -Z system_u:system_r:svirt_lxc_net_t:s0:c0,c1 -D /srv/container /bin/sh</programlisting>
+    </example>
+
+    <example>
+      <title>Run a container with an OSTree deployment</title>
+
+      <programlisting># systemd-nspawn -b -i ~/image.raw \
+      --pivot-root=/ostree/deploy/$OS/deploy/$CHECKSUM:/sysroot \
+      --bind=+/sysroot/ostree/deploy/$OS/var:/var</programlisting>
+    </example>
+  </refsect1>
+
+  <refsect1>
+    <title>Exit status</title>
+
+    <para>The exit code of the program executed in the container is
+    returned.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.nspawn</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>chroot</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry project='mankier'><refentrytitle>dnf</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry project='die-net'><refentrytitle>debootstrap</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry project='archlinux'><refentrytitle>pacman</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry project='mankier'><refentrytitle>zypper</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>machinectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry project='url'><refentrytitle url='https://btrfs.readthedocs.io/en/latest/btrfs.html'>btrfs</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-oomd.service.xml b/man/systemd-oomd.service.xml
new file mode 100644
index 0000000..d8ecfde
--- /dev/null
+++ b/man/systemd-oomd.service.xml
@@ -0,0 +1,134 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd-oomd.service" conditional='ENABLE_OOMD'
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd-oomd.service</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-oomd.service</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-oomd.service</refname>
+    <refname>systemd-oomd</refname>
+    <refpurpose>A userspace out-of-memory (OOM) killer</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>systemd-oomd.service</filename></para>
+    <para><filename>/usr/lib/systemd/systemd-oomd</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>systemd-oomd</command> is a system service that uses cgroups-v2 and pressure stall
+    information (PSI) to monitor and take corrective action before an OOM occurs in the kernel space.</para>
+
+    <para>You can enable monitoring and actions on units by setting <varname>ManagedOOMSwap=</varname> and
+    <varname>ManagedOOMMemoryPressure=</varname> in the unit configuration, see
+    <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+    <command>systemd-oomd</command> retrieves information about such units from
+    <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    when it starts and watches for subsequent changes.</para>
+
+    <para>Cgroups of units with <varname>ManagedOOMSwap=</varname> or
+    <varname>ManagedOOMMemoryPressure=</varname> set to <option>kill</option> will be monitored.
+    <command>systemd-oomd</command> periodically polls PSI statistics for the system and those cgroups to
+    decide when to take action. If the configured limits are exceeded, <command>systemd-oomd</command> will
+    select a cgroup to terminate, and send <constant>SIGKILL</constant> to all processes in it. Note that
+    only descendant cgroups are eligible candidates for killing; the unit with its property set to
+    <option>kill</option> is not a candidate (unless one of its ancestors set their property to
+    <option>kill</option>). Also only leaf cgroups and cgroups with <filename>memory.oom.group</filename> set
+    to <constant>1</constant> are eligible candidates; see <varname>OOMPolicy=</varname> in
+    <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+    </para>
+
+    <para><citerefentry><refentrytitle>oomctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> can
+    be used to list monitored cgroups and pressure information.</para>
+
+    <para>See <citerefentry><refentrytitle>oomd.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for more information about the configuration of this service.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>System requirements and configuration</title>
+
+    <para>The system must be running systemd with a full unified cgroup hierarchy for the expected cgroups-v2 features.
+    Furthermore, memory accounting must be turned on for all units monitored by <command>systemd-oomd</command>.
+    The easiest way to turn on memory accounting is by ensuring the value for <varname>DefaultMemoryAccounting=</varname>
+    is set to <constant>true</constant> in
+    <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+
+    <para>The kernel must be compiled with PSI support. This is available in Linux 4.20 and above.</para>
+
+    <para>It is highly recommended for the system to have swap enabled for <command>systemd-oomd</command> to
+    function optimally. With swap enabled, the system spends enough time swapping pages to let
+    <command>systemd-oomd</command> react.  Without swap, the system enters a livelocked state much more
+    quickly and may prevent <command>systemd-oomd</command> from responding in a reasonable amount of
+    time. See <ulink url="https://chrisdown.name/2018/01/02/in-defence-of-swap.html">"In defence of swap:
+    common misconceptions"</ulink> for more details on swap. Any swap-based actions on systems without swap
+    will be ignored. While <command>systemd-oomd</command> can perform pressure-based actions on such a
+    system, the pressure increases will be more abrupt and may require more tuning to get the desired
+    thresholds and behavior.</para>
+
+    <para>Be aware that if you intend to enable monitoring and actions on <filename>user.slice</filename>,
+    <filename>user-$UID.slice</filename>, or their ancestor cgroups, it is highly recommended that your
+    programs be managed by the systemd user manager to prevent running too many processes under the same
+    session scope (and thus avoid a situation where memory intensive tasks trigger
+    <command>systemd-oomd</command> to kill everything under the cgroup). If you're using a desktop
+    environment like GNOME or KDE, it already spawns many session components with the systemd user manager.
+    </para>
+  </refsect1>
+
+  <refsect1>
+    <title>Usage Recommendations</title>
+
+    <para><varname>ManagedOOMSwap=</varname> works with the system-wide swap values, so setting it on the root slice
+    <filename>-.slice</filename>, and allowing all descendant cgroups to be eligible candidates may make the most
+    sense.</para>
+
+    <para><varname>ManagedOOMMemoryPressure=</varname> tends to work better on the cgroups below the root
+    slice. For units which tend to have processes that are less latency sensitive (e.g.
+    <filename>system.slice</filename>), a higher limit like the default of 60% may be acceptable, as those
+    processes can usually ride out slowdowns caused by lack of memory without serious consequences. However,
+    something like <filename>user@$UID.service</filename> may prefer a much lower value like 40%.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <variablelist>
+      <varlistentry>
+        <term><option>--dry-run</option></term>
+
+        <listitem><para>Do a dry run of <command>systemd-oomd</command>: when a kill is triggered, print it
+        to the log instead of killing the cgroup.</para>
+
+        <xi:include href="version-info.xml" xpointer="v253"/></listitem>
+      </varlistentry>
+    </variablelist>
+
+    <xi:include href="standard-options.xml" xpointer="help" />
+    <xi:include href="standard-options.xml" xpointer="version" />
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>oomd.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>oomctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+</refentry>
diff --git a/man/systemd-path.xml b/man/systemd-path.xml
new file mode 100644
index 0000000..b1d566e
--- /dev/null
+++ b/man/systemd-path.xml
@@ -0,0 +1,84 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd-path"
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd-path</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-path</refentrytitle>
+    <manvolnum>1</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-path</refname>
+    <refpurpose>List and query system and user paths</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <cmdsynopsis>
+      <command>systemd-path</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="opt" rep="repeat">NAME</arg>
+    </cmdsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>systemd-path</command> may be used to query system
+    and user paths. The tool makes many of the paths described in
+    <citerefentry><refentrytitle>file-hierarchy</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+    available for querying.</para>
+
+    <para>When invoked without arguments, a list of known paths and
+    their current values is shown. When at least one argument is
+    passed, the path with this name is queried and its value shown.
+    The variables whose name begins with <literal>search-</literal>
+    do not refer to individual paths, but instead to a list of
+    colon-separated search paths, in their order of precedence.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>The following options are understood:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><option>--suffix=</option></term>
+
+        <listitem><para>Printed paths are suffixed by the specified string.</para>
+
+        <xi:include href="version-info.xml" xpointer="v215"/></listitem>
+      </varlistentry>
+
+      <xi:include href="standard-options.xml" xpointer="no-pager-255"/>
+      <xi:include href="standard-options.xml" xpointer="help" />
+      <xi:include href="standard-options.xml" xpointer="version" />
+    </variablelist>
+
+  </refsect1>
+
+  <refsect1>
+    <title>Exit status</title>
+
+    <para>On success, 0 is returned, a non-zero failure code
+    otherwise.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>file-hierarchy</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-pcrlock.xml b/man/systemd-pcrlock.xml
new file mode 100644
index 0000000..f82268c
--- /dev/null
+++ b/man/systemd-pcrlock.xml
@@ -0,0 +1,559 @@
+<?xml version="1.0"?>
+<!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+<refentry id="systemd-pcrlock" xmlns:xi="http://www.w3.org/2001/XInclude" conditional='ENABLE_BOOTLOADER'>
+
+  <refentryinfo>
+    <title>systemd-pcrlock</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-pcrlock</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-pcrlock</refname>
+    <refname>systemd-pcrlock-file-system.service</refname>
+    <refname>systemd-pcrlock-firmware-code.service</refname>
+    <refname>systemd-pcrlock-firmware-config.service</refname>
+    <refname>systemd-pcrlock-machine-id.service</refname>
+    <refname>systemd-pcrlock-make-policy.service</refname>
+    <refname>systemd-pcrlock-secureboot-authority.service</refname>
+    <refname>systemd-pcrlock-secureboot-policy.service</refname>
+    <refpurpose>Analyze and predict TPM2 PCR states and generate an access policy from the prediction</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <cmdsynopsis>
+      <command>/usr/lib/systemd/systemd-pcrlock <arg choice="opt" rep="repeat">OPTIONS</arg></command>
+    </cmdsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>Note: this command is experimental for now. While it is likely to become a regular component of
+    systemd, it might still change in behaviour and interface.</para>
+
+    <para><command>systemd-pcrlock</command> is a tool that may be used to analyze and predict TPM2 PCR
+    measurements, and generate TPM2 access policies from the prediction which it stores in a TPM2 NV index
+    (i.e. in the TPM2 non-volatile memory). This may then be used to restrict access to TPM2 objects (such as
+    disk encryption keys) to system boot-ups in which only specific, trusted components are used.</para>
+
+    <para><command>systemd-pcrlock</command> uses as input for its analysis and prediction:</para>
+
+    <itemizedlist>
+      <listitem><para>The UEFI firmware TPM2 event log
+      (i.e. <filename>/sys/kernel/security/tpm0/binary_bios_measurements</filename>) of the current
+      boot.</para></listitem>
+
+      <listitem><para>The userspace TPM2 event log
+      (i.e. <filename>/run/log/systemd/tpm2-measure.log</filename>) of the current
+      boot.</para></listitem>
+
+      <listitem><para>The current PCR state of the TPM2 chip.</para></listitem>
+
+      <listitem><para>Boot component definition files (<filename>*.pcrlock</filename> and
+      <filename>*.pcrlock.d/*.pcrlock</filename>, see
+      <citerefentry><refentrytitle>systemd.pcrlock</refentrytitle><manvolnum>5</manvolnum></citerefentry>)
+      that each define expected measurements for one component of the boot process, permitting alternative
+      variants for each. (Variants may be used used to bless multiple kernel versions or boot loader versions
+      at the same time.)</para></listitem>
+    </itemizedlist>
+
+    <para>It uses these inputs to generate a combined event log, validating it against the PCR states. It
+    then attempts to recognize event log records and matches them against the defined components. For each PCR
+    where this can be done comprehensively (i.e. where all listed records and all defined components have
+    been matched) this may then be used to predict future PCR measurements, taking the alternative variants
+    defined for each component into account. This prediction may then be converted into a TPM2 access policy
+    (consisting of TPM2 <function>PolicyPCR</function> and <function>PolicyOR</function> items), which is
+    then stored in an NV index in the TPM2. This may be used to then lock secrets (such as disk encryption
+    keys) to these policies (via a TPM2 <function>PolicyAuthorizeNV</function> policy).</para>
+
+    <para>Use tools such as
+    <citerefentry><refentrytitle>systemd-cryptenroll</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    or <citerefentry><refentrytitle>systemd-repart</refentrytitle><manvolnum>8</manvolnum></citerefentry> to
+    bind disk encryption to such a <command>systemd-pcrlock</command> TPM2 policy. Specifically, see the
+    <option>--tpm2-pcrlock=</option> switches of these tools.</para>
+
+    <para>The access policy logic requires a TPM2 device that implements the
+    <literal>PolicyAuthorizeNV</literal> command, i.e. implements TPM 2.0 version 1.38 or newer.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Commands</title>
+
+    <para>The following commands are understood:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><command>log</command></term>
+
+        <listitem><para>This reads the combined TPM2 event log, validates it, matches it against the current
+        PCR values, and outputs both in tabular form. Combine with <option>--json=</option> to generate
+        output in JSON format.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>cel</command></term>
+
+        <listitem><para>This reads the combined TPM2 event log and writes it to STDOUT in <ulink
+        url="https://trustedcomputinggroup.org/resource/canonical-event-log-format/">TCG Common Event Log
+        Format (CEL-JSON)</ulink> format.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>list-components</command></term>
+
+        <listitem><para>Shows a list of component definitions and their variants, i.e. the
+        <filename>*.pcrlock</filename> files discovered in <filename>/var/lib/pcrlock.d/</filename>,
+        <filename>/usr/lib/pcrlock.d/</filename>, and the other supported directories. See
+        <citerefentry><refentrytitle>systemd.pcrlock</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for details on these files and the full list of directories searched.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>predict</command></term>
+
+        <listitem><para>Predicts the PCR state on future boots. This will analyze the TPM2 event log as
+        described above, recognize components, and then generate all possible resulting PCR values for all
+        combinations of component variants. Note that no prediction is made for PCRs whose value does not
+        match the event log records, for which unrecognized measurements are discovered or for which
+        components are defined that cannot be found in the event log. This is a safety measure to ensure that
+        any generated access policy can be fulfilled correctly on current and future boots.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>make-policy</command></term>
+
+        <listitem><para>This predicts the PCR state for future boots, much like the
+        <command>predict</command> command above. It then uses this data to generate a TPM2 access policy
+        which it stores in a TPM2 NV index. The prediction and information about the used TPM2 and its NV
+        index are written to <filename>/var/lib/systemd/pcrlock.json</filename>.</para>
+
+        <para>The NV index is allocated on first invocation, and updated on subsequent invocations.</para>
+
+        <para>The NV index contents may be changed (and thus the policy stored in it updated) by providing an
+        access PIN. This PIN is normally generated automatically and stored in encrypted form (with an access
+        policy binding it to the NV index itself) in the aforementioned JSON policy file. This PIN may be
+        chosen by the user, via the <option>--recovery-pin=</option> switch. If specified it may be used as
+        alternative path of access to update the policy.</para>
+
+        <para>If the new prediction matches the old this command terminates quickly and executes no further
+        operation. (Unless <option>--force</option> is specified, see below.)</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>remove-policy</command></term>
+
+        <listitem><para>Removes a previously generated policy. Deletes the
+        <filename>/var/lib/systemd/pcrlock.json</filename> file, and deallocates the NV index.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>lock-firmware-code</command></term>
+        <term><command>unlock-firmware-code</command></term>
+
+        <listitem><para>Generates/removes <filename>.pcrlock</filename> files based on the TPM2 event log of
+        the current boot covering all records for PCRs 0 ("platform-code") and 2 ("external-code").</para>
+
+        <para>This operation allows locking the boot process to the current version of the firmware of the
+        system and its extension cards. This operation should only be used if the system vendor does not
+        provide suitable pcrlock data ahead of time.</para>
+
+        <para>Note that this data only matches the current version of the firmware. If a firmware update is
+        applied this data will be out-of-date and any access policy generated from it will no longer pass. It
+        is thus recommended to invoke <command>unlock-firmware-code</command> before doing a firmware update,
+        followed by <command>make-policy</command> to refresh the policy.</para>
+
+        <para><command>systemd-pcrlock lock-firmware-code</command> is invoked automatically at boot via the
+        <filename>systemd-pcrlock-firmware-code.service</filename> unit, if enabled. This ensures that an
+        access policy managed by <command>systemd-pcrlock</command> is automatically locked to the new
+        firmware version whenever the policy has been relaxed temporarily, in order to cover for firmware
+        updates, as described above.</para>
+
+        <para>The files are only generated from the event log if the event log matches the current TPM2 PCR
+        state.</para>
+
+        <para>This writes/removes the files
+        <filename>/var/lib/pcrlock.d/250-firmware-code-early.pcrlock.d/generated.pcrlock</filename> and
+        <filename>/var/lib/pcrlock.d/550-firmware-code-late.pcrlock.d/generated.pcrlock</filename>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>lock-firmware-config</command></term>
+        <term><command>unlock-firmware-config</command></term>
+
+        <listitem><para>This is similar to
+        <command>lock-firmware-code</command>/<command>unlock-firmware-code</command> but locks down the
+        firmware configuration, i.e. PCRs 1 ("platform-config") and 3 ("external-config").</para>
+
+        <para>This functionality should be used with care as in most scenarios a minor firmware configuration
+        change should not invalidate access policies to TPM2 objects. Also note that some systems measure
+        unstable and unpredictable information (e.g. current CPU voltages, temperatures, as part of SMBIOS
+        data) to these PCRs, which means this form of lockdown cannot be used reliably on such systems. Use
+        this functionality only if the system and hardware is well known and does not suffer by these
+        limitations, for example in virtualized environments.</para>
+
+        <para>Use <command>unlock-firmware-config</command> before making firmware configuration changes. If
+        the <filename>systemd-pcrlock-firmware-config.service</filename> unit is enabled it will
+        automatically generate a pcrlock file from the new measurements.</para>
+
+        <para>This writes/removes the files
+        <filename>/var/lib/pcrlock.d/250-firmware-config-early.pcrlock.d/generated.pcrlock</filename> and
+        <filename>/var/lib/pcrlock.d/550-firmware-config-late.pcrlock.d/generated.pcrlock</filename>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>lock-secureboot-policy</command></term>
+        <term><command>unlock-secureboot-policy</command></term>
+
+        <listitem><para>Generates/removes a <filename>.pcrlock</filename> file based on the SecureBoot policy
+        currently enforced. This looks at the SecureBoot, PK, KEK, db, dbx, dbt, dbr EFI variables and
+        predicts their measurements to PCR 7 ("secure-boot-policy") on the next boot.</para>
+
+        <para>Use <command>unlock-firmware-config</command> before applying SecureBoot policy updates. If
+        the <filename>systemd-pcrlock-secureboot-policy.service</filename> unit is enabled it will
+        automatically generate a pcrlock file from the policy discovered.</para>
+
+        <para>This writes/removes the file
+        <filename>/var/lib/pcrlock.d/230-secureboot-policy.pcrlock.d/generated.pcrlock</filename>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>lock-secureboot-authority</command></term>
+        <term><command>unlock-secureboot-authority</command></term>
+
+        <listitem><para>Generates/removes a <filename>.pcrlock</filename> file based on the SecureBoot
+        authorities used to validate the boot path. SecureBoot authorities are the specific SecureBoot
+        database entries that where used to validate the UEFI PE binaries executed at boot. This looks at the
+        event log of the current boot, and uses relevant measurements on PCR 7
+        ("secure-boot-policy").</para>
+
+        <para>This writes/removes the file
+        <filename>/var/lib/pcrlock.d/620-secureboot-authority.pcrlock.d/generated.pcrlock</filename>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>lock-gpt</command> <arg choice="opt"><replaceable>DEVICE</replaceable></arg></term>
+        <term><command>unlock-gpt</command></term>
+
+        <listitem><para>Generates/removes a <filename>.pcrlock</filename> file based on the GPT partition
+        table of the specified disk. If no disk is specified automatically determines the block device
+        backing the root file system. This locks the state of the disk partitioning of the booted medium,
+        which firmware measures to PCR 5 ("boot-loader-config").</para>
+
+        <para>This writes/removes the file
+        <filename>/var/lib/pcrlock.d/600-gpt.pcrlock.d/generated.pcrlock</filename>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>lock-pe</command> <arg choice="opt"><replaceable>BINARY</replaceable></arg></term>
+        <term><command>unlock-pe</command></term>
+
+        <listitem><para>Generates/removes a <filename>.pcrlock</filename> file based on the specified PE
+        binary. This is useful for predicting measurements the firmware makes to PCR 4 ("boot-loader-code")
+        if the specified binary is part of the UEFI boot process. Use this on boot loader binaries and
+        suchlike. Use <command>lock-uki</command> (see below) for PE binaries that are unified kernel images
+        (UKIs).</para>
+
+        <para>Expects a path to the PE binary as argument. If not specified, reads the binary from STDIN
+        instead.</para>
+
+        <para>The pcrlock file to write must be specified via the <option>--pcrlock=</option> switch.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>lock-uki</command> <arg choice="opt"><replaceable>UKI</replaceable></arg></term>
+        <term><command>unlock-uki</command></term>
+
+        <listitem><para>Generates/removes a <filename>.pcrlock</filename> file based on the specified UKI PE
+        binary. This is useful for predicting measurements the firmware makes to PCR 4 ("boot-loader-code"),
+        and <citerefentry><refentrytitle>systemd-stub</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+        makes to PCR 11 ("kernel-boot"), if the specified UKI is booted. This is a superset of
+        <command>lock-pe</command>.</para>
+
+        <para>Expects a path to the UKI PE binary as argument. If not specified, reads the binary from STDIN
+        instead.</para>
+
+        <para>The pcrlock file to write must be specified via the <option>--pcrlock=</option> switch.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>lock-machine-id</command></term>
+        <term><command>unlock-machine-id</command></term>
+
+        <listitem><para>Generates/removes a <filename>.pcrlock</filename> file based on
+        <filename>/etc/machine-id</filename>. This is useful for predicting measurements
+        <citerefentry><refentrytitle>systemd-pcrmachine.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        makes to PCR 15 ("system-identity").</para>
+
+        <para>This writes/removes the file
+        <filename>/var/lib/pcrlock.d/820-machine-id.pcrlock</filename>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>lock-file-system</command> <arg choice="opt"><replaceable>PATH</replaceable></arg></term>
+        <term><command>unlock-file-system</command> <arg choice="opt"><replaceable>PATH</replaceable></arg></term>
+
+        <listitem><para>Generates/removes a <filename>.pcrlock</filename> file based on file system
+        identity. This is useful for predicting measurements
+        <citerefentry><refentrytitle>systemd-pcrfs@.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        makes to PCR 15 ("system-identity") for the root and <filename>/var/</filename> file systems.</para>
+
+        <para>This writes/removes the files
+        <filename>/var/lib/pcrlock.d/830-root-file-system.pcrlock</filename> and
+        <filename>/var/lib/pcrlock.d/840-file-system-<replaceable>path</replaceable>.pcrlock</filename>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>lock-kernel-cmdline</command> <arg choice="opt"><replaceable>FILE</replaceable></arg></term>
+        <term><command>unlock-kernel-cmdline</command></term>
+
+        <listitem><para>Generates/removes a <filename>.pcrlock</filename> file based on
+        <filename>/proc/cmdline</filename> (or the specified file if given). This is useful for predicting
+        measurements the Linux kernel makes to PCR 9 ("kernel-initrd").</para>
+
+        <para>This writes/removes the file
+        <filename>/var/lib/pcrlock.d/710-kernel-cmdline.pcrlock/generated.pcrlock</filename>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>lock-kernel-initrd</command> <replaceable>FILE</replaceable></term>
+        <term><command>unlock-kernel-initrd</command></term>
+
+        <listitem><para>Generates/removes a <filename>.pcrlock</filename> file based on a kernel initrd cpio
+        archive. This is useful for predicting measurements the Linux kernel makes to PCR 9
+        ("kernel-initrd"). Do not use for <command>systemd-stub</command> UKIs, as the initrd is combined
+        dynamically from various sources and hence does not take a single input, like this command.</para>
+
+        <para>This writes/removes the file
+        <filename>/var/lib/pcrlock.d/720-kernel-initrd.pcrlock/generated.pcrlock</filename>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>lock-raw</command> <arg choice="opt"><replaceable>FILE</replaceable></arg></term>
+        <term><command>unlock-raw</command></term>
+
+        <listitem><para>Generates/removes a <filename>.pcrlock</filename> file based on raw binary data. The
+        data is either read from the specified file or from STDIN (if none is specified). This requires that
+        <option>--pcrs=</option> is specified. The generated pcrlock file is written to the file specified
+        via <option>--pcrlock=</option> or to STDOUT (if none is specified).</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/>
+        </listitem>
+      </varlistentry>
+
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>The following options are understood:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><option>--raw-description</option></term>
+
+        <listitem><para>When displaying the TPM2 event log do not attempt to decode the records to provide a
+        friendly event log description string. Instead, show the binary payload data in escaped form.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--pcr=</option></term>
+
+        <listitem><para>Specifies the PCR number to use. May be specified more than once to select multiple
+        PCRs.</para>
+
+        <para>This is used by <command>lock-raw</command> and <command>lock-pe</command> to select the
+        PCR to lock against.</para>
+
+        <para>If used with <command>predict</command> and <command>make-policy</command> this will override
+        which PCRs to include in the prediction and policy. If unspecified this defaults to PCRs 0-5, 7,
+        11-15. Note that these commands will not include any PCRs in the prediction/policy (even if specified
+        explicitly) if there are measurements in the event log that do not match the current PCR value, or
+        there are unrecognized measurements in the event log, or components define measurements not seen in
+        the event log.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--nv-index=</option></term>
+
+        <listitem><para>Specifies to NV index to store the policy in. Honoured by
+        <command>make-policy</command>. If not specified the command will automatically pick a free NV
+        index.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--components=</option></term>
+
+        <listitem><para>Takes a path to read <filename>*.pcrlock</filename> and
+        <filename>*.pcrlock.d/*.pcrlock</filename> files from. May be used more than once to specify multiple
+        such directories. If not specified defaults to <filename>/etc/pcrlock.d/</filename>,
+        <filename>/run/pcrlock.d/</filename>, <filename>/var/lib/pcrlock.d/</filename>,
+        <filename>/usr/local/pcrlock.d/</filename>, <filename>/usr/lib/pcrlock.d/</filename>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--location=</option></term>
+
+        <listitem><para>Takes either a string or a colon-separated pair of strings. Configures up to which
+        point in the sorted list of defined components to analyze/predict PCRs to. Typically, the
+        <command>systemd-pcrlock</command> tool is invoked from a fully booted system after boot-up and
+        before shutdown. This means various components that are defined for shutdown have not been measured
+        yet, and should not be searched for. This option allows one to restrict which components are
+        considered for analysis (taking only components before some point into account, ignoring components
+        after them). The expected string is ordered against the filenames of the components defined. Any
+        components with a lexicographically later name are ignored. This logic applies to the
+        <command>log</command>, <command>predict</command>, and <command>make-policy</command> verbs. If a
+        colon-separated pair of strings are specified then they select which phases of the boot to include
+        in the prediction/policy. The first string defines where the first prediction shall be made, and the
+        second string defines where the last prediction shall be made. All such predictions are then combined
+        into one set.</para>
+
+        <para>If used with <command>list-components</command> the selected location range will be highlighted
+        in the component list.</para>
+
+        <para>Defaults to <literal>760-:940-</literal>, which means the policies generated by default will
+        basically cover the whole runtime of the OS userspace, from the initrd (as <literal>760-</literal>
+        closely follows <filename>750-enter-initrd.pcrlock</filename>) until (and including) the main runtime
+        of the system (as <literal>940-</literal> is closely followed by
+        <filename>950-shutdown.pcrlock</filename>). See
+        <citerefentry><refentrytitle>systemd.pcrlock</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for a full list of well-known components, that illustrate where this range is placed by
+        default.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--recovery-pin=</option></term>
+
+        <listitem><para>Takes a boolean. Defaults to false. Honoured by <command>make-policy</command>. If
+        true, will query the user for a PIN to unlock the TPM2 NV index with. If no policy was created before
+        this PIN is used to protect the newly allocated NV index. If a policy has been created before the PIN
+        is used to unlock write access to the NV index. If this option is not used a PIN is automatically
+        generated. Regardless if user supplied or automatically generated, it is stored in encrypted form in
+        the policy metadata file. The recovery PIN may be used to regain write access to an NV index in case
+        the access policy became out of date.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--pcrlock=</option></term>
+
+        <listitem><para>Takes a file system path as argument. If specified overrides where to write the
+        generated pcrlock data to. Honoured by the various <command>lock-*</command> commands. If not
+        specified, a default path is generally used, as documented above.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--policy=</option></term>
+
+        <listitem><para>Takes a file system path as argument. If specified overrides where to write pcrlock
+        policy metadata to. If not specified defaults to
+        <filename>/var/lib/systemd/pcrlock.json</filename>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--force</option></term>
+
+        <listitem><para>If specified with <command>make-policy</command>, the predicted policy will be
+        written to the NV index even if it is detected to be the same as the previously stored
+        one.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+
+      <xi:include href="standard-options.xml" xpointer="json" />
+      <xi:include href="standard-options.xml" xpointer="no-pager" />
+      <xi:include href="standard-options.xml" xpointer="help" />
+      <xi:include href="standard-options.xml" xpointer="version" />
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Exit status</title>
+
+    <para>On success, 0 is returned, a non-zero failure code otherwise.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.pcrlock</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-cryptenroll</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-cryptsetup@.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-repart</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-pcrmachine.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+     </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-pcrphase.service.xml b/man/systemd-pcrphase.service.xml
new file mode 100644
index 0000000..2d711e4
--- /dev/null
+++ b/man/systemd-pcrphase.service.xml
@@ -0,0 +1,245 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd-pcrphase.service" conditional='ENABLE_BOOTLOADER'
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd-pcrphase.service</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-pcrphase.service</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-pcrphase.service</refname>
+    <refname>systemd-pcrphase-sysinit.service</refname>
+    <refname>systemd-pcrphase-initrd.service</refname>
+    <refname>systemd-pcrmachine.service</refname>
+    <refname>systemd-pcrfs-root.service</refname>
+    <refname>systemd-pcrfs@.service</refname>
+    <refname>systemd-pcrextend</refname>
+    <refpurpose>Measure boot phase into TPM2 PCR 11, machine ID and file system identity into PCR 15</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>systemd-pcrphase.service</filename></para>
+    <para><filename>systemd-pcrphase-sysinit.service</filename></para>
+    <para><filename>systemd-pcrphase-initrd.service</filename></para>
+    <para><filename>systemd-pcrmachine.service</filename></para>
+    <para><filename>systemd-pcrfs-root.service</filename></para>
+    <para><filename>systemd-pcrfs@.service</filename></para>
+    <para><filename>/usr/lib/systemd/systemd-pcrextend</filename> <optional><replaceable>STRING</replaceable></optional></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><filename>systemd-pcrphase.service</filename>,
+    <filename>systemd-pcrphase-sysinit.service</filename>, and
+    <filename>systemd-pcrphase-initrd.service</filename> are system services that measure specific strings
+    into TPM2 PCR 11 during boot at various milestones of the boot process.</para>
+
+    <para><filename>systemd-pcrmachine.service</filename> is a system service that measures the machine ID
+    (see <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>) into
+    PCR 15.</para>
+
+    <para><filename>systemd-pcrfs-root.service</filename> and <filename>systemd-pcrfs@.service</filename> are
+    services that measure file system identity information (i.e. mount point, file system type, label and
+    UUID, partition label and UUID) into PCR 15. <filename>systemd-pcrfs-root.service</filename> does so for
+    the root file system, <filename>systemd-pcrfs@.service</filename> is a template unit that measures the
+    file system indicated by its instance identifier instead.</para>
+
+    <para>These services require
+    <citerefentry><refentrytitle>systemd-stub</refentrytitle><manvolnum>7</manvolnum></citerefentry> to be
+    used in a unified kernel image (UKI). They execute no operation when the stub has not been used to invoke
+    the kernel. The stub will measure the invoked kernel and associated vendor resources into PCR 11 before
+    handing control to it; once userspace is invoked these services then will extend TPM2 PCR 11 with certain
+    literal strings indicating phases of the boot process. During a regular boot process PCR 11 is extended
+    with the following strings:</para>
+
+    <orderedlist>
+      <listitem><para><literal>enter-initrd</literal> — early when the initrd initializes, before activating
+      system extension images for the initrd. It acts as a barrier between the time where the kernel
+      initializes and where the initrd starts operating and enables system extension images, i.e. code
+      shipped outside of the UKI. (This extension happens when the
+      <citerefentry><refentrytitle>systemd-pcrphase-initrd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+      service is started.)</para></listitem>
+
+      <listitem><para><literal>leave-initrd</literal> — when the initrd is about to transition into the host
+      file system. It acts as barrier between initrd code and host OS code. (This extension happens when the
+      <filename>systemd-pcrphase-initrd.service</filename> service is stopped.)</para></listitem>
+
+      <listitem><para><literal>sysinit</literal> — when basic system initialization is complete (which
+      includes local file systems having been mounted), and the system begins starting regular system
+      services. (This extension happens when the
+      <citerefentry><refentrytitle>systemd-pcrphase-sysinit.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+      service is started.)</para></listitem>
+
+      <listitem><para><literal>ready</literal> — during later boot-up, after remote file systems have been
+      activated (i.e. after <filename>remote-fs.target</filename>), but before users are permitted to log in
+      (i.e. before <filename>systemd-user-sessions.service</filename>). It acts as barrier between the time
+      where unprivileged regular users are still prohibited to log in and where they are allowed to log in.
+      (This extension happens when the <filename>systemd-pcrphase.service</filename> service is started.)
+      </para></listitem>
+
+      <listitem><para><literal>shutdown</literal> — when the system shutdown begins. It acts as barrier
+      between the time the system is fully up and running and where it is about to shut down. (This extension
+      happens when the <filename>systemd-pcrphase.service</filename> service is stopped.)</para></listitem>
+
+      <listitem><para><literal>final</literal> — at the end of system shutdown. It acts as barrier between
+      the time the service manager still runs and when it transitions into the final shutdown phase where
+      service management is not available anymore. (This extension happens when the
+      <citerefentry><refentrytitle>systemd-pcrphase-sysinit.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+      service is stopped.)</para></listitem>
+    </orderedlist>
+
+    <para>During a regular system lifecycle, PCR 11 is extended with the strings
+    <literal>enter-initrd</literal>, <literal>leave-initrd</literal>, <literal>sysinit</literal>,
+    <literal>ready</literal>, <literal>shutdown</literal>, and <literal>final</literal>.</para>
+
+    <para>Specific phases of the boot process may be referenced via the series of strings measured, separated
+    by colons (the "phase path"). For example, the phase path for the regular system runtime is
+    <literal>enter-initrd:leave-initrd:sysinit:ready</literal>, while the one for the initrd is just
+    <literal>enter-initrd</literal>. The phase path for the boot phase before the initrd is an empty string;
+    because that's hard to pass around a single colon (<literal>:</literal>) may be used instead. Note that
+    the aforementioned six strings are just the default strings and individual systems might measure other
+    strings at other times, and thus implement different and more fine-grained boot phases to bind policy
+    to.</para>
+
+    <para>By binding policy of TPM2 objects to a specific phase path it is possible to restrict access to
+    them to specific phases of the boot process, for example making it impossible to access the root file
+    system's encryption key after the system transitioned from the initrd into the host root file system.
+    </para>
+
+    <para>Use
+    <citerefentry><refentrytitle>systemd-measure</refentrytitle><manvolnum>1</manvolnum></citerefentry> to
+    pre-calculate expected PCR 11 values for specific boot phases (via the <option>--phase=</option> switch).
+    </para>
+
+    <para><filename>systemd-pcrfs-root.service</filename> and <filename>systemd-pcrfs@.service</filename> are
+    automatically pulled into the initial transaction by
+    <citerefentry><refentrytitle>systemd-gpt-auto-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    for the root and <filename>/var/</filename> file
+    systems. <citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    will do this for all mounts with the <option>x-systemd.pcrfs</option> mount option in
+    <filename>/etc/fstab</filename>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>The <filename>/usr/lib/systemd/system-pcrextend</filename> executable may also be invoked from the
+    command line, where it expects the word to extend into PCR 11, as well as the following switches:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><option>--bank=</option></term>
+
+        <listitem><para>Takes the PCR banks to extend the specified word into. If not specified the tool
+        automatically determines all enabled PCR banks and measures the word into all of
+        them.</para>
+
+        <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--pcr=</option></term>
+
+        <listitem><para>Takes the index of the PCR to extend. If <option>--machine-id</option> or
+        <option>--file-system=</option> are specified defaults to 15, otherwise defaults to 11.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--tpm2-device=</option><replaceable>PATH</replaceable></term>
+
+        <listitem><para>Controls which TPM2 device to use. Expects a device node path referring to the TPM2
+        chip (e.g. <filename>/dev/tpmrm0</filename>). Alternatively the special value <literal>auto</literal>
+        may be specified, in order to automatically determine the device node of a suitable TPM2 device (of
+        which there must be exactly one). The special value <literal>list</literal> may be used to enumerate
+        all suitable TPM2 devices currently discovered.</para>
+
+        <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--graceful</option></term>
+
+        <listitem><para>If no TPM2 firmware, kernel subsystem, kernel driver or device support is found, exit
+        with exit status 0 (i.e. indicate success). If this is not specified any attempt to measure without a
+        TPM2 device will cause the invocation to fail.</para>
+
+        <xi:include href="version-info.xml" xpointer="v253"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--machine-id</option></term>
+
+        <listitem><para>Instead of measuring a word specified on the command line into PCR 11, measure the
+        host's machine ID into PCR 15.</para>
+
+        <xi:include href="version-info.xml" xpointer="v253"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--file-system=</option></term>
+
+        <listitem><para>Instead of measuring a word specified on the command line into PCR 11, measure
+        identity information of the specified file system into PCR 15. The parameter must be the path to the
+        established mount point of the file system to measure.</para>
+
+        <xi:include href="version-info.xml" xpointer="v253"/></listitem>
+      </varlistentry>
+
+      <xi:include href="standard-options.xml" xpointer="help" />
+      <xi:include href="standard-options.xml" xpointer="version" />
+
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Files</title>
+
+    <variablelist>
+      <varlistentry>
+        <term><filename>/run/log/systemd/tpm2-measure.log</filename></term>
+
+        <listitem><para>Measurements are logged into an event log file maintained in
+        <filename>/run/log/systemd/tpm2-measure.log</filename>, which contains a <ulink
+        url="https://www.rfc-editor.org/rfc/rfc7464.html">JSON-SEQ</ulink> series of objects that follow the
+        general structure of the <ulink
+        url="https://trustedcomputinggroup.org/resource/canonical-event-log-format/">TCG Common Event Log
+        Format (CEL-JSON)</ulink> event objects (but lack the <literal>recnum</literal>
+        field).</para>
+
+        <para>A <constant>LOCK_EX</constant> BSD file lock (<citerefentry
+        project='man-pages'><refentrytitle>flock</refentrytitle><manvolnum>2</manvolnum></citerefentry>) on
+        the log file is acquired while the measurement is made and the file is updated. Thus, applications
+        that intend to acquire a consistent quote from the TPM with the associated snapshot of the event log
+        should acquire a <constant>LOCK_SH</constant> lock while doing so.</para>
+
+        <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-stub</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-measure</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-gpt-auto-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <ulink url="https://systemd.io/TPM2_PCR_MEASUREMENTS">TPM2 PCR Measurements Made by systemd</ulink>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-portabled.service.xml b/man/systemd-portabled.service.xml
new file mode 100644
index 0000000..cb8cea6
--- /dev/null
+++ b/man/systemd-portabled.service.xml
@@ -0,0 +1,51 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd-portabled.service" conditional='ENABLE_PORTABLED'>
+
+  <refentryinfo>
+    <title>systemd-portabled.service</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-portabled.service</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-portabled.service</refname>
+    <refname>systemd-portabled</refname>
+    <refpurpose>Portable service manager</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>systemd-portabled.service</filename></para>
+    <para><filename>/usr/lib/systemd/systemd-portabled</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>systemd-portabled</command> is a system service that may be used to attach, detach and inspect
+    portable service images.</para>
+
+    <para>Most of <command>systemd-portabled</command>'s functionality is accessible through the
+    <citerefentry><refentrytitle>portablectl</refentrytitle><manvolnum>1</manvolnum></citerefentry> command.</para>
+
+    <para>See the <ulink url="https://systemd.io/PORTABLE_SERVICES">Portable Services</ulink> page
+    for details about the concepts this service implements.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>portablectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>org.freedesktop.portable1</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-poweroff.service.xml b/man/systemd-poweroff.service.xml
new file mode 100644
index 0000000..b430170
--- /dev/null
+++ b/man/systemd-poweroff.service.xml
@@ -0,0 +1,90 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd-poweroff.service">
+
+  <refentryinfo>
+    <title>systemd-poweroff.service</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-poweroff.service</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-poweroff.service</refname>
+    <refname>systemd-halt.service</refname>
+    <refname>systemd-reboot.service</refname>
+    <refname>systemd-kexec.service</refname>
+    <refname>systemd-shutdown</refname>
+    <refpurpose>System shutdown logic</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>systemd-poweroff.service</filename></para>
+    <para><filename>systemd-halt.service</filename></para>
+    <para><filename>systemd-reboot.service</filename></para>
+    <para><filename>systemd-kexec.service</filename></para>
+    <para><filename>/usr/lib/systemd/systemd-shutdown</filename></para>
+    <para><filename>/usr/lib/systemd/system-shutdown/</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><filename>systemd-poweroff.service</filename> is a system service that is pulled in by
+    <filename>poweroff.target</filename> and is responsible for the actual system power-off
+    operation. Similarly, <filename>systemd-halt.service</filename> is pulled in by
+    <filename>halt.target</filename>, <filename>systemd-reboot.service</filename> by
+    <filename>reboot.target</filename> and <filename>systemd-kexec.service</filename> by
+    <filename>kexec.target</filename> to execute the respective actions.</para>
+
+    <para>When these services are run, they ensure that PID 1 is replaced by the
+    <filename>/usr/lib/systemd/systemd-shutdown</filename> tool which is then responsible for the actual
+    shutdown. Before shutting down, this binary will try to unmount all remaining file systems (or at least
+    remount them read-only), disable all remaining swap devices, detach all remaining storage devices and
+    kill all remaining processes.</para>
+
+    <para>It is necessary to have this code in a separate binary because otherwise rebooting after an upgrade
+    might be broken — the running PID 1 could still depend on libraries which are not available any more,
+    thus keeping the file system busy, which then cannot be re-mounted read-only.</para>
+
+    <para>Shortly before executing the actual system power-off/halt/reboot/kexec
+    <filename>systemd-shutdown</filename> will run all executables in
+    <filename>/usr/lib/systemd/system-shutdown/</filename> and pass one arguments to them: either
+    <literal>poweroff</literal>, <literal>halt</literal>, <literal>reboot</literal>, or
+    <literal>kexec</literal>, depending on the chosen action. All executables in this directory are executed
+    in parallel, and execution of the action is not continued before all executables finished. Note that
+    these executables are run <emphasis>after</emphasis> all services have been shut down, and after most
+    mounts have been detached (the root file system as well as <filename>/run/</filename> and various API
+    file systems are still around though). This means any programs dropped into this directory must be
+    prepared to run in such a limited execution environment and not rely on external services or hierarchies
+    such as <filename>/var/</filename> to be around (or writable).</para>
+
+    <para>Note that <filename>systemd-poweroff.service</filename> (and the related units) should never be
+    executed directly. Instead, trigger system shutdown with a command such as <literal>systemctl
+    poweroff</literal>.</para>
+
+    <para>Another form of shutdown is provided by the
+    <citerefentry><refentrytitle>systemd-soft-reboot.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    functionality. It reboots only the OS userspace, leaving the kernel, firmware, and hardware as it is.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>reboot</refentrytitle><manvolnum>2</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-suspend.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-soft-reboot.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>bootup</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-pstore.service.xml b/man/systemd-pstore.service.xml
new file mode 100644
index 0000000..66ad557
--- /dev/null
+++ b/man/systemd-pstore.service.xml
@@ -0,0 +1,114 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd-pstore" conditional='ENABLE_PSTORE'
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd-pstore.service</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-pstore.service</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-pstore.service</refname>
+    <refname>systemd-pstore</refname>
+    <refpurpose>A service to archive contents of pstore</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>/usr/lib/systemd/systemd-pstore</filename></para>
+    <para><filename>systemd-pstore.service</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+    <para><filename>systemd-pstore.service</filename> is a system service that archives the
+    contents of the Linux persistent storage filesystem, pstore, to other storage,
+    thus preserving the existing information contained in the pstore, and clearing
+    pstore storage for future error events.</para>
+
+    <para>Linux provides a persistent storage file system, pstore, that can store error records when the
+    kernel dies (or reboots or powers-off). These records in turn can be referenced to debug kernel problems
+    (currently the kernel stores the tail of the kernel log, which also contains a stack backtrace, into
+    pstore).</para>
+
+    <para>The pstore file system supports a variety of backends that map onto persistent
+    storage, such as the ACPI ERST and UEFI variables. The pstore backends
+    typically offer a relatively small amount of persistent storage, e.g. 64KiB,
+    which can quickly fill up and thus prevent subsequent kernel crashes from
+    recording errors. Thus there is a need to monitor and extract the pstore
+    contents so that future kernel problems can also record information in the
+    pstore.</para>
+
+    <para>The pstore service is independent of the kdump service. In cloud environments
+    specifically, host and guest filesystems are on remote filesystems (e.g. iSCSI
+    or NFS), thus kdump relies (implicitly and/or explicitly) upon proper operation
+    of networking software *and* hardware *and* infrastructure. Thus it may not be
+    possible to capture a kernel coredump to a file since writes over the network
+    may not be possible.</para>
+
+    <para>The pstore backend, on the other hand, is completely local and provides a path
+    to store error records which will survive a reboot and aid in post-mortem
+    debugging.</para>
+
+    <para>The <command>systemd-pstore</command> executable does the actual work. Upon starting,
+    the <filename>pstore.conf</filename> file is read and the <filename>/sys/fs/pstore/</filename>
+    directory contents are processed according to the options. Pstore files are written to the
+    journal, and optionally saved into <filename>/var/lib/systemd/pstore/</filename>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Configuration</title>
+
+    <para>The behavior of <command>systemd-pstore</command> is configured through the configuration file
+    <filename>/etc/systemd/pstore.conf</filename> and corresponding snippets
+    <filename>/etc/systemd/pstore.conf.d/*.conf</filename>, see
+    <citerefentry><refentrytitle>pstore.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+    </para>
+
+    <refsect2>
+      <title>Disabling pstore processing</title>
+
+      <para>To disable pstore processing by <command>systemd-pstore</command>,
+      set <programlisting>Storage=none</programlisting> in
+      <citerefentry><refentrytitle>pstore.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+      </para>
+    </refsect2>
+
+    <refsect2>
+      <title>Kernel parameters</title>
+
+      <para> The kernel has two parameters,
+      <filename>/sys/module/kernel/parameters/crash_kexec_post_notifiers</filename> and
+      <filename>/sys/module/printk/parameters/always_kmsg_dump</filename>, that control writes into pstore.
+      The first enables storing of the kernel log (including stack trace) into pstore upon a panic or crash,
+      and the second enables storing of the kernel log upon a normal shutdown (shutdown, reboot, halt). These
+      parameters can be managed via the
+      <citerefentry><refentrytitle>tmpfiles.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+      mechanism, specifically the file <filename>/usr/lib/tmpfiles/systemd-pstore.conf</filename>.
+      </para>
+    </refsect2>
+
+  </refsect1>
+
+  <refsect1>
+    <title>Usage</title>
+    <para>Data stored in the journal can be viewed with
+    <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    as usual.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>pstore.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+</refentry>
diff --git a/man/systemd-quotacheck.service.xml b/man/systemd-quotacheck.service.xml
new file mode 100644
index 0000000..7d9ff0e
--- /dev/null
+++ b/man/systemd-quotacheck.service.xml
@@ -0,0 +1,72 @@
+<?xml version="1.0"?>
+<!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+<refentry id="systemd-quotacheck.service" conditional='ENABLE_QUOTACHECK'
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd-quotacheck.service</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-quotacheck.service</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-quotacheck.service</refname>
+    <refname>systemd-quotacheck</refname>
+    <refpurpose>File system quota checker logic</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>systemd-quotacheck.service</filename></para>
+    <para><filename>/usr/lib/systemd/systemd-quotacheck</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><filename>systemd-quotacheck.service</filename> is a service
+    responsible for file system quota checks. It is run once at boot
+    after all necessary file systems are mounted. It is pulled in only
+    if at least one file system has quotas enabled.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Kernel Command Line</title>
+
+    <para><filename>systemd-quotacheck</filename> understands one
+    kernel command line parameter:</para>
+
+    <variablelist class='kernel-commandline-options'>
+      <varlistentry>
+        <term><varname>quotacheck.mode=</varname></term>
+
+        <listitem><para>One of <literal>auto</literal>,
+        <literal>force</literal>, <literal>skip</literal>. Controls
+        the mode of operation. The default is <literal>auto</literal>,
+        and ensures that file system quota checks are done when the
+        file system quota checker deems them necessary.
+        <literal>force</literal> unconditionally results in full file
+        system quota checks. <literal>skip</literal> skips any file
+        system quota checks.</para>
+
+        <xi:include href="version-info.xml" xpointer="v186"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry project='die-net'><refentrytitle>quotacheck</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-fsck@.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-random-seed.service.xml b/man/systemd-random-seed.service.xml
new file mode 100644
index 0000000..48928ed
--- /dev/null
+++ b/man/systemd-random-seed.service.xml
@@ -0,0 +1,98 @@
+<?xml version="1.0"?>
+<!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+<refentry id="systemd-random-seed.service" conditional='ENABLE_RANDOMSEED'
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd-random-seed.service</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-random-seed.service</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-random-seed.service</refname>
+    <refname>systemd-random-seed</refname>
+    <refpurpose>Load and save the OS system random seed at boot and shutdown</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>systemd-random-seed.service</filename></para>
+    <para><filename>/usr/lib/systemd/systemd-random-seed</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><filename>systemd-random-seed.service</filename> is a service that loads an on-disk random seed
+    into the kernel entropy pool during boot and saves it at shutdown. See
+    <citerefentry><refentrytitle>random</refentrytitle><manvolnum>4</manvolnum></citerefentry> for
+    details. By default, no entropy is credited when the random seed is written into the kernel entropy pool,
+    but this may be changed with <varname>$SYSTEMD_RANDOM_SEED_CREDIT</varname>, see below. On disk the random
+    seed is stored in <filename>/var/lib/systemd/random-seed</filename>.</para>
+
+    <para>Note that this service runs relatively late during the early boot phase, i.e. generally after the
+    initrd phase has finished and the <filename>/var/</filename> file system has been mounted. Many system
+    services require entropy much earlier than this — this service is hence of limited use for complex
+    system. It is recommended to use a boot loader that can pass an initial random seed to the kernel to
+    ensure that entropy is available from earliest boot on, for example
+    <citerefentry><refentrytitle>systemd-boot</refentrytitle><manvolnum>7</manvolnum></citerefentry>, with
+    its <command>bootctl random-seed</command> functionality.</para>
+
+    <para>When loading the random seed from disk, the file is immediately updated with a new seed retrieved
+    from the kernel, in order to ensure no two boots operate with the same random seed. This new seed is
+    retrieved synchronously from the kernel, which means the service will not complete start-up until the
+    random pool is fully initialized. On entropy-starved systems this may take a while. This functionality is
+    intended to be used as synchronization point for ordering services that require an initialized entropy
+    pool to function securely (i.e. services that access <filename>/dev/urandom</filename> without any
+    further precautions).</para>
+
+    <para>Care should be taken when creating OS images that are replicated to multiple systems: if the random
+    seed file is included unmodified each system will initialize its entropy pool with the same data, and
+    thus — if otherwise entropy-starved — generate the same or at least guessable random seed streams. As a
+    safety precaution crediting entropy is thus disabled by default. It is recommended to remove the random
+    seed from OS images intended for replication on multiple systems, in which case it is safe to enable
+    entropy crediting, see below. Also see <ulink url="https://systemd.io/BUILDING_IMAGES">Safely Building
+    Images</ulink>.</para>
+
+    <para>See <ulink url="https://systemd.io/RANDOM_SEEDS">Random Seeds</ulink> for further
+    information.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Environment</title>
+
+    <variablelist class='environment-variables'>
+      <varlistentry>
+        <term><varname>$SYSTEMD_RANDOM_SEED_CREDIT</varname></term>
+        <listitem><para>By default, <filename>systemd-random-seed.service</filename> does not credit any
+        entropy when loading the random seed. With this option this behaviour may be changed: it either takes
+        a boolean parameter or the special string <literal>force</literal>. Defaults to false, in which case
+        no entropy is credited. If true, entropy is credited if the random seed file and system state pass
+        various superficial concisistency checks. If set to <literal>force</literal> entropy is credited,
+        regardless of these checks, as long as the random seed file exists.</para>
+
+        <xi:include href="version-info.xml" xpointer="v243"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>random</refentrytitle><manvolnum>4</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-boot</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-stub</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>bootctl</refentrytitle><manvolnum>4</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-boot-random-seed.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-rc-local-generator.xml b/man/systemd-rc-local-generator.xml
new file mode 100644
index 0000000..f0e38ea
--- /dev/null
+++ b/man/systemd-rc-local-generator.xml
@@ -0,0 +1,72 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [
+<!ENTITY % entities SYSTEM "custom-entities.ent" >
+%entities;
+]>
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd-rc-local-generator" conditional='HAVE_SYSV_COMPAT'>
+  <refentryinfo>
+    <title>systemd-rc-local-generator</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-rc-local-generator</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-rc-local-generator</refname>
+    <refname>rc-local.service</refname>
+    <refpurpose>Compatibility generator and service to start <filename>&RC_LOCAL_PATH;</filename> during boot</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>/usr/lib/systemd/system-generators/systemd-rc-local-generator</filename></para>
+    <para><filename>rc-local.service</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>systemd-rc-local-generator</command> is a generator that checks whether
+    <filename>&RC_LOCAL_PATH;</filename> exists and is executable, and if it is, pulls the
+    <filename>rc-local.service</filename> unit into the boot process. This unit is responsible for running
+    this script during late boot. The script is run after <filename>network.target</filename>, but in
+    parallel with most other regular system services.</para>
+
+    <para>Note that <filename>rc-local.service</filename> runs with slightly different semantics than the
+    original System V version, which was executed "last" in the boot process, which is a concept that does
+    not translate to systemd.</para>
+
+    <para>Also note that <filename>rc-local.service</filename> is ordered after
+    <filename>network.target</filename>, which does not mean that the network is functional, see
+    <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
+    If the script requires a configured network connection, it may be desirable to pull in and order it after
+    <filename>network-online.target</filename> with a drop-in:</para>
+
+    <programlisting># /etc/systemd/system/rc-local.service.d/network.conf
+[Unit]
+Wants=network-online.target
+After=network-online.target
+</programlisting>
+
+    <para>Support for <filename>&RC_LOCAL_PATH;</filename> is provided for compatibility with specific System
+    V systems only. However, it is strongly recommended to avoid making use of this script today, and instead
+    provide proper unit files with appropriate dependencies for any scripts to run during the boot process.
+    Note that the path to the script is set at compile time and varies between distributions.</para>
+
+    <para><filename>systemd-rc-local-generator</filename> implements
+    <citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+</refentry>
diff --git a/man/systemd-remount-fs.service.xml b/man/systemd-remount-fs.service.xml
new file mode 100644
index 0000000..266db88
--- /dev/null
+++ b/man/systemd-remount-fs.service.xml
@@ -0,0 +1,70 @@
+<?xml version="1.0"?>
+<!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+<refentry id="systemd-remount-fs.service">
+
+  <refentryinfo>
+    <title>systemd-remount-fs.service</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-remount-fs.service</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-remount-fs.service</refname>
+    <refname>systemd-remount-fs</refname>
+    <refpurpose>Remount root and kernel file systems</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>systemd-remount-fs.service</filename></para>
+    <para><filename>/usr/lib/systemd/systemd-remount-fs</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><filename>systemd-remount-fs.service</filename> is an early boot service that applies mount options
+    listed in <citerefentry
+    project='man-pages'><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry>, or
+    gathered from the partition table (when
+    <citerefentry><refentrytitle>systemd-gpt-auto-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    is active) to the root file system, the <filename>/usr/</filename> file system, and the kernel API file
+    systems. This is required so that the mount options of these file systems — which are pre-mounted by the
+    kernel, the initrd, container environments or system manager code — are updated to those
+    configured in <filename>/etc/fstab</filename> and the other sources. This service ignores normal file
+    systems and only changes the root file system (i.e.  <filename>/</filename>), <filename>/usr/</filename>,
+    and the virtual kernel API file systems such as <filename>/proc/</filename>, <filename>/sys/</filename> or
+    <filename>/dev/</filename>. This service executes no operation if no configuration is found
+    (<filename>/etc/fstab</filename> does not exist or lists no entries for the mentioned file systems, or
+    the partition table does not contain relevant entries).</para>
+
+    <para>For a longer discussion of kernel API file systems see
+    <ulink url="https://www.freedesktop.org/wiki/Software/systemd/APIFileSystems">API
+    File Systems</ulink>.</para>
+
+    <para>Note: <filename>systemd-remount-fs.service</filename> is usually pulled in by
+    <citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+    hence it is also affected by the kernel command line option <varname>fstab=</varname>, which may be used
+    to disable the generator. It may also pulled in by
+    <citerefentry><refentrytitle>systemd-gpt-auto-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+    which is affected by <varname>systemd.gpt_auto</varname> and other options.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>mount</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-gpt-auto-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-repart.xml b/man/systemd-repart.xml
new file mode 100644
index 0000000..5cd4c1c
--- /dev/null
+++ b/man/systemd-repart.xml
@@ -0,0 +1,633 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd-repart" conditional='ENABLE_REPART'
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd-repart</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-repart</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-repart</refname>
+    <refname>systemd-repart.service</refname>
+    <refpurpose>Automatically grow and add partitions</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <cmdsynopsis>
+      <command>systemd-repart</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="opt" rep="repeat"><replaceable><optional>BLOCKDEVICE</optional></replaceable></arg>
+    </cmdsynopsis>
+
+    <para><filename>systemd-repart.service</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>systemd-repart</command> grows and adds partitions to a partition table, based on the
+    configuration files described in
+    <citerefentry><refentrytitle>repart.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+    </para>
+
+    <para>If invoked with no arguments, it operates on the block device backing the root file system
+    partition of the running OS, thus growing and adding partitions of the booted OS image itself. If
+    <varname>--image=</varname> is used it will operate on the specified image file. When called in the
+    initrd it operates on the block device backing <filename>/sysroot/</filename> instead, i.e. on the block
+    device the system will soon transition into. The <filename>systemd-repart.service</filename> service is
+    generally run at boot in the initrd, in order to augment the partition table of the OS before its
+    partitions are mounted. <command>systemd-repart</command> (mostly) operates in a purely incremental mode:
+    it only grows existing and adds new partitions; it does not shrink, delete or move existing partitions.
+    The service is intended to be run on every boot, but when it detects that the partition table already
+    matches the installed <filename>repart.d/*.conf</filename> configuration files, it executes no
+    operation.</para>
+
+    <para><command>systemd-repart</command> is intended to be used when deploying OS images, to automatically
+    adjust them to the system they are running on, during first boot. This way the deployed image can be
+    minimal in size and may be augmented automatically at boot when needed, taking possession of disk space
+    available but not yet used. Specifically the following use cases are among those covered:</para>
+
+    <itemizedlist>
+      <listitem><para>The root partition may be grown to cover the whole available disk space.</para></listitem>
+      <listitem><para>A <filename>/home/</filename>, swap or <filename>/srv/</filename> partition can be
+      added.</para></listitem>
+      <listitem><para>A second (or third, …) root partition may be added, to cover A/B style setups
+      where a second version of the root file system is alternatingly used for implementing update
+      schemes. The deployed image would carry only a single partition ("A") but on first boot a second
+      partition ("B") for this purpose is automatically created.</para></listitem>
+    </itemizedlist>
+
+    <para>The algorithm executed by <command>systemd-repart</command> is roughly as follows:</para>
+
+    <orderedlist>
+      <listitem><para>The <filename>repart.d/*.conf</filename> configuration files are loaded and parsed,
+      and ordered by filename (without the directory prefix). For each configuration file,
+      drop-in files are looked for in directories with same name as the configuration file
+      with a suffix ".d" added.</para></listitem>
+
+      <listitem><para>The partition table already existing on the block device is loaded and
+      parsed.</para></listitem>
+
+      <listitem><para>The existing partitions in the partition table are matched up with the
+      <filename>repart.d/*.conf</filename> files by GPT partition type UUID. The first existing partition
+      of a specific type is assigned the first configuration file declaring the same type. The second
+      existing partition of a specific type is then assigned the second configuration file declaring the same
+      type, and so on. After this iterative assigning is complete any left-over existing partitions that have
+      no matching configuration file are considered "foreign" and left as they are. And any configuration
+      files for which no partition currently exists are understood as a request to create such a partition.
+      </para></listitem>
+
+      <listitem><para>Partitions that shall be created are now allocated on the disk, taking the size
+      constraints and weights declared in the configuration files into account. Free space is used within the
+      limits set by size and padding requests. In addition, existing partitions that should be grown are
+      grown. New partitions are always appended to the end of the partition table, taking the first partition
+      table slot whose index is greater than the indexes of all existing partitions. Partitions are never
+      reordered and thus partition numbers remain stable. When partitions are created, they are placed in the
+      smallest area of free space that is large enough to satisfy the size and padding limits. This means
+      that partitions might have different order on disk than in the partition table. Note that this
+      allocation happens in memory only, the partition table on disk is not updated yet.</para></listitem>
+
+      <listitem><para>All existing partitions for which configuration files exist and which currently have no
+      GPT partition label set will be assigned a label, either explicitly configured in the configuration or
+      — if that's missing — derived automatically from the partition type. The same is done for all
+      partitions that are newly created. These assignments are done in memory only, too, the disk is not
+      updated yet.</para></listitem>
+
+      <listitem><para>Similarly, all existing partitions for which configuration files exist and which
+      currently have an all-zero identifying UUID will be assigned a new UUID. This UUID is cryptographically
+      hashed from a common seed value together with the partition type UUID (and a counter in case multiple
+      partitions of the same type are defined), see below. The same is done for all partitions that are
+      created anew. These assignments are done in memory only, too, the disk is not updated yet.
+      </para></listitem>
+
+      <listitem><para>Similarly, if the disk's volume UUID is all zeroes it is also initialized, also
+      cryptographically hashed from the same common seed value. This is done in memory only too.
+      </para></listitem>
+
+      <listitem><para>The disk space assigned to new partitions (i.e. what was previously free space) is now
+      erased. Specifically, all file system signatures are removed, and if the device supports it, the
+      <constant>BLKDISCARD</constant> I/O control command is issued to inform the hardware that the space is
+      now empty. In addition any "padding" between partitions and at the end of the device is similarly
+      erased.</para></listitem>
+
+      <listitem><para>The new partition table is finally written to disk. The kernel is asked to reread the
+      partition table.</para></listitem>
+    </orderedlist>
+
+    <para>As exception to the normally strictly incremental operation, when called in a special "factory
+    reset" mode, <command>systemd-repart</command> may also be used to erase existing partitions to
+    reset an installation back to vendor defaults. This mode of operation is used when either the
+    <option>--factory-reset=yes</option> switch is passed on the tool's command line, or the
+    <option>systemd.factory_reset=yes</option> option specified on the kernel command line, or the
+    <varname>FactoryReset</varname> EFI variable (vendor UUID
+    <constant>8cf2644b-4b0b-428f-9387-6d876050dc67</constant>) is set to "yes". It alters the algorithm above
+    slightly: between the 3rd and the 4th step above any partition marked explicitly via the
+    <varname>FactoryReset=</varname> boolean is deleted, and the algorithm restarted, thus immediately
+    re-creating these partitions anew empty.</para>
+
+    <para>Note that <command>systemd-repart</command> by default only changes partition tables, it does not
+    create or resize any file systems within these partitions, unless the <varname>Format=</varname>
+    configuration option is specified. Also note that there are also separate mechanisms available for this
+    purpose, for example
+    <citerefentry><refentrytitle>systemd-growfs</refentrytitle><manvolnum>8</manvolnum></citerefentry> and
+    <command>systemd-makefs</command>.</para>
+
+    <para>The UUIDs identifying the new partitions created (or assigned to existing partitions that have no
+    UUID yet), as well as the disk as a whole are hashed cryptographically from a common seed value. This
+    seed value is usually the
+    <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry> of the
+    system, so that the machine ID reproducibly determines the UUIDs assigned to all partitions. If the
+    machine ID cannot be read (or the user passes <option>--seed=random</option>, see below) the seed is
+    generated randomly instead, so that the partition UUIDs are also effectively random. The seed value may
+    also be set explicitly, formatted as UUID via the <option>--seed=</option> option. By hashing these UUIDs
+    from a common seed images prepared with this tool become reproducible and the result of the algorithm
+    above deterministic.</para>
+
+    <para>The positional argument should specify the block device to operate on. Instead of a block device
+    node path a regular file may be specified too, in which case the command operates on it like it would if
+    a loopback block device node was specified with the file attached. If <option>--empty=create</option> is
+    specified the specified path is created as regular file, which is useful for generating disk images from
+    scratch.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>The following options are understood:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><option>--dry-run=</option></term>
+        <listitem><para>Takes a boolean. If this switch is not specified <option>--dry-run=yes</option> is
+        the implied default. Controls whether <filename>systemd-repart</filename> executes the requested
+        re-partition operations or whether it should only show what it would do. Unless
+        <option>--dry-run=no</option> is specified <filename>systemd-repart</filename> will not actually
+        touch the device's partition table.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--empty=</option></term>
+        <listitem><para>Takes one of <literal>refuse</literal>, <literal>allow</literal>,
+        <literal>require</literal>, <literal>force</literal> or <literal>create</literal>. Controls how to
+        operate on block devices that are entirely empty, i.e. carry no partition table/disk label yet. If
+        this switch is not specified the implied default is <literal>refuse</literal>.</para>
+
+        <para>If <literal>refuse</literal> <command>systemd-repart</command> requires that the block device
+        it shall operate on already carries a partition table and refuses operation if none is found. If
+        <literal>allow</literal> the command will extend an existing partition table or create a new one if
+        none exists. If <literal>require</literal> the command will create a new partition table if none
+        exists so far, and refuse operation if one already exists. If <literal>force</literal> it will create
+        a fresh partition table unconditionally, erasing the disk fully in effect. If
+        <literal>force</literal> no existing partitions will be taken into account or survive the
+        operation. Hence: use with care, this is a great way to lose all your data. If
+        <literal>create</literal> a new loopback file is create under the path passed via the device node
+        parameter, of the size indicated with <option>--size=</option>, see below.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--discard=</option></term>
+
+        <listitem><para>Takes a boolean. If this switch is not specified <option>--discard=yes</option> is
+        the implied default. Controls whether to issue the <constant>BLKDISCARD</constant> I/O control
+        command on the space taken up by any added partitions or on the space in between them. Usually, it's
+        a good idea to issue this request since it tells the underlying hardware that the covered blocks
+        shall be considered empty, improving performance. If operating on a regular file instead of a block
+        device node, a sparse file is generated.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--size=</option></term>
+
+        <listitem><para>Takes a size in bytes, using the usual K, M, G, T suffixes, or the special value
+        <literal>auto</literal>. If used the specified device node path must refer to a regular file, which
+        is then grown to the specified size if smaller, before any change is made to the partition table. If
+        specified as <literal>auto</literal> the minimal size for the disk image is automatically determined
+        (i.e. the minimal sizes of all partitions are summed up, taking space for additional metadata into
+        account). This switch is not supported if the specified node is a block device. This switch has no
+        effect if the file is already as large as the specified size or larger. The specified size is
+        implicitly rounded up to multiples of 4096. When used with <option>--empty=create</option> this
+        specifies the initial size of the loopback file to create.</para>
+
+        <para>The <option>--size=auto</option> option takes the sizes of pre-existing partitions into
+        account. However, it does not accommodate for partition tables that are not tightly packed: the
+        configured partitions might still not fit into the backing device if empty space exists between
+        pre-existing partitions (or before the first partition) that cannot be fully filled by partitions to
+        grow or create.</para>
+
+        <para>Also note that the automatic size determination does not take files or directories specified
+        with <option>CopyFiles=</option> into account: operation might fail if the specified files or
+        directories require more disk space then the configured per-partition minimal size
+        limit.</para>
+
+        <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--factory-reset=</option></term>
+
+        <listitem><para>Takes boolean. If this switch is not specified <option>--factory=reset=no</option> is
+        the implied default. Controls whether to operate in "factory reset" mode, see above. If set to true
+        this will remove all existing partitions marked with <varname>FactoryReset=</varname> set to yes
+        early while executing the re-partitioning algorithm. Use with care, this is a great way to lose all
+        your data. Note that partition files need to explicitly turn <varname>FactoryReset=</varname> on, as
+        the option defaults to off. If no partitions are marked for factory reset this switch has no
+        effect. Note that there are two other methods to request factory reset operation: via the kernel
+        command line and via an EFI variable, see above.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--can-factory-reset</option></term>
+
+        <listitem><para>If this switch is specified the disk is not re-partitioned. Instead it is determined
+        if any existing partitions are marked with <varname>FactoryReset=</varname>. If there are the tool
+        will exit with exit status zero, otherwise non-zero. This switch may be used to quickly determine
+        whether the running system supports a factory reset mechanism built on
+        <command>systemd-repart</command>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--root=</option></term>
+
+        <listitem><para>Takes a path to a directory to use as root file system when searching for
+        <filename>repart.d/*.conf</filename> files, for the machine ID file to use as seed and for the
+        <varname>CopyFiles=</varname> and <varname>CopyBlocks=</varname> source files and directories. By
+        default when invoked on the regular system this defaults to the host's root file system
+        <filename>/</filename>. If invoked from the initrd this defaults to <filename>/sysroot/</filename>,
+        so that the tool operates on the configuration and machine ID stored in the root file system later
+        transitioned into itself.</para>
+
+        <para>See <option>--copy-source=</option> for a more restricted option that only affects
+        <varname>CopyFiles=</varname>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--image=</option></term>
+
+        <listitem><para>Takes a path to a disk image file or device to mount and use in a similar fashion to
+        <option>--root=</option>, see above.</para>
+
+        <xi:include href="version-info.xml" xpointer="v249"/></listitem>
+      </varlistentry>
+
+      <xi:include href="standard-options.xml" xpointer="image-policy-open" />
+
+      <varlistentry>
+        <term><option>--seed=</option></term>
+
+        <listitem><para>Takes a UUID as argument or the special value <constant>random</constant>. If a UUID
+        is specified the UUIDs to assign to partitions and the partition table itself are derived via
+        cryptographic hashing from it. If not specified it is attempted to read the machine ID from the host
+        (or more precisely, the root directory configured via <option>--root=</option>) and use it as seed
+        instead, falling back to a randomized seed otherwise. Use <option>--seed=random</option> to force a
+        randomized seed. Explicitly specifying the seed may be used to generated strictly reproducible
+        partition tables.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--pretty=</option></term>
+
+        <listitem><para>Takes a boolean argument. If this switch is not specified, it defaults to on when
+        called from an interactive terminal and off otherwise. Controls whether to show a user friendly table
+        and graphic illustrating the changes applied.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--definitions=</option></term>
+
+        <listitem><para>Takes a file system path. If specified the <filename>*.conf</filename> files are read
+        from the specified directory instead of searching in <filename>/usr/lib/repart.d/*.conf</filename>,
+        <filename>/etc/repart.d/*.conf</filename>,
+        <filename>/run/repart.d/*.conf</filename>.</para>
+
+        <para>This parameter can be specified multiple times.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--key-file=</option></term>
+
+        <listitem><para>Takes a file system path. Configures the encryption key to use when setting up LUKS2
+        volumes configured with the <varname>Encrypt=key-file</varname> setting in partition files. Should
+        refer to a regular file containing the key, or an <constant>AF_UNIX</constant> stream socket in the
+        file system. In the latter case a connection is made to it and the key read from it. If this switch
+        is not specified the empty key (i.e. zero length key) is used. This behaviour is useful for setting
+        up encrypted partitions during early first boot that receive their user-supplied password only in a
+        later setup step.</para>
+
+        <xi:include href="version-info.xml" xpointer="v247"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--private-key=</option></term>
+
+        <listitem><para>Takes a file system path. Configures the signing key to use when creating verity
+        signature partitions with the <varname>Verity=signature</varname> setting in partition files.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--certificate=</option></term>
+
+        <listitem><para>Takes a file system path. Configures the PEM encoded X.509 certificate to use when
+        creating verity signature partitions with the <varname>Verity=signature</varname> setting in
+        partition files.</para>
+
+        <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--tpm2-device=</option></term>
+        <term><option>--tpm2-pcrs=</option></term>
+
+        <listitem><para>Configures the TPM2 device and list of PCRs to use for LUKS2 volumes configured with
+        the <varname>Encrypt=tpm2</varname> option. These options take the same parameters as the identically
+        named options to
+        <citerefentry><refentrytitle>systemd-cryptenroll</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+        and have the same effect on partitions where TPM2 enrollment is requested.</para>
+
+        <xi:include href="version-info.xml" xpointer="v248"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--tpm2-device-key=</option><arg>PATH</arg></term>
+        <term><option>--tpm2-seal-key-handle=</option><arg>HANDLE</arg></term>
+
+        <listitem><para>Configures a TPM2 SRK key to bind encryption to. See
+        <citerefentry><refentrytitle>systemd-cryptenroll</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+        for details on this option.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--tpm2-public-key=</option><arg>PATH</arg></term>
+        <term><option>--tpm2-public-key-pcrs=</option><arg rep="repeat">PCR</arg></term>
+
+        <listitem><para>Configures a TPM2 signed PCR policy to bind encryption to. See
+        <citerefentry><refentrytitle>systemd-cryptenroll</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+        for details on these two options.</para>
+
+        <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--tpm2-pcrlock=</option><arg>PATH</arg></term>
+
+        <listitem><para>Configures a TPM2 pcrlock policy to bind encryption to. See
+        <citerefentry><refentrytitle>systemd-cryptenroll</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+        for details on this option.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--split=</option><arg>BOOL</arg></term>
+
+        <listitem><para>Enables generation of split artifacts from partitions configured with
+        <varname>SplitName=</varname>. If enabled, for each partition with <varname>SplitName=</varname> set,
+        a separate output file containing just the contents of that partition is generated. The output
+        filename consists of the loopback filename suffixed with the name configured with
+        <varname>SplitName=</varname>. If the loopback filename ends with <literal>.raw</literal>, the suffix
+        is inserted before the <literal>.raw</literal> extension instead.</para>
+
+        <para>Note that <option>--split</option> is independent from <option>--dry-run</option>. Even if
+        <option>--dry-run</option> is enabled, split artifacts will still be generated from an existing image
+        if <option>--split</option> is enabled.</para>
+
+        <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--include-partitions=</option><arg rep="repeat">PARTITION</arg></term>
+        <term><option>--exclude-partitions=</option><arg rep="repeat">PARTITION</arg></term>
+
+        <listitem><para>These options specify which partition types <command>systemd-repart</command> should
+        operate on. If <option>--include-partitions=</option> is used, all partitions that aren't specified
+        are excluded. If <option>--exclude-partitions=</option> is used, all partitions that are specified
+        are excluded. Both options take a comma separated list of GPT partition type UUIDs or identifiers
+        (see <varname>Type=</varname> in
+        <citerefentry><refentrytitle>repart.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v253"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--defer-partitions=</option><arg rep="repeat">PARTITION</arg></term>
+
+        <listitem><para>This option specifies for which partition types <command>systemd-repart</command>
+        should defer. All partitions that are deferred using this option are still taken into account when
+        calculating the sizes and offsets of other partitions, but aren't actually written to the disk image.
+        The net effect of this option is that if you run <command>systemd-repart</command> again without this
+        option, the missing partitions will be added as if they had not been deferred the first time
+        <command>systemd-repart</command> was executed.</para>
+
+        <xi:include href="version-info.xml" xpointer="v253"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--sector-size=</option><arg>BYTES</arg></term>
+
+        <listitem><para>This option allows configuring the sector size of the image produced by
+        <command>systemd-repart</command>. It takes a value that is a power of <literal>2</literal> between
+        <literal>512</literal> and <literal>4096</literal>. This option is useful when building images for
+        disks that use a different sector size as the disk on which the image is produced.</para>
+
+        <xi:include href="version-info.xml" xpointer="v253"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--architecture=</option><arg>ARCH</arg></term>
+
+        <listitem><para>This option allows overriding the architecture used for architecture specific
+        partition types. For example, if set to <literal>arm64</literal> a partition type of
+        <literal>root-x86-64</literal> referenced in <filename>repart.d/</filename> drop-ins will be patched
+        dynamically to refer to <literal>root-arm64</literal> instead. Takes one of
+        <literal>alpha</literal>,
+        <literal>arc</literal>,
+        <literal>arm</literal>,
+        <literal>arm64</literal>,
+        <literal>ia64</literal>,
+        <literal>loongarch64</literal>,
+        <literal>mips-le</literal>,
+        <literal>mips64-le</literal>,
+        <literal>parisc</literal>,
+        <literal>ppc</literal>,
+        <literal>ppc64</literal>,
+        <literal>ppc64-le</literal>,
+        <literal>riscv32</literal>,
+        <literal>riscv64</literal>,
+        <literal>s390</literal>,
+        <literal>s390x</literal>,
+        <literal>tilegx</literal>,
+        <literal>x86</literal> or
+        <literal>x86-64</literal>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--offline=</option><arg>BOOL</arg></term>
+
+        <listitem><para>Instructs <command>systemd-repart</command> to build the image offline. Takes a
+        boolean or <literal>auto</literal>. Defaults to <literal>auto</literal>. If enabled, the image is
+        built without using loop devices. This is useful to build images unprivileged or when loop devices
+        are not available. If disabled, the image is always built using loop devices. If
+        <literal>auto</literal>, <command>systemd-repart</command> will build the image online if possible
+        and fall back to building the image offline if loop devices are not available or cannot be accessed
+        due to missing permissions.</para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--copy-from=</option><arg>IMAGE</arg></term>
+
+        <listitem><para>Instructs <command>systemd-repart</command> to synthesize partition definitions from
+        the partition table in the given image. This option can be specified multiple times to synthesize
+        definitions from each of the given images. The generated definitions will copy the partitions into
+        the destination partition table. The copied partitions will have the same size, metadata and contents
+        but might have a different partition number and might be located at a different offset in the
+        destination partition table. These definitions can be combined with partition definitions read from
+        regular partition definition files. The synthesized definitions take precedence over the definitions
+        read from partition definition files.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--copy-source=</option><replaceable>PATH</replaceable></term>
+        <term><option>-s</option> <replaceable>PATH</replaceable></term>
+
+        <listitem><para>Specifies a source directory all <varname>CopyFiles=</varname> source paths shall be
+        considered relative to. This is similar to <option>--root=</option>, but exclusively applies to the
+        <varname>CopyFiles=</varname> setting. If <option>--root=</option> and
+        <option>--copy-source=</option> are used in combination the former applies as usual, except for
+        <varname>CopyFiles=</varname> where the latter takes precedence.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--make-ddi=</option><replaceable>TYPE</replaceable></term>
+
+        <listitem><para>Takes one of <literal>sysext</literal>, <literal>confext</literal> or
+        <literal>portable</literal>. Generates a Discoverable Disk Image (DDI) for a system extension
+        (sysext, see
+        <citerefentry><refentrytitle>systemd-sysext</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        for details), configuration extension (confext) or <ulink
+        url="https://systemd.io/PORTABLE_SERVICES">portable service</ulink>. The generated image will consist
+        of a signed Verity <literal>erofs</literal> file system as root partition. In this mode of operation
+        the partition definitions in <filename>/usr/lib/repart.d/*.conf</filename> and related directories
+        are not read, and <option>--definitions=</option> is not supported, as appropriate definitions for
+        the selected DDI class will be chosen automatically.</para>
+
+        <para>Must be used in conjunction with <option>--copy-source=</option> to specify the file hierarchy
+        to populate the DDI with. The specified directory should contain an <filename>etc/</filename>
+        subdirectory if <literal>confext</literal> is selected. If <literal>sysext</literal> is selected it
+        should contain either a <filename>usr/</filename> or <filename>opt/</filename> directory, or both. If
+        <literal>portable</literal> is used a full OS file hierarchy can be provided.</para>
+
+        <para>This option implies <option>--empty=create</option>, <option>--size=auto</option> and
+        <option>--seed=random</option> (the latter two can be overridden).</para>
+
+        <para>The private key and certificate for signing the DDI must be specified via the
+        <option>--private-key=</option> and <option>--certificate=</option> switches.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-S</option></term>
+        <term><option>-C</option></term>
+        <term><option>-P</option></term>
+
+        <listitem><para>Shortcuts for <option>--make-ddi=sysext</option>,
+        <option>--make-ddi=confext</option>, <option>--make-ddi=portable</option>,
+        respectively.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+
+      <xi:include href="standard-options.xml" xpointer="help" />
+      <xi:include href="standard-options.xml" xpointer="version" />
+      <xi:include href="standard-options.xml" xpointer="no-pager" />
+      <xi:include href="standard-options.xml" xpointer="no-legend" />
+      <xi:include href="standard-options.xml" xpointer="json" />
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Exit status</title>
+
+    <para>On success, 0 is returned, a non-zero failure code otherwise.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Example</title>
+
+    <example>
+      <title>Generate a configuration extension image</title>
+
+      <para>The following creates a configuration extension DDI (confext) for an
+      <filename>/etc/motd</filename> update.</para>
+
+      <programlisting>mkdir tree tree/etc tree/etc/extension-release.d
+echo "Hello World" > tree/etc/motd
+cat > tree/etc/extension-release.d/extension-release.my-motd &lt;&lt;EOF
+ID=fedora
+VERSION_ID=38
+IMAGE_ID=my-motd
+IMAGE_VERSION=7
+EOF
+systemd-repart -C --private-key=privkey.pem --certificate=cert.crt -s tree/ /var/lib/confexts/my-motd.confext.raw
+systemd-confext refresh</programlisting>
+
+      <para>The DDI generated that way may be applied to the system with
+      <citerefentry><refentrytitle>systemd-confext</refentrytitle><manvolnum>1</manvolnum></citerefentry>.</para>
+    </example>
+
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>repart.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-cryptenroll</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>portablectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-sysext</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-resolved.service.xml b/man/systemd-resolved.service.xml
new file mode 100644
index 0000000..85c857d
--- /dev/null
+++ b/man/systemd-resolved.service.xml
@@ -0,0 +1,505 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd-resolved.service" conditional='ENABLE_RESOLVE'
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd-resolved.service</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-resolved.service</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-resolved.service</refname>
+    <refname>systemd-resolved</refname>
+    <refpurpose>Network Name Resolution manager</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>systemd-resolved.service</filename></para>
+    <para><filename>/usr/lib/systemd/systemd-resolved</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>systemd-resolved</command> is a system service that provides network name resolution to
+    local applications. It implements a caching and validating DNS/DNSSEC stub resolver, as well as an LLMNR
+    and MulticastDNS resolver and responder. Local applications may submit network name resolution requests
+    via three interfaces:</para>
+
+    <itemizedlist>
+      <listitem><para>The native, fully-featured API <command>systemd-resolved</command> exposes on the bus,
+      see
+      <citerefentry><refentrytitle>org.freedesktop.resolve1</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+      and
+      <citerefentry><refentrytitle>org.freedesktop.LogControl1</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+      for details. Usage of this API is generally recommended to clients as it is asynchronous and fully
+      featured (for example, properly returns DNSSEC validation status and interface scope for addresses as
+      necessary for supporting link-local networking).</para></listitem>
+
+      <listitem><para>The glibc
+      <citerefentry project='man-pages'><refentrytitle>getaddrinfo</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+      API as defined by <ulink url="https://tools.ietf.org/html/rfc3493">RFC3493</ulink> and its related
+      resolver functions, including
+      <citerefentry project='man-pages'><refentrytitle>gethostbyname</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+      This API is widely supported, including beyond the Linux platform. In its current form it does not
+      expose DNSSEC validation status information however, and is synchronous only. This API is backed by the
+      glibc Name Service Switch
+      (<citerefentry project='man-pages'><refentrytitle>nss</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
+      Usage of the glibc NSS module
+      <citerefentry><refentrytitle>nss-resolve</refentrytitle><manvolnum>8</manvolnum></citerefentry> is
+      required in order to allow glibc's NSS resolver functions to resolve hostnames via
+      <command>systemd-resolved</command>.</para></listitem>
+
+      <listitem><para>Additionally, <command>systemd-resolved</command> provides a local DNS stub listener on
+      the IP addresses 127.0.0.53 and 127.0.0.54 on the local loopback interface. Programs issuing DNS
+      requests directly, bypassing any local API may be directed to this stub, in order to connect them to
+      <command>systemd-resolved</command>. Note however that it is strongly recommended that local programs
+      use the glibc NSS or bus APIs instead (as described above), as various network resolution concepts
+      (such as link-local addressing, or LLMNR Unicode domains) cannot be mapped to the unicast DNS
+      protocol.</para>
+
+      <para id="proxy-stub">The DNS stub resolver on 127.0.0.53 provides the full feature set of the local
+      resolver, which includes offering LLMNR/MulticastDNS resolution. The DNS stub resolver on 127.0.0.54
+      provides a more limited resolver, that operates in "proxy" mode only, i.e. it will pass most DNS
+      messages relatively unmodified to the current upstream DNS servers and back, but not try to process the
+      messages locally, and hence does not validate DNSSEC, or offer up LLMNR/MulticastDNS. (It will
+      translate to DNS-over-TLS communication if needed however.)</para></listitem>
+    </itemizedlist>
+
+    <para>The DNS servers contacted are determined from the global settings in
+    <filename>/etc/systemd/resolved.conf</filename>, the per-link static settings in
+    <filename>/etc/systemd/network/*.network</filename> files (in case
+    <citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    is used), the per-link dynamic settings received over DHCP, information provided via
+    <citerefentry><refentrytitle>resolvectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, and any
+    DNS server information made available by other system services. See
+    <citerefentry><refentrytitle>resolved.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> and
+    <citerefentry><refentrytitle>systemd.network</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
+    details about systemd's own configuration files for DNS servers. To improve compatibility,
+    <filename>/etc/resolv.conf</filename> is read in order to discover configured system DNS servers, but
+    only if it is not a symlink to <filename>/run/systemd/resolve/stub-resolv.conf</filename>,
+    <filename>/usr/lib/systemd/resolv.conf</filename> or
+    <filename>/run/systemd/resolve/resolv.conf</filename> (see below).</para>
+
+  </refsect1>
+
+  <refsect1>
+    <title>Synthetic Records</title>
+
+    <para><command>systemd-resolved</command> synthesizes DNS resource records (RRs) for the following
+    cases:</para>
+
+    <itemizedlist>
+      <listitem><para>The local, configured hostname is resolved to all locally configured IP addresses
+      ordered by their scope, or — if none are configured — the IPv4 address 127.0.0.2 (which is on the local
+      loopback interface) and the IPv6 address ::1 (which is the local host).</para></listitem>
+
+      <listitem><para>The hostnames <literal>localhost</literal> and <literal>localhost.localdomain</literal>
+      as well as any hostname ending in <literal>.localhost</literal> or
+      <literal>.localhost.localdomain</literal> are resolved to the IP addresses 127.0.0.1 and ::1.
+      </para></listitem>
+
+      <listitem><para>The hostname <literal>_gateway</literal> is resolved to all current default routing
+      gateway addresses, ordered by their metric. This assigns a stable hostname to the current gateway,
+      useful for referencing it independently of the current network configuration state.</para></listitem>
+
+      <listitem><para>The hostname <literal>_outbound</literal> is resolved to the local IPv4 and IPv6
+      addresses that are most likely used for communication with other hosts. This is determined by
+      requesting a routing decision to the configured default gateways from the kernel and then using the
+      local IP addresses selected by this decision. This hostname is only available if there is at least one
+      local default gateway configured. This assigns a stable hostname to the local outbound IP addresses,
+      useful for referencing them independently of the current network configuration state.</para></listitem>
+
+      <listitem><para>The hostname <literal>_localdnsstub</literal> is resolved to the IP address 127.0.0.53,
+      i.e. the address the local DNS stub (see above) is listening on.</para></listitem>
+
+      <listitem><para>The hostname <literal>_localdnsproxy</literal> is resolved to the IP address 127.0.0.54,
+      i.e. the address the local DNS proxy (see above) is listening on.</para></listitem>
+
+      <listitem><para>The mappings defined in <filename>/etc/hosts</filename> are resolved to their
+      configured addresses and back, but they will not affect lookups for non-address types (like MX).
+      Support for <filename>/etc/hosts</filename> may be disabled with <varname>ReadEtcHosts=no</varname>,
+      see <citerefentry><refentrytitle>resolved.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+      </para></listitem>
+    </itemizedlist>
+  </refsect1>
+
+  <refsect1>
+    <title>Protocols and Routing</title>
+
+    <para>The lookup requests that <filename>systemd-resolved.service</filename> receives are routed to the
+    available DNS servers, LLMNR, and MulticastDNS interfaces according to the following rules:</para>
+
+    <itemizedlist>
+      <listitem><para>Names for which synthetic records are generated (the local hostname,
+      <literal>localhost</literal> and <literal>localdomain</literal>, local gateway, as listed in the
+      previous section) and addresses configured in <filename>/etc/hosts</filename> are never routed to the
+      network and a reply is sent immediately.</para></listitem>
+
+      <listitem><para>Single-label names are resolved using LLMNR on all local interfaces where LLMNR is
+      enabled. Lookups for IPv4 addresses are only sent via LLMNR on IPv4, and lookups for IPv6 addresses are
+      only sent via LLMNR on IPv6. Note that lookups for single-label synthesized names are not routed to
+      LLMNR, MulticastDNS or unicast DNS.</para></listitem>
+
+      <listitem><para>Queries for the address records (A and AAAA) of single-label non-synthesized names are
+      resolved via unicast DNS using search domains. For any interface which defines search domains, such
+      look-ups are routed to the servers defined for that interface, suffixed with each of those search
+      domains. When global search domains are defined, such look-ups are routed to the global servers. For
+      each search domain, queries are performed by suffixing the name with each of the search domains in
+      turn. Additionally, lookup of single-label names via unicast DNS may be enabled with the
+      <varname>ResolveUnicastSingleLabel=yes</varname> setting. The details of which servers are queried and
+      how the final reply is chosen are described below. Note that this means that address queries for
+      single-label names are never sent out to remote DNS servers by default, and resolution is only
+      possible if search domains are defined.</para></listitem>
+
+      <listitem><para>Multi-label names with the domain suffix <literal>.local</literal> are resolved using
+      MulticastDNS on all local interfaces where MulticastDNS is enabled. As with LLMNR, IPv4 address lookups
+      are sent via IPv4 and IPv6 address lookups are sent via IPv6.</para></listitem>
+
+      <listitem><para>Queries for multi-label names are routed via unicast DNS on local interfaces that have
+      a DNS server configured, plus the globally configured DNS servers if there are any. Which interfaces
+      are used is determined by the routing logic based on search and route-only domains, described below.
+      Note that by default, lookups for domains with the <literal>.local</literal> suffix are not routed to
+      DNS servers, unless the domain is specified explicitly as routing or search domain for the DNS server
+      and interface. This means that on networks where the <literal>.local</literal> domain is defined in a
+      site-specific DNS server, explicit search or routing domains need to be configured to make lookups work
+      within this DNS domain. Note that these days, it's generally recommended to avoid defining
+      <literal>.local</literal> in a DNS server, as <ulink
+      url="https://tools.ietf.org/html/rfc6762">RFC6762</ulink> reserves this domain for exclusive
+      MulticastDNS use.</para></listitem>
+
+      <listitem><para>Address lookups (reverse lookups) are routed similarly to multi-label names, with the
+      exception that addresses from the link-local address range are never routed to unicast DNS and are only
+      resolved using LLMNR and MulticastDNS (when enabled).</para></listitem>
+    </itemizedlist>
+
+    <para>If lookups are routed to multiple interfaces, the first successful response is returned (thus
+    effectively merging the lookup zones on all matching interfaces). If the lookup failed on all interfaces,
+    the last failing response is returned.</para>
+
+    <para>Routing of lookups is determined by the per-interface routing domains (search and route-only) and
+    global search domains. See
+    <citerefentry><refentrytitle>systemd.network</refentrytitle><manvolnum>5</manvolnum></citerefentry> and
+    <citerefentry><refentrytitle>resolvectl</refentrytitle><manvolnum>1</manvolnum></citerefentry> for a
+    description how those settings are set dynamically and the discussion of <varname>Domains=</varname> in
+    <citerefentry><refentrytitle>resolved.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> for a
+    description of globally configured DNS settings.</para>
+
+    <para>The following query routing logic applies for unicast DNS lookups initiated by
+    <filename>systemd-resolved.service</filename>:</para>
+
+    <itemizedlist>
+      <listitem><para>If a name to look up matches (that is: is equal to or has as suffix) any of the
+      configured routing domains (search or route-only) of any link, or the globally configured DNS settings,
+      "best matching" routing domain is determined: the matching one with the most labels. The query is then
+      sent to all DNS servers of any links or the globally configured DNS servers associated with this "best
+      matching" routing domain. (Note that more than one link might have this same "best matching" routing
+      domain configured, in which case the query is sent to all of them in parallel).</para>
+
+      <para>In case of single-label names, when search domains are defined, the same logic applies, except
+      that the name is first suffixed by each of the search domains in turn. Note that this search logic
+      doesn't apply to any names with at least one dot. Also see the discussion about compatibility with
+      the traditional glibc resolver below.</para></listitem>
+
+      <listitem><para>If a query does not match any configured routing domain (either per-link or global), it
+      is sent to all DNS servers that are configured on links with the <varname>DefaultRoute=</varname>
+      option set, as well as the globally configured DNS server.</para></listitem>
+
+      <listitem><para>If there is no link configured as <varname>DefaultRoute=</varname> and no global DNS
+      server configured, one of the compiled-in fallback DNS servers is used.</para></listitem>
+
+      <listitem><para>Otherwise the unicast DNS query fails, as no suitable DNS servers can be determined.
+      </para></listitem>
+    </itemizedlist>
+
+    <para>The <varname>DefaultRoute=</varname> option is a boolean setting configurable with
+    <command>resolvectl</command> or in <filename>.network</filename> files. If not set, it is implicitly
+    determined based on the configured DNS domains for a link: if there's a route-only domain other than
+    <literal>~.</literal>, it defaults to false, otherwise to true.</para>
+
+    <para>Effectively this means: in order to support single-label non-synthesized names, define appropriate
+    search domains. In order to preferably route all DNS queries not explicitly matched by routing domain
+    configuration to a specific link, configure a <literal>~.</literal> route-only domain on it. This will
+    ensure that other links will not be considered for these queries (unless they too carry such a routing
+    domain). In order to route all such DNS queries to a specific link only if no other link is preferred,
+    set the <varname>DefaultRoute=</varname> option for the link to true and do not configure a
+    <literal>~.</literal> route-only domain on it. Finally, in order to ensure that a specific link never
+    receives any DNS traffic not matching any of its configured routing domains, set the
+    <varname>DefaultRoute=</varname> option for it to false.</para>
+
+    <para>See
+    <citerefentry><refentrytitle>org.freedesktop.resolve1</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for information about the D-Bus APIs <filename>systemd-resolved</filename> provides.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Compatibility with the traditional glibc stub resolver</title>
+
+    <para>This section provides a short summary of differences in the resolver implemented by
+    <citerefentry><refentrytitle>nss-resolve</refentrytitle><manvolnum>8</manvolnum></citerefentry> together
+    with <command>systemd-resolved</command> and the traditional stub resolver implemented in
+    <filename>nss-dns</filename>.</para>
+
+    <itemizedlist>
+      <listitem><para>Some names are always resolved internally (see Synthetic Records above). Traditionally
+      they would be resolved by <filename>nss-files</filename> if provided in
+      <filename>/etc/hosts</filename>. But note that the details of how a query is constructed are under the
+      control of the client library. <filename>nss-dns</filename> will first try to resolve names using
+      search domains and even if those queries are routed to <filename>systemd-resolved</filename>, it will
+      send them out over the network using the usual rules for multi-label name routing <footnote><para>For
+      example, if <filename>/etc/resolv.conf</filename> has <programlisting>nameserver 127.0.0.53
+search foobar.com barbar.com
+      </programlisting>and we look up <literal>localhost</literal>, <filename>nss-dns</filename> will send
+      the following queries to <filename>systemd-resolved</filename> listening on 127.0.0.53:53: first
+      <literal>localhost.foobar.com</literal>, then <literal>localhost.barbar.com</literal>, and finally
+      <literal>localhost</literal>. If (hopefully) the first two queries fail,
+      <filename>systemd-resolved</filename> will synthesize an answer for the third query.</para>
+
+      <para>When using <filename>nss-dns</filename> with any search domains, it is thus crucial to always
+      configure <filename>nss-files</filename> with higher priority and provide mappings for names that
+      should not be resolved using search domains.</para></footnote>.</para></listitem>
+
+      <listitem><para>Single-label names are not resolved for A and AAAA records using unicast DNS (unless
+      overridden with <varname>ResolveUnicastSingleLabel=</varname>, see
+      <citerefentry><refentrytitle>resolved.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
+      This is similar to the <option>no-tld-query</option> option being set in
+      <citerefentry project='man-pages'><refentrytitle>resolv.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+      </para></listitem>
+
+      <listitem><para>Search domains are not used for <emphasis>suffixing</emphasis> of multi-label names.
+      (Search domains are nevertheless used for lookup <emphasis>routing</emphasis>, for names that were
+      originally specified as single-label or multi-label.) Any name with at least one dot is always
+      interpreted as a FQDN. <filename>nss-dns</filename> would resolve names both as relative (using search
+      domains) and absolute FQDN names. Some names would be resolved as relative first, and after that query
+      has failed, as absolute, while other names would be resolved in opposite order. The
+      <varname>ndots</varname> option in <filename>/etc/resolv.conf</filename> was used to control how many
+      dots the name needs to have to be resolved as relative first. This stub resolver does not implement
+      this at all: multi-label names are only resolved as FQDNs.<footnote><para>There are currently more than
+      1500 top-level domain names defined, and new ones are added regularly, often using "attractive" names
+      that are also likely to be used locally. Not looking up multi-label names in this fashion avoids
+      fragility in both directions: a valid global name could be obscured by a local name, and resolution of
+      a relative local name could suddenly break when a new top-level domain is created, or when a new
+      subdomain of a top-level domain in registered. Resolving any given name as either relative or absolute
+      avoids this ambiguity.</para></footnote></para></listitem>
+
+      <listitem><para>This resolver has a notion of the special <literal>.local</literal> domain used for
+      MulticastDNS, and will not route queries with that suffix to unicast DNS servers unless explicitly
+      configured, see above. Also, reverse lookups for link-local addresses are not sent to unicast DNS
+      servers.</para></listitem>
+
+      <listitem><para>This resolver reads and caches <filename>/etc/hosts</filename> internally. (In other
+      words, <filename>nss-resolve</filename> replaces <filename>nss-files</filename> in addition to
+      <filename>nss-dns</filename>). Entries in <filename>/etc/hosts</filename> have highest priority.</para>
+      </listitem>
+
+      <listitem><para>This resolver also implements LLMNR and MulticastDNS in addition to the classic unicast
+      DNS protocol, and will resolve single-label names using LLMNR (when enabled) and names ending in
+      <literal>.local</literal> using MulticastDNS (when enabled).</para></listitem>
+
+      <listitem><para>Environment variables <varname>$LOCALDOMAIN</varname> and
+      <varname>$RES_OPTIONS</varname> described in
+      <citerefentry project='man-pages'><refentrytitle>resolv.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+      are not supported currently.</para></listitem>
+
+      <listitem><para>The <filename>nss-dns</filename> resolver maintains little state between subsequent DNS
+      queries, and for each query always talks to the first listed DNS server from
+      <filename>/etc/resolv.conf</filename> first, and on failure continues with the next until reaching the
+      end of the list which is when the query fails. The resolver in
+      <filename>systemd-resolved.service</filename> however maintains state, and will continuously talk to
+      the same server for all queries on a particular lookup scope until some form of error is seen at which
+      point it switches to the next, and then continuously stays with it for all queries on the scope until
+      the next failure, and so on, eventually returning to the first configured server. This is done to
+      optimize lookup times, in particular given that the resolver typically must first probe server feature
+      sets when talking to a server, which is time consuming. This different behaviour implies that listed
+      DNS servers per lookup scope must be equivalent in the zones they serve, so that sending a query to one
+      of them will yield the same results as sending it to another configured DNS server.</para></listitem>
+    </itemizedlist>
+  </refsect1>
+
+  <refsect1>
+    <title><filename>/etc/resolv.conf</filename></title>
+
+    <para>Four modes of handling <filename>/etc/resolv.conf</filename> (see
+    <citerefentry project='man-pages'><refentrytitle>resolv.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>) are
+    supported:</para>
+
+    <itemizedlist>
+      <listitem><para><command>systemd-resolved</command> maintains the
+      <filename>/run/systemd/resolve/stub-resolv.conf</filename> file for compatibility with traditional
+      Linux programs. This file lists the 127.0.0.53 DNS stub (see above) as the only DNS server. It also
+      contains a list of search domains that are in use by systemd-resolved. The list of search domains is
+      always kept up-to-date. Note that <filename>/run/systemd/resolve/stub-resolv.conf</filename> should not
+      be used directly by applications, but only through a symlink from
+      <filename>/etc/resolv.conf</filename>. This file may be symlinked from
+      <filename>/etc/resolv.conf</filename> in order to connect all local clients that bypass local DNS APIs
+      to <command>systemd-resolved</command> with correct search domains settings. This mode of operation is
+      recommended.</para></listitem>
+
+      <listitem><para>A static file <filename>/usr/lib/systemd/resolv.conf</filename> is provided that lists
+      the 127.0.0.53 DNS stub (see above) as only DNS server. This file may be symlinked from
+      <filename>/etc/resolv.conf</filename> in order to connect all local clients that bypass local DNS APIs
+      to <command>systemd-resolved</command>. This file does not contain any search domains.
+      </para></listitem>
+
+      <listitem><para><command>systemd-resolved</command> maintains the
+      <filename>/run/systemd/resolve/resolv.conf</filename> file for compatibility with traditional Linux
+      programs. This file may be symlinked from <filename>/etc/resolv.conf</filename> and is always kept
+      up-to-date, containing information about all known DNS servers. Note the file format's limitations: it
+      does not know a concept of per-interface DNS servers and hence only contains system-wide DNS server
+      definitions. Note that <filename>/run/systemd/resolve/resolv.conf</filename> should not be used
+      directly by applications, but only through a symlink from <filename>/etc/resolv.conf</filename>. If
+      this mode of operation is used local clients that bypass any local DNS API will also bypass
+      <command>systemd-resolved</command> and will talk directly to the known DNS servers.</para></listitem>
+
+      <listitem><para>Alternatively, <filename>/etc/resolv.conf</filename> may be managed by other packages,
+      in which case <command>systemd-resolved</command> will read it for DNS configuration data. In this mode
+      of operation <command>systemd-resolved</command> is consumer rather than provider of this configuration
+      file. </para></listitem>
+    </itemizedlist>
+
+    <para>Note that the selected mode of operation for this file is detected fully automatically, depending
+    on whether <filename>/etc/resolv.conf</filename> is a symlink to
+    <filename>/run/systemd/resolve/resolv.conf</filename> or lists 127.0.0.53 as DNS server.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Signals</title>
+
+    <variablelist>
+      <varlistentry>
+        <term><constant>SIGUSR1</constant></term>
+
+        <listitem><para>Upon reception of the <constant>SIGUSR1</constant> process signal
+        <command>systemd-resolved</command> will dump the contents of all DNS resource record caches it
+        maintains, as well as all feature level information it learnt about configured DNS servers into the
+        system logs.</para>
+
+        <xi:include href="version-info.xml" xpointer="v231"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><constant>SIGUSR2</constant></term>
+
+        <listitem><para>Upon reception of the <constant>SIGUSR2</constant> process signal
+        <command>systemd-resolved</command> will flush all caches it maintains. Note that it should normally
+        not be necessary to request this explicitly – except for debugging purposes – as
+        <command>systemd-resolved</command> flushes the caches automatically anyway any time the host's
+        network configuration changes. Sending this signal to <command>systemd-resolved</command> is
+        equivalent to the <command>resolvectl flush-caches</command> command, however the latter is
+        recommended since it operates in a synchronous way.</para>
+
+        <xi:include href="version-info.xml" xpointer="v231"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><constant>SIGRTMIN+1</constant></term>
+
+        <listitem><para>Upon reception of the <constant>SIGRTMIN+1</constant> process signal
+        <command>systemd-resolved</command> will forget everything it learnt about the configured DNS
+        servers. Specifically any information about server feature support is flushed out, and the server
+        feature probing logic is restarted on the next request, starting with the most fully featured
+        level. Note that it should normally not be necessary to request this explicitly – except for
+        debugging purposes – as <command>systemd-resolved</command> automatically forgets learnt information
+        any time the DNS server configuration changes. Sending this signal to
+        <command>systemd-resolved</command> is equivalent to the <command>resolvectl
+        reset-server-features</command> command, however the latter is recommended since it operates in a
+        synchronous way.</para>
+
+        <xi:include href="version-info.xml" xpointer="v235"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Credentials</title>
+
+    <para><command>systemd-resolved</command> supports the service credentials logic as implemented by
+    <varname>ImportCredential=</varname>/<varname>LoadCredential=</varname>/<varname>SetCredential=</varname>
+    (see <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
+    details). The following credentials are used when passed in:</para>
+
+    <variablelist class='system-credentials'>
+      <varlistentry>
+        <term><varname>network.dns</varname></term>
+        <term><varname>network.search_domains</varname></term>
+
+        <listitem><para>May contain a space separated list of DNS server IP addresses and DNS search
+        domains. This information is only used when no explicit configuration via
+        <filename>/etc/systemd/resolved.conf</filename>, <filename>/etc/resolv.conf</filename> or the kernel
+        command line has been provided.</para>
+
+        <xi:include href="version-info.xml" xpointer="v253"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Kernel Command Line</title>
+
+    <para><command>systemd-resolved</command> also honours two kernel command line options:</para>
+
+    <variablelist class='kernel-commandline-options'>
+      <varlistentry>
+        <term><varname>nameserver=</varname></term>
+        <term><varname>domain=</varname></term>
+
+        <listitem><para>Takes the IP address of a DNS server (in case of <varname>nameserver=</varname>), and
+        a DNS search domain (in case of <varname>domain=</varname>). May be used multiple times, to define
+        multiple DNS servers/search domains. If either of these options are specified
+        <filename>/etc/resolv.conf</filename> will not be read and the <varname>DNS=</varname> and
+        <varname>Domains=</varname> settings of
+        <citerefentry><refentrytitle>resolved.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        will be ignored. These two kernel command line options hence override system
+        configuration.</para>
+
+        <xi:include href="version-info.xml" xpointer="v253"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>IP Ports</title>
+
+    <para>The <command>systemd-resolved</command> service listens on the following IP ports:</para>
+
+    <itemizedlist>
+      <listitem><para>Port 53 on IPv4 addresses 127.0.0.53 and 127.0.0.54 (both are on the local loopback
+      interface <literal>lo</literal>). This is the local DNS stub, as discussed above. Both UDP and TCP are
+      covered.</para></listitem>
+
+      <listitem><para>Port 5353 on all local addresses, both IPv4 and IPv6 (0.0.0.0 and ::0), for
+      MulticastDNS on UDP. Note that even though the socket is bound to all local interfaces via the selected
+      "wildcard" IP addresses, the incoming datagrams are filtered by the network interface they are coming
+      in on, and separate MulticastDNS link-local scopes are maintained for each, taking into consideration
+      whether MulticastDNS is enabled for the interface or not.</para></listitem>
+
+      <listitem><para>Port 5355 on all local addresses, both IPv4 and IP6 (0.0.0.0 and ::0), for LLMNR, on
+      both TCP and UDP. As with MulticastDNS filtering by incoming network interface is applied.</para></listitem>
+    </itemizedlist>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>resolved.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>dnssec-trust-anchors.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>nss-resolve</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>resolvectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>resolv.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>hosts</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.network</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-rfkill.service.xml b/man/systemd-rfkill.service.xml
new file mode 100644
index 0000000..f2ff486
--- /dev/null
+++ b/man/systemd-rfkill.service.xml
@@ -0,0 +1,68 @@
+<?xml version="1.0"?>
+<!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+<refentry id="systemd-rfkill.service" conditional='ENABLE_RFKILL'
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd-rfkill.service</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-rfkill.service</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-rfkill.service</refname>
+    <refname>systemd-rfkill.socket</refname>
+    <refname>systemd-rfkill</refname>
+    <refpurpose>Load and save the RF kill switch state at boot and change</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>systemd-rfkill.service</filename></para>
+    <para><filename>systemd-rfkill.socket</filename></para>
+    <para><filename>/usr/lib/systemd/systemd-rfkill</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><filename>systemd-rfkill.service</filename> is a service
+    that restores the RF kill switch state at early boot and saves it
+    on each change. On disk, the RF kill switch state is stored in
+    <filename>/var/lib/systemd/rfkill/</filename>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Kernel Command Line</title>
+
+    <para><filename>systemd-rfkill</filename> understands the
+    following kernel command line parameter:</para>
+
+    <variablelist class='kernel-commandline-options'>
+      <varlistentry>
+        <term><varname>systemd.restore_state=</varname></term>
+
+        <listitem><para>Takes a boolean argument. Defaults to
+        <literal>1</literal>. If <literal>0</literal>, does not
+        restore the rfkill settings on boot. However, settings will
+        still be stored on shutdown. </para>
+
+        <xi:include href="version-info.xml" xpointer="v227"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-run-generator.xml b/man/systemd-run-generator.xml
new file mode 100644
index 0000000..02924b4
--- /dev/null
+++ b/man/systemd-run-generator.xml
@@ -0,0 +1,81 @@
+<?xml version="1.0"?>
+<!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+<refentry id="systemd-run-generator">
+
+  <refentryinfo>
+    <title>systemd-run-generator</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-run-generator</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-run-generator</refname>
+    <refpurpose>Generator for invoking commands specified on the kernel command line as system service</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>/usr/lib/systemd/system-generators/systemd-run-generator</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><filename>systemd-run-generator</filename> is a generator
+    that reads the kernel command line and understands three
+    options:</para>
+
+    <para>If the <option>systemd.run=</option> option is specified and followed by a command line, a unit named
+    <filename>kernel-command-line.service</filename> is generated for it and booted into. The service has
+    <varname>Type=oneshot</varname> set, and has <varname>SuccessAction=exit</varname> and
+    <varname>FailureAction=exit</varname> configured by default, thus ensuring that the system is shut down as soon as
+    the command completes. The exit status of the command line is propagated to the invoking container manager, if
+    this applies (which might propagate this further, to the calling shell — e.g.
+    <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>7</manvolnum></citerefentry> does this). If
+    this option is used multiple times the unit file will contain multiple <varname>ExecStart=</varname> lines, to
+    execute all commands in order. The command is started as regular service, i.e. with
+    <varname>DefaultDependencies=</varname> on. </para>
+
+    <para>Use <option>systemd.run_success_action=</option> and <option>systemd.run_failure_action=</option> to tweak
+    how to react to the process completing. In particular assigning <literal>none</literal> will leave the system
+    running after the command completes. For further details on supported arguments, see
+    <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+
+    <para><filename>systemd-run-generator</filename> implements
+    <citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Example</title>
+
+    <para>Use a command like the following to add a user to the user database inside a container run with
+    <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>7</manvolnum></citerefentry>:</para>
+
+    <programlisting># systemd-nspawn -D mycontainer -b systemd.run='"adduser test"'</programlisting>
+    <para>(Note the requirement for double quoting in the command line above. The first level of quoting ('') is
+    processed and removed by the command shell used to invoke <command>systemd-nspawn</command>. The second level of
+    quoting ("") is propagated to the kernel command line of the container and processed and removed by
+    <command>systemd-run-generator</command>. Both together make sure both words of the specified command line
+    <command>adduser test</command> end up in the generated unit file together and are neither split apart by the
+    command shell nor by the generator.)</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>kernel-command-line</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-run.xml b/man/systemd-run.xml
new file mode 100644
index 0000000..5be9823
--- /dev/null
+++ b/man/systemd-run.xml
@@ -0,0 +1,684 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd-run"
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd-run</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-run</refentrytitle>
+    <manvolnum>1</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-run</refname>
+    <refpurpose>Run programs in transient scope units, service units, or path-, socket-, or timer-triggered service units</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <cmdsynopsis>
+      <command>systemd-run</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="plain"><replaceable>COMMAND</replaceable>
+      <arg choice="opt" rep="repeat">ARGS</arg>
+      </arg>
+    </cmdsynopsis>
+    <cmdsynopsis>
+      <command>systemd-run</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="opt" rep="repeat">PATH OPTIONS</arg>
+      <arg choice="req"><replaceable>COMMAND</replaceable></arg>
+      <arg choice="opt" rep="repeat">ARGS</arg>
+    </cmdsynopsis>
+    <cmdsynopsis>
+      <command>systemd-run</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="opt" rep="repeat">SOCKET OPTIONS</arg>
+      <arg choice="req"><replaceable>COMMAND</replaceable></arg>
+      <arg choice="opt" rep="repeat">ARGS</arg>
+    </cmdsynopsis>
+    <cmdsynopsis>
+      <command>systemd-run</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="opt" rep="repeat">TIMER OPTIONS</arg>
+      <arg choice="req"><replaceable>COMMAND</replaceable></arg>
+      <arg choice="opt" rep="repeat">ARGS</arg>
+    </cmdsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>systemd-run</command> may be used to create and start a transient <filename>.service</filename> or
+    <filename>.scope</filename> unit and run the specified <replaceable>COMMAND</replaceable> in it. It may also be
+    used to create and start a transient <filename>.path</filename>, <filename>.socket</filename>, or
+    <filename>.timer</filename> unit, that activates a <filename>.service</filename> unit when elapsing.</para>
+
+    <para>If a command is run as transient service unit, it will be started and managed by the service manager like any
+    other service, and thus shows up in the output of <command>systemctl list-units</command> like any other unit. It
+    will run in a clean and detached execution environment, with the service manager as its parent process. In this
+    mode, <command>systemd-run</command> will start the service asynchronously in the background and return after the
+    command has begun execution (unless <option>--no-block</option> or <option>--wait</option> are specified, see
+    below).</para>
+
+    <para>If a command is run as transient scope unit, it will be executed by <command>systemd-run</command>
+    itself as parent process and will thus inherit the execution environment of the caller. However, the
+    processes of the command are managed by the service manager similarly to normal services, and will show
+    up in the output of <command>systemctl list-units</command>. Execution in this case is synchronous, and
+    will return only when the command finishes. This mode is enabled via the <option>--scope</option> switch
+    (see below).</para>
+
+    <para>If a command is run with path, socket, or timer options such as <option>--on-calendar=</option> (see below),
+    a transient path, socket, or timer unit is created alongside the service unit for the specified command. Only the
+    transient path, socket, or timer unit is started immediately, the transient service unit will be triggered by the
+    path, socket, or timer unit. If the <option>--unit=</option> option is specified, the
+    <replaceable>COMMAND</replaceable> may be omitted. In this case, <command>systemd-run</command> creates only a
+    <filename>.path</filename>, <filename>.socket</filename>, or <filename>.timer</filename> unit that triggers the
+    specified unit.</para>
+
+    <para>By default, services created with <command>systemd-run</command> default to the
+    <option>simple</option> type, see the description of <varname>Type=</varname> in
+    <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
+    details. Note that when this type is used, the service manager (and thus the
+    <command>systemd-run</command> command) considers service start-up successful as soon as the
+    <function>fork()</function> for the main service process succeeded, i.e. before the
+    <function>execve()</function> is invoked, and thus even if the specified command cannot be started.
+    Consider using the <option>exec</option> service type (i.e. <option>--property=Type=exec</option>) to
+    ensure that <command>systemd-run</command> returns successfully only if the specified command line has
+    been successfully started.</para>
+
+    <para>After <command>systemd-run</command> passes the command to the service manager, the manager
+    performs variable expansion. This means that dollar characters (<literal>$</literal>) which should not be
+    expanded need to be escaped as <literal>$$</literal>. Expansion can also be disabled using
+    <varname>--expand-environment=no</varname>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>The following options are understood:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><option>--no-ask-password</option></term>
+
+        <listitem><para>Do not query the user for authentication for
+        privileged operations.</para>
+
+        <xi:include href="version-info.xml" xpointer="v226"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--scope</option></term>
+
+        <listitem>
+          <para>Create a transient <filename>.scope</filename> unit instead of the default transient
+          <filename>.service</filename> unit (see above).
+          </para>
+
+        <xi:include href="version-info.xml" xpointer="v206"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--unit=</option></term>
+        <term><option>-u</option></term>
+
+        <listitem><para>Use this unit name instead of an automatically
+        generated one.</para>
+
+        <xi:include href="version-info.xml" xpointer="v206"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--property=</option></term>
+        <term><option>-p</option></term>
+
+        <listitem><para>Sets a property on the scope or service unit that is created. This option takes an assignment
+        in the same format as
+        <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s
+        <command>set-property</command> command.</para>
+
+        <xi:include href="version-info.xml" xpointer="v211"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--description=</option></term>
+
+        <listitem><para>Provide a description for the service, scope, path, socket, or timer unit. If not specified,
+        the command itself will be used as a description. See <varname>Description=</varname> in
+        <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v206"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--slice=</option></term>
+
+        <listitem><para>Make the new <filename>.service</filename> or <filename>.scope</filename> unit part
+        of the specified slice, instead of <filename>system.slice</filename> (when running in
+        <option>--system</option> mode) or the root slice (when running in <option>--user</option>
+        mode).</para>
+
+        <xi:include href="version-info.xml" xpointer="v206"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--slice-inherit</option></term>
+
+        <listitem><para>Make the new <filename>.service</filename> or <filename>.scope</filename> unit part
+        of the inherited slice. This option can be combined with <option>--slice=</option>.</para>
+
+        <para>An inherited slice is located within <command>systemd-run</command> slice. Example: if
+        <command>systemd-run</command> slice is <filename>foo.slice</filename>, and the
+        <option>--slice=</option> argument is <filename>bar</filename>, the unit will be placed under the
+        <filename>foo-bar.slice</filename>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v246"/>
+
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--expand-environment=<replaceable>BOOL</replaceable></option></term>
+
+        <listitem><para>Expand environment variables in command arguments. If enabled, environment variables
+        specified as <literal>${<replaceable>VARIABLE</replaceable>}</literal> will be expanded in the same
+        way as in commands specified via <varname>ExecStart=</varname> in units. With
+        <varname>--scope</varname>, this expansion is performed by <command>systemd-run</command> itself, and
+        in other cases by the service manager that spawns the command. Note that this is similar to, but not
+        the same as variable expansion in
+        <citerefentry project='man-pages'><refentrytitle>bash</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+        and other shells.</para>
+
+        <para>The default is to enable this option in all cases, except for <varname>--scope</varname> where
+        it is disabled by default, for backward compatibility reasons. Note that this will be changed in a
+        future release, where it will be switched to enabled by default as well.</para>
+
+        <para>See
+        <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for a description of variable expansion. Disabling variable expansion is useful if the specified
+        command includes or may include a <literal>$</literal> sign.</para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-r</option></term>
+        <term><option>--remain-after-exit</option></term>
+
+        <listitem><para>After the service process has terminated, keep the service around until it is explicitly
+        stopped. This is useful to collect runtime information about the service after it finished running. Also see
+        <varname>RemainAfterExit=</varname> in
+        <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v207"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--send-sighup</option></term>
+
+        <listitem><para>When terminating the scope or service unit, send a SIGHUP immediately after SIGTERM. This is
+        useful to indicate to shells and shell-like processes that the connection has been severed. Also see
+        <varname>SendSIGHUP=</varname> in
+        <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v207"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--service-type=</option></term>
+
+        <listitem><para>Sets the service type. Also see
+        <varname>Type=</varname> in
+        <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>. This
+        option has no effect in conjunction with
+        <option>--scope</option>. Defaults to
+        <constant>simple</constant>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v211"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--uid=</option></term>
+        <term><option>--gid=</option></term>
+
+        <listitem><para>Runs the service process under the specified UNIX user and group. Also see
+        <varname>User=</varname> and <varname>Group=</varname> in
+        <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v211"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--nice=</option></term>
+
+        <listitem><para>Runs the service process with the specified
+        nice level. Also see <varname>Nice=</varname> in
+        <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v211"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--working-directory=</option></term>
+
+        <listitem><para>Runs the service process with the specified working directory. Also see
+        <varname>WorkingDirectory=</varname> in
+        <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v240"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--same-dir</option></term>
+        <term><option>-d</option></term>
+
+        <listitem><para>Similar to <option>--working-directory=</option>, but uses the current working
+        directory of the caller for the service to execute.</para>
+
+        <xi:include href="version-info.xml" xpointer="v240"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-E <replaceable>NAME</replaceable>[=<replaceable>VALUE</replaceable>]</option></term>
+        <term><option>--setenv=<replaceable>NAME</replaceable>[=<replaceable>VALUE</replaceable>]</option></term>
+
+        <listitem><para>Runs the service process with the specified environment variable set. This parameter
+        may be used more than once to set multiple variables. When <literal>=</literal> and
+        <replaceable>VALUE</replaceable> are omitted, the value of the variable with the same name in the
+        program environment will be used.</para>
+
+        <para>Also see <varname>Environment=</varname> in
+        <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v211"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--pty</option></term>
+        <term><option>-t</option></term>
+
+        <listitem><para>When invoking the command, the transient service connects its standard input, output and error
+        to the terminal <command>systemd-run</command> is invoked on, via a pseudo TTY device. This allows running
+        programs that expect interactive user input/output as services, such as interactive command shells.</para>
+
+        <para>Note that
+        <citerefentry><refentrytitle>machinectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s
+        <command>shell</command> command is usually a better alternative for requesting a new, interactive login
+        session on the local host or a local container.</para>
+
+        <para>See below for details on how this switch combines with <option>--pipe</option>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v219"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--pipe</option></term>
+        <term><option>-P</option></term>
+
+        <listitem><para>If specified, standard input, output, and error of the transient service are inherited from the
+        <command>systemd-run</command> command itself. This allows <command>systemd-run</command>
+        to be used within shell pipelines.
+        Note that this mode is not suitable for interactive command shells and similar, as the
+        service process will not become a TTY controller when invoked on a terminal. Use <option>--pty</option> instead
+        in that case.</para>
+
+        <para>When both <option>--pipe</option> and <option>--pty</option> are used in combination the more appropriate
+        option is automatically determined and used. Specifically, when invoked with standard input, output and error
+        connected to a TTY <option>--pty</option> is used, and otherwise <option>--pipe</option>.</para>
+
+        <para>When this option is used the original file descriptors <command>systemd-run</command> receives are passed
+        to the service processes as-is. If the service runs with different privileges than
+        <command>systemd-run</command>, this means the service might not be able to re-open the passed file
+        descriptors, due to normal file descriptor access restrictions. If the invoked process is a shell script that
+        uses the <command>echo "hello" >/dev/stderr</command> construct for writing messages to stderr, this might
+        cause problems, as this only works if stderr can be re-opened. To mitigate this use the construct <command>echo
+        "hello" >&amp;2</command> instead, which is mostly equivalent and avoids this pitfall.</para>
+
+        <xi:include href="version-info.xml" xpointer="v235"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--shell</option></term>
+        <term><option>-S</option></term>
+
+        <listitem><para>A shortcut for <literal>--pty --same-dir --wait --collect --service-type=exec $SHELL</literal>,
+        i.e. requests an interactive shell in the current working directory, running in service context, accessible
+        with a single switch.</para>
+
+        <xi:include href="version-info.xml" xpointer="v240"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--quiet</option></term>
+        <term><option>-q</option></term>
+
+        <listitem><para>Suppresses additional informational output
+        while running. This is particularly useful in combination with
+        <option>--pty</option> when it will suppress the initial
+        message explaining how to terminate the TTY connection.</para>
+
+        <xi:include href="version-info.xml" xpointer="v219"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--on-active=</option></term>
+        <term><option>--on-boot=</option></term>
+        <term><option>--on-startup=</option></term>
+        <term><option>--on-unit-active=</option></term>
+        <term><option>--on-unit-inactive=</option></term>
+
+        <listitem><para>Defines a monotonic timer relative to different starting points for starting the specified
+        command. See <varname>OnActiveSec=</varname>, <varname>OnBootSec=</varname>, <varname>OnStartupSec=</varname>,
+        <varname>OnUnitActiveSec=</varname> and <varname>OnUnitInactiveSec=</varname> in
+        <citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
+        details. These options are shortcuts for <command>--timer-property=</command> with the relevant properties.
+        These options may not be combined with <option>--scope</option> or <option>--pty</option>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v218"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--on-calendar=</option></term>
+
+        <listitem><para>Defines a calendar timer for starting the specified command. See <varname>OnCalendar=</varname>
+        in <citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry>. This
+        option is a shortcut for <command>--timer-property=OnCalendar=</command>. This option may not be combined with
+        <option>--scope</option> or <option>--pty</option>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v218"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--on-clock-change</option></term>
+        <term><option>--on-timezone-change</option></term>
+
+        <listitem><para>Defines a trigger based on system clock jumps or timezone changes for starting the
+        specified command. See <varname>OnClockChange=</varname> and <varname>OnTimezoneChange=</varname> in
+        <citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry>. These
+        options are shortcuts for <command>--timer-property=OnClockChange=yes</command> and
+        <command>--timer-property=OnTimezoneChange=yes</command>. These options may not be combined with
+        <option>--scope</option> or <option>--pty</option>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v242"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--path-property=</option></term>
+        <term><option>--socket-property=</option></term>
+        <term><option>--timer-property=</option></term>
+
+        <listitem><para>Sets a property on the path, socket, or timer unit that is created. This option is
+        similar to <option>--property=</option>, but applies to the transient path, socket, or timer unit
+        rather than the transient service unit created. This option takes an assignment in the same format as
+        <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s
+        <command>set-property</command> command. These options may not be combined with
+        <option>--scope</option> or <option>--pty</option>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v218"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--no-block</option></term>
+
+        <listitem>
+          <para>Do not synchronously wait for the unit start operation to finish. If this option is not specified, the
+          start request for the transient unit will be verified, enqueued and <command>systemd-run</command> will wait
+          until the unit's start-up is completed. By passing this argument, it is only verified and enqueued. This
+          option may not be combined with <option>--wait</option>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v220"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--wait</option></term>
+
+        <listitem><para>Synchronously wait for the transient service to terminate. If this option is specified, the
+        start request for the transient unit is verified, enqueued, and waited for. Subsequently the invoked unit is
+        monitored, and it is waited until it is deactivated again (most likely because the specified command
+        completed). On exit, terse information about the unit's runtime is shown, including total runtime (as well as
+        CPU usage, if <option>--property=CPUAccounting=1</option> was set) and the exit code and status of the main
+        process. This output may be suppressed with <option>--quiet</option>. This option may not be combined with
+        <option>--no-block</option>, <option>--scope</option> or the various path, socket, or timer options.</para>
+
+        <xi:include href="version-info.xml" xpointer="v232"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-G</option></term>
+        <term><option>--collect</option></term>
+
+        <listitem><para>Unload the transient unit after it completed, even if it failed. Normally, without this option,
+        all units that ran and failed are kept in memory until the user explicitly resets their failure state with
+        <command>systemctl reset-failed</command> or an equivalent command. On the other hand, units that ran
+        successfully are unloaded immediately. If this option is turned on the "garbage collection" of units is more
+        aggressive, and unloads units regardless if they exited successfully or failed. This option is a shortcut for
+        <command>--property=CollectMode=inactive-or-failed</command>, see the explanation for
+        <varname>CollectMode=</varname> in
+        <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> for further
+        information.</para>
+
+        <xi:include href="version-info.xml" xpointer="v236"/></listitem>
+      </varlistentry>
+
+      <xi:include href="user-system-options.xml" xpointer="user" />
+      <xi:include href="user-system-options.xml" xpointer="system" />
+      <xi:include href="user-system-options.xml" xpointer="host" />
+      <xi:include href="user-system-options.xml" xpointer="machine" />
+
+      <xi:include href="standard-options.xml" xpointer="help" />
+      <xi:include href="standard-options.xml" xpointer="version" />
+    </variablelist>
+
+    <para>All command line arguments after the first non-option argument become part of the command line of
+    the launched process.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Exit status</title>
+
+    <para>On success, 0 is returned. If <command>systemd-run</command> failed to start the service, a
+    non-zero return value will be returned. If <command>systemd-run</command> waits for the service to
+    terminate, the return value will be propagated from the service. 0 will be returned on success, including
+    all the cases where systemd considers a service to have exited cleanly, see the discussion of
+    <varname>SuccessExitStatus=</varname> in
+    <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+    </para>
+  </refsect1>
+
+  <refsect1>
+    <title>Examples</title>
+
+    <example>
+      <title>Logging environment variables provided by systemd to services</title>
+
+      <programlisting># systemd-run env
+Running as unit: run-19945.service
+# journalctl -u run-19945.service
+Sep 08 07:37:21 bupkis systemd[1]: Starting /usr/bin/env...
+Sep 08 07:37:21 bupkis systemd[1]: Started /usr/bin/env.
+Sep 08 07:37:21 bupkis env[19948]: PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin
+Sep 08 07:37:21 bupkis env[19948]: LANG=en_US.UTF-8
+Sep 08 07:37:21 bupkis env[19948]: BOOT_IMAGE=/vmlinuz-3.11.0-0.rc5.git6.2.fc20.x86_64</programlisting>
+    </example>
+
+    <example>
+      <title>Limiting resources available to a command</title>
+
+      <programlisting># systemd-run -p IOWeight=10 updatedb</programlisting>
+
+      <para>This command invokes the <citerefentry
+      project='man-pages'><refentrytitle>updatedb</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+      tool, but lowers the block I/O weight for it to 10. See
+      <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+      for more information on the <varname>IOWeight=</varname> property.</para>
+    </example>
+
+    <example>
+      <title>Running commands at a specified time</title>
+
+      <para>The following command will touch a file after 30 seconds.</para>
+
+      <programlisting># date; systemd-run --on-active=30 --timer-property=AccuracySec=100ms /bin/touch /tmp/foo
+Mon Dec  8 20:44:24 KST 2014
+Running as unit: run-71.timer
+Will run service as unit: run-71.service
+# journalctl -b -u run-71.timer
+-- Journal begins at Fri 2014-12-05 19:09:21 KST, ends at Mon 2014-12-08 20:44:54 KST. --
+Dec 08 20:44:38 container systemd[1]: Starting /bin/touch /tmp/foo.
+Dec 08 20:44:38 container systemd[1]: Started /bin/touch /tmp/foo.
+# journalctl -b -u run-71.service
+-- Journal begins at Fri 2014-12-05 19:09:21 KST, ends at Mon 2014-12-08 20:44:54 KST. --
+Dec 08 20:44:48 container systemd[1]: Starting /bin/touch /tmp/foo...
+Dec 08 20:44:48 container systemd[1]: Started /bin/touch /tmp/foo.</programlisting>
+    </example>
+
+    <example>
+      <title>Allowing access to the tty</title>
+
+      <para>The following command invokes
+      <citerefentry project='man-pages'><refentrytitle>bash</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+      as a service passing its standard input, output and error to the calling TTY.</para>
+
+      <programlisting># systemd-run -t --send-sighup bash</programlisting>
+    </example>
+
+    <example>
+      <title>Start <command>screen</command> as a user service</title>
+
+      <programlisting>$ systemd-run --scope --user screen
+Running scope as unit run-r14b0047ab6df45bfb45e7786cc839e76.scope.
+
+$ screen -ls
+There is a screen on:
+        492..laptop     (Detached)
+1 Socket in /var/run/screen/S-fatima.
+</programlisting>
+
+      <para>This starts the <command>screen</command> process as a child of the
+      <command>systemd --user</command> process that was started by
+      <filename>user@.service</filename>, in a scope unit. A
+      <citerefentry><refentrytitle>systemd.scope</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+      unit is used instead of a
+      <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+      unit, because <command>screen</command> will exit when detaching from the terminal,
+      and a service unit would be terminated. Running <command>screen</command>
+      as a user unit has the advantage that it is not part of the session scope.
+      If <varname>KillUserProcesses=yes</varname> is configured in
+      <citerefentry><refentrytitle>logind.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      the default, the session scope will be terminated when the user logs
+      out of that session.</para>
+
+      <para>The <filename>user@.service</filename> is started automatically
+      when the user first logs in, and stays around as long as at least one
+      login session is open. After the user logs out of the last session,
+      <filename>user@.service</filename> and all services underneath it
+      are terminated. This behavior is the default, when "lingering" is
+      not enabled for that user. Enabling lingering means that
+      <filename>user@.service</filename> is started automatically during
+      boot, even if the user is not logged in, and that the service is
+      not terminated when the user logs out.</para>
+
+      <para>Enabling lingering allows the user to run processes without being logged in,
+      for example to allow <command>screen</command> to persist after the user logs out,
+      even if the session scope is terminated. In the default configuration, users can
+      enable lingering for themselves:</para>
+
+      <programlisting>$ loginctl enable-linger</programlisting>
+    </example>
+
+    <example>
+      <title>Variable expansion by the manager</title>
+
+      <programlisting>$ systemd-run -t echo "&lt;${INVOCATION_ID}>" '&lt;${INVOCATION_ID}>'
+      &lt;> &lt;5d0149bfa2c34b79bccb13074001eb20>
+      </programlisting>
+
+      <para>The first argument is expanded by the shell (double quotes), but the second one is not expanded
+      by the shell (single quotes).
+      <citerefentry project='man-pages'><refentrytitle>echo</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+      is called with [<literal>/usr/bin/echo</literal>,
+      <literal>&lt;></literal>, <literal>&lt;${INVOCATION_ID}></literal>] as the argument array, and then
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+      generates <varname>${INVOCATION_ID}</varname> and substitutes it in the command-line. This substitution
+      could not be done on the client side, because the target ID that will be set for the service isn't
+      known before the call is made.</para>
+    </example>
+
+    <example>
+      <title>Variable expansion and output redirection using a shell</title>
+
+      <para>Variable expansion by
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+      can be disabled with <varname>--expand-environment=no</varname>.</para>
+
+      <para>Disabling variable expansion can be useful if the command to execute contains dollar characters
+      and escaping them would be inconvenient. For example, when a shell is used:</para>
+
+      <programlisting>$ systemd-run --expand-environment=no -t bash \
+      -c 'echo $SHELL $$ >/dev/stdout'
+/bin/bash 12345
+      </programlisting>
+
+      <para>The last argument is passed verbatim to the
+      <citerefentry project='man-pages'><refentrytitle>bash</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+      shell which is started by the service unit. The shell expands <literal>$SHELL</literal> to the path of
+      the shell, and <literal>$$</literal> to its process number, and then those strings are passed to the
+      <command>echo</command> built-in and printed to standard output (which in this case is connected to the
+      calling terminal).</para>
+    </example>
+
+    <example>
+      <title>Return value</title>
+
+      <programlisting>$ systemd-run --user --wait true
+$ systemd-run --user --wait -p SuccessExitStatus=11 bash -c 'exit 11'
+$ systemd-run --user --wait -p SuccessExitStatus=SIGUSR1 --expand-environment=no \
+      bash -c 'kill -SIGUSR1 $$'</programlisting>
+
+      <para>Those three invocations will succeed, i.e. terminate with an exit code of 0.</para>
+    </example>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.scope</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-mount</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>machinectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-sleep.conf.xml b/man/systemd-sleep.conf.xml
new file mode 100644
index 0000000..7c2adb0
--- /dev/null
+++ b/man/systemd-sleep.conf.xml
@@ -0,0 +1,246 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd-sleep.conf"
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+  <refentryinfo>
+    <title>systemd-sleep.conf</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-sleep.conf</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-sleep.conf</refname>
+    <refname>sleep.conf.d</refname>
+    <refpurpose>Suspend and hibernation configuration file</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>/etc/systemd/sleep.conf</filename></para>
+    <para><filename>/etc/systemd/sleep.conf.d/*.conf</filename></para>
+    <para><filename>/run/systemd/sleep.conf.d/*.conf</filename></para>
+    <para><filename>/usr/lib/systemd/sleep.conf.d/*.conf</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>systemd</command> supports four general
+    power-saving modes:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term>suspend</term>
+
+        <listitem><para>a low-power state
+        where execution of the OS is paused,
+        and complete power loss might result
+        in lost data, and which is fast to
+        enter and exit. This corresponds to
+        suspend, standby, or freeze states as
+        understood by the kernel.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v203"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term>hibernate</term>
+
+        <listitem><para>a low-power state
+        where execution of the OS is paused,
+        and complete power loss does not
+        result in lost data, and which might
+        be slow to enter and exit. This
+        corresponds to the hibernation as
+        understood by the kernel.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v203"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term>hybrid-sleep</term>
+
+        <listitem><para>a low-power state
+        where execution of the OS is paused,
+        which might be slow to enter, and on
+        complete power loss does not result in
+        lost data but might be slower to exit
+        in that case. This mode is called
+        suspend-to-both by the kernel.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v203"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term>suspend-then-hibernate</term>
+
+        <listitem>
+          <para>A low power state where the system is initially suspended (the state is stored in RAM).
+          When the battery level is too low (less than 5%) or a certain timespan has passed, whichever
+          happens first, the system is automatically woken up and then hibernated. This establishes a balance
+          between speed and safety.</para>
+
+          <para>If the system has no battery, it would be hibernated after <varname>HibernateDelaySec=</varname>
+          has passed. If not set, then defaults to <literal>2h</literal>.</para>
+
+          <para>If the system has battery and <varname>HibernateDelaySec=</varname> is not set, low-battery
+          alarms (ACPI _BTP) are tried first for detecting battery percentage and wake up the system for hibernation.
+          If not available, or <varname>HibernateDelaySec=</varname> is set, the system would regularly wake
+          up to check the time and detect the battery percentage/discharging rate. The rate is used to
+          schedule the next detection. If that is also not available, <varname>SuspendEstimationSec=</varname>
+          is used as last resort.</para>
+
+          <xi:include href="version-info.xml" xpointer="v239"/>
+        </listitem>
+      </varlistentry>
+
+    </variablelist>
+
+    <para>Settings in these files determine what strings
+    will be written to
+    <filename>/sys/power/disk</filename> and
+    <filename>/sys/power/state</filename> by
+    <citerefentry><refentrytitle>systemd-sleep</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    when
+    <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    attempts to suspend or hibernate the machine.
+    See
+    <citerefentry><refentrytitle>systemd.syntax</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+    for a general description of the syntax.</para>
+  </refsect1>
+
+  <xi:include href="standard-conf.xml" xpointer="main-conf" />
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>The following options can be configured in the
+    [Sleep] section of
+    <filename>/etc/systemd/sleep.conf</filename> or a
+    <filename>sleep.conf.d</filename> file:</para>
+
+    <variablelist class='config-directives'>
+      <varlistentry>
+        <term><varname>AllowSuspend=</varname></term>
+        <term><varname>AllowHibernation=</varname></term>
+        <term><varname>AllowHybridSleep=</varname></term>
+        <term><varname>AllowSuspendThenHibernate=</varname></term>
+
+        <listitem><para>By default any power-saving mode is advertised if possible (i.e.
+        the kernel supports that mode, the necessary resources are available). Those
+        switches can be used to disable specific modes.</para>
+
+        <para>If <varname>AllowHibernation=no</varname> or <varname>AllowSuspend=no</varname> is
+        used, this implies <varname>AllowSuspendThenHibernate=no</varname> and
+        <varname>AllowHybridSleep=no</varname>, since those methods use both suspend and hibernation
+        internally. <varname>AllowSuspendThenHibernate=yes</varname> and
+        <varname>AllowHybridSleep=yes</varname> can be used to override and enable those specific
+        modes.</para>
+
+        <xi:include href="version-info.xml" xpointer="v240"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>HibernateMode=</varname></term>
+
+        <listitem><para>The string to be written to <filename>/sys/power/disk</filename> by <citerefentry>
+        <refentrytitle>systemd-hibernate.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+        More than one value can be specified by separating multiple values with whitespace. They will be
+        tried in turn, until one is written without error. If none of the writes succeed, the operation will
+        be aborted.</para>
+
+        <para>The allowed set of values is determined by the kernel and is shown in the file itself (use
+        <command>cat /sys/power/disk</command> to display). See the kernel documentation page
+        <ulink url="https://www.kernel.org/doc/html/latest/admin-guide/pm/sleep-states.html#basic-sysfs-interfaces-for-system-suspend-and-hibernation">
+          Basic sysfs Interfaces for System Suspend and Hibernation</ulink> for more details.</para>
+
+        <para>
+        <citerefentry><refentrytitle>systemd-suspend-then-hibernate.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        uses the value of <varname>HibernateMode=</varname> when hibernating.</para>
+
+        <xi:include href="version-info.xml" xpointer="v203"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SuspendState=</varname></term>
+
+        <listitem><para>The string to be written to <filename>/sys/power/state</filename> by <citerefentry>
+        <refentrytitle>systemd-suspend.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+        More than one value can be specified by separating multiple values with whitespace. They will be
+        tried in turn, until one is written without error. If none of the writes succeed, the operation will
+        be aborted.</para>
+
+        <para>The allowed set of values is determined by the kernel and is shown in the file itself (use
+        <command>cat /sys/power/state</command> to display). See <ulink
+        url="https://www.kernel.org/doc/html/latest/admin-guide/pm/sleep-states.html#basic-sysfs-interfaces-for-system-suspend-and-hibernation">
+          Basic sysfs Interfaces for System Suspend and Hibernation</ulink> for more details.</para>
+
+        <para>
+        <citerefentry><refentrytitle>systemd-suspend-then-hibernate.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        uses this value when suspending.</para>
+
+        <xi:include href="version-info.xml" xpointer="v203"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>HibernateDelaySec=</varname></term>
+
+        <listitem>
+          <para>The amount of time the system spends in suspend mode before the system is
+          automatically put into hibernate mode. Only used by
+          <citerefentry><refentrytitle>systemd-suspend-then-hibernate.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+          Refer to <command>suspend-then-hibernate</command> for details on how this option interacts with
+          other options/system battery state.</para>
+
+          <xi:include href="version-info.xml" xpointer="v239"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SuspendEstimationSec=</varname></term>
+
+        <listitem>
+          <para>The RTC alarm will wake the system after the specified timespan to measure the system battery
+          capacity level and estimate battery discharging rate. Only used by
+          <citerefentry><refentrytitle>systemd-suspend-then-hibernate.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+          Refer to <command>suspend-then-hibernate</command> for details on how this option interacts with
+          other options/system battery state.</para>
+
+          <xi:include href="version-info.xml" xpointer="v253"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Example: freeze</title>
+
+    <para>Example: to exploit the <quote>freeze</quote> mode added
+    in Linux 3.9, one can use <command>systemctl suspend</command>
+    with
+    <programlisting>[Sleep]
+SuspendState=freeze</programlisting></para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd-sleep</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-suspend.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-hibernate.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-hybrid-sleep.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-suspend-then-hibernate.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-socket-activate.xml b/man/systemd-socket-activate.xml
new file mode 100644
index 0000000..1250725
--- /dev/null
+++ b/man/systemd-socket-activate.xml
@@ -0,0 +1,200 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd-socket-activate"
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd-socket-activate</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-socket-activate</refentrytitle>
+    <manvolnum>1</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-socket-activate</refname>
+    <refpurpose>Test socket activation of daemons</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <cmdsynopsis>
+      <command>systemd-socket-activate</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="plain"><replaceable>daemon</replaceable></arg>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+    </cmdsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>systemd-socket-activate</command> may be used to launch a socket-activated service program from the
+    command line for testing purposes. It may also be used to launch individual instances of the service program per
+    connection.
+    </para>
+
+    <para>The daemon to launch and its options should be specified
+    after options intended for <command>systemd-socket-activate</command>.
+    </para>
+
+    <para>If the <option>--inetd</option> option is given, the socket file descriptor will be used as the standard
+    input and output of the launched process. Otherwise, standard input and output will be inherited, and sockets will
+    be passed through file descriptors 3 and higher. Sockets passed through <varname>$LISTEN_FDS</varname> to
+    <command>systemd-socket-activate</command> will be passed through to the daemon, in the original positions. Other sockets
+    specified with <option>--listen=</option> will use consecutive descriptors.  By default,
+    <command>systemd-socket-activate</command> listens on a stream socket, use <option>--datagram</option> and
+    <option>--seqpacket</option> to listen on datagram or sequential packet sockets instead (see below).
+    </para>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+    <variablelist>
+      <varlistentry>
+        <term><option>-l <replaceable>address</replaceable></option></term>
+        <term><option>--listen=<replaceable>address</replaceable></option></term>
+
+        <listitem><para>Listen on this <replaceable>address</replaceable>.
+        Takes a string like <literal>2000</literal> or
+        <literal>127.0.0.1:2001</literal>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v230"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-a</option></term>
+        <term><option>--accept</option></term>
+
+        <listitem><para>Launch an instance of the service program for each connection and pass the connection
+        socket.</para>
+
+        <xi:include href="version-info.xml" xpointer="v230"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-d</option></term>
+        <term><option>--datagram</option></term>
+
+        <listitem><para>Listen on a datagram socket (<constant>SOCK_DGRAM</constant>), instead of a stream socket
+        (<constant>SOCK_STREAM</constant>). May not be combined with <option>--seqpacket</option>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v230"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--seqpacket</option></term>
+
+        <listitem><para>Listen on a sequential packet socket (<constant>SOCK_SEQPACKET</constant>), instead of a stream
+        socket (<constant>SOCK_STREAM</constant>). May not be combined with
+        <option>--datagram</option>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v230"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--inetd</option></term>
+
+        <listitem><para>Use the inetd protocol for passing file descriptors, i.e. as standard input and standard
+        output, instead of the new-style protocol for passing file descriptors using <varname>$LISTEN_FDS</varname>
+        (see above).</para>
+
+        <xi:include href="version-info.xml" xpointer="v230"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-E <replaceable>VAR</replaceable><optional>=<replaceable>VALUE</replaceable></optional></option></term>
+        <term><option>--setenv=<replaceable>VAR</replaceable><optional>=<replaceable>VALUE</replaceable></optional></option></term>
+
+        <listitem><para>Add this variable to the environment of the
+        launched process. If <replaceable>VAR</replaceable> is
+        followed by <literal>=</literal>, assume that it is a
+        variable–value pair. Otherwise, obtain the value from the
+        environment of <command>systemd-socket-activate</command> itself.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v230"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--fdname=</option><replaceable>NAME</replaceable><optional>:<replaceable>NAME</replaceable>…</optional></term>
+
+        <listitem><para>Specify names for the file descriptors passed. This is equivalent to setting
+        <varname>FileDescriptorName=</varname> in socket unit files, and enables use of
+        <citerefentry><refentrytitle>sd_listen_fds_with_names</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+        Multiple entries may be specifies using separate options or by separating names with colons
+        (<literal>:</literal>) in one option. In case more names are given than descriptors, superfluous ones will be
+        ignored. In case less names are given than descriptors, the remaining file descriptors will be unnamed.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v230"/></listitem>
+      </varlistentry>
+
+      <xi:include href="standard-options.xml" xpointer="help" />
+      <xi:include href="standard-options.xml" xpointer="version" />
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Environment variables</title>
+    <variablelist class='environment-variables'>
+      <varlistentry>
+        <term><varname>$LISTEN_FDS</varname></term>
+        <term><varname>$LISTEN_PID</varname></term>
+        <term><varname>$LISTEN_FDNAMES</varname></term>
+
+        <listitem><para>See
+        <citerefentry><refentrytitle>sd_listen_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v230"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>$SYSTEMD_LOG_TARGET</varname></term>
+        <term><varname>$SYSTEMD_LOG_LEVEL</varname></term>
+        <term><varname>$SYSTEMD_LOG_TIME</varname></term>
+        <term><varname>$SYSTEMD_LOG_COLOR</varname></term>
+        <term><varname>$SYSTEMD_LOG_LOCATION</varname></term>
+
+        <listitem><para>Same as in
+        <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v230"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Examples</title>
+
+    <example>
+      <title>Run an echo server on port 2000</title>
+
+      <programlisting>$ systemd-socket-activate -l 2000 --inetd -a cat</programlisting>
+    </example>
+
+    <example>
+      <title>Run a socket-activated instance of <citerefentry><refentrytitle>systemd-journal-gatewayd</refentrytitle><manvolnum>8</manvolnum></citerefentry></title>
+
+      <programlisting>$ systemd-socket-activate -l 19531 /usr/lib/systemd/systemd-journal-gatewayd</programlisting>
+    </example>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-run</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_listen_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd_listen_fds_with_names</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>cat</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+</refentry>
diff --git a/man/systemd-socket-proxyd.xml b/man/systemd-socket-proxyd.xml
new file mode 100644
index 0000000..57a6827
--- /dev/null
+++ b/man/systemd-socket-proxyd.xml
@@ -0,0 +1,190 @@
+<?xml version="1.0"?>
+<!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+<refentry id="systemd-socket-proxyd"
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd-socket-proxyd</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+  <refmeta>
+    <refentrytitle>systemd-socket-proxyd</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+  <refnamediv>
+    <refname>systemd-socket-proxyd</refname>
+    <refpurpose>Bidirectionally proxy local sockets to another (possibly remote) socket</refpurpose>
+  </refnamediv>
+  <refsynopsisdiv>
+    <cmdsynopsis>
+      <command>systemd-socket-proxyd</command>
+      <arg choice="opt" rep="repeat"><replaceable>OPTIONS</replaceable></arg>
+      <arg choice="plain"><replaceable>HOST</replaceable>:<replaceable>PORT</replaceable></arg>
+    </cmdsynopsis>
+    <cmdsynopsis>
+      <command>systemd-socket-proxyd</command>
+      <arg choice="opt" rep="repeat"><replaceable>OPTIONS</replaceable></arg>
+      <arg choice="plain"><replaceable>UNIX-DOMAIN-SOCKET-PATH</replaceable>
+      </arg>
+    </cmdsynopsis>
+  </refsynopsisdiv>
+  <refsect1>
+    <title>Description</title>
+    <para>
+    <command>systemd-socket-proxyd</command> is a generic
+    socket-activated network socket forwarder proxy daemon for IPv4,
+    IPv6 and UNIX stream sockets. It may be used to bi-directionally
+    forward traffic from a local listening socket to a local or remote
+    destination socket.</para>
+
+    <para>One use of this tool is to provide socket activation support
+    for services that do not natively support socket activation. On
+    behalf of the service to activate, the proxy inherits the socket
+    from systemd, accepts each client connection, opens a connection
+    to a configured server for each client, and then bidirectionally
+    forwards data between the two.</para>
+    <para>This utility's behavior is similar to
+    <citerefentry project='die-net'><refentrytitle>socat</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
+    The main differences for <command>systemd-socket-proxyd</command>
+    are support for socket activation with
+    <literal>Accept=no</literal> and an event-driven
+    design that scales better with the number of
+    connections.</para>
+  </refsect1>
+  <refsect1>
+    <title>Options</title>
+    <para>The following options are understood:</para>
+    <variablelist>
+      <xi:include href="standard-options.xml" xpointer="help" />
+      <xi:include href="standard-options.xml" xpointer="version" />
+      <varlistentry>
+        <term><option>--connections-max=</option></term>
+        <term><option>-c</option></term>
+
+        <listitem><para>Sets the maximum number of simultaneous connections, defaults to 256.
+        If the limit of concurrent connections is reached further connections will be refused.</para>
+
+        <xi:include href="version-info.xml" xpointer="v233"/></listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><option>--exit-idle-time=</option></term>
+
+        <listitem><para>Sets the time before exiting when there are no connections, defaults to
+        <constant>infinity</constant>. Takes a unit-less value in seconds, or a time span value such
+        as <literal>5min 20s</literal>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+  <refsect1>
+    <title>Exit status</title>
+    <para>On success, 0 is returned, a non-zero failure
+    code otherwise.</para>
+  </refsect1>
+  <refsect1>
+    <title>Examples</title>
+    <refsect2>
+      <title>Simple Example</title>
+      <para>Use two services with a dependency and no namespace
+      isolation.</para>
+      <example>
+        <title>proxy-to-nginx.socket</title>
+        <programlisting><![CDATA[[Socket]
+ListenStream=80
+
+[Install]
+WantedBy=sockets.target]]></programlisting>
+      </example>
+      <example>
+        <title>proxy-to-nginx.service</title>
+        <programlisting><![CDATA[[Unit]
+Requires=nginx.service
+After=nginx.service
+Requires=proxy-to-nginx.socket
+After=proxy-to-nginx.socket
+
+[Service]
+Type=notify
+ExecStart=/usr/lib/systemd/systemd-socket-proxyd /run/nginx/socket
+PrivateTmp=yes
+PrivateNetwork=yes]]></programlisting>
+      </example>
+      <example>
+        <title>nginx.conf</title>
+        <programlisting>
+<![CDATA[[…]
+server {
+    listen       unix:/run/nginx/socket;
+    […]]]>
+</programlisting>
+      </example>
+      <example>
+        <title>Enabling the proxy</title>
+        <programlisting><![CDATA[# systemctl enable --now proxy-to-nginx.socket
+$ curl http://localhost:80/]]></programlisting>
+      </example>
+      <para>If <filename>nginx.service</filename> has <varname>StopWhenUnneeded=</varname> set, then
+      passing <option>--exit-idle-time=</option> to <command>systemd-socket-proxyd</command> allows
+      both services to stop during idle periods.</para>
+    </refsect2>
+    <refsect2>
+      <title>Namespace Example</title>
+      <para>Similar as above, but runs the socket proxy and the main
+      service in the same private namespace, assuming that
+      <filename>nginx.service</filename> has
+      <varname>PrivateTmp=</varname> and
+      <varname>PrivateNetwork=</varname> set, too.</para>
+      <example>
+        <title>proxy-to-nginx.socket</title>
+        <programlisting><![CDATA[[Socket]
+ListenStream=80
+
+[Install]
+WantedBy=sockets.target]]></programlisting>
+      </example>
+      <example>
+        <title>proxy-to-nginx.service</title>
+        <programlisting><![CDATA[[Unit]
+Requires=nginx.service
+After=nginx.service
+Requires=proxy-to-nginx.socket
+After=proxy-to-nginx.socket
+JoinsNamespaceOf=nginx.service
+
+[Service]
+Type=notify
+ExecStart=/usr/lib/systemd/systemd-socket-proxyd 127.0.0.1:8080
+PrivateTmp=yes
+PrivateNetwork=yes]]></programlisting>
+      </example>
+      <example>
+        <title>nginx.conf</title>
+        <programlisting><![CDATA[[…]
+server {
+    listen       8080;
+    […]]]></programlisting>
+      </example>
+      <example>
+        <title>Enabling the proxy</title>
+        <programlisting><![CDATA[# systemctl enable --now proxy-to-nginx.socket
+$ curl http://localhost:80/]]></programlisting>
+      </example>
+    </refsect2>
+  </refsect1>
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry project='die-net'><refentrytitle>socat</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry project='die-net'><refentrytitle>nginx</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry project='die-net'><refentrytitle>curl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+</refentry>
diff --git a/man/systemd-soft-reboot.service.xml b/man/systemd-soft-reboot.service.xml
new file mode 100644
index 0000000..e83e18f
--- /dev/null
+++ b/man/systemd-soft-reboot.service.xml
@@ -0,0 +1,192 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd-soft-reboot.service"
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd-soft-reboot.service</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-soft-reboot.service</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-soft-reboot.service</refname>
+    <refpurpose>Userspace reboot operation</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>systemd-soft-reboot.service</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><filename>systemd-soft-reboot.service</filename> is a system service that is pulled in by
+    <filename>soft-reboot.target</filename> and is responsible for performing a userspace-only reboot
+    operation. When invoked, it will send the <constant>SIGTERM</constant> signal to any processes left
+    running (but does not wait for the processes to exit), and follow up with <constant>SIGKILL</constant>.
+    If the <filename>/run/nextroot/</filename> directory exists (which may be a regular directory, a
+    directory mount point or a symlink to either) then it will switch the file system root to it. It then
+    reexecutes the service manager off the (possibly now new) root file system, which will enqueue a new boot
+    transaction as in a normal reboot.</para>
+
+    <para>Such a userspace-only reboot operation permits updating or resetting the entirety of userspace with
+    minimal downtime, as the reboot operation does <emphasis>not</emphasis> transition through:</para>
+
+    <itemizedlist>
+      <listitem><para>The second phase of regular shutdown, as implemented by
+      <citerefentry><refentrytitle>systemd-shutdown</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para></listitem>
+
+      <listitem><para>The third phase of regular shutdown, i.e. the return to the initrd context.
+      </para></listitem>
+
+      <listitem><para>The hardware reboot operation.</para></listitem>
+
+      <listitem><para>The firmware initialization.</para></listitem>
+
+      <listitem><para>The boot loader initialization.</para></listitem>
+
+      <listitem><para>The kernel initialization.</para></listitem>
+
+      <listitem><para>The initrd initialization.</para></listitem>
+    </itemizedlist>
+
+    <para>However this form of reboot comes with drawbacks as well:</para>
+
+    <itemizedlist>
+      <listitem><para>The OS update remains incomplete, as the kernel is not reset and continues
+      running.</para></listitem>
+
+      <listitem><para>Kernel settings (such as <filename>/proc/sys/</filename> settings, a.k.a. "sysctl", or
+      <filename>/sys/</filename> settings) are not reset.</para></listitem>
+    </itemizedlist>
+
+    <para>These limitations may be addressed by various means, which are outside of the scope of this
+    documentation, such as kernel live-patching and sufficiently comprehensive
+    <filename>/etc/sysctl.d/</filename> files.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Resource Pass-Through</title>
+
+    <para>Various runtime OS resources can passed from a system runtime to the next, through the userspace
+    reboot operation. Specifically:</para>
+
+    <itemizedlist>
+      <listitem><para>File descriptors placed in the file descriptor store of services that remain active
+      until the very end are passed to the next boot, where they are placed in the file descriptor store of
+      the same unit. For this to work, units must declare <varname>DefaultDependencies=no</varname> (and
+      avoid a manual <varname>Conflicts=shutdown.target</varname> or similar) to ensure they are not
+      terminated as usual during the system shutdown operation. Alternatively, use
+      <varname>FileDescriptorStorePreserve=</varname> to allow the file descriptor store to remain pinned
+      even when the unit is down. See
+      <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
+      details about the file descriptor store.</para></listitem>
+
+      <listitem><para>Similar to this, file descriptors associated with <filename>.socket</filename> units
+      remain open (and connectible) if the units are not stopped during the transition. (Achieved by
+      <varname>DefaultDependencies=no</varname>.)</para></listitem>
+
+      <listitem><para>The <filename>/run/</filename> file system remains mounted and populated and may be
+      used to pass state information between such userspace reboot cycles.</para></listitem>
+
+      <listitem><para>Service processes may continue to run over the transition, past soft-reboot and into
+      the next session, if they are placed in services that remain active until the very end of shutdown
+      (which again is achieved via <varname>DefaultDependencies=no</varname>). They must also be set up to
+      avoid being killed by the aforementioned <constant>SIGTERM</constant> and <constant>SIGKILL</constant>
+      via <varname>SurviveFinalKillSignal=yes</varname>, and also be configured to avoid being stopped on
+      isolate via <varname>IgnoreOnIsolate=yes</varname>. They also have to be configured to be stopped on
+      normal shutdown, reboot and maintenance mode. Finally, they have to be ordered after
+      <constant>basic.target</constant> to ensure correct ordeering on boot. Note that in case any new or
+      custom units are used to isolate to, or that implement an equivalent shutdown functionality, they will
+      also have to be configured manually for correct ordering and conflicting. For example:</para>
+
+      <programlisting>[Unit]
+Description=My surviving service
+SurviveFinalKillSignal=yes
+IgnoreOnIsolate=yes
+DefaultDependencies=no
+After=basic.target
+Conflicts=reboot.target
+Before=reboot.target
+Conflicts=kexec.target
+Before=kexec.target
+Conflicts=poweroff.target
+Before=poweroff.target
+Conflicts=halt.target
+Before=halt.target
+Conflicts=rescue.target
+Before=rescue.target
+Conflicts=emergency.target
+Before=emergency.target
+
+[Service]
+Type=oneshot
+ExecStart=sleep infinity
+      </programlisting>
+      </listitem>
+
+      <listitem><para>File system mounts may remain mounted during the transition, and complex storage
+      attached, if configured to remain until the very end of the shutdown process. (Also achieved via
+      <varname>DefaultDependencies=no</varname>, and by avoiding
+      <varname>Conflicts=umount.target</varname>)</para></listitem>
+
+      <listitem><para>If the unit publishes a service over D-Bus, the connection needs to be re-established
+      after soft-reboot as the D-Bus broker will be stopped and then started again. When using the sd-bus
+      library this can be achieved by adapting the following example.
+      <programlisting><xi:include href="sd_bus_service_reconnect.c" parse="text"/></programlisting>
+      </para></listitem>
+    </itemizedlist>
+
+    <para>Even though passing resources from one soft reboot cycle to the next is possible this way, we
+    strongly suggest to use this functionality sparingly only, as it creates a more fragile system as
+    resources from different versions of the OS and applications might be mixed with unforeseen
+    consequences. In particular it's recommended to <emphasis>avoid</emphasis> allowing processes to survive
+    the soft reboot operation, as this means code updates will necessarily be incomplete, and processes
+    typically pin various other resources (such as the file system they are backed by), thus increasing
+    memory usage (as two versions of the OS/application/file system might be kept in memory). Leaving
+    processes running during a soft-reboot operation requires disconnecting the service comprehensively from
+    the rest of the OS, i.e. minimizing IPC and reducing sharing of resources with the rest of the OS. A
+    possible mechanism to achieve this is the concept of <ulink
+    url="https://systemd.io/PORTABLE_SERVICES">Portable Services</ulink>, but make sure no resource from the
+    host's OS filesystems is pinned via <varname>BindPaths=</varname> or similar unit settings, otherwise the
+    old, originating filesystem will remain mounted as long as the unit is running.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Notes</title>
+
+    <para>Note that because
+    <citerefentry><refentrytitle>systemd-shutdown</refentrytitle><manvolnum>8</manvolnum></citerefentry> is
+    not executed, the executables in <filename>/usr/lib/systemd/system-shutdown/</filename> are not executed
+    either.</para>
+
+    <para>Note that <filename>systemd-soft-reboot.service</filename> (and related units) should never be
+    executed directly. Instead, trigger system shutdown with a command such as <literal>systemctl
+    soft-reboot</literal>.</para>
+
+    <para>Note that if a new root file system has been set up on <literal>/run/nextroot/</literal>, a
+    <command>soft-reboot</command> will be performed when the <command>reboot</command> command is
+    invoked.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-poweroff.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-suspend.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>bootup</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-stdio-bridge.xml b/man/systemd-stdio-bridge.xml
new file mode 100644
index 0000000..f96dbf8
--- /dev/null
+++ b/man/systemd-stdio-bridge.xml
@@ -0,0 +1,93 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd-stdio-bridge"
+  xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd-stdio-bridge</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-stdio-bridge</refentrytitle>
+    <manvolnum>1</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-stdio-bridge</refname>
+    <refpurpose>D-Bus proxy</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <cmdsynopsis>
+      <command>systemd-stdio-bridge</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+    </cmdsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>systemd-stdio-bridge</command> implements a proxy between STDIN/STDOUT and a D-Bus bus. It
+    expects to receive an open connection via STDIN/STDOUT when started, and will create a new connection to
+    the specified bus. It will then forward messages between the two connections. This program is suitable
+    for socket activation: the first connection may be a pipe or a socket and must be passed as either
+    standard input, or as an open file descriptor according to the protocol described in
+    <citerefentry><refentrytitle>sd_listen_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry>. The
+    second connection will be made by default to the local system bus, but this can be influenced by the
+    <option>--user</option>, <option>--system</option>, <option>--machine=</option>, and
+    <option>--bus-path=</option> options described below.</para>
+
+    <para><citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry> uses
+    <command>systemd-stdio-bridge</command> to forward D-Bus connections over
+    <citerefentry project='die-net'><refentrytitle>ssh</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+    or to connect to the bus of a different user, see
+    <citerefentry><refentrytitle>sd_bus_set_address</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+    </para>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>The following options are understood:</para>
+
+    <variablelist>
+      <xi:include href="user-system-options.xml" xpointer="user" />
+      <xi:include href="user-system-options.xml" xpointer="system" />
+      <xi:include href="user-system-options.xml" xpointer="machine" />
+
+      <varlistentry>
+          <term><option>-p <replaceable>PATH</replaceable></option></term>
+          <term><option>--bus-path=<replaceable>PATH</replaceable></option></term>
+
+          <listitem><para>Path to the bus address. Default: <literal>unix:path=/run/dbus/system_bus_socket</literal>
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v251"/></listitem>
+      </varlistentry>
+
+      <xi:include href="standard-options.xml" xpointer="help" />
+      <xi:include href="standard-options.xml" xpointer="version" />
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Exit status</title>
+
+    <para>On success, 0 is returned, a non-zero failure code otherwise.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry project='dbus'><refentrytitle>dbus-daemon</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry project='dbus'><refentrytitle>dbus-broker</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <ulink url="https://www.freedesktop.org/wiki/Software/dbus">D-Bus</ulink>,
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-storagetm.service.xml b/man/systemd-storagetm.service.xml
new file mode 100644
index 0000000..4fa7958
--- /dev/null
+++ b/man/systemd-storagetm.service.xml
@@ -0,0 +1,104 @@
+<?xml version="1.0"?>
+<!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+<refentry id="systemd-storagetm.service" conditional='ENABLE_STORAGETM'
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd-storagetm.service</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-storagetm.service</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-storagetm.service</refname>
+    <refname>systemd-storagetm</refname>
+    <refpurpose>Exposes all local block devices as NVMe-TCP mass storage devices</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>systemd-storagetm.service</filename></para>
+
+    <cmdsynopsis>
+      <command>/usr/lib/systemd/systemd-storagetm</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="opt"><replaceable>DEVICE</replaceable></arg>
+    </cmdsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><filename>systemd-storagetm.service</filename> is a service that exposes all local block devices as
+    NVMe-TCP mass storage devices. Its primary use-case is to be invoked by the
+    <filename>storage-target-mode.target</filename> unit that can be booted into.</para>
+
+    <para>Warning: the NVMe disks are currently exposed without authentication or encryption, in read/write
+    mode. This means network peers may read from and write to the device without any restrictions. This
+    functionality should hence only be used in a local setup.</para>
+
+    <para>Note that to function properly networking must be configured too. The recommended mechanism to boot
+    into a storage target mode is by adding <literal>rd.systemd.unit=storage-target-mode.target
+    ip=link-local</literal> on the kernel command line. Note that <literal>ip=link-local</literal> only
+    configures link-local IP, i.e. IPv4LL and IPv6LL, which means non-routable addresses. This is done for
+    security reasons, so that only systems on the local link can access the devices. Use
+    <literal>ip=dhcp</literal> to assign routable addresses too. For further details see
+    <citerefentry><refentrytitle>systemd-network-generator.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
+
+    <para>Unless the <option>--all</option> switch is used expects one or more block devices or regular files to expose
+    via NVMe-TCP as argument.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>The following options are understood:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><option>--nqn=</option></term>
+        <listitem><para>Takes a string. If specified configures the NVMe Qualified Name to use for the
+        exposed NVMe-TCP mass storage devices. The NQN should follow the syntax described in <ulink
+        url="https://nvmexpress.org/wp-content/uploads/NVM-Express-Base-Specification-2.0c-2022.10.04-Ratified.pdf">NVM
+        Express Base Specification 2.0c</ulink>, section 4.5 "NVMe Qualified Names". Note that the NQN
+        specified here will be suffixed with a dot and the the block device name before it is exposed on the
+        NVMe target. If not specified defaults to
+        <literal>nqn.2023-10.io.systemd:storagetm.<replaceable>ID</replaceable></literal>, where ID is
+        replaced by a 128bit ID derived from
+        <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--all</option></term>
+        <term><option>-a</option></term>
+
+        <listitem><para>If specified exposes all local block devices via NVMe-TCP, current and future
+        (i.e. it watches block devices come and go and updates the NVMe-TCP list as needed). Note that by
+        default any block devices that originate on the same block device as the block device backing the
+        current root file system are excluded. If the switch is specified twice this safety mechanism is
+        disabled.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+      <xi:include href="standard-options.xml" xpointer="help" />
+      <xi:include href="standard-options.xml" xpointer="version" />
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-stub.xml b/man/systemd-stub.xml
new file mode 100644
index 0000000..6e85333
--- /dev/null
+++ b/man/systemd-stub.xml
@@ -0,0 +1,498 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd-stub" conditional='ENABLE_BOOTLOADER'
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+  <refentryinfo>
+    <title>systemd-stub</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-stub</refentrytitle>
+    <manvolnum>7</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-stub</refname>
+    <refname>sd-stub</refname>
+    <refname>linuxx64.efi.stub</refname>
+    <refname>linuxia32.efi.stub</refname>
+    <refname>linuxaa64.efi.stub</refname>
+    <refpurpose>A simple UEFI kernel boot stub</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>/usr/lib/systemd/boot/efi/linuxx64.efi.stub</filename></para>
+    <para><filename>/usr/lib/systemd/boot/efi/linuxia32.efi.stub</filename></para>
+    <para><filename>/usr/lib/systemd/boot/efi/linuxaa64.efi.stub</filename></para>
+    <para><filename><replaceable>ESP</replaceable>/.../<replaceable>foo</replaceable>.efi.extra.d/*.addon.efi</filename></para>
+    <para><filename><replaceable>ESP</replaceable>/.../<replaceable>foo</replaceable>.efi.extra.d/*.cred</filename></para>
+    <para><filename><replaceable>ESP</replaceable>/.../<replaceable>foo</replaceable>.efi.extra.d/*.raw</filename></para>
+    <para><filename><replaceable>ESP</replaceable>/loader/addons/*.addon.efi</filename></para>
+    <para><filename><replaceable>ESP</replaceable>/loader/credentials/*.cred</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>systemd-stub</command> (stored in per-architecture files
+    <filename>linuxx64.efi.stub</filename>, <filename>linuxia32.efi.stub</filename>,
+    <filename>linuxaa64.efi.stub</filename> on disk) is a simple UEFI boot stub. An UEFI boot stub is
+    attached to a Linux kernel binary image, and is a piece of code that runs in the UEFI firmware
+    environment before transitioning into the Linux kernel environment. The UEFI boot stub ensures a Linux
+    kernel is executable as regular UEFI binary, and is able to do various preparations before switching the
+    system into the Linux world.</para>
+
+    <para>The UEFI boot stub looks for various resources for the kernel invocation inside the UEFI PE binary
+    itself. This allows combining various resources inside a single PE binary image (usually called "Unified
+    Kernel Image", or "UKI" for short), which may then be signed via UEFI SecureBoot as a whole, covering all
+    individual resources at once. Specifically it may include:</para>
+
+    <itemizedlist>
+      <!-- Let's keep this in the canonical order we also measure the sections by, i.e. as in
+           src/fundamental/uki.h's UnifiedSection enum -->
+
+      <listitem><para>A <literal>.linux</literal> section with the ELF Linux kernel image.</para></listitem>
+
+      <listitem><para>An <literal>.osrel</literal> section with OS release information, i.e. the contents of
+      the <citerefentry><refentrytitle>os-release</refentrytitle><manvolnum>5</manvolnum></citerefentry> file
+      of the OS the kernel belongs to.</para></listitem>
+
+      <listitem><para>A <literal>.cmdline</literal> section with the kernel command line to pass to the
+      invoked kernel.</para></listitem>
+
+      <listitem><para>An <literal>.initrd</literal> section with the initrd.</para></listitem>
+
+      <listitem><para>A <literal>.splash</literal> section with an image (in the Windows
+      <filename>.BMP</filename> format) to show on screen before invoking the kernel.</para></listitem>
+
+      <listitem><para>A <literal>.dtb</literal> section with a compiled binary DeviceTree.</para></listitem>
+
+      <listitem><para>A <literal>.uname</literal> section with the kernel version information, i.e. the
+      output of <command>uname -r</command> for the kernel included in the <literal>.linux</literal>
+      section.</para></listitem>
+
+      <listitem><para>An <literal>.sbat</literal> section with
+      <ulink url="https://github.com/rhboot/shim/blob/main/SBAT.md">SBAT</ulink> revocation
+      metadata.</para></listitem>
+
+      <listitem><para>A <literal>.pcrsig</literal> section with a set of cryptographic signatures for the
+      expected TPM2 PCR values after the kernel has been booted, in JSON format. This is useful for
+      implementing TPM2 policies that bind disk encryption and similar to kernels that are signed by a
+      specific key.</para></listitem>
+
+      <listitem><para>A <literal>.pcrpkey</literal> section with a public key in the PEM format matching the
+      signature data in the the <literal>.pcrsig</literal> section.</para></listitem>
+    </itemizedlist>
+
+    <para>If UEFI SecureBoot is enabled and the <literal>.cmdline</literal> section is present in the executed
+    image, any attempts to override the kernel command line by passing one as invocation parameters to the
+    EFI binary are ignored. Thus, in order to allow overriding the kernel command line, either disable UEFI
+    SecureBoot, or don't include a kernel command line PE section in the kernel image file. If a command line
+    is accepted via EFI invocation parameters to the EFI binary it is measured into TPM PCR 12 (if a TPM is
+    present).</para>
+
+    <para>If a DeviceTree is embedded in the <literal>.dtb</literal> section, it replaces an existing
+    DeviceTree in the corresponding EFI configuration table. systemd-stub will ask the firmware via the
+    <literal>EFI_DT_FIXUP_PROTOCOL</literal> for hardware specific fixups to the DeviceTree.</para>
+
+    <para>The contents of eight of these nine sections are measured into TPM PCR 11. It is otherwise not used
+    and thus the result can be pre-calculated without too much effort. The <literal>.pcrsig</literal> section
+    is not included in this PCR measurement, since it is supposed to contain signatures for the output of the
+    measurement operation, and thus cannot also be input to it.</para>
+
+    <para>When <literal>.pcrsig</literal> and/or <literal>.pcrpkey</literal> sections are present in a
+    unified kernel image their contents are passed to the booted kernel in an synthetic initrd cpio archive
+    that places them in the <filename>/.extra/tpm2-pcr-signature.json</filename> and
+    <filename>/.extra/tpm2-pcr-public-key.pem</filename> files. Typically, a
+    <citerefentry><refentrytitle>tmpfiles.d</refentrytitle><manvolnum>5</manvolnum></citerefentry> line then
+    ensures they are copied into <filename>/run/systemd/tpm2-pcr-signature.json</filename> and
+    <filename>/run/systemd/tpm2-pcr-public-key.pem</filename> where they remain accessible even after the
+    system transitions out of the initrd environment into the host file system. Tools such
+    <citerefentry><refentrytitle>systemd-cryptsetup@.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>systemd-cryptenroll</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    and <citerefentry><refentrytitle>systemd-creds</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    will automatically use files present under these paths to unlock protected resources (encrypted storage
+    or credentials) or bind encryption to booted kernels.</para>
+
+    <para>For further details about the UKI concept, see the <ulink
+    url="https://uapi-group.org/specifications/specs/unified_kernel_image/">UKI specification</ulink>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Companion Files</title>
+
+    <para>The <command>systemd-stub</command> UEFI boot stub automatically collects three types of auxiliary
+    companion files optionally placed in drop-in directories on the same partition as the EFI binary,
+    dynamically generates <command>cpio</command> initrd archives from them, and passes them to the kernel.
+    Specifically:</para>
+
+    <itemizedlist>
+      <listitem><para>For a kernel binary called <filename><replaceable>foo</replaceable>.efi</filename>, it
+      will look for files with the <filename>.cred</filename> suffix in a directory named
+      <filename><replaceable>foo</replaceable>.efi.extra.d/</filename> next to it. If the kernel binary
+      uses a counter for the purpose of
+      <ulink url="https://systemd.io/AUTOMATIC_BOOT_ASSESSMENT">Automatic Boot Assessment</ulink>, this
+      counter will be ignored. For example, <filename><replaceable>foo</replaceable>+3-0.efi</filename>
+      will look in directory <filename><replaceable>foo</replaceable>.efi.extra.d/</filename>.
+      A <command>cpio</command>
+      archive is generated from all files found that way, placing them in the
+      <filename>/.extra/credentials/</filename> directory of the initrd file hierarchy. The main initrd may
+      then access them in this directory. This is supposed to be used to store auxiliary, encrypted,
+      authenticated credentials for use with <varname>LoadCredentialEncrypted=</varname> in the UEFI System
+      Partition. See
+      <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+      and
+      <citerefentry><refentrytitle>systemd-creds</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+      for
+      details on encrypted credentials. The generated <command>cpio</command> archive is measured into TPM
+      PCR 12 (if a TPM is present).</para></listitem>
+
+      <listitem><para>Similarly, files <filename><replaceable>foo</replaceable>.efi.extra.d/*.raw</filename>
+      are packed up in a <command>cpio</command> archive and placed in the <filename>/.extra/sysext/</filename>
+      directory in the initrd file hierarchy. This is supposed to be used to pass additional system extension
+      images to the initrd. See
+      <citerefentry><refentrytitle>systemd-sysext</refentrytitle><manvolnum>8</manvolnum></citerefentry> for
+      details on system extension images. The generated <command>cpio</command> archive containing these
+      system extension images is measured into TPM PCR 13 (if a TPM is present).</para></listitem>
+
+      <listitem><para>Similarly, files
+      <filename><replaceable>foo</replaceable>.efi.extra.d/*.addon.efi</filename> are loaded and verified as
+      PE binaries, and a <literal>.cmdline</literal> section is parsed from them. Addons are supposed to be
+      used to pass additional kernel command line parameters or Devicetree blobs, regardless of the kernel
+      image being booted, for example to allow platform vendors to ship platform-specific
+      configuration.</para>
+
+      <para>In case Secure Boot is enabled, these files will be validated using keys in UEFI DB, Shim's DB or
+      Shim's MOK, and will be rejected otherwise. Additionally, if the both the addon and the UKI contain a a
+      <literal>.uname</literal> section, the addon will be rejected if they do not match exactly. It is
+      recommended to always add a <literal>.sbat</literal> section to all signed addons, so that they may be
+      revoked with a SBAT policy update, without requiring blocklisting via DBX/MOKX. The
+      <citerefentry><refentrytitle>ukify</refentrytitle><manvolnum>1</manvolnum></citerefentry> tool will add
+      a SBAT policy by default if none is passed when building addons. For more information on SBAT see
+      <ulink url="https://github.com/rhboot/shim/blob/main/SBAT.md">Shim documentation</ulink>.</para>
+
+      <para>Addon files are sorted, loaded, and measured into TPM PCR 12 (if a TPM is present) and appended
+      to the kernel command line. UKI command line options are listed first, then options from addons in
+      <filename>/loader/addons/*.addon.efi</filename>, and finally UKI-specific addons. Device tree blobs are
+      loaded and measured following the same algorithm. Addons are always loaded in the same order based on
+      the filename, so that, given the same set of addons, the same set of measurements can be expected in
+      PCR12. However, note that the filename is not protected by the PE signature, and as such an attacker
+      with write access to the ESP could potentially rename these files to change the order in which they are
+      loaded, in a way that could alter the functionality of the kernel, as some options might be
+      order-dependent. If you sign such addons, you should pay attention to the PCR12 values and make use of
+      an attestation service so that improper use of your signed addons can be detected and dealt with using
+      one of the aforementioned revocation mechanisms.</para></listitem>
+
+      <listitem><para>Files <filename>/loader/credentials/*.cred</filename> are packed up in a
+      <command>cpio</command> archive and placed in the <filename>/.extra/global_credentials/</filename>
+      directory of the initrd file hierarchy. This is supposed to be used to pass additional credentials to
+      the initrd, regardless of the kernel being booted. The generated <command>cpio</command> archive is
+      measured into TPM PCR 12 (if a TPM is present).</para></listitem>
+
+      <listitem><para>Additionally, files <filename>/loader/addons/*.addon.efi</filename> are loaded and
+      verified as PE binaries, and <literal>.cmdline</literal> and/or <literal>.dtb</literal> sections are
+      parsed from them. This is supposed to be used to pass additional command line parameters or Devicetree
+      blobs to the kernel, regardless of the kernel being booted.</para></listitem>
+    </itemizedlist>
+
+    <para>These mechanisms may be used to parameterize and extend trusted (i.e. signed), immutable initrd
+    images in a reasonably safe way: all data they contain is measured into TPM PCRs. On access they should be
+    further validated: in case of the credentials case by encrypting/authenticating them via TPM, as exposed
+    by <command>systemd-creds encrypt -T</command> (see
+    <citerefentry><refentrytitle>systemd-creds</refentrytitle><manvolnum>1</manvolnum></citerefentry> for
+    details); in case of the system extension images by using signed Verity images.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>TPM PCR Notes</title>
+
+    <para>Note that when a unified kernel using <command>systemd-stub</command> is invoked the firmware will
+    measure it as a whole to TPM PCR 4, covering all embedded resources, such as the stub code itself, the
+    core kernel, the embedded initrd and kernel command line (see above for a full list).</para>
+
+    <para>Also note that the Linux kernel will measure all initrds it receives into TPM PCR 9. This means
+    every type of initrd will be measured two or three times: the initrd embedded in the kernel image will be
+    measured to PCR 4, PCR 9 and PCR 11; the initrd synthesized from credentials will be measured to both PCR
+    9 and PCR 12; the initrd synthesized from system extensions will be measured to both PCR 4 and PCR
+    9. Let's summarize the OS resources and the PCRs they are measured to:</para>
+
+    <table>
+      <title>OS Resource PCR Summary</title>
+
+      <tgroup cols='2' align='left' colsep='1' rowsep='1'>
+        <colspec colname="pcr" />
+        <colspec colname="definition" />
+
+        <thead>
+          <row>
+            <entry>OS Resource</entry>
+            <entry>Measurement PCR</entry>
+          </row>
+        </thead>
+
+        <tbody>
+          <row>
+            <entry><command>systemd-stub</command> code (the entry point of the unified PE binary)</entry>
+            <entry>4</entry>
+          </row>
+
+          <row>
+            <entry>Core kernel code (embedded in unified PE binary)</entry>
+            <entry>4 + 11</entry>
+          </row>
+
+          <row>
+            <entry>OS release information (embedded in the unified PE binary)</entry>
+            <entry>4 + 11</entry>
+          </row>
+
+          <row>
+            <entry>Main initrd (embedded in unified PE binary)</entry>
+            <entry>4 + 9 + 11</entry>
+          </row>
+
+          <row>
+            <entry>Default kernel command line (embedded in unified PE binary)</entry>
+            <entry>4 + 11</entry>
+          </row>
+
+          <row>
+            <entry>Overridden kernel command line</entry>
+            <entry>12</entry>
+          </row>
+
+          <row>
+            <entry>Boot splash (embedded in the unified PE binary)</entry>
+            <entry>4 + 11</entry>
+          </row>
+
+          <row>
+            <entry>TPM2 PCR signature JSON (embedded in unified PE binary, synthesized into initrd)</entry>
+            <entry>4 + 9</entry>
+          </row>
+
+          <row>
+            <entry>TPM2 PCR PEM public key (embedded in unified PE binary, synthesized into initrd)</entry>
+            <entry>4 + 9 + 11</entry>
+          </row>
+
+          <row>
+            <entry>Credentials (synthesized initrd from companion files)</entry>
+            <entry>9 + 12</entry>
+          </row>
+
+          <row>
+            <entry>System Extensions (synthesized initrd from companion files)</entry>
+            <entry>9 + 13</entry>
+          </row>
+        </tbody>
+      </tgroup>
+    </table>
+  </refsect1>
+
+  <refsect1>
+    <title>EFI Variables</title>
+
+    <para>The following EFI variables are defined, set and read by <command>systemd-stub</command>, under the
+    vendor UUID <literal>4a67b082-0a4c-41cf-b6c7-440b29bb8c4f</literal>, for communication between the boot
+    stub and the OS:</para>
+
+    <variablelist class='efi-variables'>
+      <varlistentry>
+        <term><varname>LoaderDevicePartUUID</varname></term>
+
+        <listitem><para>Contains the partition UUID of the EFI System Partition the EFI image was run
+        from. <citerefentry><refentrytitle>systemd-gpt-auto-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        uses this information to automatically find the disk booted from, in order to discover various other
+        partitions on the same disk automatically.</para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>LoaderFirmwareInfo</varname></term>
+        <term><varname>LoaderFirmwareType</varname></term>
+
+        <listitem><para>Brief firmware information. Use
+        <citerefentry><refentrytitle>bootctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> to view this
+        data.</para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>LoaderImageIdentifier</varname></term>
+
+        <listitem><para>The path of EFI executable, relative to the EFI System Partition's root
+        directory. Use
+        <citerefentry><refentrytitle>bootctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> to view
+        this data.</para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>StubInfo</varname></term>
+
+        <listitem><para>Brief stub information. Use
+        <citerefentry><refentrytitle>bootctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> to view
+        this data.</para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>StubPcrKernelImage</varname></term>
+
+        <listitem><para>The PCR register index the kernel image, initrd image, boot splash, devicetree
+        database, and the embedded command line are measured into, formatted as decimal ASCII string (e.g.
+        <literal>11</literal>). This variable is set if a measurement was successfully completed, and remains
+        unset otherwise.</para>
+
+        <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>StubPcrKernelParameters</varname></term>
+
+        <listitem><para>The PCR register index the kernel command line and credentials are measured into,
+        formatted as decimal ASCII string (e.g. <literal>12</literal>). This variable is set if a measurement
+        was successfully completed, and remains unset otherwise.</para>
+
+        <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>StubPcrInitRDSysExts</varname></term>
+
+        <listitem><para>The PCR register index the systemd extensions for the initrd, which are picked up
+        from the file system the kernel image is located on. Formatted as decimal ASCII string (e.g.
+        <literal>13</literal>). This variable is set if a measurement was successfully completed, and remains
+        unset otherwise.</para>
+
+        <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+      </varlistentry>
+    </variablelist>
+
+    <para>Note that some of the variables above may also be set by the boot loader. The stub will only set
+    them if they aren't set already. Some of these variables are defined by the <ulink
+    url="https://systemd.io/BOOT_LOADER_INTERFACE">Boot Loader Interface</ulink>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>initrd Resources</title>
+
+    <para>The following resources are passed as initrd cpio archives to the booted kernel, and thus make up
+    the initial file system hierarchy in the initrd execution environment:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><filename>/</filename></term>
+
+        <listitem><para>The main initrd from the <literal>.initrd</literal> PE section of the unified kernel
+        image.</para>
+
+        <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>/.extra/credentials/*.cred</filename></term>
+        <listitem><para>Credential files (suffix <literal>.cred</literal>) that are placed next to the
+        unified kernel image (as described above) are copied into the
+        <filename>/.extra/credentials/</filename> directory in the initrd execution
+        environment.</para>
+
+        <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>/.extra/global_credentials/*.cred</filename></term>
+        <listitem><para>Similarly, credential files in the <filename>/loader/credentials/</filename>
+        directory in the file system the unified kernel image is placed in are copied into the
+        <filename>/.extra/global_credentials/</filename> directory in the initrd execution
+        environment.</para>
+
+        <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>/.extra/sysext/*.raw</filename></term>
+        <listitem><para>System extension image files (suffix <literal>.raw</literal>) that are placed next to
+        the unified kernel image (as described above) are copied into the
+        <filename>/.extra/sysext/</filename> directory in the initrd execution environment.</para>
+
+        <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>/.extra/tpm2-pcr-signature.json</filename></term>
+        <listitem><para>The TPM2 PCR signature JSON object included in the <literal>.pcrsig</literal> PE
+        section of the unified kernel image is copied into the
+        <filename>/.extra/tpm2-pcr-signature.json</filename> file in the initrd execution environment.</para>
+
+        <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>/.extra/tpm2-pcr-pkey.pem</filename></term>
+        <listitem><para>The PEM public key included in the <literal>.pcrpkey</literal> PE section of the
+        unified kernel image is copied into the <filename>/.extra/tpm2-pcr-public-key.pem</filename> file in
+        the initrd execution environment.</para>
+
+        <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+      </varlistentry>
+    </variablelist>
+
+    <para>Note that all these files are located in the <literal>tmpfs</literal> file system the kernel sets
+    up for the initrd file hierarchy and are thus lost when the system transitions from the initrd execution
+    environment into the host file system. If these resources shall be kept around over this transition they
+    need to be copied to a place that survives the transition first, for example via a suitable
+    <citerefentry><refentrytitle>tmpfiles.d</refentrytitle><manvolnum>5</manvolnum></citerefentry> line. By
+    default, this is done for the TPM2 PCR signature and public key files.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>SMBIOS Type 11 Strings</title>
+
+    <para><command>systemd-stub</command> can be configured using SMBIOS Type 11 strings. Applicable strings
+    consist of a name, followed by <literal>=</literal>, followed by the value.
+    <command>systemd-stub</command> will search the table for a string with a specific name, and if found,
+    use its value. The following strings are read:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><varname>io.systemd.stub.kernel-cmdline-extra</varname></term>
+        <listitem><para>If set, the value of this string is added to the list of kernel command line
+        arguments that are measured in PCR12 and passed to the kernel.</para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Assembling Kernel Images</title>
+
+    <para>In order to assemble a bootable Unified Kernel Image from various components as described above, use
+    <citerefentry><refentrytitle>ukify</refentrytitle><manvolnum>1</manvolnum></citerefentry>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd-boot</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-creds</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-sysext</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <ulink url="https://uapi-group.org/specifications/specs/boot_loader_specification">Boot Loader Specification</ulink>,
+      <ulink url="https://systemd.io/BOOT_LOADER_INTERFACE">Boot Loader Interface</ulink>,
+      <citerefentry><refentrytitle>ukify</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-measure</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <ulink url="https://systemd.io/TPM2_PCR_MEASUREMENTS">TPM2 PCR Measurements Made by systemd</ulink>
+    </para>
+  </refsect1>
+</refentry>
diff --git a/man/systemd-suspend.service.xml b/man/systemd-suspend.service.xml
new file mode 100644
index 0000000..02daecf
--- /dev/null
+++ b/man/systemd-suspend.service.xml
@@ -0,0 +1,129 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd-suspend.service"
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd-suspend.service</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-suspend.service</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-suspend.service</refname>
+    <refname>systemd-hibernate.service</refname>
+    <refname>systemd-hybrid-sleep.service</refname>
+    <refname>systemd-suspend-then-hibernate.service</refname>
+    <refname>systemd-sleep</refname>
+    <refpurpose>System sleep state logic</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>systemd-suspend.service</filename></para>
+    <para><filename>systemd-hibernate.service</filename></para>
+    <para><filename>systemd-hybrid-sleep.service</filename></para>
+    <para><filename>systemd-suspend-then-hibernate.service</filename></para>
+    <para><filename>/usr/lib/systemd/system-sleep</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><filename>systemd-suspend.service</filename> is a system
+    service that is pulled in by <filename>suspend.target</filename>
+    and is responsible for the actual system suspend. Similarly,
+    <filename>systemd-hibernate.service</filename> is pulled in by
+    <filename>hibernate.target</filename> to execute the actual
+    hibernation. Finally,
+    <filename>systemd-hybrid-sleep.service</filename> is pulled in by
+    <filename>hybrid-sleep.target</filename> to execute hybrid
+    hibernation with system suspend and pulled in by
+    <filename>suspend-then-hibernate.target</filename> to execute system suspend
+    with a timeout that will activate hibernate later.</para>
+
+    <para>Immediately before entering system suspend and/or
+    hibernation <filename>systemd-suspend.service</filename> (and the
+    other mentioned units, respectively) will run all executables in
+    <filename>/usr/lib/systemd/system-sleep/</filename> and pass two
+    arguments to them. The first argument will be
+    <literal>pre</literal>, the second either
+    <literal>suspend</literal>, <literal>hibernate</literal>,
+    <literal>hybrid-sleep</literal>, or <literal>suspend-then-hibernate</literal>
+    depending on the chosen action. An environment variable called <literal>SYSTEMD_SLEEP_ACTION</literal>
+    will be set and contain the sleep action that is processing. This is primarily helpful for
+    <literal>suspend-then-hibernate</literal> where the value of the variable will be <literal>suspend</literal>, <literal>hibernate</literal>,
+    or <literal>suspend-after-failed-hibernate</literal> in cases where hibernation has failed.
+    Immediately after leaving system suspend and/or hibernation the
+    same executables are run, but the first argument is now
+    <literal>post</literal>. All executables in this directory are
+    executed in parallel, and execution of the action is not continued
+    until all executables have finished.</para>
+
+    <para>Note that scripts or binaries dropped in
+    <filename>/usr/lib/systemd/system-sleep/</filename> are intended
+    for local use only and should be considered hacks. If applications
+    want to react to system suspend/hibernation and resume,
+    they should rather use the <ulink
+    url="https://www.freedesktop.org/wiki/Software/systemd/inhibit">Inhibitor
+    interface</ulink>.</para>
+
+    <para>Note that <filename>systemd-suspend.service</filename>,
+    <filename>systemd-hibernate.service</filename>, <filename>systemd-hybrid-sleep.service</filename>, and
+    <filename>systemd-suspend-then-hibernate.service</filename> should never be executed directly. Instead,
+    trigger system sleep with a command such as <command>systemctl suspend</command> or <command>systemctl
+    hibernate</command>.</para>
+
+    <para>Internally, this service will echo a string like
+    <literal>mem</literal> into <filename>/sys/power/state</filename>,
+    to trigger the actual system suspend. What exactly is written
+    where can be configured in the [Sleep] section
+    of <filename>/etc/systemd/sleep.conf</filename> or a
+    <filename>sleep.conf.d</filename> file. See
+    <citerefentry><refentrytitle>systemd-sleep.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+    </para>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para><command>systemd-sleep</command> understands the
+    following commands:</para>
+
+    <variablelist>
+      <xi:include href="standard-options.xml" xpointer="help" />
+      <xi:include href="standard-options.xml" xpointer="version" />
+
+      <varlistentry>
+        <term><option>suspend</option></term>
+        <term><option>hibernate</option></term>
+        <term><option>suspend-then-hibernate</option></term>
+        <term><option>hybrid-sleep</option></term>
+
+        <listitem><para>Suspend, hibernate, suspend then hibernate, or put the
+        system to hybrid sleep.</para>
+
+        <xi:include href="version-info.xml" xpointer="v203"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd-sleep.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-halt.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-sysctl.service.xml b/man/systemd-sysctl.service.xml
new file mode 100644
index 0000000..cce3284
--- /dev/null
+++ b/man/systemd-sysctl.service.xml
@@ -0,0 +1,168 @@
+<?xml version="1.0"?>
+<!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+<refentry id="systemd-sysctl.service"
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd-sysctl.service</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-sysctl.service</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-sysctl.service</refname>
+    <refname>systemd-sysctl</refname>
+    <refpurpose>Configure kernel parameters at boot</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <cmdsynopsis>
+      <command>/usr/lib/systemd/systemd-sysctl</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="opt" rep="repeat"><replaceable>CONFIGFILE</replaceable></arg>
+    </cmdsynopsis>
+    <para><filename>systemd-sysctl.service</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><filename>systemd-sysctl.service</filename> is an early boot
+    service that configures
+    <citerefentry project='man-pages'><refentrytitle>sysctl</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    kernel parameters by invoking <command>/usr/lib/systemd/systemd-sysctl</command>.</para>
+
+    <para>When invoked with no arguments, <command>/usr/lib/systemd/systemd-sysctl</command> applies
+    all directives from configuration files listed in
+    <citerefentry><refentrytitle>sysctl.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+    If one or more filenames are passed on the command line, only the directives in these files are
+    applied.</para>
+
+    <para>In addition, <option>--prefix=</option> option may be used to limit which sysctl
+    settings are applied.</para>
+
+    <para>See
+    <citerefentry><refentrytitle>sysctl.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for information about the configuration of sysctl settings. After sysctl configuration is
+    changed on disk, it must be written to the files in <filename>/proc/sys/</filename> before it
+    takes effect. It is possible to update specific settings, or simply to reload all configuration,
+    see Examples below.</para>
+  </refsect1>
+
+  <refsect1><title>Options</title>
+    <variablelist>
+      <varlistentry id='prefix'>
+        <term><option>--prefix=</option></term>
+        <listitem>
+          <para>Only apply rules with the specified prefix.</para>
+
+        <xi:include href="version-info.xml" xpointer="v230"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry id='strict'>
+        <term><option>--strict=</option></term>
+        <listitem>
+          <para>Always return non-zero exit code on failure (including invalid sysctl variable
+          name and insufficient permissions), unless the sysctl variable name is prefixed with a "-"
+          character.</para>
+
+          <xi:include href="version-info.xml" xpointer="v252"/>
+        </listitem>
+      </varlistentry>
+
+      <xi:include href="standard-options.xml" xpointer="cat-config" />
+      <xi:include href="standard-options.xml" xpointer="tldr" />
+      <xi:include href="standard-options.xml" xpointer="no-pager" />
+      <xi:include href="standard-options.xml" xpointer="help" />
+      <xi:include href="standard-options.xml" xpointer="version" />
+
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Credentials</title>
+
+    <para><command>systemd-sysctl</command> supports the service credentials logic as implemented by
+    <varname>ImportCredential=</varname>/<varname>LoadCredential=</varname>/<varname>SetCredential=</varname>
+    (see <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
+    details). The following credentials are used when passed in:</para>
+
+    <variablelist class='system-credentials'>
+      <varlistentry>
+        <term><varname>sysctl.extra</varname></term>
+
+        <listitem><para>The contents of this credential may contain additional lines to operate on. The
+        credential contents should follow the same format as any other <filename>sysctl.d/</filename> drop-in
+        configuration file. If this credential is passed it is processed after all of the drop-in files read
+        from the file system. The settings configured in the credential hence take precedence over those in
+        the file system.</para>
+
+        <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+      </varlistentry>
+    </variablelist>
+
+    <para>Note that by default the <filename>systemd-sysctl.service</filename> unit file is set up to inherit
+    the <literal>sysctl.extra</literal> credential from the service manager.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Examples</title>
+
+    <example>
+      <title>Reset all sysctl settings</title>
+
+      <programlisting>systemctl restart systemd-sysctl</programlisting>
+    </example>
+
+    <example>
+      <title>View coredump handler configuration</title>
+
+      <programlisting># sysctl kernel.core_pattern
+kernel.core_pattern = |/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t %P %I
+</programlisting>
+    </example>
+
+    <example>
+      <title>Update coredump handler configuration</title>
+
+      <programlisting># /usr/lib/systemd/systemd-sysctl --prefix kernel.core_pattern</programlisting>
+
+      <para>This searches all the directories listed in
+      <citerefentry><refentrytitle>sysctl.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+      for configuration files and writes <filename>/proc/sys/kernel/core_pattern</filename>.</para>
+    </example>
+
+    <example>
+      <title>Update coredump handler configuration according to a specific file</title>
+
+      <programlisting># /usr/lib/systemd/systemd-sysctl 50-coredump.conf</programlisting>
+
+      <para>This applies all the settings found in <filename>50-coredump.conf</filename>.
+      Either <filename>/etc/sysctl.d/50-coredump.conf</filename>, or
+      <filename>/run/sysctl.d/50-coredump.conf</filename>, or
+      <filename>/usr/lib/sysctl.d/50-coredump.conf</filename> will be used, in the order
+      of preference.</para>
+    </example>
+
+    <para>See
+    <citerefentry project='man-pages'><refentrytitle>sysctl</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    for various ways to directly apply sysctl settings.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sysctl.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>sysctl</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-sysext.xml b/man/systemd-sysext.xml
new file mode 100644
index 0000000..7607693
--- /dev/null
+++ b/man/systemd-sysext.xml
@@ -0,0 +1,361 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd-sysext"
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd-sysext</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-sysext</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-sysext</refname>
+    <refname>systemd-sysext.service</refname>
+    <refname>systemd-confext</refname>
+    <refname>systemd-confext.service</refname>
+    <refpurpose>Activates System Extension Images</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <cmdsynopsis>
+      <command>systemd-sysext</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="plain">COMMAND</arg>
+    </cmdsynopsis>
+
+    <para><literallayout><filename>systemd-sysext.service</filename></literallayout></para>
+
+    <cmdsynopsis>
+      <command>systemd-confext</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="plain">COMMAND</arg>
+    </cmdsynopsis>
+
+    <para><literallayout><filename>systemd-confext.service</filename></literallayout></para>
+
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>systemd-sysext</command> activates/deactivates system extension images. System extension
+    images may – dynamically at runtime — extend the <filename>/usr/</filename> and
+    <filename>/opt/</filename> directory hierarchies with additional files. This is particularly useful on
+    immutable system images where a <filename>/usr/</filename> and/or <filename>/opt/</filename> hierarchy
+    residing on a read-only file system shall be extended temporarily at runtime without making any
+    persistent modifications.</para>
+
+    <para>System extension images should contain files and directories similar in fashion to regular
+    operating system tree. When one or more system extension images are activated, their
+    <filename>/usr/</filename> and <filename>/opt/</filename> hierarchies are combined via
+    <literal>overlayfs</literal> with the same hierarchies of the host OS, and the host
+    <filename>/usr/</filename> and <filename>/opt/</filename> overmounted with it ("merging"). When they are
+    deactivated, the mount point is disassembled — again revealing the unmodified original host version of
+    the hierarchy ("unmerging"). Merging thus makes the extension's resources suddenly appear below the
+    <filename>/usr/</filename> and <filename>/opt/</filename> hierarchies as if they were included in the
+    base OS image itself. Unmerging makes them disappear again, leaving in place only the files that were
+    shipped with the base OS image itself.</para>
+
+    <para>Files and directories contained in the extension images outside of the <filename>/usr/</filename>
+    and <filename>/opt/</filename> hierarchies are <emphasis>not</emphasis> merged, and hence have no effect
+    when included in a system extension image. In particular, files in the <filename>/etc/</filename> and
+    <filename>/var/</filename> included in a system extension image will <emphasis>not</emphasis> appear in
+    the respective hierarchies after activation.</para>
+
+    <para>System extension images are strictly read-only, and the host <filename>/usr/</filename> and
+    <filename>/opt/</filename> hierarchies become read-only too while they are activated.</para>
+
+    <para>System extensions are supposed to be purely additive, i.e. they are supposed to include only files
+    that do not exist in the underlying basic OS image. However, the underlying mechanism (overlayfs) also
+    allows overlaying or removing files, but it is recommended not to make use of this.</para>
+
+    <para>System extension images may be provided in the following formats:</para>
+
+    <orderedlist>
+      <listitem><para>Plain directories or btrfs subvolumes containing the OS tree</para></listitem>
+      <listitem><para>Disk images with a GPT disk label, following the <ulink
+      url="https://uapi-group.org/specifications/specs/discoverable_partitions_specification">Discoverable Partitions Specification</ulink></para></listitem>
+      <listitem><para>Disk images lacking a partition table, with a naked Linux file system (e.g. erofs,
+      squashfs or ext4)</para></listitem>
+    </orderedlist>
+
+    <para>These image formats are the same ones that
+    <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    supports via its <option>--directory=</option>/<option>--image=</option> switches and those that the
+    service manager supports via <option>RootDirectory=</option>/<option>RootImage=</option>. Similar to
+    them they may optionally carry Verity authentication information.</para>
+
+    <para>System extensions are searched for in the directories
+    <filename>/etc/extensions/</filename>, <filename>/run/extensions/</filename> and
+    <filename>/var/lib/extensions/</filename>. The first two listed directories are not suitable for
+    carrying large binary images, however are still useful for carrying symlinks to them. The primary place
+    for installing system extensions is <filename>/var/lib/extensions/</filename>. Any directories found in
+    these search directories are considered directory based extension images; any files with the
+    <filename>.raw</filename> suffix are considered disk image based extension images. When invoked in the
+    initrd, the additional directory <filename>/.extra/sysext/</filename> is included in the directories that
+    are searched for extension images. Note however, that by default a tighter image policy applies to images
+    found there, though, see below. This directory is populated by
+    <citerefentry><refentrytitle>systemd-stub</refentrytitle><manvolnum>7</manvolnum></citerefentry> with
+    extension images found in the system's EFI System Partition.</para>
+
+    <para>During boot OS extension images are activated automatically, if the
+    <filename>systemd-sysext.service</filename> is enabled. Note that this service runs only after the
+    underlying file systems where system extensions may be located have been mounted. This means they are not
+    suitable for shipping resources that are processed by subsystems running in earliest boot. Specifically,
+    OS extension images are not suitable for shipping system services or
+    <citerefentry><refentrytitle>systemd-sysusers</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    definitions. See the <ulink url="https://systemd.io/PORTABLE_SERVICES">Portable Services</ulink> page
+    for a simple mechanism for shipping system services in disk images, in a similar fashion to OS
+    extensions. Note the different isolation on these two mechanisms: while system extension directly extend
+    the underlying OS image with additional files that appear in a way very similar to as if they were
+    shipped in the OS image itself and thus imply no security isolation, portable services imply service
+    level sandboxing in one way or another. The <filename>systemd-sysext.service</filename> service is
+    guaranteed to finish start-up before <filename>basic.target</filename> is reached; i.e. at the time
+    regular services initialize (those which do not use <varname>DefaultDependencies=no</varname>), the files
+    and directories system extensions provide are available in <filename>/usr/</filename> and
+    <filename>/opt/</filename> and may be accessed.</para>
+
+    <para>Note that there is no concept of enabling/disabling installed system extension images: all
+    installed extension images are automatically activated at boot. However, you can place an empty directory
+    named like the extension (no <filename>.raw</filename>) in <filename>/etc/extensions/</filename> to "mask"
+    an extension with the same name in a system folder with lower precedence.</para>
+
+    <para>A simple mechanism for version compatibility is enforced: a system extension image must carry a
+    <filename>/usr/lib/extension-release.d/extension-release.<replaceable>NAME</replaceable></filename>
+    file, which must match its image name, that is compared with the host <filename>os-release</filename>
+    file: the contained <varname>ID=</varname> fields have to match unless <literal>_any</literal> is set
+    for the extension. If the extension <varname>ID=</varname> is not <literal>_any</literal>, the
+    <varname>SYSEXT_LEVEL=</varname> field (if defined) has to match. If the latter is not defined, the
+    <varname>VERSION_ID=</varname> field has to match instead. If the extension defines the
+    <varname>ARCHITECTURE=</varname> field and the value is not <literal>_any</literal> it has to match the kernel's
+    architecture reported by <citerefentry><refentrytitle>uname</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+    but the used architecture identifiers are the same as for <varname>ConditionArchitecture=</varname>
+    described in <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+    <varname>EXTENSION_RELOAD_MANAGER=</varname> can be set to 1 if the extension requires a service manager reload after application
+    of the extension. Note that the for the reasons mentioned earlier:
+    <ulink url="https://systemd.io/PORTABLE_SERVICES">Portable Services</ulink> remain
+    the recommended way to ship system services.
+
+    System extensions should not ship a <filename>/usr/lib/os-release</filename> file (as that would be merged
+    into the host <filename>/usr/</filename> tree, overriding the host OS version data, which is not desirable).
+    The <filename>extension-release</filename> file follows the same format and semantics, and carries the same
+    content, as the <filename>os-release</filename> file of the OS, but it describes the resources carried
+    in the extension image.</para>
+
+    <para>The <command>systemd-confext</command> concept follows the same principle as the
+    <citerefentry><refentrytitle>systemd-sysext</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    functionality but instead of working on <filename>/usr</filename> and <filename>/opt</filename>,
+    <command>confext</command> will extend only <filename>/etc</filename>. Files and directories contained
+    in the confext images outside of the <filename>/etc/</filename> hierarchy are <emphasis>not</emphasis>
+    merged, and hence have no effect when included in the image. Formats for these images are of the
+    same as sysext images. The merged hierarchy will be mounted with <literal>nosuid</literal> and
+    (if not disabled via <option>--noexec=false</option>) <literal>noexec</literal>.</para>
+
+    <para>Confexts are looked for in the directories <filename>/run/confexts/</filename>,
+    <filename>/var/lib/confexts/</filename>, <filename>/usr/lib/confexts/</filename> and
+    <filename>/usr/local/lib/confexts/</filename>. The first listed directory is not suitable for
+    carrying large binary images, however is still useful for carrying symlinks to them. The primary place
+    for installing configuration extensions is <filename>/var/lib/confexts/</filename>. Any directories found
+    in these search directories are considered directory based confext images; any files with the
+    <filename>.raw</filename> suffix are considered disk image based confext images.</para>
+
+    <para>Again, just like sysext images, the confext images will contain a
+    <filename>/etc/extension-release.d/extension-release.<replaceable>NAME</replaceable></filename>
+    file, which must match the image name (with the usual escape hatch of
+    the <varname>user.extension-release.strict</varname>
+    <citerefentry project='man-pages'><refentrytitle>xattr</refentrytitle><manvolnum>7</manvolnum></citerefentry>),
+    and again with content being one or more of <varname>ID=</varname>, <varname>VERSION_ID=</varname>, and
+    <varname>CONFEXT_LEVEL</varname>. Confext images will then be checked and matched against the base OS
+    layer.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Uses</title>
+
+    <para>The primary use case for system images are immutable environments where debugging and development
+    tools shall optionally be made available, but not included in the immutable base OS image itself (e.g.
+    <citerefentry project='man-pages'><refentrytitle>strace</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    and
+    <citerefentry project='man-pages'><refentrytitle>gdb</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    shall be an optionally installable addition in order to make debugging/development easier). System
+    extension images should not be misunderstood as a generic software packaging framework, as no dependency
+    scheme is available: system extensions should carry all files they need themselves, except for those
+    already shipped in the underlying host system image. Typically, system extension images are built at the
+    same time as the base OS image — within the same build system.</para>
+
+    <para>Another use case for the system extension concept is temporarily overriding OS supplied resources
+    with newer ones, for example to install a locally compiled development version of some low-level
+    component over the immutable OS image without doing a full OS rebuild or modifying the nominally
+    immutable image. (e.g. "install" a locally built package with <command>DESTDIR=/var/lib/extensions/mytest
+    make install &amp;&amp; systemd-sysext refresh</command>, making it available in
+    <filename>/usr/</filename> as if it was installed in the OS image itself.) This case works regardless if
+    the underlying host <filename>/usr/</filename> is managed as immutable disk image or is a traditional
+    package manager controlled (i.e. writable) tree.</para>
+
+    <para>For the confext case, the OSConfig project aims to perform runtime reconfiguration of OS services.
+    Sometimes, there is a need to swap certain configuration parameter values or restart only a specific
+    service without deployment of new code or a complete OS deployment. In other words, we want to be able
+    to tie the most frequently configured options to runtime updateable flags that can be changed without a
+    system reboot. This will help reduce servicing times when there is a need for changing the OS configuration.</para></refsect1>
+
+  <refsect1>
+    <title>Commands</title>
+
+    <para>The following commands are understood by both the sysext and confext concepts:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><option>status</option></term>
+
+        <listitem><para>When invoked without any command verb, or when <option>status</option> is specified
+        the current merge status is shown, separately (for both <filename>/usr/</filename> and
+        <filename>/opt/</filename> of sysext and for <filename>/etc/</filename> of confext).</para>
+
+        <xi:include href="version-info.xml" xpointer="v248"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>merge</option></term>
+        <listitem><para>Merges all currently installed system extension images into
+        <filename>/usr/</filename> and <filename>/opt/</filename>, by overmounting these hierarchies with an
+        <literal>overlayfs</literal> file system combining the underlying hierarchies with those included in
+        the extension images. This command will fail if the hierarchies are already merged. For confext, the merge
+        happens into the <filename>/etc/</filename> directory instead.</para>
+
+        <xi:include href="version-info.xml" xpointer="v248"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>unmerge</option></term>
+        <listitem><para>Unmerges all currently installed system extension images from
+        <filename>/usr/</filename> and <filename>/opt/</filename> for sysext and <filename>/etc/</filename>,
+        for confext, by unmounting the <literal>overlayfs</literal> file systems created by <option>merge</option>
+        prior.</para>
+
+        <xi:include href="version-info.xml" xpointer="v248"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>refresh</option></term>
+        <listitem><para>A combination of <option>unmerge</option> and <option>merge</option>: if already
+        mounted the existing <literal>overlayfs</literal> instance is unmounted temporarily, and then
+        replaced by a new version. This command is useful after installing/removing system extension images,
+        in order to update the <literal>overlayfs</literal> file system accordingly. If no system extensions
+        are installed when this command is executed, the equivalent of <option>unmerge</option> is executed,
+        without establishing any new <literal>overlayfs</literal> instance.
+        Note that currently there's a brief moment where neither the old nor the new <literal>overlayfs</literal>
+        file system is mounted. This implies that all resources supplied by a system extension will briefly
+        disappear — even if it exists continuously during the refresh operation.</para>
+
+        <xi:include href="version-info.xml" xpointer="v248"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>list</option></term>
+
+        <listitem><para>A brief list of installed extension images is shown.</para>
+
+        <xi:include href="version-info.xml" xpointer="v248"/></listitem>
+      </varlistentry>
+
+      <xi:include href="standard-options.xml" xpointer="help" />
+      <xi:include href="standard-options.xml" xpointer="version" />
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <variablelist>
+      <varlistentry>
+        <term><option>--root=</option></term>
+
+        <listitem><para>Operate relative to the specified root directory, i.e. establish the
+        <literal>overlayfs</literal> mount not on the top-level host <filename>/usr/</filename> and
+        <filename>/opt/</filename> hierarchies for sysext or <filename>/etc/</filename> for confext,
+        but below some specified root directory.</para>
+
+        <xi:include href="version-info.xml" xpointer="v248"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--force</option></term>
+
+        <listitem><para>When merging system extensions into <filename>/usr/</filename> and
+        <filename>/opt/</filename> for sysext and <filename>/etc/</filename> for confext,
+        ignore version incompatibilities, i.e. force merging regardless of
+        whether the version information included in the images matches the host or not.</para>
+
+        <xi:include href="version-info.xml" xpointer="v248"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--image-policy=<replaceable>policy</replaceable></option></term>
+
+        <listitem><para>Takes an image policy string as argument, as per
+        <citerefentry><refentrytitle>systemd.image-policy</refentrytitle><manvolnum>7</manvolnum></citerefentry>. The
+        policy is enforced when operating on system extension disk images. If not specified defaults to
+        <literal>root=verity+signed+encrypted+unprotected+absent:usr=verity+signed+encrypted+unprotected+absent</literal>
+        for system extensions, i.e. only the root and <filename>/usr/</filename> file systems in the image
+        are used. For configuration extensions defaults to
+        <literal>root=verity+signed+encrypted+unprotected+absent</literal>. When run in the initrd and
+        operating on a system extension image stored in the <filename>/.extra/sysext/</filename> directory a
+        slightly stricter policy is used by default: <literal>root=signed+absent:usr=signed+absent</literal>,
+        see above for details.</para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--noexec=</option><replaceable>BOOL</replaceable></term>
+
+        <listitem><para>When merging configuration extensions into <filename>/etc/</filename> the
+        <literal>MS_NOEXEC</literal> mount flag is used by default. This option can be used to disable
+        it.</para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--no-reload</option></term>
+
+        <listitem>
+          <para>When used with <command>merge</command>,
+          <command>unmerge</command> or <command>refresh</command>, do not reload daemon
+          after executing the changes even if an extension that is applied requires a reload via the
+          <varname>EXTENSION_RELOAD_MANAGER=</varname> set to 1.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/>
+        </listitem>
+      </varlistentry>
+
+      <xi:include href="standard-options.xml" xpointer="no-pager" />
+      <xi:include href="standard-options.xml" xpointer="no-legend" />
+      <xi:include href="standard-options.xml" xpointer="json" />
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Exit status</title>
+
+    <para>On success, 0 is returned.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-stub</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-system-update-generator.xml b/man/systemd-system-update-generator.xml
new file mode 100644
index 0000000..1611a71
--- /dev/null
+++ b/man/systemd-system-update-generator.xml
@@ -0,0 +1,50 @@
+<?xml version="1.0"?>
+<!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+<refentry id="systemd-system-update-generator">
+
+  <refentryinfo>
+    <title>systemd-system-update-generator</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-system-update-generator</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-system-update-generator</refname>
+    <refpurpose>Generator for redirecting boot to offline update mode</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>/usr/lib/systemd/system-generators/systemd-system-update-generator</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><filename>systemd-system-update-generator</filename> is a
+    generator that automatically redirects the boot process to
+    <filename>system-update.target</filename>, if
+    <filename>/system-update</filename> or <filename>/etc/system-update</filename> exists. This is required to
+    implement the logic explained in the
+    <citerefentry><refentrytitle>systemd.offline-updates</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
+    </para>
+
+    <para><filename>systemd-system-update-generator</filename> implements
+    <citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-system.conf.xml b/man/systemd-system.conf.xml
new file mode 100644
index 0000000..3c06b65
--- /dev/null
+++ b/man/systemd-system.conf.xml
@@ -0,0 +1,727 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [
+<!ENTITY % entities SYSTEM "custom-entities.ent" >
+%entities;
+]>
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd-system.conf"
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+  <refentryinfo>
+    <title>systemd-system.conf</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-system.conf</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-system.conf</refname>
+    <refname>system.conf.d</refname>
+    <refname>systemd-user.conf</refname>
+    <refname>user.conf.d</refname>
+    <refpurpose>System and session service manager configuration files</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>/etc/systemd/system.conf</filename>,
+    <filename>/etc/systemd/system.conf.d/*.conf</filename>,
+    <filename>/run/systemd/system.conf.d/*.conf</filename>,
+    <filename>/usr/lib/systemd/system.conf.d/*.conf</filename></para>
+
+    <para><filename>~/.config/systemd/user.conf</filename>,
+    <filename>/etc/systemd/user.conf</filename>,
+    <filename>/etc/systemd/user.conf.d/*.conf</filename>,
+    <filename>/run/systemd/user.conf.d/*.conf</filename>,
+    <filename>/usr/lib/systemd/user.conf.d/*.conf</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>When run as a system instance, <command>systemd</command> interprets the configuration file
+    <filename>system.conf</filename> and the files in <filename>system.conf.d</filename> directories; when
+    run as a user instance, it interprets the configuration file <filename>user.conf</filename> (either in
+    the home directory of the user, or if not found, under <filename>/etc/systemd/</filename>) and the files
+    in <filename>user.conf.d</filename> directories. These configuration files contain a few settings
+    controlling basic manager operations.</para>
+
+    <para>See
+    <citerefentry><refentrytitle>systemd.syntax</refentrytitle><manvolnum>7</manvolnum></citerefentry> for a
+    general description of the syntax.</para>
+  </refsect1>
+
+  <xi:include href="standard-conf.xml" xpointer="main-conf" />
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>All options are configured in the
+    [Manager] section:</para>
+
+    <variablelist class='config-directives'>
+
+      <varlistentry>
+        <term><varname>LogColor=</varname></term>
+        <term><varname>LogLevel=</varname></term>
+        <term><varname>LogLocation=</varname></term>
+        <term><varname>LogTarget=</varname></term>
+        <term><varname>LogTime=</varname></term>
+        <term><varname>DumpCore=yes</varname></term>
+        <term><varname>CrashChangeVT=no</varname></term>
+        <term><varname>CrashShell=no</varname></term>
+        <term><varname>CrashReboot=no</varname></term>
+        <term><varname>ShowStatus=yes</varname></term>
+        <term><varname>DefaultStandardOutput=journal</varname></term>
+        <term><varname>DefaultStandardError=inherit</varname></term>
+
+        <listitem><para>Configures various parameters of basic manager operation. These options may be overridden by
+        the respective process and kernel command line arguments. See
+        <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> for
+        details.</para>
+
+        <xi:include href="version-info.xml" xpointer="v198"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>CtrlAltDelBurstAction=</varname></term>
+
+        <listitem><para>Defines what action will be performed
+        if user presses Ctrl-Alt-Delete more than 7 times in 2s.
+        Can be set to <literal>reboot-force</literal>, <literal>poweroff-force</literal>,
+        <literal>reboot-immediate</literal>, <literal>poweroff-immediate</literal>
+        or disabled with <literal>none</literal>. Defaults to
+        <literal>reboot-force</literal>.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v232"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>CPUAffinity=</varname></term>
+
+        <listitem><para>Configures the CPU affinity for the service manager as well as the default CPU
+        affinity for all forked off processes. Takes a list of CPU indices or ranges separated by either
+        whitespace or commas. CPU ranges are specified by the lower and upper CPU indices separated by a
+        dash. This option may be specified more than once, in which case the specified CPU affinity masks are
+        merged. If the empty string is assigned, the mask is reset, all assignments prior to this will have
+        no effect. Individual services may override the CPU affinity for their processes with the
+        <varname>CPUAffinity=</varname> setting in unit files, see
+        <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v198"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>NUMAPolicy=</varname></term>
+
+        <listitem><para>Configures the NUMA memory policy for the service manager and the default NUMA memory policy
+        for all forked off processes. Individual services may override the default policy with the
+        <varname>NUMAPolicy=</varname> setting in unit files, see
+        <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v243"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>NUMAMask=</varname></term>
+
+        <listitem><para>Configures the NUMA node mask that will be associated with the selected NUMA policy. Note that
+        <option>default</option> and <option>local</option> NUMA policies don't require explicit NUMA node mask and
+        value of the option can be empty. Similarly to <varname>NUMAPolicy=</varname>, value can be overridden
+        by individual services in unit files, see
+        <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v243"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RuntimeWatchdogSec=</varname></term>
+        <term><varname>RebootWatchdogSec=</varname></term>
+        <term><varname>KExecWatchdogSec=</varname></term>
+
+        <listitem><para>Configure the hardware watchdog at runtime and at reboot. Takes a timeout value in
+        seconds (or in other time units if suffixed with <literal>ms</literal>, <literal>min</literal>,
+        <literal>h</literal>, <literal>d</literal>, <literal>w</literal>), or the special strings
+        <literal>off</literal> or <literal>default</literal>. If set to <literal>off</literal>
+        (alternatively: <literal>0</literal>) the watchdog logic is disabled: no watchdog device is opened,
+        configured, or pinged. If set to the special string <literal>default</literal> the watchdog is opened
+        and pinged in regular intervals, but the timeout is not changed from the default. If set to any other
+        time value the watchdog timeout is configured to the specified value (or a value close to it,
+        depending on hardware capabilities).</para>
+
+        <para>If <varname>RuntimeWatchdogSec=</varname> is set to a non-zero value, the watchdog hardware
+        (<filename>/dev/watchdog0</filename> or the path specified with <varname>WatchdogDevice=</varname> or
+        the kernel option <varname>systemd.watchdog-device=</varname>) will be programmed to automatically
+        reboot the system if it is not contacted within the specified timeout interval. The system manager
+        will ensure to contact it at least once in half the specified timeout interval. This feature requires
+        a hardware watchdog device to be present, as it is commonly the case in embedded and server
+        systems. Not all hardware watchdogs allow configuration of all possible reboot timeout values, in
+        which case the closest available timeout is picked.</para>
+
+        <para><varname>RebootWatchdogSec=</varname> may be used to configure the hardware watchdog when the
+        system is asked to reboot. It works as a safety net to ensure that the reboot takes place even if a
+        clean reboot attempt times out. Note that the <varname>RebootWatchdogSec=</varname> timeout applies
+        only to the second phase of the reboot, i.e. after all regular services are already terminated, and
+        after the system and service manager process (PID 1) got replaced by the
+        <filename>systemd-shutdown</filename> binary, see system
+        <citerefentry><refentrytitle>bootup</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
+        details. During the first phase of the shutdown operation the system and service manager remains
+        running and hence <varname>RuntimeWatchdogSec=</varname> is still honoured. In order to define a
+        timeout on this first phase of system shutdown, configure <varname>JobTimeoutSec=</varname> and
+        <varname>JobTimeoutAction=</varname> in the [Unit] section of the
+        <filename>shutdown.target</filename> unit. By default <varname>RuntimeWatchdogSec=</varname> defaults
+        to 0 (off), and <varname>RebootWatchdogSec=</varname> to 10min.</para>
+
+        <para><varname>KExecWatchdogSec=</varname> may be used to additionally enable the watchdog when kexec
+        is being executed rather than when rebooting. Note that if the kernel does not reset the watchdog on
+        kexec (depending on the specific hardware and/or driver), in this case the watchdog might not get
+        disabled after kexec succeeds and thus the system might get rebooted, unless
+        <varname>RuntimeWatchdogSec=</varname> is also enabled at the same time.  For this reason it is
+        recommended to enable <varname>KExecWatchdogSec=</varname> only if
+        <varname>RuntimeWatchdogSec=</varname> is also enabled.</para>
+
+        <para>These settings have no effect if a hardware watchdog is not available.</para>
+
+        <xi:include href="version-info.xml" xpointer="v198"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RuntimeWatchdogPreSec=</varname></term>
+
+        <listitem><para>Configure the hardware watchdog device pre-timeout value.
+        Takes a timeout value in seconds (or in other time units similar to
+        <varname>RuntimeWatchdogSec=</varname>). A watchdog pre-timeout is a
+        notification generated by the watchdog before the watchdog reset might
+        occur in the event the watchdog has not been serviced. This notification
+        is handled by the kernel and can be configured to take an action (i.e.
+        generate a kernel panic) using <varname>RuntimeWatchdogPreGovernor=</varname>.
+        Not all watchdog hardware or drivers support generating a pre-timeout and
+        depending on the state of the system, the kernel may be unable to take the
+        configured action before the watchdog reboot. The watchdog will be configured
+        to generate the pre-timeout event at the amount of time specified by
+        <varname>RuntimeWatchdogPreSec=</varname> before the runtime watchdog timeout
+        (set by <varname>RuntimeWatchdogSec=</varname>). For example, if the we have
+        <varname>RuntimeWatchdogSec=30</varname> and
+        <varname>RuntimeWatchdogPreSec=10</varname>, then the pre-timeout event
+        will occur if the watchdog has not pinged for 20s (10s before the
+        watchdog would fire). By default, <varname>RuntimeWatchdogPreSec=</varname>
+        defaults to 0 (off). The value set for <varname>RuntimeWatchdogPreSec=</varname>
+        must be smaller than the timeout value for <varname>RuntimeWatchdogSec=</varname>.
+        This setting has no effect if a hardware watchdog is not available or the
+        hardware watchdog does not support a pre-timeout and will be ignored by the
+        kernel if the setting is greater than the actual watchdog timeout.</para>
+
+        <xi:include href="version-info.xml" xpointer="v251"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RuntimeWatchdogPreGovernor=</varname></term>
+
+        <listitem><para>Configure the action taken by the hardware watchdog device
+        when the pre-timeout expires. The default action for the pre-timeout event
+        depends on the kernel configuration, but it is usually to log a kernel
+        message. For a list of valid actions available for a given watchdog device,
+        check the content of the
+        <filename>/sys/class/watchdog/watchdog<replaceable>X</replaceable>/pretimeout_available_governors</filename>
+        file. Typically, available governor types are <varname>noop</varname> and <varname>panic</varname>.
+        Availability, names and functionality might vary depending on the specific device driver
+        in use. If the <filename>pretimeout_available_governors</filename> sysfs file is empty,
+        the governor might be built as a kernel module and might need to be manually loaded
+        (e.g. <varname>pretimeout_noop.ko</varname>), or the watchdog device might not support
+        pre-timeouts.</para>
+
+        <xi:include href="version-info.xml" xpointer="v251"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>WatchdogDevice=</varname></term>
+
+        <listitem><para>Configure the hardware watchdog device that the
+        runtime and shutdown watchdog timers will open and use. Defaults
+        to <filename>/dev/watchdog0</filename>. This setting has no
+        effect if a hardware watchdog is not available.</para>
+
+        <xi:include href="version-info.xml" xpointer="v236"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>CapabilityBoundingSet=</varname></term>
+
+        <listitem><para>Controls which capabilities to include in the
+        capability bounding set for PID 1 and its children. See
+        <citerefentry project='man-pages'><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+        for details. Takes a whitespace-separated list of capability
+        names as read by
+        <citerefentry project='mankier'><refentrytitle>cap_from_name</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+        Capabilities listed will be included in the bounding set, all
+        others are removed. If the list of capabilities is prefixed
+        with ~, all but the listed capabilities will be included, the
+        effect of the assignment inverted. Note that this option also
+        affects the respective capabilities in the effective,
+        permitted and inheritable capability sets. The capability
+        bounding set may also be individually configured for units
+        using the <varname>CapabilityBoundingSet=</varname> directive
+        for units, but note that capabilities dropped for PID 1 cannot
+        be regained in individual units, they are lost for
+        good.</para>
+
+        <xi:include href="version-info.xml" xpointer="v198"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>NoNewPrivileges=</varname></term>
+
+        <listitem><para>Takes a boolean argument. If true, ensures that PID 1
+        and all its children can never gain new privileges through
+        <citerefentry project='man-pages'><refentrytitle>execve</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+        (e.g. via setuid or setgid bits, or filesystem capabilities).
+        Defaults to false. General purpose distributions commonly rely
+        on executables with setuid or setgid bits and will thus not
+        function properly with this option enabled. Individual units
+        cannot disable this option.
+        Also see <ulink url="https://docs.kernel.org/userspace-api/no_new_privs.html">No New Privileges Flag</ulink>.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SystemCallArchitectures=</varname></term>
+
+        <listitem><para>Takes a space-separated list of architecture
+        identifiers. Selects from which architectures system calls may
+        be invoked on this system. This may be used as an effective
+        way to disable invocation of non-native binaries system-wide,
+        for example to prohibit execution of 32-bit x86 binaries on
+        64-bit x86-64 systems. This option operates system-wide, and
+        acts similar to the
+        <varname>SystemCallArchitectures=</varname> setting of unit
+        files, see
+        <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for details. This setting defaults to the empty list, in which
+        case no filtering of system calls based on architecture is
+        applied. Known architecture identifiers are
+        <literal>x86</literal>, <literal>x86-64</literal>,
+        <literal>x32</literal>, <literal>arm</literal> and the special
+        identifier <literal>native</literal>. The latter implicitly
+        maps to the native architecture of the system (or more
+        specifically, the architecture the system manager was compiled
+        for). Set this setting to <literal>native</literal> to
+        prohibit execution of any non-native binaries. When a binary
+        executes a system call of an architecture that is not listed
+        in this setting, it will be immediately terminated with the
+        SIGSYS signal.</para>
+
+        <xi:include href="version-info.xml" xpointer="v209"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>TimerSlackNSec=</varname></term>
+
+        <listitem><para>Sets the timer slack in nanoseconds for PID 1,
+        which is inherited by all executed processes, unless
+        overridden individually, for example with the
+        <varname>TimerSlackNSec=</varname> setting in service units
+        (for details see
+        <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
+        The timer slack controls the accuracy of wake-ups triggered by
+        system timers. See
+        <citerefentry><refentrytitle>prctl</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+        for more information. Note that in contrast to most other time
+        span definitions this parameter takes an integer value in
+        nano-seconds if no unit is specified. The usual time units are
+        understood too.</para>
+
+        <xi:include href="version-info.xml" xpointer="v198"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>StatusUnitFormat=</varname></term>
+
+        <listitem><para>Takes <option>name</option>, <option>description</option> or
+        <option>combined</option> as the value. If <option>name</option>, the system manager will use unit
+        names in status messages (e.g. <literal>systemd-journald.service</literal>), instead of the longer
+        and more informative descriptions set with <varname>Description=</varname> (e.g. <literal>Journal
+        Logging Service</literal>). If <option>combined</option>, the system manager will use both unit names
+        and descriptions in status messages (e.g. <literal>systemd-journald.service - Journal Logging
+        Service</literal>).</para>
+
+        <para>See
+        <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
+        details about unit names and <varname>Description=</varname>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v243"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>DefaultTimerAccuracySec=</varname></term>
+
+        <listitem><para>Sets the default accuracy of timer units. This
+        controls the global default for the
+        <varname>AccuracySec=</varname> setting of timer units, see
+        <citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for details. <varname>AccuracySec=</varname> set in individual
+        units override the global default for the specific unit.
+        Defaults to 1min. Note that the accuracy of timer units is
+        also affected by the configured timer slack for PID 1, see
+        <varname>TimerSlackNSec=</varname> above.</para>
+
+        <xi:include href="version-info.xml" xpointer="v212"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>DefaultTimeoutStartSec=</varname></term>
+        <term><varname>DefaultTimeoutStopSec=</varname></term>
+        <term><varname>DefaultTimeoutAbortSec=</varname></term>
+        <term><varname>DefaultRestartSec=</varname></term>
+
+        <listitem><para>Configures the default timeouts for starting, stopping and aborting of units, as well
+        as the default time to sleep between automatic restarts of units, as configured per-unit in
+        <varname>TimeoutStartSec=</varname>, <varname>TimeoutStopSec=</varname>,
+        <varname>TimeoutAbortSec=</varname> and <varname>RestartSec=</varname> (for services, see
+        <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for details on the per-unit settings). For non-service units,
+        <varname>DefaultTimeoutStartSec=</varname> sets the default <varname>TimeoutSec=</varname> value.
+        </para>
+
+        <para><varname>DefaultTimeoutStartSec=</varname> and <varname>DefaultTimeoutStopSec=</varname>
+        default to &DEFAULT_TIMEOUT; in the system manager and &DEFAULT_USER_TIMEOUT; in the user manager.
+        <varname>DefaultTimeoutAbortSec=</varname> is not set by default so that all units fall back to
+        <varname>TimeoutStopSec=</varname>. <varname>DefaultRestartSec=</varname> defaults to 100 ms.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v209"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>DefaultDeviceTimeoutSec=</varname></term>
+
+        <listitem><para>Configures the default timeout for waiting for devices. It can be changed per
+        device via the <varname>x-systemd.device-timeout=</varname> option in <filename>/etc/fstab</filename>
+        and <filename>/etc/crypttab</filename> (see
+        <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>crypttab</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
+        Defaults to &DEFAULT_TIMEOUT; in the system manager and &DEFAULT_USER_TIMEOUT; in the user manager.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>DefaultStartLimitIntervalSec=</varname></term>
+        <term><varname>DefaultStartLimitBurst=</varname></term>
+
+        <listitem><para>Configure the default unit start rate
+        limiting, as configured per-service by
+        <varname>StartLimitIntervalSec=</varname> and
+        <varname>StartLimitBurst=</varname>. See
+        <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for details on the per-service settings.
+        <varname>DefaultStartLimitIntervalSec=</varname> defaults to
+        10s. <varname>DefaultStartLimitBurst=</varname> defaults to
+        5.</para>
+
+        <xi:include href="version-info.xml" xpointer="v209"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>DefaultEnvironment=</varname></term>
+
+        <listitem><para>Configures environment variables passed to all executed processes. Takes a
+        space-separated list of variable assignments. See <citerefentry
+        project='man-pages'><refentrytitle>environ</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
+        details about environment variables.</para>
+
+        <para>Simple <literal>%</literal>-specifier expansion is supported, see below for a list of supported
+        specifiers.</para>
+
+        <para>Example:
+
+        <programlisting>DefaultEnvironment="VAR1=word1 word2" VAR2=word3 "VAR3=word 5 6"</programlisting>
+
+        Sets three variables
+        <literal>VAR1</literal>,
+        <literal>VAR2</literal>,
+        <literal>VAR3</literal>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v205"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ManagerEnvironment=</varname></term>
+
+        <listitem><para>Takes the same arguments as <varname>DefaultEnvironment=</varname>, see above. Sets
+        environment variables just for the manager process itself. In contrast to user managers, these variables
+        are not inherited by processes spawned by the system manager, use <varname>DefaultEnvironment=</varname>
+        for that. Note that these variables are merged into the existing environment block. In particular, in
+        case of the system manager, this includes variables set by the kernel based on the kernel command line.</para>
+
+        <para>Setting environment variables for the manager process may be useful to modify its behaviour.
+        See <ulink url="https://systemd.io/ENVIRONMENT">Known Environment Variables</ulink> for a
+        descriptions of some variables understood by <command>systemd</command>.</para>
+
+        <para>Simple <literal>%</literal>-specifier expansion is supported, see below for a list of supported
+        specifiers.</para>
+
+        <xi:include href="version-info.xml" xpointer="v248"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>DefaultCPUAccounting=</varname></term>
+        <term><varname>DefaultMemoryAccounting=</varname></term>
+        <term><varname>DefaultTasksAccounting=</varname></term>
+        <term><varname>DefaultIOAccounting=</varname></term>
+        <term><varname>DefaultIPAccounting=</varname></term>
+
+        <listitem>
+        <para>Configure the default resource accounting settings, as configured per-unit by
+        <varname>CPUAccounting=</varname>, <varname>MemoryAccounting=</varname>,
+        <varname>TasksAccounting=</varname>, <varname>IOAccounting=</varname> and
+        <varname>IPAccounting=</varname>. See
+        <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for details on the per-unit settings.</para>
+
+        <para><varname>DefaultCPUAccounting=</varname> defaults to yes when running on kernel ≥4.15, and no on older versions.
+        <varname>DefaultMemoryAccounting=</varname> defaults to &MEMORY_ACCOUNTING_DEFAULT;.
+        <varname>DefaultTasksAccounting=</varname> defaults to yes.
+        The other settings default to no.</para>
+
+        <xi:include href="version-info.xml" xpointer="v211"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>DefaultTasksMax=</varname></term>
+
+        <listitem><para>Configure the default value for the per-unit <varname>TasksMax=</varname> setting. See
+        <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for details. This setting applies to all unit types that support resource control settings, with the exception
+        of slice units. Defaults to 15% of the minimum of <varname>kernel.pid_max=</varname>, <varname>kernel.threads-max=</varname>
+        and root cgroup <varname>pids.max</varname>.
+        Kernel has a default value for <varname>kernel.pid_max=</varname> and an algorithm of counting in case of more than 32 cores.
+        For example, with the default <varname>kernel.pid_max=</varname>, <varname>DefaultTasksMax=</varname> defaults to 4915,
+        but might be greater in other systems or smaller in OS containers.</para>
+
+        <xi:include href="version-info.xml" xpointer="v228"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>DefaultLimitCPU=</varname></term>
+        <term><varname>DefaultLimitFSIZE=</varname></term>
+        <term><varname>DefaultLimitDATA=</varname></term>
+        <term><varname>DefaultLimitSTACK=</varname></term>
+        <term><varname>DefaultLimitCORE=</varname></term>
+        <term><varname>DefaultLimitRSS=</varname></term>
+        <term><varname>DefaultLimitNOFILE=</varname></term>
+        <term><varname>DefaultLimitAS=</varname></term>
+        <term><varname>DefaultLimitNPROC=</varname></term>
+        <term><varname>DefaultLimitMEMLOCK=</varname></term>
+        <term><varname>DefaultLimitLOCKS=</varname></term>
+        <term><varname>DefaultLimitSIGPENDING=</varname></term>
+        <term><varname>DefaultLimitMSGQUEUE=</varname></term>
+        <term><varname>DefaultLimitNICE=</varname></term>
+        <term><varname>DefaultLimitRTPRIO=</varname></term>
+        <term><varname>DefaultLimitRTTIME=</varname></term>
+
+        <listitem><para>These settings control various default resource limits for processes executed by
+        units. See
+        <citerefentry><refentrytitle>setrlimit</refentrytitle><manvolnum>2</manvolnum></citerefentry> for
+        details. These settings may be overridden in individual units using the corresponding
+        <varname>LimitXXX=</varname> directives and they accept the same parameter syntax,
+        see <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for details. Note that these resource limits are only defaults
+        for units, they are not applied to the service manager process (i.e. PID 1) itself.</para>
+
+        <para>Most of these settings are unset, which means the resource limits are inherited from the kernel or, if
+        invoked in a container, from the container manager. However, the following have defaults:</para>
+        <itemizedlist>
+          <listitem><para><varname>DefaultLimitNOFILE=</varname> defaults to 1024:&HIGH_RLIMIT_NOFILE;.
+          </para></listitem>
+
+          <listitem><para><varname>DefaultLimitMEMLOCK=</varname> defaults to 8M.</para></listitem>
+
+          <listitem><para><varname>DefaultLimitCORE=</varname> does not have a default but it is worth mentioning that
+          <varname>RLIMIT_CORE</varname> is set to <literal>infinity</literal> by PID 1 which is inherited by its
+          children.</para></listitem>
+        </itemizedlist>
+
+        <para>Note that the service manager internally in PID 1 bumps <varname>RLIMIT_NOFILE</varname> and
+        <varname>RLIMIT_MEMLOCK</varname> to higher values, however the limit is reverted to the mentioned
+        defaults for all child processes forked off.</para>
+
+        <xi:include href="version-info.xml" xpointer="v198"/>
+      </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>DefaultOOMPolicy=</varname></term>
+
+        <listitem><para>Configure the default policy for reacting to processes being killed by the Linux
+        Out-Of-Memory (OOM) killer or <command>systemd-oomd</command>. This may be used to pick a global default for the per-unit
+        <varname>OOMPolicy=</varname> setting. See
+        <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for details. Note that this default is not used for services that have <varname>Delegate=</varname>
+        turned on.</para>
+
+        <xi:include href="version-info.xml" xpointer="v243"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>DefaultOOMScoreAdjust=</varname></term>
+
+        <listitem><para>Configures the default OOM score adjustments of processes run by the service
+        manager. This defaults to unset (meaning the forked off processes inherit the service manager's OOM
+        score adjustment value), except if the service manager is run for an unprivileged user, in which case
+        this defaults to the service manager's OOM adjustment value plus 100 (this makes service processes
+        slightly more likely to be killed under memory pressure than the manager itself). This may be used to
+        pick a global default for the per-unit <varname>OOMScoreAdjust=</varname> setting. See
+        <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
+        details. Note that this setting has no effect on the OOM score adjustment value of the service
+        manager process itself, it retains the original value set during its invocation.</para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>DefaultSmackProcessLabel=</varname></term>
+
+        <listitem><para>Takes a <option>SMACK64</option> security label as the argument. The process executed
+        by a unit will be started under this label if <varname>SmackProcessLabel=</varname> is not set in the
+        unit. See <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for the details.</para>
+
+        <para>If the value is <literal>/</literal>, only labels specified with <varname>SmackProcessLabel=</varname>
+        are assigned and the compile-time default is ignored.</para>
+
+        <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ReloadLimitIntervalSec=</varname></term>
+        <term><varname>ReloadLimitBurst=</varname></term>
+
+        <listitem><para>Rate limiting for daemon-reload requests. Default to unset, and any number of daemon-reload
+        operations can be requested at any time. <varname>ReloadLimitIntervalSec=</varname> takes a value in seconds
+        to configure the rate limit window, and <varname>ReloadLimitBurst=</varname> takes a positive integer to
+        configure the maximum allowed number of reloads within the configured time window.</para>
+
+        <xi:include href="version-info.xml" xpointer="v253"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>DefaultMemoryPressureWatch=</varname></term>
+        <term><varname>DefaultMemoryPressureThresholdSec=</varname></term>
+
+        <listitem><para>Configures the default settings for the per-unit
+        <varname>MemoryPressureWatch=</varname> and <varname>MemoryPressureThresholdSec=</varname>
+        settings. See
+        <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for details. Defaults to <literal>auto</literal> and <literal>200ms</literal>, respectively. This
+        also sets the memory pressure monitoring threshold for the service manager itself.</para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Specifiers</title>
+
+    <para>Specifiers may be used in the <varname>DefaultEnvironment=</varname> and
+    <varname>ManagerEnvironment=</varname> settings. The following expansions are understood:</para>
+      <table class='specifiers'>
+        <title>Specifiers available</title>
+        <tgroup cols='3' align='left' colsep='1' rowsep='1'>
+          <colspec colname="spec" />
+          <colspec colname="mean" />
+          <colspec colname="detail" />
+          <thead>
+            <row>
+              <entry>Specifier</entry>
+              <entry>Meaning</entry>
+              <entry>Details</entry>
+            </row>
+          </thead>
+          <tbody>
+            <xi:include href="standard-specifiers.xml" xpointer="a"/>
+            <xi:include href="standard-specifiers.xml" xpointer="A"/>
+            <xi:include href="standard-specifiers.xml" xpointer="b"/>
+            <xi:include href="standard-specifiers.xml" xpointer="B"/>
+            <xi:include href="standard-specifiers.xml" xpointer="H"/>
+            <xi:include href="standard-specifiers.xml" xpointer="l"/>
+            <xi:include href="standard-specifiers.xml" xpointer="m"/>
+            <xi:include href="standard-specifiers.xml" xpointer="M"/>
+            <xi:include href="standard-specifiers.xml" xpointer="o"/>
+            <xi:include href="standard-specifiers.xml" xpointer="v"/>
+            <xi:include href="standard-specifiers.xml" xpointer="w"/>
+            <xi:include href="standard-specifiers.xml" xpointer="W"/>
+            <xi:include href="standard-specifiers.xml" xpointer="T"/>
+            <xi:include href="standard-specifiers.xml" xpointer="V"/>
+            <row>
+              <entry><literal>%h</literal></entry>
+              <entry>User home directory</entry>
+              <entry>This is the home directory of the <emphasis>user running the service manager instance</emphasis>.</entry>
+            </row>
+            <row>
+              <entry><literal>%u</literal></entry>
+              <entry>Username</entry>
+              <entry>This is the username of the <emphasis>user running the service manager instance</emphasis>.</entry>
+            </row>
+            <row>
+              <entry><literal>%U</literal></entry>
+              <entry>User id</entry>
+              <entry>This is the user id of the <emphasis>user running the service manager instance</emphasis>.</entry>
+            </row>
+            <row>
+              <entry><literal>%g</literal></entry>
+              <entry>Primary group</entry>
+              <entry>This is the primary group of the <emphasis>user running the service manager instance</emphasis>.</entry>
+            </row>
+            <row>
+              <entry><literal>%G</literal></entry>
+              <entry>Primary group id</entry>
+              <entry>This is the primary group id of the <emphasis>user running the service manager instance</emphasis>.</entry>
+            </row>
+            <row>
+              <entry><literal>%s</literal></entry>
+              <entry>User shell</entry>
+              <entry>This is the shell of the <emphasis>user running the service manager instance</emphasis>.</entry>
+            </row>
+            <xi:include href="standard-specifiers.xml" xpointer="percent"/>
+          </tbody>
+        </tgroup>
+      </table>
+  </refsect1>
+
+  <refsect1>
+      <title>History</title>
+
+      <variablelist>
+        <varlistentry>
+          <term>systemd 252</term>
+          <listitem><para>Option <varname>DefaultBlockIOAccounting=</varname> was deprecated. Please switch
+          to the unified cgroup hierarchy.</para>
+
+          <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+        </varlistentry>
+      </variablelist>
+  </refsect1>
+
+  <refsect1>
+      <title>See Also</title>
+      <para>
+        <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry project='man-pages'><refentrytitle>environ</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+        <citerefentry project='man-pages'><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+      </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-sysupdate.xml b/man/systemd-sysupdate.xml
new file mode 100644
index 0000000..65848b8
--- /dev/null
+++ b/man/systemd-sysupdate.xml
@@ -0,0 +1,319 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd-sysupdate" conditional='ENABLE_SYSUPDATE'
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd-sysupdate</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-sysupdate</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-sysupdate</refname>
+    <refname>systemd-sysupdate.service</refname>
+    <refname>systemd-sysupdate.timer</refname>
+    <refname>systemd-sysupdate-reboot.service</refname>
+    <refname>systemd-sysupdate-reboot.timer</refname>
+    <refpurpose>Automatically Update OS or Other Resources</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <cmdsynopsis>
+      <command>systemd-sysupdate</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+    </cmdsynopsis>
+
+    <para><filename>systemd-sysupdate.service</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>systemd-sysupdate</command> atomically updates the host OS, container images, portable
+    service images or other sources, based on the transfer configuration files described in
+    <citerefentry><refentrytitle>sysupdate.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+
+    <para>This tool implements file, directory, or partition based update schemes, supporting multiple
+    parallel installed versions of specific resources in an A/B (or even: A/B/C, A/B/C/D/, …) style. A/B
+    updating means that when one version of a resource is currently being used, the next version can be
+    downloaded, unpacked, and prepared in an entirely separate location, independently of the first, and — once
+    complete — be activated, swapping the roles so that it becomes the used one and the previously used one
+    becomes the one that is replaced by the next update, and so on. The resources to update are defined
+    in transfer files, one for each resource to be updated. For example, resources that may be updated with
+    this tool could be: a root file system partition, a matching Verity partition plus one kernel image. The
+    combination of the three would be considered a complete OS update.</para>
+
+    <para>The tool updates partitions, files or directory trees always in whole, and operates with at least
+    two versions of each of these resources: the <emphasis>current</emphasis> version, plus the
+    <emphasis>next</emphasis> version: the one that is being updated to, and which is initially incomplete as
+    the downloaded data is written to it; plus optionally more versions. Once the download of a newer version
+    is complete it becomes the current version, releasing the version previously considered current for
+    deletion/replacement/updating.</para>
+
+    <para>When installing new versions the tool will directly download, decompress, unpack and write the new
+    version into the destination. This is done in a robust fashion so that an incomplete download can be
+    recognized on next invocation, and flushed out before a new attempt is initiated.</para>
+
+    <para>Note that when writing updates to a partition, the partition has to exist already, as
+    <command>systemd-sysupdate</command> will not automatically create new partitions. Use a tool such as
+    <citerefentry><refentrytitle>systemd-repart</refentrytitle><manvolnum>8</manvolnum></citerefentry> to
+    automatically create additional partitions to be used with <command>systemd-sysupdate</command> on
+    boot.</para>
+
+    <para>The tool can both be used on the running OS, to update the OS in "online" state from within itself,
+    and on "offline" disk images, to update them from the outside based on transfer files
+    embedded in the disk images. For the latter, see <option>--image=</option> below. The latter is
+    particularly interesting to update container images or portable service images.</para>
+
+    <para>The <filename>systemd-sysupdate.service</filename> system service will automatically update the
+    host OS based on the installed transfer files. It is triggered in regular intervals via
+    <filename>systemd-sysupdate.timer</filename>. The <filename>systemd-sysupdate-reboot.service</filename>
+    will automatically reboot the system after a new version is installed. It is triggered via
+    <filename>systemd-sysupdate-reboot.timer</filename>. The two services are separate from each other as it
+    is typically advisable to download updates regularly while the system is up, but delay reboots until the
+    appropriate time (i.e. typically at night). The two sets of service/timer units may be enabled
+    separately.</para>
+
+    <para>For details about transfer files and examples see
+    <citerefentry><refentrytitle>sysupdate.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Command</title>
+
+    <para>The following commands are understood:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><option>list</option> <optional><replaceable>VERSION</replaceable></optional></term>
+
+        <listitem><para>If invoked without an argument, enumerates downloadable and installed versions, and
+        shows a summarizing table with the discovered versions and their properties, including whether
+        there's a newer candidate version to update to. If a version argument is specified, shows details
+        about the specific version, including the individual files that need to be transferred to acquire the
+        version.</para>
+
+        <para>If no command is explicitly specified this command is implied.</para>
+
+        <xi:include href="version-info.xml" xpointer="v251"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>check-new</option></term>
+
+        <listitem><para>Checks if there's a new version available. This internally enumerates downloadable and
+        installed versions and returns exit status 0 if there's a new version to update to, non-zero
+        otherwise. If there is a new version to update to, its version identifier is written to standard
+        output.</para>
+
+        <xi:include href="version-info.xml" xpointer="v251"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>update</option> <optional><replaceable>VERSION</replaceable></optional></term>
+
+        <listitem><para>Installs (updates to) the specified version, or if none is specified to the newest
+        version available. If the version is already installed or no newer version available, no operation is
+        executed.</para>
+
+        <para>If a new version to install/update to is found, old installed versions are deleted until at
+        least one new version can be installed, as configured via <varname>InstanceMax=</varname> in
+        <citerefentry><refentrytitle>sysupdate.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>, or
+        via the available partition slots of the right type. This implicit operation can also be invoked
+        explicitly via the <command>vacuum</command> command described below.</para>
+
+        <xi:include href="version-info.xml" xpointer="v251"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>vacuum</option></term>
+
+        <listitem><para>Deletes old installed versions until the limits configured via
+        <varname>InstanceMax=</varname> in
+        <citerefentry><refentrytitle>sysupdate.d</refentrytitle><manvolnum>5</manvolnum></citerefentry> are
+        met again. Normally, it should not be necessary to invoke this command explicitly, since it is
+        implicitly invoked whenever a new update is initiated.</para>
+
+        <xi:include href="version-info.xml" xpointer="v251"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>pending</option></term>
+
+        <listitem><para>Checks whether a newer version of the OS is installed than the one currently
+        running. Returns zero if so, non-zero otherwise. This compares the newest installed version's
+        identifier with the OS image version as reported by the <varname>IMAGE_VERSION=</varname> field in
+        <filename>/etc/os-release</filename>. If the former is newer than the latter, an update was
+        apparently completed but not activated (i.e. rebooted into) yet.</para>
+
+        <xi:include href="version-info.xml" xpointer="v251"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>reboot</option></term>
+
+        <listitem><para>Similar to the <option>pending</option> command but immediately reboots in case a
+        newer version of the OS has been installed than the one currently running. This operation can be done
+        implicitly together with the <command>update</command> command, after a completed update via the
+        <option>--reboot</option> switch, see below. This command will execute no operation (and return
+        success) if no update has been installed, and thus the system was not rebooted.</para>
+
+        <xi:include href="version-info.xml" xpointer="v251"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>components</option></term>
+
+        <listitem><para>Lists components that can be updated. This enumerates the
+        <filename>/etc/sysupdate.*.d/</filename>, <filename>/run/sysupdate.*.d/</filename> and
+        <filename>/usr/lib/sysupdate.*.d/</filename> directories that contain transfer files. This command is
+        useful to list possible parameters for <option>--component=</option> (see below).</para>
+
+        <xi:include href="version-info.xml" xpointer="v251"/></listitem>
+      </varlistentry>
+
+      <xi:include href="standard-options.xml" xpointer="help" />
+      <xi:include href="standard-options.xml" xpointer="version" />
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>The following options are understood:</para>
+
+    <variablelist>
+
+      <varlistentry>
+        <term><option>--component=</option></term>
+        <term><option>-C</option></term>
+
+        <listitem><para>Selects the component to update. Takes a component name as argument. This has the
+        effect of slightly altering the search logic for transfer files. If this switch is not used, the
+        transfer files are loaded from <filename>/etc/sysupdate.d/*.conf</filename>,
+        <filename>/run/sysupdate.d/*.conf</filename> and <filename>/usr/lib/sysupdate.d/*.conf</filename>. If
+        this switch is used, the specified component name is used to alter the directories to look in to be
+        <filename>/etc/sysupdate.<replaceable>component</replaceable>.d/*.conf</filename>,
+        <filename>/run/sysupdate.<replaceable>component</replaceable>.d/*.conf</filename> and
+        <filename>/usr/lib/sysupdate.<replaceable>component</replaceable>.d/*.conf</filename>, each time with
+        the <filename><replaceable>component</replaceable></filename> string replaced with the specified
+        component name.</para>
+
+        <para>Use the <command>components</command> command to list available components to update. This enumerates
+        the directories matching this naming rule.</para>
+
+        <para>Components may be used to define a separate set of transfer files for different components of
+        the OS that shall be updated separately. Do not use this concept for resources that shall always be
+        updated together in a synchronous fashion. Simply define multiple transfer files within the same
+        <filename>sysupdate.d/</filename> directory for these cases.</para>
+
+        <para>This option may not be combined with <option>--definitions=</option>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v251"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--definitions=</option></term>
+
+        <listitem><para>A path to a directory. If specified, the transfer <filename>*.conf</filename> files
+        are read from this directory instead of <filename>/usr/lib/sysupdate.d/*.conf</filename>,
+        <filename>/etc/sysupdate.d/*.conf</filename>, and <filename>/run/sysupdate.d/*.conf</filename>.</para>
+
+        <para>This option may not be combined with <option>--component=</option>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v251"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--root=</option></term>
+
+        <listitem><para>Takes a path to a directory to use as root file system when searching for
+        <filename>sysupdate.d/*.conf</filename> files.</para>
+
+        <xi:include href="version-info.xml" xpointer="v251"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--image=</option></term>
+
+        <listitem><para>Takes a path to a disk image file or device to mount and use in a similar fashion to
+        <option>--root=</option>, see above. If this is used and partition resources are updated this is done
+        inside the specified disk image.</para>
+
+        <xi:include href="version-info.xml" xpointer="v251"/></listitem>
+      </varlistentry>
+
+      <xi:include href="standard-options.xml" xpointer="image-policy-open" />
+
+      <varlistentry>
+        <term><option>--instances-max=</option></term>
+        <term><option>-m</option></term>
+
+        <listitem><para>Takes a decimal integer greater than or equal to 2. Controls how many versions to
+        keep at any time. This option may also be configured inside the transfer files, via the
+        <varname>InstancesMax=</varname> setting, see
+        <citerefentry><refentrytitle>sysupdate.d</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
+        details.</para>
+
+        <xi:include href="version-info.xml" xpointer="v251"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--sync=</option></term>
+
+        <listitem><para>Takes a boolean argument, defaults to yes. This may be used to specify whether the
+        newly updated resource versions shall be synchronized to disk when appropriate (i.e. after the
+        download is complete, before it is finalized, and again after finalization). This should not be
+        turned off, except to improve runtime performance in testing environments.</para>
+
+        <xi:include href="version-info.xml" xpointer="v251"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--verify=</option></term>
+
+        <listitem><para>Takes a boolean argument, defaults to yes. Controls whether to cryptographically
+        verify downloads. Do not turn this off, except in testing environments.</para>
+
+        <xi:include href="version-info.xml" xpointer="v251"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--reboot</option></term>
+
+        <listitem><para>When used in combination with the <command>update</command> command and a new version is
+        installed, automatically reboots the system immediately afterwards.</para>
+
+        <xi:include href="version-info.xml" xpointer="v251"/></listitem>
+      </varlistentry>
+
+      <xi:include href="standard-options.xml" xpointer="no-pager" />
+      <xi:include href="standard-options.xml" xpointer="no-legend" />
+      <xi:include href="standard-options.xml" xpointer="json" />
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Exit status</title>
+
+    <para>On success, 0 is returned, a non-zero failure code otherwise.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sysupdate.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-repart</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-sysusers.xml b/man/systemd-sysusers.xml
new file mode 100644
index 0000000..88645aa
--- /dev/null
+++ b/man/systemd-sysusers.xml
@@ -0,0 +1,238 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd-sysusers"
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd-sysusers</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-sysusers</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-sysusers</refname>
+    <refname>systemd-sysusers.service</refname>
+    <refpurpose>Allocate system users and groups</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <cmdsynopsis>
+      <command>systemd-sysusers</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="opt" rep="repeat"><replaceable>CONFIGFILE</replaceable></arg>
+    </cmdsynopsis>
+
+    <para><filename>systemd-sysusers.service</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>systemd-sysusers</command> creates system users and groups, based on files in the format
+    described in
+    <citerefentry><refentrytitle>sysusers.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+    </para>
+
+    <para>If invoked with no arguments, it applies all directives from all files found in the directories
+    specified by
+    <citerefentry><refentrytitle>sysusers.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>. When
+    invoked with positional arguments, if option <option>--replace=<replaceable>PATH</replaceable></option>
+    is specified, arguments specified on the command line are used instead of the configuration file
+    <replaceable>PATH</replaceable>. Otherwise, just the configuration specified by the command line
+    arguments is executed. The string <literal>-</literal> may be specified instead of a filename to instruct
+    <command>systemd-sysusers</command> to read the configuration from standard input. If the argument is a
+    relative path, all configuration directories are searched for a matching file and the file found that has
+    the highest priority is executed. If the argument is an absolute path, that file is used directly without
+    searching of the configuration directories.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>The following options are understood:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><option>--root=<replaceable>root</replaceable></option></term>
+        <listitem><para>Takes a directory path as an argument. All
+        paths will be prefixed with the given alternate
+        <replaceable>root</replaceable> path, including config search
+        paths. </para>
+
+        <xi:include href="version-info.xml" xpointer="v215"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--image=<replaceable>image</replaceable></option></term>
+
+        <listitem><para>Takes a path to a disk image file or block device node. If specified all operations
+        are applied to file system in the indicated disk image. This is similar to <option>--root=</option>
+        but operates on file systems stored in disk images or block devices. The disk image should either
+        contain just a file system or a set of file systems within a GPT partition table, following the
+        <ulink url="https://uapi-group.org/specifications/specs/discoverable_partitions_specification">Discoverable Partitions
+        Specification</ulink>. For further information on supported disk images, see
+        <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s
+        switch of the same name.</para>
+
+        <xi:include href="version-info.xml" xpointer="v247"/></listitem>
+      </varlistentry>
+
+      <xi:include href="standard-options.xml" xpointer="image-policy-open" />
+
+      <varlistentry>
+        <term><option>--replace=<replaceable>PATH</replaceable></option></term>
+        <listitem><para>When this option is given, one or more positional arguments
+        must be specified. All configuration files found in the directories listed in
+        <citerefentry><refentrytitle>sysusers.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        will be read, and the configuration given on the command line will be
+        handled instead of and with the same priority as the configuration file
+        <replaceable>PATH</replaceable>.</para>
+
+        <para>This option is intended to be used when package installation scripts
+        are running and files belonging to that package are not yet available on
+        disk, so their contents must be given on the command line, but the admin
+        configuration might already exist and should be given higher priority.
+        </para>
+
+        <example>
+          <title>RPM installation script for radvd</title>
+
+          <programlisting>echo 'u radvd - "radvd daemon"' | \
+          systemd-sysusers --replace=/usr/lib/sysusers.d/radvd.conf -</programlisting>
+
+          <para>This will create the radvd user as if
+          <filename>/usr/lib/sysusers.d/radvd.conf</filename> was already on disk.
+          An admin might override the configuration specified on the command line by
+          placing <filename>/etc/sysusers.d/radvd.conf</filename> or even
+          <filename>/etc/sysusers.d/00-overrides.conf</filename>.</para>
+
+          <para>Note that this is the expanded form, and when used in a package, this
+          would be written using a macro with "radvd" and a file containing the
+          configuration line as arguments.</para>
+        </example>
+
+          <xi:include href="version-info.xml" xpointer="v238"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--dry-run</option></term>
+        <listitem><para>Process the configuration and figure out what entries would be created, but don't
+        actually write anything.</para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--inline</option></term>
+        <listitem><para>Treat each positional argument as a separate configuration
+        line instead of a file name.</para>
+
+        <xi:include href="version-info.xml" xpointer="v238"/></listitem>
+      </varlistentry>
+
+      <xi:include href="standard-options.xml" xpointer="cat-config" />
+      <xi:include href="standard-options.xml" xpointer="tldr" />
+      <xi:include href="standard-options.xml" xpointer="no-pager" />
+      <xi:include href="standard-options.xml" xpointer="help" />
+      <xi:include href="standard-options.xml" xpointer="version" />
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Credentials</title>
+
+    <para><command>systemd-sysusers</command> supports the service credentials logic as implemented by
+    <varname>ImportCredential=</varname>/<varname>LoadCredential=</varname>/<varname>SetCredential=</varname>
+    (see <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>1</manvolnum></citerefentry> for
+    details). The following credentials are used when passed in:</para>
+
+    <variablelist class='system-credentials'>
+      <varlistentry>
+        <term><varname>passwd.hashed-password.<replaceable>user</replaceable></varname></term>
+        <listitem><para>A UNIX hashed password string to use for the specified user, when creating an entry
+        for it. This is particularly useful for the <literal>root</literal> user as it allows provisioning
+        the default root password to use via a unit file drop-in or from a container manager passing in this
+        credential. Note that setting this credential has no effect if the specified user account already
+        exists. This credential is hence primarily useful in first boot scenarios or systems that are fully
+        stateless and come up with an empty <filename>/etc/</filename> on every boot.</para>
+
+        <xi:include href="version-info.xml" xpointer="v249"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>passwd.plaintext-password.<replaceable>user</replaceable></varname></term>
+
+        <listitem><para>Similar to <literal>passwd.hashed-password.<replaceable>user</replaceable></literal>
+        but expect a literal, plaintext password, which is then automatically hashed before used for the user
+        account. If both the hashed and the plaintext credential are specified for the same user the
+        former takes precedence. It's generally recommended to specify the hashed version; however in test
+        environments with weaker requirements on security it might be easier to pass passwords in plaintext
+        instead.</para>
+
+        <xi:include href="version-info.xml" xpointer="v249"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>passwd.shell.<replaceable>user</replaceable></varname></term>
+
+        <listitem><para>Specifies the shell binary to use for the specified account when creating it.</para>
+
+        <xi:include href="version-info.xml" xpointer="v249"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>sysusers.extra</varname></term>
+
+        <listitem><para>The contents of this credential may contain additional lines to operate on. The
+        credential contents should follow the same format as any other <filename>sysusers.d/</filename>
+        drop-in. If this credential is passed it is processed after all of the drop-in files read from the
+        file system.</para>
+
+        <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+      </varlistentry>
+    </variablelist>
+
+    <para>Note that by default the <filename>systemd-sysusers.service</filename> unit file is set up to
+    inherit the <literal>passwd.hashed-password.root</literal>,
+    <literal>passwd.plaintext-password.root</literal>, <literal>passwd.shell.root</literal> and
+    <literal>sysusers.extra</literal> credentials from the service manager. Thus, when invoking a container
+    with an unpopulated <filename>/etc/</filename> for the first time it is possible to configure the root
+    user's password to be <literal>systemd</literal> like this:</para>
+
+    <para><programlisting># systemd-nspawn --image=… --set-credential=passwd.hashed-password.root:'$y$j9T$yAuRJu1o5HioZAGDYPU5d.$F64ni6J2y2nNQve90M/p0ZP0ECP/qqzipNyaY9fjGpC' …</programlisting></para>
+
+    <para>Note again that the data specified in this credential is consulted only when creating an account
+    for the first time, it may not be used for changing the password or shell of an account that already
+    exists.</para>
+
+    <para>Use <citerefentry project='man-pages'><refentrytitle>mkpasswd</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    for generating UNIX password hashes from the command line.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Exit status</title>
+
+    <para>On success, 0 is returned, a non-zero failure code
+    otherwise.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sysusers.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <ulink url="https://systemd.io/UIDS-GIDS">Users, Groups, UIDs and GIDs on systemd systems</ulink>,
+      <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>mkpasswd</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-sysv-generator.xml b/man/systemd-sysv-generator.xml
new file mode 100644
index 0000000..2172e09
--- /dev/null
+++ b/man/systemd-sysv-generator.xml
@@ -0,0 +1,73 @@
+<?xml version="1.0"?>
+<!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+<refentry id="systemd-sysv-generator" conditional="HAVE_SYSV_COMPAT">
+
+  <refentryinfo>
+    <title>systemd-sysv-generator</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-sysv-generator</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-sysv-generator</refname>
+    <refpurpose>Unit generator for SysV init scripts</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>/usr/lib/systemd/system-generators/systemd-sysv-generator</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><emphasis>Note: this component is deprecated and scheduled for removal. Please replace remaining
+    SysV init scripts with native unit files.</emphasis></para>
+
+    <para><filename>systemd-sysv-generator</filename> is a generator that creates wrapper .service units for
+    <ulink url="https://savannah.nongnu.org/projects/sysvinit">System V init</ulink> scripts in
+    <filename>/etc/init.d/*</filename> at boot and when configuration of the system manager is reloaded. This
+    allows <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> to
+    support them similarly to native units.</para>
+
+    <para><ulink
+    url="http://refspecs.linuxbase.org/LSB_3.1.1/LSB-Core-generic/LSB-Core-generic/iniscrptact.html">LSB
+    headers</ulink> in SysV init scripts are interpreted, and the ordering specified in the header is turned
+    into dependencies between the generated unit and other units. The LSB facilities
+    <literal>$remote_fs</literal>, <literal>$network</literal>, <literal>$named</literal>,
+    <literal>$portmap</literal>, <literal>$time</literal> are supported and will be turned into dependencies
+    on specific native systemd targets.  See
+    <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
+    more details.</para>
+
+    <para>Note that compatibility is quite comprehensive but not 100%, for more details see <ulink
+    url="https://www.freedesktop.org/wiki/Software/systemd/Incompatibilities">Incompatibilities with
+    SysV</ulink>.</para>
+
+    <para>SysV runlevels have corresponding systemd targets
+    (<filename>runlevel<replaceable>X</replaceable>.target</filename>).  The wrapper unit that is generated
+    will be wanted by those targets which correspond to runlevels for which the script is enabled.</para>
+
+    <para><command>systemd</command> does not support SysV scripts as part of early boot, so all wrapper
+    units are ordered after <filename>basic.target</filename>.</para>
+
+    <para><filename>systemd-sysv-generator</filename> implements
+    <citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-time-wait-sync.service.xml b/man/systemd-time-wait-sync.service.xml
new file mode 100644
index 0000000..fe7ef17
--- /dev/null
+++ b/man/systemd-time-wait-sync.service.xml
@@ -0,0 +1,73 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd-time-wait-sync.service" conditional='ENABLE_TIMESYNCD'
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd-time-wait-sync.service</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-time-wait-sync.service</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-time-wait-sync.service</refname>
+    <refname>systemd-time-wait-sync</refname>
+    <refpurpose>Wait until kernel time is synchronized</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>systemd-time-wait-sync.service</filename></para>
+    <para><filename>/usr/lib/systemd/systemd-time-wait-sync</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><filename>systemd-time-wait-sync</filename> is a system service that delays the start of units that
+    are ordered after <filename>time-sync.target</filename> (see
+    <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
+    details) until the system time has been synchronized with an accurate remote reference time source by
+    <filename>systemd-timesyncd.service</filename>.</para>
+
+    <para><filename>systemd-timesyncd.service</filename> notifies <filename>systemd-time-wait-sync</filename>
+    about successful synchronization.  <filename>systemd-time-wait-sync</filename> also tries to detect when
+    the kernel marks the system clock as synchronized, but this detection is not reliable and is intended
+    only as a fallback for compatibility with alternative NTP services that can be used to synchronize time
+    (e.g., ntpd, chronyd).</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Files</title>
+
+    <variablelist>
+      <varlistentry>
+        <term><filename>/run/systemd/timesync/synchronized</filename></term>
+
+        <listitem>
+          <para>The presence of this file indicates to this service that the system clock has been synchronized.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/>
+        </listitem>
+
+      </varlistentry>
+    </variablelist>
+
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-timesyncd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-timedated.service.xml b/man/systemd-timedated.service.xml
new file mode 100644
index 0000000..112bdf3
--- /dev/null
+++ b/man/systemd-timedated.service.xml
@@ -0,0 +1,105 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd-timedated.service" conditional='ENABLE_TIMEDATED'>
+
+  <refentryinfo>
+    <title>systemd-timedated.service</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-timedated.service</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-timedated.service</refname>
+    <refname>systemd-timedated</refname>
+    <refpurpose>Time and date bus mechanism</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>systemd-timedated.service</filename></para>
+    <para><filename>/usr/lib/systemd/systemd-timedated</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><filename>systemd-timedated.service</filename> is a system service
+    that may be used as a mechanism to change the system clock and
+    timezone, as well as to enable/disable network time synchronization.
+    <filename>systemd-timedated</filename> is automatically activated
+    on request and terminates itself when it is unused.</para>
+
+    <para>The tool
+    <citerefentry><refentrytitle>timedatectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    is a command line client to this service.</para>
+
+    <para><filename>systemd-timedated</filename> currently offers access to
+    the following four settings:
+    <itemizedlist>
+      <listitem><para>The system time</para></listitem>
+
+      <listitem><para>The system timezone</para></listitem>
+
+      <listitem><para>A boolean controlling whether the system RTC is in local or UTC
+      timezone</para></listitem>
+
+      <listitem><para>Whether the time synchronization service is enabled/started or
+      disabled/stopped, see next section.</para></listitem>
+    </itemizedlist></para>
+
+    <para>See
+    <citerefentry><refentrytitle>org.freedesktop.timedate1</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    and
+    <citerefentry><refentrytitle>org.freedesktop.LogControl1</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for information about the D-Bus API.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>List of network time synchronization services</title>
+
+    <para><command>systemd-timesyncd</command> will look for files with a <literal>.list</literal> extension
+    in <filename>ntp-units.d/</filename> directories. Each file is parsed as a list of unit names, one per
+    line. Empty lines and lines with comments (<literal>#</literal>) are ignored.  Files are read from
+    <filename>/usr/lib/systemd/ntp-units.d/</filename> and the corresponding directories under
+    <filename>/etc/</filename>, <filename>/run/</filename>, <filename>/usr/local/lib/</filename>. Files in
+    <filename>/etc/</filename> override files with the same name in <filename>/run/</filename>,
+    <filename>/usr/local/lib/</filename>, and <filename>/usr/lib/</filename>. Files in
+    <filename>/run/</filename> override files with the same name under <filename>/usr/</filename>. Packages
+    should install their configuration files in <filename>/usr/lib/</filename> (distribution packages) or
+    <filename>/usr/local/lib/</filename> (local installs).</para>
+
+    <example>
+      <title><filename>ntp-units.d/</filename> entry for <command>systemd-timesyncd</command></title>
+      <programlisting># /usr/lib/systemd/ntp-units.d/80-systemd-timesync.list
+systemd-timesyncd.service
+</programlisting>
+    </example>
+
+    <para>If the environment variable <varname>$SYSTEMD_TIMEDATED_NTP_SERVICES</varname> is set,
+    <command>systemd-timesyncd</command> will parse the contents of that variable as a colon-separated list
+    of unit names. When set, this variable overrides the file-based list described above.</para>
+
+    <example>
+      <title>An override that specifies that <command>chronyd</command> should be used if available</title>
+      <programlisting>SYSTEMD_TIMEDATED_NTP_SERVICES=chronyd.service:systemd-timesyncd.service</programlisting>
+    </example>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>timedatectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>localtime</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>hwclock</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-timesyncd</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-timesyncd.service.xml b/man/systemd-timesyncd.service.xml
new file mode 100644
index 0000000..87625ac
--- /dev/null
+++ b/man/systemd-timesyncd.service.xml
@@ -0,0 +1,134 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd-timesyncd.service" conditional='ENABLE_TIMESYNCD'
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd-timesyncd.service</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-timesyncd.service</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-timesyncd.service</refname>
+    <refname>systemd-timesyncd</refname>
+    <refpurpose>Network Time Synchronization</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>systemd-timesyncd.service</filename></para>
+    <para><filename>/usr/lib/systemd/systemd-timesyncd</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><filename>systemd-timesyncd</filename> is a system service that may be used to synchronize the
+    local system clock with a remote Network Time Protocol (NTP) server. It also saves the local time to disk
+    every time the clock has been synchronized and uses this to possibly advance the system realtime clock on
+    subsequent reboots to ensure it (roughly) monotonically advances even if the system lacks a
+    battery-buffered RTC chip.</para>
+
+    <para>The <filename>systemd-timesyncd</filename> service implements SNTP only. This minimalistic service
+    will step the system clock for large offsets or slowly adjust it for smaller deltas. Complex use cases
+    that require full NTP support (and where SNTP is not sufficient) are not covered by
+    <filename>systemd-timesyncd</filename>.</para>
+
+    <para>The NTP servers contacted are determined from the global settings in
+    <citerefentry><refentrytitle>timesyncd.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>, the
+    per-link static settings in <filename>.network</filename> files, and the per-link dynamic settings
+    received over DHCP. See
+    <citerefentry><refentrytitle>systemd.network</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
+    further details.</para>
+
+    <para><citerefentry><refentrytitle>timedatectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s
+    <command>set-ntp</command> command may be used to enable and start, or disable and stop this
+    service.</para>
+
+    <para><citerefentry><refentrytitle>timedatectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s
+    <command>timesync-status</command> or <command>show-timesync</command> command can be used to show the
+    current status of this service.</para>
+
+    <para><filename>systemd-timesyncd</filename> initialization delays the start of units that are ordered
+    after <filename>time-set.target</filename> (see
+    <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
+    details) until the local time has been updated from <filename>/var/lib/systemd/timesync/clock</filename>
+    (see below) in order to make it roughly monotonic. It does not delay other units until synchronization
+    with an accurate reference time sources has been reached. Use
+    <citerefentry><refentrytitle>systemd-time-wait-sync.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    to achieve that, which will delay start of units that are ordered after
+    <filename>time-sync.target</filename> until synchronization to an accurate reference clock is
+    reached.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Files</title>
+
+    <variablelist>
+      <varlistentry>
+        <term><filename>/var/lib/systemd/timesync/clock</filename></term>
+
+        <listitem>
+          <para>The modification time ("mtime") of this file is updated on each successful NTP
+          synchronization or after each <varname>SaveIntervalSec=</varname> time interval, as specified in
+          <citerefentry><refentrytitle>timesyncd.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+
+          <para>When initializing, the local clock is advanced to the modification time of this file (if the
+          file timestamp is in the past this adjustment is not made). If the file does not exist yet, the
+          clock is instead advanced to the modification time of <filename>/usr/lib/clock-epoch</filename> –
+          if it exists – or to a time derived from the source tree at build time. This mechanism is used to
+          ensure that the system clock remains somewhat reasonably initialized and roughly monotonic across
+          reboots, in case no battery-buffered local RTC is available.</para>
+
+          <xi:include href="version-info.xml" xpointer="v219"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>/usr/lib/clock-epoch</filename></term>
+
+        <listitem><para>The modification time ("mtime") of this file is used for advancing the system clock
+        in case <filename>/var/lib/systemd/timesync/clock</filename> does not exist yet, see
+        above.</para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>/run/systemd/timesync/synchronized</filename></term>
+
+        <listitem>
+          <para>A file that is touched on each successful synchronization, to assist
+          <filename>systemd-time-wait-sync</filename> and other applications to detecting synchronization
+          with accurate reference clocks.</para>
+
+          <xi:include href="version-info.xml" xpointer="v239"/>
+        </listitem>
+
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>timesyncd.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.network</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-time-wait-sync.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>timedatectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>localtime</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>hwclock</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-tmpfiles.xml b/man/systemd-tmpfiles.xml
new file mode 100644
index 0000000..d0f8ed3
--- /dev/null
+++ b/man/systemd-tmpfiles.xml
@@ -0,0 +1,349 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd-tmpfiles"
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd-tmpfiles</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-tmpfiles</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-tmpfiles</refname>
+    <refname>systemd-tmpfiles-setup.service</refname>
+    <refname>systemd-tmpfiles-setup-dev-early.service</refname>
+    <refname>systemd-tmpfiles-setup-dev.service</refname>
+    <refname>systemd-tmpfiles-clean.service</refname>
+    <refname>systemd-tmpfiles-clean.timer</refname>
+    <refpurpose>Creates, deletes and cleans up volatile
+    and temporary files and directories</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <cmdsynopsis>
+      <command>systemd-tmpfiles</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="opt" rep="repeat"><replaceable>CONFIGFILE</replaceable></arg>
+    </cmdsynopsis>
+
+    <para>System units:
+<literallayout><filename>systemd-tmpfiles-setup.service</filename>
+<filename>systemd-tmpfiles-setup-dev-early.service</filename>
+<filename>systemd-tmpfiles-setup-dev.service</filename>
+<filename>systemd-tmpfiles-clean.service</filename>
+<filename>systemd-tmpfiles-clean.timer</filename></literallayout></para>
+
+    <para>User units:
+<literallayout><filename>systemd-tmpfiles-setup.service</filename>
+<filename>systemd-tmpfiles-clean.service</filename>
+<filename>systemd-tmpfiles-clean.timer</filename></literallayout></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>systemd-tmpfiles</command> creates, deletes, and cleans up volatile and temporary files
+    and directories, using the configuration file format and location specified in
+    <citerefentry><refentrytitle>tmpfiles.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>. It must
+    be invoked with one or more options <option>--create</option>, <option>--remove</option>, and
+    <option>--clean</option>, to select the respective subset of operations.</para>
+
+    <para>By default, directives from all configuration files are applied. When invoked with
+    <option>--replace=<replaceable>PATH</replaceable></option>, arguments specified on the command line are
+    used instead of the configuration file <replaceable>PATH</replaceable>. Otherwise, if one or more
+    absolute filenames are passed on the command line, only the directives in these files are applied. If
+    <literal>-</literal> is specified instead of a filename, directives are read from standard input. If only
+    the basename of a configuration file is specified, all configuration directories as specified in
+    <citerefentry><refentrytitle>tmpfiles.d</refentrytitle><manvolnum>5</manvolnum></citerefentry> are
+    searched for a matching file and the file found that has the highest priority is executed.</para>
+
+    <para>System services (<filename>systemd-tmpfiles-setup.service</filename>,
+    <filename>systemd-tmpfiles-setup-dev-early.service</filename>,
+    <filename>systemd-tmpfiles-setup-dev.service</filename>,
+    <filename>systemd-tmpfiles-clean.service</filename>) invoke <command>systemd-tmpfiles</command> to create
+    system files and to perform system wide cleanup. Those services read administrator-controlled
+    configuration files in <filename>tmpfiles.d/</filename> directories. User services
+    (<filename>systemd-tmpfiles-setup.service</filename>,
+    <filename>systemd-tmpfiles-clean.service</filename>) also invoke <command>systemd-tmpfiles</command>, but
+    it reads a separate set of files, which includes user-controlled files under
+    <filename>~/.config/user-tmpfiles.d/</filename> and <filename>~/.local/share/user-tmpfiles.d/</filename>,
+    and administrator-controlled files under <filename>/usr/share/user-tmpfiles.d/</filename>. Users may use
+    this to create and clean up files under their control, but the system instance performs global cleanup
+    and is not influenced by user configuration. Note that this means a time-based cleanup configured in the
+    system instance, such as the one typically configured for <filename>/tmp/</filename>, will thus also
+    affect files created by the user instance if they are placed in <filename>/tmp/</filename>, even if the
+    user instance's time-based cleanup is turned off.</para>
+
+    <para>To re-apply settings after configuration has been modified, simply restart
+    <filename>systemd-tmpfiles-clean.service</filename>, which will apply any settings which can be safely
+    executed at runtime. To debug <command>systemd-tmpfiles</command>, it may be useful to invoke it
+    directly from the command line with increased log level (see <varname>$SYSTEMD_LOG_LEVEL</varname>
+    below).</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>The following options are understood:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><option>--create</option></term>
+        <listitem><para>If this option is passed, all files and
+        directories marked with
+        <varname>f</varname>,
+        <varname>F</varname>,
+        <varname>w</varname>,
+        <varname>d</varname>,
+        <varname>D</varname>,
+        <varname>v</varname>,
+        <varname>p</varname>,
+        <varname>L</varname>,
+        <varname>c</varname>,
+        <varname>b</varname>,
+        <varname>m</varname>
+        in the configuration files are created or written to. Files
+        and directories marked with
+        <varname>z</varname>,
+        <varname>Z</varname>,
+        <varname>t</varname>,
+        <varname>T</varname>,
+        <varname>a</varname>, and
+        <varname>A</varname> have their ownership, access mode and
+        security labels set.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--clean</option></term>
+        <listitem><para>If this option is passed, all files and
+        directories with an age parameter configured will be cleaned
+        up.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--remove</option></term>
+        <listitem><para>If this option is passed, the contents of
+        directories marked with <varname>D</varname> or
+        <varname>R</varname>, and files or directories themselves
+        marked with <varname>r</varname> or <varname>R</varname> are
+        removed unless an exclusive or shared BSD lock is taken on them (see <citerefentry
+        project='man-pages'><refentrytitle>flock</refentrytitle><manvolnum>2</manvolnum></citerefentry>).
+        </para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--user</option></term>
+        <listitem><para>Execute "user" configuration, i.e. <filename>tmpfiles.d</filename>
+        files in user configuration directories.</para>
+
+        <xi:include href="version-info.xml" xpointer="v236"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--boot</option></term>
+        <listitem><para>Also execute lines with an exclamation mark. Lines that are not safe to be executed
+        on a running system may be marked in this way. <command>systemd-tmpfiles</command> is executed in
+        early boot with <option>--boot</option> specified and will execute those lines. When invoked again
+        later, it should be called without <option>--boot</option>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v209"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--graceful</option></term>
+        <listitem><para>Ignore configuration lines pertaining to unknown users or groups. This option is
+        intended to be used in early boot before all users or groups have been created.</para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--prefix=<replaceable>path</replaceable></option></term>
+        <listitem><para>Only apply rules with paths that start with
+        the specified prefix. This option can be specified multiple
+        times.</para>
+
+        <xi:include href="version-info.xml" xpointer="v212"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--exclude-prefix=<replaceable>path</replaceable></option></term>
+        <listitem><para>Ignore rules with paths that start with the
+        specified prefix. This option can be specified multiple
+        times.</para>
+
+        <xi:include href="version-info.xml" xpointer="v207"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-E</option></term>
+        <listitem><para>A shortcut for <literal>--exclude-prefix=/dev --exclude-prefix=/proc
+        --exclude-prefix=/run --exclude-prefix=/sys</literal>, i.e. exclude the hierarchies typically backed
+        by virtual or memory file systems. This is useful in combination with <option>--root=</option>, if
+        the specified directory tree contains an OS tree without these virtual/memory file systems mounted
+        in, as it is typically not desirable to create any files and directories below these subdirectories
+        if they are supposed to be overmounted during runtime.</para>
+
+        <xi:include href="version-info.xml" xpointer="v247"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--root=<replaceable>root</replaceable></option></term>
+        <listitem><para>Takes a directory path as an argument. All paths will be prefixed with the given alternate
+        <replaceable>root</replaceable> path, including config search paths.</para>
+
+        <para>When this option is used, the libc Name Service Switch (NSS) is bypassed for resolving users
+        and groups. Instead the files <filename>/etc/passwd</filename> and <filename>/etc/group</filename>
+        inside the alternate root are read directly. This means that users/groups not listed in these files
+        will not be resolved, i.e. LDAP NIS and other complex databases are not considered.</para>
+
+        <para>Consider combining this with <option>-E</option> to ensure the invocation does not create files
+        or directories below mount points in the OS image operated on that are typically overmounted during
+        runtime.</para>
+
+        <xi:include href="version-info.xml" xpointer="v212"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--image=<replaceable>image</replaceable></option></term>
+
+        <listitem><para>Takes a path to a disk image file or block device node. If specified all operations
+        are applied to file system in the indicated disk image. This is similar to <option>--root=</option>
+        but operates on file systems stored in disk images or block devices. The disk image should either
+        contain just a file system or a set of file systems within a GPT partition table, following the
+        <ulink url="https://uapi-group.org/specifications/specs/discoverable_partitions_specification">Discoverable Partitions
+        Specification</ulink>. For further information on supported disk images, see
+        <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s
+        switch of the same name.</para>
+
+        <para>Implies <option>-E</option>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v247"/></listitem>
+      </varlistentry>
+
+      <xi:include href="standard-options.xml" xpointer="image-policy-open" />
+
+      <varlistentry>
+        <term><option>--replace=<replaceable>PATH</replaceable></option></term>
+        <listitem><para>When this option is given, one or more positional arguments
+        must be specified. All configuration files found in the directories listed in
+        <citerefentry><refentrytitle>tmpfiles.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        will be read, and the configuration given on the command line will be
+        handled instead of and with the same priority as the configuration file
+        <replaceable>PATH</replaceable>.</para>
+
+        <para>This option is intended to be used when package installation scripts
+        are running and files belonging to that package are not yet available on
+        disk, so their contents must be given on the command line, but the admin
+        configuration might already exist and should be given higher priority.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v238"/></listitem>
+      </varlistentry>
+
+      <xi:include href="standard-options.xml" xpointer="cat-config" />
+      <xi:include href="standard-options.xml" xpointer="tldr" />
+      <xi:include href="standard-options.xml" xpointer="no-pager" />
+      <xi:include href="standard-options.xml" xpointer="help" />
+      <xi:include href="standard-options.xml" xpointer="version" />
+    </variablelist>
+
+    <para>It is possible to combine <option>--create</option>, <option>--clean</option>, and <option>--remove</option>
+    in one invocation (in which case removal and cleanup are executed before creation of new files). For example,
+    during boot the following command line is executed to ensure that all temporary and volatile directories are
+    removed and created according to the configuration file:</para>
+
+    <programlisting>systemd-tmpfiles --remove --create</programlisting>
+  </refsect1>
+
+  <refsect1>
+    <title>Credentials</title>
+
+    <para><command>systemd-tmpfiles</command> supports the service credentials logic as implemented by
+    <varname>ImportCredential=</varname>/<varname>LoadCredential=</varname>/<varname>SetCredential=</varname>
+    (see <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
+    details). The following credentials are used when passed in:</para>
+
+    <variablelist class='system-credentials'>
+      <varlistentry>
+        <term><varname>tmpfiles.extra</varname></term>
+
+        <listitem><para> The contents of this credential may contain additional lines to operate on. The
+        credential contents should follow the same format as any other <filename>tmpfiles.d/</filename>
+        drop-in configuration file. If this credential is passed it is processed after all of the drop-in
+        files read from the file system. The lines in the credential can hence augment existing lines of the
+        OS, but not override them.</para>
+
+        <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+      </varlistentry>
+    </variablelist>
+
+    <para>Note that by default the <filename>systemd-tmpfiles-setup.service</filename> unit file (and related
+    unit files) is set up to inherit the <literal>tmpfiles.extra</literal> credential from the service
+    manager.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Environment</title>
+
+    <variablelist class='environment-variables'>
+      <xi:include href="common-variables.xml" xpointer="log-level" />
+      <xi:include href="common-variables.xml" xpointer="log-color" />
+      <xi:include href="common-variables.xml" xpointer="log-time" />
+      <xi:include href="common-variables.xml" xpointer="log-location" />
+      <xi:include href="common-variables.xml" xpointer="log-target" />
+      <xi:include href="common-variables.xml" xpointer="pager" />
+      <xi:include href="common-variables.xml" xpointer="less" />
+      <xi:include href="common-variables.xml" xpointer="lesscharset" />
+      <xi:include href="common-variables.xml" xpointer="lesssecure" />
+      <xi:include href="common-variables.xml" xpointer="colors" />
+      <xi:include href="common-variables.xml" xpointer="urlify" />
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Unprivileged --cleanup operation</title>
+
+    <para><command>systemd-tmpfiles</command> tries to avoid changing
+    the access and modification times on the directories it accesses,
+    which requires <constant>CAP_FOWNER</constant> privileges. When
+    running as non-root, directories which are checked for files to
+    clean up will have their access time bumped, which might prevent
+    their cleanup.
+    </para>
+  </refsect1>
+
+  <refsect1>
+    <title>Exit status</title>
+
+    <para>On success, 0 is returned. If the configuration was syntactically invalid (syntax errors, missing
+    arguments, …), so some lines had to be ignored, but no other errors occurred, <constant>65</constant> is
+    returned (<constant>EX_DATAERR</constant> from <filename>/usr/include/sysexits.h</filename>). If the
+    configuration was syntactically valid, but could not be executed (lack of permissions, creation of files
+    in missing directories, invalid contents when writing to <filename>/sys/</filename> values, …),
+    <constant>73</constant> is returned (<constant>EX_CANTCREAT</constant> from
+    <filename>/usr/include/sysexits.h</filename>). Otherwise, <constant>1</constant> is returned
+    (<constant>EXIT_FAILURE</constant> from <filename>/usr/include/stdlib.h</filename>).</para>
+
+    <para>Note: when creating items, if the target already exists, but is of the wrong type or otherwise does
+    not match the requested state, and forced operation has not been requested with <literal>+</literal>,
+    a message is emitted, but the failure is otherwise ignored.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>tmpfiles.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-tpm2-setup.service.xml b/man/systemd-tpm2-setup.service.xml
new file mode 100644
index 0000000..8c13895
--- /dev/null
+++ b/man/systemd-tpm2-setup.service.xml
@@ -0,0 +1,82 @@
+<?xml version="1.0"?>
+<!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+<refentry id="systemd-tpm2-setup.service" conditional='ENABLE_BOOTLOADER'
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd-tpm2-setup.service</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-tpm2-setup.service</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-tpm2-setup.service</refname>
+    <refname>systemd-tpm2-setup-early.service</refname>
+    <refname>systemd-tpm2-setup</refname>
+    <refpurpose>Set up the TPM2 Storage Root Key (SRK) at boot</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>systemd-tpm2-setup.service</filename></para>
+    <para><filename>/usr/lib/systemd/systemd-tpm2-setup</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><filename>systemd-tpm2-setup.service</filename> and
+    <filename>systemd-tpm2-setup-early.service</filename> are services that generate the Storage Root Key
+    (SRK) if it hasn't been generated yet, and stores it in the TPM.</para>
+
+    <para>The services will store the public key of the SRK key pair in a PEM file in
+    <filename>/run/systemd/tpm2-srk-public-key.pem</filename> and
+    <filename>/var/lib/systemd/tpm2-srk-public-key.pem</filename>. It will also store it in TPM2B_PUBLIC
+    format in <filename>/run/systemd/tpm2-srk-public-key.tpm2_public</filename> and
+    <filename>/var/lib/systemd/tpm2-srk-public-key.tpm2b_public</filename>.</para>
+
+    <para><filename>systemd-tpm2-setup-early.service</filename> runs very early at boot (possibly in the
+    initrd), and writes the SRK public key to <filename>/run/systemd/tpm2-srk-public-key.*</filename> (as
+    <filename>/var/</filename> is generally not accessible this early yet), while
+    <filename>systemd-tpm2-setup.service</filename> runs during a later boot phase and saves the public key
+    to <filename>/var/lib/systemd/tpm2-srk-public-key.*</filename>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Files</title>
+
+    <variablelist>
+      <varlistentry>
+        <term><filename>/run/systemd/tpm2-srk-public-key.pem</filename></term>
+        <term><filename>/run/systemd/tpm2-srk-public-key.tpm2b_public</filename></term>
+
+        <listitem><para>The SRK public key in PEM and TPM2B_PUBLIC format, written during early boot.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>/var/lib/systemd/tpm2-srk-public-key.pem</filename></term>
+        <term><filename>/var/lib/systemd/tpm2-srk-public-key.tpm2_public</filename></term>
+
+        <listitem><para>The SRK public key in PEM and TPM2B_PUBLIC format, written during later boot (once
+        <filename>/var/</filename> is available).</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+</refentry>
diff --git a/man/systemd-tty-ask-password-agent.xml b/man/systemd-tty-ask-password-agent.xml
new file mode 100644
index 0000000..864dff3
--- /dev/null
+++ b/man/systemd-tty-ask-password-agent.xml
@@ -0,0 +1,138 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd-tty-ask-password-agent"
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd-tty-ask-password-agent</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-tty-ask-password-agent</refentrytitle>
+    <manvolnum>1</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-tty-ask-password-agent</refname>
+    <refpurpose>List or process pending systemd password requests</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <cmdsynopsis>
+      <command>systemd-tty-ask-password-agent</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="opt" rep="repeat">VARIABLE=VALUE</arg>
+    </cmdsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>systemd-tty-ask-password-agent</command> is a
+    password agent that handles password requests of the system, for
+    example for hard disk encryption passwords or SSL certificate
+    passwords that need to be queried at boot-time or during
+    runtime.</para>
+
+    <para><command>systemd-tty-ask-password-agent</command> implements
+    the <ulink url="https://systemd.io/PASSWORD_AGENTS/">Password Agents
+    Specification</ulink>, and is one of many possible response agents which
+    answer to queries formulated with
+    <citerefentry><refentrytitle>systemd-ask-password</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
+    </para>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>The following options are understood:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><option>--list</option></term>
+
+        <listitem><para>Lists all currently pending system password requests.</para>
+
+        <xi:include href="version-info.xml" xpointer="v186"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--query</option></term>
+
+        <listitem><para>Process all currently pending system password
+        requests by querying the user on the calling
+        TTY.</para>
+
+        <xi:include href="version-info.xml" xpointer="v186"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--watch</option></term>
+
+        <listitem><para>Continuously process password
+        requests.</para>
+
+        <xi:include href="version-info.xml" xpointer="v186"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--wall</option></term>
+
+        <listitem><para>Forward password requests to
+        <citerefentry project='man-pages'><refentrytitle>wall</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+        instead of querying the user on the calling
+        TTY.</para>
+
+        <xi:include href="version-info.xml" xpointer="v186"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--plymouth</option></term>
+
+        <listitem><para>Ask question with
+        <citerefentry project='die-net'><refentrytitle>plymouth</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        instead of querying the user on the calling
+        TTY.</para>
+
+        <xi:include href="version-info.xml" xpointer="v186"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--console</option><optional>=<replaceable>DEVICE</replaceable></optional></term>
+
+        <listitem><para>Ask question on TTY <replaceable>DEVICE</replaceable> instead of querying the user on
+        the calling TTY. If <replaceable>DEVICE</replaceable> is not specified,
+        <filename>/dev/console</filename> will be used.</para>
+
+        <xi:include href="version-info.xml" xpointer="v186"/></listitem>
+      </varlistentry>
+
+      <xi:include href="standard-options.xml" xpointer="help" />
+      <xi:include href="standard-options.xml" xpointer="version" />
+    </variablelist>
+
+  </refsect1>
+
+  <refsect1>
+    <title>Exit status</title>
+
+    <para>On success, 0 is returned, a non-zero failure
+    code otherwise.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-ask-password-console.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>wall</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry project='die-net'><refentrytitle>plymouth</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-udev-settle.service.xml b/man/systemd-udev-settle.service.xml
new file mode 100644
index 0000000..2852f31
--- /dev/null
+++ b/man/systemd-udev-settle.service.xml
@@ -0,0 +1,51 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd-udev-settle.service"
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd-udev-settle.service</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-udev-settle.service</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-udev-settle.service</refname>
+    <refpurpose>Wait for all pending udev events to be handled</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>systemd-udev-settle.service</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1><title>Description</title>
+  <para>This service calls <command>udevadm settle</command> to wait until all events that have been queued
+  by <citerefentry><refentrytitle>udev</refentrytitle><manvolnum>7</manvolnum></citerefentry> have been
+  processed. It is a crude way to wait until "all" hardware has been discovered. Services may pull in this
+  service and order themselves after it to wait for the udev queue to be empty.</para>
+
+  <para><emphasis>Using this service is not recommended.</emphasis> There can be no guarantee that hardware
+  is fully discovered at any specific time, because the kernel does hardware detection asynchronously, and
+  certain buses and devices take a very long time to become ready, and also additional hardware may be
+  plugged in at any time. Instead, services should subscribe to udev events and react to any new hardware as
+  it is discovered. Services that, based on configuration, expect certain devices to appear, may warn or
+  report failure after a timeout. This timeout should be tailored to the hardware type. Waiting for
+  <filename>systemd-udev-settle.service</filename> usually slows boot significantly, because it means waiting
+  for all unrelated events too.</para>
+ </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>udev</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>udevadm</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+</refentry>
diff --git a/man/systemd-udevd.service.xml b/man/systemd-udevd.service.xml
new file mode 100644
index 0000000..27d0e02
--- /dev/null
+++ b/man/systemd-udevd.service.xml
@@ -0,0 +1,311 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd-udevd.service"
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd-udevd.service</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-udevd.service</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-udevd.service</refname>
+    <refname>systemd-udevd-control.socket</refname>
+    <refname>systemd-udevd-kernel.socket</refname>
+    <refname>systemd-udevd</refname>
+    <refpurpose>Device event managing daemon</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>systemd-udevd.service</filename></para>
+    <para><filename>systemd-udevd-control.socket</filename></para>
+    <para><filename>systemd-udevd-kernel.socket</filename></para>
+
+    <cmdsynopsis>
+      <command>/usr/lib/systemd/systemd-udevd</command>
+      <arg><option>--daemon</option></arg>
+      <arg><option>--debug</option></arg>
+      <arg><option>--children-max=</option></arg>
+      <arg><option>--exec-delay=</option></arg>
+      <arg><option>--event-timeout=</option></arg>
+      <arg><option>--resolve-names=early|late|never</option></arg>
+      <arg><option>--version</option></arg>
+      <arg><option>--help</option></arg>
+    </cmdsynopsis>
+
+  </refsynopsisdiv>
+
+  <refsect1><title>Description</title>
+    <para><command>systemd-udevd</command> listens to kernel uevents.
+    For every event, systemd-udevd executes matching instructions
+    specified in udev rules. See <citerefentry>
+    <refentrytitle>udev</refentrytitle><manvolnum>7</manvolnum>
+    </citerefentry>.</para>
+
+    <para>The behavior of the daemon can be configured using
+    <citerefentry><refentrytitle>udev.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    its command line options, environment variables, and on the kernel
+    command line, or changed dynamically with <command>udevadm
+    control</command>.
+    </para>
+  </refsect1>
+
+  <refsect1><title>Options</title>
+    <variablelist>
+      <varlistentry>
+        <term><option>-d</option></term>
+        <term><option>--daemon</option></term>
+        <listitem>
+          <para>Detach and run in the background.</para>
+
+        <xi:include href="version-info.xml" xpointer="v186"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-D</option></term>
+        <term><option>--debug</option></term>
+        <listitem>
+          <para>Print debug messages to standard error.</para>
+
+        <xi:include href="version-info.xml" xpointer="v186"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-c</option></term>
+        <term><option>--children-max=</option></term>
+        <listitem>
+          <para>Limit the number of events executed in parallel.</para>
+
+        <xi:include href="version-info.xml" xpointer="v186"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-e</option></term>
+        <term><option>--exec-delay=</option></term>
+        <listitem>
+          <para>Delay the execution of each <varname>RUN{<replaceable>program</replaceable>}</varname>
+          parameter by the given number of seconds. This option
+          might be useful when debugging system crashes during
+          coldplug caused by loading non-working kernel
+          modules.</para>
+
+        <xi:include href="version-info.xml" xpointer="v186"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-t</option></term>
+        <term><option>--event-timeout=</option></term>
+        <listitem>
+          <para>Set the number of seconds to wait for events to finish. After
+          this time, the event will be terminated. The default is 180 seconds.</para>
+
+          <xi:include href="version-info.xml" xpointer="v216"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-s</option></term>
+        <term><option>--timeout-signal=</option></term>
+        <listitem>
+          <para>Set the signal which <filename>systemd-udevd</filename> will send to
+          forked off processes after reaching event timeout. The setting can be overridden
+          at boot time with the kernel command line option
+          <varname>udev.timeout_signal=</varname>. Setting to <constant>SIGABRT</constant>
+          may be helpful in order to debug worker timeouts. Defaults to
+          <constant>SIGKILL</constant>. Note that setting the option on the command line
+          overrides the setting from the configuration file.
+          </para>
+
+        <xi:include href="version-info.xml" xpointer="v246"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-N</option></term>
+        <term><option>--resolve-names=</option></term>
+        <listitem>
+          <para>Specify when systemd-udevd should resolve names of users and groups.
+          When set to <option>early</option> (the default), names will be
+          resolved when the rules are parsed.  When set to
+          <option>late</option>, names will be resolved for every event.
+          When set to <option>never</option>, names will never be resolved
+          and all devices will be owned by root.</para>
+
+          <xi:include href="version-info.xml" xpointer="v186"/>
+        </listitem>
+      </varlistentry>
+
+      <xi:include href="standard-options.xml" xpointer="help" />
+      <xi:include href="standard-options.xml" xpointer="version" />
+    </variablelist>
+  </refsect1>
+
+  <refsect1><title>Kernel command line</title>
+    <variablelist class='kernel-commandline-options'>
+      <para>Parameters prefixed with "rd." will be read when <command>systemd-udevd</command> is used in an
+      initrd, those without will be processed both in the initrd and on the host.</para>
+      <varlistentry>
+        <term><varname>udev.log_level=</varname></term>
+        <term><varname>rd.udev.log_level=</varname></term>
+        <listitem>
+          <para>Set the log level.</para>
+
+        <xi:include href="version-info.xml" xpointer="v247"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>udev.children_max=</varname></term>
+        <term><varname>rd.udev.children_max=</varname></term>
+        <listitem>
+          <para>Limit the number of events executed in parallel.</para>
+
+        <xi:include href="version-info.xml" xpointer="v186"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>udev.exec_delay=</varname></term>
+        <term><varname>rd.udev.exec_delay=</varname></term>
+        <listitem>
+          <para>Delay the execution of each <varname>RUN{<replaceable>program</replaceable>}</varname> parameter by the given
+          number of seconds. This option might be useful when
+          debugging system crashes during coldplug caused by loading
+          non-working kernel modules.</para>
+
+        <xi:include href="version-info.xml" xpointer="v186"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>udev.event_timeout=</varname></term>
+        <term><varname>rd.udev.event_timeout=</varname></term>
+        <listitem>
+          <para>Wait for events to finish up to the given number
+          of seconds. This option might be useful if events are
+          terminated due to kernel drivers taking too long to initialize.</para>
+
+          <xi:include href="version-info.xml" xpointer="v216"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>udev.timeout_signal=</varname></term>
+        <term><varname>rd.udev.timeout_signal=</varname></term>
+        <listitem>
+          <para>Specifies a signal that <filename>systemd-udevd</filename> will send to
+          workers on timeout. Note that kernel command line option overrides both the
+          setting in the configuration file and the one on the program command line.</para>
+
+        <xi:include href="version-info.xml" xpointer="v246"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>udev.blockdev_read_only</varname></term>
+        <term><varname>rd.udev.blockdev_read_only</varname></term>
+        <listitem>
+          <para>If specified, mark all physical block devices read-only as they appear. Synthetic block
+          devices (such as loopback block devices or device mapper devices) are left as they are. This is
+          useful to guarantee that the contents of physical block devices remains unmodified during runtime,
+          for example to implement fully stateless systems, for testing or for recovery situations where
+          corrupted file systems shall not be corrupted further through accidental modification.</para>
+
+          <para>A block device may be marked writable again by issuing the <command>blockdev
+          --setrw</command> command, see <citerefentry
+          project='man-pages'><refentrytitle>blockdev</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+          for details.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>net.ifnames=</varname></term>
+        <listitem>
+          <para>Network interfaces are renamed to give them predictable names
+          when possible. It is enabled by default; specifying 0 disables it.</para>
+
+          <xi:include href="version-info.xml" xpointer="v199"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>net.naming-scheme=</varname></term>
+        <listitem>
+          <para>Network interfaces are renamed to give them predictable names when possible (unless
+          <varname>net.ifnames=0</varname> is specified, see above). With this kernel command line option it
+          is possible to pick a specific version of this algorithm and override the default chosen at
+          compilation time. Expects one of the naming scheme identifiers listed in
+          <citerefentry><refentrytitle>systemd.net-naming-scheme</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+          or <literal>latest</literal> to select the latest scheme known (to this particular version of
+          <filename>systemd-udevd.service</filename>).</para>
+
+          <para>Note that selecting a specific scheme is not sufficient to fully stabilize interface naming:
+          the naming is generally derived from driver attributes exposed by the kernel. As the kernel is
+          updated, previously missing attributes <filename>systemd-udevd.service</filename> is checking might
+          appear, which affects older name derivation algorithms, too.</para>
+
+          <xi:include href="version-info.xml" xpointer="v240"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>net.ifname-policy=<replaceable>policy1</replaceable>[,<replaceable>policy2</replaceable>,…][,<replaceable>MAC</replaceable>]</varname></term>
+        <listitem>
+          <para>Specifies naming policies applied when renaming network interfaces. Takes a list of
+          policies and an optional MAC address separated with comma. Each policy value must be one of
+          the policies understood by the <varname>NamePolicy=</varname> setting in .link files, e.g.
+          <literal>onboard</literal> or <literal>path</literal>. See
+          <citerefentry><refentrytitle>systemd.link</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+          for more details. When the MAC address is specified, the policies are applied to the
+          interface which has the address. When no MAC address is specified, the policies are applied
+          to all interfaces. This kernel command line argument can be specified multiple times.</para>
+
+          <para>This argument is not directly read by <command>systemd-udevd</command>, but is instead
+          converted to a .link file by
+          <citerefentry><refentrytitle>systemd-network-generator.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+          For this argument to take effect, <filename>systemd-network-generator.service</filename> must be
+          enabled.</para>
+
+          <para>Example:
+          <programlisting>net.ifname-policy=keep,kernel,path,slot,onboard,01:23:45:67:89:ab
+net.ifname-policy=keep,kernel,path,slot,onboard,mac</programlisting>
+          This is mostly equivalent to creating the following .link files:
+          <programlisting># 91-name-policy-with-mac.link
+[Match]
+MACAddress=01:23:45:67:89:ab
+
+[Link]
+NamePolicy=keep kernel path slot onboard
+AlternativeNamePolicy=path slot onboard</programlisting>
+          and
+          <programlisting># 92-name-policy-for-all.link
+[Match]
+OriginalName=*
+
+[Link]
+NamePolicy=keep kernel path slot onboard mac
+AlternativeNamePolicy=path slot onboard mac</programlisting>
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v250"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+    <!-- when adding entries here, consider also adding them in kernel-command-line.xml -->
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>udev.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>udev</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>udevadm</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+</refentry>
diff --git a/man/systemd-update-done.service.xml b/man/systemd-update-done.service.xml
new file mode 100644
index 0000000..3393010
--- /dev/null
+++ b/man/systemd-update-done.service.xml
@@ -0,0 +1,76 @@
+<?xml version="1.0"?>
+<!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+<refentry id="systemd-update-done.service">
+
+  <refentryinfo>
+    <title>systemd-update-done.service</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-update-done.service</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-update-done.service</refname>
+    <refname>systemd-update-done</refname>
+    <refpurpose>Mark <filename>/etc/</filename> and <filename>/var/</filename> fully updated</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>systemd-update-done.service</filename></para>
+    <para><filename>/usr/lib/systemd/systemd-update-done</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><filename>systemd-update-done.service</filename> is a
+    service that is invoked as part of the first boot after the vendor
+    operating system resources in <filename>/usr/</filename> have been
+    updated. This is useful to implement offline updates of
+    <filename>/usr/</filename> which might require updates to
+    <filename>/etc/</filename> or <filename>/var/</filename> on the
+    following boot.</para>
+
+    <para><filename>systemd-update-done.service</filename> updates the
+    file modification time (mtime) of the stamp files
+    <filename>/etc/.updated</filename> and
+    <filename>/var/.updated</filename> to the modification time of the
+    <filename>/usr/</filename> directory, unless the stamp files are
+    already newer.</para>
+
+    <para>Services that shall run after offline upgrades of
+    <filename>/usr/</filename> should order themselves before
+    <filename>systemd-update-done.service</filename>, and use the
+    <varname>ConditionNeedsUpdate=</varname> (see
+    <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>)
+    condition to make sure to run when <filename>/etc/</filename> or
+    <filename>/var/</filename> are older than <filename>/usr/</filename>
+    according to the modification times of the files described above.
+    This requires that updates to <filename>/usr/</filename> are always
+    followed by an update of the modification time of
+    <filename>/usr/</filename>, for example by invoking
+    <citerefentry project='man-pages'><refentrytitle>touch</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    on it.</para>
+
+    <para>Note that if the <varname>systemd.condition-needs-update=</varname> kernel command line option is
+    used it overrides the <varname>ConditionNeedsUpdate=</varname> unit condition checks. In that case
+    <filename>systemd-update-done.service</filename> will not reset the condition state until a follow-up
+    reboot where the kernel switch is not specified anymore.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>touch</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-update-utmp.service.xml b/man/systemd-update-utmp.service.xml
new file mode 100644
index 0000000..ff01893
--- /dev/null
+++ b/man/systemd-update-utmp.service.xml
@@ -0,0 +1,51 @@
+<?xml version="1.0"?>
+<!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+<refentry id="systemd-update-utmp.service" conditional="ENABLE_UTMP">
+
+  <refentryinfo>
+    <title>systemd-update-utmp.service</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-update-utmp.service</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-update-utmp.service</refname>
+    <refname>systemd-update-utmp-runlevel.service</refname>
+    <refname>systemd-update-utmp</refname>
+    <refpurpose>Write audit and utmp updates at bootup, runlevel
+    changes and shutdown</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>systemd-update-utmp.service</filename></para>
+    <para><filename>systemd-update-utmp-runlevel.service</filename></para>
+    <para><filename>/usr/lib/systemd/systemd-update-utmp</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><filename>systemd-update-utmp-runlevel.service</filename> is
+    a service that writes SysV runlevel changes to utmp and wtmp, as
+    well as the audit logs, as they occur.
+    <filename>systemd-update-utmp.service</filename> does the same for
+    system reboots and shutdown requests.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>utmp</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>auditd</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-user-sessions.service.xml b/man/systemd-user-sessions.service.xml
new file mode 100644
index 0000000..f05e4e3
--- /dev/null
+++ b/man/systemd-user-sessions.service.xml
@@ -0,0 +1,50 @@
+<?xml version="1.0"?>
+<!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+<refentry id="systemd-user-sessions.service" conditional='HAVE_PAM'>
+
+  <refentryinfo>
+    <title>systemd-user-sessions.service</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-user-sessions.service</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-user-sessions.service</refname>
+    <refname>systemd-user-sessions</refname>
+    <refpurpose>Permit user logins after boot, prohibit user logins at shutdown</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>systemd-user-sessions.service</filename></para>
+    <para><filename>/usr/lib/systemd/systemd-user-sessions</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><filename>systemd-user-sessions.service</filename> is a
+    service that controls user logins through
+    <citerefentry project='man-pages'><refentrytitle>pam_nologin</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+    After basic system initialization is complete, it removes
+    <filename>/run/nologin</filename>, thus permitting logins. Before
+    system shutdown, it creates <filename>/run/nologin</filename>, thus
+    prohibiting further logins.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-logind.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>pam_nologin</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-userdbd.service.xml b/man/systemd-userdbd.service.xml
new file mode 100644
index 0000000..71a5dff
--- /dev/null
+++ b/man/systemd-userdbd.service.xml
@@ -0,0 +1,74 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd-userdbd.service" conditional='ENABLE_USERDB'>
+
+  <refentryinfo>
+    <title>systemd-userdbd.service</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-userdbd.service</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-userdbd.service</refname>
+    <refname>systemd-userdbd</refname>
+    <refpurpose>JSON User/Group Record Query Multiplexer/NSS Compatibility</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>systemd-userdbd.service</filename></para>
+    <para><filename>/usr/lib/systemd/systemd-userdbd</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>systemd-userdbd</command> is a system service that multiplexes user/group lookups to all
+    local services that provide JSON user/group record definitions to the system. In addition it synthesizes
+    JSON user/group records from classic UNIX/glibc NSS user/group records in order to provide full backwards
+    compatibility. It may also pick up statically defined JSON user/group records from files in
+    <filename>/etc/userdb/</filename>, <filename>/run/userdb/</filename>,
+    <filename>/run/host/userdb/</filename> and <filename>/usr/lib/userdb/</filename> with the
+    <literal>.user</literal> extension.</para>
+
+    <para>Most of <command>systemd-userdbd</command>'s functionality is accessible through the
+    <citerefentry><refentrytitle>userdbctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    command.</para>
+
+    <para>The user and group records this service provides access to follow the <ulink
+    url="https://systemd.io/USER_RECORD">JSON User Records</ulink> and <ulink
+    url="https://systemd.io/GROUP_RECORD">JSON Group Record</ulink> definitions. This service implements the
+    <ulink url="https://systemd.io/USER_GROUP_API">User/Group Record Lookup API via Varlink</ulink>, and
+    multiplexes access other services implementing this API, too. It is thus both server and client of this
+    API.</para>
+
+    <para>This service provides three distinct <ulink url="https://varlink.org/">Varlink</ulink> services:
+    <constant>io.systemd.Multiplexer</constant> provides a single, unified API for querying JSON user and
+    group records. Internally it talks to all other user/group record services running on the system in
+    parallel and forwards any information discovered. This simplifies clients substantially since they need
+    to talk to a single service only instead of all of them in
+    parallel. <constant>io.systemd.NameServiceSwitch</constant> provides compatibility with classic
+    UNIX/glibc NSS user records, i.e. converts <type>struct passwd</type> and <type>struct group</type>
+    records as acquired with APIs such as <citerefentry
+    project='man-pages'><refentrytitle>getpwnam</refentrytitle><manvolnum>1</manvolnum></citerefentry> to
+    JSON user/group records, thus hiding the differences between the services as much as
+    possible. <constant>io.systemd.DropIn</constant> makes JSON user/group records from the aforementioned
+    drop-in directories available.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>nss-systemd</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>userdbctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-homed.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+</refentry>
diff --git a/man/systemd-vconsole-setup.service.xml b/man/systemd-vconsole-setup.service.xml
new file mode 100644
index 0000000..0962dc9
--- /dev/null
+++ b/man/systemd-vconsole-setup.service.xml
@@ -0,0 +1,109 @@
+<?xml version="1.0"?>
+<!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+<refentry id="systemd-vconsole-setup.service" conditional='ENABLE_VCONSOLE'
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd-vconsole-setup.service</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-vconsole-setup.service</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-vconsole-setup.service</refname>
+    <refname>systemd-vconsole-setup</refname>
+    <refpurpose>Configure the virtual consoles</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>systemd-vconsole-setup.service</filename></para>
+    <cmdsynopsis>
+      <command>/usr/lib/systemd/systemd-vconsole-setup</command>
+      <arg choice="opt">TTY</arg>
+    </cmdsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>systemd-vconsole-setup</command> sets up and configures either all virtual consoles, or
+    — if the optional <replaceable>TTY</replaceable> parameter is provided — a specific one. When the system
+    is booting up, <filename>systemd-vconsole-setup.service</filename> is called by
+    <citerefentry><refentrytitle>systemd-udevd</refentrytitle><manvolnum>8</manvolnum></citerefentry> during
+    VT console subsystem initialization. Also,
+    <citerefentry><refentrytitle>systemd-localed.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    invokes it as needed when language or console changes are made.
+    Internally, this program calls
+    <citerefentry project='mankier'><refentrytitle>loadkeys</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    and
+    <citerefentry project='die-net'><refentrytitle>setfont</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+    </para>
+
+    <para>Execute <command>systemctl restart systemd-vconsole-setup.service</command> in order to apply any manual
+    changes made to <filename>/etc/vconsole.conf</filename>.</para>
+
+    <para>See <citerefentry><refentrytitle>vconsole.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
+    information about the configuration files and kernel command line options understood by this program.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Credentials</title>
+
+    <para><command>systemd-vconsole-setup</command> supports the service credentials logic as implemented by
+    <varname>ImportCredential=</varname>/<varname>LoadCredential=</varname>/<varname>SetCredential=</varname>
+    (see <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
+    details). The following credentials are used when passed in:</para>
+
+    <variablelist class='system-credentials'>
+      <varlistentry>
+        <term><varname>vconsole.keymap</varname></term>
+        <term><varname>vconsole.keymap_toggle</varname></term>
+
+        <listitem><para>The keymap (and toggle keymap) to apply. The matching options in
+        <filename>vconsole.conf</filename> and on the kernel command line take precedence over these
+        credentials.</para>
+
+        <para>Note the relationship to the <varname>firstboot.keymap</varname> credential understood by
+        <citerefentry><refentrytitle>systemd-firstboot.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>:
+        both ultimately affect the same setting, but <varname>firstboot.keymap</varname> is written into
+        <filename>/etc/vconsole.conf</filename> on first boot (if not already configured), and then read from
+        there by <command>systemd-vconsole-setup</command>, while <varname>vconsole.keymap</varname> is read
+        on every boot, and is not persisted to disk (but any configuration in
+        <filename>vconsole.conf</filename> will take precedence if present).</para>
+
+        <xi:include href="version-info.xml" xpointer="v253"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>vconsole.font</varname></term>
+        <term><varname>vconsole.font_map</varname></term>
+        <term><varname>vconsole.font_unimap</varname></term>
+
+        <listitem><para>The console font settings to apply. The matching options in
+        <filename>vconsole.conf</filename> and on the kernel command line take precedence over these
+        credentials.</para>
+
+        <xi:include href="version-info.xml" xpointer="v253"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>vconsole.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry project='mankier'><refentrytitle>loadkeys</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry project='die-net'><refentrytitle>setfont</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-localed.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-veritysetup-generator.xml b/man/systemd-veritysetup-generator.xml
new file mode 100644
index 0000000..b1efed5
--- /dev/null
+++ b/man/systemd-veritysetup-generator.xml
@@ -0,0 +1,137 @@
+<?xml version="1.0"?>
+<!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+<refentry id="systemd-veritysetup-generator" conditional='HAVE_LIBCRYPTSETUP'
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd-veritysetup-generator</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-veritysetup-generator</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-veritysetup-generator</refname>
+    <refpurpose>Unit generator for verity protected block devices</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>/usr/lib/systemd/system-generators/systemd-veritysetup-generator</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>systemd-veritysetup-generator</command> is a generator that translates kernel command line
+    options configuring verity protected block devices into native systemd units early at boot and when
+    configuration of the system manager is reloaded. This will create
+    <citerefentry><refentrytitle>systemd-veritysetup@.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    units as necessary.</para>
+
+    <para>Currently, only two verity devices may be set up with this generator, backing the root and <filename>/usr</filename> file systems of the
+    OS.</para>
+
+    <para><command>systemd-veritysetup-generator</command> implements
+    <citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Kernel Command Line</title>
+
+    <para><command>systemd-veritysetup-generator</command>
+    understands the following kernel command line parameters:</para>
+
+    <variablelist class='kernel-commandline-options'>
+      <varlistentry>
+        <term><varname>systemd.verity=</varname></term>
+        <term><varname>rd.systemd.verity=</varname></term>
+
+        <listitem><para>Takes a boolean argument. Defaults to <literal>yes</literal>. If
+        <literal>no</literal>, disables the generator entirely. <varname>rd.systemd.verity=</varname> is
+        honored only by the initrd while <varname>systemd.verity=</varname> is honored by both the host
+        system and the initrd.</para>
+
+        <xi:include href="version-info.xml" xpointer="v233"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>roothash=</varname></term>
+
+        <listitem><para>Takes a root hash value for the root file system. Expects a hash value formatted in hexadecimal
+        characters of the appropriate length (i.e. most likely 256 bit/64 characters, or longer). If not specified via
+        <varname>systemd.verity_root_data=</varname> and <varname>systemd.verity_root_hash=</varname>, the hash and
+        data devices to use are automatically derived from the specified hash value. Specifically, the data partition
+        device is looked for under a GPT partition UUID derived from the first 128-bit of the root hash, the hash
+        partition device is looked for under a GPT partition UUID derived from the last 128-bit of the root hash. Hence
+        it is usually sufficient to specify the root hash to boot from a verity protected root file system, as
+        device paths are automatically determined from it — as long as the partition table is properly set up.</para>
+
+        <xi:include href="version-info.xml" xpointer="v233"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>systemd.verity_root_data=</varname></term>
+        <term><varname>systemd.verity_root_hash=</varname></term>
+
+        <listitem><para>These two settings take block device paths as arguments and may be used to explicitly
+        configure the data partition and hash partition to use for setting up the verity protection for the root file
+        system. If not specified, these paths are automatically derived from the <varname>roothash=</varname> argument
+        (see above).</para>
+
+        <xi:include href="version-info.xml" xpointer="v233"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>systemd.verity_root_options=</varname></term>
+
+        <listitem><para>Takes a comma-separated list of dm-verity options. Expects the following options
+        <option>superblock=<replaceable>BOOLEAN</replaceable></option>,
+        <option>format=<replaceable>NUMBER</replaceable></option>,
+        <option>data-block-size=<replaceable>BYTES</replaceable></option>,
+        <option>hash-block-size=<replaceable>BYTES</replaceable></option>,
+        <option>data-blocks=<replaceable>BLOCKS</replaceable></option>,
+        <option>hash-offset=<replaceable>BYTES</replaceable></option>,
+        <option>salt=<replaceable>HEX</replaceable></option>, <option>uuid=<replaceable>UUID</replaceable></option>,
+        <option>ignore-corruption</option>, <option>restart-on-corruption</option>, <option>ignore-zero-blocks</option>,
+        <option>check-at-most-once</option>, <option>panic-on-corruption</option>,
+        <option>hash=<replaceable>HASH</replaceable></option>, <option>fec-device=<replaceable>PATH</replaceable></option>,
+        <option>fec-offset=<replaceable>BYTES</replaceable></option>, <option>fec-roots=<replaceable>NUM</replaceable></option> and
+        <option>root-hash-signature=<replaceable>PATH</replaceable>|base64:<replaceable>HEX</replaceable></option>. See
+        <citerefentry project='die-net'><refentrytitle>veritysetup</refentrytitle><manvolnum>8</manvolnum></citerefentry> for more
+        details.</para>
+
+        <xi:include href="version-info.xml" xpointer="v248"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>usrhash=</varname></term>
+        <term><varname>systemd.verity_usr_data=</varname></term>
+        <term><varname>systemd.verity_usr_hash=</varname></term>
+        <term><varname>systemd.verity_usr_options=</varname></term>
+
+        <listitem><para>Equivalent to their counterparts for the root file system as described above, but
+        apply to the <filename>/usr/</filename> file system instead.</para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-veritysetup@.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry project='die-net'><refentrytitle>veritysetup</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-veritysetup@.service.xml b/man/systemd-veritysetup@.service.xml
new file mode 100644
index 0000000..d6131a8
--- /dev/null
+++ b/man/systemd-veritysetup@.service.xml
@@ -0,0 +1,104 @@
+<?xml version="1.0"?>
+<!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+<refentry id="systemd-veritysetup@.service" conditional='HAVE_LIBCRYPTSETUP'
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd-veritysetup@.service</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-veritysetup@.service</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-veritysetup@.service</refname>
+    <refname>systemd-veritysetup</refname>
+    <refpurpose>Disk verity protection logic</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>systemd-veritysetup@.service</filename></para>
+    <para><filename>/usr/lib/systemd/systemd-veritysetup</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><filename>systemd-veritysetup@.service</filename> is a service responsible for setting up verity
+    protection block devices. It should be instantiated for each device that requires verity
+    protection.</para>
+
+    <para>At early boot and when the system manager configuration is reloaded kernel command line configuration for
+    verity protected block devices is translated into <filename>systemd-veritysetup@.service</filename> units by
+    <citerefentry><refentrytitle>systemd-veritysetup-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
+
+    <para><filename>systemd-veritysetup@.service</filename> calls <command>systemd-veritysetup</command>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Commands</title>
+
+    <para>The following commands are understood by <command>systemd-veritysetup</command>:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term>
+          <option>attach</option>
+          <replaceable>volume</replaceable>
+          <replaceable>datadevice</replaceable>
+          <replaceable>hashdevice</replaceable>
+          <replaceable>roothash</replaceable>
+          [<replaceable>option</replaceable>...]
+        </term>
+
+        <listitem><para>Create a block device <replaceable>volume</replaceable> using
+        <replaceable>datadevice</replaceable> and <replaceable>hashdevice</replaceable> as the backing
+        devices. <replaceable>roothash</replaceable> forms the root of the tree of hashes stored on
+        <replaceable>hashdevice</replaceable>. See
+        <ulink url="https://docs.kernel.org/admin-guide/device-mapper/verity.html">
+          Kernel dm-verity</ulink> documentation for details.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term>
+          <option>detach</option>
+          <replaceable>volume</replaceable>
+        </term>
+
+        <listitem><para>Detach (destroy) the block device
+        <replaceable>volume</replaceable>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term>
+          <option>help</option>
+        </term>
+
+        <listitem><para>Print short information about command syntax.</para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-veritysetup-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry project='die-net'><refentrytitle>veritysetup</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+     </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-vmspawn.xml b/man/systemd-vmspawn.xml
new file mode 100644
index 0000000..fa55f8e
--- /dev/null
+++ b/man/systemd-vmspawn.xml
@@ -0,0 +1,221 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd-vmspawn" conditional="ENABLE_VMSPAWN"
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd-vmspawn</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-vmspawn</refentrytitle>
+    <manvolnum>1</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-vmspawn</refname>
+    <refpurpose>Spawn an OS in a virtual machine.</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <cmdsynopsis>
+      <command>systemd-vmspawn</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="opt" rep="repeat">ARGS</arg>
+    </cmdsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+    <para><command>systemd-vmspawn</command> may be used to start a virtual machine from an OS image. In many ways it is similar to <citerefentry
+    project='man-pages'><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>, but it
+    launches a full virtual machine instead of using namespaces.</para>
+
+    <para>Note: on Ubuntu/Debian derivatives systemd-vmspawn requires the user to be in the <literal>kvm</literal> group to use the VSock options.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>The excess arguments are passed as extra kernel command line arguments using SMBIOS.</para>
+
+    <para>The following options are understood:</para>
+
+    <refsect2>
+      <title>Image Options</title>
+
+      <variablelist>
+        <varlistentry>
+          <term><option>-i</option></term>
+          <term><option>--image=</option></term>
+
+          <listitem><para>Root file system disk image (or device node) for the virtual machine.</para>
+
+          <xi:include href="version-info.xml" xpointer="v255"/>
+          </listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+
+    <refsect2>
+      <title>Host Configuration</title>
+
+      <variablelist>
+        <varlistentry>
+          <term><option>--qemu-smp=</option><replaceable>SMP</replaceable></term>
+
+          <listitem><para>Configures the number of CPUs to start the virtual machine with.
+          Defaults to 1.</para>
+
+          <xi:include href="version-info.xml" xpointer="v255"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><option>--qemu-mem=</option><replaceable>MEM</replaceable></term>
+
+          <listitem><para>Configures the amount of memory to start the virtual machine with.
+          Defaults to 2G.</para>
+
+          <xi:include href="version-info.xml" xpointer="v255"/>
+          </listitem>
+        </varlistentry>
+
+      <varlistentry>
+        <term><option>--qemu-kvm=</option><replaceable>BOOL</replaceable></term>
+
+        <listitem><para>Configures whether to use KVM. If the option is not specified KVM support will be
+        detected automatically. If true, KVM is always used, and if false, KVM is never used.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--qemu-vsock=</option><replaceable>BOOL</replaceable></term>
+
+        <listitem>
+          <para>Configure whether to use VSock networking.</para>
+          <para>If the option is not specified VSock support will be detected automatically.
+          If yes is specified VSocks are always used, and vice versa if no is set VSocks are never used.</para>
+          <xi:include href="version-info.xml" xpointer="v255"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--vsock-cid=</option><replaceable>CID</replaceable></term>
+
+        <listitem>
+          <para>Configure vmspawn to use a specific CID for the guest.</para>
+          <para>If the option is not specified or an empty argument is supplied the guest will be assigned a random CID.</para>
+          <para>Valid CIDs are in the range <constant>3</constant> to <constant>4294967294</constant> (<constant>0xFFFF_FFFE</constant>).
+          CIDs outside of this range are reserved.</para>
+          <xi:include href="version-info.xml" xpointer="v255"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--qemu-gui</option></term>
+
+        <listitem><para>Start QEMU in graphical mode.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--secure-boot=</option><replaceable>BOOL</replaceable></term>
+
+        <listitem><para>Configure whether to search for firmware which supports Secure Boot.</para>
+        <para>If the option is not specified the first firmware which is detected will be used.
+        If the option is set to yes then the first firmware with Secure Boot support will be selected.
+        If no is specified then the first firmware without Secure Boot will be selected.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+    </variablelist>
+
+    </refsect2><refsect2>
+      <title>System Identity Options</title>
+
+      <variablelist>
+        <varlistentry>
+          <term><option>-M</option></term>
+          <term><option>--machine=</option></term>
+
+          <listitem><para>Sets the machine name for this container. This
+          name may be used to identify this container during its runtime
+          (for example in tools like
+          <citerefentry><refentrytitle>machinectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+          and similar).</para>
+          <xi:include href="version-info.xml" xpointer="v255"/>
+          </listitem>
+        </varlistentry>
+      </variablelist>
+
+    </refsect2><refsect2>
+      <title>Credentials</title>
+
+      <variablelist>
+        <varlistentry>
+          <term><option>--load-credential=</option><replaceable>ID</replaceable>:<replaceable>PATH</replaceable></term>
+          <term><option>--set-credential=</option><replaceable>ID</replaceable>:<replaceable>VALUE</replaceable></term>
+
+          <listitem><para>Pass a credential to the container. These two options correspond to the
+          <varname>LoadCredential=</varname> and <varname>SetCredential=</varname> settings in unit files. See
+          <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
+          details about these concepts, as well as the syntax of the option's arguments.</para>
+
+          <para>In order to embed binary data into the credential data for <option>--set-credential=</option>,
+          use C-style escaping (i.e. <literal>\n</literal> to embed a newline, or <literal>\x00</literal> to
+          embed a <constant>NUL</constant> byte). Note that the invoking shell might already apply unescaping
+          once, hence this might require double escaping!.</para>
+
+          <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+        </varlistentry>
+      </variablelist>
+
+    </refsect2><refsect2>
+      <title>Other</title>
+
+      <variablelist>
+        <xi:include href="standard-options.xml" xpointer="no-pager" />
+        <xi:include href="standard-options.xml" xpointer="help" />
+        <xi:include href="standard-options.xml" xpointer="version" />
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <xi:include href="common-variables.xml" />
+
+  <refsect1>
+    <title>Examples</title>
+
+    <example>
+      <title>Run an Arch Linux VM image generated by mkosi</title>
+
+      <programlisting>
+$ mkosi -d arch -p systemd -p linux --autologin -o image.raw -f build
+$ systemd-vmspawn --image=image.raw
+      </programlisting>
+    </example>
+  </refsect1>
+
+  <refsect1>
+    <title>Exit status</title>
+
+    <para>If an error occurred the value errno is propagated to the return code.
+    If EXIT_STATUS is supplied by the running image that is returned.
+    Otherwise EXIT_SUCCESS is returned.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>mkosi</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+</refentry>
diff --git a/man/systemd-volatile-root.service.xml b/man/systemd-volatile-root.service.xml
new file mode 100644
index 0000000..0d3b402
--- /dev/null
+++ b/man/systemd-volatile-root.service.xml
@@ -0,0 +1,55 @@
+<?xml version="1.0"?>
+<!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+<refentry id="systemd-volatile-root.service">
+
+  <refentryinfo>
+    <title>systemd-volatile-root.service</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-volatile-root.service</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-volatile-root.service</refname>
+    <refname>systemd-volatile-root</refname>
+    <refpurpose>Make the root file system volatile</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>systemd-volatile-root.service</filename></para>
+    <para><filename>/usr/lib/systemd/systemd-volatile-root</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><filename>systemd-volatile-root.service</filename> is a service that replaces the root directory with a
+    volatile memory file system (<literal>tmpfs</literal>), mounting the original (non-volatile)
+    <filename>/usr/</filename> inside it read-only. This way, vendor data from <filename>/usr/</filename> is available as
+    usual, but all configuration data in <filename>/etc/</filename>, all state data in <filename>/var/</filename> and all
+    other resources stored directly under the root directory are reset on boot and lost at shutdown, enabling fully
+    stateless systems.</para>
+
+    <para>This service is only enabled if full volatile mode is selected, for example by specifying
+    <literal>systemd.volatile=yes</literal> on the kernel command line. This service runs only in the initrd,
+    before the system transitions to the host's root directory. Note that this service is not used if
+    <literal>systemd.volatile=state</literal> is used, as in that mode the root directory is non-volatile.
+    </para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>kernel-command-line</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd-xdg-autostart-generator.xml b/man/systemd-xdg-autostart-generator.xml
new file mode 100644
index 0000000..bafe6e9
--- /dev/null
+++ b/man/systemd-xdg-autostart-generator.xml
@@ -0,0 +1,106 @@
+<?xml version="1.0"?>
+<!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+<refentry id="systemd-xdg-autostart-generator" conditional="ENABLE_XDG_AUTOSTART">
+
+  <refentryinfo>
+    <title>systemd-xdg-autostart-generator</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd-xdg-autostart-generator</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd-xdg-autostart-generator</refname>
+    <refpurpose>User unit generator for XDG autostart files</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>/usr/lib/systemd/user-generators/systemd-xdg-autostart-generator</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><filename>systemd-xdg-autostart-generator</filename> is a generator
+    that creates .service units for
+    <ulink url="https://specifications.freedesktop.org/autostart-spec/autostart-spec-latest.html">XDG autostart</ulink>
+    files.
+    This permits desktop environments to delegate startup of these applications to
+    <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    .</para>
+
+    <para>Units created by <filename>systemd-xdg-autostart-generator</filename>
+    can be started by the desktop environment using <literal>xdg-desktop-autostart.target</literal>.
+    See
+    <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+    for more details.</para>
+
+    <para>XDG autostart may be conditionalized using both standardized and non-standardized keys.
+    In order to handle these, the generator may create one or more <varname>ExecCondition=</varname> entries.
+    For non-standardized keys, well-known helper binaries provided by Desktop Environments are used.
+    All external helpers <emphasis>must</emphasis> detect their corresponding desktop environment and
+    <emphasis>must</emphasis> return success when run in a different environment.
+    This is important as all <varname>ExecCondition=</varname> directives must succeed for an application to be started.</para>
+
+    <table>
+      <title>
+        Special XDG desktop file entries that are processed
+      </title>
+      <tgroup cols='2'>
+        <colspec colname='entry' />
+        <colspec colname='handling' />
+        <thead>
+          <row>
+            <entry>Entry</entry>
+            <entry>Handling</entry>
+          </row>
+        </thead>
+        <tbody>
+          <row>
+            <entry><varname>Hidden=</varname>, <varname>X-systemd-skip=</varname></entry>
+            <entry>No service will be generated if set to true</entry>
+          </row>
+          <row>
+            <entry><varname>OnlyShowIn=</varname>, <varname>NotShowIn=</varname></entry>
+            <entry><varname>ExecCondition=</varname> using <filename>systemd-xdg-autostart-condition</filename></entry>
+          </row>
+          <row>
+            <entry><varname>TryExec=</varname></entry>
+            <entry>No service will be generated if the binary does not exist or cannot be executed</entry>
+          </row>
+          <row>
+            <entry><varname>AutostartCondition=</varname> (GNOME extension)</entry>
+            <entry><varname>ExecCondition=</varname> using <filename>gnome-systemd-autostart-condition</filename></entry>
+          </row>
+          <row>
+            <entry><varname>X-GNOME-Autostart-Phase=</varname></entry>
+            <entry>No service will be generated if set to any value</entry>
+          </row>
+          <row>
+            <entry><varname>X-KDE-autostart-condition=</varname></entry>
+            <entry><varname>ExecCondition=</varname> using <filename>kde-systemd-start-condition</filename></entry>
+          </row>
+        </tbody>
+      </tgroup>
+    </table>
+
+    <para><filename>systemd-xdg-autostart-generator</filename> implements
+    <citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd.automount.xml b/man/systemd.automount.xml
new file mode 100644
index 0000000..0bbd4e8
--- /dev/null
+++ b/man/systemd.automount.xml
@@ -0,0 +1,194 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd.automount" xmlns:xi="http://www.w3.org/2001/XInclude">
+  <refentryinfo>
+    <title>systemd.automount</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd.automount</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd.automount</refname>
+    <refpurpose>Automount unit configuration</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename><replaceable>automount</replaceable>.automount</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>A unit configuration file whose name ends in <literal>.automount</literal> encodes information
+    about a file system automount point controlled and supervised by systemd. Automount units may be used to
+    implement on-demand mounting as well as parallelized mounting of file systems.</para>
+
+    <para>This man page lists the configuration options specific to
+    this unit type. See
+    <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for the common options of all unit configuration files. The common
+    configuration items are configured in the generic [Unit] and
+    [Install] sections. The automount specific configuration options
+    are configured in the [Automount] section.</para>
+
+    <para>Automount units must be named after the automount directories they control. Example: the automount
+    point <filename index="false">/home/lennart</filename> must be configured in a unit file
+    <filename>home-lennart.automount</filename>. For details about the escaping logic used to convert a file
+    system path to a unit name see
+    <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>. Note
+    that automount units cannot be templated, nor is it possible to add multiple names to an automount unit
+    by creating symlinks to its unit file.</para>
+
+    <para>For each automount unit file a matching mount unit file (see
+    <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for details) must exist which is activated when the automount path
+    is accessed. Example: if an automount unit
+    <filename>home-lennart.automount</filename> is active and the user
+    accesses <filename>/home/lennart</filename> the mount unit
+    <filename>home-lennart.mount</filename> will be activated.</para>
+
+    <para>Note that automount units are separate from the mount itself, so you
+    should not set <varname>After=</varname> or <varname>Requires=</varname>
+    for mount dependencies here. For example, you should not set
+    <varname>After=network-online.target</varname> or similar on network
+    filesystems. Doing so may result in an ordering cycle.</para>
+
+    <para>Note that automount support on Linux is privileged, automount units are hence only available in the
+    system service manager (and root's user service manager), but not in unprivileged users' service
+    managers.</para>
+
+    <para>Note that automount units should not be nested. (The establishment of the inner automount point
+    would unconditionally pin the outer mount point, defeating its purpose.)</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Automatic Dependencies</title>
+
+    <refsect2>
+      <title>Implicit Dependencies</title>
+
+      <para>The following dependencies are implicitly added:</para>
+
+      <itemizedlist>
+        <listitem><para>If an automount unit is beneath another mount unit in the file system hierarchy, a
+        requirement and ordering dependencies are created to the on the unit higher in the hierarchy.
+        </para></listitem>
+
+        <listitem><para>An implicit <varname>Before=</varname> dependency is created between an automount
+        unit and the mount unit it activates.</para></listitem>
+      </itemizedlist>
+    </refsect2>
+
+    <refsect2>
+      <title>Default Dependencies</title>
+
+      <para>The following dependencies are added unless <varname>DefaultDependencies=no</varname> is set:</para>
+
+      <itemizedlist>
+        <listitem><para>Automount units acquire automatic <varname>Before=</varname> and
+        <varname>Conflicts=</varname> on <filename>umount.target</filename> in order to be stopped during
+        shutdown.</para></listitem>
+
+        <listitem><para>Automount units automatically gain an <varname>After=</varname> dependency
+        on <filename>local-fs-pre.target</filename>, and a <varname>Before=</varname> dependency on
+        <filename>local-fs.target</filename>.</para></listitem>
+      </itemizedlist>
+    </refsect2>
+  </refsect1>
+
+  <refsect1>
+    <title><filename>fstab</filename></title>
+
+    <para>Automount units may either be configured via unit files, or
+    via <filename>/etc/fstab</filename> (see
+    <citerefentry project='man-pages'><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for details).</para>
+
+    <para>For details how systemd parses
+    <filename>/etc/fstab</filename> see
+    <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+
+    <para>If an automount point is configured in both
+    <filename>/etc/fstab</filename> and a unit file, the configuration
+    in the latter takes precedence.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>Automount unit files may include [Unit] and [Install] sections, which are described in
+    <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+    </para>
+
+    <para>Automount unit files must include an [Automount] section, which
+    carries information about the file system automount points it
+    supervises. The options specific to the [Automount] section of
+    automount units are the following:</para>
+
+    <variablelist class='unit-directives'>
+
+      <varlistentry>
+        <term><varname>Where=</varname></term>
+        <listitem><para>Takes an absolute path of a directory of the
+        automount point. If the automount point does not exist at time
+        that the automount point is installed, it is created. This
+        string must be reflected in the unit filename. (See above.)
+        This option is mandatory.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ExtraOptions=</varname></term>
+        <listitem><para>Extra mount options to use when creating the autofs
+        mountpoint. This takes a comma-separated list of options. This setting
+        is optional. Note that the usual specifier expansion is applied to this
+        setting, literal percent characters should hence be written as
+        <literal class='specifiers'>%%</literal>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>DirectoryMode=</varname></term>
+        <listitem><para>Directories of automount points (and any
+        parent directories) are automatically created if needed. This
+        option specifies the file system access mode used when
+        creating these directories. Takes an access mode in octal
+        notation. Defaults to 0755.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>TimeoutIdleSec=</varname></term>
+        <listitem><para>Configures an idle timeout. Once the mount has been
+        idle for the specified time, systemd will attempt to unmount. Takes a
+        unit-less value in seconds, or a time span value such as "5min 20s".
+        Pass 0 to disable the timeout logic. The timeout is disabled by
+        default.</para>
+
+        <xi:include href="version-info.xml" xpointer="v220"/></listitem>
+      </varlistentry>
+    </variablelist>
+
+    <xi:include href="systemd.service.xml" xpointer="shared-unit-options" />
+  </refsect1>
+
+  <refsect1>
+      <title>See Also</title>
+      <para>
+        <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry project='man-pages'><refentrytitle>mount</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+        <citerefentry project='die-net'><refentrytitle>automount</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+      </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd.device.xml b/man/systemd.device.xml
new file mode 100644
index 0000000..529552e
--- /dev/null
+++ b/man/systemd.device.xml
@@ -0,0 +1,171 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd.device">
+  <refentryinfo>
+    <title>systemd.device</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd.device</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd.device</refname>
+    <refpurpose>Device unit configuration</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename><replaceable>device</replaceable>.device</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>A unit configuration file whose name ends in <literal>.device</literal> encodes information about a
+    device unit as exposed in the
+    sysfs/<citerefentry><refentrytitle>udev</refentrytitle><manvolnum>7</manvolnum></citerefentry> device
+    tree. This may be used to define dependencies between devices and other units.</para>
+
+    <para>This unit type has no specific options. See
+    <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for the common options of all unit configuration files. The common
+    configuration items are configured in the generic
+    [Unit] and [Install]
+    sections. A separate [Device] section does not
+    exist, since no device-specific options may be configured.</para>
+
+    <para>systemd will dynamically create device units for all kernel devices that are marked with the
+    <literal>systemd</literal> udev tag (by default all block and network devices, and a few others). Note
+    that <emphasis>if <filename>systemd-udevd.service</filename> is not running, no device units will be
+    available (for example in a typical container)</emphasis>.</para>
+
+    <para>Device units are named after the <filename>/sys/</filename>
+    and <filename>/dev/</filename> paths they control. Example: the
+    device <filename index="false">/dev/sda5</filename> is exposed in
+    systemd as <filename>dev-sda5.device</filename>. For details about
+    the escaping logic used to convert a file system path to a unit
+    name see
+    <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+
+    <para>To tag a udev device, use <literal>TAG+="systemd"</literal> in the udev rules file, see
+    <citerefentry><refentrytitle>udev</refentrytitle><manvolnum>7</manvolnum></citerefentry> for details.
+    </para>
+
+    <para>Device units will be reloaded by systemd whenever the
+    corresponding device generates a <literal>changed</literal> event.
+    Other units can use <varname>ReloadPropagatedFrom=</varname> to react
+    to that event.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Automatic Dependencies</title>
+
+    <refsect2>
+      <title>Implicit Dependencies</title>
+
+      <para>Many unit types automatically acquire dependencies on device
+      units of devices they require. For example,
+      <filename>.socket</filename> unit acquire dependencies on the
+      device units of the network interface specified in
+      <varname>BindToDevice=</varname>. Similar, swap and mount units
+      acquire dependencies on the units encapsulating their backing
+      block devices.</para>
+    </refsect2>
+
+    <refsect2>
+      <title>Default Dependencies</title>
+
+      <para>There are no default dependencies for device units.</para>
+    </refsect2>
+  </refsect1>
+
+  <refsect1>
+    <title>The udev Database</title>
+
+    <para>Unit settings of device units may either be configured via unit files, or directly from the udev
+    database. The following udev device properties are understood by the service manager:</para>
+
+    <variablelist class='udev-directives'>
+      <varlistentry>
+        <term><varname>SYSTEMD_WANTS=</varname></term>
+        <term><varname>SYSTEMD_USER_WANTS=</varname></term>
+        <listitem><para>Adds dependencies of type <varname>Wants=</varname> from the device unit to the specified
+        units. <varname>SYSTEMD_WANTS=</varname> is read by the system service manager,
+        <varname>SYSTEMD_USER_WANTS=</varname> by user service manager instances. These properties may be used to
+        activate arbitrary units when a specific device becomes available.</para>
+
+        <para>Note that this and the other udev device properties are not taken into account unless the device is
+        tagged with the <literal>systemd</literal> tag in the udev database, because otherwise the device is not
+        exposed as a systemd unit (see above).</para>
+
+        <para>Note that systemd will only act on <varname>Wants=</varname> dependencies when a device first becomes
+        active. It will not act on them if they are added to devices that are already active. Use
+        <varname>SYSTEMD_READY=</varname> (see below) to configure when a udev device shall be considered active, and
+        thus when to trigger the dependencies.</para>
+
+        <!-- Note that we don't document here that we actually apply unit_name_mangle() to all specified names, since
+             that's kinda ugly, and people should instead specify correctly escaped names -->
+
+        <para>The specified property value should be a space-separated list of valid unit names. If a unit template
+        name is specified (that is, a unit name containing an <literal>@</literal> character indicating a unit name to
+        use for multiple instantiation, but with an empty instance name following the <literal>@</literal>), it will be
+        automatically instantiated by the device's <literal>sysfs</literal> path (that is: the path is escaped and
+        inserted as instance name into the template unit name). This is useful in order to instantiate a specific
+        template unit once for each device that appears and matches specific properties.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SYSTEMD_ALIAS=</varname></term>
+        <listitem><para>Adds an additional alias name to the device
+        unit. This must be an absolute path that is automatically
+        transformed into a unit name. (See above.)</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SYSTEMD_READY=</varname></term>
+        <listitem><para>If set to 0, systemd will consider this device unplugged even if it shows up in the udev
+        tree. If this property is unset or set to 1, the device will be considered plugged if it is visible in the udev
+        tree.</para>
+
+        <para>This option is useful for devices that initially show up in an uninitialized state in the tree, and for
+        which a <literal>changed</literal> event is generated the moment they are fully set up. Note that
+        <varname>SYSTEMD_WANTS=</varname> (see above) is not acted on as long as <varname>SYSTEMD_READY=0</varname> is
+        set for a device.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ID_MODEL_FROM_DATABASE=</varname></term>
+        <term><varname>ID_MODEL=</varname></term>
+
+        <listitem><para>If set, this property is used as description
+        string for the device unit.</para></listitem>
+      </varlistentry>
+
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>Device unit files may include [Unit] and [Install] sections, which are described in
+    <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>. No
+    options specific to this file type are supported.</para>
+  </refsect1>
+
+  <refsect1>
+      <title>See Also</title>
+      <para>
+        <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>udev</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+      </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd.dnssd.xml b/man/systemd.dnssd.xml
new file mode 100644
index 0000000..5bf9375
--- /dev/null
+++ b/man/systemd.dnssd.xml
@@ -0,0 +1,241 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd.dnssd"
+          xmlns:xi="http://www.w3.org/2001/XInclude"
+          conditional='ENABLE_RESOLVE'>
+
+  <refentryinfo>
+    <title>systemd.dnssd</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd.dnssd</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd.dnssd</refname>
+    <refpurpose>DNS-SD configuration</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename><replaceable>network_service</replaceable>.dnssd</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>DNS-SD setup is performed by
+    <citerefentry><refentrytitle>systemd-resolved</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+    </para>
+
+    <para>The main network service file must have the extension <filename>.dnssd</filename>; other
+    extensions are ignored.</para>
+
+    <para>The <filename>.dnssd</filename> files are read from the files located in the system network
+    directories <filename>/usr/lib/systemd/dnssd</filename> and
+    <filename>/usr/local/lib/systemd/dnssd</filename>, the volatile runtime network directory
+    <filename>/run/systemd/dnssd</filename> and the local administration network directory
+    <filename>/etc/systemd/dnssd</filename>. All configuration files are collectively sorted and processed in
+    lexical order, regardless of the directories in which they live. However, files with identical filenames
+    replace each other. Files in <filename>/etc/</filename> have the highest priority, files in
+    <filename>/run/</filename> take precedence over files with the same name in
+    <filename>/usr/lib/</filename>. This can be used to override a system-supplied configuration file with a
+    local file if needed.</para>
+
+    <para>Along with the network service file <filename>foo.dnssd</filename>, a "drop-in" directory
+    <filename>foo.dnssd.d/</filename> may exist. All files with the suffix
+    <literal>.conf</literal> from this directory will be parsed after the file itself is
+    parsed. This is useful to alter or add configuration settings, without having to modify the main
+    configuration file. Each drop-in file must have appropriate section headers.</para>
+
+    <para>In addition to <filename>/etc/systemd/dnssd</filename>, drop-in <literal>.d</literal> directories
+    can be placed in <filename>/usr/lib/systemd/dnssd</filename> or <filename>/run/systemd/dnssd</filename>
+    directories. Drop-in files in <filename>/etc/</filename> take precedence over those in
+    <filename>/run/</filename> which in turn take precedence over those in <filename>/usr/lib/</filename> or
+    <filename>/usr/local/lib</filename>. Drop-in files under any of these directories take precedence over
+    the main network service file wherever located.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>[Service] Section Options</title>
+
+      <para>The network service file contains a [Service]
+      section, which specifies a discoverable network service announced in a
+      local network with Multicast DNS broadcasts.</para>
+
+      <variablelist class='network-directives'>
+        <varlistentry>
+          <term><varname>Name=</varname></term>
+          <listitem>
+            <para>An instance name of the network service as defined in the section 4.1.1 of <ulink
+            url="https://tools.ietf.org/html/rfc6763">RFC 6763</ulink>, e.g. <literal>webserver</literal>.</para>
+            <para>The option supports simple specifier expansion. The following expansions are understood:</para>
+            <table class='specifiers'>
+              <title>Specifiers available</title>
+              <tgroup cols='3' align='left' colsep='1' rowsep='1'>
+                <colspec colname="spec" />
+                <colspec colname="mean" />
+                <colspec colname="detail" />
+                <thead>
+                  <row>
+                    <entry>Specifier</entry>
+                    <entry>Meaning</entry>
+                    <entry>Details</entry>
+                  </row>
+                </thead>
+                <tbody>
+                  <xi:include href="standard-specifiers.xml" xpointer="a"/>
+                  <xi:include href="standard-specifiers.xml" xpointer="A"/>
+                  <xi:include href="standard-specifiers.xml" xpointer="b"/>
+                  <xi:include href="standard-specifiers.xml" xpointer="B"/>
+                  <xi:include href="standard-specifiers.xml" xpointer="H"/>
+                  <xi:include href="standard-specifiers.xml" xpointer="m"/>
+                  <xi:include href="standard-specifiers.xml" xpointer="M"/>
+                  <xi:include href="standard-specifiers.xml" xpointer="o"/>
+                  <xi:include href="standard-specifiers.xml" xpointer="v"/>
+                  <xi:include href="standard-specifiers.xml" xpointer="w"/>
+                  <xi:include href="standard-specifiers.xml" xpointer="W"/>
+                  <xi:include href="standard-specifiers.xml" xpointer="percent"/>
+                </tbody>
+              </tgroup>
+            </table>
+
+              <xi:include href="version-info.xml" xpointer="v236"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>Type=</varname></term>
+          <listitem>
+            <para>A type of the network service as defined in the section 4.1.2 of <ulink
+            url="https://tools.ietf.org/html/rfc6763">RFC 6763</ulink>, e.g. <literal>_http._tcp</literal>.
+            </para>
+
+          <xi:include href="version-info.xml" xpointer="v236"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>Port=</varname></term>
+          <listitem>
+            <para>An IP port number of the network service.</para>
+
+          <xi:include href="version-info.xml" xpointer="v236"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>Priority=</varname></term>
+          <listitem>
+            <para>A priority number set in <constant class='dns'>SRV</constant> resource records corresponding
+            to the network service.</para>
+
+          <xi:include href="version-info.xml" xpointer="v236"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>Weight=</varname></term>
+          <listitem>
+            <para>A weight number set in <constant class='dns'>SRV</constant> resource records corresponding
+            to the network service.</para>
+
+          <xi:include href="version-info.xml" xpointer="v236"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>TxtText=</varname></term>
+          <listitem>
+            <para>A whitespace-separated list of arbitrary key/value pairs
+            conveying additional information about the named service in the corresponding TXT resource record,
+            e.g. <literal>path=/portal/index.html</literal>. Keys and values can contain C-style escape
+            sequences which get translated upon reading configuration files.
+            </para>
+            <para>This option together with <varname>TxtData=</varname> may be specified more than once, in which
+            case multiple TXT resource records will be created for the service. If the empty string is assigned to
+            this option, the list is reset and all prior assignments will have no effect.
+            </para>
+
+            <xi:include href="version-info.xml" xpointer="v236"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>TxtData=</varname></term>
+          <listitem>
+            <para>A whitespace-separated list of arbitrary key/value pairs
+            conveying additional information about the named service in the corresponding TXT resource record
+            where values are base64-encoded string representing any binary data,
+            e.g. <literal>data=YW55IGJpbmFyeSBkYXRhCg==</literal>. Keys can contain C-style escape
+            sequences which get translated upon reading configuration files.
+            </para>
+            <para>This option together with <varname>TxtText=</varname> may be specified more than once, in which
+            case multiple TXT resource records will be created for the service. If the empty string is assigned to
+            this option, the list is reset and all prior assignments will have no effect.
+            </para>
+
+            <xi:include href="version-info.xml" xpointer="v236"/>
+          </listitem>
+        </varlistentry>
+      </variablelist>
+
+  </refsect1>
+
+  <refsect1>
+    <title>Examples</title>
+    <example>
+      <title>HTTP service</title>
+
+      <programlisting># /etc/systemd/dnssd/http.dnssd
+[Service]
+Name=%H
+Type=_http._tcp
+Port=80
+TxtText=path=/stats/index.html t=temperature_sensor</programlisting>
+
+      <para>This makes the http server running on the host discoverable in the local network
+      given MulticastDNS is enabled on the network interface.</para>
+
+      <para>Now the utility <literal>resolvectl</literal> should be able to resolve the
+      service to the host's name:</para>
+
+      <programlisting>$ resolvectl service meteo._http._tcp.local
+meteo._http._tcp.local: meteo.local:80 [priority=0, weight=0]
+                        169.254.208.106%senp0s21f0u2u4
+                        fe80::213:3bff:fe49:8aa%senp0s21f0u2u4
+                        path=/stats/index.html
+                        t=temperature_sensor
+                        (meteo/_http._tcp/local)
+
+-- Information acquired via protocol mDNS/IPv6 in 4.0ms.
+-- Data is authenticated: yes</programlisting>
+
+      <para><literal>Avahi</literal> running on a different host in the same local network should see the service as well:</para>
+
+      <programlisting>$ avahi-browse -a -r
++ enp3s0 IPv6 meteo                                         Web Site             local
++ enp3s0 IPv4 meteo                                         Web Site             local
+= enp3s0 IPv6 meteo                                         Web Site             local
+   hostname = [meteo.local]
+   address = [fe80::213:3bff:fe49:8aa]
+   port = [80]
+   txt = ["path=/stats/index.html" "t=temperature_sensor"]
+= enp3s0 IPv4 meteo                                         Web Site             local
+   hostname = [meteo.local]
+   address = [169.254.208.106]
+   port = [80]
+   txt = ["path=/stats/index.html" "t=temperature_sensor"]</programlisting>
+
+    </example>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-resolved.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>resolvectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd.environment-generator.xml b/man/systemd.environment-generator.xml
new file mode 100644
index 0000000..856f6a6
--- /dev/null
+++ b/man/systemd.environment-generator.xml
@@ -0,0 +1,134 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [
+<!ENTITY % entities SYSTEM "custom-entities.ent" >
+%entities;
+]>
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd.environment-generator" conditional='ENABLE_ENVIRONMENT_D'
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+  <refentryinfo>
+    <title>systemd.environment-generator</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd.environment-generator</refentrytitle>
+    <manvolnum>7</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd.environment-generator</refname>
+    <refpurpose>systemd environment file generators</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <cmdsynopsis>
+      <command>&SYSTEM_ENV_GENERATOR_DIR;/some-generator</command>
+    </cmdsynopsis>
+    <cmdsynopsis>
+      <command>&USER_ENV_GENERATOR_DIR;/some-generator</command>
+    </cmdsynopsis>
+
+    <para>
+      <literallayout><filename>/run/systemd/system-environment-generators/*</filename>
+<filename>/etc/systemd/system-environment-generators/*</filename>
+<filename>/usr/local/lib/systemd/system-environment-generators/*</filename>
+<filename>&SYSTEM_ENV_GENERATOR_DIR;/*</filename></literallayout>
+    </para>
+
+    <para>
+      <literallayout><filename>/run/systemd/user-environment-generators/*</filename>
+<filename>/etc/systemd/user-environment-generators/*</filename>
+<filename>/usr/local/lib/systemd/user-environment-generators/*</filename>
+<filename>&USER_ENV_GENERATOR_DIR;/*</filename></literallayout>
+    </para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+    <para>Generators are small executables that live in
+    <filename>&SYSTEM_ENV_GENERATOR_DIR;/</filename> and other directories listed above.
+    <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> will
+    execute those binaries very early at the startup of each manager and at configuration
+    reload time, before running the generators described in
+    <citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+    and before starting any units. Environment generators can override the environment that the
+    manager exports to services and other processes.</para>
+
+    <para>Generators are loaded from a set of paths determined during compilation, as listed
+    above. System and user environment generators are loaded from directories with names ending in
+    <filename>system-environment-generators/</filename> and
+    <filename>user-environment-generators/</filename>, respectively. Generators found in directories
+    listed earlier override the ones with the same name in directories lower in the list. A symlink
+    to <filename>/dev/null</filename> or an empty file can be used to mask a generator, thereby
+    preventing it from running. Please note that the order of the two directories with the highest
+    priority is reversed with respect to the unit load path, and generators in
+    <filename>/run/</filename> overwrite those in <filename>/etc/</filename>.</para>
+
+    <para>After installing new generators or updating the configuration, <command>systemctl
+    daemon-reload</command> may be executed. This will re-run all generators, updating environment
+    configuration. It will be used for any services that are started subsequently.</para>
+
+    <para>Environment file generators are executed similarly to unit file generators described
+    in
+    <citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+    with the following differences:</para>
+
+    <itemizedlist>
+      <listitem>
+        <para>Generators are executed sequentially in the alphanumerical order of the final
+        component of their name. The output of each generator output is immediately parsed and used
+        to update the environment for generators that run after that. Thus, later generators can use
+        and/or modify the output of earlier generators.</para>
+      </listitem>
+
+      <listitem>
+        <para>Generators are run by every manager instance, their output can be different for each
+        user.</para>
+      </listitem>
+    </itemizedlist>
+
+    <para>It is recommended to use numerical prefixes for generator names to simplify ordering.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Examples</title>
+
+    <example>
+      <title>A simple generator that extends an environment variable if a directory exists in the file system</title>
+
+      <programlisting># 50-xdg-data-dirs.sh
+
+<xi:include href="50-xdg-data-dirs.sh" parse="text" /></programlisting>
+    </example>
+
+    <example>
+      <title>A more complicated generator which reads existing configuration and mutates one variable</title>
+
+      <programlisting># 90-rearrange-path.py
+
+<xi:include href="90-rearrange-path.py" parse="text" /></programlisting>
+    </example>
+
+    <example>
+      <title>Debugging a generator</title>
+
+      <programlisting>SYSTEMD_LOG_LEVEL=debug VAR_A=something VAR_B="something else" \
+&SYSTEM_ENV_GENERATOR_DIR;/path-to-generator
+</programlisting>
+    </example>
+  </refsect1>
+
+  <refsect1>
+    <title>See also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd-environment-d-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+</refentry>
diff --git a/man/systemd.exec.xml b/man/systemd.exec.xml
new file mode 100644
index 0000000..a671649
--- /dev/null
+++ b/man/systemd.exec.xml
@@ -0,0 +1,4634 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd.exec" xmlns:xi="http://www.w3.org/2001/XInclude">
+  <refentryinfo>
+    <title>systemd.exec</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd.exec</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd.exec</refname>
+    <refpurpose>Execution environment configuration</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename><replaceable>service</replaceable>.service</filename>,
+    <filename><replaceable>socket</replaceable>.socket</filename>,
+    <filename><replaceable>mount</replaceable>.mount</filename>,
+    <filename><replaceable>swap</replaceable>.swap</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>Unit configuration files for services, sockets, mount points, and swap devices share a subset of
+    configuration options which define the execution environment of spawned processes.</para>
+
+    <para>This man page lists the configuration options shared by these four unit types. See
+    <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> for the common
+    options of all unit configuration files, and
+    <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>systemd.swap</refentrytitle><manvolnum>5</manvolnum></citerefentry>, and
+    <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry> for more
+    information on the specific unit configuration files. The execution specific configuration options are configured
+    in the [Service], [Socket], [Mount], or [Swap] sections, depending on the unit type.</para>
+
+    <para>In addition, options which control resources through Linux Control Groups (cgroups) are listed in
+    <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+    Those options complement options listed here.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Implicit Dependencies</title>
+
+    <para>A few execution parameters result in additional, automatic dependencies to be added:</para>
+
+    <itemizedlist>
+      <listitem><para>Units with <varname>WorkingDirectory=</varname>, <varname>RootDirectory=</varname>,
+      <varname>RootImage=</varname>, <varname>RuntimeDirectory=</varname>, <varname>StateDirectory=</varname>,
+      <varname>CacheDirectory=</varname>, <varname>LogsDirectory=</varname> or
+      <varname>ConfigurationDirectory=</varname> set automatically gain dependencies of type
+      <varname>Requires=</varname> and <varname>After=</varname> on all mount units required to access the specified
+      paths. This is equivalent to having them listed explicitly in
+      <varname>RequiresMountsFor=</varname>.</para></listitem>
+
+      <listitem><para>Similarly, units with <varname>PrivateTmp=</varname> enabled automatically get mount
+      unit dependencies for all mounts required to access <filename>/tmp/</filename> and
+      <filename>/var/tmp/</filename>. They will also gain an automatic <varname>After=</varname> dependency
+      on
+      <citerefentry><refentrytitle>systemd-tmpfiles-setup.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+      </para></listitem>
+
+      <listitem><para>Units whose standard output or error output is connected to <option>journal</option> or
+      <option>kmsg</option> (or their combinations with console output, see below) automatically acquire
+      dependencies of type <varname>After=</varname> on
+      <filename>systemd-journald.socket</filename>.</para></listitem>
+
+      <listitem><para>Units using <varname>LogNamespace=</varname> will automatically gain ordering and
+      requirement dependencies on the two socket units associated with
+      <filename>systemd-journald@.service</filename> instances.</para></listitem>
+    </itemizedlist>
+  </refsect1>
+
+  <!-- We don't have any default dependency here. -->
+
+  <refsect1>
+    <title>Paths</title>
+
+    <para>The following settings may be used to change a service's view of the filesystem. Please note that the paths
+    must be absolute and must not contain a <literal>..</literal> path component.</para>
+
+    <variablelist class='unit-directives'>
+
+      <varlistentry>
+        <term><varname>ExecSearchPath=</varname></term>
+
+        <listitem><para>Takes a colon separated list of absolute paths relative to which the executable
+        used by the <varname>Exec*=</varname> (e.g. <varname>ExecStart=</varname>,
+        <varname>ExecStop=</varname>, etc.) properties can be found. <varname>ExecSearchPath=</varname>
+        overrides <varname>$PATH</varname> if <varname>$PATH</varname> is not supplied by the user through
+        <varname>Environment=</varname>, <varname>EnvironmentFile=</varname> or
+        <varname>PassEnvironment=</varname>. Assigning an empty string removes previous assignments
+        and setting <varname>ExecSearchPath=</varname> to a value multiple times will append
+        to the previous setting.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>WorkingDirectory=</varname></term>
+
+        <listitem><para>Takes a directory path relative to the service's root directory specified by
+        <varname>RootDirectory=</varname>, or the special value <literal>~</literal>. Sets the working directory for
+        executed processes. If set to <literal>~</literal>, the home directory of the user specified in
+        <varname>User=</varname> is used. If not set, defaults to the root directory when systemd is running as a
+        system instance and the respective user's home directory if run as user. If the setting is prefixed with the
+        <literal>-</literal> character, a missing working directory is not considered fatal. If
+        <varname>RootDirectory=</varname>/<varname>RootImage=</varname> is not set, then
+        <varname>WorkingDirectory=</varname> is relative to the root of the system running the service manager. Note
+        that setting this parameter might result in additional dependencies to be added to the unit (see
+        above).</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RootDirectory=</varname></term>
+
+        <listitem><para>Takes a directory path relative to the host's root directory (i.e. the root of the system
+        running the service manager). Sets the root directory for executed processes, with the <citerefentry
+        project='man-pages'><refentrytitle>chroot</refentrytitle><manvolnum>2</manvolnum></citerefentry> system
+        call. If this is used, it must be ensured that the process binary and all its auxiliary files are available in
+        the <function>chroot()</function> jail. Note that setting this parameter might result in additional
+        dependencies to be added to the unit (see above).</para>
+
+        <para>The <varname>MountAPIVFS=</varname> and <varname>PrivateUsers=</varname> settings are particularly useful
+        in conjunction with <varname>RootDirectory=</varname>. For details, see below.</para>
+
+        <para>If <varname>RootDirectory=</varname>/<varname>RootImage=</varname> are used together with
+        <varname>NotifyAccess=</varname> the notification socket is automatically mounted from the host into
+        the root environment, to ensure the notification interface can work correctly.</para>
+
+        <para>Note that services using <varname>RootDirectory=</varname>/<varname>RootImage=</varname> will
+        not be able to log via the syslog or journal protocols to the host logging infrastructure, unless the
+        relevant sockets are mounted from the host, specifically:</para>
+
+        <para>The host's
+        <citerefentry><refentrytitle>os-release</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        file will be made available for the service (read-only) as
+        <filename>/run/host/os-release</filename>.
+        It will be updated automatically on soft reboot (see:
+        <citerefentry><refentrytitle>systemd-soft-reboot.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>),
+        in case the service is configured to survive it.</para>
+
+        <example>
+          <title>Mounting logging sockets into root environment</title>
+
+          <programlisting>BindReadOnlyPaths=/dev/log /run/systemd/journal/socket /run/systemd/journal/stdout</programlisting>
+        </example>
+
+        <xi:include href="system-or-user-ns.xml" xpointer="singular"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RootImage=</varname></term>
+
+        <listitem><para>Takes a path to a block device node or regular file as argument. This call is similar
+        to <varname>RootDirectory=</varname> however mounts a file system hierarchy from a block device node
+        or loopback file instead of a directory. The device node or file system image file needs to contain a
+        file system without a partition table, or a file system within an MBR/MS-DOS or GPT partition table
+        with only a single Linux-compatible partition, or a set of file systems within a GPT partition table
+        that follows the
+        <ulink url="https://uapi-group.org/specifications/specs/discoverable_partitions_specification">
+          Discoverable Partitions Specification</ulink>.</para>
+
+        <para>When <varname>DevicePolicy=</varname> is set to <literal>closed</literal> or
+        <literal>strict</literal>, or set to <literal>auto</literal> and <varname>DeviceAllow=</varname> is
+        set, then this setting adds <filename>/dev/loop-control</filename> with <constant>rw</constant> mode,
+        <literal>block-loop</literal> and <literal>block-blkext</literal> with <constant>rwm</constant> mode
+        to <varname>DeviceAllow=</varname>. See
+        <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for the details about <varname>DevicePolicy=</varname> or <varname>DeviceAllow=</varname>. Also, see
+        <varname>PrivateDevices=</varname> below, as it may change the setting of
+        <varname>DevicePolicy=</varname>.</para>
+
+        <para>Units making use of <varname>RootImage=</varname> automatically gain an
+        <varname>After=</varname> dependency on <filename>systemd-udevd.service</filename>.</para>
+
+        <para>The host's
+        <citerefentry><refentrytitle>os-release</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        file will be made available for the service (read-only) as
+        <filename>/run/host/os-release</filename>.
+        It will be updated automatically on soft reboot (see:
+        <citerefentry><refentrytitle>systemd-soft-reboot.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>),
+        in case the service is configured to survive it.</para>
+
+        <xi:include href="system-only.xml" xpointer="singular"/>
+
+        <xi:include href="version-info.xml" xpointer="v233"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RootImageOptions=</varname></term>
+
+        <listitem><para>Takes a comma-separated list of mount options that will be used on disk images specified by
+        <varname>RootImage=</varname>. Optionally a partition name can be prefixed, followed by colon, in
+        case the image has multiple partitions, otherwise partition name <literal>root</literal> is implied.
+        Options for multiple partitions can be specified in a single line with space separators. Assigning an empty
+        string removes previous assignments. Duplicated options are ignored. For a list of valid mount options, please
+        refer to
+        <citerefentry project='man-pages'><refentrytitle>mount</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+        </para>
+
+        <para>Valid partition names follow the
+        <ulink url="https://uapi-group.org/specifications/specs/discoverable_partitions_specification">
+          Discoverable Partitions Specification</ulink>:
+        <constant>root</constant>, <constant>usr</constant>, <constant>home</constant>, <constant>srv</constant>,
+        <constant>esp</constant>, <constant>xbootldr</constant>, <constant>tmp</constant>,
+        <constant>var</constant>.</para>
+
+        <xi:include href="system-only.xml" xpointer="singular"/>
+
+        <xi:include href="version-info.xml" xpointer="v247"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RootEphemeral=</varname></term>
+
+        <listitem><para>Takes a boolean argument. If enabled, executed processes will run in an ephemeral
+        copy of the root directory or root image. The ephemeral copy is placed in
+        <filename>/var/lib/systemd/ephemeral-trees/</filename> while the service is active and is cleaned up
+        when the service is stopped or restarted. If <varname>RootDirectory=</varname> is used and the root
+        directory is a subvolume, the ephemeral copy will be created by making a snapshot of the subvolume.
+        </para>
+
+        <para>To make sure making ephemeral copies can be made efficiently, the root directory or root image
+        should be located on the same filesystem as <filename>/var/lib/systemd/ephemeral-trees/</filename>.
+        When using <varname>RootEphemeral=</varname> with root directories,
+        <citerefentry project='url'><refentrytitle url='https://btrfs.readthedocs.io/en/latest/btrfs-man5.html'>btrfs</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        should be used as the filesystem and the root directory should ideally be a subvolume which
+        <command>systemd</command> can snapshot to make the ephemeral copy. For root images, a filesystem
+        with support for reflinks should be used to ensure an efficient ephemeral copy.</para>
+
+        <xi:include href="system-only.xml" xpointer="singular"/>
+
+        <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RootHash=</varname></term>
+
+        <listitem><para>Takes a data integrity (dm-verity) root hash specified in hexadecimal, or the path to a file
+        containing a root hash in ASCII hexadecimal format. This option enables data integrity checks using dm-verity,
+        if the used image contains the appropriate integrity data (see above) or if <varname>RootVerity=</varname> is used.
+        The specified hash must match the root hash of integrity data, and is usually at least 256 bits (and hence 64
+        formatted hexadecimal characters) long (in case of SHA256 for example). If this option is not specified, but
+        the image file carries the <literal>user.verity.roothash</literal> extended file attribute (see <citerefentry
+        project='man-pages'><refentrytitle>xattr</refentrytitle><manvolnum>7</manvolnum></citerefentry>), then the root
+        hash is read from it, also as formatted hexadecimal characters. If the extended file attribute is not found (or
+        is not supported by the underlying file system), but a file with the <filename>.roothash</filename> suffix is
+        found next to the image file, bearing otherwise the same name (except if the image has the
+        <filename>.raw</filename> suffix, in which case the root hash file must not have it in its name), the root hash
+        is read from it and automatically used, also as formatted hexadecimal characters.</para>
+
+        <para>If the disk image contains a separate <filename>/usr/</filename> partition it may also be
+        Verity protected, in which case the root hash may configured via an extended attribute
+        <literal>user.verity.usrhash</literal> or a <filename>.usrhash</filename> file adjacent to the disk
+        image. There's currently no option to configure the root hash for the <filename>/usr/</filename> file
+        system via the unit file directly.</para>
+
+        <xi:include href="system-only.xml" xpointer="singular"/>
+
+        <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RootHashSignature=</varname></term>
+
+        <listitem><para>Takes a PKCS7 signature of the <varname>RootHash=</varname> option as a path to a
+        DER-encoded signature file, or as an ASCII base64 string encoding of a DER-encoded signature prefixed
+        by <literal>base64:</literal>. The dm-verity volume will only be opened if the signature of the root
+        hash is valid and signed by a public key present in the kernel keyring. If this option is not
+        specified, but a file with the <filename>.roothash.p7s</filename> suffix is found next to the image
+        file, bearing otherwise the same name (except if the image has the <filename>.raw</filename> suffix,
+        in which case the signature file must not have it in its name), the signature is read from it and
+        automatically used.</para>
+
+        <para>If the disk image contains a separate <filename>/usr/</filename> partition it may also be
+        Verity protected, in which case the signature for the root hash may configured via a
+        <filename>.usrhash.p7s</filename> file adjacent to the disk image. There's currently no option to
+        configure the root hash signature for the <filename>/usr/</filename> via the unit file
+        directly.</para>
+
+        <xi:include href="system-only.xml" xpointer="singular"/>
+
+        <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RootVerity=</varname></term>
+
+        <listitem><para>Takes the path to a data integrity (dm-verity) file. This option enables data integrity checks
+        using dm-verity, if <varname>RootImage=</varname> is used and a root-hash is passed and if the used image itself
+        does not contain the integrity data. The integrity data must be matched by the root hash. If this option is not
+        specified, but a file with the <filename>.verity</filename> suffix is found next to the image file, bearing otherwise
+        the same name (except if the image has the <filename>.raw</filename> suffix, in which case the verity data file must
+        not have it in its name), the verity data is read from it and automatically used.</para>
+
+        <para>This option is supported only for disk images that contain a single file system, without an
+        enveloping partition table. Images that contain a GPT partition table should instead include both
+        root file system and matching Verity data in the same image, implementing the
+        <ulink url="https://uapi-group.org/specifications/specs/discoverable_partitions_specification">
+          Discoverable Partitions Specification</ulink>.</para>
+
+        <xi:include href="system-only.xml" xpointer="singular"/>
+
+        <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RootImagePolicy=</varname></term>
+        <term><varname>MountImagePolicy=</varname></term>
+        <term><varname>ExtensionImagePolicy=</varname></term>
+
+        <listitem><para>Takes an image policy string as per
+        <citerefentry><refentrytitle>systemd.image-policy</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+        to use when mounting the disk images (DDI) specified in <varname>RootImage=</varname>,
+        <varname>MountImage=</varname>, <varname>ExtensionImage=</varname>, respectively. If not specified
+        the following policy string is the default for <varname>RootImagePolicy=</varname> and <varname>MountImagePolicy</varname>:</para>
+
+        <programlisting>root=verity+signed+encrypted+unprotected+absent: \
+        usr=verity+signed+encrypted+unprotected+absent: \
+        home=encrypted+unprotected+absent: \
+        srv=encrypted+unprotected+absent: \
+        tmp=encrypted+unprotected+absent: \
+        var=encrypted+unprotected+absent</programlisting>
+
+        <para>The default policy for <varname>ExtensionImagePolicy=</varname> is:</para>
+
+        <programlisting>root=verity+signed+encrypted+unprotected+absent: \
+        usr=verity+signed+encrypted+unprotected+absent</programlisting>
+
+        <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>MountAPIVFS=</varname></term>
+
+        <listitem><para>Takes a boolean argument. If on, a private mount namespace for the unit's processes is created
+        and the API file systems <filename>/proc/</filename>, <filename>/sys/</filename>, <filename>/dev/</filename> and
+        <filename>/run/</filename> (as an empty <literal>tmpfs</literal>) are mounted inside of it, unless they are
+        already mounted. Note that this option has no effect unless used in conjunction with
+        <varname>RootDirectory=</varname>/<varname>RootImage=</varname> as these four mounts are
+        generally mounted in the host anyway, and unless the root directory is changed, the private mount namespace
+        will be a 1:1 copy of the host's, and include these four mounts. Note that the <filename>/dev/</filename> file
+        system of the host is bind mounted if this option is used without <varname>PrivateDevices=</varname>. To run
+        the service with a private, minimal version of <filename>/dev/</filename>, combine this option with
+        <varname>PrivateDevices=</varname>.</para>
+
+        <para>In order to allow propagating mounts at runtime in a safe manner, <filename>/run/systemd/propagate/</filename>
+        on the host will be used to set up new mounts, and <filename>/run/host/incoming/</filename> in the private namespace
+        will be used as an intermediate step to store them before being moved to the final mount point.</para>
+
+        <xi:include href="version-info.xml" xpointer="v233"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ProtectProc=</varname></term>
+
+        <listitem><para>Takes one of <literal>noaccess</literal>, <literal>invisible</literal>,
+        <literal>ptraceable</literal> or <literal>default</literal> (which it defaults to). When set, this
+        controls the <literal>hidepid=</literal> mount option of the <literal>procfs</literal> instance for
+        the unit that controls which directories with process metainformation
+        (<filename>/proc/<replaceable>PID</replaceable></filename>) are visible and accessible: when set to
+        <literal>noaccess</literal> the ability to access most of other users' process metadata in
+        <filename>/proc/</filename> is taken away for processes of the service. When set to
+        <literal>invisible</literal> processes owned by other users are hidden from
+        <filename>/proc/</filename>. If <literal>ptraceable</literal> all processes that cannot be
+        <function>ptrace()</function>'ed by a process are hidden to it. If <literal>default</literal> no
+        restrictions on <filename>/proc/</filename> access or visibility are made. For further details see
+        <ulink url="https://docs.kernel.org/filesystems/proc.html#mount-options">The /proc
+        Filesystem</ulink>. It is generally recommended to run most system services with this option set to
+        <literal>invisible</literal>. This option is implemented via file system namespacing, and thus cannot
+        be used with services that shall be able to install mount points in the host file system
+        hierarchy. Note that the root user is unaffected by this option, so to be effective it has to be used
+        together with <varname>User=</varname> or <varname>DynamicUser=yes</varname>, and also without the
+        <literal>CAP_SYS_PTRACE</literal> capability, which also allows a process to bypass this feature. It
+        cannot be used for services that need to access metainformation about other users' processes. This
+        option implies <varname>MountAPIVFS=</varname>.</para>
+
+        <para>If the kernel doesn't support per-mount point <option>hidepid=</option> mount options this
+        setting remains without effect, and the unit's processes will be able to access and see other process
+        as if the option was not used.</para>
+
+        <xi:include href="system-only.xml" xpointer="singular"/>
+
+        <xi:include href="version-info.xml" xpointer="v247"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ProcSubset=</varname></term>
+
+        <listitem><para>Takes one of <literal>all</literal> (the default) and <literal>pid</literal>. If
+        <literal>pid</literal>, all files and directories not directly associated with process management and
+        introspection are made invisible in the <filename>/proc/</filename> file system configured for the
+        unit's processes. This controls the <literal>subset=</literal> mount option of the
+        <literal>procfs</literal> instance for the unit. For further details see <ulink
+        url="https://docs.kernel.org/filesystems/proc.html#mount-options">The /proc
+        Filesystem</ulink>. Note that Linux exposes various kernel APIs via <filename>/proc/</filename>,
+        which are made unavailable with this setting. Since these APIs are used frequently this option is
+        useful only in a few, specific cases, and is not suitable for most non-trivial programs.</para>
+
+        <para>Much like <varname>ProtectProc=</varname> above, this is implemented via file system mount
+        namespacing, and hence the same restrictions apply: it is only available to system services, it
+        disables mount propagation to the host mount table, and it implies
+        <varname>MountAPIVFS=</varname>. Also, like <varname>ProtectProc=</varname> this setting is gracefully
+        disabled if the used kernel does not support the <literal>subset=</literal> mount option of
+        <literal>procfs</literal>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v247"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>BindPaths=</varname></term>
+        <term><varname>BindReadOnlyPaths=</varname></term>
+
+        <listitem><para>Configures unit-specific bind mounts. A bind mount makes a particular file or directory
+        available at an additional place in the unit's view of the file system. Any bind mounts created with this
+        option are specific to the unit, and are not visible in the host's mount table. This option expects a
+        whitespace separated list of bind mount definitions. Each definition consists of a colon-separated triple of
+        source path, destination path and option string, where the latter two are optional. If only a source path is
+        specified the source and destination is taken to be the same. The option string may be either
+        <literal>rbind</literal> or <literal>norbind</literal> for configuring a recursive or non-recursive bind
+        mount. If the destination path is omitted, the option string must be omitted too.
+        Each bind mount definition may be prefixed with <literal>-</literal>, in which case it will be ignored
+        when its source path does not exist.</para>
+
+        <para><varname>BindPaths=</varname> creates regular writable bind mounts (unless the source file system mount
+        is already marked read-only), while <varname>BindReadOnlyPaths=</varname> creates read-only bind mounts. These
+        settings may be used more than once, each usage appends to the unit's list of bind mounts. If the empty string
+        is assigned to either of these two options the entire list of bind mounts defined prior to this is reset. Note
+        that in this case both read-only and regular bind mounts are reset, regardless which of the two settings is
+        used.</para>
+
+        <para>This option is particularly useful when <varname>RootDirectory=</varname>/<varname>RootImage=</varname>
+        is used. In this case the source path refers to a path on the host file system, while the destination path
+        refers to a path below the root directory of the unit.</para>
+
+        <para>Note that the destination directory must exist or systemd must be able to create it. Thus, it
+        is not possible to use those options for mount points nested underneath paths specified in
+        <varname>InaccessiblePaths=</varname>, or under <filename>/home/</filename> and other protected
+        directories if <varname>ProtectHome=yes</varname> is
+        specified. <varname>TemporaryFileSystem=</varname> with <literal>:ro</literal> or
+        <varname>ProtectHome=tmpfs</varname> should be used instead.</para>
+
+        <xi:include href="version-info.xml" xpointer="v233"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>MountImages=</varname></term>
+
+        <listitem><para>This setting is similar to <varname>RootImage=</varname> in that it mounts a file
+        system hierarchy from a block device node or loopback file, but the destination directory can be
+        specified as well as mount options. This option expects a whitespace separated list of mount
+        definitions. Each definition consists of a colon-separated tuple of source path and destination
+        definitions, optionally followed by another colon and a list of mount options.</para>
+
+        <para>Mount options may be defined as a single comma-separated list of options, in which case they
+        will be implicitly applied to the root partition on the image, or a series of colon-separated tuples
+        of partition name and mount options. Valid partition names and mount options are the same as for
+        <varname>RootImageOptions=</varname> setting described above.</para>
+
+        <para>Each mount definition may be prefixed with <literal>-</literal>, in which case it will be
+        ignored when its source path does not exist. The source argument is a path to a block device node or
+        regular file. If source or destination contain a <literal>:</literal>, it needs to be escaped as
+        <literal>\:</literal>. The device node or file system image file needs to follow the same rules as
+        specified for <varname>RootImage=</varname>. Any mounts created with this option are specific to the
+        unit, and are not visible in the host's mount table.</para>
+
+        <para>These settings may be used more than once, each usage appends to the unit's list of mount
+        paths. If the empty string is assigned, the entire list of mount paths defined prior to this is
+        reset.</para>
+
+        <para>Note that the destination directory must exist or systemd must be able to create it. Thus, it
+        is not possible to use those options for mount points nested underneath paths specified in
+        <varname>InaccessiblePaths=</varname>, or under <filename>/home/</filename> and other protected
+        directories if <varname>ProtectHome=yes</varname> is specified.</para>
+
+        <para>When <varname>DevicePolicy=</varname> is set to <literal>closed</literal> or
+        <literal>strict</literal>, or set to <literal>auto</literal> and <varname>DeviceAllow=</varname> is
+        set, then this setting adds <filename>/dev/loop-control</filename> with <constant>rw</constant> mode,
+        <literal>block-loop</literal> and <literal>block-blkext</literal> with <constant>rwm</constant> mode
+        to <varname>DeviceAllow=</varname>. See
+        <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for the details about <varname>DevicePolicy=</varname> or <varname>DeviceAllow=</varname>. Also, see
+        <varname>PrivateDevices=</varname> below, as it may change the setting of
+        <varname>DevicePolicy=</varname>.</para>
+
+        <xi:include href="system-only.xml" xpointer="singular"/>
+
+        <xi:include href="version-info.xml" xpointer="v247"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ExtensionImages=</varname></term>
+
+        <listitem><para>This setting is similar to <varname>MountImages=</varname> in that it mounts a file
+        system hierarchy from a block device node or loopback file, but instead of providing a destination
+        path, an overlay will be set up. This option expects a whitespace separated list of mount
+        definitions. Each definition consists of a source path, optionally followed by a colon and a list of
+        mount options.</para>
+
+        <para>A read-only OverlayFS will be set up on top of <filename>/usr/</filename> and
+        <filename>/opt/</filename> hierarchies for sysext images and <filename>/etc/</filename>
+        hierarchy for confext images. The order in which the images are listed will determine the
+        order in which the overlay is laid down: images specified first to last will result in overlayfs
+        layers bottom to top.</para>
+
+        <para>Mount options may be defined as a single comma-separated list of options, in which case they
+        will be implicitly applied to the root partition on the image, or a series of colon-separated tuples
+        of partition name and mount options. Valid partition names and mount options are the same as for
+        <varname>RootImageOptions=</varname> setting described above.</para>
+
+        <para>Each mount definition may be prefixed with <literal>-</literal>, in which case it will be
+        ignored when its source path does not exist. The source argument is a path to a block device node or
+        regular file. If the source path contains a <literal>:</literal>, it needs to be escaped as
+        <literal>\:</literal>. The device node or file system image file needs to follow the same rules as
+        specified for <varname>RootImage=</varname>. Any mounts created with this option are specific to the
+        unit, and are not visible in the host's mount table.</para>
+
+        <para>These settings may be used more than once, each usage appends to the unit's list of image
+        paths. If the empty string is assigned, the entire list of mount paths defined prior to this is
+        reset.</para>
+
+        <para>Each sysext image must carry a <filename>/usr/lib/extension-release.d/extension-release.IMAGE</filename>
+        file while each confext image must carry a <filename>/etc/extension-release.d/extension-release.IMAGE</filename>
+        file, with the appropriate metadata which matches <varname>RootImage=</varname>/<varname>RootDirectory=</varname>
+        or the host. See:
+        <citerefentry><refentrytitle>os-release</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+        To disable the safety check that the extension-release file name matches the image file name, the
+        <varname>x-systemd.relax-extension-release-check</varname> mount option may be appended.</para>
+
+        <para>When <varname>DevicePolicy=</varname> is set to <literal>closed</literal> or
+        <literal>strict</literal>, or set to <literal>auto</literal> and <varname>DeviceAllow=</varname> is
+        set, then this setting adds <filename>/dev/loop-control</filename> with <constant>rw</constant> mode,
+        <literal>block-loop</literal> and <literal>block-blkext</literal> with <constant>rwm</constant> mode
+        to <varname>DeviceAllow=</varname>. See
+        <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for the details about <varname>DevicePolicy=</varname> or <varname>DeviceAllow=</varname>. Also, see
+        <varname>PrivateDevices=</varname> below, as it may change the setting of
+        <varname>DevicePolicy=</varname>.</para>
+
+        <xi:include href="system-only.xml" xpointer="singular"/>
+
+        <xi:include href="version-info.xml" xpointer="v248"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ExtensionDirectories=</varname></term>
+
+        <listitem><para>This setting is similar to <varname>BindReadOnlyPaths=</varname> in that it mounts a file
+        system hierarchy from a directory, but instead of providing a destination path, an overlay will be set
+        up. This option expects a whitespace separated list of source directories.</para>
+
+        <para>A read-only OverlayFS will be set up on top of <filename>/usr/</filename> and
+        <filename>/opt/</filename> hierarchies for sysext images and <filename>/etc/</filename>
+        hierarchy for confext images. The order in which the directories are listed will determine
+        the order in which the overlay is laid down: directories specified first to last will result in overlayfs
+        layers bottom to top.</para>
+
+        <para>Each directory listed in <varname>ExtensionDirectories=</varname> may be prefixed with <literal>-</literal>,
+        in which case it will be ignored when its source path does not exist. Any mounts created with this option are
+        specific to the unit, and are not visible in the host's mount table.</para>
+
+        <para>These settings may be used more than once, each usage appends to the unit's list of directories
+        paths. If the empty string is assigned, the entire list of mount paths defined prior to this is
+        reset.</para>
+
+        <para>Each sysext directory must contain a <filename>/usr/lib/extension-release.d/extension-release.IMAGE</filename>
+        file while each confext directory must carry a <filename>/etc/extension-release.d/extension-release.IMAGE</filename>
+        file, with the appropriate metadata which matches <varname>RootImage=</varname>/<varname>RootDirectory=</varname>
+        or the host. See:
+        <citerefentry><refentrytitle>os-release</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+
+        <para>Note that usage from user units requires overlayfs support in unprivileged user namespaces,
+        which was first introduced in kernel v5.11.</para>
+
+        <xi:include href="system-or-user-ns.xml" xpointer="singular"/>
+
+        <xi:include href="version-info.xml" xpointer="v251"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>User/Group Identity</title>
+
+    <xi:include href="system-only.xml" xpointer="plural"/>
+
+    <variablelist class='unit-directives'>
+
+      <varlistentry>
+        <term><varname>User=</varname></term>
+        <term><varname>Group=</varname></term>
+
+        <listitem><para>Set the UNIX user or group that the processes are executed as, respectively. Takes a single
+        user or group name, or a numeric ID as argument. For system services (services run by the system service
+        manager, i.e. managed by PID 1) and for user services of the root user (services managed by root's instance of
+        <command>systemd --user</command>), the default is <literal>root</literal>, but <varname>User=</varname> may be
+        used to specify a different user. For user services of any other user, switching user identity is not
+        permitted, hence the only valid setting is the same user the user's service manager is running as. If no group
+        is set, the default group of the user is used. This setting does not affect commands whose command line is
+        prefixed with <literal>+</literal>.</para>
+
+        <para>Note that this enforces only weak restrictions on the user/group name syntax, but will generate
+        warnings in many cases where user/group names do not adhere to the following rules: the specified
+        name should consist only of the characters a-z, A-Z, 0-9, <literal>_</literal> and
+        <literal>-</literal>, except for the first character which must be one of a-z, A-Z and
+        <literal>_</literal> (i.e. digits and <literal>-</literal> are not permitted as first character). The
+        user/group name must have at least one character, and at most 31. These restrictions are made in
+        order to avoid ambiguities and to ensure user/group names and unit files remain portable among Linux
+        systems. For further details on the names accepted and the names warned about see <ulink
+        url="https://systemd.io/USER_NAMES">User/Group Name Syntax</ulink>.</para>
+
+        <para>When used in conjunction with <varname>DynamicUser=</varname> the user/group name specified is
+        dynamically allocated at the time the service is started, and released at the time the service is
+        stopped — unless it is already allocated statically (see below). If <varname>DynamicUser=</varname>
+        is not used the specified user and group must have been created statically in the user database no
+        later than the moment the service is started, for example using the
+        <citerefentry><refentrytitle>sysusers.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        facility, which is applied at boot or package install time. If the user does not exist by then
+        program invocation will fail.</para>
+
+        <para>If the <varname>User=</varname> setting is used the supplementary group list is initialized
+        from the specified user's default group list, as defined in the system's user and group
+        database. Additional groups may be configured through the <varname>SupplementaryGroups=</varname>
+        setting (see below).</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>DynamicUser=</varname></term>
+
+        <listitem><para>Takes a boolean parameter. If set, a UNIX user and group pair is allocated
+        dynamically when the unit is started, and released as soon as it is stopped. The user and group will
+        not be added to <filename>/etc/passwd</filename> or <filename>/etc/group</filename>, but are managed
+        transiently during runtime. The
+        <citerefentry><refentrytitle>nss-systemd</refentrytitle><manvolnum>8</manvolnum></citerefentry> glibc
+        NSS module provides integration of these dynamic users/groups into the system's user and group
+        databases. The user and group name to use may be configured via <varname>User=</varname> and
+        <varname>Group=</varname> (see above). If these options are not used and dynamic user/group
+        allocation is enabled for a unit, the name of the dynamic user/group is implicitly derived from the
+        unit name. If the unit name without the type suffix qualifies as valid user name it is used directly,
+        otherwise a name incorporating a hash of it is used. If a statically allocated user or group of the
+        configured name already exists, it is used and no dynamic user/group is allocated. Note that if
+        <varname>User=</varname> is specified and the static group with the name exists, then it is required
+        that the static user with the name already exists. Similarly, if <varname>Group=</varname> is
+        specified and the static user with the name exists, then it is required that the static group with
+        the name already exists. Dynamic users/groups are allocated from the UID/GID range 61184…65519. It is
+        recommended to avoid this range for regular system or login users. At any point in time each UID/GID
+        from this range is only assigned to zero or one dynamically allocated users/groups in use. However,
+        UID/GIDs are recycled after a unit is terminated. Care should be taken that any processes running as
+        part of a unit for which dynamic users/groups are enabled do not leave files or directories owned by
+        these users/groups around, as a different unit might get the same UID/GID assigned later on, and thus
+        gain access to these files or directories. If <varname>DynamicUser=</varname> is enabled,
+        <varname>RemoveIPC=</varname> and <varname>PrivateTmp=</varname> are implied (and cannot be turned
+        off). This ensures that the lifetime of IPC objects and temporary files created by the executed
+        processes is bound to the runtime of the service, and hence the lifetime of the dynamic
+        user/group. Since <filename>/tmp/</filename> and <filename>/var/tmp/</filename> are usually the only
+        world-writable directories on a system this ensures that a unit making use of dynamic user/group
+        allocation cannot leave files around after unit termination. Furthermore
+        <varname>NoNewPrivileges=</varname> and <varname>RestrictSUIDSGID=</varname> are implicitly enabled
+        (and cannot be disabled), to ensure that processes invoked cannot take benefit or create SUID/SGID
+        files or directories. Moreover <varname>ProtectSystem=strict</varname> and
+        <varname>ProtectHome=read-only</varname> are implied, thus prohibiting the service to write to
+        arbitrary file system locations. In order to allow the service to write to certain directories, they
+        have to be allow-listed using <varname>ReadWritePaths=</varname>, but care must be taken so that
+        UID/GID recycling doesn't create security issues involving files created by the service. Use
+        <varname>RuntimeDirectory=</varname> (see below) in order to assign a writable runtime directory to a
+        service, owned by the dynamic user/group and removed automatically when the unit is terminated. Use
+        <varname>StateDirectory=</varname>, <varname>CacheDirectory=</varname> and
+        <varname>LogsDirectory=</varname> in order to assign a set of writable directories for specific
+        purposes to the service in a way that they are protected from vulnerabilities due to UID reuse (see
+        below). If this option is enabled, care should be taken that the unit's processes do not get access
+        to directories outside of these explicitly configured and managed ones. Specifically, do not use
+        <varname>BindPaths=</varname> and be careful with <constant>AF_UNIX</constant> file descriptor
+        passing for directory file descriptors, as this would permit processes to create files or directories
+        owned by the dynamic user/group that are not subject to the lifecycle and access guarantees of the
+        service. Note that this option is currently incompatible with D-Bus policies, thus a service using
+        this option may currently not allocate a D-Bus service name (note that this does not affect calling
+        into other D-Bus services). Defaults to off.</para>
+
+        <xi:include href="version-info.xml" xpointer="v232"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SupplementaryGroups=</varname></term>
+
+        <listitem><para>Sets the supplementary Unix groups the processes are executed as. This takes a space-separated
+        list of group names or IDs. This option may be specified more than once, in which case all listed groups are
+        set as supplementary groups. When the empty string is assigned, the list of supplementary groups is reset, and
+        all assignments prior to this one will have no effect. In any way, this option does not override, but extends
+        the list of supplementary groups configured in the system group database for the user. This does not affect
+        commands prefixed with <literal>+</literal>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SetLoginEnvironment=</varname></term>
+
+        <listitem><para>Takes a boolean parameter that controls whether to set <varname>$HOME</varname>,
+        <varname>$LOGNAME</varname>, and <varname>$SHELL</varname> environment variables. If unset, this is
+        controlled by whether <varname>User=</varname> is set. If true, they will always be set for system services,
+        i.e. even when the default user <literal>root</literal> is used. If false, the mentioned variables are not set
+        by systemd, no matter whether <varname>User=</varname> is used or not. This option normally has no effect
+        on user services, since these variables are typically inherited from user manager's own environment anyway.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>PAMName=</varname></term>
+
+        <listitem><para>Sets the PAM service name to set up a session as. If set, the executed process will be
+        registered as a PAM session under the specified service name. This is only useful in conjunction with the
+        <varname>User=</varname> setting, and is otherwise ignored. If not set, no PAM session will be opened for the
+        executed processes. See <citerefentry
+        project='man-pages'><refentrytitle>pam</refentrytitle><manvolnum>8</manvolnum></citerefentry> for
+        details.</para>
+
+        <para>Note that for each unit making use of this option a PAM session handler process will be maintained as
+        part of the unit and stays around as long as the unit is active, to ensure that appropriate actions can be
+        taken when the unit and hence the PAM session terminates. This process is named <literal>(sd-pam)</literal> and
+        is an immediate child process of the unit's main process.</para>
+
+        <para>Note that when this option is used for a unit it is very likely (depending on PAM configuration) that the
+        main unit process will be migrated to its own session scope unit when it is activated. This process will hence
+        be associated with two units: the unit it was originally started from (and for which
+        <varname>PAMName=</varname> was configured), and the session scope unit. Any child processes of that process
+        will however be associated with the session scope unit only. This has implications when used in combination
+        with <varname>NotifyAccess=</varname><option>all</option>, as these child processes will not be able to affect
+        changes in the original unit through notification messages. These messages will be considered belonging to the
+        session scope unit and not the original unit. It is hence not recommended to use <varname>PAMName=</varname> in
+        combination with <varname>NotifyAccess=</varname><option>all</option>.</para>
+        </listitem>
+      </varlistentry>
+
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Capabilities</title>
+
+    <xi:include href="system-or-user-ns.xml" xpointer="plural"/>
+
+    <variablelist class='unit-directives'>
+
+      <varlistentry>
+        <term><varname>CapabilityBoundingSet=</varname></term>
+
+        <listitem><para>Controls which capabilities to include in the capability bounding set for the
+        executed process. See <citerefentry
+        project='man-pages'><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+        for details. Takes a whitespace-separated list of capability names,
+        e.g. <constant>CAP_SYS_ADMIN</constant>, <constant>CAP_DAC_OVERRIDE</constant>,
+        <constant>CAP_SYS_PTRACE</constant>. Capabilities listed will be included in the bounding set, all
+        others are removed. If the list of capabilities is prefixed with <literal>~</literal>, all but the
+        listed capabilities will be included, the effect of the assignment inverted. Note that this option
+        also affects the respective capabilities in the effective, permitted and inheritable capability
+        sets. If this option is not used, the capability bounding set is not modified on process execution,
+        hence no limits on the capabilities of the process are enforced. This option may appear more than
+        once, in which case the bounding sets are merged by <constant>OR</constant>, or by
+        <constant>AND</constant> if the lines are prefixed with <literal>~</literal> (see below). If the
+        empty string is assigned to this option, the bounding set is reset to the empty capability set, and
+        all prior settings have no effect. If set to <literal>~</literal> (without any further argument),
+        the bounding set is reset to the full set of available capabilities, also undoing any previous
+        settings. This does not affect commands prefixed with <literal>+</literal>.</para>
+
+        <para>Use
+        <citerefentry><refentrytitle>systemd-analyze</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s
+        <command>capability</command> command to retrieve a list of capabilities defined on the local
+        system.</para>
+
+        <para>Example: if a unit has the following,
+        <programlisting>CapabilityBoundingSet=CAP_A CAP_B
+CapabilityBoundingSet=CAP_B CAP_C</programlisting>
+        then <constant index='false'>CAP_A</constant>, <constant index='false'>CAP_B</constant>, and
+        <constant index='false'>CAP_C</constant> are set. If the second line is prefixed with
+        <literal>~</literal>, e.g.,
+        <programlisting>CapabilityBoundingSet=CAP_A CAP_B
+CapabilityBoundingSet=~CAP_B CAP_C</programlisting>
+        then, only <constant index='false'>CAP_A</constant> is set.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>AmbientCapabilities=</varname></term>
+
+        <listitem><para>Controls which capabilities to include in the ambient capability set for the executed
+        process. Takes a whitespace-separated list of capability names, e.g. <constant>CAP_SYS_ADMIN</constant>,
+        <constant>CAP_DAC_OVERRIDE</constant>, <constant>CAP_SYS_PTRACE</constant>. This option may appear more than
+        once, in which case the ambient capability sets are merged (see the above examples in
+        <varname>CapabilityBoundingSet=</varname>). If the list of capabilities is prefixed with <literal>~</literal>,
+        all but the listed capabilities will be included, the effect of the assignment inverted. If the empty string is
+        assigned to this option, the ambient capability set is reset to the empty capability set, and all prior
+        settings have no effect. If set to <literal>~</literal> (without any further argument), the ambient capability
+        set is reset to the full set of available capabilities, also undoing any previous settings. Note that adding
+        capabilities to the ambient capability set adds them to the process's inherited capability set. </para><para>
+        Ambient capability sets are useful if you want to execute a process as a non-privileged user but still want to
+        give it some capabilities. Note that in this case option <constant>keep-caps</constant> is automatically added
+        to <varname>SecureBits=</varname> to retain the capabilities over the user
+        change. <varname>AmbientCapabilities=</varname> does not affect commands prefixed with
+        <literal>+</literal>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v229"/></listitem>
+      </varlistentry>
+
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Security</title>
+
+    <variablelist class='unit-directives'>
+
+      <varlistentry>
+        <term><varname>NoNewPrivileges=</varname></term>
+
+        <listitem><para>Takes a boolean argument. If true, ensures that the service process and all its
+        children can never gain new privileges through <function>execve()</function> (e.g. via setuid or
+        setgid bits, or filesystem capabilities). This is the simplest and most effective way to ensure that
+        a process and its children can never elevate privileges again. Defaults to false. In case the service
+        will be run in a new mount namespace anyway and SELinux is disabled, all file systems are mounted with
+        <constant>MS_NOSUID</constant> flag. Also see <ulink
+        url="https://docs.kernel.org/userspace-api/no_new_privs.html">No New Privileges Flag</ulink>.
+        </para>
+
+        <para>Note that this setting only has an effect on the unit's processes themselves (or any processes
+        directly or indirectly forked off them). It has no effect on processes potentially invoked on request
+        of them through tools such as <citerefentry
+        project='man-pages'><refentrytitle>at</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+        <citerefentry
+        project='man-pages'><refentrytitle>crontab</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd-run</refentrytitle><manvolnum>1</manvolnum></citerefentry>, or
+        arbitrary IPC services.</para>
+
+        <xi:include href="version-info.xml" xpointer="v187"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SecureBits=</varname></term>
+
+        <listitem><para>Controls the secure bits set for the executed process. Takes a space-separated combination of
+        options from the following list: <option>keep-caps</option>, <option>keep-caps-locked</option>,
+        <option>no-setuid-fixup</option>, <option>no-setuid-fixup-locked</option>, <option>noroot</option>, and
+        <option>noroot-locked</option>. This option may appear more than once, in which case the secure bits are
+        ORed. If the empty string is assigned to this option, the bits are reset to 0. This does not affect commands
+        prefixed with <literal>+</literal>. See <citerefentry
+        project='man-pages'><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
+        details.</para></listitem>
+      </varlistentry>
+
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Mandatory Access Control</title>
+
+    <xi:include href="system-only.xml" xpointer="plural"/>
+
+    <variablelist class='unit-directives'>
+
+      <varlistentry>
+        <term><varname>SELinuxContext=</varname></term>
+
+        <listitem><para>Set the SELinux security context of the executed process. If set, this will override the
+        automated domain transition. However, the policy still needs to authorize the transition. This directive is
+        ignored if SELinux is disabled. If prefixed by <literal>-</literal>, failing to set the SELinux
+        security context will be ignored, but it's still possible that the subsequent
+        <function>execve()</function> may fail if the policy doesn't allow the transition for the
+        non-overridden context. This does not affect commands prefixed with <literal>+</literal>. See
+        <citerefentry
+        project='die-net'><refentrytitle>setexeccon</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+        for details.</para>
+
+        <xi:include href="version-info.xml" xpointer="v209"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>AppArmorProfile=</varname></term>
+
+        <listitem><para>Takes a profile name as argument. The process executed by the unit will switch to
+        this profile when started. Profiles must already be loaded in the kernel, or the unit will fail. If
+        prefixed by <literal>-</literal>, all errors will be ignored. This setting has no effect if AppArmor
+        is not enabled. This setting does not affect commands prefixed with <literal>+</literal>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v210"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SmackProcessLabel=</varname></term>
+
+        <listitem><para>Takes a <option>SMACK64</option> security label as argument. The process executed by the unit
+        will be started under this label and SMACK will decide whether the process is allowed to run or not, based on
+        it. The process will continue to run under the label specified here unless the executable has its own
+        <option>SMACK64EXEC</option> label, in which case the process will transition to run under that label. When not
+        specified, the label that systemd is running under is used. This directive is ignored if SMACK is
+        disabled.</para>
+
+        <para>The value may be prefixed by <literal>-</literal>, in which case all errors will be ignored. An empty
+        value may be specified to unset previous assignments. This does not affect commands prefixed with
+        <literal>+</literal>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v218"/></listitem>
+      </varlistentry>
+
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Process Properties</title>
+
+    <variablelist class='unit-directives'>
+
+      <varlistentry>
+        <term><varname>LimitCPU=</varname></term>
+        <term><varname>LimitFSIZE=</varname></term>
+        <term><varname>LimitDATA=</varname></term>
+        <term><varname>LimitSTACK=</varname></term>
+        <term><varname>LimitCORE=</varname></term>
+        <term><varname>LimitRSS=</varname></term>
+        <term><varname>LimitNOFILE=</varname></term>
+        <term><varname>LimitAS=</varname></term>
+        <term><varname>LimitNPROC=</varname></term>
+        <term><varname>LimitMEMLOCK=</varname></term>
+        <term><varname>LimitLOCKS=</varname></term>
+        <term><varname>LimitSIGPENDING=</varname></term>
+        <term><varname>LimitMSGQUEUE=</varname></term>
+        <term><varname>LimitNICE=</varname></term>
+        <term><varname>LimitRTPRIO=</varname></term>
+        <term><varname>LimitRTTIME=</varname></term>
+
+        <listitem><para>Set soft and hard limits on various resources for executed processes. See
+        <citerefentry><refentrytitle>setrlimit</refentrytitle><manvolnum>2</manvolnum></citerefentry> for
+        details on the process resource limit concept. Process resource limits may be specified in two formats:
+        either as single value to set a specific soft and hard limit to the same value, or as colon-separated
+        pair <option>soft:hard</option> to set both limits individually
+        (e.g. <literal>LimitAS=4G:16G</literal>).  Use the string <option>infinity</option> to configure no
+        limit on a specific resource. The multiplicative suffixes K, M, G, T, P and E (to the base 1024) may
+        be used for resource limits measured in bytes (e.g. <literal>LimitAS=16G</literal>). For the limits
+        referring to time values, the usual time units ms, s, min, h and so on may be used (see
+        <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
+        details). Note that if no time unit is specified for <varname>LimitCPU=</varname> the default unit of
+        seconds is implied, while for <varname>LimitRTTIME=</varname> the default unit of microseconds is
+        implied. Also, note that the effective granularity of the limits might influence their
+        enforcement. For example, time limits specified for <varname>LimitCPU=</varname> will be rounded up
+        implicitly to multiples of 1s. For <varname>LimitNICE=</varname> the value may be specified in two
+        syntaxes: if prefixed with <literal>+</literal> or <literal>-</literal>, the value is understood as
+        regular Linux nice value in the range -20…19. If not prefixed like this the value is understood as
+        raw resource limit parameter in the range 0…40 (with 0 being equivalent to 1).</para>
+
+        <para>Note that most process resource limits configured with these options are per-process, and
+        processes may fork in order to acquire a new set of resources that are accounted independently of the
+        original process, and may thus escape limits set. Also note that <varname>LimitRSS=</varname> is not
+        implemented on Linux, and setting it has no effect. Often it is advisable to prefer the resource
+        controls listed in
+        <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        over these per-process limits, as they apply to services as a whole, may be altered dynamically at
+        runtime, and are generally more expressive. For example, <varname>MemoryMax=</varname> is a more
+        powerful (and working) replacement for <varname>LimitRSS=</varname>.</para>
+
+        <para>Note that <varname>LimitNPROC=</varname> will limit the number of processes from one (real) UID and
+        not the number of processes started (forked) by the service. Therefore the limit is cumulative for all
+        processes running under the same UID. Please also note that the <varname>LimitNPROC=</varname> will not be
+        enforced if the service is running as root (and not dropping privileges). Due to these limitations,
+        <varname>TasksMax=</varname> (see <citerefentry><refentrytitle>systemd.resource-control</refentrytitle>
+        <manvolnum>5</manvolnum></citerefentry>) is typically a better choice than <varname>LimitNPROC=</varname>.
+        </para>
+
+        <para>Resource limits not configured explicitly for a unit default to the value configured in the various
+        <varname>DefaultLimitCPU=</varname>, <varname>DefaultLimitFSIZE=</varname>, … options available in
+        <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>, and –
+        if not configured there – the kernel or per-user defaults, as defined by the OS (the latter only for user
+        services, see below).</para>
+
+        <para>For system units these resource limits may be chosen freely. When these settings are configured
+        in a user service (i.e. a service run by the per-user instance of the service manager) they cannot be
+        used to raise the limits above those set for the user manager itself when it was first invoked, as
+        the user's service manager generally lacks the privileges to do so. In user context these
+        configuration options are hence only useful to lower the limits passed in or to raise the soft limit
+        to the maximum of the hard limit as configured for the user. To raise the user's limits further, the
+        available configuration mechanisms differ between operating systems, but typically require
+        privileges. In most cases it is possible to configure higher per-user resource limits via PAM or by
+        setting limits on the system service encapsulating the user's service manager, i.e. the user's
+        instance of <filename>user@.service</filename>. After making such changes, make sure to restart the
+        user's service manager.</para>
+
+        <table>
+          <title>Resource limit directives, their equivalent <command>ulimit</command> shell commands and the unit used</title>
+
+          <tgroup cols='4'>
+            <colspec colname='directive' />
+            <colspec colname='equivalent' />
+            <colspec colname='unit' />
+            <colspec colname='notes' />
+            <thead>
+              <row>
+                <entry>Directive</entry>
+                <entry><command>ulimit</command> equivalent</entry>
+                <entry>Unit</entry>
+                <entry>Notes</entry>
+              </row>
+            </thead>
+            <tbody>
+              <row>
+                <entry>LimitCPU=</entry>
+                <entry>ulimit -t</entry>
+                <entry>Seconds</entry>
+                <entry>-</entry>
+              </row>
+              <row>
+                <entry>LimitFSIZE=</entry>
+                <entry>ulimit -f</entry>
+                <entry>Bytes</entry>
+                <entry>-</entry>
+              </row>
+              <row>
+                <entry>LimitDATA=</entry>
+                <entry>ulimit -d</entry>
+                <entry>Bytes</entry>
+                <entry>Don't use. This limits the allowed address range, not memory use! Defaults to unlimited and should not be lowered. To limit memory use, see <varname>MemoryMax=</varname> in <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</entry>
+              </row>
+              <row>
+                <entry>LimitSTACK=</entry>
+                <entry>ulimit -s</entry>
+                <entry>Bytes</entry>
+                <entry>-</entry>
+              </row>
+              <row>
+                <entry>LimitCORE=</entry>
+                <entry>ulimit -c</entry>
+                <entry>Bytes</entry>
+                <entry>-</entry>
+              </row>
+              <row>
+                <entry>LimitRSS=</entry>
+                <entry>ulimit -m</entry>
+                <entry>Bytes</entry>
+                <entry>Don't use. No effect on Linux.</entry>
+              </row>
+              <row>
+                <entry>LimitNOFILE=</entry>
+                <entry>ulimit -n</entry>
+                <entry>Number of File Descriptors</entry>
+                <entry>Don't use. Be careful when raising the soft limit above 1024, since <citerefentry project='man-pages'><refentrytitle>select</refentrytitle><manvolnum>2</manvolnum></citerefentry> cannot function with file descriptors above 1023 on Linux. Nowadays, the hard limit defaults to 524288, a very high value compared to historical defaults. Typically applications should increase their soft limit to the hard limit on their own, if they are OK with working with file descriptors above 1023, i.e. do not use <citerefentry project='man-pages'><refentrytitle>select</refentrytitle><manvolnum>2</manvolnum></citerefentry>. Note that file descriptors are nowadays accounted like any other form of memory, thus there should not be any need to lower the hard limit. Use <varname>MemoryMax=</varname> to control overall service memory use, including file descriptor memory.</entry>
+              </row>
+              <row>
+                <entry>LimitAS=</entry>
+                <entry>ulimit -v</entry>
+                <entry>Bytes</entry>
+                <entry>Don't use. This limits the allowed address range, not memory use! Defaults to unlimited and should not be lowered. To limit memory use, see <varname>MemoryMax=</varname> in <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</entry>
+              </row>
+              <row>
+                <entry>LimitNPROC=</entry>
+                <entry>ulimit -u</entry>
+                <entry>Number of Processes</entry>
+                <entry>This limit is enforced based on the number of processes belonging to the user. Typically it's better to track processes per service, i.e. use <varname>TasksMax=</varname>, see <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</entry>
+              </row>
+              <row>
+                <entry>LimitMEMLOCK=</entry>
+                <entry>ulimit -l</entry>
+                <entry>Bytes</entry>
+                <entry>-</entry>
+              </row>
+              <row>
+                <entry>LimitLOCKS=</entry>
+                <entry>ulimit -x</entry>
+                <entry>Number of Locks</entry>
+                <entry>-</entry>
+              </row>
+              <row>
+                <entry>LimitSIGPENDING=</entry>
+                <entry>ulimit -i</entry>
+                <entry>Number of Queued Signals</entry>
+                <entry>-</entry>
+              </row>
+              <row>
+                <entry>LimitMSGQUEUE=</entry>
+                <entry>ulimit -q</entry>
+                <entry>Bytes</entry>
+                <entry>-</entry>
+              </row>
+              <row>
+                <entry>LimitNICE=</entry>
+                <entry>ulimit -e</entry>
+                <entry>Nice Level</entry>
+                <entry>-</entry>
+              </row>
+              <row>
+                <entry>LimitRTPRIO=</entry>
+                <entry>ulimit -r</entry>
+                <entry>Realtime Priority</entry>
+                <entry>-</entry>
+              </row>
+              <row>
+                <entry>LimitRTTIME=</entry>
+                <entry>ulimit -R</entry>
+                <entry>Microseconds</entry>
+                <entry>-</entry>
+              </row>
+            </tbody>
+          </tgroup>
+        </table></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>UMask=</varname></term>
+
+        <listitem><para>Controls the file mode creation mask. Takes an access mode in octal notation. See
+        <citerefentry><refentrytitle>umask</refentrytitle><manvolnum>2</manvolnum></citerefentry> for
+        details. Defaults to 0022 for system units. For user units the default value is inherited from the
+        per-user service manager (whose default is in turn inherited from the system service manager, and
+        thus typically also is 0022 — unless overridden by a PAM module). In order to change the per-user mask
+        for all user services, consider setting the <varname>UMask=</varname> setting of the user's
+        <filename>user@.service</filename> system service instance. The per-user umask may also be set via
+        the <varname>umask</varname> field of a user's <ulink url="https://systemd.io/USER_RECORD">JSON User
+        Record</ulink> (for users managed by
+        <citerefentry><refentrytitle>systemd-homed.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        this field may be controlled via <command>homectl --umask=</command>). It may also be set via a PAM
+        module, such as <citerefentry
+        project='man-pages'><refentrytitle>pam_umask</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>CoredumpFilter=</varname></term>
+
+        <listitem><para>Controls which types of memory mappings will be saved if the process dumps core
+        (using the <filename>/proc/<replaceable>pid</replaceable>/coredump_filter</filename> file). Takes a
+        whitespace-separated combination of mapping type names or numbers (with the default base 16). Mapping
+        type names are <constant>private-anonymous</constant>, <constant>shared-anonymous</constant>,
+        <constant>private-file-backed</constant>, <constant>shared-file-backed</constant>,
+        <constant>elf-headers</constant>, <constant>private-huge</constant>,
+        <constant>shared-huge</constant>, <constant>private-dax</constant>, <constant>shared-dax</constant>,
+        and the special values <constant>all</constant> (all types) and <constant>default</constant> (the
+        kernel default of <literal><constant>private-anonymous</constant>
+        <constant>shared-anonymous</constant> <constant>elf-headers</constant>
+        <constant>private-huge</constant></literal>). See
+        <citerefentry project='man-pages'><refentrytitle>core</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for the meaning of the mapping types. When specified multiple times, all specified masks are
+        ORed. When not set, or if the empty value is assigned, the inherited value is not changed.</para>
+
+        <example>
+          <title>Add DAX pages to the dump filter</title>
+
+          <programlisting>CoredumpFilter=default private-dax shared-dax</programlisting>
+        </example>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>KeyringMode=</varname></term>
+
+        <listitem><para>Controls how the kernel session keyring is set up for the service (see <citerefentry
+        project='man-pages'><refentrytitle>session-keyring</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
+        details on the session keyring). Takes one of <option>inherit</option>, <option>private</option>,
+        <option>shared</option>. If set to <option>inherit</option> no special keyring setup is done, and the kernel's
+        default behaviour is applied. If <option>private</option> is used a new session keyring is allocated when a
+        service process is invoked, and it is not linked up with any user keyring. This is the recommended setting for
+        system services, as this ensures that multiple services running under the same system user ID (in particular
+        the root user) do not share their key material among each other. If <option>shared</option> is used a new
+        session keyring is allocated as for <option>private</option>, but the user keyring of the user configured with
+        <varname>User=</varname> is linked into it, so that keys assigned to the user may be requested by the unit's
+        processes. In this mode multiple units running processes under the same user ID may share key material. Unless
+        <option>inherit</option> is selected the unique invocation ID for the unit (see below) is added as a protected
+        key by the name <literal>invocation_id</literal> to the newly created session keyring. Defaults to
+        <option>private</option> for services of the system service manager and to <option>inherit</option> for
+        non-service units and for services of the user service manager.</para>
+
+        <xi:include href="version-info.xml" xpointer="v235"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>OOMScoreAdjust=</varname></term>
+
+        <listitem><para>Sets the adjustment value for the Linux kernel's Out-Of-Memory (OOM) killer score for
+        executed processes. Takes an integer between -1000 (to disable OOM killing of processes of this unit)
+        and 1000 (to make killing of processes of this unit under memory pressure very likely). See <ulink
+        url="https://docs.kernel.org/filesystems/proc.html">The /proc Filesystem</ulink> for
+        details. If not specified defaults to the OOM score adjustment level of the service manager itself,
+        which is normally at 0.</para>
+
+        <para>Use the <varname>OOMPolicy=</varname> setting of service units to configure how the service
+        manager shall react to the kernel OOM killer or <command>systemd-oomd</command> terminating a process of the service. See
+        <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for details.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>TimerSlackNSec=</varname></term>
+        <listitem><para>Sets the timer slack in nanoseconds for the executed processes. The timer slack controls the
+        accuracy of wake-ups triggered by timers. See
+        <citerefentry><refentrytitle>prctl</refentrytitle><manvolnum>2</manvolnum></citerefentry> for more
+        information. Note that in contrast to most other time span definitions this parameter takes an integer value in
+        nano-seconds if no unit is specified. The usual time units are understood too.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Personality=</varname></term>
+
+        <listitem><para>Controls which kernel architecture <citerefentry
+        project='man-pages'><refentrytitle>uname</refentrytitle><manvolnum>2</manvolnum></citerefentry> shall
+        report, when invoked by unit processes. Takes one of the architecture identifiers
+        <constant>arm64</constant>, <constant>arm64-be</constant>, <constant>arm</constant>,
+        <constant>arm-be</constant>, <constant>x86</constant>, <constant>x86-64</constant>,
+        <constant>ppc</constant>, <constant>ppc-le</constant>, <constant>ppc64</constant>,
+        <constant>ppc64-le</constant>, <constant>s390</constant> or <constant>s390x</constant>. Which
+        personality architectures are supported depends on the kernel's native architecture. Usually the
+        64-bit versions of the various system architectures support their immediate 32-bit personality
+        architecture counterpart, but no others. For example, <constant>x86-64</constant> systems support the
+        <constant>x86-64</constant> and <constant>x86</constant> personalities but no others. The personality
+        feature is useful when running 32-bit services on a 64-bit host system. If not specified, the
+        personality is left unmodified and thus reflects the personality of the host system's kernel. This
+        option is not useful on architectures for which only one native word width was ever available, such
+        as <constant>m68k</constant> (32-bit only) or <constant>alpha</constant> (64-bit only).</para>
+
+        <xi:include href="version-info.xml" xpointer="v209"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>IgnoreSIGPIPE=</varname></term>
+
+        <listitem><para>Takes a boolean argument. If true, <constant>SIGPIPE</constant> is ignored in the
+        executed process. Defaults to true since <constant>SIGPIPE</constant> is generally only useful in
+        shell pipelines.</para></listitem>
+      </varlistentry>
+
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Scheduling</title>
+
+    <variablelist class='unit-directives'>
+
+      <varlistentry>
+        <term><varname>Nice=</varname></term>
+
+        <listitem><para>Sets the default nice level (scheduling priority) for executed processes. Takes an
+        integer between -20 (highest priority) and 19 (lowest priority). In case of resource contention,
+        smaller values mean more resources will be made available to the unit's processes, larger values mean
+        less resources will be made available. See
+        <citerefentry><refentrytitle>setpriority</refentrytitle><manvolnum>2</manvolnum></citerefentry> for
+        details.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>CPUSchedulingPolicy=</varname></term>
+
+        <listitem><para>Sets the CPU scheduling policy for executed processes. Takes one of <option>other</option>,
+        <option>batch</option>, <option>idle</option>, <option>fifo</option> or <option>rr</option>. See
+        <citerefentry project='man-pages'><refentrytitle>sched_setscheduler</refentrytitle><manvolnum>2</manvolnum></citerefentry> for
+        details.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>CPUSchedulingPriority=</varname></term>
+
+        <listitem><para>Sets the CPU scheduling priority for executed processes. The available priority range
+        depends on the selected CPU scheduling policy (see above). For real-time scheduling policies an
+        integer between 1 (lowest priority) and 99 (highest priority) can be used. In case of CPU resource
+        contention, smaller values mean less CPU time is made available to the service, larger values mean
+        more. See <citerefentry
+        project='man-pages'><refentrytitle>sched_setscheduler</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+        for details. </para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>CPUSchedulingResetOnFork=</varname></term>
+
+        <listitem><para>Takes a boolean argument. If true, elevated CPU scheduling priorities and policies
+        will be reset when the executed processes call
+        <citerefentry project='man-pages'><refentrytitle>fork</refentrytitle><manvolnum>2</manvolnum></citerefentry>,
+        and can hence not leak into child processes. See
+        <citerefentry project='man-pages'><refentrytitle>sched_setscheduler</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+        for details. Defaults to false.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>CPUAffinity=</varname></term>
+
+        <listitem><para>Controls the CPU affinity of the executed processes. Takes a list of CPU indices or ranges
+        separated by either whitespace or commas. Alternatively, takes a special "numa" value in which case systemd
+        automatically derives allowed CPU range based on the value of <varname>NUMAMask=</varname> option. CPU ranges
+        are specified by the lower and upper CPU indices separated by a dash. This option may be specified more than
+        once, in which case the specified CPU affinity masks are merged. If the empty string is assigned, the mask
+        is reset, all assignments prior to this will have no effect. See
+        <citerefentry project='man-pages'><refentrytitle>sched_setaffinity</refentrytitle><manvolnum>2</manvolnum></citerefentry> for
+        details.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>NUMAPolicy=</varname></term>
+
+        <listitem><para>Controls the NUMA memory policy of the executed processes. Takes a policy type, one of:
+        <option>default</option>, <option>preferred</option>, <option>bind</option>, <option>interleave</option> and
+        <option>local</option>. A list of NUMA nodes that should be associated with the policy must be specified
+        in <varname>NUMAMask=</varname>. For more details on each policy please see,
+        <citerefentry><refentrytitle>set_mempolicy</refentrytitle><manvolnum>2</manvolnum></citerefentry>. For overall
+        overview of NUMA support in Linux see,
+        <citerefentry project='man-pages'><refentrytitle>numa</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v243"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>NUMAMask=</varname></term>
+
+        <listitem><para>Controls the NUMA node list which will be applied alongside with selected NUMA policy.
+        Takes a list of NUMA nodes and has the same syntax as a list of CPUs for <varname>CPUAffinity=</varname>
+        option or special "all" value which will include all available NUMA nodes in the mask. Note that the list
+        of NUMA nodes is not required for <option>default</option> and <option>local</option>
+        policies and for <option>preferred</option> policy we expect a single NUMA node.</para>
+
+        <xi:include href="version-info.xml" xpointer="v243"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>IOSchedulingClass=</varname></term>
+
+        <listitem><para>Sets the I/O scheduling class for executed processes. Takes one of the strings
+        <option>realtime</option>, <option>best-effort</option> or <option>idle</option>. The kernel's
+        default scheduling class is <option>best-effort</option> at a priority of 4. If the empty string is
+        assigned to this option, all prior assignments to both <varname>IOSchedulingClass=</varname> and
+        <varname>IOSchedulingPriority=</varname> have no effect. See
+        <citerefentry><refentrytitle>ioprio_set</refentrytitle><manvolnum>2</manvolnum></citerefentry> for
+        details.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>IOSchedulingPriority=</varname></term>
+
+        <listitem><para>Sets the I/O scheduling priority for executed processes. Takes an integer between 0
+        (highest priority) and 7 (lowest priority). In case of I/O contention, smaller values mean more I/O
+        bandwidth is made available to the unit's processes, larger values mean less bandwidth. The available
+        priorities depend on the selected I/O scheduling class (see above). If the empty string is assigned
+        to this option, all prior assignments to both <varname>IOSchedulingClass=</varname> and
+        <varname>IOSchedulingPriority=</varname> have no effect. For the kernel's default scheduling class
+        (<option>best-effort</option>) this defaults to 4. See
+        <citerefentry><refentrytitle>ioprio_set</refentrytitle><manvolnum>2</manvolnum></citerefentry> for
+        details.</para></listitem>
+      </varlistentry>
+
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Sandboxing</title>
+
+    <para>The following sandboxing options are an effective way to limit the exposure of the system towards the unit's
+    processes. It is recommended to turn on as many of these options for each unit as is possible without negatively
+    affecting the process' ability to operate. Note that many of these sandboxing features are gracefully turned off on
+    systems where the underlying security mechanism is not available. For example, <varname>ProtectSystem=</varname>
+    has no effect if the kernel is built without file system namespacing or if the service manager runs in a container
+    manager that makes file system namespacing unavailable to its payload. Similarly,
+    <varname>RestrictRealtime=</varname> has no effect on systems that lack support for SECCOMP system call filtering,
+    or in containers where support for this is turned off.</para>
+
+    <para>Also note that some sandboxing functionality is generally not available in user services (i.e. services run
+    by the per-user service manager). Specifically, the various settings requiring file system namespacing support
+    (such as <varname>ProtectSystem=</varname>) are not available, as the underlying kernel functionality is only
+    accessible to privileged processes. However, most namespacing settings, that will not work on their own in user
+    services, will work when used in conjunction with <varname>PrivateUsers=</varname><option>true</option>.</para>
+
+    <variablelist class='unit-directives'>
+
+      <varlistentry>
+        <term><varname>ProtectSystem=</varname></term>
+
+        <listitem><para>Takes a boolean argument or the special values <literal>full</literal> or
+        <literal>strict</literal>. If true, mounts the <filename>/usr/</filename> and the boot loader
+        directories (<filename>/boot</filename> and <filename>/efi</filename>) read-only for processes
+        invoked by this unit. If set to <literal>full</literal>, the <filename>/etc/</filename> directory is
+        mounted read-only, too. If set to <literal>strict</literal> the entire file system hierarchy is
+        mounted read-only, except for the API file system subtrees <filename>/dev/</filename>,
+        <filename>/proc/</filename> and <filename>/sys/</filename> (protect these directories using
+        <varname>PrivateDevices=</varname>, <varname>ProtectKernelTunables=</varname>,
+        <varname>ProtectControlGroups=</varname>). This setting ensures that any modification of the vendor-supplied
+        operating system (and optionally its configuration, and local mounts) is prohibited for the service. It is
+        recommended to enable this setting for all long-running services, unless they are involved with system updates
+        or need to modify the operating system in other ways. If this option is used,
+        <varname>ReadWritePaths=</varname> may be used to exclude specific directories from being made read-only. This
+        setting is implied if <varname>DynamicUser=</varname> is set. This setting cannot ensure protection in all
+        cases. In general it has the same limitations as <varname>ReadOnlyPaths=</varname>, see below. Defaults to
+        off.</para>
+
+        <xi:include href="version-info.xml" xpointer="v214"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ProtectHome=</varname></term>
+
+        <listitem><para>Takes a boolean argument or the special values <literal>read-only</literal> or
+        <literal>tmpfs</literal>. If true, the directories <filename>/home/</filename>,
+        <filename>/root</filename>, and <filename>/run/user</filename> are made inaccessible and empty for
+        processes invoked by this unit. If set to <literal>read-only</literal>, the three directories are
+        made read-only instead. If set to <literal>tmpfs</literal>, temporary file systems are mounted on the
+        three directories in read-only mode. The value <literal>tmpfs</literal> is useful to hide home
+        directories not relevant to the processes invoked by the unit, while still allowing necessary
+        directories to be made visible when listed in <varname>BindPaths=</varname> or
+        <varname>BindReadOnlyPaths=</varname>.</para>
+
+        <para>Setting this to <literal>yes</literal> is mostly equivalent to setting the three directories in
+        <varname>InaccessiblePaths=</varname>. Similarly, <literal>read-only</literal> is mostly equivalent to
+        <varname>ReadOnlyPaths=</varname>, and <literal>tmpfs</literal> is mostly equivalent to
+        <varname>TemporaryFileSystem=</varname> with <literal>:ro</literal>.</para>
+
+        <para>It is recommended to enable this setting for all long-running services (in particular
+        network-facing ones), to ensure they cannot get access to private user data, unless the services
+        actually require access to the user's private data. This setting is implied if
+        <varname>DynamicUser=</varname> is set. This setting cannot ensure protection in all cases. In
+        general it has the same limitations as <varname>ReadOnlyPaths=</varname>, see below.</para>
+
+        <xi:include href="system-or-user-ns.xml" xpointer="singular"/>
+
+        <xi:include href="version-info.xml" xpointer="v214"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RuntimeDirectory=</varname></term>
+        <term><varname>StateDirectory=</varname></term>
+        <term><varname>CacheDirectory=</varname></term>
+        <term><varname>LogsDirectory=</varname></term>
+        <term><varname>ConfigurationDirectory=</varname></term>
+
+        <listitem><para>These options take a whitespace-separated list of directory names. The specified
+        directory names must be relative, and may not include <literal>..</literal>. If set, when the unit is
+        started, one or more directories by the specified names will be created (including their parents)
+        below the locations defined in the following table. Also, the corresponding environment variable will
+        be defined with the full paths of the directories. If multiple directories are set, then in the
+        environment variable the paths are concatenated with colon (<literal>:</literal>).</para>
+        <table>
+          <title>Automatic directory creation and environment variables</title>
+          <tgroup cols='4'>
+            <thead>
+              <row>
+                <entry>Directory</entry>
+                <entry>Below path for system units</entry>
+                <entry>Below path for user units</entry>
+                <entry>Environment variable set</entry>
+              </row>
+            </thead>
+            <tbody>
+              <row>
+                <entry><varname>RuntimeDirectory=</varname></entry>
+                <entry><filename>/run/</filename></entry>
+                <entry><varname>$XDG_RUNTIME_DIR</varname></entry>
+                <entry><varname>$RUNTIME_DIRECTORY</varname></entry>
+              </row>
+              <row>
+                <entry><varname>StateDirectory=</varname></entry>
+                <entry><filename>/var/lib/</filename></entry>
+                <entry><varname>$XDG_STATE_HOME</varname></entry>
+                <entry><varname>$STATE_DIRECTORY</varname></entry>
+              </row>
+              <row>
+                <entry><varname>CacheDirectory=</varname></entry>
+                <entry><filename>/var/cache/</filename></entry>
+                <entry><varname>$XDG_CACHE_HOME</varname></entry>
+                <entry><varname>$CACHE_DIRECTORY</varname></entry>
+              </row>
+              <row>
+                <entry><varname>LogsDirectory=</varname></entry>
+                <entry><filename>/var/log/</filename></entry>
+                <entry><varname>$XDG_STATE_HOME</varname><filename>/log/</filename></entry>
+                <entry><varname>$LOGS_DIRECTORY</varname></entry>
+              </row>
+              <row>
+                <entry><varname>ConfigurationDirectory=</varname></entry>
+                <entry><filename>/etc/</filename></entry>
+                <entry><varname>$XDG_CONFIG_HOME</varname></entry>
+                <entry><varname>$CONFIGURATION_DIRECTORY</varname></entry>
+              </row>
+            </tbody>
+          </tgroup>
+        </table>
+
+        <para>In case of <varname>RuntimeDirectory=</varname> the innermost subdirectories are removed when
+        the unit is stopped. It is possible to preserve the specified directories in this case if
+        <varname>RuntimeDirectoryPreserve=</varname> is configured to <option>restart</option> or
+        <option>yes</option> (see below). The directories specified with <varname>StateDirectory=</varname>,
+        <varname>CacheDirectory=</varname>, <varname>LogsDirectory=</varname>,
+        <varname>ConfigurationDirectory=</varname> are not removed when the unit is stopped.</para>
+
+        <para>Except in case of <varname>ConfigurationDirectory=</varname>, the innermost specified directories will be
+        owned by the user and group specified in <varname>User=</varname> and <varname>Group=</varname>. If the
+        specified directories already exist and their owning user or group do not match the configured ones, all files
+        and directories below the specified directories as well as the directories themselves will have their file
+        ownership recursively changed to match what is configured. As an optimization, if the specified directories are
+        already owned by the right user and group, files and directories below of them are left as-is, even if they do
+        not match what is requested. The innermost specified directories will have their access mode adjusted to the
+        what is specified in <varname>RuntimeDirectoryMode=</varname>, <varname>StateDirectoryMode=</varname>,
+        <varname>CacheDirectoryMode=</varname>, <varname>LogsDirectoryMode=</varname> and
+        <varname>ConfigurationDirectoryMode=</varname>.</para>
+
+        <para>These options imply <varname>BindPaths=</varname> for the specified paths. When combined with
+        <varname>RootDirectory=</varname> or <varname>RootImage=</varname> these paths always reside on the host and
+        are mounted from there into the unit's file system namespace.</para>
+
+        <para>If <varname>DynamicUser=</varname> is used, the logic for <varname>CacheDirectory=</varname>,
+        <varname>LogsDirectory=</varname> and <varname>StateDirectory=</varname> is slightly altered: the directories are created below
+        <filename>/var/cache/private</filename>, <filename>/var/log/private</filename> and <filename>/var/lib/private</filename>,
+        respectively, which are host directories made inaccessible to
+        unprivileged users, which ensures that access to these directories cannot be gained through dynamic
+        user ID recycling. Symbolic links are created to hide this difference in behaviour. Both from
+        perspective of the host and from inside the unit, the relevant directories hence always appear
+        directly below <filename>/var/cache</filename>, <filename>/var/log</filename> and
+        <filename>/var/lib</filename>.</para>
+
+        <para>Use <varname>RuntimeDirectory=</varname> to manage one or more runtime directories for the unit and bind
+        their lifetime to the daemon runtime. This is particularly useful for unprivileged daemons that cannot create
+        runtime directories in <filename>/run/</filename> due to lack of privileges, and to make sure the runtime
+        directory is cleaned up automatically after use. For runtime directories that require more complex or different
+        configuration or lifetime guarantees, please consider using
+        <citerefentry><refentrytitle>tmpfiles.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+
+        <para><varname>RuntimeDirectory=</varname>, <varname>StateDirectory=</varname>, <varname>CacheDirectory=</varname>
+        and <varname>LogsDirectory=</varname>  optionally support a second parameter, separated by <literal>:</literal>.
+        The second parameter will be interpreted as a destination path that will be created as a symlink to the directory.
+        The symlinks will be created after any <varname>BindPaths=</varname> or <varname>TemporaryFileSystem=</varname>
+        options have been set up, to make ephemeral symlinking possible. The same source can have multiple symlinks, by
+        using the same first parameter, but a different second parameter.</para>
+
+        <para>The directories defined by these options are always created under the standard paths used by systemd
+        (<filename>/var/</filename>, <filename>/run/</filename>, <filename>/etc/</filename>, …). If the service needs
+        directories in a different location, a different mechanism has to be used to create them.</para>
+
+        <para><citerefentry><refentrytitle>tmpfiles.d</refentrytitle><manvolnum>5</manvolnum></citerefentry> provides
+        functionality that overlaps with these options. Using these options is recommended, because the lifetime of
+        the directories is tied directly to the lifetime of the unit, and it is not necessary to ensure that the
+        <filename>tmpfiles.d</filename> configuration is executed before the unit is started.</para>
+
+        <para>To remove any of the directories created by these settings, use the <command>systemctl clean
+        …</command> command on the relevant units, see
+        <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> for
+        details.</para>
+
+        <para>Example: if a system service unit has the following,
+        <programlisting>RuntimeDirectory=foo/bar baz</programlisting>
+        the service manager creates <filename index='false'>/run/foo</filename> (if it does not exist),
+
+        <filename index='false'>/run/foo/bar</filename>, and <filename index='false'>/run/baz</filename>. The
+        directories <filename index='false'>/run/foo/bar</filename> and
+        <filename index='false'>/run/baz</filename> except <filename index='false'>/run/foo</filename> are
+        owned by the user and group specified in <varname>User=</varname> and <varname>Group=</varname>, and removed
+        when the service is stopped.</para>
+
+        <para>Example: if a system service unit has the following,
+        <programlisting>RuntimeDirectory=foo/bar
+StateDirectory=aaa/bbb ccc</programlisting>
+        then the environment variable <literal>RUNTIME_DIRECTORY</literal> is set with <literal>/run/foo/bar</literal>, and
+        <literal>STATE_DIRECTORY</literal> is set with <literal>/var/lib/aaa/bbb:/var/lib/ccc</literal>.</para>
+
+        <para>Example: if a system service unit has the following,
+        <programlisting>RuntimeDirectory=foo:bar foo:baz</programlisting>
+        the service manager creates <filename index='false'>/run/foo</filename> (if it does not exist), and
+        <filename index='false'>/run/bar</filename> plus <filename index='false'>/run/baz</filename> as symlinks to
+        <filename index='false'>/run/foo</filename>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v211"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RuntimeDirectoryMode=</varname></term>
+        <term><varname>StateDirectoryMode=</varname></term>
+        <term><varname>CacheDirectoryMode=</varname></term>
+        <term><varname>LogsDirectoryMode=</varname></term>
+        <term><varname>ConfigurationDirectoryMode=</varname></term>
+
+        <listitem><para>Specifies the access mode of the directories specified in <varname>RuntimeDirectory=</varname>,
+        <varname>StateDirectory=</varname>, <varname>CacheDirectory=</varname>, <varname>LogsDirectory=</varname>, or
+        <varname>ConfigurationDirectory=</varname>, respectively, as an octal number. Defaults to
+        <constant>0755</constant>. See "Permissions" in <citerefentry
+        project='man-pages'><refentrytitle>path_resolution</refentrytitle><manvolnum>7</manvolnum></citerefentry> for a
+        discussion of the meaning of permission bits.</para>
+
+        <xi:include href="version-info.xml" xpointer="v234"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RuntimeDirectoryPreserve=</varname></term>
+
+        <listitem><para>Takes a boolean argument or <option>restart</option>. If set to <option>no</option> (the
+        default), the directories specified in <varname>RuntimeDirectory=</varname> are always removed when the service
+        stops. If set to <option>restart</option> the directories are preserved when the service is both automatically
+        and manually restarted. Here, the automatic restart means the operation specified in
+        <varname>Restart=</varname>, and manual restart means the one triggered by <command>systemctl restart
+        foo.service</command>. If set to <option>yes</option>, then the directories are not removed when the service is
+        stopped. Note that since the runtime directory <filename>/run/</filename> is a mount point of
+        <literal>tmpfs</literal>, then for system services the directories specified in
+        <varname>RuntimeDirectory=</varname> are removed when the system is rebooted.</para>
+
+        <xi:include href="version-info.xml" xpointer="v235"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>TimeoutCleanSec=</varname></term>
+        <listitem><para>Configures a timeout on the clean-up operation requested through <command>systemctl
+        clean …</command>, see
+        <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> for
+        details. Takes the usual time values and defaults to <constant>infinity</constant>, i.e. by default
+        no timeout is applied. If a timeout is configured the clean operation will be aborted forcibly when
+        the timeout is reached, potentially leaving resources on disk.</para>
+
+        <xi:include href="version-info.xml" xpointer="v244"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ReadWritePaths=</varname></term>
+        <term><varname>ReadOnlyPaths=</varname></term>
+        <term><varname>InaccessiblePaths=</varname></term>
+        <term><varname>ExecPaths=</varname></term>
+        <term><varname>NoExecPaths=</varname></term>
+
+        <listitem><para>Sets up a new file system namespace for executed processes. These options may be used
+        to limit access a process has to the file system. Each setting takes a space-separated list of paths
+        relative to the host's root directory (i.e. the system running the service manager). Note that if
+        paths contain symlinks, they are resolved relative to the root directory set with
+        <varname>RootDirectory=</varname>/<varname>RootImage=</varname>.</para>
+
+        <para>Paths listed in <varname>ReadWritePaths=</varname> are accessible from within the namespace
+        with the same access modes as from outside of it. Paths listed in <varname>ReadOnlyPaths=</varname>
+        are accessible for reading only, writing will be refused even if the usual file access controls would
+        permit this. Nest <varname>ReadWritePaths=</varname> inside of <varname>ReadOnlyPaths=</varname> in
+        order to provide writable subdirectories within read-only directories. Use
+        <varname>ReadWritePaths=</varname> in order to allow-list specific paths for write access if
+        <varname>ProtectSystem=strict</varname> is used. Note that <varname>ReadWritePaths=</varname> cannot
+        be used to gain write access to a file system whose superblock is mounted read-only. On Linux, for
+        each mount point write access is granted only if the mount point itself <emphasis>and</emphasis> the
+        file system superblock backing it are not marked read-only. <varname>ReadWritePaths=</varname> only
+        controls the former, not the latter, hence a read-only file system superblock remains
+        protected.</para>
+
+        <para>Paths listed in <varname>InaccessiblePaths=</varname> will be made inaccessible for processes inside
+        the namespace along with everything below them in the file system hierarchy. This may be more restrictive than
+        desired, because it is not possible to nest <varname>ReadWritePaths=</varname>, <varname>ReadOnlyPaths=</varname>,
+        <varname>BindPaths=</varname>, or <varname>BindReadOnlyPaths=</varname> inside it. For a more flexible option,
+        see <varname>TemporaryFileSystem=</varname>.</para>
+
+        <para>Content in paths listed in <varname>NoExecPaths=</varname> are not executable even if the usual
+        file access controls would permit this. Nest <varname>ExecPaths=</varname> inside of
+        <varname>NoExecPaths=</varname> in order to provide executable content within non-executable
+        directories.</para>
+
+        <para>Non-directory paths may be specified as well. These options may be specified more than once,
+        in which case all paths listed will have limited access from within the namespace. If the empty string is
+        assigned to this option, the specific list is reset, and all prior assignments have no effect.</para>
+
+        <para>Paths in <varname>ReadWritePaths=</varname>, <varname>ReadOnlyPaths=</varname>,
+        <varname>InaccessiblePaths=</varname>, <varname>ExecPaths=</varname> and
+        <varname>NoExecPaths=</varname> may be prefixed with <literal>-</literal>, in which case they will be
+        ignored when they do not exist. If prefixed with <literal>+</literal> the paths are taken relative to the root
+        directory of the unit, as configured with <varname>RootDirectory=</varname>/<varname>RootImage=</varname>,
+        instead of relative to the root directory of the host (see above). When combining <literal>-</literal> and
+        <literal>+</literal> on the same path make sure to specify <literal>-</literal> first, and <literal>+</literal>
+        second.</para>
+
+        <para>Note that these settings will disconnect propagation of mounts from the unit's processes to the
+        host. This means that this setting may not be used for services which shall be able to install mount points in
+        the main mount namespace. For <varname>ReadWritePaths=</varname> and <varname>ReadOnlyPaths=</varname>,
+        propagation in the other direction is not affected, i.e. mounts created on the host generally appear in the
+        unit processes' namespace, and mounts removed on the host also disappear there too. In particular, note that
+        mount propagation from host to unit will result in unmodified mounts to be created in the unit's namespace,
+        i.e. writable mounts appearing on the host will be writable in the unit's namespace too, even when propagated
+        below a path marked with <varname>ReadOnlyPaths=</varname>! Restricting access with these options hence does
+        not extend to submounts of a directory that are created later on. This means the lock-down offered by that
+        setting is not complete, and does not offer full protection.</para>
+
+        <para>Note that the effect of these settings may be undone by privileged processes. In order to set up an
+        effective sandboxed environment for a unit it is thus recommended to combine these settings with either
+        <varname>CapabilityBoundingSet=~CAP_SYS_ADMIN</varname> or <varname>SystemCallFilter=~@mount</varname>.</para>
+
+        <para>Please be extra careful when applying these options to API file systems (a list of them could be
+        found in <varname>MountAPIVPS=</varname>), since they may be required for basic system functionalities.
+        Moreover, <filename>/run/</filename> needs to be writable for setting up mount namespace and propagation.</para>
+
+        <para>Simple allow-list example using these directives:
+        <programlisting>[Service]
+ReadOnlyPaths=/
+ReadWritePaths=/var /run
+InaccessiblePaths=-/lost+found
+NoExecPaths=/
+ExecPaths=/usr/sbin/my_daemon /usr/lib /usr/lib64
+</programlisting></para>
+
+        <xi:include href="system-or-user-ns.xml" xpointer="plural"/>
+
+        <xi:include href="version-info.xml" xpointer="v231"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>TemporaryFileSystem=</varname></term>
+
+        <listitem><para>Takes a space-separated list of mount points for temporary file systems (tmpfs). If set, a new file
+        system namespace is set up for executed processes, and a temporary file system is mounted on each mount point.
+        This option may be specified more than once, in which case temporary file systems are mounted on all listed mount
+        points. If the empty string is assigned to this option, the list is reset, and all prior assignments have no effect.
+        Each mount point may optionally be suffixed with a colon (<literal>:</literal>) and mount options such as
+        <literal>size=10%</literal> or <literal>ro</literal>. By default, each temporary file system is mounted
+        with <literal>nodev,strictatime,mode=0755</literal>. These can be disabled by explicitly specifying the corresponding
+        mount options, e.g., <literal>dev</literal> or <literal>nostrictatime</literal>.</para>
+
+        <para>This is useful to hide files or directories not relevant to the processes invoked by the unit, while necessary
+        files or directories can be still accessed by combining with <varname>BindPaths=</varname> or
+        <varname>BindReadOnlyPaths=</varname>:</para>
+
+        <para>Example: if a unit has the following,
+        <programlisting>TemporaryFileSystem=/var:ro
+BindReadOnlyPaths=/var/lib/systemd</programlisting>
+        then the invoked processes by the unit cannot see any files or directories under <filename>/var/</filename> except for
+        <filename>/var/lib/systemd</filename> or its contents.</para>
+
+        <xi:include href="system-or-user-ns.xml" xpointer="singular"/>
+
+        <xi:include href="version-info.xml" xpointer="v238"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>PrivateTmp=</varname></term>
+
+        <listitem><para>Takes a boolean argument. If true, sets up a new file system namespace for the
+        executed processes and mounts private <filename>/tmp/</filename> and <filename>/var/tmp/</filename>
+        directories inside it that are not shared by processes outside of the namespace. This is useful to
+        secure access to temporary files of the process, but makes sharing between processes via
+        <filename>/tmp/</filename> or <filename>/var/tmp/</filename> impossible. If true, all temporary files
+        created by a service in these directories will be removed after the service is stopped. Defaults to
+        false. It is possible to run two or more units within the same private <filename>/tmp/</filename> and
+        <filename>/var/tmp/</filename> namespace by using the <varname>JoinsNamespaceOf=</varname> directive,
+        see <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for details. This setting is implied if <varname>DynamicUser=</varname> is set. For this setting, the
+        same restrictions regarding mount propagation and privileges apply as for
+        <varname>ReadOnlyPaths=</varname> and related calls, see above. Enabling this setting has the side
+        effect of adding <varname>Requires=</varname> and <varname>After=</varname> dependencies on all mount
+        units necessary to access <filename>/tmp/</filename> and <filename>/var/tmp/</filename>. Moreover an
+        implicitly <varname>After=</varname> ordering on
+        <citerefentry><refentrytitle>systemd-tmpfiles-setup.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        is added.</para>
+
+        <para>Note that the implementation of this setting might be impossible (for example if mount namespaces are not
+        available), and the unit should be written in a way that does not solely rely on this setting for
+        security.</para>
+
+        <xi:include href="system-or-user-ns.xml" xpointer="singular"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>PrivateDevices=</varname></term>
+
+        <listitem><para>Takes a boolean argument. If true, sets up a new <filename>/dev/</filename> mount for
+        the executed processes and only adds API pseudo devices such as <filename>/dev/null</filename>,
+        <filename>/dev/zero</filename> or <filename>/dev/random</filename> (as well as the pseudo TTY
+        subsystem) to it, but no physical devices such as <filename>/dev/sda</filename>, system memory
+        <filename>/dev/mem</filename>, system ports <filename>/dev/port</filename> and others. This is useful
+        to turn off physical device access by the executed process. Defaults to false.</para>
+
+        <para>Enabling this option will install a system call filter to block low-level I/O system calls that
+        are grouped in the <varname>@raw-io</varname> set, remove <constant>CAP_MKNOD</constant> and
+        <constant>CAP_SYS_RAWIO</constant> from the capability bounding set for the unit, and set
+        <varname>DevicePolicy=closed</varname> (see
+        <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for details). Note that using this setting will disconnect propagation of mounts from the service to
+        the host (propagation in the opposite direction continues to work). This means that this setting may
+        not be used for services which shall be able to install mount points in the main mount namespace. The
+        new <filename>/dev/</filename> will be mounted read-only and 'noexec'. The latter may break old
+        programs which try to set up executable memory by using
+        <citerefentry><refentrytitle>mmap</refentrytitle><manvolnum>2</manvolnum></citerefentry> of
+        <filename>/dev/zero</filename> instead of using <constant>MAP_ANON</constant>. For this setting the
+        same restrictions regarding mount propagation and privileges apply as for
+        <varname>ReadOnlyPaths=</varname> and related calls, see above.</para>
+
+        <para>Note that the implementation of this setting might be impossible (for example if mount
+        namespaces are not available), and the unit should be written in a way that does not solely rely on
+        this setting for security.</para>
+
+        <xi:include href="system-or-user-ns.xml" xpointer="singular"/>
+
+        <para>When access to some but not all devices must be possible, the <varname>DeviceAllow=</varname>
+        setting might be used instead. See
+        <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v209"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>PrivateNetwork=</varname></term>
+
+        <listitem><para>Takes a boolean argument. If true, sets up a new network namespace for the executed processes
+        and configures only the loopback network device <literal>lo</literal> inside it. No other network devices will
+        be available to the executed process. This is useful to turn off network access by the executed process.
+        Defaults to false. It is possible to run two or more units within the same private network namespace by using
+        the <varname>JoinsNamespaceOf=</varname> directive, see
+        <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
+        details. Note that this option will disconnect all socket families from the host, including
+        <constant>AF_NETLINK</constant> and <constant>AF_UNIX</constant>. Effectively, for
+        <constant>AF_NETLINK</constant> this means that device configuration events received from
+        <citerefentry><refentrytitle>systemd-udevd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> are
+        not delivered to the unit's processes. And for <constant>AF_UNIX</constant> this has the effect that
+        <constant>AF_UNIX</constant> sockets in the abstract socket namespace of the host will become unavailable to
+        the unit's processes (however, those located in the file system will continue to be accessible).</para>
+
+        <para>Note that the implementation of this setting might be impossible (for example if network namespaces are
+        not available), and the unit should be written in a way that does not solely rely on this setting for
+        security.</para>
+
+        <para>When this option is enabled, <varname>PrivateMounts=</varname> is implied unless it is
+        explicitly disabled, and <filename>/sys</filename> will be remounted to associate it with the new
+        network namespace.</para>
+
+        <para>When this option is used on a socket unit any sockets bound on behalf of this unit will be
+        bound within a private network namespace. This may be combined with
+        <varname>JoinsNamespaceOf=</varname> to listen on sockets inside of network namespaces of other
+        services.</para>
+
+        <xi:include href="system-or-user-ns.xml" xpointer="singular"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>NetworkNamespacePath=</varname></term>
+
+        <listitem><para>Takes an absolute file system path referring to a Linux network namespace
+        pseudo-file (i.e. a file like <filename>/proc/$PID/ns/net</filename> or a bind mount or symlink to
+        one). When set the invoked processes are added to the network namespace referenced by that path. The
+        path has to point to a valid namespace file at the moment the processes are forked off. If this
+        option is used <varname>PrivateNetwork=</varname> has no effect. If this option is used together with
+        <varname>JoinsNamespaceOf=</varname> then it only has an effect if this unit is started before any of
+        the listed units that have <varname>PrivateNetwork=</varname> or
+        <varname>NetworkNamespacePath=</varname> configured, as otherwise the network namespace of those
+        units is reused.</para>
+
+        <para>When this option is enabled, <varname>PrivateMounts=</varname> is implied unless it is
+        explicitly disabled, and <filename>/sys</filename> will be remounted to associate it with the new
+        network namespace.</para>
+
+        <para>When this option is used on a socket unit any sockets bound on behalf of this unit will be
+        bound within the specified network namespace.</para>
+
+        <xi:include href="system-or-user-ns.xml" xpointer="singular"/>
+
+        <xi:include href="version-info.xml" xpointer="v242"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>PrivateIPC=</varname></term>
+
+        <listitem><para>Takes a boolean argument. If true, sets up a new IPC namespace for the executed processes.
+        Each IPC namespace has its own set of System V IPC identifiers and its own POSIX message queue file system.
+        This is useful to avoid name clash of IPC identifiers. Defaults to false. It is possible to run two or
+        more units within the same private IPC namespace by using the <varname>JoinsNamespaceOf=</varname> directive,
+        see <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
+        details.</para>
+
+        <para>Note that IPC namespacing does not have an effect on
+        <constant>AF_UNIX</constant> sockets, which are the most common
+        form of IPC used on Linux. Instead, <constant>AF_UNIX</constant>
+        sockets in the file system are subject to mount namespacing, and
+        those in the abstract namespace are subject to network namespacing.
+        IPC namespacing only has an effect on SysV IPC (which is mostly
+        legacy) as well as POSIX message queues (for which
+        <constant>AF_UNIX</constant>/<constant>SOCK_SEQPACKET</constant>
+        sockets are typically a better replacement). IPC namespacing also
+        has no effect on POSIX shared memory (which is subject to mount
+        namespacing) either. See
+        <citerefentry project='man-pages'><refentrytitle>ipc_namespaces</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
+        the details.</para>
+
+        <para>Note that the implementation of this setting might be impossible (for example if IPC namespaces are
+        not available), and the unit should be written in a way that does not solely rely on this setting for
+        security.</para>
+
+        <xi:include href="system-or-user-ns.xml" xpointer="singular"/>
+
+        <xi:include href="version-info.xml" xpointer="v248"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>IPCNamespacePath=</varname></term>
+
+        <listitem><para>Takes an absolute file system path referring to a Linux IPC namespace
+        pseudo-file (i.e. a file like <filename>/proc/$PID/ns/ipc</filename> or a bind mount or symlink to
+        one). When set the invoked processes are added to the network namespace referenced by that path. The
+        path has to point to a valid namespace file at the moment the processes are forked off. If this
+        option is used <varname>PrivateIPC=</varname> has no effect. If this option is used together with
+        <varname>JoinsNamespaceOf=</varname> then it only has an effect if this unit is started before any of
+        the listed units that have <varname>PrivateIPC=</varname> or
+        <varname>IPCNamespacePath=</varname> configured, as otherwise the network namespace of those
+        units is reused.</para>
+
+        <xi:include href="system-or-user-ns.xml" xpointer="singular"/>
+
+        <xi:include href="version-info.xml" xpointer="v248"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>MemoryKSM=</varname></term>
+
+        <listitem><para>Takes a boolean argument. When set, it enables KSM (kernel samepage merging) for
+        the processes. KSM is a memory-saving de-duplication feature. Anonymous memory pages with identical
+        content can be replaced by a single write-protected page. This feature should only be enabled for
+        jobs that share the same security domain. For details, see
+        <ulink url="https://docs.kernel.org/admin-guide/mm/ksm.html">Kernel Samepage Merging</ulink> in the
+        kernel documentation.</para>
+
+        <para>Note that this functionality might not be available, for example if KSM is disabled in the
+        kernel, or the kernel doesn't support controlling KSM at the process level through
+        <citerefentry><refentrytitle>prctl</refentrytitle><manvolnum>2</manvolnum></citerefentry>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>PrivateUsers=</varname></term>
+
+        <listitem><para>Takes a boolean argument. If true, sets up a new user namespace for the executed processes and
+        configures a minimal user and group mapping, that maps the <literal>root</literal> user and group as well as
+        the unit's own user and group to themselves and everything else to the <literal>nobody</literal> user and
+        group. This is useful to securely detach the user and group databases used by the unit from the rest of the
+        system, and thus to create an effective sandbox environment. All files, directories, processes, IPC objects and
+        other resources owned by users/groups not equaling <literal>root</literal> or the unit's own will stay visible
+        from within the unit but appear owned by the <literal>nobody</literal> user and group. If this mode is enabled,
+        all unit processes are run without privileges in the host user namespace (regardless if the unit's own
+        user/group is <literal>root</literal> or not). Specifically this means that the process will have zero process
+        capabilities on the host's user namespace, but full capabilities within the service's user namespace. Settings
+        such as <varname>CapabilityBoundingSet=</varname> will affect only the latter, and there's no way to acquire
+        additional capabilities in the host's user namespace. Defaults to off.</para>
+
+        <para>When this setting is set up by a per-user instance of the service manager, the mapping of the
+        <literal>root</literal> user and group to itself is omitted (unless the user manager is root).
+        Additionally, in the per-user instance manager case, the
+        user namespace will be set up before most other namespaces. This means that combining
+        <varname>PrivateUsers=</varname><option>true</option> with other namespaces will enable use of features not
+        normally supported by the per-user instances of the service manager.</para>
+
+        <para>This setting is particularly useful in conjunction with
+        <varname>RootDirectory=</varname>/<varname>RootImage=</varname>, as the need to synchronize the user and group
+        databases in the root directory and on the host is reduced, as the only users and groups who need to be matched
+        are <literal>root</literal>, <literal>nobody</literal> and the unit's own user and group.</para>
+
+        <para>Note that the implementation of this setting might be impossible (for example if user namespaces are not
+        available), and the unit should be written in a way that does not solely rely on this setting for
+        security.</para>
+
+        <xi:include href="version-info.xml" xpointer="v232"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ProtectHostname=</varname></term>
+
+        <listitem><para>Takes a boolean argument. When set, sets up a new UTS namespace for the executed
+        processes. In addition, changing hostname or domainname is prevented. Defaults to off.</para>
+
+        <para>Note that the implementation of this setting might be impossible (for example if UTS namespaces
+        are not available), and the unit should be written in a way that does not solely rely on this setting
+        for security.</para>
+
+        <para>Note that when this option is enabled for a service hostname changes no longer propagate from
+        the system into the service, it is hence not suitable for services that need to take notice of system
+        hostname changes dynamically.</para>
+
+        <xi:include href="system-or-user-ns.xml" xpointer="singular"/>
+
+        <xi:include href="version-info.xml" xpointer="v242"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ProtectClock=</varname></term>
+
+        <listitem><para>Takes a boolean argument. If set, writes to the hardware clock or system clock will
+        be denied. Defaults to off. Enabling this option removes <constant>CAP_SYS_TIME</constant> and
+        <constant>CAP_WAKE_ALARM</constant> from the capability bounding set for this unit, installs a system
+        call filter to block calls that can set the clock, and <varname>DeviceAllow=char-rtc r</varname> is
+        implied. Note that the system calls are blocked altogether, the filter does not take into account
+        that some of the calls can be used to read the clock state with some parameter combinations.
+        Effectively, <filename>/dev/rtc0</filename>, <filename>/dev/rtc1</filename>, etc. are made read-only
+        to the service. See
+        <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for the details about <varname>DeviceAllow=</varname>.</para>
+
+        <para>It is recommended to turn this on for most services that do not need modify the clock or check
+        its state.</para>
+
+        <xi:include href="system-or-user-ns.xml" xpointer="singular"/>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ProtectKernelTunables=</varname></term>
+
+        <listitem><para>Takes a boolean argument. If true, kernel variables accessible through
+        <filename>/proc/sys/</filename>, <filename>/sys/</filename>, <filename>/proc/sysrq-trigger</filename>,
+        <filename>/proc/latency_stats</filename>, <filename>/proc/acpi</filename>,
+        <filename>/proc/timer_stats</filename>, <filename>/proc/fs</filename> and <filename>/proc/irq</filename> will
+        be made read-only to all processes of the unit. Usually, tunable kernel variables should be initialized only at
+        boot-time, for example with the
+        <citerefentry><refentrytitle>sysctl.d</refentrytitle><manvolnum>5</manvolnum></citerefentry> mechanism. Few
+        services need to write to these at runtime; it is hence recommended to turn this on for most services. For this
+        setting the same restrictions regarding mount propagation and privileges apply as for
+        <varname>ReadOnlyPaths=</varname> and related calls, see above. Defaults to off.
+        Note that this option does not prevent indirect changes to kernel tunables effected by IPC calls to
+        other processes. However, <varname>InaccessiblePaths=</varname> may be used to make relevant IPC file system
+        objects inaccessible. If <varname>ProtectKernelTunables=</varname> is set,
+        <varname>MountAPIVFS=yes</varname> is implied.</para>
+
+        <xi:include href="system-or-user-ns.xml" xpointer="singular"/>
+
+        <xi:include href="version-info.xml" xpointer="v232"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ProtectKernelModules=</varname></term>
+
+        <listitem><para>Takes a boolean argument. If true, explicit module loading will be denied. This allows
+        module load and unload operations to be turned off on modular kernels. It is recommended to turn this on for most services
+        that do not need special file systems or extra kernel modules to work. Defaults to off. Enabling this option
+        removes <constant>CAP_SYS_MODULE</constant> from the capability bounding set for the unit, and installs a
+        system call filter to block module system calls, also <filename>/usr/lib/modules</filename> is made
+        inaccessible. For this setting the same restrictions regarding mount propagation and privileges apply as for
+        <varname>ReadOnlyPaths=</varname> and related calls, see above. Note that limited automatic module loading due
+        to user configuration or kernel mapping tables might still happen as side effect of requested user operations,
+        both privileged and unprivileged. To disable module auto-load feature please see
+        <citerefentry><refentrytitle>sysctl.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        <constant>kernel.modules_disabled</constant> mechanism and
+        <filename>/proc/sys/kernel/modules_disabled</filename> documentation.</para>
+
+        <xi:include href="system-or-user-ns.xml" xpointer="singular"/>
+
+        <xi:include href="version-info.xml" xpointer="v232"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ProtectKernelLogs=</varname></term>
+
+        <listitem><para>Takes a boolean argument. If true, access to the kernel log ring buffer will be denied. It is
+        recommended to turn this on for most services that do not need to read from or write to the kernel log ring
+        buffer. Enabling this option removes <constant>CAP_SYSLOG</constant> from the capability bounding set for this
+        unit, and installs a system call filter to block the
+        <citerefentry project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+        system call (not to be confused with the libc API
+        <citerefentry project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+        for userspace logging). The kernel exposes its log buffer to userspace via <filename>/dev/kmsg</filename> and
+        <filename>/proc/kmsg</filename>. If enabled, these are made inaccessible to all the processes in the unit.
+        </para>
+
+        <xi:include href="system-or-user-ns.xml" xpointer="singular"/>
+
+        <xi:include href="version-info.xml" xpointer="v244"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ProtectControlGroups=</varname></term>
+
+        <listitem><para>Takes a boolean argument. If true, the Linux Control Groups (<citerefentry
+        project='man-pages'><refentrytitle>cgroups</refentrytitle><manvolnum>7</manvolnum></citerefentry>) hierarchies
+        accessible through <filename>/sys/fs/cgroup/</filename> will be made read-only to all processes of the
+        unit. Except for container managers no services should require write access to the control groups hierarchies;
+        it is hence recommended to turn this on for most services. For this setting the same restrictions regarding
+        mount propagation and privileges apply as for <varname>ReadOnlyPaths=</varname> and related calls, see
+        above. Defaults to off. If <varname>ProtectControlGroups=</varname> is set, <varname>MountAPIVFS=yes</varname>
+        is implied.</para>
+
+        <xi:include href="system-only.xml" xpointer="singular"/>
+
+        <xi:include href="version-info.xml" xpointer="v232"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RestrictAddressFamilies=</varname></term>
+
+        <listitem><para>Restricts the set of socket address families accessible to the processes of this
+        unit. Takes <literal>none</literal>, or a space-separated list of address family names to
+        allow-list, such as <constant>AF_UNIX</constant>, <constant>AF_INET</constant> or
+        <constant>AF_INET6</constant>. When <literal>none</literal> is specified, then all address
+        families will be denied. When prefixed with <literal>~</literal> the listed address
+        families will be applied as deny list, otherwise as allow list. Note that this restricts access
+        to the
+        <citerefentry project='man-pages'><refentrytitle>socket</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+        system call only. Sockets passed into the process by other means (for example, by using socket
+        activation with socket units, see
+        <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>)
+        are unaffected. Also, sockets created with <function>socketpair()</function> (which creates connected
+        AF_UNIX sockets only) are unaffected. Note that this option has no effect on 32-bit x86, s390, s390x,
+        mips, mips-le, ppc, ppc-le, ppc64, ppc64-le and is ignored (but works correctly on other ABIs,
+        including x86-64). Note that on systems supporting multiple ABIs (such as x86/x86-64) it is
+        recommended to turn off alternative ABIs for services, so that they cannot be used to circumvent the
+        restrictions of this option. Specifically, it is recommended to combine this option with
+        <varname>SystemCallArchitectures=native</varname> or similar. By default, no restrictions apply, all
+        address families are accessible to processes. If assigned the empty string, any previous address family
+        restriction changes are undone. This setting does not affect commands prefixed with <literal>+</literal>.</para>
+
+        <para>Use this option to limit exposure of processes to remote access, in particular via exotic and sensitive
+        network protocols, such as <constant>AF_PACKET</constant>. Note that in most cases, the local
+        <constant>AF_UNIX</constant> address family should be included in the configured allow list as it is frequently
+        used for local communication, including for
+        <citerefentry><refentrytitle>syslog</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+        logging.</para>
+
+        <xi:include href="version-info.xml" xpointer="v211"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RestrictFileSystems=</varname></term>
+
+        <listitem><para>Restricts the set of filesystems processes of this unit can open files on. Takes a space-separated
+        list of filesystem names. Any filesystem listed is made accessible to the unit's processes, access to filesystem
+        types not listed is prohibited (allow-listing). If the first character of the list is <literal>~</literal>, the
+        effect is inverted: access to the filesystems listed is prohibited (deny-listing). If the empty string is assigned,
+        access to filesystems is not restricted.</para>
+
+        <para>If you specify both types of this option (i.e. allow-listing and deny-listing), the first encountered will take
+        precedence and will dictate the default action (allow access to the filesystem or deny it). Then the next occurrences
+        of this option will add or delete the listed filesystems from the set of the restricted filesystems, depending on its
+        type and the default action.</para>
+
+        <para>Example: if a unit has the following,
+        <programlisting>RestrictFileSystems=ext4 tmpfs
+RestrictFileSystems=ext2 ext4</programlisting>
+        then access to <constant>ext4</constant>, <constant>tmpfs</constant>, and <constant>ext2</constant> is allowed
+        and access to other filesystems is denied.</para>
+
+        <para>Example: if a unit has the following,
+        <programlisting>RestrictFileSystems=ext4 tmpfs
+RestrictFileSystems=~ext4</programlisting>
+        then only access <constant>tmpfs</constant> is allowed.</para>
+
+        <para>Example: if a unit has the following,
+        <programlisting>RestrictFileSystems=~ext4 tmpfs
+RestrictFileSystems=ext4</programlisting>
+        then only access to <constant>tmpfs</constant> is denied.</para>
+
+        <para>As the number of possible filesystems is large, predefined sets of filesystems are provided. A set
+        starts with <literal>@</literal> character, followed by name of the set.</para>
+
+        <table>
+          <title>Currently predefined filesystem sets</title>
+
+          <tgroup cols='2'>
+            <colspec colname='set' />
+            <colspec colname='description' />
+            <thead>
+              <row>
+                <entry>Set</entry>
+                <entry>Description</entry>
+              </row>
+            </thead>
+            <tbody>
+              <row>
+                <entry>@basic-api</entry>
+                <entry>Basic filesystem API.</entry>
+              </row>
+              <row>
+                <entry>@auxiliary-api</entry>
+                <entry>Auxiliary filesystem API.</entry>
+              </row>
+              <row>
+                <entry>@common-block</entry>
+                <entry>Common block device filesystems.</entry>
+              </row>
+              <row>
+                <entry>@historical-block</entry>
+                <entry>Historical block device filesystems.</entry>
+              </row>
+              <row>
+                <entry>@network</entry>
+                <entry>Well-known network filesystems.</entry>
+              </row>
+              <row>
+                <entry>@privileged-api</entry>
+                <entry>Privileged filesystem API.</entry>
+              </row>
+              <row>
+                <entry>@temporary</entry>
+                <entry>Temporary filesystems: tmpfs, ramfs.</entry>
+              </row>
+              <row>
+                <entry>@known</entry>
+                <entry>All known filesystems defined by the kernel. This list is defined statically in systemd based on a kernel version that was available when this systemd version was released. It will become progressively more out-of-date as the kernel is updated.</entry>
+              </row>
+            </tbody>
+          </tgroup>
+        </table>
+
+        <para>Use
+        <citerefentry><refentrytitle>systemd-analyze</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s
+        <command>filesystems</command> command to retrieve a list of filesystems defined on the local
+        system.</para>
+
+        <para>Note that this setting might not be supported on some systems (for example if the LSM eBPF hook is
+        not enabled in the underlying kernel or if not using the unified control group hierarchy). In that case this setting
+        has no effect.</para>
+
+        <xi:include href="cgroup-sandboxing.xml" xpointer="singular"/>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RestrictNamespaces=</varname></term>
+
+        <listitem><para>Restricts access to Linux namespace functionality for the processes of this unit. For details
+        about Linux namespaces, see <citerefentry
+        project='man-pages'><refentrytitle>namespaces</refentrytitle><manvolnum>7</manvolnum></citerefentry>. Either
+        takes a boolean argument, or a space-separated list of namespace type identifiers. If false (the default), no
+        restrictions on namespace creation and switching are made. If true, access to any kind of namespacing is
+        prohibited. Otherwise, a space-separated list of namespace type identifiers must be specified, consisting of
+        any combination of: <constant>cgroup</constant>, <constant>ipc</constant>, <constant>net</constant>,
+        <constant>mnt</constant>, <constant>pid</constant>, <constant>user</constant> and <constant>uts</constant>. Any
+        namespace type listed is made accessible to the unit's processes, access to namespace types not listed is
+        prohibited (allow-listing). By prepending the list with a single tilde character (<literal>~</literal>) the
+        effect may be inverted: only the listed namespace types will be made inaccessible, all unlisted ones are
+        permitted (deny-listing). If the empty string is assigned, the default namespace restrictions are applied,
+        which is equivalent to false. This option may appear more than once, in which case the namespace types are
+        merged by <constant>OR</constant>, or by <constant>AND</constant> if the lines are prefixed with
+        <literal>~</literal> (see examples below). Internally, this setting limits access to the
+        <citerefentry><refentrytitle>unshare</refentrytitle><manvolnum>2</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>clone</refentrytitle><manvolnum>2</manvolnum></citerefentry> and
+        <citerefentry><refentrytitle>setns</refentrytitle><manvolnum>2</manvolnum></citerefentry> system calls, taking
+        the specified flags parameters into account. Note that — if this option is used — in addition to restricting
+        creation and switching of the specified types of namespaces (or all of them, if true) access to the
+        <function>setns()</function> system call with a zero flags parameter is prohibited. This setting is only
+        supported on x86, x86-64, mips, mips-le, mips64, mips64-le, mips64-n32, mips64-le-n32, ppc64, ppc64-le, s390
+        and s390x, and enforces no restrictions on other architectures.</para>
+
+        <para>Example: if a unit has the following,
+        <programlisting>RestrictNamespaces=cgroup ipc
+RestrictNamespaces=cgroup net</programlisting>
+        then <constant>cgroup</constant>, <constant>ipc</constant>, and <constant>net</constant> are set.
+        If the second line is prefixed with <literal>~</literal>, e.g.,
+        <programlisting>RestrictNamespaces=cgroup ipc
+RestrictNamespaces=~cgroup net</programlisting>
+        then, only <constant>ipc</constant> is set.</para>
+
+        <xi:include href="version-info.xml" xpointer="v233"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>LockPersonality=</varname></term>
+
+        <listitem><para>Takes a boolean argument. If set, locks down the <citerefentry
+        project='man-pages'><refentrytitle>personality</refentrytitle><manvolnum>2</manvolnum></citerefentry> system
+        call so that the kernel execution domain may not be changed from the default or the personality selected with
+        <varname>Personality=</varname> directive. This may be useful to improve security, because odd personality
+        emulations may be poorly tested and source of vulnerabilities.</para>
+
+        <xi:include href="version-info.xml" xpointer="v235"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>MemoryDenyWriteExecute=</varname></term>
+
+        <listitem><para>Takes a boolean argument. If set, attempts to create memory mappings that are writable and
+        executable at the same time, or to change existing memory mappings to become executable, or mapping shared
+        memory segments as executable, are prohibited. Specifically, a system call filter is added (or
+        preferably, an equivalent kernel check is enabled with
+        <citerefentry><refentrytitle>prctl</refentrytitle><manvolnum>2</manvolnum></citerefentry>) that
+        rejects <citerefentry><refentrytitle>mmap</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+        system calls with both <constant>PROT_EXEC</constant> and <constant>PROT_WRITE</constant> set,
+        <citerefentry><refentrytitle>mprotect</refentrytitle><manvolnum>2</manvolnum></citerefentry> or
+        <citerefentry><refentrytitle>pkey_mprotect</refentrytitle><manvolnum>2</manvolnum></citerefentry> system calls
+        with <constant>PROT_EXEC</constant> set and
+        <citerefentry><refentrytitle>shmat</refentrytitle><manvolnum>2</manvolnum></citerefentry> system calls with
+        <constant>SHM_EXEC</constant> set. Note that this option is incompatible with programs and libraries that
+        generate program code dynamically at runtime, including JIT execution engines, executable stacks, and code
+        "trampoline" feature of various C compilers. This option improves service security, as it makes harder for
+        software exploits to change running code dynamically. However, the protection can be circumvented, if
+        the service can write to a filesystem, which is not mounted with <constant>noexec</constant> (such as
+        <filename>/dev/shm</filename>), or it can use <function>memfd_create()</function>. This can be
+        prevented by making such file systems inaccessible to the service
+        (e.g. <varname>InaccessiblePaths=/dev/shm</varname>) and installing further system call filters
+        (<varname>SystemCallFilter=~memfd_create</varname>). Note that this feature is fully available on
+        x86-64, and partially on x86. Specifically, the <function>shmat()</function> protection is not
+        available on x86. Note that on systems supporting multiple ABIs (such as x86/x86-64) it is
+        recommended to turn off alternative ABIs for services, so that they cannot be used to circumvent the
+        restrictions of this option. Specifically, it is recommended to combine this option with
+        <varname>SystemCallArchitectures=native</varname> or similar.</para>
+
+        <xi:include href="version-info.xml" xpointer="v231"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RestrictRealtime=</varname></term>
+
+        <listitem><para>Takes a boolean argument. If set, any attempts to enable realtime scheduling in a process of
+        the unit are refused. This restricts access to realtime task scheduling policies such as
+        <constant>SCHED_FIFO</constant>, <constant>SCHED_RR</constant> or <constant>SCHED_DEADLINE</constant>. See
+        <citerefentry project='man-pages'><refentrytitle>sched</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+        for details about these scheduling policies. Realtime scheduling policies may be used to monopolize CPU
+        time for longer periods of time, and may hence be used to lock up or otherwise trigger Denial-of-Service
+        situations on the system. It is hence recommended to restrict access to realtime scheduling to the few programs
+        that actually require them. Defaults to off.</para>
+
+        <xi:include href="version-info.xml" xpointer="v231"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RestrictSUIDSGID=</varname></term>
+
+        <listitem><para>Takes a boolean argument. If set, any attempts to set the set-user-ID (SUID) or
+        set-group-ID (SGID) bits on files or directories will be denied (for details on these bits see
+        <citerefentry
+        project='man-pages'><refentrytitle>inode</refentrytitle><manvolnum>7</manvolnum></citerefentry>).
+        As the SUID/SGID bits are mechanisms to elevate privileges, and allow users to acquire the
+        identity of other users, it is recommended to restrict creation of SUID/SGID files to the few
+        programs that actually require them. Note that this restricts marking of any type of file system
+        object with these bits, including both regular files and directories (where the SGID is a different
+        meaning than for files, see documentation). This option is implied if <varname>DynamicUser=</varname>
+        is enabled. Defaults to off.</para>
+
+        <xi:include href="version-info.xml" xpointer="v242"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RemoveIPC=</varname></term>
+
+        <listitem><para>Takes a boolean parameter. If set, all System V and POSIX IPC objects owned by the user and
+        group the processes of this unit are run as are removed when the unit is stopped. This setting only has an
+        effect if at least one of <varname>User=</varname>, <varname>Group=</varname> and
+        <varname>DynamicUser=</varname> are used. It has no effect on IPC objects owned by the root user. Specifically,
+        this removes System V semaphores, as well as System V and POSIX shared memory segments and message queues. If
+        multiple units use the same user or group the IPC objects are removed when the last of these units is
+        stopped. This setting is implied if <varname>DynamicUser=</varname> is set.</para>
+
+        <xi:include href="system-only.xml" xpointer="singular"/>
+
+        <xi:include href="version-info.xml" xpointer="v232"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>PrivateMounts=</varname></term>
+
+        <listitem><para>Takes a boolean parameter. If set, the processes of this unit will be run in their own private
+        file system (mount) namespace with all mount propagation from the processes towards the host's main file system
+        namespace turned off. This means any file system mount points established or removed by the unit's processes
+        will be private to them and not be visible to the host. However, file system mount points established or
+        removed on the host will be propagated to the unit's processes. See <citerefentry
+        project='man-pages'><refentrytitle>mount_namespaces</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
+        details on file system namespaces. Defaults to off.</para>
+
+        <para>When turned on, this executes three operations for each invoked process: a new
+        <constant>CLONE_NEWNS</constant> namespace is created, after which all existing mounts are remounted to
+        <constant>MS_SLAVE</constant> to disable propagation from the unit's processes to the host (but leaving
+        propagation in the opposite direction in effect). Finally, the mounts are remounted again to the propagation
+        mode configured with <varname>MountFlags=</varname>, see below.</para>
+
+        <para>File system namespaces are set up individually for each process forked off by the service manager. Mounts
+        established in the namespace of the process created by <varname>ExecStartPre=</varname> will hence be cleaned
+        up automatically as soon as that process exits and will not be available to subsequent processes forked off for
+        <varname>ExecStart=</varname> (and similar applies to the various other commands configured for
+        units). Similarly, <varname>JoinsNamespaceOf=</varname> does not permit sharing kernel mount namespaces between
+        units, it only enables sharing of the <filename>/tmp/</filename> and <filename>/var/tmp/</filename>
+        directories.</para>
+
+        <para>Other file system namespace unit settings — <varname>PrivateMounts=</varname>,
+        <varname>PrivateTmp=</varname>, <varname>PrivateDevices=</varname>, <varname>ProtectSystem=</varname>,
+        <varname>ProtectHome=</varname>, <varname>ReadOnlyPaths=</varname>, <varname>InaccessiblePaths=</varname>,
+        <varname>ReadWritePaths=</varname>, … — also enable file system namespacing in a fashion equivalent to this
+        option. Hence it is primarily useful to explicitly request this behaviour if none of the other settings are
+        used.</para>
+
+        <xi:include href="system-or-user-ns.xml" xpointer="singular"/>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>MountFlags=</varname></term>
+
+        <listitem><para>Takes a mount propagation setting: <option>shared</option>, <option>slave</option> or
+        <option>private</option>, which controls whether file system mount points in the file system namespaces set up
+        for this unit's processes will receive or propagate mounts and unmounts from other file system namespaces. See
+        <citerefentry project='man-pages'><refentrytitle>mount</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+        for details on mount propagation, and the three propagation flags in particular.</para>
+
+        <para>This setting only controls the <emphasis>final</emphasis> propagation setting in effect on all mount
+        points of the file system namespace created for each process of this unit. Other file system namespacing unit
+        settings (see the discussion in <varname>PrivateMounts=</varname> above) will implicitly disable mount and
+        unmount propagation from the unit's processes towards the host by changing the propagation setting of all mount
+        points in the unit's file system namespace to <option>slave</option> first. Setting this option to
+        <option>shared</option> does not reestablish propagation in that case.</para>
+
+        <para>If not set – but file system namespaces are enabled through another file system namespace unit setting –
+        <option>shared</option> mount propagation is used, but — as mentioned — as <option>slave</option> is applied
+        first, propagation from the unit's processes to the host is still turned off.</para>
+
+        <para>It is not recommended to use <option>private</option> mount propagation for units, as this means
+        temporary mounts (such as removable media) of the host will stay mounted and thus indefinitely busy in forked
+        off processes, as unmount propagation events won't be received by the file system namespace of the unit.</para>
+
+        <para>Usually, it is best to leave this setting unmodified, and use higher level file system namespacing
+        options instead, in particular <varname>PrivateMounts=</varname>, see above.</para>
+
+        <xi:include href="system-or-user-ns.xml" xpointer="singular"/></listitem>
+      </varlistentry>
+
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>System Call Filtering</title>
+    <variablelist class='unit-directives'>
+
+      <varlistentry>
+        <term><varname>SystemCallFilter=</varname></term>
+
+        <listitem><para>Takes a space-separated list of system call names. If this setting is used, all
+        system calls executed by the unit processes except for the listed ones will result in immediate
+        process termination with the <constant>SIGSYS</constant> signal (allow-listing). (See
+        <varname>SystemCallErrorNumber=</varname> below for changing the default action). If the first
+        character of the list is <literal>~</literal>, the effect is inverted: only the listed system calls
+        will result in immediate process termination (deny-listing). Deny-listed system calls and system call
+        groups may optionally be suffixed with a colon (<literal>:</literal>) and <literal>errno</literal>
+        error number (between 0 and 4095) or errno name such as <constant>EPERM</constant>,
+        <constant>EACCES</constant> or <constant>EUCLEAN</constant> (see <citerefentry
+        project='man-pages'><refentrytitle>errno</refentrytitle><manvolnum>3</manvolnum></citerefentry> for a
+        full list). This value will be returned when a deny-listed system call is triggered, instead of
+        terminating the processes immediately. Special setting <literal>kill</literal> can be used to
+        explicitly specify killing. This value takes precedence over the one given in
+        <varname>SystemCallErrorNumber=</varname>, see below. This feature makes use of the Secure Computing Mode 2
+        interfaces of the kernel ('seccomp filtering') and is useful for enforcing a minimal sandboxing environment.
+        Note that the <function>execve()</function>, <function>exit()</function>, <function>exit_group()</function>,
+        <function>getrlimit()</function>, <function>rt_sigreturn()</function>, <function>sigreturn()</function>
+        system calls and the system calls for querying time and sleeping are implicitly allow-listed and do not
+        need to be listed explicitly. This option may be specified more than once, in which case the filter masks are
+        merged. If the empty string is assigned, the filter is reset, all prior assignments will have no
+        effect. This does not affect commands prefixed with <literal>+</literal>.</para>
+
+        <para>Note that on systems supporting multiple ABIs (such as x86/x86-64) it is recommended to turn off
+        alternative ABIs for services, so that they cannot be used to circumvent the restrictions of this
+        option. Specifically, it is recommended to combine this option with
+        <varname>SystemCallArchitectures=native</varname> or similar.</para>
+
+        <para>Note that strict system call filters may impact execution and error handling code paths of the service
+        invocation. Specifically, access to the <function>execve()</function> system call is required for the execution
+        of the service binary — if it is blocked service invocation will necessarily fail. Also, if execution of the
+        service binary fails for some reason (for example: missing service executable), the error handling logic might
+        require access to an additional set of system calls in order to process and log this failure correctly. It
+        might be necessary to temporarily disable system call filters in order to simplify debugging of such
+        failures.</para>
+
+        <para>If you specify both types of this option (i.e. allow-listing and deny-listing), the first
+        encountered will take precedence and will dictate the default action (termination or approval of a
+        system call). Then the next occurrences of this option will add or delete the listed system calls
+        from the set of the filtered system calls, depending of its type and the default action. (For
+        example, if you have started with an allow list rule for <function>read()</function> and
+        <function>write()</function>, and right after it add a deny list rule for <function>write()</function>,
+        then <function>write()</function> will be removed from the set.)</para>
+
+        <para>As the number of possible system calls is large, predefined sets of system calls are provided. A set
+        starts with <literal>@</literal> character, followed by name of the set.
+
+        <table>
+          <title>Currently predefined system call sets</title>
+
+          <tgroup cols='2'>
+            <colspec colname='set' />
+            <colspec colname='description' />
+            <thead>
+              <row>
+                <entry>Set</entry>
+                <entry>Description</entry>
+              </row>
+            </thead>
+            <tbody>
+              <row>
+                <entry>@aio</entry>
+                <entry>Asynchronous I/O (<citerefentry project='man-pages'><refentrytitle>io_setup</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>io_submit</refentrytitle><manvolnum>2</manvolnum></citerefentry>, and related calls)</entry>
+              </row>
+              <row>
+                <entry>@basic-io</entry>
+                <entry>System calls for basic I/O: reading, writing, seeking, file descriptor duplication and closing (<citerefentry project='man-pages'><refentrytitle>read</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>write</refentrytitle><manvolnum>2</manvolnum></citerefentry>, and related calls)</entry>
+              </row>
+              <row>
+                <entry>@chown</entry>
+                <entry>Changing file ownership (<citerefentry project='man-pages'><refentrytitle>chown</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>fchownat</refentrytitle><manvolnum>2</manvolnum></citerefentry>, and related calls)</entry>
+              </row>
+              <row>
+                <entry>@clock</entry>
+                <entry>System calls for changing the system clock (<citerefentry project='man-pages'><refentrytitle>adjtimex</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>settimeofday</refentrytitle><manvolnum>2</manvolnum></citerefentry>, and related calls)</entry>
+              </row>
+              <row>
+                <entry>@cpu-emulation</entry>
+                <entry>System calls for CPU emulation functionality (<citerefentry project='man-pages'><refentrytitle>vm86</refentrytitle><manvolnum>2</manvolnum></citerefentry> and related calls)</entry>
+              </row>
+              <row>
+                <entry>@debug</entry>
+                <entry>Debugging, performance monitoring and tracing functionality (<citerefentry project='man-pages'><refentrytitle>ptrace</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>perf_event_open</refentrytitle><manvolnum>2</manvolnum></citerefentry> and related calls)</entry>
+              </row>
+              <row>
+                <entry>@file-system</entry>
+                <entry>File system operations: opening, creating files and directories for read and write, renaming and removing them, reading file properties, or creating hard and symbolic links</entry>
+              </row>
+              <row>
+                <entry>@io-event</entry>
+                <entry>Event loop system calls (<citerefentry project='man-pages'><refentrytitle>poll</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>select</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>epoll</refentrytitle><manvolnum>7</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>eventfd</refentrytitle><manvolnum>2</manvolnum></citerefentry> and related calls)</entry>
+              </row>
+              <row>
+                <entry>@ipc</entry>
+                <entry>Pipes, SysV IPC, POSIX Message Queues and other IPC (<citerefentry project='man-pages'><refentrytitle>mq_overview</refentrytitle><manvolnum>7</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>svipc</refentrytitle><manvolnum>7</manvolnum></citerefentry>)</entry>
+              </row>
+              <row>
+                <entry>@keyring</entry>
+                <entry>Kernel keyring access (<citerefentry project='man-pages'><refentrytitle>keyctl</refentrytitle><manvolnum>2</manvolnum></citerefentry> and related calls)</entry>
+              </row>
+              <row>
+                <entry>@memlock</entry>
+                <entry>Locking of memory in RAM (<citerefentry project='man-pages'><refentrytitle>mlock</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>mlockall</refentrytitle><manvolnum>2</manvolnum></citerefentry> and related calls)</entry>
+              </row>
+              <row>
+                <entry>@module</entry>
+                <entry>Loading and unloading of kernel modules (<citerefentry project='man-pages'><refentrytitle>init_module</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>delete_module</refentrytitle><manvolnum>2</manvolnum></citerefentry> and related calls)</entry>
+              </row>
+              <row>
+                <entry>@mount</entry>
+                <entry>Mounting and unmounting of file systems (<citerefentry project='man-pages'><refentrytitle>mount</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>chroot</refentrytitle><manvolnum>2</manvolnum></citerefentry>, and related calls)</entry>
+              </row>
+              <row>
+                <entry>@network-io</entry>
+                <entry>Socket I/O (including local AF_UNIX): <citerefentry project='man-pages'><refentrytitle>socket</refentrytitle><manvolnum>7</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>unix</refentrytitle><manvolnum>7</manvolnum></citerefentry></entry>
+              </row>
+              <row>
+                <entry>@obsolete</entry>
+                <entry>Unusual, obsolete or unimplemented (<citerefentry project='man-pages'><refentrytitle>create_module</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>gtty</refentrytitle><manvolnum>2</manvolnum></citerefentry>, …)</entry>
+              </row>
+              <row>
+                <entry>@pkey</entry>
+                <entry>System calls that deal with memory protection keys (<citerefentry project='man-pages'><refentrytitle>pkeys</refentrytitle><manvolnum>7</manvolnum></citerefentry>)</entry>
+              </row>
+              <row>
+                <entry>@privileged</entry>
+                <entry>All system calls which need super-user capabilities (<citerefentry project='man-pages'><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry>)</entry>
+              </row>
+              <row>
+                <entry>@process</entry>
+                <entry>Process control, execution, namespacing operations (<citerefentry project='man-pages'><refentrytitle>clone</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>kill</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>namespaces</refentrytitle><manvolnum>7</manvolnum></citerefentry>, …)</entry>
+              </row>
+              <row>
+                <entry>@raw-io</entry>
+                <entry>Raw I/O port access (<citerefentry project='man-pages'><refentrytitle>ioperm</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>iopl</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <function>pciconfig_read()</function>, …)</entry>
+              </row>
+              <row>
+                <entry>@reboot</entry>
+                <entry>System calls for rebooting and reboot preparation (<citerefentry project='man-pages'><refentrytitle>reboot</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <function>kexec()</function>, …)</entry>
+              </row>
+              <row>
+                <entry>@resources</entry>
+                <entry>System calls for changing resource limits, memory and scheduling parameters (<citerefentry project='man-pages'><refentrytitle>setrlimit</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>setpriority</refentrytitle><manvolnum>2</manvolnum></citerefentry>, …)</entry>
+              </row>
+              <row>
+                <entry>@sandbox</entry>
+                <entry>System calls for sandboxing programs (<citerefentry project='man-pages'><refentrytitle>seccomp</refentrytitle><manvolnum>2</manvolnum></citerefentry>, Landlock system calls, …)</entry>
+              </row>
+              <row>
+                <entry>@setuid</entry>
+                <entry>System calls for changing user ID and group ID credentials, (<citerefentry project='man-pages'><refentrytitle>setuid</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>setgid</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>setresuid</refentrytitle><manvolnum>2</manvolnum></citerefentry>, …)</entry>
+              </row>
+              <row>
+                <entry>@signal</entry>
+                <entry>System calls for manipulating and handling process signals (<citerefentry project='man-pages'><refentrytitle>signal</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>sigprocmask</refentrytitle><manvolnum>2</manvolnum></citerefentry>, …)</entry>
+              </row>
+              <row>
+                <entry>@swap</entry>
+                <entry>System calls for enabling/disabling swap devices (<citerefentry project='man-pages'><refentrytitle>swapon</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>swapoff</refentrytitle><manvolnum>2</manvolnum></citerefentry>)</entry>
+              </row>
+              <row>
+                <entry>@sync</entry>
+                <entry>Synchronizing files and memory to disk (<citerefentry project='man-pages'><refentrytitle>fsync</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>msync</refentrytitle><manvolnum>2</manvolnum></citerefentry>, and related calls)</entry>
+              </row>
+              <row>
+                <entry>@system-service</entry>
+                <entry>A reasonable set of system calls used by common system services, excluding any special purpose calls. This is the recommended starting point for allow-listing system calls for system services, as it contains what is typically needed by system services, but excludes overly specific interfaces. For example, the following APIs are excluded: <literal>@clock</literal>, <literal>@mount</literal>, <literal>@swap</literal>, <literal>@reboot</literal>.</entry>
+              </row>
+              <row>
+                <entry>@timer</entry>
+                <entry>System calls for scheduling operations by time (<citerefentry project='man-pages'><refentrytitle>alarm</refentrytitle><manvolnum>2</manvolnum></citerefentry>, <citerefentry project='man-pages'><refentrytitle>timer_create</refentrytitle><manvolnum>2</manvolnum></citerefentry>, …)</entry>
+              </row>
+              <row>
+                <entry>@known</entry>
+                <entry>All system calls defined by the kernel. This list is defined statically in systemd based on a kernel version that was available when this systemd version was released. It will become progressively more out-of-date as the kernel is updated.</entry>
+              </row>
+            </tbody>
+          </tgroup>
+        </table>
+
+        Note, that as new system calls are added to the kernel, additional system calls might be added to the groups
+        above. Contents of the sets may also change between systemd versions. In addition, the list of system calls
+        depends on the kernel version and architecture for which systemd was compiled. Use
+        <command>systemd-analyze syscall-filter</command> to list the actual list of system calls in each
+        filter.</para>
+
+        <para>Generally, allow-listing system calls (rather than deny-listing) is the safer mode of
+        operation. It is recommended to enforce system call allow lists for all long-running system
+        services. Specifically, the following lines are a relatively safe basic choice for the majority of
+        system services:</para>
+
+        <programlisting>[Service]
+SystemCallFilter=@system-service
+SystemCallErrorNumber=EPERM</programlisting>
+
+        <para>Note that various kernel system calls are defined redundantly: there are multiple system calls
+        for executing the same operation. For example, the <function>pidfd_send_signal()</function> system
+        call may be used to execute operations similar to what can be done with the older
+        <function>kill()</function> system call, hence blocking the latter without the former only provides
+        weak protection. Since new system calls are added regularly to the kernel as development progresses,
+        keeping system call deny lists comprehensive requires constant work. It is thus recommended to use
+        allow-listing instead, which offers the benefit that new system calls are by default implicitly
+        blocked until the allow list is updated.</para>
+
+        <para>Also note that a number of system calls are required to be accessible for the dynamic linker to
+        work. The dynamic linker is required for running most regular programs (specifically: all dynamic ELF
+        binaries, which is how most distributions build packaged programs). This means that blocking these
+        system calls (which include <function>open()</function>, <function>openat()</function> or
+        <function>mmap()</function>) will make most programs typically shipped with generic distributions
+        unusable.</para>
+
+        <para>It is recommended to combine the file system namespacing related options with
+        <varname>SystemCallFilter=~@mount</varname>, in order to prohibit the unit's processes to undo the
+        mappings. Specifically these are the options <varname>PrivateTmp=</varname>,
+        <varname>PrivateDevices=</varname>, <varname>ProtectSystem=</varname>, <varname>ProtectHome=</varname>,
+        <varname>ProtectKernelTunables=</varname>, <varname>ProtectControlGroups=</varname>,
+        <varname>ProtectKernelLogs=</varname>, <varname>ProtectClock=</varname>, <varname>ReadOnlyPaths=</varname>,
+        <varname>InaccessiblePaths=</varname> and <varname>ReadWritePaths=</varname>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v187"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SystemCallErrorNumber=</varname></term>
+
+        <listitem><para>Takes an <literal>errno</literal> error number (between 1 and 4095) or errno name
+        such as <constant>EPERM</constant>, <constant>EACCES</constant> or <constant>EUCLEAN</constant>, to
+        return when the system call filter configured with <varname>SystemCallFilter=</varname> is triggered,
+        instead of terminating the process immediately. See <citerefentry
+        project='man-pages'><refentrytitle>errno</refentrytitle><manvolnum>3</manvolnum></citerefentry> for a
+        full list of error codes. When this setting is not used, or when the empty string or the special
+        setting <literal>kill</literal> is assigned, the process will be terminated immediately when the
+        filter is triggered.</para>
+
+        <xi:include href="version-info.xml" xpointer="v209"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SystemCallArchitectures=</varname></term>
+
+        <listitem><para>Takes a space-separated list of architecture identifiers to include in the system call
+        filter. The known architecture identifiers are the same as for <varname>ConditionArchitecture=</varname>
+        described in <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        as well as <constant>x32</constant>, <constant>mips64-n32</constant>, <constant>mips64-le-n32</constant>, and
+        the special identifier <constant>native</constant>. The special identifier <constant>native</constant>
+        implicitly maps to the native architecture of the system (or more precisely: to the architecture the system
+        manager is compiled for). By default, this option is set to the empty list, i.e. no filtering is applied.</para>
+
+        <para>If this setting is used, processes of this unit will only be permitted to call native system calls, and
+        system calls of the specified architectures. For the purposes of this option, the x32 architecture is treated
+        as including x86-64 system calls. However, this setting still fulfills its purpose, as explained below, on
+        x32.</para>
+
+        <para>System call filtering is not equally effective on all architectures. For example, on x86
+        filtering of network socket-related calls is not possible, due to ABI limitations — a limitation that x86-64
+        does not have, however. On systems supporting multiple ABIs at the same time — such as x86/x86-64 — it is hence
+        recommended to limit the set of permitted system call architectures so that secondary ABIs may not be used to
+        circumvent the restrictions applied to the native ABI of the system. In particular, setting
+        <varname>SystemCallArchitectures=native</varname> is a good choice for disabling non-native ABIs.</para>
+
+        <para>System call architectures may also be restricted system-wide via the
+        <varname>SystemCallArchitectures=</varname> option in the global configuration. See
+        <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
+        details.</para>
+
+        <xi:include href="version-info.xml" xpointer="v209"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SystemCallLog=</varname></term>
+
+        <listitem><para>Takes a space-separated list of system call names. If this setting is used, all
+        system calls executed by the unit processes for the listed ones will be logged. If the first
+        character of the list is <literal>~</literal>, the effect is inverted: all system calls except the
+        listed system calls will be logged. This feature makes use of the Secure Computing Mode 2 interfaces
+        of the kernel ('seccomp filtering') and is useful for auditing or setting up a minimal sandboxing
+        environment. This option may be specified more than once, in which case the filter masks are merged.
+        If the empty string is assigned, the filter is reset, all prior assignments will have no effect.
+        This does not affect commands prefixed with <literal>+</literal>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v247"/></listitem>
+      </varlistentry>
+
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Environment</title>
+
+    <variablelist class='unit-directives'>
+
+      <varlistentry>
+        <term><varname>Environment=</varname></term>
+
+        <listitem><para>Sets environment variables for executed processes. Each line is unquoted using the
+        rules described in "Quoting" section in
+        <citerefentry><refentrytitle>systemd.syntax</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+        and becomes a list of variable assignments. If you need to assign a value containing spaces or the
+        equals sign to a variable, put quotes around the whole assignment. Variable expansion is not
+        performed inside the strings and the <literal>$</literal> character has no special meaning. Specifier
+        expansion is performed, see the "Specifiers" section in
+        <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+        </para>
+
+        <para>This option may be specified more than once, in which case all listed variables will be set. If
+        the same variable is listed twice, the later setting will override the earlier setting. If the empty
+        string is assigned to this option, the list of environment variables is reset, all prior assignments
+        have no effect.</para>
+
+        <para>The names of the variables can contain ASCII letters, digits, and the underscore character.
+        Variable names cannot be empty or start with a digit. In variable values, most characters are
+        allowed, but non-printable characters are currently rejected.</para>
+
+        <para>Example:
+        <programlisting>Environment="VAR1=word1 word2" VAR2=word3 "VAR3=$word 5 6"</programlisting>
+        gives three variables <literal>VAR1</literal>,
+        <literal>VAR2</literal>, <literal>VAR3</literal>
+        with the values <literal>word1 word2</literal>,
+        <literal>word3</literal>, <literal>$word 5 6</literal>.
+        </para>
+
+        <para>See <citerefentry
+        project='man-pages'><refentrytitle>environ</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
+        details about environment variables.</para>
+
+        <para>Note that environment variables are not suitable for passing secrets (such as passwords, key
+        material, …)  to service processes. Environment variables set for a unit are exposed to unprivileged
+        clients via D-Bus IPC, and generally not understood as being data that requires protection. Moreover,
+        environment variables are propagated down the process tree, including across security boundaries
+        (such as setuid/setgid executables), and hence might leak to processes that should not have access to
+        the secret data. Use <varname>LoadCredential=</varname>, <varname>LoadCredentialEncrypted=</varname>
+        or <varname>SetCredentialEncrypted=</varname> (see below) to pass data to unit processes
+        securely.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>EnvironmentFile=</varname></term>
+
+        <listitem><para>Similar to <varname>Environment=</varname>, but reads the environment variables from
+        a text file. The text file should contain newline-separated variable assignments. Empty lines, lines
+        without an <literal>=</literal> separator, or lines starting with <literal>;</literal> or
+        <literal>#</literal> will be ignored, which may be used for commenting. The file must be encoded with
+        UTF-8. Valid characters are
+        <ulink url="https://www.unicode.org/glossary/#unicode_scalar_value">unicode scalar values</ulink>
+        other than
+        <ulink url="https://www.unicode.org/glossary/#noncharacter">unicode noncharacters</ulink>,
+        <constant>U+0000</constant> <constant>NUL</constant>, and <constant>U+FEFF</constant>
+        <ulink url="https://www.unicode.org/glossary/#byte_order_mark">unicode byte order mark</ulink>.
+        Control codes other than <constant>NUL</constant> are allowed.</para>
+
+        <para>In the file, an unquoted value after the <literal>=</literal> is parsed with the same backslash-escape
+        rules as <ulink
+        url="https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_02_01">POSIX shell unquoted
+        text</ulink>, but unlike in a shell, interior whitespace is preserved and quotes after the
+        first non-whitespace character are preserved. Leading and trailing whitespace (space, tab, carriage return) is
+        discarded, but interior whitespace within the line is preserved verbatim. A line ending with a backslash will be
+        continued to the following one, with the newline itself discarded. A backslash
+        <literal>\</literal> followed by any character other than newline will preserve the following character, so that
+        <literal>\\</literal> will become the value <literal>\</literal>.</para>
+
+        <para>In the file, a <literal>'</literal>-quoted value after the <literal>=</literal> can span
+        multiple lines and contain any character verbatim other than single quote, like <ulink
+        url="https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_02_02">POSIX
+        shell single-quoted text</ulink>. No backslash-escape sequences are recognized. Leading and trailing
+        whitespace outside of the single quotes is discarded.</para>
+
+        <para>In the file, a <literal>"</literal>-quoted value after the <literal>=</literal> can span
+        multiple lines, and the same escape sequences are recognized as in <ulink
+        url="https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_02_03">POSIX
+        shell double-quoted text</ulink>. Backslash (<literal>\</literal>) followed by any of
+        <literal>"\`$</literal> will preserve that character. A backslash followed by newline is a line
+        continuation, and the newline itself is discarded. A backslash followed by any other character is
+        ignored; both the backslash and the following character are preserved verbatim. Leading and trailing
+        whitespace outside of the double quotes is discarded.</para>
+
+        <para>The argument passed should be an absolute filename or wildcard expression, optionally prefixed with
+        <literal>-</literal>, which indicates that if the file does not exist, it will not be read and no error or
+        warning message is logged. This option may be specified more than once in which case all specified files are
+        read. If the empty string is assigned to this option, the list of file to read is reset, all prior assignments
+        have no effect.</para>
+
+        <para>The files listed with this directive will be read shortly before the process is executed (more
+        specifically, after all processes from a previous unit state terminated. This means you can generate these
+        files in one unit state, and read it with this option in the next. The files are read from the file
+        system of the service manager, before any file system changes like bind mounts take place).</para>
+
+        <para>Settings from these files override settings made with <varname>Environment=</varname>. If the same
+        variable is set twice from these files, the files will be read in the order they are specified and the later
+        setting will override the earlier setting.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>PassEnvironment=</varname></term>
+
+        <listitem><para>Pass environment variables set for the system service manager to executed processes. Takes a
+        space-separated list of variable names. This option may be specified more than once, in which case all listed
+        variables will be passed. If the empty string is assigned to this option, the list of environment variables to
+        pass is reset, all prior assignments have no effect. Variables specified that are not set for the system
+        manager will not be passed and will be silently ignored. Note that this option is only relevant for the system
+        service manager, as system services by default do not automatically inherit any environment variables set for
+        the service manager itself. However, in case of the user service manager all environment variables are passed
+        to the executed processes anyway, hence this option is without effect for the user service manager.</para>
+
+        <para>Variables set for invoked processes due to this setting are subject to being overridden by those
+        configured with <varname>Environment=</varname> or <varname>EnvironmentFile=</varname>.</para>
+
+        <para>Example:
+        <programlisting>PassEnvironment=VAR1 VAR2 VAR3</programlisting>
+        passes three variables <literal>VAR1</literal>,
+        <literal>VAR2</literal>, <literal>VAR3</literal>
+        with the values set for those variables in PID1.</para>
+
+        <para>
+        See <citerefentry
+        project='man-pages'><refentrytitle>environ</refentrytitle><manvolnum>7</manvolnum></citerefentry> for details
+        about environment variables.</para>
+
+        <xi:include href="version-info.xml" xpointer="v228"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>UnsetEnvironment=</varname></term>
+
+        <listitem><para>Explicitly unset environment variable assignments that would normally be passed from the
+        service manager to invoked processes of this unit. Takes a space-separated list of variable names or variable
+        assignments. This option may be specified more than once, in which case all listed variables/assignments will
+        be unset. If the empty string is assigned to this option, the list of environment variables/assignments to
+        unset is reset. If a variable assignment is specified (that is: a variable name, followed by
+        <literal>=</literal>, followed by its value), then any environment variable matching this precise assignment is
+        removed. If a variable name is specified (that is a variable name without any following <literal>=</literal> or
+        value), then any assignment matching the variable name, regardless of its value is removed. Note that the
+        effect of <varname>UnsetEnvironment=</varname> is applied as final step when the environment list passed to
+        executed processes is compiled. That means it may undo assignments from any configuration source, including
+        assignments made through <varname>Environment=</varname> or <varname>EnvironmentFile=</varname>, inherited from
+        the system manager's global set of environment variables, inherited via <varname>PassEnvironment=</varname>,
+        set by the service manager itself (such as <varname>$NOTIFY_SOCKET</varname> and such), or set by a PAM module
+        (in case <varname>PAMName=</varname> is used).</para>
+
+        <para>See "Environment Variables in Spawned Processes" below for a description of how those
+        settings combine to form the inherited environment. See <citerefentry
+        project='man-pages'><refentrytitle>environ</refentrytitle><manvolnum>7</manvolnum></citerefentry> for general
+        information about environment variables.</para>
+
+        <xi:include href="version-info.xml" xpointer="v235"/></listitem>
+      </varlistentry>
+
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Logging and Standard Input/Output</title>
+
+    <variablelist class='unit-directives'>
+      <varlistentry>
+
+        <term><varname>StandardInput=</varname></term>
+
+        <listitem><para>Controls where file descriptor 0 (STDIN) of the executed processes is connected to. Takes one
+        of <option>null</option>, <option>tty</option>, <option>tty-force</option>, <option>tty-fail</option>,
+        <option>data</option>, <option>file:<replaceable>path</replaceable></option>, <option>socket</option> or
+        <option>fd:<replaceable>name</replaceable></option>.</para>
+
+        <para>If <option>null</option> is selected, standard input will be connected to <filename>/dev/null</filename>,
+        i.e. all read attempts by the process will result in immediate EOF.</para>
+
+        <para>If <option>tty</option> is selected, standard input is connected to a TTY (as configured by
+        <varname>TTYPath=</varname>, see below) and the executed process becomes the controlling process of the
+        terminal. If the terminal is already being controlled by another process, the executed process waits until the
+        current controlling process releases the terminal.</para>
+
+        <para><option>tty-force</option> is similar to <option>tty</option>, but the executed process is forcefully and
+        immediately made the controlling process of the terminal, potentially removing previous controlling processes
+        from the terminal.</para>
+
+        <para><option>tty-fail</option> is similar to <option>tty</option>, but if the terminal already has a
+        controlling process start-up of the executed process fails.</para>
+
+        <para>The <option>data</option> option may be used to configure arbitrary textual or binary data to pass via
+        standard input to the executed process. The data to pass is configured via
+        <varname>StandardInputText=</varname>/<varname>StandardInputData=</varname> (see below). Note that the actual
+        file descriptor type passed (memory file, regular file, UNIX pipe, …) might depend on the kernel and available
+        privileges. In any case, the file descriptor is read-only, and when read returns the specified data followed by
+        EOF.</para>
+
+        <para>The <option>file:<replaceable>path</replaceable></option> option may be used to connect a specific file
+        system object to standard input. An absolute path following the <literal>:</literal> character is expected,
+        which may refer to a regular file, a FIFO or special file. If an <constant>AF_UNIX</constant> socket in the
+        file system is specified, a stream socket is connected to it. The latter is useful for connecting standard
+        input of processes to arbitrary system services.</para>
+
+        <para>The <option>socket</option> option is valid in socket-activated services only, and requires the relevant
+        socket unit file (see
+        <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry> for details)
+        to have <varname>Accept=yes</varname> set, or to specify a single socket only. If this option is set, standard
+        input will be connected to the socket the service was activated from, which is primarily useful for
+        compatibility with daemons designed for use with the traditional <citerefentry
+        project='freebsd'><refentrytitle>inetd</refentrytitle><manvolnum>8</manvolnum></citerefentry> socket activation
+        daemon (<varname>$LISTEN_FDS</varname> (and related) environment variables are not passed when
+        <option>socket</option> value is configured).</para>
+
+        <para>The <option>fd:<replaceable>name</replaceable></option> option connects standard input to a specific,
+        named file descriptor provided by a socket unit. The name may be specified as part of this option, following a
+        <literal>:</literal> character (e.g. <literal>fd:foobar</literal>). If no name is specified, the name
+        <literal>stdin</literal> is implied (i.e. <literal>fd</literal> is equivalent to <literal>fd:stdin</literal>).
+        At least one socket unit defining the specified name must be provided via the <varname>Sockets=</varname>
+        option, and the file descriptor name may differ from the name of its containing socket unit. If multiple
+        matches are found, the first one will be used. See <varname>FileDescriptorName=</varname> in
+        <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry> for more
+        details about named file descriptors and their ordering.</para>
+
+        <para>This setting defaults to <option>null</option>, unless
+        <varname>StandardInputText=</varname>/<varname>StandardInputData=</varname> are set, in which case it
+        defaults to <option>data</option>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>StandardOutput=</varname></term>
+
+        <listitem><para>Controls where file descriptor 1 (stdout) of the executed processes is connected
+        to. Takes one of <option>inherit</option>, <option>null</option>, <option>tty</option>,
+        <option>journal</option>, <option>kmsg</option>, <option>journal+console</option>,
+        <option>kmsg+console</option>, <option>file:<replaceable>path</replaceable></option>,
+        <option>append:<replaceable>path</replaceable></option>, <option>truncate:<replaceable>path</replaceable></option>,
+        <option>socket</option> or <option>fd:<replaceable>name</replaceable></option>.</para>
+
+        <para><option>inherit</option> duplicates the file descriptor of standard input for standard output.</para>
+
+        <para><option>null</option> connects standard output to <filename>/dev/null</filename>, i.e. everything written
+        to it will be lost.</para>
+
+        <para><option>tty</option> connects standard output to a tty (as configured via <varname>TTYPath=</varname>,
+        see below). If the TTY is used for output only, the executed process will not become the controlling process of
+        the terminal, and will not fail or wait for other processes to release the terminal.</para>
+
+        <para><option>journal</option> connects standard output with the journal, which is accessible via
+        <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>. Note
+        that everything that is written to kmsg (see below) is implicitly stored in the journal as well, the
+        specific option listed below is hence a superset of this one. (Also note that any external,
+        additional syslog daemons receive their log data from the journal, too, hence this is the option to
+        use when logging shall be processed with such a daemon.)</para>
+
+        <para><option>kmsg</option> connects standard output with the kernel log buffer which is accessible via
+        <citerefentry project='man-pages'><refentrytitle>dmesg</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+        in addition to the journal. The journal daemon might be configured to send all logs to kmsg anyway, in which
+        case this option is no different from <option>journal</option>.</para>
+
+        <para><option>journal+console</option> and <option>kmsg+console</option> work in a similar way as the
+        two options above but copy the output to the system console as well.</para>
+
+        <para>The <option>file:<replaceable>path</replaceable></option> option may be used to connect a specific file
+        system object to standard output. The semantics are similar to the same option of
+        <varname>StandardInput=</varname>, see above. If <replaceable>path</replaceable> refers to a regular file
+        on the filesystem, it is opened (created if it doesn't exist yet) for writing at the beginning of the file,
+        but without truncating it.
+        If standard input and output are directed to the same file path, it is opened only once — for reading as well
+        as writing — and duplicated. This is particularly useful when the specified path refers to an
+        <constant>AF_UNIX</constant> socket in the file system, as in that case only a
+        single stream connection is created for both input and output.</para>
+
+        <para><option>append:<replaceable>path</replaceable></option> is similar to
+        <option>file:<replaceable>path</replaceable></option> above, but it opens the file in append mode.
+        </para>
+
+        <para><option>truncate:<replaceable>path</replaceable></option> is similar to
+        <option>file:<replaceable>path</replaceable></option> above, but it truncates the file when opening
+        it. For units with multiple command lines, e.g. <varname>Type=oneshot</varname> services with
+        multiple <varname>ExecStart=</varname>, or services with <varname>ExecCondition=</varname>,
+        <varname>ExecStartPre=</varname> or <varname>ExecStartPost=</varname>, the output file is reopened
+        and therefore re-truncated for each command line. If the output file is truncated while another
+        process still has the file open, e.g. by an <varname>ExecReload=</varname> running concurrently with
+        an <varname>ExecStart=</varname>, and the other process continues writing to the file without
+        adjusting its offset, then the space between the file pointers of the two processes may be filled
+        with <constant>NUL</constant> bytes, producing a sparse file. Thus,
+        <option>truncate:<replaceable>path</replaceable></option> is typically only useful for units where
+        only one process runs at a time, such as services with a single <varname>ExecStart=</varname> and no
+        <varname>ExecStartPost=</varname>, <varname>ExecReload=</varname>, <varname>ExecStop=</varname> or
+        similar.</para>
+
+        <para><option>socket</option> connects standard output to a socket acquired via socket activation. The
+        semantics are similar to the same option of <varname>StandardInput=</varname>, see above.</para>
+
+        <para>The <option>fd:<replaceable>name</replaceable></option> option connects standard output to a
+        specific, named file descriptor provided by a socket unit. A name may be specified as part of this
+        option, following a <literal>:</literal> character
+        (e.g. <literal>fd:<replaceable>foobar</replaceable></literal>). If no name is specified, the name
+        <literal>stdout</literal> is implied (i.e. <literal>fd</literal> is equivalent to
+        <literal>fd:stdout</literal>). At least one socket unit defining the specified name must be provided
+        via the <varname>Sockets=</varname> option, and the file descriptor name may differ from the name of
+        its containing socket unit. If multiple matches are found, the first one will be used. See
+        <varname>FileDescriptorName=</varname> in
+        <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for more details about named descriptors and their ordering.</para>
+
+        <para>If the standard output (or error output, see below) of a unit is connected to the journal or
+        the kernel log buffer, the unit will implicitly gain a dependency of type <varname>After=</varname>
+        on <filename>systemd-journald.socket</filename> (also see the "Implicit Dependencies" section
+        above). Also note that in this case stdout (or stderr, see below) will be an
+        <constant>AF_UNIX</constant> stream socket, and not a pipe or FIFO that can be re-opened. This means
+        when executing shell scripts the construct <command>echo "hello" &gt; /dev/stderr</command> for
+        writing text to stderr will not work. To mitigate this use the construct <command>echo "hello"
+        >&amp;2</command> instead, which is mostly equivalent and avoids this pitfall.</para>
+
+        <para>If <varname>StandardInput=</varname> is set to one of <option>tty</option>, <option>tty-force</option>,
+        <option>tty-fail</option>, <option>socket</option>, or <option>fd:<replaceable>name</replaceable></option>, this
+        setting defaults to <option>inherit</option>.</para>
+
+        <para>In other cases, this setting defaults to the value set with <varname>DefaultStandardOutput=</varname> in
+        <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>, which
+        defaults to <option>journal</option>. Note that setting this parameter might result in additional dependencies
+        to be added to the unit (see above).</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>StandardError=</varname></term>
+
+        <listitem><para>Controls where file descriptor 2 (stderr) of the executed processes is connected to. The
+        available options are identical to those of <varname>StandardOutput=</varname>, with some exceptions: if set to
+        <option>inherit</option> the file descriptor used for standard output is duplicated for standard error, while
+        <option>fd:<replaceable>name</replaceable></option> will use a default file descriptor name of
+        <literal>stderr</literal>.</para>
+
+        <para>This setting defaults to the value set with <varname>DefaultStandardError=</varname> in
+        <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>, which
+        defaults to <option>inherit</option>. Note that setting this parameter might result in additional dependencies
+        to be added to the unit (see above).</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>StandardInputText=</varname></term>
+        <term><varname>StandardInputData=</varname></term>
+
+        <listitem><para>Configures arbitrary textual or binary data to pass via file descriptor 0 (STDIN) to
+        the executed processes. These settings have no effect unless <varname>StandardInput=</varname> is set
+        to <option>data</option> (which is the default if <varname>StandardInput=</varname> is not set
+        otherwise, but <varname>StandardInputText=</varname>/<varname>StandardInputData=</varname> is). Use
+        this option to embed process input data directly in the unit file.</para>
+
+        <para><varname>StandardInputText=</varname> accepts arbitrary textual data. C-style escapes for special
+        characters as well as the usual <literal>%</literal>-specifiers are resolved. Each time this setting is used
+        the specified text is appended to the per-unit data buffer, followed by a newline character (thus every use
+        appends a new line to the end of the buffer). Note that leading and trailing whitespace of lines configured
+        with this option is removed. If an empty line is specified the buffer is cleared (hence, in order to insert an
+        empty line, add an additional <literal>\n</literal> to the end or beginning of a line).</para>
+
+        <para><varname>StandardInputData=</varname> accepts arbitrary binary data, encoded in <ulink
+        url="https://tools.ietf.org/html/rfc2045#section-6.8">Base64</ulink>. No escape sequences or specifiers are
+        resolved. Any whitespace in the encoded version is ignored during decoding.</para>
+
+        <para>Note that <varname>StandardInputText=</varname> and <varname>StandardInputData=</varname> operate on the
+        same data buffer, and may be mixed in order to configure both binary and textual data for the same input
+        stream. The textual or binary data is joined strictly in the order the settings appear in the unit
+        file. Assigning an empty string to either will reset the data buffer.</para>
+
+        <para>Please keep in mind that in order to maintain readability long unit file settings may be split into
+        multiple lines, by suffixing each line (except for the last) with a <literal>\</literal> character (see
+        <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
+        details). This is particularly useful for large data configured with these two options. Example:</para>
+
+        <programlisting>…
+StandardInput=data
+StandardInputData=V2XigLJyZSBubyBzdHJhbmdlcnMgdG8gbG92ZQpZb3Uga25vdyB0aGUgcnVsZXMgYW5kIHNvIGRv \
+                  IEkKQSBmdWxsIGNvbW1pdG1lbnQncyB3aGF0IEnigLJtIHRoaW5raW5nIG9mCllvdSB3b3VsZG4n \
+                  dCBnZXQgdGhpcyBmcm9tIGFueSBvdGhlciBndXkKSSBqdXN0IHdhbm5hIHRlbGwgeW91IGhvdyBJ \
+                  J20gZmVlbGluZwpHb3R0YSBtYWtlIHlvdSB1bmRlcnN0YW5kCgpOZXZlciBnb25uYSBnaXZlIHlv \
+                  dSB1cApOZXZlciBnb25uYSBsZXQgeW91IGRvd24KTmV2ZXIgZ29ubmEgcnVuIGFyb3VuZCBhbmQg \
+                  ZGVzZXJ0IHlvdQpOZXZlciBnb25uYSBtYWtlIHlvdSBjcnkKTmV2ZXIgZ29ubmEgc2F5IGdvb2Ri \
+                  eWUKTmV2ZXIgZ29ubmEgdGVsbCBhIGxpZSBhbmQgaHVydCB5b3UK
+…</programlisting>
+
+        <xi:include href="version-info.xml" xpointer="v236"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>LogLevelMax=</varname></term>
+
+        <listitem><para>Configures filtering by log level of log messages generated by this unit. Takes a
+        <command>syslog</command> log level, one of <option>emerg</option> (lowest log level, only highest priority
+        messages), <option>alert</option>, <option>crit</option>, <option>err</option>, <option>warning</option>,
+        <option>notice</option>, <option>info</option>, <option>debug</option> (highest log level, also lowest priority
+        messages). See <citerefentry
+        project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry> for
+        details. By default no filtering is applied (i.e. the default maximum log level is <option>debug</option>). Use
+        this option to configure the logging system to drop log messages of a specific service above the specified
+        level. For example, set <varname>LogLevelMax=</varname><option>info</option> in order to turn off debug logging
+        of a particularly chatty unit. Note that the configured level is applied to any log messages written by any
+        of the processes belonging to this unit, as well as any log messages written by the system manager process
+        (PID 1) in reference to this unit, sent via any supported logging protocol. The filtering is applied
+        early in the logging pipeline, before any kind of further processing is done. Moreover, messages which pass
+        through this filter successfully might still be dropped by filters applied at a later stage in the logging
+        subsystem. For example, <varname>MaxLevelStore=</varname> configured in
+        <citerefentry><refentrytitle>journald.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> might
+        prohibit messages of higher log levels to be stored on disk, even though the per-unit
+        <varname>LogLevelMax=</varname> permitted it to be processed.</para>
+
+        <xi:include href="version-info.xml" xpointer="v236"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>LogExtraFields=</varname></term>
+
+        <listitem><para>Configures additional log metadata fields to include in all log records generated by
+        processes associated with this unit, including systemd. This setting takes one or more journal field
+        assignments in the format <literal>FIELD=VALUE</literal> separated by whitespace. See
+        <citerefentry><refentrytitle>systemd.journal-fields</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+        for details on the journal field concept. Even though the underlying journal implementation permits
+        binary field values, this setting accepts only valid UTF-8 values. To include space characters in a
+        journal field value, enclose the assignment in double quotes ("). <!-- " fake closing quote for emacs-->
+        The usual specifiers are expanded in all assignments (see below). Note that this setting is not only
+        useful for attaching additional metadata to log records of a unit, but given that all fields and
+        values are indexed may also be used to implement cross-unit log record matching. Assign an empty
+        string to reset the list.</para>
+
+        <xi:include href="version-info.xml" xpointer="v236"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>LogRateLimitIntervalSec=</varname></term>
+        <term><varname>LogRateLimitBurst=</varname></term>
+
+        <listitem><para>Configures the rate limiting that is applied to log messages generated by this unit.
+        If, in the time interval defined by <varname>LogRateLimitIntervalSec=</varname>, more messages than
+        specified in <varname>LogRateLimitBurst=</varname> are logged by a service, all further messages
+        within the interval are dropped until the interval is over. A message about the number of dropped
+        messages is generated. The time specification for <varname>LogRateLimitIntervalSec=</varname> may be
+        specified in the following units: "s", "min", "h", "ms", "us". See
+        <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
+        details. The default settings are set by <varname>RateLimitIntervalSec=</varname> and
+        <varname>RateLimitBurst=</varname> configured in
+        <citerefentry><refentrytitle>journald.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+        Note that this only applies to log messages that are processed by the logging subsystem, i.e. by
+        <citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+        This means that if you connect a service's stderr directly to a file via
+        <varname>StandardOutput=file:…</varname> or a similar setting, the rate limiting will not be applied
+        to messages written that way (but it will be enforced for messages generated via
+        <citerefentry project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+        and similar functions).</para>
+
+        <xi:include href="version-info.xml" xpointer="v240"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>LogFilterPatterns=</varname></term>
+
+        <listitem><para>Define an extended regular expression to filter log messages based on the
+        <varname>MESSAGE=</varname> field of the structured message. If the first character of the pattern is
+        <literal>~</literal>, log entries matching the pattern should be discarded. This option takes a single
+        pattern as an argument but can be used multiple times to create a list of allowed and denied patterns.
+        If the empty string is assigned, the filter is reset, and all prior assignments will have no effect.</para>
+
+        <para>Because the <literal>~</literal> character is used to define denied patterns, it must be replaced
+        with <literal>\x7e</literal> to allow a message starting with <literal>~</literal>. For example,
+        <literal>~foobar</literal> would add a pattern matching <literal>foobar</literal> to the deny list, while
+        <literal>\x7efoobar</literal> would add a pattern matching <literal>~foobar</literal> to the allow list.</para>
+
+        <para>Log messages are tested against denied patterns (if any), then against allowed patterns
+        (if any). If a log message matches any of the denied patterns, it will be discarded, whatever the
+        allowed patterns. Then, remaining log messages are tested against allowed patterns. Messages matching
+        against none of the allowed pattern are discarded. If no allowed patterns are defined, then all
+        messages are processed directly after going through denied filters.</para>
+
+        <para>Filtering is based on the unit for which <varname>LogFilterPatterns=</varname> is defined, meaning log
+        messages coming from
+        <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> about the
+        unit are not taken into account. Filtered log messages won't be forwarded to traditional syslog daemons,
+        the kernel log buffer (kmsg), the systemd console, or sent as wall messages to all logged-in
+        users.</para>
+
+        <xi:include href="version-info.xml" xpointer="v253"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>LogNamespace=</varname></term>
+
+        <listitem><para>Run the unit's processes in the specified journal namespace. Expects a short
+        user-defined string identifying the namespace. If not used the processes of the service are run in
+        the default journal namespace, i.e. their log stream is collected and processed by
+        <filename>systemd-journald.service</filename>. If this option is used any log data generated by
+        processes of this unit (regardless if via the <function>syslog()</function>, journal native logging
+        or stdout/stderr logging) is collected and processed by an instance of the
+        <filename>systemd-journald@.service</filename> template unit, which manages the specified
+        namespace. The log data is stored in a data store independent from the default log namespace's data
+        store. See
+        <citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        for details about journal namespaces.</para>
+
+        <para>Internally, journal namespaces are implemented through Linux mount namespacing and
+        over-mounting the directory that contains the relevant <constant>AF_UNIX</constant> sockets used for
+        logging in the unit's mount namespace. Since mount namespaces are used this setting disconnects
+        propagation of mounts from the unit's processes to the host, similarly to how
+        <varname>ReadOnlyPaths=</varname> and similar settings describe above work. Journal namespaces may hence
+        not be used for services that need to establish mount points on the host.</para>
+
+        <para>When this option is used the unit will automatically gain ordering and requirement dependencies
+        on the two socket units associated with the <filename>systemd-journald@.service</filename> instance
+        so that they are automatically established prior to the unit starting up. Note that when this option
+        is used log output of this service does not appear in the regular
+        <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+        output, unless the <option>--namespace=</option> option is used.</para>
+
+        <xi:include href="system-only.xml" xpointer="singular"/>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SyslogIdentifier=</varname></term>
+
+        <listitem><para>Sets the process name ("<command>syslog</command> tag") to prefix log lines sent to
+        the logging system or the kernel log buffer with. If not set, defaults to the process name of the
+        executed process. This option is only useful when <varname>StandardOutput=</varname> or
+        <varname>StandardError=</varname> are set to <option>journal</option> or <option>kmsg</option> (or to
+        the same settings in combination with <option>+console</option>) and only applies to log messages
+        written to stdout or stderr.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SyslogFacility=</varname></term>
+
+        <listitem><para>Sets the <command>syslog</command> facility identifier to use when logging. One of
+        <option>kern</option>, <option>user</option>, <option>mail</option>, <option>daemon</option>,
+        <option>auth</option>, <option>syslog</option>, <option>lpr</option>, <option>news</option>,
+        <option>uucp</option>, <option>cron</option>, <option>authpriv</option>, <option>ftp</option>,
+        <option>local0</option>, <option>local1</option>, <option>local2</option>, <option>local3</option>,
+        <option>local4</option>, <option>local5</option>, <option>local6</option> or
+        <option>local7</option>. See <citerefentry
+        project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry> for
+        details. This option is only useful when <varname>StandardOutput=</varname> or
+        <varname>StandardError=</varname> are set to <option>journal</option> or <option>kmsg</option> (or to
+        the same settings in combination with <option>+console</option>), and only applies to log messages
+        written to stdout or stderr. Defaults to <option>daemon</option>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SyslogLevel=</varname></term>
+
+        <listitem><para>The default <command>syslog</command> log level to use when logging to the logging system or
+        the kernel log buffer. One of <option>emerg</option>, <option>alert</option>, <option>crit</option>,
+        <option>err</option>, <option>warning</option>, <option>notice</option>, <option>info</option>,
+        <option>debug</option>. See <citerefentry
+        project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry> for
+        details. This option is only useful when <varname>StandardOutput=</varname> or
+        <varname>StandardError=</varname> are set to <option>journal</option> or
+        <option>kmsg</option> (or to the same settings in combination with <option>+console</option>), and only applies
+        to log messages written to stdout or stderr. Note that individual lines output by executed processes may be
+        prefixed with a different log level which can be used to override the default log level specified here. The
+        interpretation of these prefixes may be disabled with <varname>SyslogLevelPrefix=</varname>, see below. For
+        details, see <citerefentry><refentrytitle>sd-daemon</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+        Defaults to <option>info</option>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SyslogLevelPrefix=</varname></term>
+
+        <listitem><para>Takes a boolean argument. If true and <varname>StandardOutput=</varname> or
+        <varname>StandardError=</varname> are set to <option>journal</option> or <option>kmsg</option> (or to
+        the same settings in combination with <option>+console</option>), log lines written by the executed
+        process that are prefixed with a log level will be processed with this log level set but the prefix
+        removed. If set to false, the interpretation of these prefixes is disabled and the logged lines are
+        passed on as-is. This only applies to log messages written to stdout or stderr. For details about
+        this prefixing see
+        <citerefentry><refentrytitle>sd-daemon</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+        Defaults to true.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>TTYPath=</varname></term>
+
+        <listitem><para>Sets the terminal device node to use if standard input, output, or error are connected to a TTY
+        (see above). Defaults to <filename>/dev/console</filename>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>TTYReset=</varname></term>
+
+        <listitem><para>Reset the terminal device specified with <varname>TTYPath=</varname> before and after
+        execution. Defaults to <literal>no</literal>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>TTYVHangup=</varname></term>
+
+        <listitem><para>Disconnect all clients which have opened the terminal device specified with
+        <varname>TTYPath=</varname> before and after execution. Defaults to <literal>no</literal>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>TTYRows=</varname></term>
+        <term><varname>TTYColumns=</varname></term>
+
+        <listitem><para>Configure the size of the TTY specified with <varname>TTYPath=</varname>. If unset or
+        set to the empty string, the kernel default is used.</para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>TTYVTDisallocate=</varname></term>
+
+        <listitem><para>If the terminal device specified with <varname>TTYPath=</varname> is a virtual console
+        terminal, try to deallocate the TTY before and after execution. This ensures that the screen and scrollback
+        buffer is cleared. Defaults to <literal>no</literal>.</para></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Credentials</title>
+
+    <variablelist class='unit-directives'>
+
+      <varlistentry>
+        <term><varname>LoadCredential=</varname><replaceable>ID</replaceable><optional>:<replaceable>PATH</replaceable></optional></term>
+        <term><varname>LoadCredentialEncrypted=</varname><replaceable>ID</replaceable><optional>:<replaceable>PATH</replaceable></optional></term>
+
+        <listitem><para>Pass a credential to the unit. Credentials are limited-size binary or textual objects
+        that may be passed to unit processes. They are primarily used for passing cryptographic keys (both
+        public and private) or certificates, user account information or identity information from host to
+        services. The data is accessible from the unit's processes via the file system, at a read-only
+        location that (if possible and permitted) is backed by non-swappable memory. The data is only
+        accessible to the user associated with the unit, via the
+        <varname>User=</varname>/<varname>DynamicUser=</varname> settings (as well as the superuser). When
+        available, the location of credentials is exported as the <varname>$CREDENTIALS_DIRECTORY</varname>
+        environment variable to the unit's processes.</para>
+
+        <para>The <varname>LoadCredential=</varname> setting takes a textual ID to use as name for a
+        credential plus a file system path, separated by a colon. The ID must be a short ASCII string
+        suitable as filename in the filesystem, and may be chosen freely by the user. If the specified path
+        is absolute it is opened as regular file and the credential data is read from it. If the absolute
+        path refers to an <constant>AF_UNIX</constant> stream socket in the file system a connection is made
+        to it (only once at unit start-up) and the credential data read from the connection, providing an
+        easy IPC integration point for dynamically transferring credentials from other services.</para>
+
+        <para>If the specified path is not absolute and itself qualifies as valid credential identifier it is
+        attempted to find a credential that the service manager itself received under the specified name —
+        which may be used to propagate credentials from an invoking environment (e.g. a container manager
+        that invoked the service manager) into a service. If no matching system credential is found, the
+        directories <filename>/etc/credstore/</filename>, <filename>/run/credstore/</filename> and
+        <filename>/usr/lib/credstore/</filename> are searched for files under the credential's name — which
+        hence are recommended locations for credential data on disk. If
+        <varname>LoadCredentialEncrypted=</varname> is used <filename>/run/credstore.encrypted/</filename>,
+        <filename>/etc/credstore.encrypted/</filename>, and
+        <filename>/usr/lib/credstore.encrypted/</filename> are searched as well.</para>
+
+        <para>If the file system path is omitted it is chosen identical to the credential name, i.e. this is
+        a terse way to declare credentials to inherit from the service manager into a service. This option
+        may be used multiple times, each time defining an additional credential to pass to the unit.</para>
+
+        <para>If an absolute path referring to a directory is specified, every file in that directory
+        (recursively) will be loaded as a separate credential. The ID for each credential will be the
+        provided ID suffixed with <literal>_$FILENAME</literal> (e.g., <literal>Key_file1</literal>). When
+        loading from a directory, symlinks will be ignored.</para>
+
+        <para>The contents of the file/socket may be arbitrary binary or textual data, including newline
+        characters and <constant>NUL</constant> bytes.</para>
+
+        <para>The <varname>LoadCredentialEncrypted=</varname> setting is identical to
+        <varname>LoadCredential=</varname>, except that the credential data is decrypted and authenticated
+        before being passed on to the executed processes. Specifically, the referenced path should refer to a
+        file or socket with an encrypted credential, as implemented by
+        <citerefentry><refentrytitle>systemd-creds</refentrytitle><manvolnum>1</manvolnum></citerefentry>. This
+        credential is loaded, decrypted, authenticated and then passed to the application in plaintext form,
+        in the same way a regular credential specified via <varname>LoadCredential=</varname> would be. A
+        credential configured this way may be symmetrically encrypted/authenticated with a secret key derived
+        from the system's TPM2 security chip, or with a secret key stored in
+        <filename>/var/lib/systemd/credentials.secret</filename>, or with both. Using encrypted and
+        authenticated credentials improves security as credentials are not stored in plaintext and only
+        authenticated and decrypted into plaintext the moment a service requiring them is started. Moreover,
+        credentials may be bound to the local hardware and installations, so that they cannot easily be
+        analyzed offline, or be generated externally. When <varname>DevicePolicy=</varname> is set to
+        <literal>closed</literal> or <literal>strict</literal>, or set to <literal>auto</literal> and
+        <varname>DeviceAllow=</varname> is set, or <varname>PrivateDevices=</varname> is set, then this
+        setting adds <filename>/dev/tpmrm0</filename> with <constant>rw</constant> mode to
+        <varname>DeviceAllow=</varname>. See
+        <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for the details about <varname>DevicePolicy=</varname> or <varname>DeviceAllow=</varname>.</para>
+
+        <para>The credential files/IPC sockets must be accessible to the service manager, but don't have to
+        be directly accessible to the unit's processes: the credential data is read and copied into separate,
+        read-only copies for the unit that are accessible to appropriately privileged processes. This is
+        particularly useful in combination with <varname>DynamicUser=</varname> as this way privileged data
+        can be made available to processes running under a dynamic UID (i.e. not a previously known one)
+        without having to open up access to all users.</para>
+
+        <para>In order to reference the path a credential may be read from within a
+        <varname>ExecStart=</varname> command line use <literal>${CREDENTIALS_DIRECTORY}/mycred</literal>,
+        e.g. <literal>ExecStart=cat ${CREDENTIALS_DIRECTORY}/mycred</literal>. In order to reference the path
+        a credential may be read from within a <varname>Environment=</varname> line use
+        <literal>%d/mycred</literal>, e.g. <literal>Environment=MYCREDPATH=%d/mycred</literal>. For system
+        services the path may also be referenced as
+        <literal>/run/credentials/<replaceable>UNITNAME</replaceable></literal> in cases where no
+        interpolation is possible, e.g. configuration files of software that does not yet support credentials
+        natively. <varname>$CREDENTIALS_DIRECTORY</varname> is considered the primary interface to look for
+        credentials, though, since it also works for user services.</para>
+
+        <para>Currently, an accumulated credential size limit of 1 MB per unit is enforced.</para>
+
+        <para>The service manager itself may receive system credentials that can be propagated to services
+        from a hosting container manager or VM hypervisor. See the <ulink
+        url="https://systemd.io/CONTAINER_INTERFACE">Container Interface</ulink> documentation for details
+        about the former. For the latter, pass <ulink
+        url="https://www.dmtf.org/standards/smbios">DMI/SMBIOS</ulink> OEM string table entries (field type
+        11) with a prefix of <literal>io.systemd.credential:</literal> or
+        <literal>io.systemd.credential.binary:</literal>. In both cases a key/value pair separated by
+        <literal>=</literal> is expected, in the latter case the right-hand side is Base64 decoded when
+        parsed (thus permitting binary data to be passed in). Example <ulink
+        url="https://www.qemu.org/docs/master/system/index.html">qemu</ulink> switch: <literal>-smbios
+        type=11,value=io.systemd.credential:xx=yy</literal>, or <literal>-smbios
+        type=11,value=io.systemd.credential.binary:rick=TmV2ZXIgR29ubmEgR2l2ZSBZb3UgVXA=</literal>. Alternatively,
+        use the <command>qemu</command> <literal>fw_cfg</literal> node
+        <literal>opt/io.systemd.credentials/</literal>. Example <command>qemu</command> switch:
+        <literal>-fw_cfg name=opt/io.systemd.credentials/mycred,string=supersecret</literal>. They may also
+        be passed from the UEFI firmware environment via
+        <citerefentry><refentrytitle>systemd-stub</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+        from the initrd (see
+        <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>), or be
+        specified on the kernel command line using the <literal>systemd.set_credential=</literal> and
+        <literal>systemd.set_credential_binary=</literal> switches (see
+        <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> – this is
+        not recommended since unprivileged userspace can read the kernel command line). </para>
+
+        <para>If referencing an <constant>AF_UNIX</constant> stream socket to connect to, the connection will
+        originate from an abstract namespace socket, that includes information about the unit and the
+        credential ID in its socket name. Use <citerefentry
+        project='man-pages'><refentrytitle>getpeername</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+        to query this information. The returned socket name is formatted as <constant>NUL</constant>
+        <replaceable>RANDOM</replaceable> <literal>/unit/</literal> <replaceable>UNIT</replaceable>
+        <literal>/</literal> <replaceable>ID</replaceable>, i.e. a <constant>NUL</constant> byte (as required
+        for abstract namespace socket names), followed by a random string (consisting of alphadecimal
+        characters), followed by the literal string <literal>/unit/</literal>, followed by the requesting
+        unit name, followed by the literal character <literal>/</literal>, followed by the textual credential
+        ID requested. Example: <literal>\0adf9d86b6eda275e/unit/foobar.service/credx</literal> in case the
+        credential <literal>credx</literal> is requested for a unit <literal>foobar.service</literal>. This
+        functionality is useful for using a single listening socket to serve credentials to multiple
+        consumers.</para>
+
+        <para>For further information see <ulink url="https://systemd.io/CREDENTIALS">System and Service
+        Credentials</ulink> documentation.</para>
+
+        <xi:include href="version-info.xml" xpointer="v247"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ImportCredential=</varname><replaceable>GLOB</replaceable></term>
+
+        <listitem><para>Pass one or more credentials to the unit. Takes a credential name for which we'll
+        attempt to find a credential that the service manager itself received under the specified name —
+        which may be used to propagate credentials from an invoking environment (e.g. a container manager
+        that invoked the service manager) into a service. If the credential name is a glob, all credentials
+        matching the glob are passed to the unit. Matching credentials are searched for in the system
+        credentials, the encrypted system credentials, and under <filename>/etc/credstore/</filename>,
+        <filename>/run/credstore/</filename>, <filename>/usr/lib/credstore/</filename>,
+        <filename>/run/credstore.encrypted/</filename>, <filename>/etc/credstore.encrypted/</filename>, and
+        <filename>/usr/lib/credstore.encrypted/</filename> in that order. When multiple credentials of the
+        same name are found, the first one found is used.</para>
+
+        <para>The globbing expression implements a restrictive subset of <citerefentry
+        project='man-pages'><refentrytitle>glob</refentrytitle><manvolnum>7</manvolnum></citerefentry>: only
+        a single trailing <literal>*</literal> wildcard may be specified. Both <literal>?</literal> and
+        <literal>[]</literal> wildcards are not permitted, nor are <literal>*</literal> wildcards anywhere
+        except at the end of the glob expression.</para>
+
+        <para>When multiple credentials of the same name are found, credentials found by
+        <varname>LoadCredential=</varname> and <varname>LoadCredentialEncrypted=</varname> take priority over
+        credentials found by <varname>ImportCredential=</varname>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SetCredential=</varname><replaceable>ID</replaceable>:<replaceable>VALUE</replaceable></term>
+        <term><varname>SetCredentialEncrypted=</varname><replaceable>ID</replaceable>:<replaceable>VALUE</replaceable></term>
+
+        <listitem><para>The <varname>SetCredential=</varname> setting is similar to
+        <varname>LoadCredential=</varname> but accepts a literal value to use as data for the credential,
+        instead of a file system path to read the data from. Do not use this option for data that is supposed
+        to be secret, as it is accessible to unprivileged processes via IPC. It's only safe to use this for
+        user IDs, public key material and similar non-sensitive data. For everything else use
+        <varname>LoadCredential=</varname>. In order to embed binary data into the credential data use
+        C-style escaping (i.e. <literal>\n</literal> to embed a newline, or <literal>\x00</literal> to embed
+        a <constant>NUL</constant> byte).</para>
+
+        <para>The <varname>SetCredentialEncrypted=</varname> setting is identical to
+        <varname>SetCredential=</varname> but expects an encrypted credential in literal form as value. This
+        allows embedding confidential credentials securely directly in unit files. Use
+        <citerefentry><refentrytitle>systemd-creds</refentrytitle><manvolnum>1</manvolnum></citerefentry>'
+        <option>-p</option> switch to generate suitable <varname>SetCredentialEncrypted=</varname> lines
+        directly from plaintext credentials. For further details see
+        <varname>LoadCredentialEncrypted=</varname> above.</para>
+
+        <para>When multiple credentials of the same name are found, credentials found by
+        <varname>LoadCredential=</varname>, <varname>LoadCredentialEncrypted=</varname> and
+        <varname>ImportCredential=</varname> take priority over credentials found by
+        <varname>SetCredential=</varname>. As such, <varname>SetCredential=</varname> will act as default if
+        no credentials are found by any of the former. In this case not being able to retrieve the credential
+        from the path specified in <varname>LoadCredential=</varname> or
+        <varname>LoadCredentialEncrypted=</varname> is not considered fatal.</para>
+
+        <xi:include href="version-info.xml" xpointer="v247"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>System V Compatibility</title>
+    <variablelist class='unit-directives'>
+
+      <varlistentry>
+        <term><varname>UtmpIdentifier=</varname></term>
+
+        <listitem><para>Takes a four character identifier string for an <citerefentry
+        project='man-pages'><refentrytitle>utmp</refentrytitle><manvolnum>5</manvolnum></citerefentry> and wtmp entry
+        for this service. This should only be set for services such as <command>getty</command> implementations (such
+        as <citerefentry
+        project='die-net'><refentrytitle>agetty</refentrytitle><manvolnum>8</manvolnum></citerefentry>) where utmp/wtmp
+        entries must be created and cleared before and after execution, or for services that shall be executed as if
+        they were run by a <command>getty</command> process (see below). If the configured string is longer than four
+        characters, it is truncated and the terminal four characters are used. This setting interprets %I style string
+        replacements. This setting is unset by default, i.e. no utmp/wtmp entries are created or cleaned up for this
+        service.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+         <term><varname>UtmpMode=</varname></term>
+
+         <listitem><para>Takes one of <literal>init</literal>, <literal>login</literal> or <literal>user</literal>. If
+         <varname>UtmpIdentifier=</varname> is set, controls which type of <citerefentry
+         project='man-pages'><refentrytitle>utmp</refentrytitle><manvolnum>5</manvolnum></citerefentry>/wtmp entries
+         for this service are generated. This setting has no effect unless <varname>UtmpIdentifier=</varname> is set
+         too. If <literal>init</literal> is set, only an <constant>INIT_PROCESS</constant> entry is generated and the
+         invoked process must implement a <command>getty</command>-compatible utmp/wtmp logic. If
+         <literal>login</literal> is set, first an <constant>INIT_PROCESS</constant> entry, followed by a
+         <constant>LOGIN_PROCESS</constant> entry is generated. In this case, the invoked process must implement a
+         <citerefentry
+         project='die-net'><refentrytitle>login</refentrytitle><manvolnum>1</manvolnum></citerefentry>-compatible
+         utmp/wtmp logic. If <literal>user</literal> is set, first an <constant>INIT_PROCESS</constant> entry, then a
+         <constant>LOGIN_PROCESS</constant> entry and finally a <constant>USER_PROCESS</constant> entry is
+         generated. In this case, the invoked process may be any process that is suitable to be run as session
+         leader. Defaults to <literal>init</literal>.</para>
+
+         <xi:include href="version-info.xml" xpointer="v225"/></listitem>
+      </varlistentry>
+
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Environment Variables in Spawned Processes</title>
+
+    <para>Processes started by the service manager are executed with an environment variable block assembled from
+    multiple sources. Processes started by the system service manager generally do not inherit environment variables
+    set for the service manager itself (but this may be altered via <varname>PassEnvironment=</varname>), but processes
+    started by the user service manager instances generally do inherit all environment variables set for the service
+    manager itself.</para>
+
+    <para>For each invoked process the list of environment variables set is compiled from the following sources:</para>
+
+    <itemizedlist>
+      <listitem><para>Variables globally configured for the service manager, using the
+      <varname>DefaultEnvironment=</varname> setting in
+      <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      the kernel command line option <varname>systemd.setenv=</varname> understood by
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, or via
+      <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+      <command>set-environment</command> verb.</para></listitem>
+
+      <listitem><para>Variables defined by the service manager itself (see the list below).</para></listitem>
+
+      <listitem><para>Variables set in the service manager's own environment variable block (subject to
+      <varname>PassEnvironment=</varname> for the system service manager).</para></listitem>
+
+      <listitem><para>Variables set via <varname>Environment=</varname> in the unit file.</para></listitem>
+
+      <listitem><para>Variables read from files specified via <varname>EnvironmentFile=</varname> in the unit
+      file.</para></listitem>
+
+      <listitem><para>Variables set by any PAM modules in case <varname>PAMName=</varname> is in effect,
+      cf. <citerefentry
+      project='man-pages'><refentrytitle>pam_env</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+      </para></listitem>
+    </itemizedlist>
+
+    <para>If the same environment variable is set by multiple of these sources, the later source — according
+    to the order of the list above — wins. Note that as the final step all variables listed in
+    <varname>UnsetEnvironment=</varname> are removed from the compiled environment variable list, immediately
+    before it is passed to the executed process.</para>
+
+    <para>The general philosophy is to expose a small curated list of environment variables to processes.
+    Services started by the system manager (PID 1) will be started, without additional service-specific
+    configuration, with just a few environment variables. The user manager inherits environment variables as
+    any other system service, but in addition may receive additional environment variables from PAM, and,
+    typically, additional imported variables when the user starts a graphical session. It is recommended to
+    keep the environment blocks in both the system and user managers lean. Importing all variables
+    inherited by the graphical session or by one of the user shells is strongly discouraged.</para>
+
+    <para>Hint: <command>systemd-run -P env</command> and <command>systemd-run --user -P env</command> print
+    the effective system and user service environment blocks.</para>
+
+    <refsect2>
+      <title>Environment Variables Set or Propagated by the Service Manager</title>
+
+      <para>The following environment variables are propagated by the service manager or generated internally
+      for each invoked process:</para>
+
+      <variablelist class='environment-variables'>
+        <varlistentry>
+          <term><varname>$PATH</varname></term>
+
+          <listitem><para>Colon-separated list of directories to use when launching
+          executables. <command>systemd</command> uses a fixed value of
+          <literal><filename>/usr/local/sbin</filename>:<filename>/usr/local/bin</filename>:<filename>/usr/sbin</filename>:<filename>/usr/bin</filename></literal>
+          in the system manager. In case of the user manager, a different path may be configured by the
+          distribution. It is recommended to not rely on the order of entries, and have only one program
+          with a given name in <varname>$PATH</varname>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v208"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>$LANG</varname></term>
+
+          <listitem><para>Locale. Can be set in <citerefentry
+          project='man-pages'><refentrytitle>locale.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+          or on the kernel command line (see
+          <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> and
+          <citerefentry><refentrytitle>kernel-command-line</refentrytitle><manvolnum>7</manvolnum></citerefentry>).
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v208"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>$USER</varname></term>
+          <term><varname>$LOGNAME</varname></term>
+          <term><varname>$HOME</varname></term>
+          <term><varname>$SHELL</varname></term>
+
+          <listitem><para>User name (twice), home directory, and the login shell. <varname>$USER</varname> is
+          set unconditionally, while <varname>$HOME</varname>, <varname>$LOGNAME</varname>, and <varname>$SHELL</varname>
+          are only set for the units that have <varname>User=</varname> set and <varname>SetLoginEnvironment=</varname>
+          unset or set to true. For user services, these variables are typically inherited from the user manager itself. See
+          <citerefentry project='die-net'><refentrytitle>passwd</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v208"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>$INVOCATION_ID</varname></term>
+
+          <listitem><para>Contains a randomized, unique 128-bit ID identifying each runtime cycle of the unit, formatted
+          as 32 character hexadecimal string. A new ID is assigned each time the unit changes from an inactive state into
+          an activating or active state, and may be used to identify this specific runtime cycle, in particular in data
+          stored offline, such as the journal. The same ID is passed to all processes run as part of the
+          unit.</para>
+
+          <xi:include href="version-info.xml" xpointer="v232"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>$XDG_RUNTIME_DIR</varname></term>
+
+          <listitem><para>The directory to use for runtime objects (such as IPC objects) and volatile state. Set for all
+          services run by the user <command>systemd</command> instance, as well as any system services that use
+          <varname>PAMName=</varname> with a PAM stack that includes <command>pam_systemd</command>. See below and
+          <citerefentry><refentrytitle>pam_systemd</refentrytitle><manvolnum>8</manvolnum></citerefentry> for more
+          information.</para>
+
+          <xi:include href="version-info.xml" xpointer="v208"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>$RUNTIME_DIRECTORY</varname></term>
+          <term><varname>$STATE_DIRECTORY</varname></term>
+          <term><varname>$CACHE_DIRECTORY</varname></term>
+          <term><varname>$LOGS_DIRECTORY</varname></term>
+          <term><varname>$CONFIGURATION_DIRECTORY</varname></term>
+
+          <listitem><para>Absolute paths to the directories defined with
+          <varname>RuntimeDirectory=</varname>, <varname>StateDirectory=</varname>,
+          <varname>CacheDirectory=</varname>, <varname>LogsDirectory=</varname>, and
+          <varname>ConfigurationDirectory=</varname> when those settings are used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v244"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>$CREDENTIALS_DIRECTORY</varname></term>
+
+          <listitem><para>An absolute path to the per-unit directory with credentials configured via
+          <varname>ImportCredential=</varname>/<varname>LoadCredential=</varname>/<varname>SetCredential=</varname>.
+          The directory is marked read-only and is placed in unswappable memory (if supported and permitted),
+          and is only accessible to the UID associated with the unit via <varname>User=</varname> or
+          <varname>DynamicUser=</varname> (and the superuser).</para>
+
+          <xi:include href="version-info.xml" xpointer="v247"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>$MAINPID</varname></term>
+
+          <listitem><para>The PID of the unit's main process if it is
+          known. This is only set for control processes as invoked by
+          <varname>ExecReload=</varname> and similar.</para>
+
+          <xi:include href="version-info.xml" xpointer="v209"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>$MANAGERPID</varname></term>
+
+          <listitem><para>The PID of the user <command>systemd</command>
+          instance, set for processes spawned by it.</para>
+
+          <xi:include href="version-info.xml" xpointer="v208"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>$LISTEN_FDS</varname></term>
+          <term><varname>$LISTEN_PID</varname></term>
+          <term><varname>$LISTEN_FDNAMES</varname></term>
+
+          <listitem><para>Information about file descriptors passed to a
+          service for socket activation. See
+          <citerefentry><refentrytitle>sd_listen_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v208"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>$NOTIFY_SOCKET</varname></term>
+
+          <listitem><para>The socket <function>sd_notify()</function> talks to. See
+          <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v229"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>$WATCHDOG_PID</varname></term>
+          <term><varname>$WATCHDOG_USEC</varname></term>
+
+          <listitem><para>Information about watchdog keep-alive notifications. See
+          <citerefentry><refentrytitle>sd_watchdog_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v229"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>$SYSTEMD_EXEC_PID</varname></term>
+
+          <listitem><para>The PID of the unit process (e.g. process invoked by
+          <varname>ExecStart=</varname>). The child process can use this information to determine
+          whether the process is directly invoked by the service manager or indirectly as a child of
+          another process by comparing this value with the current PID (similarly to the scheme used in
+          <citerefentry><refentrytitle>sd_listen_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+          with <varname>$LISTEN_PID</varname> and <varname>$LISTEN_FDS</varname>).</para>
+
+          <xi:include href="version-info.xml" xpointer="v248"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>$TERM</varname></term>
+
+          <listitem><para>Terminal type, set only for units connected to
+          a terminal (<varname>StandardInput=tty</varname>,
+          <varname>StandardOutput=tty</varname>, or
+          <varname>StandardError=tty</varname>). See
+          <citerefentry project='man-pages'><refentrytitle>termcap</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v209"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>$LOG_NAMESPACE</varname></term>
+
+          <listitem><para>Contains the name of the selected logging namespace when the
+          <varname>LogNamespace=</varname> service setting is used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>$JOURNAL_STREAM</varname></term>
+
+          <listitem><para>If the standard output or standard error output of the executed processes are connected to the
+          journal (for example, by setting <varname>StandardError=journal</varname>) <varname>$JOURNAL_STREAM</varname>
+          contains the device and inode numbers of the connection file descriptor, formatted in decimal, separated by a
+          colon (<literal>:</literal>). This permits invoked processes to safely detect whether their standard output or
+          standard error output are connected to the journal. The device and inode numbers of the file descriptors should
+          be compared with the values set in the environment variable to determine whether the process output is still
+          connected to the journal. Note that it is generally not sufficient to only check whether
+          <varname>$JOURNAL_STREAM</varname> is set at all as services might invoke external processes replacing their
+          standard output or standard error output, without unsetting the environment variable.</para>
+
+          <para>If both standard output and standard error of the executed processes are connected to the journal via a
+          stream socket, this environment variable will contain information about the standard error stream, as that's
+          usually the preferred destination for log data. (Note that typically the same stream is used for both standard
+          output and standard error, hence very likely the environment variable contains device and inode information
+          matching both stream file descriptors.)</para>
+
+          <para>This environment variable is primarily useful to allow services to optionally upgrade their used log
+          protocol to the native journal protocol (using
+          <citerefentry><refentrytitle>sd_journal_print</refentrytitle><manvolnum>3</manvolnum></citerefentry> and other
+          functions) if their standard output or standard error output is connected to the journal anyway, thus enabling
+          delivery of structured metadata along with logged messages.</para>
+
+          <xi:include href="version-info.xml" xpointer="v231"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>$SERVICE_RESULT</varname></term>
+
+          <listitem><para>Only used for the service unit type. This environment variable is passed to all
+          <varname>ExecStop=</varname> and <varname>ExecStopPost=</varname> processes, and encodes the service
+          "result". Currently, the following values are defined:</para>
+
+          <table>
+            <title>Defined <varname>$SERVICE_RESULT</varname> values</title>
+            <tgroup cols='2'>
+              <colspec colname='result'/>
+              <colspec colname='meaning'/>
+              <thead>
+                <row>
+                  <entry>Value</entry>
+                  <entry>Meaning</entry>
+                </row>
+              </thead>
+
+              <tbody>
+                <row>
+                  <entry><literal>success</literal></entry>
+                  <entry>The service ran successfully and exited cleanly.</entry>
+                </row>
+                <row>
+                  <entry><literal>protocol</literal></entry>
+                  <entry>A protocol violation occurred: the service did not take the steps required by its unit configuration (specifically what is configured in its <varname>Type=</varname> setting).</entry>
+                </row>
+                <row>
+                  <entry><literal>timeout</literal></entry>
+                  <entry>One of the steps timed out.</entry>
+                </row>
+                <row>
+                  <entry><literal>exit-code</literal></entry>
+                  <entry>Service process exited with a non-zero exit code; see <varname>$EXIT_CODE</varname> below for the actual exit code returned.</entry>
+                </row>
+                <row>
+                  <entry><literal>signal</literal></entry>
+                  <entry>A service process was terminated abnormally by a signal, without dumping core. See <varname>$EXIT_CODE</varname> below for the actual signal causing the termination.</entry>
+                </row>
+                <row>
+                  <entry><literal>core-dump</literal></entry>
+                  <entry>A service process terminated abnormally with a signal and dumped core. See <varname>$EXIT_CODE</varname> below for the signal causing the termination.</entry>
+                </row>
+                <row>
+                  <entry><literal>watchdog</literal></entry>
+                  <entry>Watchdog keep-alive ping was enabled for the service, but the deadline was missed.</entry>
+                </row>
+                <row>
+                  <entry><literal>exec-condition</literal></entry>
+                  <entry>Service did not run because <varname>ExecCondition=</varname> failed.</entry>
+                </row>
+                <row>
+                  <entry><literal>oom-kill</literal></entry>
+                  <entry>A service process was terminated by the Out-Of-Memory (OOM) killer.</entry>
+                </row>
+                <row>
+                  <entry><literal>start-limit-hit</literal></entry>
+                  <entry>A start limit was defined for the unit and it was hit, causing the unit to fail to start. See <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>'s <varname>StartLimitIntervalSec=</varname> and <varname>StartLimitBurst=</varname> for details.</entry>
+                </row>
+                <row>
+                  <entry><literal>resources</literal></entry>
+                  <entry>A catch-all condition in case a system operation failed.</entry>
+                </row>
+              </tbody>
+            </tgroup>
+          </table>
+
+          <para>This environment variable is useful to monitor failure or successful termination of a service. Even
+          though this variable is available in both <varname>ExecStop=</varname> and <varname>ExecStopPost=</varname>, it
+          is usually a better choice to place monitoring tools in the latter, as the former is only invoked for services
+          that managed to start up correctly, and the latter covers both services that failed during their start-up and
+          those which failed during their runtime.</para>
+
+          <xi:include href="version-info.xml" xpointer="v232"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>$EXIT_CODE</varname></term>
+          <term><varname>$EXIT_STATUS</varname></term>
+
+          <listitem><para>Only defined for the service unit type. These environment variables are passed to all
+          <varname>ExecStop=</varname>, <varname>ExecStopPost=</varname> processes and contain exit status/code
+          information of the main process of the service. For the precise definition of the exit code and status, see
+          <citerefentry><refentrytitle>wait</refentrytitle><manvolnum>2</manvolnum></citerefentry>. <varname>$EXIT_CODE</varname>
+          is one of <literal>exited</literal>, <literal>killed</literal>,
+          <literal>dumped</literal>. <varname>$EXIT_STATUS</varname> contains the numeric exit code formatted as string
+          if <varname>$EXIT_CODE</varname> is <literal>exited</literal>, and the signal name in all other cases. Note
+          that these environment variables are only set if the service manager succeeded to start and identify the main
+          process of the service.</para>
+
+          <table>
+            <title>Summary of possible service result variable values</title>
+            <tgroup cols='3'>
+              <colspec colname='result' />
+              <colspec colname='code' />
+              <colspec colname='status' />
+              <thead>
+                <row>
+                  <entry><varname>$SERVICE_RESULT</varname></entry>
+                  <entry><varname>$EXIT_CODE</varname></entry>
+                  <entry><varname>$EXIT_STATUS</varname></entry>
+                </row>
+              </thead>
+
+              <tbody>
+                <row>
+                  <entry morerows="1" valign="top"><literal>success</literal></entry>
+                  <entry valign="top"><literal>killed</literal></entry>
+                  <entry><literal>HUP</literal>, <literal>INT</literal>, <literal>TERM</literal>, <literal>PIPE</literal></entry>
+                </row>
+                <row>
+                  <entry valign="top"><literal>exited</literal></entry>
+                  <entry><literal>0</literal></entry>
+                </row>
+                <row>
+                  <entry morerows="1" valign="top"><literal>protocol</literal></entry>
+                  <entry valign="top">not set</entry>
+                  <entry>not set</entry>
+                </row>
+                <row>
+                  <entry><literal>exited</literal></entry>
+                  <entry><literal>0</literal></entry>
+                </row>
+                <row>
+                  <entry morerows="1" valign="top"><literal>timeout</literal></entry>
+                  <entry valign="top"><literal>killed</literal></entry>
+                  <entry><literal>TERM</literal>, <literal>KILL</literal></entry>
+                </row>
+                <row>
+                  <entry valign="top"><literal>exited</literal></entry>
+                  <entry><literal>0</literal>, <literal>1</literal>, <literal>2</literal>, <literal
+                  >3</literal>, …, <literal>255</literal></entry>
+                </row>
+                <row>
+                  <entry valign="top"><literal>exit-code</literal></entry>
+                  <entry valign="top"><literal>exited</literal></entry>
+                  <entry><literal>1</literal>, <literal>2</literal>, <literal
+                  >3</literal>, …, <literal>255</literal></entry>
+                </row>
+                <row>
+                  <entry valign="top"><literal>signal</literal></entry>
+                  <entry valign="top"><literal>killed</literal></entry>
+                  <entry><literal>HUP</literal>, <literal>INT</literal>, <literal>KILL</literal>, …</entry>
+                </row>
+                <row>
+                  <entry valign="top"><literal>core-dump</literal></entry>
+                  <entry valign="top"><literal>dumped</literal></entry>
+                  <entry><literal>ABRT</literal>, <literal>SEGV</literal>, <literal>QUIT</literal>, …</entry>
+                </row>
+                <row>
+                  <entry morerows="2" valign="top"><literal>watchdog</literal></entry>
+                  <entry><literal>dumped</literal></entry>
+                  <entry><literal>ABRT</literal></entry>
+                </row>
+                <row>
+                  <entry><literal>killed</literal></entry>
+                  <entry><literal>TERM</literal>, <literal>KILL</literal></entry>
+                </row>
+                <row>
+                  <entry><literal>exited</literal></entry>
+                  <entry><literal>0</literal>, <literal>1</literal>, <literal>2</literal>, <literal
+                  >3</literal>, …, <literal>255</literal></entry>
+                </row>
+                <row>
+                  <entry valign="top"><literal>exec-condition</literal></entry>
+                  <entry><literal>exited</literal></entry>
+                  <entry><literal>1</literal>, <literal>2</literal>, <literal>3</literal>, <literal
+                  >4</literal>, …, <literal>254</literal></entry>
+                </row>
+                <row>
+                  <entry valign="top"><literal>oom-kill</literal></entry>
+                  <entry valign="top"><literal>killed</literal></entry>
+                  <entry><literal>TERM</literal>, <literal>KILL</literal></entry>
+                </row>
+                <row>
+                  <entry><literal>start-limit-hit</literal></entry>
+                  <entry>not set</entry>
+                  <entry>not set</entry>
+                </row>
+                <row>
+                  <entry><literal>resources</literal></entry>
+                  <entry>any of the above</entry>
+                  <entry>any of the above</entry>
+                </row>
+                <row>
+                  <entry namest="results" nameend="status">Note: the process may be also terminated by a signal not sent by systemd. In particular the process may send an arbitrary signal to itself in a handler for any of the non-maskable signals. Nevertheless, in the <literal>timeout</literal> and <literal>watchdog</literal> rows above only the signals that systemd sends have been included. Moreover, using <varname>SuccessExitStatus=</varname> additional exit statuses may be declared to indicate clean termination, which is not reflected by this table.</entry>
+                </row>
+              </tbody>
+            </tgroup>
+          </table>
+
+            <xi:include href="version-info.xml" xpointer="v232"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>$MONITOR_SERVICE_RESULT</varname></term>
+          <term><varname>$MONITOR_EXIT_CODE</varname></term>
+          <term><varname>$MONITOR_EXIT_STATUS</varname></term>
+          <term><varname>$MONITOR_INVOCATION_ID</varname></term>
+          <term><varname>$MONITOR_UNIT</varname></term>
+
+          <listitem><para>Only defined for the service unit type. Those environment variables are passed to
+          all <varname>ExecStart=</varname> and <varname>ExecStartPre=</varname> processes which run in
+          services triggered by <varname>OnFailure=</varname> or <varname>OnSuccess=</varname> dependencies.
+          </para>
+
+          <para>Variables <varname>$MONITOR_SERVICE_RESULT</varname>, <varname>$MONITOR_EXIT_CODE</varname>
+          and <varname>$MONITOR_EXIT_STATUS</varname> take the same values as for
+          <varname>ExecStop=</varname> and <varname>ExecStopPost=</varname> processes. Variables
+          <varname>$MONITOR_INVOCATION_ID</varname> and <varname>$MONITOR_UNIT</varname> are set to the
+          invocation id and unit name of the service which triggered the dependency.</para>
+
+          <para>Note that when multiple services trigger the same unit, those variables will be
+          <emphasis>not</emphasis> be passed. Consider using a template handler unit for that case instead:
+          <literal>OnFailure=<replaceable>handler</replaceable>@%n.service</literal> for non-templated units,
+          or <literal>OnFailure=<replaceable>handler</replaceable>@%p-%i.service</literal> for templated
+          units.</para>
+
+          <xi:include href="version-info.xml" xpointer="v251"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>$PIDFILE</varname></term>
+
+          <listitem><para>The path to the configured PID file, in case the process is forked off on behalf of
+          a service that uses the <varname>PIDFile=</varname> setting, see
+          <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+          for details. Service code may use this environment variable to automatically generate a PID file at
+          the location configured in the unit file. This field is set to an absolute path in the file
+          system.</para>
+
+          <xi:include href="version-info.xml" xpointer="v242"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>$REMOTE_ADDR</varname></term>
+          <term><varname>$REMOTE_PORT</varname></term>
+
+          <listitem><para>If this is a unit started via per-connection socket activation (i.e. via a socket
+          unit with <varname>Accept=yes</varname>), these environment variables contain the IP address and
+          port number of the remote peer of the socket connection.</para>
+
+          <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>$TRIGGER_UNIT</varname></term>
+          <term><varname>$TRIGGER_PATH</varname></term>
+          <term><varname>$TRIGGER_TIMER_REALTIME_USEC</varname></term>
+          <term><varname>$TRIGGER_TIMER_MONOTONIC_USEC</varname></term>
+
+          <listitem><para>If the unit was activated dynamically (e.g.: a corresponding path unit or timer unit), the
+          unit that triggered it and other type-dependent information will be passed via these variables. Note that
+          this information is provided in a best-effort way. For example, multiple triggers happening one after
+          another will be coalesced and only one will be reported, with no guarantee as to which one it will be.
+          Because of this, in most cases this variable will be primarily informational, i.e. useful for debugging
+          purposes, is lossy, and should not be relied upon to propagate a comprehensive reason for activation.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>$MEMORY_PRESSURE_WATCH</varname></term>
+          <term><varname>$MEMORY_PRESSURE_WRITE</varname></term>
+
+          <listitem><para>If memory pressure monitoring is enabled for this service unit, the path to watch
+          and the data to write into it. See <ulink url="https://systemd.io/MEMORY_PRESSURE">Memory Pressure
+          Handling</ulink> for details about these variables and the service protocol data they
+          convey.</para>
+
+          <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>$FDSTORE</varname></term>
+
+          <listitem><para>The maximum number of file descriptors that may be stored in the manager for the
+          service. This variable is set when the file descriptor store is enabled for the service, i.e.
+          <varname>FileDescriptorStoreMax=</varname> is set to a non-zero value (see
+          <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+          for details). Applications may check this environment variable before sending file descriptors to
+          the service manager via
+          <citerefentry><refentrytitle>sd_pid_notify_with_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+        </para>
+
+          <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+        </varlistentry>
+
+      </variablelist>
+
+      <para>For system services, when <varname>PAMName=</varname> is enabled and <command>pam_systemd</command> is part
+      of the selected PAM stack, additional environment variables defined by systemd may be set for
+      services. Specifically, these are <varname>$XDG_SEAT</varname>, <varname>$XDG_VTNR</varname>, see
+      <citerefentry><refentrytitle>pam_systemd</refentrytitle><manvolnum>8</manvolnum></citerefentry> for details.</para>
+    </refsect2>
+
+  </refsect1>
+
+  <refsect1>
+    <title>Process Exit Codes</title>
+
+    <para>When invoking a unit process the service manager possibly fails to apply the execution parameters configured
+    with the settings above. In that case the already created service process will exit with a non-zero exit code
+    before the configured command line is executed. (Or in other words, the child process possibly exits with these
+    error codes, after having been created by the <citerefentry
+    project='man-pages'><refentrytitle>fork</refentrytitle><manvolnum>2</manvolnum></citerefentry> system call, but
+    before the matching <citerefentry
+    project='man-pages'><refentrytitle>execve</refentrytitle><manvolnum>2</manvolnum></citerefentry> system call is
+    called.) Specifically, exit codes defined by the C library, by the LSB specification and by the systemd service
+    manager itself are used.</para>
+
+    <para>The following basic service exit codes are defined by the C library.</para>
+
+    <table>
+      <title>Basic C library exit codes</title>
+      <tgroup cols='3'>
+        <thead>
+          <row>
+            <entry>Exit Code</entry>
+            <entry>Symbolic Name</entry>
+            <entry>Description</entry>
+          </row>
+        </thead>
+        <tbody>
+          <row>
+            <entry>0</entry>
+            <entry><constant>EXIT_SUCCESS</constant></entry>
+            <entry>Generic success code.</entry>
+          </row>
+          <row>
+            <entry>1</entry>
+            <entry><constant>EXIT_FAILURE</constant></entry>
+            <entry>Generic failure or unspecified error.</entry>
+          </row>
+        </tbody>
+      </tgroup>
+    </table>
+
+    <para>The following service exit codes are defined by the <ulink
+    url="https://refspecs.linuxbase.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html">LSB specification</ulink>.
+    </para>
+
+    <table>
+      <title>LSB service exit codes</title>
+      <tgroup cols='3'>
+        <thead>
+          <row>
+            <entry>Exit Code</entry>
+            <entry>Symbolic Name</entry>
+            <entry>Description</entry>
+          </row>
+        </thead>
+        <tbody>
+          <row>
+            <entry>2</entry>
+            <entry><constant>EXIT_INVALIDARGUMENT</constant></entry>
+            <entry>Invalid or excess arguments.</entry>
+          </row>
+          <row>
+            <entry>3</entry>
+            <entry><constant>EXIT_NOTIMPLEMENTED</constant></entry>
+            <entry>Unimplemented feature.</entry>
+          </row>
+          <row>
+            <entry>4</entry>
+            <entry><constant>EXIT_NOPERMISSION</constant></entry>
+            <entry>The user has insufficient privileges.</entry>
+          </row>
+          <row>
+            <entry>5</entry>
+            <entry><constant>EXIT_NOTINSTALLED</constant></entry>
+            <entry>The program is not installed.</entry>
+          </row>
+          <row>
+            <entry>6</entry>
+            <entry><constant>EXIT_NOTCONFIGURED</constant></entry>
+            <entry>The program is not configured.</entry>
+          </row>
+          <row>
+            <entry>7</entry>
+            <entry><constant>EXIT_NOTRUNNING</constant></entry>
+            <entry>The program is not running.</entry>
+          </row>
+        </tbody>
+      </tgroup>
+    </table>
+
+    <para>
+      The LSB specification suggests that error codes 200 and above are reserved for implementations. Some of them are
+      used by the service manager to indicate problems during process invocation:
+    </para>
+    <table>
+      <title>systemd-specific exit codes</title>
+      <tgroup cols='3'>
+        <thead>
+          <row>
+            <entry>Exit Code</entry>
+            <entry>Symbolic Name</entry>
+            <entry>Description</entry>
+          </row>
+        </thead>
+        <tbody>
+          <row>
+            <entry>200</entry>
+            <entry><constant>EXIT_CHDIR</constant></entry>
+            <entry>Changing to the requested working directory failed. See <varname>WorkingDirectory=</varname> above.</entry>
+          </row>
+          <row>
+            <entry>201</entry>
+            <entry><constant>EXIT_NICE</constant></entry>
+            <entry>Failed to set up process scheduling priority (nice level). See <varname>Nice=</varname> above.</entry>
+          </row>
+          <row>
+            <entry>202</entry>
+            <entry><constant>EXIT_FDS</constant></entry>
+            <entry>Failed to close unwanted file descriptors, or to adjust passed file descriptors.</entry>
+          </row>
+          <row>
+            <entry>203</entry>
+            <entry><constant>EXIT_EXEC</constant></entry>
+            <entry>The actual process execution failed (specifically, the <citerefentry project='man-pages'><refentrytitle>execve</refentrytitle><manvolnum>2</manvolnum></citerefentry> system call). Most likely this is caused by a missing or non-accessible executable file.</entry>
+          </row>
+          <row>
+            <entry>204</entry>
+            <entry><constant>EXIT_MEMORY</constant></entry>
+            <entry>Failed to perform an action due to memory shortage.</entry>
+          </row>
+          <row>
+            <entry>205</entry>
+            <entry><constant>EXIT_LIMITS</constant></entry>
+            <entry>Failed to adjust resource limits. See <varname>LimitCPU=</varname> and related settings above.</entry>
+          </row>
+          <row>
+            <entry>206</entry>
+            <entry><constant>EXIT_OOM_ADJUST</constant></entry>
+            <entry>Failed to adjust the OOM setting. See <varname>OOMScoreAdjust=</varname> above.</entry>
+          </row>
+          <row>
+            <entry>207</entry>
+            <entry><constant>EXIT_SIGNAL_MASK</constant></entry>
+            <entry>Failed to set process signal mask.</entry>
+          </row>
+          <row>
+            <entry>208</entry>
+            <entry><constant>EXIT_STDIN</constant></entry>
+            <entry>Failed to set up standard input. See <varname>StandardInput=</varname> above.</entry>
+          </row>
+          <row>
+            <entry>209</entry>
+            <entry><constant>EXIT_STDOUT</constant></entry>
+            <entry>Failed to set up standard output. See <varname>StandardOutput=</varname> above.</entry>
+          </row>
+          <row>
+            <entry>210</entry>
+            <entry><constant>EXIT_CHROOT</constant></entry>
+            <entry>Failed to change root directory (<citerefentry project='man-pages'><refentrytitle>chroot</refentrytitle><manvolnum>2</manvolnum></citerefentry>). See <varname>RootDirectory=</varname>/<varname>RootImage=</varname> above.</entry>
+          </row>
+          <row>
+            <entry>211</entry>
+            <entry><constant>EXIT_IOPRIO</constant></entry>
+            <entry>Failed to set up IO scheduling priority. See <varname>IOSchedulingClass=</varname>/<varname>IOSchedulingPriority=</varname> above.</entry>
+          </row>
+          <row>
+            <entry>212</entry>
+            <entry><constant>EXIT_TIMERSLACK</constant></entry>
+            <entry>Failed to set up timer slack. See <varname>TimerSlackNSec=</varname> above.</entry>
+          </row>
+          <row>
+            <entry>213</entry>
+            <entry><constant>EXIT_SECUREBITS</constant></entry>
+            <entry>Failed to set process secure bits. See <varname>SecureBits=</varname> above.</entry>
+          </row>
+          <row>
+            <entry>214</entry>
+            <entry><constant>EXIT_SETSCHEDULER</constant></entry>
+            <entry>Failed to set up CPU scheduling. See <varname>CPUSchedulingPolicy=</varname>/<varname>CPUSchedulingPriority=</varname> above.</entry>
+          </row>
+          <row>
+            <entry>215</entry>
+            <entry><constant>EXIT_CPUAFFINITY</constant></entry>
+            <entry>Failed to set up CPU affinity. See <varname>CPUAffinity=</varname> above.</entry>
+          </row>
+          <row>
+            <entry>216</entry>
+            <entry><constant>EXIT_GROUP</constant></entry>
+            <entry>Failed to determine or change group credentials. See <varname>Group=</varname>/<varname>SupplementaryGroups=</varname> above.</entry>
+          </row>
+          <row>
+            <entry>217</entry>
+            <entry><constant>EXIT_USER</constant></entry>
+            <entry>Failed to determine or change user credentials, or to set up user namespacing. See <varname>User=</varname>/<varname>PrivateUsers=</varname> above.</entry>
+          </row>
+          <row>
+            <entry>218</entry>
+            <entry><constant>EXIT_CAPABILITIES</constant></entry>
+            <entry>Failed to drop capabilities, or apply ambient capabilities. See <varname>CapabilityBoundingSet=</varname>/<varname>AmbientCapabilities=</varname> above.</entry>
+          </row>
+          <row>
+            <entry>219</entry>
+            <entry><constant>EXIT_CGROUP</constant></entry>
+            <entry>Setting up the service control group failed.</entry>
+          </row>
+          <row>
+            <entry>220</entry>
+            <entry><constant>EXIT_SETSID</constant></entry>
+            <entry>Failed to create new process session.</entry>
+          </row>
+          <row>
+            <entry>221</entry>
+            <entry><constant>EXIT_CONFIRM</constant></entry>
+            <entry>Execution has been cancelled by the user. See the <varname>systemd.confirm_spawn=</varname> kernel command line setting on <citerefentry><refentrytitle>kernel-command-line</refentrytitle><manvolnum>7</manvolnum></citerefentry> for details.</entry>
+          </row>
+          <row>
+            <entry>222</entry>
+            <entry><constant>EXIT_STDERR</constant></entry>
+            <entry>Failed to set up standard error output. See <varname>StandardError=</varname> above.</entry>
+          </row>
+          <row>
+            <entry>224</entry>
+            <entry><constant>EXIT_PAM</constant></entry>
+            <entry>Failed to set up PAM session. See <varname>PAMName=</varname> above.</entry>
+          </row>
+          <row>
+            <entry>225</entry>
+            <entry><constant>EXIT_NETWORK</constant></entry>
+            <entry>Failed to set up network namespacing. See <varname>PrivateNetwork=</varname> above.</entry>
+          </row>
+          <row>
+            <entry>226</entry>
+            <entry><constant>EXIT_NAMESPACE</constant></entry>
+            <entry>Failed to set up mount, UTS, or IPC namespacing. See <varname>ReadOnlyPaths=</varname>, <varname>ProtectHostname=</varname>, <varname>PrivateIPC=</varname>, and related settings above.</entry>
+          </row>
+          <row>
+            <entry>227</entry>
+            <entry><constant>EXIT_NO_NEW_PRIVILEGES</constant></entry>
+            <entry>Failed to disable new privileges. See <varname>NoNewPrivileges=yes</varname> above.</entry>
+          </row>
+          <row>
+            <entry>228</entry>
+            <entry><constant>EXIT_SECCOMP</constant></entry>
+            <entry>Failed to apply system call filters. See <varname>SystemCallFilter=</varname> and related settings above.</entry>
+          </row>
+          <row>
+            <entry>229</entry>
+            <entry><constant>EXIT_SELINUX_CONTEXT</constant></entry>
+            <entry>Determining or changing SELinux context failed. See <varname>SELinuxContext=</varname> above.</entry>
+          </row>
+          <row>
+            <entry>230</entry>
+            <entry><constant>EXIT_PERSONALITY</constant></entry>
+            <entry>Failed to set up an execution domain (personality). See <varname>Personality=</varname> above.</entry>
+          </row>
+          <row>
+            <entry>231</entry>
+            <entry><constant>EXIT_APPARMOR_PROFILE</constant></entry>
+            <entry>Failed to prepare changing AppArmor profile. See <varname>AppArmorProfile=</varname> above.</entry>
+          </row>
+          <row>
+            <entry>232</entry>
+            <entry><constant>EXIT_ADDRESS_FAMILIES</constant></entry>
+            <entry>Failed to restrict address families. See <varname>RestrictAddressFamilies=</varname> above.</entry>
+          </row>
+          <row>
+            <entry>233</entry>
+            <entry><constant>EXIT_RUNTIME_DIRECTORY</constant></entry>
+            <entry>Setting up runtime directory failed. See <varname>RuntimeDirectory=</varname> and related settings above.</entry>
+          </row>
+          <row>
+            <entry>235</entry>
+            <entry><constant>EXIT_CHOWN</constant></entry>
+            <entry>Failed to adjust socket ownership. Used for socket units only.</entry>
+          </row>
+          <row>
+            <entry>236</entry>
+            <entry><constant>EXIT_SMACK_PROCESS_LABEL</constant></entry>
+            <entry>Failed to set SMACK label. See <varname>SmackProcessLabel=</varname> above.</entry>
+          </row>
+          <row>
+            <entry>237</entry>
+            <entry><constant>EXIT_KEYRING</constant></entry>
+            <entry>Failed to set up kernel keyring.</entry>
+          </row>
+          <row>
+            <entry>238</entry>
+            <entry><constant>EXIT_STATE_DIRECTORY</constant></entry>
+            <entry>Failed to set up unit's state directory. See <varname>StateDirectory=</varname> above.</entry>
+          </row>
+          <row>
+            <entry>239</entry>
+            <entry><constant>EXIT_CACHE_DIRECTORY</constant></entry>
+            <entry>Failed to set up unit's cache directory. See <varname>CacheDirectory=</varname> above.</entry>
+          </row>
+          <row>
+            <entry>240</entry>
+            <entry><constant>EXIT_LOGS_DIRECTORY</constant></entry>
+            <entry>Failed to set up unit's logging directory. See <varname>LogsDirectory=</varname> above.</entry>
+          </row>
+          <row>
+            <entry>241</entry>
+            <entry><constant>EXIT_CONFIGURATION_DIRECTORY</constant></entry>
+            <entry>Failed to set up unit's configuration directory. See <varname>ConfigurationDirectory=</varname> above.</entry>
+          </row>
+          <row>
+            <entry>242</entry>
+            <entry><constant>EXIT_NUMA_POLICY</constant></entry>
+            <entry>Failed to set up unit's NUMA memory policy. See <varname>NUMAPolicy=</varname> and <varname>NUMAMask=</varname> above.</entry>
+          </row>
+          <row>
+            <entry>243</entry>
+            <entry><constant>EXIT_CREDENTIALS</constant></entry>
+            <entry>Failed to set up unit's credentials. See <varname>ImportCredential=</varname>, <varname>LoadCredential=</varname> and <varname>SetCredential=</varname> above.</entry>
+          </row>
+          <row>
+            <entry>245</entry>
+            <entry><constant>EXIT_BPF</constant></entry>
+            <entry>Failed to apply BPF restrictions. See <varname>RestrictFileSystems=</varname> above.</entry>
+          </row>
+        </tbody>
+      </tgroup>
+    </table>
+
+    <para>Finally, the BSD operating systems define a set of exit codes, typically defined on Linux systems too:</para>
+
+    <table>
+      <title>BSD exit codes</title>
+      <tgroup cols='3'>
+        <thead>
+          <row>
+            <entry>Exit Code</entry>
+            <entry>Symbolic Name</entry>
+            <entry>Description</entry>
+          </row>
+        </thead>
+        <tbody>
+          <row>
+            <entry>64</entry>
+            <entry><constant>EX_USAGE</constant></entry>
+            <entry>Command line usage error</entry>
+          </row>
+          <row>
+            <entry>65</entry>
+            <entry><constant>EX_DATAERR</constant></entry>
+            <entry>Data format error</entry>
+          </row>
+          <row>
+            <entry>66</entry>
+            <entry><constant>EX_NOINPUT</constant></entry>
+            <entry>Cannot open input</entry>
+          </row>
+          <row>
+            <entry>67</entry>
+            <entry><constant>EX_NOUSER</constant></entry>
+            <entry>Addressee unknown</entry>
+          </row>
+          <row>
+            <entry>68</entry>
+            <entry><constant>EX_NOHOST</constant></entry>
+            <entry>Host name unknown</entry>
+          </row>
+          <row>
+            <entry>69</entry>
+            <entry><constant>EX_UNAVAILABLE</constant></entry>
+            <entry>Service unavailable</entry>
+          </row>
+          <row>
+            <entry>70</entry>
+            <entry><constant>EX_SOFTWARE</constant></entry>
+            <entry>internal software error</entry>
+          </row>
+          <row>
+            <entry>71</entry>
+            <entry><constant>EX_OSERR</constant></entry>
+            <entry>System error (e.g., can't fork)</entry>
+          </row>
+          <row>
+            <entry>72</entry>
+            <entry><constant>EX_OSFILE</constant></entry>
+            <entry>Critical OS file missing</entry>
+          </row>
+          <row>
+            <entry>73</entry>
+            <entry><constant>EX_CANTCREAT</constant></entry>
+            <entry>Can't create (user) output file</entry>
+          </row>
+          <row>
+            <entry>74</entry>
+            <entry><constant>EX_IOERR</constant></entry>
+            <entry>Input/output error</entry>
+          </row>
+          <row>
+            <entry>75</entry>
+            <entry><constant>EX_TEMPFAIL</constant></entry>
+            <entry>Temporary failure; user is invited to retry</entry>
+          </row>
+          <row>
+            <entry>76</entry>
+            <entry><constant>EX_PROTOCOL</constant></entry>
+            <entry>Remote error in protocol</entry>
+          </row>
+          <row>
+            <entry>77</entry>
+            <entry><constant>EX_NOPERM</constant></entry>
+            <entry>Permission denied</entry>
+          </row>
+          <row>
+            <entry>78</entry>
+            <entry><constant>EX_CONFIG</constant></entry>
+            <entry>Configuration error</entry>
+          </row>
+        </tbody>
+      </tgroup>
+    </table>
+  </refsect1>
+
+  <refsect1>
+    <title>Examples</title>
+
+      <example>
+        <title><varname>$MONITOR_<replaceable>*</replaceable></varname> usage</title>
+
+        <para>A service <filename index="false">myfailer.service</filename> which can trigger an
+        <varname>OnFailure=</varname> dependency.</para>
+
+        <programlisting>
+[Unit]
+Description=Service which can trigger an OnFailure= dependency
+OnFailure=myhandler.service
+
+[Service]
+ExecStart=/bin/myprogram
+        </programlisting>
+
+        <para>A service <filename index="false">mysuccess.service</filename> which can trigger an
+        <varname>OnSuccess=</varname> dependency.</para>
+
+        <programlisting>
+[Unit]
+Description=Service which can trigger an OnSuccess= dependency
+OnSuccess=myhandler.service
+
+[Service]
+ExecStart=/bin/mysecondprogram
+        </programlisting>
+
+        <para>A service <filename index="false">myhandler.service</filename> which can be triggered
+        by any of the above services.</para>
+
+        <programlisting>
+[Unit]
+Description=Acts on service failing or succeeding
+
+[Service]
+ExecStart=/bin/bash -c "echo $MONITOR_SERVICE_RESULT $MONITOR_EXIT_CODE $MONITOR_EXIT_STATUS $MONITOR_INVOCATION_ID $MONITOR_UNIT"
+        </programlisting>
+
+        <para>If <filename index="false">myfailer.service</filename> were to run and exit in failure,
+        then <filename index="false">myhandler.service</filename> would be triggered and the
+        monitor variables would be set as follows:</para>
+
+        <programlisting>
+MONITOR_SERVICE_RESULT=exit-code
+MONITOR_EXIT_CODE=exited
+MONITOR_EXIT_STATUS=1
+MONITOR_INVOCATION_ID=cc8fdc149b2b4ca698d4f259f4054236
+MONITOR_UNIT=myfailer.service
+        </programlisting>
+
+        <para>If <filename index="false">mysuccess.service</filename> were to run and exit in success,
+        then <filename index="false">myhandler.service</filename> would be triggered and the
+        monitor variables would be set as follows:</para>
+
+        <programlisting>
+MONITOR_SERVICE_RESULT=success
+MONITOR_EXIT_CODE=exited
+MONITOR_EXIT_STATUS=0
+MONITOR_INVOCATION_ID=6ab9af147b8c4a3ebe36e7a5f8611697
+MONITOR_UNIT=mysuccess.service
+        </programlisting>
+
+    </example>
+
+  </refsect1>
+
+  <refsect1>
+      <title>See Also</title>
+      <para>
+        <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd-analyze</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.swap</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>tmpfiles.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry project='man-pages'><refentrytitle>exec</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+        <citerefentry project='man-pages'><refentrytitle>fork</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+      </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd.generator.xml b/man/systemd.generator.xml
new file mode 100644
index 0000000..b216ef9
--- /dev/null
+++ b/man/systemd.generator.xml
@@ -0,0 +1,403 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [
+<!ENTITY % entities SYSTEM "custom-entities.ent" >
+%entities;
+]>
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd.generator" xmlns:xi="http://www.w3.org/2001/XInclude">
+  <refentryinfo>
+    <title>systemd.generator</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd.generator</refentrytitle>
+    <manvolnum>7</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd.generator</refname>
+    <refpurpose>systemd unit generators</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <cmdsynopsis>
+      <command index='false'>/path/to/generator</command>
+      <arg choice="plain"><replaceable>normal-dir</replaceable></arg>
+      <arg choice="option"><replaceable>early-dir</replaceable></arg>
+      <arg choice="option"><replaceable>late-dir</replaceable></arg>
+    </cmdsynopsis>
+
+    <para>
+      <literallayout><filename>/run/systemd/system-generators/*</filename>
+<filename>/etc/systemd/system-generators/*</filename>
+<filename>/usr/local/lib/systemd/system-generators/*</filename>
+<filename>&SYSTEM_GENERATOR_DIR;/*</filename></literallayout>
+    </para>
+
+    <para>
+      <literallayout><filename>/run/systemd/user-generators/*</filename>
+<filename>/etc/systemd/user-generators/*</filename>
+<filename>/usr/local/lib/systemd/user-generators/*</filename>
+<filename>&USER_GENERATOR_DIR;/*</filename></literallayout>
+    </para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+    <para>Generators are small executables placed in <filename>&SYSTEM_GENERATOR_DIR;/</filename> and other
+    directories listed above.
+    <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> will execute
+    these binaries very early at bootup and at configuration reload time — before unit files are
+    loaded. Their main purpose is to convert configuration and execution context parameters that are not
+    native to the service manager into dynamically generated unit files, symlinks or unit file drop-ins, so
+    that they can extend the unit file hierarchy the service manager subsequently loads and operates
+    on.</para>
+
+    <para><command>systemd</command> will call each generator with three directory paths that are to be used
+    for generator output. In these three directories, generators may dynamically generate unit files (regular
+    ones, instances, as well as templates), unit file <filename>.d/</filename> drop-ins, and create symbolic
+    links to unit files to add additional dependencies, create aliases, or instantiate existing templates.
+    Those directories are included in the unit load path, allowing generated configuration to extend or
+    override existing definitions. For tests, generators may be called with just one argument; the generator
+    should assume that all three paths are the same in that case.</para>
+
+    <para>Directory paths for generator output differ by priority: <filename>…/generator.early</filename> has
+    priority higher than the admin configuration in <filename>/etc/</filename>, while
+    <filename>…/generator</filename> has lower priority than <filename>/etc/</filename> but higher than
+    vendor configuration in <filename>/usr/</filename>, and <filename>…/generator.late</filename> has
+    priority lower than all other configuration. See the next section and the discussion of unit load paths
+    and unit overriding in
+    <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+    </para>
+
+    <para>Generators are loaded from a set of paths determined during compilation, as listed above. System
+    and user generators are loaded from directories with names ending in
+    <filename>system-generators/</filename> and <filename>user-generators/</filename>,
+    respectively. Generators found in directories listed earlier override the ones with the same name in
+    directories lower in the list. A symlink to <filename>/dev/null</filename> or an empty file can be used
+    to mask a generator, thereby preventing it from running. Please note that the order of the two
+    directories with the highest priority is reversed with respect to the unit load path, and generators in
+    <filename>/run/</filename> overwrite those in <filename>/etc/</filename>.</para>
+
+    <para>After installing new generators or updating the configuration, <command>systemctl
+    daemon-reload</command> may be executed. This will delete the previous configuration created by
+    generators, re-run all generators, and cause <command>systemd</command> to reload units from disk. See
+    <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> for more
+    information.
+    </para>
+  </refsect1>
+
+  <refsect1>
+    <title>Output directories</title>
+
+    <para>Generators are invoked with three arguments: paths to directories where generators can place their
+    generated unit files or symlinks. By default those paths are runtime directories that are included in the
+    search path of <command>systemd</command>, but a generator may be called with different paths for
+    debugging purposes. If only one argument is provided, the generator should use the same directory as the
+    three output paths.</para>
+
+    <orderedlist>
+      <listitem>
+        <para><parameter>normal-dir</parameter></para>
+        <para>In normal use this is <filename>/run/systemd/generator</filename> in case of the system
+        generators and <filename>$XDG_RUNTIME_DIR/systemd/generator</filename> in case of the user
+        generators. Unit files placed in this directory take precedence over vendor unit configuration but
+        not over native user/administrator unit configuration.
+        </para>
+      </listitem>
+
+      <listitem>
+        <para><parameter>early-dir</parameter></para>
+        <para>In normal use this is <filename>/run/systemd/generator.early</filename> in case of the system
+        generators and <filename>$XDG_RUNTIME_DIR/systemd/generator.early</filename> in case of the user
+        generators. Unit files placed in this directory override unit files in <filename>/usr/</filename>,
+        <filename>/run/</filename> and <filename>/etc/</filename>. This means that unit files placed in this
+        directory take precedence over all normal configuration, both vendor and user/administrator.</para>
+      </listitem>
+
+      <listitem>
+        <para><parameter>late-dir</parameter></para>
+        <para>In normal use this is <filename>/run/systemd/generator.late</filename> in case of the system
+        generators and <filename>$XDG_RUNTIME_DIR/systemd/generator.late</filename> in case of the user
+        generators. This directory may be used to extend the unit file tree without overriding any other unit
+        files. Any native configuration files supplied by the vendor or user/administrator take
+        precedence.</para>
+      </listitem>
+    </orderedlist>
+
+    <para>Note: generators <emphasis>must not</emphasis> write to other locations or otherwise make changes
+    to system state. Generator output is supposed to last only until the next
+    <command>daemon-reload</command> or <command>daemon-reexec</command>; if the generator is replaced
+    or masked, its effects should vanish.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Environment</title>
+
+    <para>The service manager sets a number of environment variables when invoking generator
+    executables. They carry information about the execution context of the generator, in order to simplify
+    conditionalizing generators to specific environments. The following environment variables are set:</para>
+
+    <variablelist class='environment-variables'>
+      <varlistentry>
+        <term><varname>$SYSTEMD_SCOPE</varname></term>
+
+        <listitem><para>If the generator is invoked from the system service manager this variable is set to
+        <literal>system</literal>; if invoked from the per-user service manager it is set to
+        <literal>user</literal>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v251"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>$SYSTEMD_IN_INITRD</varname></term>
+
+        <listitem><para>If the generator is run as part of an initrd this is set to <literal>1</literal>. If
+        it is run from the regular host (i.e. after the transition from initrd to host) it is set to
+        <literal>0</literal>. This environment variable is only set for system generators.</para>
+
+        <xi:include href="version-info.xml" xpointer="v251"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>$SYSTEMD_FIRST_BOOT</varname></term>
+
+        <listitem><para>If this boot-up cycle is considered a "first boot", this is set to
+        <literal>1</literal>; if it is a subsequent, regular boot it is set to <literal>0</literal>. For
+        details see the documentation of <varname>ConditionFirstBoot=</varname> in
+        <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>. This
+        environment variable is only set for system generators.</para>
+
+        <xi:include href="version-info.xml" xpointer="v251"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>$SYSTEMD_VIRTUALIZATION</varname></term>
+
+        <listitem><para>If the service manager is run in a virtualized environment,
+        <varname>$SYSTEMD_VIRTUALIZATION</varname> is set to a pair of strings, separated by a colon. The
+        first string is either <literal>vm</literal> or <literal>container</literal>, categorizing the type
+        of virtualization. The second string identifies the implementation of the virtualization
+        technology. If no virtualization is detected this variable will not be set. This data is identical to
+        what
+        <citerefentry><refentrytitle>systemd-detect-virt</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+        detects and reports, and uses the same vocabulary of virtualization implementation
+        identifiers.</para>
+
+        <xi:include href="version-info.xml" xpointer="v251"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>$SYSTEMD_ARCHITECTURE</varname></term>
+
+        <listitem><para>This variable is set to a short identifier of the reported architecture of the
+        system. For details about defined values, see documentation of
+        <varname>ConditionArchitecture=</varname> in
+        <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v251"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>$CREDENTIALS_DIRECTORY</varname></term>
+        <term><varname>$ENCRYPTED_CREDENTIALS_DIRECTORY</varname></term>
+
+        <listitem><para>If set, refers to the directory system credentials have been placed in. Credentials
+        passed into the system in plaintext form will be placed in <varname>$CREDENTIALS_DIRECTORY</varname>,
+        and those passed in in encrypted form will be placed in
+        <varname>$ENCRYPTED_CREDENTIALS_DIRECTORY</varname>. Use the
+        <citerefentry><refentrytitle>systemd-creds</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+        command to automatically decrypt/authenticate credentials passed in, if needed. Specifically, use the
+        <command>systemd-creds --system cat</command> command.</para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>$SYSTEMD_CONFIDENTIAL_VIRTUALIZATION</varname></term>
+
+        <listitem><para>If the service manager is run in a confidential virtualized environment,
+        <varname>$SYSTEMD_CONFIDENTIAL_VIRTUALIZATION</varname> is set to a string that identifies
+        the confidential virtualization hardware technology. If no confidential virtualization is
+        detected this variable will not be set. This data is identical to what
+        <citerefentry><refentrytitle>systemd-detect-virt</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+        detects and reports, and uses the same vocabulary of confidential virtualization
+        technology identifiers.</para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Notes about writing generators</title>
+
+    <itemizedlist>
+      <listitem>
+        <para>All generators are executed in parallel. That means all executables are started at the very
+        same time and need to be able to cope with this parallelism.
+        </para>
+      </listitem>
+
+      <listitem>
+        <para>Generators are run very early at boot and cannot rely on any external services. They may not
+        talk to any other process. That includes simple things such as logging to <citerefentry
+        project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>, or
+        <command>systemd</command> itself (this means: no
+        <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>)!
+        Non-essential file systems like <filename>/var/</filename> and <filename>/home/</filename> are
+        mounted after generators have run. Generators can however rely on the most basic kernel functionality
+        to be available, as well as mounted <filename>/sys/</filename>, <filename>/proc/</filename>,
+        <filename>/dev/</filename>, <filename>/usr/</filename> and <filename>/run/</filename> file systems.
+        </para>
+      </listitem>
+
+      <listitem>
+        <para>Units written by generators are removed when the configuration is reloaded. That means the
+        lifetime of the generated units is closely bound to the reload cycles of <command>systemd</command>
+        itself.</para>
+      </listitem>
+
+      <listitem>
+        <para>Generators should only be used to generate unit files, <filename>.d/*.conf</filename> drop-ins
+        for them and symlinks to them, not any other kind of non-unit related configuration. Due to the
+        lifecycle logic mentioned above, generators are not a good fit to generate dynamic configuration for
+        other services. If you need to generate dynamic configuration for other services, do so in normal
+        services you order before the service in question.</para>
+
+        <para>Note that using the <varname>StandardInputData=</varname>/<varname>StandardInputText=</varname>
+        settings of service unit files (see
+        <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>), it
+        is possible to make arbitrary input data (including daemon-specific configuration) part of the unit
+        definitions, which often might be sufficient to embed data or configuration for other programs into
+        unit files in a native fashion.</para>
+      </listitem>
+
+      <listitem>
+        <para>Since
+        <citerefentry project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+
+        is not available (see above), log messages have to be written to <filename>/dev/kmsg</filename>
+        instead.</para>
+      </listitem>
+
+      <listitem>
+        <para>The generator should always include its own name in a comment at the top of the generated file,
+        so that the user can easily figure out which component created or amended a particular unit.</para>
+
+        <para>The <varname>SourcePath=</varname> directive should be used in generated files to specify the
+        source configuration file they are generated from. This makes things more easily understood by the
+        user and also has the benefit that systemd can warn the user about configuration files that changed
+        on disk but have not been read yet by systemd. The <varname>SourcePath=</varname> value does not have
+        to be a file in a physical filesystem. For example, in the common case of the generator looking at
+        the kernel command line, <option>SourcePath=/proc/cmdline</option> should be used.</para>
+      </listitem>
+
+      <listitem>
+        <para>Generators may write out dynamic unit files or just hook unit files into other units with the
+        usual <filename>.wants/</filename> or <filename>.requires/</filename> symlinks. Often, it is nicer to
+        simply instantiate a template unit file from <filename>/usr/</filename> with a generator instead of
+        writing out entirely dynamic unit files. Of course, this works only if a single parameter is to be
+        used.</para>
+      </listitem>
+
+      <listitem>
+        <para>If you are careful, you can implement generators in shell scripts. We do recommend C code
+        however, since generators are executed synchronously and hence delay the entire boot if they are
+        slow.</para>
+      </listitem>
+
+      <listitem>
+        <para>Regarding overriding semantics: there are two rules we try to follow when thinking about the
+        overriding semantics:</para>
+
+        <orderedlist numeration="lowerroman">
+          <listitem>
+            <para>User configuration should override vendor configuration. This (mostly) means that stuff
+            from <filename>/etc/</filename> should override stuff from <filename>/usr/</filename>.</para>
+          </listitem>
+
+          <listitem>
+            <para>Native configuration should override non-native configuration. This (mostly) means that
+            stuff you generate should never override native unit files for the same purpose.</para>
+          </listitem>
+        </orderedlist>
+
+        <para>Of these two rules the first rule is probably the more important one and breaks the second one
+        sometimes. Hence, when deciding whether to use argv[1], argv[2], or argv[3], your default choice
+        should probably be argv[1].</para>
+      </listitem>
+
+      <listitem>
+        <para>Instead of heading off now and writing all kind of generators for legacy configuration file
+        formats, please think twice! It is often a better idea to just deprecate old stuff instead of keeping
+        it artificially alive.
+        </para>
+      </listitem>
+    </itemizedlist>
+  </refsect1>
+
+  <refsect1>
+    <title>Examples</title>
+    <example>
+      <title>systemd-fstab-generator</title>
+
+      <para><citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+      converts <filename>/etc/fstab</filename> into native mount units. It uses argv[1] as location to place
+      the generated unit files in order to allow the user to override <filename>/etc/fstab</filename> with
+      their own native unit files, but also to ensure that <filename>/etc/fstab</filename> overrides any
+      vendor default from <filename>/usr/</filename>.</para>
+
+      <para>After editing <filename>/etc/fstab</filename>, the user should invoke <command>systemctl
+      daemon-reload</command>. This will re-run all generators and cause <command>systemd</command> to reload
+      units from disk. To actually mount new directories added to <filename>fstab</filename>,
+      <command>systemctl start <replaceable>/path/to/mountpoint</replaceable></command> or <command>systemctl
+      start local-fs.target</command> may be used.</para>
+    </example>
+
+    <example>
+      <title>systemd-system-update-generator</title>
+
+      <para><citerefentry><refentrytitle>systemd-system-update-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+      temporarily redirects <filename>default.target</filename> to <filename>system-update.target</filename>,
+      if a system update is scheduled. Since this needs to override the default user configuration for
+      <filename>default.target</filename>, it uses argv[2]. For details about this logic, see
+      <citerefentry><refentrytitle>systemd.offline-updates</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
+      </para>
+    </example>
+
+    <example>
+      <title>Debugging a generator</title>
+
+      <programlisting>dir=$(mktemp -d)
+SYSTEMD_LOG_LEVEL=debug &SYSTEM_GENERATOR_DIR;/systemd-fstab-generator \
+        "$dir" "$dir" "$dir"
+find $dir</programlisting>
+    </example>
+  </refsect1>
+
+  <refsect1>
+    <title>See also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-cryptsetup-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-debug-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-getty-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-gpt-auto-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-hibernate-resume-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-rc-local-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-system-update-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-sysv-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-xdg-autostart-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.environment-generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+</refentry>
diff --git a/man/systemd.image-policy.xml b/man/systemd.image-policy.xml
new file mode 100644
index 0000000..7a4453d
--- /dev/null
+++ b/man/systemd.image-policy.xml
@@ -0,0 +1,191 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd.image-policy">
+
+  <refentryinfo>
+    <title>systemd.image-policy</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd.image-policy</refentrytitle>
+    <manvolnum>7</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd.image-policy</refname>
+    <refpurpose>Disk Image Dissection Policy</refpurpose>
+  </refnamediv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>In systemd, whenever a disk image (DDI) implementing the <ulink
+    url="https://uapi-group.org/specifications/specs/discoverable_partitions_specification">Discoverable
+    Partitions Specification</ulink> is activated, a policy may be specified controlling which partitions to
+    mount and what kind of cryptographic protection to require. Such a disk image dissection policy is a
+    string that contains per-partition-type rules, separated by colons (<literal>:</literal>). The individual
+    rules consist of a partition identifier, an equal sign (<literal>=</literal>), and one or more flags
+    which may be set per partition. If multiple flags are specified per partition they are separated by a
+    plus sign (<literal>+</literal>).</para>
+
+    <para>The partition identifiers currently defined are: <option>root</option>, <option>usr</option>,
+    <option>home</option>, <option>srv</option>, <option>esp</option>, <option>xbootldr</option>,
+    <option>swap</option>, <option>root-verity</option>, <option>root-verity-sig</option>,
+    <option>usr-verity</option>, <option>usr-verity-sig</option>, <option>tmp</option>,
+    <option>var</option>. These identifiers match the relevant partition types in the Discoverable Partitions
+    Specification, but are agnostic to CPU architectures. If the partition identifier is left empty it
+    defines the <emphasis>default</emphasis> policy for partitions defined in the Discoverable Partitions
+    Specification for which no policy flags are explicitly listed in the policy string.</para>
+
+    <para>The following partition policy flags are defined that dictate the existence/absence, the use, and
+    the protection level of partitions:</para>
+
+    <itemizedlist>
+      <listitem><para><option>unprotected</option> for partitions that shall exist and be used, but shall
+      come without cryptographic protection, lacking both Verity authentication and LUKS
+      encryption.</para></listitem>
+
+      <listitem><para><option>verity</option> for partitions that shall exist and be used, with Verity
+      authentication. (Note: if a DDI image carries a data partition, along with a Verity partition and a
+      signature partition for it, and only the <option>verity</option> flag is set (<option>signed</option>
+      is not), then the image will be set up with Verity, but the signature data will not be used. Or in
+      other words: any DDI with a set of partitions that qualify for <option>signature</option> also
+      implicitly qualifies for <option>verity</option>, and in fact also
+      <option>unprotected</option>).</para></listitem>
+
+      <listitem><para><option>signed</option> for partitions that shall exist and be used, with Verity
+      authentication, which are also accompanied by a PKCS#7 signature of the Verity root
+      hash.</para></listitem>
+
+      <listitem><para><option>encrypted</option> for partitions which shall exist and be used and are
+      encrypted with LUKS.</para></listitem>
+
+      <listitem><para><option>unused</option> for partitions that shall exist but shall not be
+      used.</para></listitem>
+
+      <listitem><para><option>absent</option> for partitions that shall not exist on the
+      image.</para></listitem>
+    </itemizedlist>
+
+    <para>By setting a combination of the flags above, alternatives can be declared. For example the
+    combination <literal>unused+absent</literal> means: the partition may exist (in which case it shall not
+    be used) or may be absent. The combination of
+    <literal>unprotected+verity+signed+encrypted+unused+absent</literal> may be specified via the special
+    shortcut <literal>open</literal>, and indicates that the partition may exist or may be absent, but if it
+    exists is used, regardless of the protection level.</para>
+
+    <para>As special rule: if none of the flags above are set for a listed partition identifier, the default
+    policy of <option>open</option> is implied, i.e. setting none of these flags listed above means
+    effectively all flags listed above will be set.</para>
+
+    <para>The following partition policy flags are defined that dictate the state of specific GPT partition
+    flags:</para>
+
+    <itemizedlist>
+      <listitem><para><option>read-only-off</option>, <option>read-only-on</option> to require that the
+      partitions have the read-only partition flag off or on.</para></listitem>
+
+      <listitem><para><option>growfs-off</option>, <option>growfs-on</option> to require that the
+      partitions have the growfs partition flag off or on.</para></listitem>
+    </itemizedlist>
+
+    <para>If both <option>read-only-off</option> and <option>read-only-on</option> are set for a partition,
+    then the state of the read-only flag on the partition is not dictated by the policy. Setting neither flag
+    is equivalent to setting both, i.e. setting neither of these two flags means effectively both will be
+    set. A similar logic applies to <option>growfs-off</option>/<option>growfs-on</option>.</para>
+
+    <para>If partitions are not listed within an image policy string, the default policy flags are applied
+    (configurable via an empty partition identifier, see above). If no default policy flags are configured in
+    the policy string, it is implied to be <literal>absent+unused</literal>, except for the Verity partition
+    and their signature partitions where the policy is automatically derived from minimal protection level of
+    the data partition they protect, as encoded in the policy.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Special Policies</title>
+
+    <para>The special image policy string <literal>*</literal> is short for "use everything", i.e. is
+    equivalent to:</para>
+
+    <programlisting>=verity+signed+encrypted+unprotected+unused+absent</programlisting>
+
+    <para>The special image policy string <literal>-</literal> is short for "use nothing", i.e. is equivalent
+    to:</para>
+
+    <programlisting>=unused+absent</programlisting>
+
+    <para>The special image policy string <literal>~</literal> is short for "everything must be absent",
+    i.e. is equivalent to:</para>
+
+    <programlisting>=absent</programlisting>
+
+  </refsect1>
+
+  <refsect1>
+    <title>Use</title>
+
+    <para>Most systemd components that support operating with disk images support a
+    <option>--image-policy=</option> command line option to specify the image policy to use, and default to
+    relatively open policies (typically the <literal>*</literal> policy, as described above), under the
+    assumption that trust in disk images is established before the images are passed to the program in
+    question.</para>
+
+    <para>For the host image itself
+    <citerefentry><refentrytitle>systemd-gpt-auto-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    is responsible for processing the GPT partition table and making use of the included discoverable
+    partitions. It accepts an image policy via the kernel command line option
+    <option>systemd.image-policy=</option>.</para>
+
+    <para>Note that image policies do not dictate how the components will mount and use disk images — they
+    only dictate which parts to avoid and which protection level and arrangement to require while
+    mounting/using them. For example,
+    <citerefentry><refentrytitle>systemd-sysext</refentrytitle><manvolnum>8</manvolnum></citerefentry> only
+    cares for the <filename>/usr/</filename> and <filename>/opt/</filename> trees inside a disk image, and
+    thus ignores any <filename>/home/</filename> partitions (and similar) in all cases, which might be
+    included in the image, regardless whether the configured image policy would allow access to it or
+    not. Similar,
+    <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry> is not
+    going to make use of any discovered swap device, regardless if the policy would allow that or not.</para>
+
+    <para>Use the <command>image-policy</command> command of the
+    <citerefentry><refentrytitle>systemd-analyze</refentrytitle><manvolnum>8</manvolnum></citerefentry> tool
+    to analyze image policy strings, and determine what a specific policy string means for a specific
+    partition.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Examples</title>
+
+    <para>The following image policy string dictates one read-only Verity-enabled <filename>/usr/</filename>
+    partition must exist, plus encrypted root and swap partitions. All other partitions are ignored:</para>
+
+    <programlisting>usr=verity+read-only-on:root=encrypted:swap=encrypted</programlisting>
+
+    <para>The following image policy string dictates an encrypted, writable root file system, and optional
+    <filename>/srv/</filename> file system that must be encrypted if it exists and no swap partition may
+    exist:</para>
+
+    <programlisting>root=encrypted+read-only-off:srv=encrypted+absent:swap=absent</programlisting>
+
+    <para>The following image policy string dictates a single root partition that may be encrypted, but
+    doesn't have to be, and ignores swap partitions, and uses all other partitions if they are available, possibly with encryption.</para>
+
+    <programlisting>root=unprotected+encrypted:swap=absent+unused:=unprotected+encrypted+absent</programlisting>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-dissect</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-gpt-auto-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-sysext</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-analyze</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd.journal-fields.xml b/man/systemd.journal-fields.xml
new file mode 100644
index 0000000..365f61e
--- /dev/null
+++ b/man/systemd.journal-fields.xml
@@ -0,0 +1,679 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd.journal-fields" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd.journal-fields</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd.journal-fields</refentrytitle>
+    <manvolnum>7</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd.journal-fields</refname>
+    <refpurpose>Special journal fields</refpurpose>
+  </refnamediv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>Entries in the journal (as written by
+    <citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>)
+    resemble a UNIX process environment block in syntax but with field values that may include binary data,
+    and with non-unique field names permitted. Primarily, field values are formatted UTF-8 text strings —
+    binary encoding is used only where formatting as UTF-8 text strings makes little sense. New fields may
+    freely be defined by applications, but a few fields have special meanings, which are listed
+    below. Typically, fields may only appear once per log entry, however there are special exceptions: some
+    fields may appear more than once per entry, in which case this is explicitly mentioned below. Even though
+    the logging subsystem makes no restrictions on which fields to accept non-unique values for, it is
+    strongly recommended to avoid relying on this for the fields listed below (except where listed otherwise,
+    as mentioned) in order to avoid unnecessary incompatibilities with other applications.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>User Journal Fields</title>
+
+    <para>User fields are fields that are directly passed from clients
+    and stored in the journal.</para>
+
+    <variablelist class='journal-directives'>
+      <varlistentry>
+        <term><varname>MESSAGE=</varname></term>
+        <listitem>
+          <para>The human-readable message string for this entry. This is supposed to be the primary text
+          shown to the user. It is usually not translated (but might be in some cases), and is not supposed
+          to be parsed for metadata. In order to encode multiple lines in a single log entry, separate them
+          by newline characters (ASCII code 10), but encode them as a single <varname>MESSAGE=</varname>
+          field. Do not add multiple values of this field type to the same entry (also see above), as
+          consuming applications generally do not expect this and are unlikely to show all values in that
+          case.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>MESSAGE_ID=</varname></term>
+        <listitem>
+          <para>A 128-bit message identifier ID for recognizing certain message types, if this is desirable. This
+          should contain a 128-bit ID formatted as a lower-case hexadecimal string, without any separating dashes or
+          suchlike. This is recommended to be a UUID-compatible ID, but this is not enforced, and formatted
+          differently. Developers can generate a new ID for this purpose with <command>systemd-id128 new</command>.
+          </para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>PRIORITY=</varname></term>
+        <listitem>
+          <para>A priority value between 0 (<literal>emerg</literal>)
+          and 7 (<literal>debug</literal>) formatted as a decimal
+          string. This field is compatible with syslog's priority
+          concept.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>CODE_FILE=</varname></term>
+        <term><varname>CODE_LINE=</varname></term>
+        <term><varname>CODE_FUNC=</varname></term>
+        <listitem>
+          <para>The code location generating this message, if known.
+          Contains the source filename, the line number and the
+          function name.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ERRNO=</varname></term>
+        <listitem>
+          <para>The low-level Unix error number causing this entry, if
+          any. Contains the numeric value of
+          <citerefentry project='man-pages'><refentrytitle>errno</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+          formatted as a decimal string.</para>
+
+          <xi:include href="version-info.xml" xpointer="v188"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>INVOCATION_ID=</varname></term>
+        <term><varname>USER_INVOCATION_ID=</varname></term>
+        <listitem>
+          <para>A randomized, unique 128-bit ID identifying each runtime cycle of the unit. This is different from
+          <varname>_SYSTEMD_INVOCATION_ID</varname> in that it is only used for messages coming from systemd code
+          (e.g. logs from the system/user manager or from forked processes performing systemd-related setup).</para>
+
+          <xi:include href="version-info.xml" xpointer="v245"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SYSLOG_FACILITY=</varname></term>
+        <term><varname>SYSLOG_IDENTIFIER=</varname></term>
+        <term><varname>SYSLOG_PID=</varname></term>
+        <term><varname>SYSLOG_TIMESTAMP=</varname></term>
+        <listitem>
+          <para>Syslog compatibility fields containing the facility (formatted as
+          decimal string), the identifier string (i.e.  "tag"), the client PID, and
+          the timestamp as specified in the original datagram. (Note that the tag is
+          usually derived from glibc's
+          <varname>program_invocation_short_name</varname> variable, see
+          <citerefentry project='die-net'><refentrytitle>program_invocation_short_name</refentrytitle><manvolnum>3</manvolnum></citerefentry>.)</para>
+          <para>Note that the journal service does not validate the values of any structured
+          journal fields whose name is not prefixed with an underscore, and this includes any
+          syslog related fields such as these. Hence, applications that supply a facility, PID,
+          or log level are expected to do so properly formatted, i.e. as numeric integers formatted
+          as decimal strings.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SYSLOG_RAW=</varname></term>
+        <listitem>
+          <para>The original contents of the syslog line as received in the syslog
+          datagram. This field is only included if the <varname>MESSAGE=</varname>
+          field was modified compared to the original payload or the timestamp could
+          not be located properly and is not included in
+          <varname>SYSLOG_TIMESTAMP=</varname>. Message truncation occurs when
+          the message contains leading or trailing whitespace (trailing and leading
+          whitespace is stripped), or it contains an embedded
+          <constant>NUL</constant> byte (the <constant>NUL</constant> byte and
+          anything after it is not included). Thus, the original syslog line is
+          either stored as <varname>SYSLOG_RAW=</varname> or it can be recreated
+          based on the stored priority and facility, timestamp, identifier, and the
+          message payload in <varname>MESSAGE=</varname>.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v240"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>DOCUMENTATION=</varname></term>
+        <listitem>
+          <para>A documentation URL with further information about the topic of the log message. Tools such
+          as <command>journalctl</command> will include a hyperlink to a URL specified this way in their
+          output. Should be an <literal>http://</literal>, <literal>https://</literal>,
+          <literal>file:/</literal>, <literal>man:</literal> or <literal>info:</literal> URL.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>TID=</varname></term>
+        <listitem>
+          <para>The numeric thread ID (TID) the log message originates from.</para>
+
+        <xi:include href="version-info.xml" xpointer="v247"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>UNIT=</varname></term>
+        <term><varname>USER_UNIT=</varname></term>
+        <listitem>
+          <para>The name of a unit. Used by the system and user managers when logging about specific
+          units.</para>
+
+          <para>When <option>--unit=<replaceable>name</replaceable></option> or
+          <option>--user-unit=<replaceable>name</replaceable></option> are used with
+          <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, a
+          match pattern that includes <literal>UNIT=<replaceable>name</replaceable>.service</literal> or
+          <literal>USER_UNIT=<replaceable>name</replaceable>.service</literal> will be generated.</para>
+
+          <xi:include href="version-info.xml" xpointer="v251"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Trusted Journal Fields</title>
+
+    <para>Fields prefixed with an underscore are trusted fields, i.e.
+    fields that are implicitly added by the journal and cannot be
+    altered by client code.</para>
+
+    <variablelist class='journal-directives'>
+      <varlistentry>
+        <term><varname>_PID=</varname></term>
+        <term><varname>_UID=</varname></term>
+        <term><varname>_GID=</varname></term>
+        <listitem>
+          <para>The process, user, and group ID of the process the
+          journal entry originates from formatted as a decimal
+          string. Note that entries obtained via <literal>stdout</literal> or
+          <literal>stderr</literal> of forked processes will contain credentials valid for a parent
+          process (that initiated the connection to <command>systemd-journald</command>).</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>_COMM=</varname></term>
+        <term><varname>_EXE=</varname></term>
+        <term><varname>_CMDLINE=</varname></term>
+        <listitem>
+          <para>The name, the executable path, and the command line of
+          the process the journal entry originates from.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>_CAP_EFFECTIVE=</varname></term>
+        <listitem>
+          <para>The effective
+          <citerefentry project='man-pages'><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+          of the process the journal entry originates from.</para>
+
+          <xi:include href="version-info.xml" xpointer="v206"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>_AUDIT_SESSION=</varname></term>
+        <term><varname>_AUDIT_LOGINUID=</varname></term>
+        <listitem>
+          <para>The session and login UID of the process the journal
+          entry originates from, as maintained by the kernel audit
+          subsystem.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>_SYSTEMD_CGROUP=</varname></term>
+        <term><varname>_SYSTEMD_SLICE=</varname></term>
+        <term><varname>_SYSTEMD_UNIT=</varname></term>
+        <term><varname>_SYSTEMD_USER_UNIT=</varname></term>
+        <term><varname>_SYSTEMD_USER_SLICE=</varname></term>
+        <term><varname>_SYSTEMD_SESSION=</varname></term>
+        <term><varname>_SYSTEMD_OWNER_UID=</varname></term>
+
+        <listitem>
+          <para>The control group path in the systemd hierarchy, the systemd slice unit name, the systemd
+          unit name, the unit name in the systemd user manager (if any), the systemd session ID (if any), and
+          the owner UID of the systemd user unit or systemd session (if any) of the process the journal entry
+          originates from.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>_SELINUX_CONTEXT=</varname></term>
+        <listitem>
+          <para>The SELinux security context (label) of the process
+          the journal entry originates from.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>_SOURCE_REALTIME_TIMESTAMP=</varname></term>
+        <listitem>
+          <para>The earliest trusted timestamp of the message, if any
+          is known that is different from the reception time of the
+          journal. This is the time in microseconds since the epoch
+          UTC, formatted as a decimal string.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>_BOOT_ID=</varname></term>
+        <listitem>
+          <para>The kernel boot ID for the boot the message was
+          generated in, formatted as a 128-bit hexadecimal
+          string.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>_MACHINE_ID=</varname></term>
+        <listitem>
+          <para>The machine ID of the originating host, as available
+          in
+          <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>_SYSTEMD_INVOCATION_ID=</varname></term>
+        <listitem>
+          <para>The invocation ID for the runtime cycle of the unit
+          the message was generated in, as available to processes
+          of the unit in <varname>$INVOCATION_ID</varname> (see
+          <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>).</para>
+
+          <xi:include href="version-info.xml" xpointer="v233"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>_HOSTNAME=</varname></term>
+        <listitem>
+          <para>The name of the originating host.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>_TRANSPORT=</varname></term>
+        <listitem>
+          <para>How the entry was received by the journal service.
+          Valid transports are:
+          </para>
+          <variablelist>
+            <varlistentry>
+              <term>
+                <option>audit</option>
+              </term>
+              <listitem>
+                <para>for those read from the kernel audit subsystem
+                </para>
+
+                <xi:include href="version-info.xml" xpointer="v227"/>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term>
+                <option>driver</option>
+              </term>
+              <listitem>
+                <para>for internally generated messages
+                </para>
+
+                <xi:include href="version-info.xml" xpointer="v205"/>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term>
+                <option>syslog</option>
+              </term>
+              <listitem>
+                <para>for those received via the local syslog socket
+                with the syslog protocol
+                </para>
+
+                <xi:include href="version-info.xml" xpointer="v205"/>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term>
+                <option>journal</option>
+              </term>
+              <listitem>
+                <para>for those received via the native journal
+                protocol
+                </para>
+
+                <xi:include href="version-info.xml" xpointer="v205"/>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term>
+                <option>stdout</option>
+              </term>
+              <listitem>
+                <para>for those read from a service's standard output
+                or error output
+                </para>
+
+                <xi:include href="version-info.xml" xpointer="v205"/>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term>
+                <option>kernel</option>
+              </term>
+              <listitem>
+                <para>for those read from the kernel
+                </para>
+
+                <xi:include href="version-info.xml" xpointer="v205"/>
+              </listitem>
+            </varlistentry>
+          </variablelist>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>_STREAM_ID=</varname></term>
+        <listitem>
+          <para>Only applies to <literal>_TRANSPORT=stdout</literal> records: specifies a randomized 128-bit ID assigned
+          to the stream connection when it was first created. This ID is useful to reconstruct individual log streams
+          from the log records: all log records carrying the same stream ID originate from the same stream.</para>
+
+        <xi:include href="version-info.xml" xpointer="v235"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>_LINE_BREAK=</varname></term>
+        <listitem>
+          <para>Only applies to <literal>_TRANSPORT=stdout</literal> records: indicates that the log message
+          in the standard output/error stream was not terminated with a normal newline character
+          (<literal>\n</literal>, i.e. ASCII 10). Specifically, when set this field is one of
+          <option>nul</option> (in case the line was terminated by a <constant>NUL</constant> byte), <option>line-max</option> (in
+          case the maximum log line length was reached, as configured with <varname>LineMax=</varname> in
+          <citerefentry><refentrytitle>journald.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>),
+          <option>eof</option> (if this was the last log record of a stream and the stream ended without a
+          final newline character), or <option>pid-change</option> (if the process which generated the log
+          output changed in the middle of a line). Note that this record is not generated when a normal
+          newline character was used for marking the log line end.</para>
+
+        <xi:include href="version-info.xml" xpointer="v235"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>_NAMESPACE=</varname></term>
+
+        <listitem><para>If this file was written by a <command>systemd-journald</command> instance managing a
+        journal namespace that is not the default, this field contains the namespace identifier. See
+        <citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        for details about journal namespaces.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>_RUNTIME_SCOPE=</varname></term>
+
+        <listitem><para>A string field that specifies the runtime scope in which the message was logged. If
+        <literal>initrd</literal>, the log message was processed while the system was running inside the
+        initrd. If <literal>system</literal>, the log message was generated after the system switched
+        execution to the host root filesystem.</para>
+
+        <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Kernel Journal Fields</title>
+
+    <para>Kernel fields are fields that are used by messages
+    originating in the kernel and stored in the journal.</para>
+
+    <variablelist class='journal-directives'>
+      <varlistentry>
+        <term><varname>_KERNEL_DEVICE=</varname></term>
+        <listitem>
+          <para>The kernel device name. If the entry is associated to a block device, contains the major and
+          minor numbers of the device node, separated by <literal>:</literal> and prefixed by
+          <literal>b</literal>. Similarly for character devices, but prefixed by <literal>c</literal>. For
+          network devices, this is the interface index prefixed by <literal>n</literal>. For all other
+          devices, this is the subsystem name prefixed by <literal>+</literal>, followed by
+          <literal>:</literal>, followed by the kernel device name.</para>
+
+          <xi:include href="version-info.xml" xpointer="v189"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>_KERNEL_SUBSYSTEM=</varname></term>
+        <listitem>
+          <para>The kernel subsystem name.</para>
+
+        <xi:include href="version-info.xml" xpointer="v189"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>_UDEV_SYSNAME=</varname></term>
+        <listitem>
+          <para>The kernel device name as it shows up in the device
+          tree below <filename>/sys/</filename>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v189"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>_UDEV_DEVNODE=</varname></term>
+        <listitem>
+          <para>The device node path of this device in
+          <filename>/dev/</filename>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v189"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>_UDEV_DEVLINK=</varname></term>
+        <listitem>
+          <para>Additional symlink names pointing to the device node
+          in <filename>/dev/</filename>. This field is frequently set
+          more than once per entry.</para>
+
+          <xi:include href="version-info.xml" xpointer="v189"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Fields to log on behalf of a different program</title>
+
+    <para>Fields in this section are used by programs to specify that
+    they are logging on behalf of another program or unit.
+    </para>
+
+    <para>Fields used by the <command>systemd-coredump</command>
+    coredump kernel helper:
+    </para>
+
+    <variablelist class='journal-directives'>
+      <varlistentry>
+        <term><varname>COREDUMP_UNIT=</varname></term>
+        <term><varname>COREDUMP_USER_UNIT=</varname></term>
+        <listitem>
+          <para>Used to annotate messages containing coredumps from
+          system and session units. See
+          <citerefentry><refentrytitle>coredumpctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v198"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+
+    <para>Privileged programs (currently UID 0) may attach
+    <varname>OBJECT_PID=</varname> to a message. This will instruct
+    <command>systemd-journald</command> to attach additional fields on
+    behalf of the caller:</para>
+
+    <variablelist class='journal-directives'>
+      <varlistentry>
+        <term><varname>OBJECT_PID=<replaceable>PID</replaceable></varname></term>
+        <listitem>
+          <para>PID of the program that this message pertains to.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v205"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>OBJECT_UID=</varname></term>
+        <term><varname>OBJECT_GID=</varname></term>
+        <term><varname>OBJECT_COMM=</varname></term>
+        <term><varname>OBJECT_EXE=</varname></term>
+        <term><varname>OBJECT_CMDLINE=</varname></term>
+        <term><varname>OBJECT_AUDIT_SESSION=</varname></term>
+        <term><varname>OBJECT_AUDIT_LOGINUID=</varname></term>
+        <term><varname>OBJECT_SYSTEMD_CGROUP=</varname></term>
+        <term><varname>OBJECT_SYSTEMD_SESSION=</varname></term>
+        <term><varname>OBJECT_SYSTEMD_OWNER_UID=</varname></term>
+        <term><varname>OBJECT_SYSTEMD_UNIT=</varname></term>
+        <term><varname>OBJECT_SYSTEMD_USER_UNIT=</varname></term>
+        <listitem>
+          <para>These are additional fields added automatically by
+          <command>systemd-journald</command>. Their meaning is the
+          same as
+          <varname>_UID=</varname>,
+          <varname>_GID=</varname>,
+          <varname>_COMM=</varname>,
+          <varname>_EXE=</varname>,
+          <varname>_CMDLINE=</varname>,
+          <varname>_AUDIT_SESSION=</varname>,
+          <varname>_AUDIT_LOGINUID=</varname>,
+          <varname>_SYSTEMD_CGROUP=</varname>,
+          <varname>_SYSTEMD_SESSION=</varname>,
+          <varname>_SYSTEMD_UNIT=</varname>,
+          <varname>_SYSTEMD_USER_UNIT=</varname>, and
+          <varname>_SYSTEMD_OWNER_UID=</varname>
+          as described above, except that the process identified by
+          <replaceable>PID</replaceable> is described, instead of the
+          process which logged the message.</para>
+
+          <xi:include href="version-info.xml" xpointer="v205"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+
+  </refsect1>
+
+  <refsect1>
+    <title>Address Fields</title>
+
+    <para>During serialization into external formats, such as the
+    <ulink url="https://systemd.io/JOURNAL_EXPORT_FORMATS#journal-export-format">Journal Export Format</ulink>
+    or the
+    <ulink url="https://systemd.io/JOURNAL_EXPORT_FORMATS#journal-json-format">Journal JSON Format</ulink>,
+    the addresses of journal entries are
+    serialized into fields prefixed with double underscores. Note that
+    these are not proper fields when stored in the journal but for
+    addressing metadata of entries. They cannot be written as part of
+    structured log entries via calls such as
+    <citerefentry><refentrytitle>sd_journal_send</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+    They may also not be used as matches for
+    <citerefentry><refentrytitle>sd_journal_add_match</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+    </para>
+
+    <variablelist class='journal-directives'>
+      <varlistentry>
+        <term><varname>__CURSOR=</varname></term>
+        <listitem>
+          <para>The cursor for the entry. A cursor is an opaque text
+          string that uniquely describes the position of an entry in
+          the journal and is portable across machines, platforms and
+          journal files.
+          </para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>__REALTIME_TIMESTAMP=</varname></term>
+        <listitem>
+          <para>The wallclock time
+          (<constant>CLOCK_REALTIME</constant>) at the point in time
+          the entry was received by the journal, in microseconds since
+          the epoch UTC, formatted as a decimal string. This has
+          different properties from
+          <literal>_SOURCE_REALTIME_TIMESTAMP=</literal>, as it is
+          usually a bit later but more likely to be monotonic.
+          </para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>__MONOTONIC_TIMESTAMP=</varname></term>
+        <listitem>
+          <para>The monotonic time
+          (<constant>CLOCK_MONOTONIC</constant>) at the point in time
+          the entry was received by the journal in microseconds,
+          formatted as a decimal string. To be useful as an address
+          for the entry, this should be combined with the boot ID in
+          <literal>_BOOT_ID=</literal>.
+          </para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>__SEQNUM=</varname></term>
+        <term><varname>__SEQNUM_ID=</varname></term>
+
+        <listitem><para>The sequence number (and associated sequence number ID) of this journal entry in the
+        journal file it originates from. See
+        <citerefentry><refentrytitle>sd_journal_get_seqnum</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+        for details.</para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+      <title>See Also</title>
+      <para>
+        <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>journald.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>sd-journal</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>coredumpctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+      </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd.kill.xml b/man/systemd.kill.xml
new file mode 100644
index 0000000..e5441bb
--- /dev/null
+++ b/man/systemd.kill.xml
@@ -0,0 +1,209 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd.kill" xmlns:xi="http://www.w3.org/2001/XInclude">
+  <refentryinfo>
+    <title>systemd.kill</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd.kill</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd.kill</refname>
+    <refpurpose>Process killing procedure
+    configuration</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename><replaceable>service</replaceable>.service</filename>,
+    <filename><replaceable>socket</replaceable>.socket</filename>,
+    <filename><replaceable>mount</replaceable>.mount</filename>,
+    <filename><replaceable>swap</replaceable>.swap</filename>,
+    <filename><replaceable>scope</replaceable>.scope</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>Unit configuration files for services, sockets, mount
+    points, swap devices and scopes share a subset of configuration
+    options which define the killing procedure of processes belonging
+    to the unit.</para>
+
+    <para>This man page lists the configuration options shared by
+    these five unit types. See
+    <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for the common options shared by all unit configuration files, and
+    <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>systemd.swap</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    and
+    <citerefentry><refentrytitle>systemd.scope</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for more information on the configuration file options specific to
+    each unit type.</para>
+
+    <para>The kill procedure configuration options are configured in
+    the [Service], [Socket], [Mount] or [Swap] section, depending on
+    the unit type.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <variablelist class='unit-directives'>
+
+      <varlistentry>
+        <term><varname>KillMode=</varname></term>
+        <listitem><para>Specifies how processes of this unit shall be killed. One of
+        <option>control-group</option>, <option>mixed</option>, <option>process</option>,
+        <option>none</option>.</para>
+
+        <para>If set to <option>control-group</option>, all remaining processes in the control group of this
+        unit will be killed on unit stop (for services: after the stop command is executed, as configured
+        with <varname>ExecStop=</varname>). If set to <option>mixed</option>, the
+        <constant>SIGTERM</constant> signal (see below) is sent to the main process while the subsequent
+        <constant>SIGKILL</constant> signal (see below) is sent to all remaining processes of the unit's
+        control group. If set to <option>process</option>, only the main process itself is killed (not
+        recommended!). If set to <option>none</option>, no process is killed (strongly recommended
+        against!). In this case, only the stop command will be executed on unit stop, but no process will be
+        killed otherwise.  Processes remaining alive after stop are left in their control group and the
+        control group continues to exist after stop unless empty.</para>
+
+        <para>Note that it is not recommended to set <varname>KillMode=</varname> to
+        <constant>process</constant> or even <constant>none</constant>, as this allows processes to escape
+        the service manager's lifecycle and resource management, and to remain running even while their
+        service is considered stopped and is assumed to not consume any resources.</para>
+
+        <para>Processes will first be terminated via <constant>SIGTERM</constant> (unless the signal to send
+        is changed via <varname>KillSignal=</varname> or <varname>RestartKillSignal=</varname>). Optionally,
+        this is immediately followed by a <constant>SIGHUP</constant> (if enabled with
+        <varname>SendSIGHUP=</varname>). If processes still remain after:
+        <itemizedlist>
+          <listitem><para>the main process of a unit has exited (applies to <varname>KillMode=</varname>:
+              <option>mixed</option>)</para></listitem>
+          <listitem><para>the delay configured via the <varname>TimeoutStopSec=</varname> has passed
+              (applies to <varname>KillMode=</varname>: <option>control-group</option>, <option>mixed</option>,
+              <option>process</option>)</para></listitem>
+        </itemizedlist>
+
+        the termination request is repeated with the <constant>SIGKILL</constant> signal or the signal specified via
+        <varname>FinalKillSignal=</varname> (unless this is disabled via the <varname>SendSIGKILL=</varname>
+        option). See <citerefentry><refentrytitle>kill</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+        for more information.</para>
+
+        <para>Defaults to <option>control-group</option>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v187"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>KillSignal=</varname></term>
+        <listitem><para>Specifies which signal to use when stopping a service. This controls the signal that
+        is sent as first step of shutting down a unit (see above), and is usually followed by
+        <constant>SIGKILL</constant> (see above and below). For a list of valid signals, see
+        <citerefentry project='man-pages'><refentrytitle>signal</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
+        Defaults to <constant>SIGTERM</constant>.</para>
+
+        <para>Note that, right after sending the signal specified in this setting, systemd will always send
+        <constant>SIGCONT</constant>, to ensure that even suspended tasks can be terminated cleanly.</para>
+
+        <xi:include href="version-info.xml" xpointer="v187"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RestartKillSignal=</varname></term>
+        <listitem><para>Specifies which signal to use when restarting a service. The same as
+        <varname>KillSignal=</varname> described above, with the exception that this setting is used in a
+        restart job. Not set by default, and the value of <varname>KillSignal=</varname> is used.</para>
+
+        <xi:include href="version-info.xml" xpointer="v244"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SendSIGHUP=</varname></term>
+        <listitem><para>Specifies whether to send
+        <constant>SIGHUP</constant> to remaining processes immediately
+        after sending the signal configured with
+        <varname>KillSignal=</varname>. This is useful to indicate to
+        shells and shell-like programs that their connection has been
+        severed. Takes a boolean value. Defaults to <literal>no</literal>.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v207"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SendSIGKILL=</varname></term>
+        <listitem><para>Specifies whether to send
+        <constant>SIGKILL</constant> (or the signal specified by
+        <varname>FinalKillSignal=</varname>) to remaining processes
+        after a timeout, if the normal shutdown procedure left
+        processes of the service around. When disabled, a
+        <varname>KillMode=</varname> of <constant>control-group</constant>
+        or <constant>mixed</constant> service will not restart if
+        processes from prior services exist within the control group.
+        Takes a boolean value. Defaults to <literal>yes</literal>.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v187"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>FinalKillSignal=</varname></term>
+        <listitem><para>Specifies which signal to send to remaining
+        processes after a timeout if <varname>SendSIGKILL=</varname>
+        is enabled. The signal configured here should be one that is
+        not typically caught and processed by services (<constant>SIGTERM</constant>
+        is not suitable). Developers can find it useful to use this to
+        generate a coredump to troubleshoot why a service did not
+        terminate upon receiving the initial <constant>SIGTERM</constant>
+        signal. This can be achieved by configuring <varname>LimitCORE=</varname>
+        and setting <varname>FinalKillSignal=</varname> to either
+        <constant>SIGQUIT</constant> or <constant>SIGABRT</constant>.
+        Defaults to <constant>SIGKILL</constant>.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v240"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>WatchdogSignal=</varname></term>
+        <listitem><para>Specifies which signal to use to terminate the
+        service when the watchdog timeout expires (enabled through
+        <varname>WatchdogSec=</varname>). Defaults to <constant>SIGABRT</constant>.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v240"/></listitem>
+      </varlistentry>
+
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+      <title>See Also</title>
+      <para>
+        <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.swap</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>kill</refentrytitle><manvolnum>2</manvolnum></citerefentry>,
+        <citerefentry project='man-pages'><refentrytitle>signal</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+      </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd.link.xml b/man/systemd.link.xml
new file mode 100644
index 0000000..063f8e3
--- /dev/null
+++ b/man/systemd.link.xml
@@ -0,0 +1,1425 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd.link"
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+  <refentryinfo>
+    <title>systemd.link</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd.link</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd.link</refname>
+    <refpurpose>Network device configuration</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename><replaceable>link</replaceable>.link</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>A plain ini-style text file that encodes configuration for matching network devices, used by
+    <citerefentry><refentrytitle>systemd-udevd</refentrytitle><manvolnum>8</manvolnum></citerefentry> and in
+    particular its <command>net_setup_link</command> builtin. See
+    <citerefentry><refentrytitle>systemd.syntax</refentrytitle><manvolnum>7</manvolnum></citerefentry> for a
+    general description of the syntax.</para>
+
+    <para>The <filename>.link</filename> files are read from the files located in the system network
+    directory <filename>/usr/lib/systemd/network</filename> and
+    <filename>/usr/local/lib/systemd/network</filename>, the volatile runtime network directory
+    <filename>/run/systemd/network</filename>, and the local administration network directory
+    <filename>/etc/systemd/network</filename>. All configuration files are collectively sorted and
+    processed in alphanumeric order, regardless of the directories in which they live. However, files
+    with identical filenames replace each other. It is recommended that each filename is prefixed with
+    a number smaller than <literal>70</literal> (e.g. <filename>10-eth0.link</filename>). Otherwise, the
+    default <filename>.link</filename> files or those generated by
+    <citerefentry><refentrytitle>systemd-network-generator.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    may take precedence over user configured files. Files in <filename>/etc/</filename> have the
+    highest priority, files in <filename>/run/</filename> take precedence over files with the same name
+    in <filename>/usr/lib/</filename>. This can be used to override a system-supplied link file with a
+    local file if needed. As a special case, an empty file (file size 0) or symlink with the same name
+    pointing to <filename>/dev/null</filename> disables the configuration file entirely (it is
+    "masked").</para>
+
+    <para>Along with the link file <filename>foo.link</filename>, a "drop-in" directory
+    <filename>foo.link.d/</filename> may exist. All files with the suffix <literal>.conf</literal>
+    from this directory will be merged in the alphanumeric order and parsed after the main file itself
+    has been parsed. This is useful to alter or add configuration settings, without having to modify
+    the main configuration file. Each drop-in file must have appropriate section headers.</para>
+
+    <para>In addition to <filename>/etc/systemd/network</filename>, drop-in <literal>.d</literal>
+    directories can be placed in <filename>/usr/lib/systemd/network</filename> or
+    <filename>/run/systemd/network</filename> directories. Drop-in files in <filename>/etc/</filename>
+    take precedence over those in <filename>/run/</filename> which in turn take precedence over those
+    in <filename>/usr/lib/</filename>. Drop-in files under any of these directories take precedence
+    over the main link file wherever located.</para>
+
+    <para>The link file contains a [Match] section, which determines if a given link file may be applied to a
+    given device, as well as a [Link] section specifying how the device should be configured. The first (in
+    lexical order) of the link files that matches a given device is applied. Note that a default file
+    <filename>99-default.link</filename> is shipped by the system. Any user-supplied
+    <filename>.link</filename> should hence have a lexically earlier name to be considered at all.</para>
+
+    <para>See <citerefentry><refentrytitle>udevadm</refentrytitle><manvolnum>8</manvolnum></citerefentry> for
+    diagnosing problems with <filename>.link</filename> files.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>[Match] Section Options</title>
+
+    <para>A link file is said to match an interface if all matches specified by the [Match] section are
+    satisfied. When a link file does not contain valid settings in [Match] section, then the file will
+    match all interfaces and <command>systemd-udevd</command> warns about that. Hint: to avoid the
+    warning and to make it clear that all interfaces shall be matched, add the following:
+    <programlisting>OriginalName=*</programlisting>
+    The first (in alphanumeric order) of the link files that matches a given interface is applied, all
+    later files are ignored, even if they match as well. The following keys are accepted:</para>
+
+    <variablelist class='network-directives'>
+      <!-- This list is reused in systemd.network(3), hence maintain a specific order:
+           1. device matches shared between the two lists
+           2. non-shared settings
+           3. host matches shared between the two lists
+        -->
+
+      <varlistentry id='mac-address'>
+        <term><varname>MACAddress=</varname></term>
+        <listitem>
+          <para>A whitespace-separated list of hardware addresses. The acceptable formats are:</para>
+
+          <variablelist>
+            <varlistentry>
+              <term><option>colon-delimited hexadecimal</option></term>
+              <listitem><para>
+                Each field must be one byte.
+                E.g. <literal>12:34:56:78:90:ab</literal> or <literal>AA:BB:CC:DD:EE:FF</literal>.
+              </para>
+
+                <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+            </varlistentry>
+            <varlistentry>
+              <term><option>hyphen-delimited hexadecimal</option></term>
+              <listitem><para>
+                Each field must be one byte.
+                E.g. <literal>12-34-56-78-90-ab</literal> or <literal>AA-BB-CC-DD-EE-FF</literal>.
+              </para>
+
+                <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+            </varlistentry>
+            <varlistentry>
+              <term><option>dot-delimited hexadecimal</option></term>
+              <listitem><para>
+                Each field must be two bytes.
+                E.g. <literal>1234.5678.90ab</literal> or <literal>AABB.CCDD.EEFF</literal>.
+              </para>
+
+                <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+            </varlistentry>
+            <varlistentry>
+              <term><option>IPv4 address format</option></term>
+              <listitem><para>
+                E.g. <literal>127.0.0.1</literal> or <literal>192.168.0.1</literal>.
+              </para>
+
+                <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+            </varlistentry>
+            <varlistentry>
+              <term><option>IPv6 address format</option></term>
+              <listitem><para>
+                E.g. <literal>2001:0db8:85a3::8a2e:0370:7334</literal> or <literal>::1</literal>.
+              </para>
+
+                <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+            </varlistentry>
+          </variablelist>
+
+          <para>The total length of each MAC address must be 4 (for IPv4 tunnel), 6 (for Ethernet), 16
+          (for IPv6 tunnel), or 20 (for InfiniBand). This option may appear more than once, in which
+          case the lists are merged. If the empty string is assigned to this option, the list of
+          hardware addresses defined prior to this is reset. Defaults to unset.</para>
+
+          <xi:include href="version-info.xml" xpointer="v211"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry id='permanent-mac-address'>
+        <term><varname>PermanentMACAddress=</varname></term>
+        <listitem>
+          <para>A whitespace-separated list of hardware's permanent addresses. While
+          <varname>MACAddress=</varname> matches the device's current MAC address, this matches the
+          device's permanent MAC address, which may be different from the current one. Use full
+          colon-, hyphen- or dot-delimited hexadecimal, or IPv4 or IPv6 address format. This option may
+          appear more than once, in which case the lists are merged. If the empty string is assigned to
+          this option, the list of hardware addresses defined prior to this is reset. Defaults to
+          unset.</para>
+
+          <xi:include href="version-info.xml" xpointer="v245"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry id='path'>
+        <term><varname>Path=</varname></term>
+        <listitem>
+          <para>A whitespace-separated list of shell-style globs matching
+          the persistent path, as exposed by the udev property
+          <varname>ID_PATH</varname>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v211"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry id='driver'>
+        <term><varname>Driver=</varname></term>
+        <listitem>
+          <para>A whitespace-separated list of shell-style globs matching the driver currently bound to the
+          device, as exposed by the udev property <varname>ID_NET_DRIVER</varname> of its parent device, or
+          if that is not set, the driver as exposed by <command>ethtool -i</command> of the device itself.
+          If the list is prefixed with a "!", the test is inverted.</para>
+
+          <xi:include href="version-info.xml" xpointer="v211"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry id='type'>
+        <term><varname>Type=</varname></term>
+        <listitem>
+          <para>A whitespace-separated list of shell-style globs matching the device type, as exposed by
+          <command>networkctl list</command>. If the list is prefixed with a "!", the test is inverted.
+          Some valid values are <literal>ether</literal>, <literal>loopback</literal>, <literal>wlan</literal>, <literal>wwan</literal>.
+          Valid types are named either from the udev <literal>DEVTYPE</literal> attribute, or
+          <literal>ARPHRD_</literal> macros in <filename>linux/if_arp.h</filename>, so this is not comprehensive.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v211"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry id='kind'>
+        <term><varname>Kind=</varname></term>
+        <listitem>
+          <para>A whitespace-separated list of shell-style globs matching the device kind, as exposed by
+          <command>networkctl status <replaceable>INTERFACE</replaceable></command> or
+          <command>ip -d link show <replaceable>INTERFACE</replaceable></command>. If the list is
+          prefixed with a "!", the test is inverted. Some valid values are <literal>bond</literal>,
+          <literal>bridge</literal>, <literal>gre</literal>, <literal>tun</literal>,
+          <literal>veth</literal>. Valid kinds are given by netlink's <literal>IFLA_INFO_KIND</literal>
+          attribute, so this is not comprehensive.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v251"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry id='property'>
+        <term><varname>Property=</varname></term>
+        <listitem>
+          <para>A whitespace-separated list of udev property names with their values after equals sign
+          (<literal>=</literal>). If multiple properties are specified, the test results are ANDed.
+          If the list is prefixed with a "!", the test is inverted. If a value contains white
+          spaces, then please quote whole key and value pair. If a value contains quotation, then
+          please escape the quotation with <literal>\</literal>.</para>
+
+          <para>Example: if a .link file has the following:
+          <programlisting>Property=ID_MODEL_ID=9999 "ID_VENDOR_FROM_DATABASE=vendor name" "KEY=with \"quotation\""</programlisting>
+          then, the .link file matches only when an interface has all the above three properties.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v243"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>OriginalName=</varname></term>
+        <listitem>
+          <para>A whitespace-separated list of shell-style globs matching the device name, as exposed by the
+          udev property "INTERFACE". This cannot be used to match on names that have already been changed
+          from userspace. Caution is advised when matching on kernel-assigned names, as they are known to be
+          unstable between reboots.</para>
+
+          <xi:include href="version-info.xml" xpointer="v218"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry id='host'>
+        <term><varname>Host=</varname></term>
+        <listitem>
+          <para>Matches against the hostname or machine ID of the host. See <varname>ConditionHost=</varname> in
+          <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+          for details. When prefixed with an exclamation mark (<literal>!</literal>), the result is negated.
+          If an empty string is assigned, the previously assigned value is cleared.
+          </para>
+
+        <xi:include href="version-info.xml" xpointer="v211"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry id='virtualization'>
+        <term><varname>Virtualization=</varname></term>
+        <listitem>
+          <para>Checks whether the system is executed in a virtualized environment and optionally test
+          whether it is a specific implementation. See <varname>ConditionVirtualization=</varname> in
+          <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+          for details. When prefixed with an exclamation mark (<literal>!</literal>), the result is negated.
+          If an empty string is assigned, the previously assigned value is cleared.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v211"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry id='kernel-command-line'>
+        <term><varname>KernelCommandLine=</varname></term>
+        <listitem>
+          <para>Checks whether a specific kernel command line option is set. See
+          <varname>ConditionKernelCommandLine=</varname> in
+          <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+          for details. When prefixed with an exclamation mark (<literal>!</literal>), the result is negated.
+          If an empty string is assigned, the previously assigned value is cleared.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v211"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry id='kernel-version'>
+        <term><varname>KernelVersion=</varname></term>
+        <listitem>
+          <para>Checks whether the kernel version (as reported by <command>uname -r</command>) matches a certain
+          expression. See <varname>ConditionKernelVersion=</varname> in
+          <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
+          details. When prefixed with an exclamation mark (<literal>!</literal>), the result is negated.
+          If an empty string is assigned, the previously assigned value is cleared.
+          </para>
+
+        <xi:include href="version-info.xml" xpointer="v237"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry id='credential'>
+        <term><varname>Credential=</varname></term>
+        <listitem>
+          <para>Checks whether the specified credential was passed to the
+          <filename>systemd-udevd.service</filename> service. See <ulink
+          url="https://systemd.io/CREDENTIALS">System and Service Credentials</ulink> for details. When
+          prefixed with an exclamation mark (<literal>!</literal>), the result is negated.  If an empty
+          string is assigned, the previously assigned value is cleared.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v252"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry id='architecture'>
+        <term><varname>Architecture=</varname></term>
+        <listitem>
+          <para>Checks whether the system is running on a specific architecture. See
+          <varname>ConditionArchitecture=</varname> in
+          <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+          for details. When prefixed with an exclamation mark (<literal>!</literal>), the result is negated.
+          If an empty string is assigned, the previously assigned value is cleared.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v211"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry id='firmware'>
+        <term><varname>Firmware=</varname></term>
+        <listitem>
+          <para>Checks whether the system is running on a machine with the specified firmware. See
+          <varname>ConditionFirmware=</varname> in
+          <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+          for details. When prefixed with an exclamation mark (<literal>!</literal>), the result is negated.
+          If an empty string is assigned, the previously assigned value is cleared.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v249"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+
+  </refsect1>
+
+  <refsect1>
+    <title>[Link] Section Options</title>
+
+    <para>The [Link] section accepts the following
+    keys:</para>
+
+    <variablelist class='network-directives'>
+      <varlistentry>
+        <term><varname>Description=</varname></term>
+        <listitem>
+          <para>A description of the device.</para>
+
+        <xi:include href="version-info.xml" xpointer="v211"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>Alias=</varname></term>
+        <listitem>
+          <para>The <varname>ifalias</varname> interface property is set to this value.</para>
+
+        <xi:include href="version-info.xml" xpointer="v211"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>MACAddressPolicy=</varname></term>
+        <listitem>
+          <para>The policy by which the MAC address should be set. The
+          available policies are:
+          </para>
+
+          <variablelist>
+            <varlistentry>
+              <term><option>persistent</option></term>
+              <listitem>
+                <para>If the hardware has a persistent MAC address, as
+                most hardware should, and if it is used by the kernel,
+                nothing is done. Otherwise, a new MAC address is
+                generated which is guaranteed to be the same on every
+                boot for the given machine and the given device, but
+                which is otherwise random. This feature depends on ID_NET_NAME_*
+                properties to exist for the link. On hardware where these
+                properties are not set, the generation of a persistent MAC address
+                will fail.</para>
+
+                <xi:include href="version-info.xml" xpointer="v211"/>
+              </listitem>
+            </varlistentry>
+            <varlistentry>
+              <term><option>random</option></term>
+              <listitem>
+                <para>If the kernel is using a random MAC address,
+                nothing is done. Otherwise, a new address is randomly
+                generated each time the device appears, typically at
+                boot. Either way, the random address will have the
+                <literal>unicast</literal> and
+                <literal>locally administered</literal> bits set.</para>
+
+                <xi:include href="version-info.xml" xpointer="v211"/>
+              </listitem>
+            </varlistentry>
+            <varlistentry>
+              <term><option>none</option></term>
+              <listitem>
+                <para>Keeps the MAC address assigned by the kernel. Or use the MAC address specified in
+                <varname>MACAddress=</varname>.</para>
+
+                <xi:include href="version-info.xml" xpointer="v227"/>
+              </listitem>
+            </varlistentry>
+          </variablelist>
+
+          <para>An empty string assignment is equivalent to setting <literal>none</literal>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v211"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>MACAddress=</varname></term>
+        <listitem>
+          <para>The interface MAC address to use. For this setting to take effect,
+          <varname>MACAddressPolicy=</varname> must either be unset, empty, or <literal>none</literal>.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v211"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>NamePolicy=</varname></term>
+        <listitem>
+          <para>An ordered, space-separated list of policies by which the interface name should be set.
+          <varname>NamePolicy=</varname> may be disabled by specifying <option>net.ifnames=0</option> on the
+          kernel command line. Each of the policies may fail, and the first successful one is used. The name
+          is not set directly, but is exported to udev as the property <option>ID_NET_NAME</option>, which
+          is, by default, used by a
+          <citerefentry><refentrytitle>udev</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+          rule to set <varname>NAME</varname>. The available policies are:
+          </para>
+
+          <variablelist>
+            <varlistentry>
+              <term><option>kernel</option></term>
+              <listitem>
+                <para>If the kernel claims that the name it has set
+                for a device is predictable, then no renaming is
+                performed.</para>
+
+                <xi:include href="version-info.xml" xpointer="v216"/>
+              </listitem>
+            </varlistentry>
+            <varlistentry>
+              <term><option>database</option></term>
+              <listitem>
+                <para>The name is set based on entries in the udev's
+                Hardware Database with the key
+                <varname>ID_NET_NAME_FROM_DATABASE</varname>.
+                </para>
+
+                <xi:include href="version-info.xml" xpointer="v211"/>
+              </listitem>
+            </varlistentry>
+            <varlistentry>
+              <term><option>onboard</option></term>
+              <listitem>
+                <para>The name is set based on information given by
+                the firmware for on-board devices, as exported by the
+                udev property <varname>ID_NET_NAME_ONBOARD</varname>.
+                See <citerefentry><refentrytitle>systemd.net-naming-scheme</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
+                </para>
+
+                <xi:include href="version-info.xml" xpointer="v211"/>
+              </listitem>
+            </varlistentry>
+            <varlistentry>
+              <term><option>slot</option></term>
+              <listitem>
+                <para>The name is set based on information given by
+                the firmware for hot-plug devices, as exported by the
+                udev property <varname>ID_NET_NAME_SLOT</varname>.
+                See <citerefentry><refentrytitle>systemd.net-naming-scheme</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
+                </para>
+
+                <xi:include href="version-info.xml" xpointer="v211"/>
+              </listitem>
+            </varlistentry>
+            <varlistentry>
+              <term><option>path</option></term>
+              <listitem>
+                <para>The name is set based on the device's physical
+                location, as exported by the udev property
+                <varname>ID_NET_NAME_PATH</varname>.
+                See <citerefentry><refentrytitle>systemd.net-naming-scheme</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
+                </para>
+
+                <xi:include href="version-info.xml" xpointer="v211"/>
+              </listitem>
+            </varlistentry>
+            <varlistentry>
+              <term><option>mac</option></term>
+              <listitem>
+                <para>The name is set based on the device's persistent
+                MAC address, as exported by the udev property
+                <varname>ID_NET_NAME_MAC</varname>.
+                See <citerefentry><refentrytitle>systemd.net-naming-scheme</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
+                </para>
+
+                <xi:include href="version-info.xml" xpointer="v211"/>
+              </listitem>
+            </varlistentry>
+            <varlistentry>
+              <term><option>keep</option></term>
+              <listitem>
+                <para>If the device already had a name given by userspace (as part of creation of the device
+                or a rename), keep it.</para>
+
+                <xi:include href="version-info.xml" xpointer="v241"/>
+              </listitem>
+            </varlistentry>
+          </variablelist>
+
+            <xi:include href="version-info.xml" xpointer="v211"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>Name=</varname></term>
+        <listitem>
+          <para>The interface name to use. This option has lower precedence than
+          <varname>NamePolicy=</varname>, so for this setting to take effect, <varname>NamePolicy=</varname>
+          must either be unset, empty, disabled, or all policies configured there must fail. Also see the
+          example below with <literal>Name=dmz0</literal>.</para>
+
+          <para>Note that specifying a name that the kernel might use for another interface (for example
+          <literal>eth0</literal>) is dangerous because the name assignment done by udev will race with the
+          assignment done by the kernel, and only one interface may use the name. Depending on the order of
+          operations, either udev or the kernel will win, making the naming unpredictable. It is best to use
+          some different prefix, for example <literal>internal0</literal>/<literal>external0</literal> or
+          <literal>lan0</literal>/<literal>lan1</literal>/<literal>lan3</literal>.</para>
+
+          <para>Interface names must have a minimum length of 1 character and a maximum length of 15
+          characters, and may contain any 7bit ASCII character, with the exception of control characters,
+          <literal>:</literal>, <literal>/</literal> and <literal>%</literal>. While <literal>.</literal> is
+          an allowed character, it's recommended to avoid it when naming interfaces as various tools (such as
+          <citerefentry><refentrytitle>resolvconf</refentrytitle><manvolnum>1</manvolnum></citerefentry>) use
+          it as separator character. Also, fully numeric interface names are not allowed (in order to avoid
+          ambiguity with interface specification by numeric indexes), as are the special strings
+          <literal>.</literal>, <literal>..</literal>, <literal>all</literal> and
+          <literal>default</literal>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v211"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>AlternativeNamesPolicy=</varname></term>
+        <listitem>
+          <para>A space-separated list of policies by which the interface's alternative names
+          should be set. Each of the policies may fail, and all successful policies are used. The
+          available policies are <literal>database</literal>, <literal>onboard</literal>,
+          <literal>slot</literal>, <literal>path</literal>, and <literal>mac</literal>. If the
+          kernel does not support the alternative names, then this setting will be ignored.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v245"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>AlternativeName=</varname></term>
+        <listitem>
+          <para>The alternative interface name to use. This option can be specified multiple times.
+          If the empty string is assigned to this option, the list is reset, and all prior assignments
+          have no effect. If the kernel does not support the alternative names, then this setting will
+          be ignored.</para>
+
+          <para>Alternative interface names may be used to identify interfaces in various tools. In contrast
+          to the primary name (as configured with <varname>Name=</varname> above) there may be multiple
+          alternative names referring to the same interface. Alternative names may have a maximum length of
+          127 characters, in contrast to the 15 allowed for the primary interface name, but otherwise are
+          subject to the same naming constraints.</para>
+
+          <xi:include href="version-info.xml" xpointer="v245"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>TransmitQueues=</varname></term>
+        <listitem>
+          <para>Specifies the device's number of transmit queues. An integer in the range 1…4096.
+          When unset, the kernel's default will be used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v248"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>ReceiveQueues=</varname></term>
+        <listitem>
+          <para>Specifies the device's number of receive queues. An integer in the range 1…4096.
+          When unset, the kernel's default will be used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v248"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>TransmitQueueLength=</varname></term>
+        <listitem>
+          <para>Specifies the transmit queue length of the device in number of packets. An unsigned integer
+          in the range 0…4294967294. When unset, the kernel's default will be used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v248"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>MTUBytes=</varname></term>
+        <listitem>
+          <para>The maximum transmission unit in bytes to set for the
+          device. The usual suffixes K, M, G are supported and are
+          understood to the base of 1024.</para>
+
+          <xi:include href="version-info.xml" xpointer="v211"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>BitsPerSecond=</varname></term>
+        <listitem>
+          <para>The speed to set for the device, the value is rounded
+          down to the nearest Mbps. The usual suffixes K, M, G are
+          supported and are understood to the base of 1000.</para>
+
+          <xi:include href="version-info.xml" xpointer="v211"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>Duplex=</varname></term>
+        <listitem>
+          <para>The duplex mode to set for the device. The accepted values are <option>half</option> and
+          <option>full</option>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v211"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>AutoNegotiation=</varname></term>
+        <listitem>
+          <para>Takes a boolean. If set to yes, automatic negotiation of transmission parameters is enabled.
+          Autonegotiation is a procedure by which two connected ethernet devices choose
+          common transmission parameters, such as speed, duplex mode, and flow control.
+          When unset, the kernel's default will be used.</para>
+
+          <para>Note that if autonegotiation is enabled, speed and duplex settings are
+          read-only. If autonegotiation is disabled, speed and duplex settings are writable
+          if the driver supports multiple link modes.</para>
+
+          <xi:include href="version-info.xml" xpointer="v233"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>WakeOnLan=</varname></term>
+        <listitem>
+          <para>The Wake-on-LAN policy to set for the device. Takes the special value
+          <literal>off</literal> which disables Wake-on-LAN, or space separated list of the following
+          words:</para>
+
+          <variablelist>
+            <varlistentry>
+              <term><option>phy</option></term>
+              <listitem>
+                <para>Wake on PHY activity.</para>
+
+              <xi:include href="version-info.xml" xpointer="v211"/>
+              </listitem>
+            </varlistentry>
+            <varlistentry>
+              <term><option>unicast</option></term>
+              <listitem>
+                <para>Wake on unicast messages.</para>
+
+              <xi:include href="version-info.xml" xpointer="v235"/>
+              </listitem>
+            </varlistentry>
+            <varlistentry>
+              <term><option>multicast</option></term>
+              <listitem>
+                <para>Wake on multicast messages.</para>
+
+              <xi:include href="version-info.xml" xpointer="v235"/>
+              </listitem>
+            </varlistentry>
+            <varlistentry>
+              <term><option>broadcast</option></term>
+              <listitem>
+                <para>Wake on broadcast messages.</para>
+
+              <xi:include href="version-info.xml" xpointer="v235"/>
+              </listitem>
+            </varlistentry>
+            <varlistentry>
+              <term><option>arp</option></term>
+              <listitem>
+                <para>Wake on ARP.</para>
+
+              <xi:include href="version-info.xml" xpointer="v235"/>
+              </listitem>
+            </varlistentry>
+            <varlistentry>
+              <term><option>magic</option></term>
+              <listitem>
+                <para>Wake on receipt of a magic packet.
+                </para>
+
+                <xi:include href="version-info.xml" xpointer="v211"/>
+              </listitem>
+            </varlistentry>
+            <varlistentry>
+              <term><option>secureon</option></term>
+              <listitem>
+                <para>Enable SecureOn password for MagicPacket. Implied when
+                <varname>WakeOnLanPassword=</varname> is specified. If specified without
+                <varname>WakeOnLanPassword=</varname> option, then the password is read from the
+                credential <literal><replaceable>LINK</replaceable>.link.wol.password</literal> (e.g.,
+                <literal>60-foo.link.wol.password</literal>), and if the credential not found, then
+                read from <literal>wol.password</literal>. See
+                <varname>ImportCredential=</varname>/<varname>LoadCredential=</varname>/<varname>SetCredential=</varname> in
+                <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+                for details. The password in the credential, must be 6 bytes in hex format with each
+                byte separated by a colon (<literal>:</literal>) like an Ethernet MAC address, e.g.,
+                <literal>aa:bb:cc:dd:ee:ff</literal>.</para>
+
+                <xi:include href="version-info.xml" xpointer="v235"/>
+              </listitem>
+            </varlistentry>
+          </variablelist>
+
+          <para>Defaults to unset, and the device's default will be used. This setting can be specified
+          multiple times. If an empty string is assigned, then the all previous assignments are
+          cleared.</para>
+
+          <xi:include href="version-info.xml" xpointer="v211"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>WakeOnLanPassword=</varname></term>
+        <listitem>
+          <para>Specifies the SecureOn password for MagicPacket. Takes an absolute path to a regular
+          file or an <constant>AF_UNIX</constant> stream socket, or the plain password. When a path to
+          a regular file is specified, the password is read from it. When an
+          <constant>AF_UNIX</constant> stream socket is specified, a connection is made to it and the
+          password is read from it. The password must be 6 bytes in hex format with each byte separated
+          by a colon (<literal>:</literal>) like an Ethernet MAC address, e.g.,
+          <literal>aa:bb:cc:dd:ee:ff</literal>. This implies <varname>WakeOnLan=secureon</varname>.
+          Defaults to unset, and the current value will not be changed.</para>
+
+          <xi:include href="version-info.xml" xpointer="v250"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>Port=</varname></term>
+        <listitem>
+          <para>The port option is used to select the device port. The
+          supported values are:</para>
+
+          <variablelist>
+            <varlistentry>
+              <term><option>tp</option></term>
+              <listitem>
+                <para>An Ethernet interface using Twisted-Pair cable as the medium.</para>
+
+              <xi:include href="version-info.xml" xpointer="v234"/>
+              </listitem>
+            </varlistentry>
+            <varlistentry>
+              <term><option>aui</option></term>
+              <listitem>
+                <para>Attachment Unit Interface (AUI). Normally used with hubs.
+                </para>
+
+                <xi:include href="version-info.xml" xpointer="v234"/>
+              </listitem>
+            </varlistentry>
+            <varlistentry>
+              <term><option>bnc</option></term>
+              <listitem>
+                <para>An Ethernet interface using BNC connectors and co-axial cable.</para>
+
+              <xi:include href="version-info.xml" xpointer="v234"/>
+              </listitem>
+            </varlistentry>
+            <varlistentry>
+              <term><option>mii</option></term>
+              <listitem>
+                <para>An Ethernet interface using a Media Independent Interface (MII).</para>
+
+              <xi:include href="version-info.xml" xpointer="v234"/>
+              </listitem>
+            </varlistentry>
+            <varlistentry>
+              <term><option>fibre</option></term>
+              <listitem>
+                <para>An Ethernet interface using Optical Fibre as the medium.</para>
+
+              <xi:include href="version-info.xml" xpointer="v234"/>
+              </listitem>
+            </varlistentry>
+          </variablelist>
+
+            <xi:include href="version-info.xml" xpointer="v234"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>Advertise=</varname></term>
+        <listitem>
+          <para>This sets what speeds and duplex modes of operation are advertised for auto-negotiation.
+          This implies <literal>AutoNegotiation=yes</literal>. The supported values are:
+
+          <table>
+            <title>Supported advertise values</title>
+            <tgroup cols='3'>
+              <colspec colname='Advertise' />
+              <colspec colname='Speed' />
+              <colspec colname='Duplex Mode' />
+
+              <thead><row>
+                <entry>Advertise</entry>
+                <entry>Speed (Mbps)</entry>
+                <entry>Duplex Mode</entry>
+              </row></thead>
+              <xi:include href="ethtool-link-mode.xml" />
+            </tgroup>
+          </table>
+
+          By default this is unset, i.e. all possible modes will be advertised.
+          This option may be specified more than once, in which case all specified speeds and modes are advertised.
+          If the empty string is assigned to this option, the list is reset, and all prior assignments have no effect.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v240"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>ReceiveChecksumOffload=</varname></term>
+        <listitem>
+          <para>Takes a boolean. If set to true, hardware offload for checksumming of ingress
+          network packets is enabled. When unset, the kernel's default will be used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v245"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>TransmitChecksumOffload=</varname></term>
+        <listitem>
+          <para>Takes a boolean. If set to true, hardware offload for checksumming of egress
+          network packets is enabled. When unset, the kernel's default will be used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v245"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>TCPSegmentationOffload=</varname></term>
+        <listitem>
+          <para>Takes a boolean. If set to true, TCP Segmentation Offload (TSO) is enabled.
+          When unset, the kernel's default will be used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v232"/>
+        </listitem>
+      </varlistentry>
+       <varlistentry>
+      <term><varname>TCP6SegmentationOffload=</varname></term>
+        <listitem>
+          <para>Takes a boolean. If set to true, TCP6 Segmentation Offload (tx-tcp6-segmentation) is enabled.
+          When unset, the kernel's default will be used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v235"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>GenericSegmentationOffload=</varname></term>
+        <listitem>
+          <para>Takes a boolean. If set to true, Generic Segmentation Offload (GSO) is enabled.
+          When unset, the kernel's default will be used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v232"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>GenericReceiveOffload=</varname></term>
+        <listitem>
+          <para>Takes a boolean. If set to true, Generic Receive Offload (GRO) is enabled.
+          When unset, the kernel's default will be used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v232"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>GenericReceiveOffloadHardware=</varname></term>
+        <listitem>
+          <para>Takes a boolean. If set to true, hardware accelerated Generic Receive Offload (GRO) is
+          enabled. When unset, the kernel's default will be used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v250"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>LargeReceiveOffload=</varname></term>
+        <listitem>
+          <para>Takes a boolean. If set to true, Large Receive Offload (LRO) is enabled.
+          When unset, the kernel's default will be used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v232"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>ReceiveVLANCTAGHardwareAcceleration=</varname></term>
+        <listitem>
+          <para>Takes a boolean. If set to true, receive VLAN CTAG hardware acceleration is enabled.
+          When unset, the kernel's default will be used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v250"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>TransmitVLANCTAGHardwareAcceleration=</varname></term>
+        <listitem>
+          <para>Takes a boolean. If set to true, transmit VLAN CTAG hardware acceleration is enabled.
+          When unset, the kernel's default will be used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v250"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>ReceiveVLANCTAGFilter=</varname></term>
+        <listitem>
+          <para>Takes a boolean. If set to true, receive filtering on VLAN CTAGs is enabled.
+          When unset, the kernel's default will be used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v250"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>TransmitVLANSTAGHardwareAcceleration=</varname></term>
+        <listitem>
+          <para>Takes a boolean. If set to true, transmit VLAN STAG hardware acceleration is enabled.
+          When unset, the kernel's default will be used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v250"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>NTupleFilter=</varname></term>
+        <listitem>
+          <para>Takes a boolean. If set to true, receive N-tuple filters and actions are enabled.
+          When unset, the kernel's default will be used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v250"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>RxChannels=</varname></term>
+        <term><varname>TxChannels=</varname></term>
+        <term><varname>OtherChannels=</varname></term>
+        <term><varname>CombinedChannels=</varname></term>
+        <listitem>
+          <para>Specifies the number of receive, transmit, other, or combined channels, respectively.
+          Takes an unsigned integer in the range 1…4294967295 or <literal>max</literal>. If set to
+          <literal>max</literal>, the advertised maximum value of the hardware will be used. When
+          unset, the number will not be changed. Defaults to unset.</para>
+
+          <xi:include href="version-info.xml" xpointer="v239"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>RxBufferSize=</varname></term>
+        <term><varname>RxMiniBufferSize=</varname></term>
+        <term><varname>RxJumboBufferSize=</varname></term>
+        <term><varname>TxBufferSize=</varname></term>
+        <listitem>
+          <para>Specifies the maximum number of pending packets in the NIC receive buffer, mini receive
+          buffer, jumbo receive buffer, or transmit buffer, respectively. Takes an unsigned integer in
+          the range 1…4294967295 or <literal>max</literal>. If set to <literal>max</literal>, the
+          advertised maximum value of the hardware will be used. When unset, the number will not be
+          changed. Defaults to unset.</para>
+
+          <xi:include href="version-info.xml" xpointer="v244"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>RxFlowControl=</varname></term>
+        <listitem>
+          <para>Takes a boolean. When set, enables receive flow control, also known as the ethernet
+          receive PAUSE message (generate and send ethernet PAUSE frames). When unset, the kernel's
+          default will be used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>TxFlowControl=</varname></term>
+        <listitem>
+          <para>Takes a boolean. When set, enables transmit flow control, also known as the ethernet
+          transmit PAUSE message (respond to received ethernet PAUSE frames). When unset, the kernel's
+          default will be used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>AutoNegotiationFlowControl=</varname></term>
+        <listitem>
+          <para>Takes a boolean. When set, auto negotiation enables the interface to exchange state
+          advertisements with the connected peer so that the two devices can agree on the ethernet
+          PAUSE configuration. When unset, the kernel's default will be used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>GenericSegmentOffloadMaxBytes=</varname></term>
+        <listitem>
+          <para>Specifies the maximum size of a Generic Segment Offload (GSO) packet the
+          device should accept. The usual suffixes K, M, G are supported and are
+          understood to the base of 1024. An unsigned integer in the range 1…65536.
+          Defaults to unset.</para>
+
+          <xi:include href="version-info.xml" xpointer="v248"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>GenericSegmentOffloadMaxSegments=</varname></term>
+        <listitem>
+          <para>Specifies the maximum number of Generic Segment Offload (GSO) segments the device should
+          accept. An unsigned integer in the range 1…65535. Defaults to unset.</para>
+
+          <xi:include href="version-info.xml" xpointer="v248"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>UseAdaptiveRxCoalesce=</varname></term>
+        <term><varname>UseAdaptiveTxCoalesce=</varname></term>
+        <listitem>
+          <para>Boolean properties that, when set, enable/disable adaptive Rx/Tx coalescing if the hardware
+          supports it. When unset, the kernel's default will be used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v250"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>RxCoalesceSec=</varname></term>
+        <term><varname>RxCoalesceIrqSec=</varname></term>
+        <term><varname>RxCoalesceLowSec=</varname></term>
+        <term><varname>RxCoalesceHighSec=</varname></term>
+        <term><varname>TxCoalesceSec=</varname></term>
+        <term><varname>TxCoalesceIrqSec=</varname></term>
+        <term><varname>TxCoalesceLowSec=</varname></term>
+        <term><varname>TxCoalesceHighSec=</varname></term>
+        <listitem>
+          <para>These properties configure the delay before Rx/Tx interrupts are generated after a packet is
+          sent/received. The <literal>Irq</literal> properties come into effect when the host is servicing an
+          IRQ. The <literal>Low</literal> and <literal>High</literal> properties come into effect when the
+          packet rate drops below the low packet rate threshold or exceeds the high packet rate threshold
+          respectively if adaptive Rx/Tx coalescing is enabled. When unset, the kernel's defaults will be
+          used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v250"/>
+        </listitem>
+      </varlistentry>
+        <varlistentry>
+        <term><varname>RxMaxCoalescedFrames=</varname></term>
+        <term><varname>RxMaxCoalescedIrqFrames=</varname></term>
+        <term><varname>RxMaxCoalescedLowFrames=</varname></term>
+        <term><varname>RxMaxCoalescedHighFrames=</varname></term>
+        <term><varname>TxMaxCoalescedFrames=</varname></term>
+        <term><varname>TxMaxCoalescedIrqFrames=</varname></term>
+        <term><varname>TxMaxCoalescedLowFrames=</varname></term>
+        <term><varname>TxMaxCoalescedHighFrames=</varname></term>
+        <listitem>
+          <para>These properties configure the maximum number of frames that are sent/received before a Rx/Tx
+          interrupt is generated. The <literal>Irq</literal> properties come into effect when the host is
+          servicing an IRQ. The <literal>Low</literal> and <literal>High</literal> properties come into
+          effect when the packet rate drops below the low packet rate threshold or exceeds the high packet
+          rate threshold respectively if adaptive Rx/Tx coalescing is enabled. When unset, the kernel's
+          defaults will be used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v250"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>CoalescePacketRateLow=</varname></term>
+        <term><varname>CoalescePacketRateHigh=</varname></term>
+        <listitem>
+          <para>These properties configure the low and high packet rate (expressed in packets per second)
+          threshold respectively and are used to determine when the corresponding coalescing settings for low
+          and high packet rates come into effect if adaptive Rx/Tx coalescing is enabled. If unset, the
+          kernel's defaults will be used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v250"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>CoalescePacketRateSampleIntervalSec=</varname></term>
+        <listitem>
+          <para>Configures how often to sample the packet rate used for adaptive Rx/Tx coalescing. This
+          property cannot be zero. This lowest time granularity supported by this property is seconds.
+          Partial seconds will be rounded up before being passed to the kernel. If unset, the kernel's
+          default will be used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v250"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>StatisticsBlockCoalesceSec=</varname></term>
+        <listitem>
+          <para>How long to delay driver in-memory statistics block updates. If the driver does not have an
+          in-memory statistic block, this property is ignored. This property cannot be zero. If unset, the
+          kernel's default will be used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v250"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>MDI=</varname></term>
+        <listitem>
+          <para>Specifies the medium dependent interface (MDI) mode for the interface. A MDI describes
+          the interface from a physical layer implementation to the physical medium used to carry the
+          transmission. Takes one of the following words: <literal>straight</literal> (or equivalently:
+          <literal>mdi</literal>), <literal>crossover</literal> (or equivalently:
+          <literal>mdi-x</literal>, <literal>mdix</literal>), and <literal>auto</literal>. When
+          <literal>straight</literal>, the MDI straight through mode will be used. When
+          <literal>crossover</literal>, the MDI crossover (MDI-X) mode will be used. When
+          <literal>auto</literal>, the MDI status is automatically detected. Defaults to unset, and the
+          kernel's default will be used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v251"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SR-IOVVirtualFunctions=</varname></term>
+        <listitem>
+          <para>Specifies the number of SR-IOV virtual functions. Takes an integer in the range
+          0…2147483647. Defaults to unset, and automatically determined from the values specified in
+          the <varname>VirtualFunction=</varname> settings in the [SR-IOV] sections.</para>
+
+          <xi:include href="version-info.xml" xpointer="v251"/>
+        </listitem>
+      </varlistentry>
+
+    </variablelist>
+  </refsect1>
+
+  <refsect1 id='sr-iov'>
+    <title>[SR-IOV] Section Options</title>
+    <para>The [SR-IOV] section accepts the following keys. Specify several [SR-IOV] sections to
+    configure several SR-IOVs. SR-IOV provides the ability to partition a single physical PCI resource
+    into virtual PCI functions which can then be injected into a VM. In the case of network VFs, SR-IOV
+    improves north-south network performance (that is, traffic with endpoints outside the host machine)
+    by allowing traffic to bypass the host machine’s network stack.</para>
+
+    <variablelist class='network-directives'>
+      <varlistentry>
+        <term><varname>VirtualFunction=</varname></term>
+        <listitem>
+          <para>Specifies a Virtual Function (VF), lightweight PCIe function designed solely to move
+          data in and out. Takes an integer in the range 0…2147483646. This option is compulsory.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v251"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>VLANId=</varname></term>
+        <listitem>
+          <para>Specifies VLAN ID of the virtual function. Takes an integer in the range 1…4095.</para>
+
+        <xi:include href="version-info.xml" xpointer="v251"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>QualityOfService=</varname></term>
+        <listitem>
+          <para>Specifies quality of service of the virtual function. Takes an integer in the range
+          1…4294967294.</para>
+
+          <xi:include href="version-info.xml" xpointer="v251"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>VLANProtocol=</varname></term>
+        <listitem>
+          <para>Specifies VLAN protocol of the virtual function. Takes <literal>802.1Q</literal> or
+          <literal>802.1ad</literal>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v251"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>MACSpoofCheck=</varname></term>
+        <listitem>
+          <para>Takes a boolean. Controls the MAC spoof checking. When unset, the kernel's default will
+          be used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v251"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>QueryReceiveSideScaling=</varname></term>
+        <listitem>
+          <para>Takes a boolean. Toggle the ability of querying the receive side scaling (RSS)
+          configuration of the virtual function (VF). The VF RSS information like RSS hash key may be
+          considered sensitive on some devices where this information is shared between VF and the
+          physical function (PF). When unset, the kernel's default will be used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v251"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Trust=</varname></term>
+        <listitem>
+          <para>Takes a boolean. Allows one to set trust mode of the virtual function (VF). When set,
+          VF users can set a specific feature which may impact security and/or performance. When unset,
+          the kernel's default will be used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v251"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>LinkState=</varname></term>
+        <listitem>
+          <para>Allows one to set the link state of the virtual function (VF). Takes a boolean or a
+          special value <literal>auto</literal>. Setting to <literal>auto</literal> means a
+          reflection of the physical function (PF) link state, <literal>yes</literal> lets the VF to
+          communicate with other VFs on this host even if the PF link state is down,
+          <literal>no</literal> causes the hardware to drop any packets sent by the VF. When unset,
+          the kernel's default will be used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v251"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>MACAddress=</varname></term>
+        <listitem>
+          <para>Specifies the MAC address for the virtual function.</para>
+
+        <xi:include href="version-info.xml" xpointer="v251"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Examples</title>
+
+    <example>
+      <title>/usr/lib/systemd/network/99-default.link</title>
+
+      <para>The link file <filename>99-default.link</filename> that is shipped with systemd defines the
+      default policies for the interface name, alternative names, and MAC address of links.</para>
+
+      <programlisting>[Match]
+OriginalName=*
+
+[Link]
+NamePolicy=keep kernel database onboard slot path
+AlternativeNamesPolicy=database onboard slot path
+MACAddressPolicy=persistent</programlisting>
+    </example>
+
+    <example>
+      <title>/etc/systemd/network/10-dmz.link</title>
+
+      <para>This example assigns the fixed name <literal>dmz0</literal> to the interface with the MAC address
+      00:a0:de:63:7a:e6:</para>
+
+      <programlisting>[Match]
+MACAddress=00:a0:de:63:7a:e6
+
+[Link]
+Name=dmz0</programlisting>
+
+      <para><varname>NamePolicy=</varname> is not set, so <varname>Name=</varname> takes effect. We use the
+      <literal>10-</literal> prefix to order this file early in the list. Note that it needs to be before
+      <filename>99-default.link</filename>, i.e. it needs a numerical prefix, to have any effect at all.</para>
+    </example>
+
+    <example>
+      <title>(Re-)applying a .link file to an interface</title>
+
+      <para>After a new .link file has been created, or an existing .link file modified, the new settings
+      may be applied to the matching interface with the following commands:</para>
+
+      <programlisting>$ sudo udevadm control --reload
+$ sudo ip link set eth0 down
+$ sudo udevadm trigger --verbose --settle --action add /sys/class/net/eth0</programlisting>
+
+      <para>You may also need to stop the service that manages the network interface, e.g.
+      <citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+      or <filename>NetworkManager.service</filename> before the above operation, and then restart the service
+      after that. For more details about <command>udevadm</command> command, see
+      <citerefentry><refentrytitle>udevadm</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
+    </example>
+
+    <example>
+      <title>Debugging <varname>NamePolicy=</varname> assignments</title>
+
+      <programlisting>$ sudo SYSTEMD_LOG_LEVEL=debug udevadm test-builtin net_setup_link /sys/class/net/hub0
+…
+Parsed configuration file /usr/lib/systemd/network/99-default.link
+Parsed configuration file /etc/systemd/network/10-eth0.link
+ID_NET_DRIVER=cdc_ether
+Config file /etc/systemd/network/10-eth0.link applies to device hub0
+link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
+hub0: Device has name_assign_type=4
+Using default interface naming scheme 'v240'.
+hub0: Policies didn't yield a name, using specified Name=hub0.
+ID_NET_LINK_FILE=/etc/systemd/network/10-eth0.link
+ID_NET_NAME=hub0
+…</programlisting>
+
+     <para>Explicit <varname>Name=</varname> configuration wins in this case.</para>
+
+     <programlisting>sudo SYSTEMD_LOG_LEVEL=debug udevadm test-builtin net_setup_link /sys/class/net/enp0s31f6
+…
+Parsed configuration file /usr/lib/systemd/network/99-default.link
+Parsed configuration file /etc/systemd/network/10-eth0.link
+Created link configuration context.
+ID_NET_DRIVER=e1000e
+Config file /usr/lib/systemd/network/99-default.link applies to device enp0s31f6
+link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
+enp0s31f6: Device has name_assign_type=4
+Using default interface naming scheme 'v240'.
+enp0s31f6: Policy *keep*: keeping existing userspace name
+enp0s31f6: Device has addr_assign_type=0
+enp0s31f6: MAC on the device already matches policy *persistent*
+ID_NET_LINK_FILE=/usr/lib/systemd/network/99-default.link
+…
+</programlisting>
+
+     <para>In this case, the interface was already renamed, so the <option>keep</option> policy specified as
+     the first option in <filename index="false">99-default.link</filename> means that the existing name is
+     preserved. If <option>keep</option> was removed, or if were in boot before the renaming has happened,
+     we might get the following instead:</para>
+
+     <programlisting>enp0s31f6: Policy *path* yields "enp0s31f6".
+enp0s31f6: Device has addr_assign_type=0
+enp0s31f6: MAC on the device already matches policy *persistent*
+ID_NET_LINK_FILE=/usr/lib/systemd/network/99-default.link
+ID_NET_NAME=enp0s31f6
+…
+</programlisting>
+
+      <para>Please note that the details of output are subject to change.</para>
+    </example>
+
+    <example>
+      <title>/etc/systemd/network/10-internet.link</title>
+
+      <para>This example assigns the fixed name
+      <literal>internet0</literal> to the interface with the device
+      path <literal>pci-0000:00:1a.0-*</literal>:</para>
+
+      <programlisting>[Match]
+Path=pci-0000:00:1a.0-*
+
+[Link]
+Name=internet0</programlisting>
+    </example>
+
+    <example>
+      <title>/etc/systemd/network/25-wireless.link</title>
+
+      <para>Here's an overly complex example that shows the use of a large number of [Match] and [Link] settings.</para>
+
+      <programlisting>[Match]
+MACAddress=12:34:56:78:9a:bc
+Driver=brcmsmac
+Path=pci-0000:02:00.0-*
+Type=wlan
+Virtualization=no
+Host=my-laptop
+Architecture=x86-64
+
+[Link]
+Name=wireless0
+MTUBytes=1450
+BitsPerSecond=10M
+WakeOnLan=magic
+MACAddress=cb:a9:87:65:43:21</programlisting>
+    </example>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry>
+        <refentrytitle>systemd-udevd.service</refentrytitle><manvolnum>8</manvolnum>
+      </citerefentry>,
+      <citerefentry>
+        <refentrytitle>udevadm</refentrytitle><manvolnum>8</manvolnum>
+      </citerefentry>,
+      <citerefentry>
+        <refentrytitle>systemd.netdev</refentrytitle><manvolnum>5</manvolnum>
+      </citerefentry>,
+      <citerefentry>
+        <refentrytitle>systemd.network</refentrytitle><manvolnum>5</manvolnum>
+      </citerefentry>,
+      <citerefentry>
+        <refentrytitle>systemd-network-generator.service</refentrytitle><manvolnum>8</manvolnum>
+      </citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd.mount.xml b/man/systemd.mount.xml
new file mode 100644
index 0000000..c2e470e
--- /dev/null
+++ b/man/systemd.mount.xml
@@ -0,0 +1,658 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd.mount" xmlns:xi="http://www.w3.org/2001/XInclude">
+  <refentryinfo>
+    <title>systemd.mount</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd.mount</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd.mount</refname>
+    <refpurpose>Mount unit configuration</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename><replaceable>mount</replaceable>.mount</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>A unit configuration file whose name ends in
+    <literal>.mount</literal> encodes information about a file system
+    mount point controlled and supervised by systemd.</para>
+
+    <para>This man page lists the configuration options specific to
+    this unit type. See
+    <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for the common options of all unit configuration files. The common
+    configuration items are configured in the generic [Unit] and
+    [Install] sections. The mount specific configuration options are
+    configured in the [Mount] section.</para>
+
+    <para>Additional options are listed in
+    <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    which define the execution environment the
+    <citerefentry project='man-pages'><refentrytitle>mount</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    program is executed in, and in
+    <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    which define the way the processes are terminated, and in
+    <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    which configure resource control settings for the processes of the
+    service.</para>
+
+    <para>Note that the options <varname>User=</varname> and
+    <varname>Group=</varname> are not useful for mount units.
+    systemd passes two parameters to
+    <citerefentry project='man-pages'><refentrytitle>mount</refentrytitle><manvolnum>8</manvolnum></citerefentry>;
+    the values of <varname>What=</varname> and <varname>Where=</varname>.
+    When invoked in this way,
+    <citerefentry project='man-pages'><refentrytitle>mount</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    does not read any options from <filename>/etc/fstab</filename>, and
+    must be run as UID 0.</para>
+
+    <para>Mount units must be named after the mount point directories they control. Example: the mount point
+    <filename index="false">/home/lennart</filename> must be configured in a unit file
+    <filename>home-lennart.mount</filename>.  For details about the escaping logic used to convert a file
+    system path to a unit name, see
+    <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>. Note
+    that mount units cannot be templated, nor is possible to add multiple names to a mount unit by creating
+    symlinks to its unit file.</para>
+
+    <para>Optionally, a mount unit may be accompanied by an automount
+    unit, to allow on-demand or parallelized mounting. See
+    <citerefentry><refentrytitle>systemd.automount</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+
+    <para>Mount points created at runtime (independently of unit files
+    or <filename>/etc/fstab</filename>) will be monitored by systemd
+    and appear like any other mount unit in systemd. See
+    <filename>/proc/self/mountinfo</filename> description in
+    <citerefentry project='man-pages'><refentrytitle>proc</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+    </para>
+
+    <para>Some file systems have special semantics as API file systems
+    for kernel-to-userspace and userspace-to-userspace interfaces. Some
+    of them may not be changed via mount units, and cannot be
+    disabled. For a longer discussion see <ulink
+    url="https://www.freedesktop.org/wiki/Software/systemd/APIFileSystems">API
+    File Systems</ulink>.</para>
+
+    <para>The
+    <citerefentry><refentrytitle>systemd-mount</refentrytitle><manvolnum>1</manvolnum></citerefentry> command
+    allows creating <filename>.mount</filename> and <filename>.automount</filename> units dynamically and
+    transiently from the command line.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Automatic Dependencies</title>
+
+    <refsect2>
+      <title>Implicit Dependencies</title>
+
+      <para>The following dependencies are implicitly added:</para>
+
+      <itemizedlist>
+        <listitem><para>If a mount unit is beneath another mount unit in the file
+        system hierarchy, both a requirement dependency and an ordering
+        dependency between both units are created automatically.</para></listitem>
+
+        <listitem><para>Block device backed file systems automatically gain
+        <varname>BindsTo=</varname> and <varname>After=</varname> type
+        dependencies on the device unit encapsulating the block
+        device (see below).</para></listitem>
+
+        <listitem><para>If traditional file system quota is enabled for a mount
+        unit, automatic <varname>Wants=</varname> and
+        <varname>Before=</varname> dependencies on
+        <filename>systemd-quotacheck.service</filename> and
+        <filename>quotaon.service</filename> are added.</para></listitem>
+
+        <listitem><para>Additional implicit dependencies may be added as result of
+        execution and resource control parameters as documented in
+        <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        and
+        <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+        </para></listitem>
+      </itemizedlist>
+    </refsect2>
+
+    <refsect2>
+      <title>Default Dependencies</title>
+
+      <para>The following dependencies are added unless <varname>DefaultDependencies=no</varname> is set:</para>
+
+      <itemizedlist>
+        <listitem><para>All mount units acquire automatic <varname>Before=</varname> and <varname>Conflicts=</varname> on
+        <filename>umount.target</filename> in order to be stopped during shutdown.</para></listitem>
+
+        <listitem><para>Mount units referring to local file systems automatically gain
+        an <varname>After=</varname> dependency on <filename>local-fs-pre.target</filename>, and a
+        <varname>Before=</varname> dependency on <filename>local-fs.target</filename> unless
+        <option>nofail</option> mount option is set.</para></listitem>
+
+        <listitem><para>Network mount units
+        automatically acquire <varname>After=</varname> dependencies on <filename>remote-fs-pre.target</filename>,
+        <filename>network.target</filename> and <filename>network-online.target</filename>, and gain a
+        <varname>Before=</varname> dependency on <filename>remote-fs.target</filename> unless
+        <option>nofail</option> mount option is set. Towards the latter a
+        <varname>Wants=</varname> unit is added as well.</para></listitem>
+      </itemizedlist>
+
+      <para>Mount units referring to local and network file systems are distinguished by their file system type
+      specification. In some cases this is not sufficient (for example network block device based mounts, such as
+      iSCSI), in which case <option>_netdev</option> may be added to the mount option string of the unit, which forces
+      systemd to consider the mount unit a network mount.</para>
+    </refsect2>
+  </refsect1>
+
+  <refsect1>
+    <title><filename>fstab</filename></title>
+
+    <para>Mount units may either be configured via unit files, or via <filename>/etc/fstab</filename> (see
+    <citerefentry project='man-pages'><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for details). Mounts listed in <filename>/etc/fstab</filename> will be converted into native units
+    dynamically at boot and when the configuration of the system manager is reloaded. In general, configuring
+    mount points through <filename>/etc/fstab</filename> is the preferred approach to manage mounts for
+    humans. For tooling, writing mount units should be preferred over editing <filename>/etc/fstab</filename>.
+    See <citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    for details about the conversion from <filename>/etc/fstab</filename> to mount units.</para>
+
+    <para>The NFS mount option <option>bg</option> for NFS background mounts
+    as documented in <citerefentry project='man-pages'><refentrytitle>nfs</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    is detected by <command>systemd-fstab-generator</command> and the options
+    are transformed so that systemd fulfills the job-control implications of
+    that option.  Specifically <command>systemd-fstab-generator</command> acts
+    as though <literal>x-systemd.mount-timeout=infinity,retry=10000</literal> was
+    prepended to the option list, and <literal>fg,nofail</literal> was appended.
+    Depending on specific requirements, it may be appropriate to provide some of
+    these options explicitly, or to make use of the
+    <literal>x-systemd.automount</literal> option described below instead
+    of using <literal>bg</literal>.</para>
+
+    <para>When reading <filename>/etc/fstab</filename> a few special
+    mount options are understood by systemd which influence how
+    dependencies are created for mount points. systemd will create a
+    dependency of type <varname>Wants=</varname> or
+    <option>Requires=</option> (see option <option>nofail</option>
+    below), from either <filename>local-fs.target</filename> or
+    <filename>remote-fs.target</filename>, depending whether the file
+    system is local or remote.</para>
+
+    <variablelist class='fstab-options'>
+
+      <varlistentry>
+        <term><option>x-systemd.requires=</option></term>
+
+        <listitem><para>Configures a <varname>Requires=</varname> and
+        an <varname>After=</varname> dependency between the created
+        mount unit and another systemd unit, such as a device or mount
+        unit. The argument should be a unit name, or an absolute path
+        to a device node or mount point.  This option may be specified
+        more than once. This option is particularly useful for mount
+        point declarations that need an additional device to be around
+        (such as an external journal device for journal file systems)
+        or an additional mount to be in place (such as an overlay file
+        system that merges multiple mount points). See
+        <varname>After=</varname> and <varname>Requires=</varname> in
+        <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for details.</para>
+
+        <para>Note that this option always applies to the created mount unit
+        only regardless whether <option>x-systemd.automount</option> has been
+        specified.</para>
+
+        <xi:include href="version-info.xml" xpointer="v220"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>x-systemd.before=</option></term>
+        <term><option>x-systemd.after=</option></term>
+
+        <listitem><para>In the created mount unit, configures a
+        <varname>Before=</varname> or <varname>After=</varname>
+        dependency on another systemd unit, such as a mount unit.
+        The argument should be a unit name or an absolute path
+        to a mount point. This option may be specified more than once.
+        This option is particularly useful for mount point declarations
+        with <option>nofail</option> option that are mounted
+        asynchronously but need to be mounted before or after some unit
+        start, for example, before <filename>local-fs.target</filename>
+        unit.
+        See <varname>Before=</varname> and <varname>After=</varname> in
+        <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for details.</para>
+
+        <para>Note that these options always apply to the created mount unit
+        only regardless whether <option>x-systemd.automount</option> has been
+        specified.</para>
+
+        <xi:include href="version-info.xml" xpointer="v233"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>x-systemd.wanted-by=</option></term>
+        <term><option>x-systemd.required-by=</option></term>
+
+        <listitem><para>In the created mount unit, configures a
+        <varname>WantedBy=</varname> or <varname>RequiredBy=</varname>
+        dependency on another unit.  This option may be
+        specified more than once. If this is specified, the normal
+        automatic dependencies on the created mount unit, e.g.,
+        <filename>local-fs.target</filename>, are not automatically
+        created. See <varname>WantedBy=</varname> and <varname>RequiredBy=</varname> in
+        <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for details.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>x-systemd.requires-mounts-for=</option></term>
+
+        <listitem><para>Configures a
+        <varname>RequiresMountsFor=</varname> dependency between the
+        created mount unit and other mount units. The argument must be
+        an absolute path. This option may be specified more than once.
+        See <varname>RequiresMountsFor=</varname> in
+        <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for details.</para>
+
+        <xi:include href="version-info.xml" xpointer="v220"/></listitem>
+       </varlistentry>
+
+      <varlistentry>
+        <term><option>x-systemd.device-bound=</option></term>
+
+        <listitem><para>Takes a boolean argument. If true or no argument, a <varname>BindsTo=</varname> dependency
+        on the backing device is set. If false, the mount unit is not stopped no matter whether the backing device
+        is still present. This is useful when the file system is backed by volume managers. If not set, and the mount
+        comes from unit fragments, i.e. generated from <filename>/etc/fstab</filename> by <citerefentry>
+        <refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry> or loaded from
+        a manually configured mount unit, a combination of <varname>Requires=</varname> and <varname>StopPropagatedFrom=</varname>
+        dependencies is set on the backing device. If doesn't, only <varname>Requires=</varname> is used.</para>
+
+        <xi:include href="version-info.xml" xpointer="v233"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>x-systemd.automount</option></term>
+
+        <listitem><para>An automount unit will be created for the file
+        system. See
+        <citerefentry><refentrytitle>systemd.automount</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for details.</para>
+
+        <xi:include href="version-info.xml" xpointer="v215"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>x-systemd.idle-timeout=</option></term>
+
+        <listitem><para>Configures the idle timeout of the
+        automount unit. See <varname>TimeoutIdleSec=</varname> in
+        <citerefentry><refentrytitle>systemd.automount</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for details.</para>
+
+        <xi:include href="version-info.xml" xpointer="v220"/></listitem>
+      </varlistentry>
+
+      <varlistentry id='device-timeout'>
+        <term><option>x-systemd.device-timeout=</option></term>
+
+        <listitem><para>Configure how long systemd should wait for a
+        device to show up before giving up on an entry from
+        <filename>/etc/fstab</filename>. Specify a time in seconds or
+        explicitly append a unit such as <literal>s</literal>,
+        <literal>min</literal>, <literal>h</literal>,
+        <literal>ms</literal>.</para>
+
+        <para>Note that this option can only be used in
+        <filename>/etc/fstab</filename>, and will be
+        ignored when part of the <varname>Options=</varname>
+        setting in a unit file.</para>
+
+        <xi:include href="version-info.xml" xpointer="v215"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>x-systemd.mount-timeout=</option></term>
+
+        <listitem><para>Configure how long systemd should wait for the
+        mount command to finish before giving up on an entry from
+        <filename>/etc/fstab</filename>. Specify a time in seconds or
+        explicitly append a unit such as <literal>s</literal>,
+        <literal>min</literal>, <literal>h</literal>,
+        <literal>ms</literal>.</para>
+
+        <para>Note that this option can only be used in
+        <filename>/etc/fstab</filename>, and will be
+        ignored when part of the <varname>Options=</varname>
+        setting in a unit file.</para>
+
+        <para>See <varname>TimeoutSec=</varname> below for
+        details.</para>
+
+        <xi:include href="version-info.xml" xpointer="v233"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>x-systemd.makefs</option></term>
+
+        <listitem><para>The file system will be initialized
+        on the device. If the device is not "empty", i.e. it contains any signature,
+        the operation will be skipped. It is hence expected that this option
+        remains set even after the device has been initialized.</para>
+
+        <para>Note that this option can only be used in
+        <filename>/etc/fstab</filename>, and will be ignored when part of the
+        <varname>Options=</varname> setting in a unit file.</para>
+
+        <para>See
+        <citerefentry><refentrytitle>systemd-makefs@.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+        </para>
+
+        <para><citerefentry project='man-pages'><refentrytitle>wipefs</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        may be used to remove any signatures from a block device to force
+        <option>x-systemd.makefs</option> to reinitialize the device.</para>
+
+        <xi:include href="version-info.xml" xpointer="v236"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>x-systemd.growfs</option></term>
+
+        <listitem><para>The file system will be grown to occupy the full block
+        device. If the file system is already at maximum size, no action will
+        be performed. It is hence expected that this option remains set even after
+        the file system has been grown. Only certain file system types are supported,
+        see
+        <citerefentry><refentrytitle>systemd-makefs@.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        for details.</para>
+
+        <para>Note that this option can only be used in
+        <filename>/etc/fstab</filename>, and will be ignored when part of the
+        <varname>Options=</varname> setting in a unit file.</para>
+
+        <xi:include href="version-info.xml" xpointer="v236"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>x-systemd.pcrfs</option></term>
+
+        <listitem><para>Measures file system identity information (mount point, type, label, UUID, partition
+        label, partition UUID) into PCR 15 after the file system has been mounted. This ensures the
+        <citerefentry><refentrytitle>systemd-pcrfs@.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        or <filename>systemd-pcrfs-root.service</filename> services are pulled in by the mount unit.</para>
+
+        <para>Note that this option can only be used in <filename>/etc/fstab</filename>, and will be ignored
+        when part of the <varname>Options=</varname> setting in a unit file. It is also implied for the root
+        and <filename>/usr/</filename> partitions discovered by
+        <citerefentry><refentrytitle>systemd-gpt-auto-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v253"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>x-systemd.rw-only</option></term>
+
+        <listitem><para>If a mount operation fails to mount the file system
+        read-write, it normally tries mounting the file system read-only instead.
+        This option disables that behaviour, and causes the mount to fail
+        immediately instead. This option is translated into the
+        <varname>ReadWriteOnly=</varname> setting in a unit file.</para>
+
+        <xi:include href="version-info.xml" xpointer="v246"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>_netdev</option></term>
+
+        <listitem><para>Normally the file system type is used to determine if a
+        mount is a "network mount", i.e. if it should only be started after the
+        network is available. Using this option overrides this detection and
+        specifies that the mount requires network.</para>
+
+        <para>Network mount units are ordered between <filename>remote-fs-pre.target</filename>
+        and <filename>remote-fs.target</filename>, instead of
+        <filename>local-fs-pre.target</filename> and <filename>local-fs.target</filename>.
+        They also pull in <filename>network-online.target</filename> and are ordered after
+        it and <filename>network.target</filename>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v235"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>noauto</option></term>
+        <term><option>auto</option></term>
+
+        <listitem><para>With <option>noauto</option>, the mount unit will not be added as a dependency for
+        <filename>local-fs.target</filename> or <filename>remote-fs.target</filename>. This means that it
+        will not be mounted automatically during boot, unless it is pulled in by some other unit. The
+        <option>auto</option> option has the opposite meaning and is the default.</para>
+
+        <para>Note that if <option>x-systemd.automount</option> (see above) is used, neither
+        <option>auto</option> nor <option>noauto</option> have any effect. The matching automount unit will
+        be added as a dependency to the appropriate target.</para>
+
+        <xi:include href="version-info.xml" xpointer="v215"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>nofail</option></term>
+
+        <listitem><para>With <option>nofail</option>, this mount will be only wanted, not required, by
+        <filename>local-fs.target</filename> or <filename>remote-fs.target</filename>. Moreover the mount unit is not
+        ordered before these target units. This means that the boot will continue without waiting for the mount unit
+        and regardless whether the mount point can be mounted successfully.</para>
+
+        <xi:include href="version-info.xml" xpointer="v215"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>x-initrd.mount</option></term>
+
+        <listitem><para>An additional filesystem to be mounted in the initrd. See
+        <filename>initrd-fs.target</filename> description in
+        <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>. This
+        is both an indicator to the initrd to mount this partition early and an indicator to the host to
+        leave the partition mounted until final shutdown. Or in other words, if this flag is set it is
+        assumed the mount shall be active during the entire regular runtime of the system, i.e. established
+        before the initrd transitions into the host all the way until the host transitions to the final
+        shutdown phase.</para>
+
+        <xi:include href="version-info.xml" xpointer="v215"/></listitem>
+      </varlistentry>
+    </variablelist>
+
+    <para>If a mount point is configured in both
+    <filename>/etc/fstab</filename> and a unit file that is stored
+    below <filename>/usr/</filename>, the former will take precedence.
+    If the unit file is stored below <filename>/etc/</filename>, it
+    will take precedence. This means: native unit files take
+    precedence over traditional configuration files, but this is
+    superseded by the rule that configuration in
+    <filename>/etc/</filename> will always take precedence over
+    configuration in <filename>/usr/</filename>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>Mount unit files may include [Unit] and [Install] sections, which are described in
+    <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+    </para>
+
+    <para>Mount unit files must include a [Mount] section, which carries
+    information about the file system mount points it supervises. A
+    number of options that may be used in this section are shared with
+    other unit types. These options are documented in
+    <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    and
+    <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+    The options specific to the [Mount] section of mount units are the
+    following:</para>
+
+    <variablelist class='unit-directives'>
+
+      <varlistentry>
+        <term><varname>What=</varname></term>
+        <listitem><para>Takes an absolute path of a device node, file or other resource to mount. See
+        <citerefentry
+        project='man-pages'><refentrytitle>mount</refentrytitle><manvolnum>8</manvolnum></citerefentry> for
+        details. If this refers to a device node, a dependency on the respective device unit is automatically
+        created. (See
+        <citerefentry><refentrytitle>systemd.device</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for more information.) This option is mandatory. Note that the usual specifier expansion is applied
+        to this setting, literal percent characters should hence be written as <literal
+        class='specifiers'>%%</literal>. If this mount is a bind mount and the specified path does not exist
+        yet it is created as directory.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Where=</varname></term>
+        <listitem><para>Takes an absolute path of a file or directory for the mount point; in particular, the
+        destination cannot be a symbolic link.  If the mount point does not exist at the time of mounting, it
+        is created as either a directory or a file. The former is the usual case; the latter is done only if this mount
+        is a bind mount and the source (<varname>What=</varname>) is not a directory.
+        This string must be reflected in the unit filename. (See above.) This option
+        is mandatory.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Type=</varname></term>
+        <listitem><para>Takes a string for the file system type. See
+        <citerefentry project='man-pages'><refentrytitle>mount</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        for details. This setting is optional.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Options=</varname></term>
+
+        <listitem><para>Mount options to use when mounting. This takes a comma-separated list of options. This setting
+        is optional. Note that the usual specifier expansion is applied to this setting, literal percent characters
+        should hence be written as <literal class='specifiers'>%%</literal>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SloppyOptions=</varname></term>
+
+        <listitem><para>Takes a boolean argument. If true, parsing of
+        the options specified in <varname>Options=</varname> is
+        relaxed, and unknown mount options are tolerated. This
+        corresponds with
+        <citerefentry project='man-pages'><refentrytitle>mount</refentrytitle><manvolnum>8</manvolnum></citerefentry>'s
+        <parameter>-s</parameter> switch. Defaults to
+        off.</para>
+
+        <xi:include href="version-info.xml" xpointer="v215"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>LazyUnmount=</varname></term>
+
+        <listitem><para>Takes a boolean argument. If true, detach the
+        filesystem from the filesystem hierarchy at time of the unmount
+        operation, and clean up all references to the filesystem as
+        soon as they are not busy anymore.
+        This corresponds with
+        <citerefentry project='man-pages'><refentrytitle>umount</refentrytitle><manvolnum>8</manvolnum></citerefentry>'s
+        <parameter>-l</parameter> switch. Defaults to
+        off.</para>
+
+        <xi:include href="version-info.xml" xpointer="v232"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ReadWriteOnly=</varname></term>
+
+        <listitem><para>Takes a boolean argument. If false, a mount
+        point that shall be mounted read-write but cannot be mounted
+        so is retried to be mounted read-only. If true the operation
+        will fail immediately after the read-write mount attempt did
+        not succeed. This corresponds with
+        <citerefentry project='man-pages'><refentrytitle>mount</refentrytitle><manvolnum>8</manvolnum></citerefentry>'s
+        <parameter>-w</parameter> switch. Defaults to
+        off.</para>
+
+        <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ForceUnmount=</varname></term>
+
+        <listitem><para>Takes a boolean argument. If true, force an
+        unmount (in case of an unreachable NFS system).
+        This corresponds with
+        <citerefentry project='man-pages'><refentrytitle>umount</refentrytitle><manvolnum>8</manvolnum></citerefentry>'s
+        <parameter>-f</parameter> switch. Defaults to
+        off.</para>
+
+        <xi:include href="version-info.xml" xpointer="v232"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>DirectoryMode=</varname></term>
+        <listitem><para>Directories of mount points (and any parent
+        directories) are automatically created if needed. This option
+        specifies the file system access mode used when creating these
+        directories. Takes an access mode in octal notation. Defaults
+        to 0755.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>TimeoutSec=</varname></term>
+        <listitem><para>Configures the time to wait for the mount
+        command to finish. If a command does not exit within the
+        configured time, the mount will be considered failed and be
+        shut down again. All commands still running will be terminated
+        forcibly via <constant>SIGTERM</constant>, and after another
+        delay of this time with <constant>SIGKILL</constant>. (See
+        <option>KillMode=</option> in
+        <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>.)
+        Takes a unit-less value in seconds, or a time span value such
+        as "5min 20s". Pass 0 to disable the timeout logic. The
+        default value is set from <varname>DefaultTimeoutStartSec=</varname> option in
+        <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+        </para></listitem>
+      </varlistentry>
+    </variablelist>
+
+    <xi:include href="systemd.service.xml" xpointer="shared-unit-options" />
+  </refsect1>
+
+  <refsect1>
+      <title>See Also</title>
+      <para>
+        <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.device</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry project='man-pages'><refentrytitle>proc</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry project='man-pages'><refentrytitle>mount</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd-mount</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+      </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd.net-naming-scheme.xml b/man/systemd.net-naming-scheme.xml
new file mode 100644
index 0000000..e9c00c9
--- /dev/null
+++ b/man/systemd.net-naming-scheme.xml
@@ -0,0 +1,632 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd.net-naming-scheme" xmlns:xi="http://www.w3.org/2001/XInclude">
+  <refentryinfo>
+    <title>systemd.net-naming-scheme</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd.net-naming-scheme</refentrytitle>
+    <manvolnum>7</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd.net-naming-scheme</refname>
+    <refpurpose>Network device naming schemes</refpurpose>
+  </refnamediv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>Network interfaces names and MAC addresses may be generated based on certain stable interface
+    attributes. This is possible when there is enough information about the device to generate those
+    attributes and the use of this information is configured. This page describes interface naming, i.e. what
+    possible names may be generated. Those names are generated by the
+    <citerefentry><refentrytitle>systemd-udevd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    builtin <command>net_id</command> and exported as udev properties
+    (<varname>ID_NET_NAME_ONBOARD=</varname>, <varname>ID_NET_LABEL_ONBOARD=</varname>,
+    <varname>ID_NET_NAME_PATH=</varname>, <varname>ID_NET_NAME_SLOT=</varname>).</para>
+
+    <para>Names and MAC addresses are derived from various stable device metadata attributes. Newer versions
+    of udev take more of these attributes into account, improving (and thus possibly changing) the names and
+    addresses used for the same devices. Different versions of those generation rules are called "naming
+    schemes". The default naming scheme is chosen at compilation time. Usually this will be the latest
+    implemented version, but it is also possible to set one of the older versions to preserve
+    compatibility. This may be useful for example for distributions, which may introduce new versions of
+    systemd in stable releases without changing the naming scheme. The naming scheme may also be overridden
+    using the <varname>net.naming-scheme=</varname> kernel command line switch, see
+    <citerefentry><refentrytitle>systemd-udevd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+    Available naming schemes are described below.</para>
+
+    <para>After the udev properties have been generated, appropriate udev rules may be used to actually rename
+    devices based on those properties. See the description of <varname>NamePolicy=</varname> and
+    <varname>MACAddressPolicy=</varname> in
+    <citerefentry><refentrytitle>systemd.link</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+
+    <para>Note that while the concept of network interface naming schemes is primarily relevant in the
+    context of <filename>systemd-udevd.service</filename>, the
+    <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    container manager also takes it into account when naming network interfaces, see below.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Policies</title>
+
+    <para>All names start with a two-character prefix that signifies the interface type.</para>
+
+    <table>
+      <title>Two character prefixes based on the type of interface</title>
+
+      <tgroup cols='2'>
+        <thead>
+          <row>
+            <entry>Prefix</entry>
+            <entry>Description</entry>
+          </row>
+        </thead>
+        <tbody>
+          <row>
+            <entry><constant>en</constant></entry>
+            <entry>Ethernet</entry>
+          </row>
+          <row>
+            <entry><constant>ib</constant></entry>
+            <entry>InfiniBand</entry>
+          </row>
+          <row>
+            <entry><constant>sl</constant></entry>
+            <entry>Serial line IP (slip)</entry>
+          </row>
+          <row>
+            <entry><constant>wl</constant></entry>
+            <entry>Wireless local area network (WLAN)</entry>
+          </row>
+          <row>
+            <entry><constant>ww</constant></entry>
+            <entry>Wireless wide area network (WWAN)</entry>
+          </row>
+        </tbody>
+      </tgroup>
+    </table>
+
+    <para>The udev <command>net_id</command> builtin exports the following udev device properties:</para>
+
+    <variablelist>
+        <varlistentry>
+          <term><varname>ID_NET_NAME_ONBOARD=<replaceable>prefix</replaceable><constant>o</constant><replaceable>number</replaceable></varname></term>
+          <term><varname>ID_NET_NAME_ONBOARD=<replaceable>prefix</replaceable><constant>d</constant><replaceable>number</replaceable></varname></term>
+
+          <listitem><para>This name is set based on the numeric ordering information given by the firmware
+          for on-board devices. Different schemes are used depending on the firmware type, as described in
+          the table below.</para>
+
+            <table>
+              <title>On-board naming schemes</title>
+
+              <tgroup cols='2'>
+                <thead>
+                  <row>
+                    <entry>Format</entry>
+                    <entry>Description</entry>
+                  </row>
+                </thead>
+
+                <tbody>
+                  <row>
+                    <entry><replaceable>prefix</replaceable><constant>o</constant><replaceable>number</replaceable></entry>
+                    <entry>PCI on-board index</entry>
+                  </row>
+
+                  <row>
+                    <entry><replaceable>prefix</replaceable><constant>d</constant><replaceable>number</replaceable></entry>
+                    <entry>Devicetree alias index</entry>
+                  </row>
+
+                </tbody>
+              </tgroup>
+            </table>
+
+              <xi:include href="version-info.xml" xpointer="v243"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>ID_NET_LABEL_ONBOARD=<replaceable>prefix</replaceable> <replaceable>label</replaceable></varname></term>
+
+          <listitem><para>This property is set based on textual label given by the firmware for on-board
+          devices. The name consists of the prefix concatenated with the label. This is only available for
+          PCI devices.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v243"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>ID_NET_NAME_MAC=<replaceable>prefix</replaceable><constant>x</constant><replaceable>AABBCCDDEEFF</replaceable></varname></term>
+
+          <listitem><para>This name consists of the prefix, letter <constant>x</constant>, and 12 hexadecimal
+          digits of the MAC address. It is available if the device has a fixed MAC address. Because this name
+          is based on an attribute of the card itself, it remains "stable" when the device is moved (even
+          between machines), but will change when the hardware is replaced.</para>
+
+          <xi:include href="version-info.xml" xpointer="v243"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>ID_NET_NAME_SLOT=<replaceable>prefix</replaceable>[<constant>P</constant><replaceable>domain</replaceable>]<constant>s</constant><replaceable>slot</replaceable>[<constant>f</constant><replaceable>function</replaceable>][<constant>n</constant><replaceable>port_name</replaceable>|<constant>d</constant><replaceable>dev_port</replaceable>]</varname></term>
+          <term><varname>ID_NET_NAME_SLOT=<replaceable>prefix</replaceable><constant>v</constant><replaceable>slot</replaceable></varname></term>
+          <term><varname>ID_NET_NAME_SLOT=<replaceable>prefix</replaceable><constant>x</constant><replaceable>slot</replaceable></varname></term>
+          <term><varname>ID_NET_NAME_SLOT=<replaceable>prefix</replaceable>[<constant>P</constant><replaceable>domain</replaceable>]<constant>s</constant><replaceable>slot</replaceable>[<constant>f</constant><replaceable>function</replaceable>][<constant>n</constant><replaceable>port_name</replaceable>|<constant>d</constant><replaceable>dev_port</replaceable>]<constant>b</constant><replaceable>number</replaceable></varname></term>
+          <term><varname>ID_NET_NAME_SLOT=<replaceable>prefix</replaceable>[<constant>P</constant><replaceable>domain</replaceable>]<constant>s</constant><replaceable>slot</replaceable>[<constant>f</constant><replaceable>function</replaceable>][<constant>n</constant><replaceable>port_name</replaceable>|<constant>d</constant><replaceable>dev_port</replaceable>]<constant>u</constant><replaceable>port</replaceable>…[<constant>c</constant><replaceable>config</replaceable>][<constant>i</constant><replaceable>interface</replaceable>]</varname></term>
+          <term><varname>ID_NET_NAME_SLOT=<replaceable>prefix</replaceable>[<constant>P</constant><replaceable>domain</replaceable>]<constant>s</constant><replaceable>slot</replaceable>[<constant>f</constant><replaceable>function</replaceable>][<constant>n</constant><replaceable>port_name</replaceable>|<constant>d</constant><replaceable>dev_port</replaceable>]<constant>v</constant><replaceable>slot</replaceable></varname></term>
+          <term><varname>ID_NET_NAME_SLOT=<replaceable>prefix</replaceable>[<constant>P</constant><replaceable>domain</replaceable>]<constant>s</constant><replaceable>slot</replaceable>[<constant>f</constant><replaceable>function</replaceable>][<constant>n</constant><replaceable>port_name</replaceable>|<constant>d</constant><replaceable>dev_port</replaceable>]<constant>r</constant><replaceable>slot</replaceable></varname></term>
+
+          <listitem><para>This property describes the slot position. Different schemes are used depending on
+          the bus type, as described in the table below. In case of USB, BCMA, and SR-VIO devices, the full
+          name consists of the prefix, PCI slot identifier, and USB or BCMA or SR-VIO slot identifier. The
+          first two parts are denoted as "…" in the table below.</para>
+
+          <table>
+            <title>Slot naming schemes</title>
+
+            <tgroup cols='2'>
+              <thead>
+                <row>
+                  <entry>Format</entry>
+                  <entry>Description</entry>
+                </row>
+              </thead>
+
+              <tbody>
+                <row>
+                  <entry><replaceable>prefix</replaceable> [<constant>P</constant><replaceable>domain</replaceable>] <constant>s</constant><replaceable>slot</replaceable> [<constant>f</constant><replaceable>function</replaceable>] [<constant>n</constant><replaceable>port_name</replaceable> | <constant>d</constant><replaceable>dev_port</replaceable>]</entry>
+                  <entry>PCI slot number</entry>
+                </row>
+
+                <row>
+                  <entry><replaceable>prefix</replaceable> <constant>v</constant><replaceable>slot</replaceable></entry>
+                  <entry>VIO slot number (IBM PowerVM)</entry>
+                </row>
+
+                <row>
+                  <entry><replaceable>prefix</replaceable> <constant>X</constant><replaceable>number</replaceable></entry>
+                  <entry>VIF interface number (Xen)</entry>
+                </row>
+
+                <row>
+                  <entry>… <constant>b</constant><replaceable>number</replaceable></entry>
+                  <entry>Broadcom bus (BCMA) core number</entry>
+                </row>
+
+                <row>
+                  <entry>… <constant>u</constant><replaceable>port</replaceable>… [<constant>c</constant><replaceable>config</replaceable>] [<constant>i</constant><replaceable>interface</replaceable>]</entry>
+                  <entry>USB port number chain</entry>
+                </row>
+
+                <row>
+                  <entry>… <constant>v</constant><replaceable>slot</replaceable></entry>
+                  <entry>SR-VIO slot number</entry>
+                </row>
+
+                <row>
+                  <entry>… <constant>r</constant><replaceable>slot</replaceable></entry>
+                  <entry>SR-IOV slot number</entry>
+                </row>
+              </tbody>
+            </tgroup>
+          </table>
+
+          <para>The PCI domain is only prepended when it is not 0. All multi-function PCI devices will carry
+          the <constant>f<replaceable>function</replaceable></constant> number in the device name, including
+          the function 0 device. For non-multi-function devices, the number is suppressed if 0. The port name
+          <replaceable>port_name</replaceable> is used, or the port number
+          <constant>d</constant><replaceable>dev_port</replaceable> if the name is not known.</para>
+
+          <para>For BCMA devices, the core number is suppressed when 0.</para>
+
+          <para>For USB devices the full chain of port numbers of hubs is composed. If the name gets longer
+          than the maximum number of 15 characters, the name is not exported. The usual USB configuration
+          number 1 and interface number 0 values are suppressed.</para>
+
+          <para>SR-IOV virtual devices are named based on the name of the parent interface, with a suffix of
+          <constant>v</constant> and the virtual device number, with any leading zeros removed. The bus
+          number is ignored.</para>
+
+          <para>SR-IOV virtual device representors are named based on the name of the physical device
+          interface, with a suffix of <constant>r</constant> and the number of the virtual device that
+          is linked to the particular representor, with any leading zeros removed. The physical port
+          name and the bus number are ignored.</para>
+
+          <para>In some configurations a parent PCI bridge of a given network controller may be associated
+          with a slot. In such case we don't generate this device property to avoid possible naming conflicts.</para>
+
+          <xi:include href="version-info.xml" xpointer="v243"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>ID_NET_NAME_PATH=<replaceable>prefix</replaceable><constant>c</constant><replaceable>bus_id</replaceable></varname></term>
+          <term><varname>ID_NET_NAME_PATH=<replaceable>prefix</replaceable><constant>a</constant><replaceable>vendor</replaceable><replaceable>model</replaceable><constant>i</constant><replaceable>instance</replaceable></varname></term>
+          <term><varname>ID_NET_NAME_PATH=<replaceable>prefix</replaceable><constant>i</constant><replaceable>address</replaceable><constant>n</constant><replaceable>port_name</replaceable></varname></term>
+          <term><varname>ID_NET_NAME_PATH=<replaceable>prefix</replaceable><constant>u</constant><replaceable>port</replaceable>…</varname></term>
+          <term><varname>ID_NET_NAME_PATH=<replaceable>prefix</replaceable>[<constant>P</constant><replaceable>domain</replaceable>]<constant>p</constant><replaceable>bus</replaceable><constant>s</constant><replaceable>slot</replaceable>[<constant>f</constant><replaceable>function</replaceable>][<constant>n</constant><replaceable>phys_port_name</replaceable>|<constant>d</constant><replaceable>dev_port</replaceable>]</varname></term>
+          <term><varname>ID_NET_NAME_PATH=<replaceable>prefix</replaceable>[<constant>P</constant><replaceable>domain</replaceable>]<constant>p</constant><replaceable>bus</replaceable><constant>s</constant><replaceable>slot</replaceable>[<constant>f</constant><replaceable>function</replaceable>][<constant>n</constant><replaceable>phys_port_name</replaceable>|<constant>d</constant><replaceable>dev_port</replaceable>]<constant>b</constant><replaceable>number</replaceable></varname></term>
+          <term><varname>ID_NET_NAME_PATH=<replaceable>prefix</replaceable>[<constant>P</constant><replaceable>domain</replaceable>]<constant>p</constant><replaceable>bus</replaceable><constant>s</constant><replaceable>slot</replaceable>[<constant>f</constant><replaceable>function</replaceable>][<constant>n</constant><replaceable>phys_port_name</replaceable>|<constant>d</constant><replaceable>dev_port</replaceable>]<constant>u</constant><replaceable>port</replaceable>…[<constant>c</constant><replaceable>config</replaceable>][<constant>i</constant><replaceable>interface</replaceable>]</varname></term>
+
+          <listitem><para>This property describes the device installation location. Different schemes are
+          used depending on the bus type, as described in the table below. For BCMA and USB devices, PCI path
+          information must known, and the full name consists of the prefix, PCI slot identifier, and USB or
+          BCMA location. The first two parts are denoted as "…" in the table below.</para>
+
+          <table>
+            <title>Path naming schemes</title>
+
+            <tgroup cols='2'>
+              <thead>
+                <row>
+                  <entry>Format</entry>
+                  <entry>Description</entry>
+                </row>
+              </thead>
+
+              <tbody>
+                <row>
+                  <entry><replaceable>prefix</replaceable> <constant>c</constant><replaceable>bus_id</replaceable></entry>
+                  <entry>CCW or grouped CCW device identifier</entry>
+                </row>
+
+                <row>
+                  <entry><replaceable>prefix</replaceable> <constant>a</constant><replaceable>vendor</replaceable> <replaceable>model</replaceable> <constant>i</constant><replaceable>instance</replaceable></entry>
+                  <entry>ACPI path names for ARM64 platform devices</entry>
+                </row>
+
+                <row>
+                  <entry><replaceable>prefix</replaceable> <constant>i</constant><replaceable>address</replaceable> <constant>n</constant><replaceable>port_name</replaceable></entry>
+                  <entry>Netdevsim (simulated networking device) device number and port name</entry>
+                </row>
+
+                <row>
+                  <entry><replaceable>prefix</replaceable> [<constant>P</constant><replaceable>domain</replaceable>] <constant>p</constant><replaceable>bus</replaceable> <constant>s</constant><replaceable>slot</replaceable> [<constant>f</constant><replaceable>function</replaceable>] [<constant>n</constant><replaceable>phys_port_name</replaceable> | <constant>d</constant><replaceable>dev_port</replaceable>]</entry>
+                  <entry>PCI geographical location</entry>
+                </row>
+
+                <row>
+                  <entry>… <constant>b</constant><replaceable>number</replaceable></entry>
+                  <entry>Broadcom bus (BCMA) core number</entry>
+                </row>
+
+                <row>
+                  <entry>… <constant>u</constant><replaceable>port</replaceable>… [<constant>c</constant><replaceable>config</replaceable>] [<constant>i</constant><replaceable>interface</replaceable>]</entry>
+                  <entry>USB port number chain</entry>
+                </row>
+
+              </tbody>
+            </tgroup>
+          </table>
+
+          <para>CCW and grouped CCW devices are found in IBM System Z mainframes. Any leading zeros and
+          dots are suppressed.</para>
+
+          <para>For PCI, BCMA, and USB devices, the same rules as described above for slot naming are
+          used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v243"/>
+          </listitem>
+        </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>History</title>
+
+    <para>The following "naming schemes" have been defined (which may be chosen at system boot-up time via
+    the <varname>net.naming-scheme=</varname> kernel command line switch, see above):</para>
+
+    <variablelist>
+        <varlistentry>
+          <term><constant>v238</constant></term>
+
+          <listitem><para>This is the naming scheme that was implemented in systemd 238.</para>
+
+          <xi:include href="version-info.xml" xpointer="v243"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>v239</constant></term>
+
+          <listitem><para>Naming was changed for virtual network interfaces created with SR-IOV and NPAR and
+          for devices where the PCI network controller device does not have a slot number associated.</para>
+
+          <para>SR-IOV virtual devices are named based on the name of the parent interface, with a suffix of
+          <literal>v<replaceable>port</replaceable></literal>, where <replaceable>port</replaceable> is the
+          virtual device number. Previously those virtual devices were named as if completely independent.
+          </para>
+
+          <para>The ninth and later NPAR virtual devices are named following the scheme used for the first
+          eight NPAR partitions. Previously those devices were not renamed and the kernel default
+          ("eth<replaceable>N</replaceable>") was used.</para>
+
+          <para>Names are also generated for PCI devices where the PCI network controller device does not
+          have an associated slot number itself, but one of its parents does. Previously those devices were
+          not renamed and the kernel default was used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v243"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>v240</constant></term>
+
+          <listitem><para>The <literal>ib</literal> prefix and stable names for infiniband devices are
+          introduced. Previously those devices were not renamed.</para>
+
+          <para>The ACPI index field (used in <varname>ID_NET_NAME_ONBOARD=</varname>) is now also used when
+          0.</para>
+
+          <para>A new naming policy <varname>NamePolicy=keep</varname> was introduced. With this policy, if
+          the network device name was already set by userspace, the device will not be renamed
+          again. Previously, this naming policy applied implicitly, and now it must be explicitly
+          requested. Effectively, this means that network devices will be renamed according to the
+          configuration, even if they have been renamed already, if <constant>keep</constant> is not
+          specified as the naming policy in the <filename index="false">.link</filename> file. See
+          <citerefentry><refentrytitle>systemd.link</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+          for a description of <varname>NamePolicy=</varname>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v243"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>v241</constant></term>
+
+          <listitem><para><option>MACAddressPolicy=persistent</option> was extended to set MAC addresses
+          based on the device name. Previously addresses were only based on the
+          <varname index="false">ID_NET_NAME_*</varname> attributes, which meant that interface names would
+          never be generated for virtual devices. Now a persistent address will be generated for most
+          devices, including in particular bridges.</para>
+
+          <para>Note: when userspace does not set a MAC address for a bridge device, the kernel will
+          initially assign a random address, and then change it when the first device is enslaved to the
+          bridge. With this naming policy change, bridges get a persistent MAC address based on the bridge
+          name instead of the first enslaved device.</para>
+
+          <xi:include href="version-info.xml" xpointer="v243"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>v243</constant></term>
+
+          <listitem><para>Support for renaming netdevsim (simulated networking) devices was added. Previously
+          those devices were not renamed.</para>
+
+          <para>Previously two-letter interface type prefix was prepended to
+          <varname>ID_NET_LABEL_ONBOARD=</varname>. This is not done anymore.</para>
+
+          <xi:include href="version-info.xml" xpointer="v243"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>v245</constant></term>
+
+          <listitem><para>When
+          <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+          derives the name for the host side of the network interface created with
+          <option>--network-veth</option> from the container name it previously simply truncated the result
+          at 15 characters if longer (since that's the maximum length for network interface names). From now
+          on, for any interface name that would be longer than 15 characters the last 4 characters are set to
+          a 24bit hash value of the full interface name. This way network interface name collisions between
+          multiple similarly named containers (who only differ in container name suffix) should be less
+          likely (but still possible, since the 24bit hash value is very small).</para>
+
+          <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>v247</constant></term>
+
+          <listitem><para>When a PCI slot is associated with a PCI bridge that has multiple child network
+          controllers, the same value of the <varname>ID_NET_NAME_SLOT</varname> property might be derived
+          for those controllers. This would cause a naming conflict if the property is selected as the device
+          name. Now, we detect this situation and don't produce the <varname>ID_NET_NAME_SLOT</varname>
+          property.</para>
+
+          <xi:include href="version-info.xml" xpointer="v247"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>v249</constant></term>
+
+          <listitem><para>PCI hotplug slot names for the s390 PCI driver are a hexadecimal representation
+          of the <filename>function_id</filename> device attribute. This attribute is now used to build the
+          <varname>ID_NET_NAME_SLOT</varname>. Before that, all slot names were parsed as decimal
+          numbers, which could either result in an incorrect value of the <varname>ID_NET_NAME_SLOT</varname>
+          property or none at all.</para>
+
+          <para>Some firmware and hypervisor implementations report unreasonably high numbers for the
+          on-board index. To prevent the generation of bogus on-board interface names, index numbers greater
+          than 16381 (2¹⁴-1) were ignored. For s390 PCI devices index values up to 65535 (2¹⁶-1) are valid.
+          To account for that, the limit was increased to 65535.</para>
+
+          <para>The udev rule <varname>NAME=</varname> replaces <literal>:</literal>,
+          <literal>/</literal>, and <literal>%</literal> with an underscore (<literal>_</literal>), and
+          refuses strings which contain only numerics.</para>
+
+          <xi:include href="version-info.xml" xpointer="v249"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>v250</constant></term>
+
+          <listitem><para>Added naming scheme for Xen netfront "vif" interfaces based on the guest side
+          VIF number set from the Xen config (or the interface index in AWS EC2).</para>
+
+          <xi:include href="version-info.xml" xpointer="v250"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>v251</constant></term>
+
+          <listitem><para>Since version <constant>v247</constant> we no longer set
+          <varname>ID_NET_NAME_SLOT</varname> if we detect that a PCI device associated with a slot is a PCI
+          bridge as that would create naming conflict when there are more child devices on that bridge. Now,
+          this is relaxed and we will use slot information to generate the name based on it but only if
+          the PCI device has multiple functions. This is safe because distinct function number is a part of
+          the device name for multifunction devices.</para>
+
+          <xi:include href="version-info.xml" xpointer="v251"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>v252</constant></term>
+
+          <listitem><para>Added naming scheme for platform devices with devicetree aliases.</para>
+
+          <xi:include href="version-info.xml" xpointer="v252"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>v253</constant></term>
+
+          <listitem><para>Set <varname>ID_NET_NAME_PATH</varname> for usb devices not connected via a PCI bus.</para>
+
+          <xi:include href="version-info.xml" xpointer="v253"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>v254</constant></term>
+
+          <listitem><para>Naming was changed for SR-IOV virtual device representors, optionally settable at
+          compilation time. The <literal>r<replaceable>slot</replaceable></literal> suffix was added to
+          differentiate SR-IOV virtual device representors attached to a single physical device interface.
+          Because of a mistake, this scheme was <emphasis>not the the default scheme for systemd version
+          254</emphasis>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v255"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><constant>v255</constant></term>
+
+          <listitem><para>Naming was changed for SR-IOV virtual device representors to enable the
+          change introduced in <constant>v254</constant> by default.</para>
+
+          <xi:include href="version-info.xml" xpointer="v255"/>
+          </listitem>
+        </varlistentry>
+
+      </variablelist>
+
+    <para>Note that <constant>latest</constant> may be used to denote the latest scheme known (to this
+    particular version of systemd).</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Examples</title>
+
+    <example>
+      <title>Using <command>udevadm test-builtin</command> to display device properties</title>
+
+      <programlisting>$ udevadm test-builtin net_id /sys/class/net/enp0s31f6
+...
+Using default interface naming scheme 'v243'.
+ID_NET_NAMING_SCHEME=v243
+ID_NET_NAME_MAC=enx54ee75cb1dc0
+ID_OUI_FROM_DATABASE=Wistron InfoComm(Kunshan)Co.,Ltd.
+ID_NET_NAME_PATH=enp0s31f6
+...</programlisting>
+    </example>
+
+    <example>
+      <title>PCI Ethernet card with firmware index "1"</title>
+
+      <programlisting>ID_NET_NAME_ONBOARD=eno1
+ID_NET_NAME_ONBOARD_LABEL=Ethernet Port 1
+      </programlisting>
+    </example>
+
+    <example>
+      <title>PCI Ethernet card in hotplug slot with firmware index number</title>
+
+      <programlisting># /sys/devices/pci0000:00/0000:00:1c.3/0000:05:00.0/net/ens1
+ID_NET_NAME_MAC=enx000000000466
+ID_NET_NAME_PATH=enp5s0
+ID_NET_NAME_SLOT=ens1</programlisting>
+    </example>
+
+    <example>
+      <title>PCI Ethernet multi-function card with 2 ports</title>
+
+      <programlisting># /sys/devices/pci0000:00/0000:00:1c.0/0000:02:00.0/net/enp2s0f0
+ID_NET_NAME_MAC=enx78e7d1ea46da
+ID_NET_NAME_PATH=enp2s0f0
+
+# /sys/devices/pci0000:00/0000:00:1c.0/0000:02:00.1/net/enp2s0f1
+ID_NET_NAME_MAC=enx78e7d1ea46dc
+ID_NET_NAME_PATH=enp2s0f1</programlisting>
+    </example>
+
+    <example>
+      <title>PCI WLAN card</title>
+
+      <programlisting># /sys/devices/pci0000:00/0000:00:1c.1/0000:03:00.0/net/wlp3s0
+ID_NET_NAME_MAC=wlx0024d7e31130
+ID_NET_NAME_PATH=wlp3s0</programlisting>
+    </example>
+
+    <example>
+      <title>PCI IB host adapter with 2 ports</title>
+
+      <programlisting># /sys/devices/pci0000:00/0000:00:03.0/0000:15:00.0/net/ibp21s0f0
+ID_NET_NAME_PATH=ibp21s0f0
+
+# /sys/devices/pci0000:00/0000:00:03.0/0000:15:00.1/net/ibp21s0f1
+ID_NET_NAME_PATH=ibp21s0f1</programlisting>
+    </example>
+
+    <example>
+      <title>USB built-in 3G modem</title>
+
+      <programlisting># /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.4/2-1.4:1.6/net/wwp0s29u1u4i6
+ID_NET_NAME_MAC=wwx028037ec0200
+ID_NET_NAME_PATH=wwp0s29u1u4i6</programlisting>
+    </example>
+
+    <example>
+      <title>USB Android phone</title>
+
+      <programlisting># /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0/net/enp0s29u1u2
+ID_NET_NAME_MAC=enxd626b3450fb5
+ID_NET_NAME_PATH=enp0s29u1u2</programlisting>
+    </example>
+
+    <example>
+      <title>s390 grouped CCW interface</title>
+
+      <programlisting># /sys/devices/css0/0.0.0007/0.0.f5f0/group_device/net/encf5f0
+ID_NET_NAME_MAC=enx026d3c00000a
+ID_NET_NAME_PATH=encf5f0</programlisting>
+    </example>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>udev</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>udevadm</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <ulink url="https://systemd.io/PREDICTABLE_INTERFACE_NAMES">Predictable Network Interface Names</ulink>,
+      <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd.netdev.xml b/man/systemd.netdev.xml
new file mode 100644
index 0000000..9cad358
--- /dev/null
+++ b/man/systemd.netdev.xml
@@ -0,0 +1,2896 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd.netdev" conditional='ENABLE_NETWORKD'
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd.network</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd.netdev</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd.netdev</refname>
+    <refpurpose>Virtual Network Device configuration</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename><replaceable>netdev</replaceable>.netdev</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>A plain ini-style text file that encodes configuration about a virtual network device, used by
+    <citerefentry><refentrytitle>systemd-networkd</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+    See <citerefentry><refentrytitle>systemd.syntax</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+    for a general description of the syntax.</para>
+
+    <para>The main Virtual Network Device file must have the extension <filename>.netdev</filename>;
+    other extensions are ignored. Virtual network devices are created as soon as networkd is
+    started. If a netdev with the specified name already exists, networkd will use that as-is rather
+    than create its own. Note that the settings of the pre-existing netdev will not be changed by
+    networkd.</para>
+
+    <para>The <filename>.netdev</filename> files are read from the files located in the system network
+    directory <filename>/usr/lib/systemd/network</filename> and
+    <filename>/usr/local/lib/systemd/network</filename>, the volatile runtime network directory
+    <filename>/run/systemd/network</filename> and the local administration network directory
+    <filename>/etc/systemd/network</filename>. All configuration files are collectively sorted and
+    processed in alphanumeric order, regardless of the directories in which they live. However, files
+    with identical filenames replace each other. It is recommended that each filename is prefixed with
+    a number smaller than <literal>70</literal> (e.g. <filename>10-vlan.netdev</filename>). Otherwise,
+    <filename>.netdev</filename> files generated by
+    <citerefentry><refentrytitle>systemd-network-generator.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    may take precedence over user configured files. Files in <filename>/etc/</filename> have the
+    highest priority, files in <filename>/run/</filename> take precedence over files with the same name
+    in <filename>/usr/lib/</filename>. This can be used to override a system-supplied configuration
+    file with a local file if needed. As a special case, an empty file (file size 0) or symlink with
+    the same name pointing to <filename>/dev/null</filename> disables the configuration file entirely
+    (it is "masked").</para>
+
+    <para>Along with the netdev file <filename>foo.netdev</filename>, a "drop-in" directory
+    <filename>foo.netdev.d/</filename> may exist. All files with the suffix <literal>.conf</literal>
+    from this directory will be merged in the alphanumeric order and parsed after the main file itself
+    has been parsed. This is useful to alter or add configuration settings, without having to modify
+    the main configuration file. Each drop-in file must have appropriate section headers.</para>
+
+    <para>In addition to <filename>/etc/systemd/network</filename>, drop-in <literal>.d</literal>
+    directories can be placed in <filename>/usr/lib/systemd/network</filename> or
+    <filename>/run/systemd/network</filename> directories. Drop-in files in
+    <filename>/etc/</filename> take precedence over those in <filename>/run/</filename> which in turn
+    take precedence over those in <filename>/usr/lib/</filename>. Drop-in files under any of these
+    directories take precedence over the main netdev file wherever located. (Of course, since
+    <filename>/run/</filename> is temporary and <filename>/usr/lib/</filename> is for vendors, it is
+    unlikely drop-ins should be used in either of those places.)</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Supported netdev kinds</title>
+
+    <para>The following kinds of virtual network devices may be
+    configured in <filename>.netdev</filename> files:</para>
+
+    <table>
+      <title>Supported kinds of virtual network devices</title>
+
+      <tgroup cols='2'>
+        <colspec colname='kind' />
+        <colspec colname='explanation' />
+        <thead><row>
+          <entry>Kind</entry>
+          <entry>Description</entry>
+        </row></thead>
+        <tbody>
+          <row><entry><varname>bond</varname></entry>
+          <entry>A bond device is an aggregation of all its slave devices. See <ulink url="https://docs.kernel.org/networking/bonding.html">Linux Ethernet Bonding Driver HOWTO</ulink> for details.</entry></row>
+
+          <row><entry><varname>bridge</varname></entry>
+          <entry>A bridge device is a software switch, and each of its slave devices and the bridge itself are ports of the switch.</entry></row>
+
+          <row><entry><varname>dummy</varname></entry>
+          <entry>A dummy device drops all packets sent to it.</entry></row>
+
+          <row><entry><varname>gre</varname></entry>
+          <entry>A Level 3 GRE tunnel over IPv4. See <ulink url="https://tools.ietf.org/html/rfc2784">RFC 2784</ulink> for details. Name <literal>gre0</literal> should not be used, as the kernel creates a device with this name when the corresponding kernel module is loaded.</entry></row>
+
+          <row><entry><varname>gretap</varname></entry>
+          <entry>A Level 2 GRE tunnel over IPv4. Name <literal>gretap0</literal> should not be used, as the kernel creates a device with this name when the corresponding kernel module is loaded.</entry></row>
+
+          <row><entry><varname>erspan</varname></entry>
+          <entry>ERSPAN mirrors traffic on one or more source ports and delivers the mirrored traffic to one or more destination ports on another switch. The traffic is encapsulated in generic routing encapsulation (GRE) and is therefore routable across a layer 3 network between the source switch and the destination switch. Name <literal>erspan0</literal> should not be used, as the kernel creates a device with this name when the corresponding kernel module is loaded.</entry></row>
+
+          <row><entry><varname>ip6gre</varname></entry>
+          <entry>A Level 3 GRE tunnel over IPv6.</entry></row>
+
+          <row><entry><varname>ip6tnl</varname></entry>
+          <entry>An IPv4 or IPv6 tunnel over IPv6</entry></row>
+
+          <row><entry><varname>ip6gretap</varname></entry>
+          <entry>A Level 2 GRE tunnel over IPv6.</entry></row>
+
+          <row><entry><varname>ipip</varname></entry>
+          <entry>An IPv4 over IPv4 tunnel.</entry></row>
+
+          <row><entry><varname>ipvlan</varname></entry>
+          <entry>An IPVLAN device is a stacked device which receives packets from its underlying device based on IP address filtering.</entry></row>
+
+          <row><entry><varname>ipvtap</varname></entry>
+          <entry>An IPVTAP device is a stacked device which receives packets from its underlying device based on IP address filtering and can be accessed using the tap user space interface.</entry></row>
+
+          <row><entry><varname>macvlan</varname></entry>
+          <entry>A macvlan device is a stacked device which receives packets from its underlying device based on MAC address filtering.</entry></row>
+
+          <row><entry><varname>macvtap</varname></entry>
+          <entry>A macvtap device is a stacked device which receives packets from its underlying device based on MAC address filtering.</entry></row>
+
+          <row><entry><varname>sit</varname></entry>
+          <entry>An IPv6 over IPv4 tunnel.</entry></row>
+
+          <row><entry><varname>tap</varname></entry>
+          <entry>A persistent Level 2 tunnel between a network device and a device node.</entry></row>
+
+          <row><entry><varname>tun</varname></entry>
+          <entry>A persistent Level 3 tunnel between a network device and a device node.</entry></row>
+
+          <row><entry><varname>veth</varname></entry>
+          <entry>An Ethernet tunnel between a pair of network devices.</entry></row>
+
+          <row><entry><varname>vlan</varname></entry>
+          <entry>A VLAN is a stacked device which receives packets from its underlying device based on VLAN tagging. See <ulink url="http://www.ieee802.org/1/pages/802.1Q.html">IEEE 802.1Q</ulink> for details.</entry></row>
+
+          <row><entry><varname>vti</varname></entry>
+          <entry>An IPv4 over IPSec tunnel.</entry></row>
+
+          <row><entry><varname>vti6</varname></entry>
+          <entry>An IPv6 over IPSec tunnel.</entry></row>
+
+          <row><entry><varname>vxlan</varname></entry>
+          <entry>A virtual extensible LAN (vxlan), for connecting Cloud computing deployments.</entry></row>
+
+          <row><entry><varname>geneve</varname></entry>
+          <entry>A GEneric NEtwork Virtualization Encapsulation (GENEVE) netdev driver.</entry></row>
+
+          <row><entry><varname>l2tp</varname></entry>
+          <entry>A Layer 2 Tunneling Protocol (L2TP) is a tunneling protocol used to support virtual private networks (VPNs) or as part of the delivery of services by ISPs. It does not provide any encryption or confidentiality by itself</entry></row>
+
+          <row><entry><varname>macsec</varname></entry>
+          <entry>Media Access Control Security (MACsec) is an 802.1AE IEEE industry-standard security technology that provides secure communication for all traffic on Ethernet links. MACsec provides point-to-point security on Ethernet links between directly connected nodes and is capable of identifying and preventing most security threats.</entry></row>
+
+          <row><entry><varname>vrf</varname></entry>
+          <entry>A Virtual Routing and Forwarding (<ulink url="https://docs.kernel.org/networking/vrf.html">VRF</ulink>) interface to create separate routing and forwarding domains.</entry></row>
+
+          <row><entry><varname>vcan</varname></entry>
+          <entry>The virtual CAN driver (vcan). Similar to the network loopback devices, vcan offers a virtual local CAN interface.</entry></row>
+
+          <row><entry><varname>vxcan</varname></entry>
+          <entry>The virtual CAN tunnel driver (vxcan). Similar to the virtual ethernet driver veth, vxcan implements a local CAN traffic tunnel between two virtual CAN network devices. When creating a vxcan, two vxcan devices are created as pair. When one end receives the packet it appears on its pair and vice versa. The vxcan can be used for cross namespace communication.
+          </entry></row>
+
+          <row><entry><varname>wireguard</varname></entry>
+          <entry>WireGuard Secure Network Tunnel.</entry></row>
+
+          <row><entry><varname>nlmon</varname></entry>
+          <entry>A Netlink monitor device. Use an nlmon device when you want to monitor system Netlink messages.</entry></row>
+
+          <row><entry><varname>fou</varname></entry>
+          <entry>Foo-over-UDP tunneling.</entry></row>
+
+          <row><entry><varname>xfrm</varname></entry>
+          <entry>A virtual tunnel interface like vti/vti6 but with several advantages.</entry></row>
+
+          <row><entry><varname>ifb</varname></entry>
+          <entry>The Intermediate Functional Block (ifb) pseudo network interface acts as a QoS concentrator for multiple different sources of traffic.</entry></row>
+
+          <row><entry><varname>bareudp</varname></entry>
+          <entry>Bare UDP tunnels provide a generic L3 encapsulation support for tunnelling different L3 protocols like MPLS, IP etc. inside of a UDP tunnel.</entry></row>
+
+          <row><entry><varname>batadv</varname></entry>
+          <entry><ulink url="https://www.open-mesh.org/projects/open-mesh/wiki">B.A.T.M.A.N. Advanced</ulink> is a routing protocol for multi-hop mobile ad-hoc networks which operates on layer 2.</entry></row>
+
+          <row><entry><varname>ipoib</varname></entry>
+          <entry>An IP over Infiniband subinterface.</entry></row>
+
+          <row><entry><varname>wlan</varname></entry>
+          <entry>A virtual wireless network (WLAN) interface.</entry></row>
+        </tbody>
+      </tgroup>
+    </table>
+
+  </refsect1>
+
+  <refsect1>
+    <title>[Match] Section Options</title>
+
+    <para>A virtual network device is only created if the [Match] section matches the current
+    environment, or if the section is empty. The following keys are accepted:</para>
+
+    <variablelist class='network-directives'>
+      <xi:include href="systemd.link.xml" xpointer="host" />
+      <xi:include href="systemd.link.xml" xpointer="virtualization" />
+      <xi:include href="systemd.link.xml" xpointer="kernel-command-line" />
+      <xi:include href="systemd.link.xml" xpointer="kernel-version" />
+      <xi:include href="systemd.link.xml" xpointer="credential" />
+      <xi:include href="systemd.link.xml" xpointer="architecture" />
+      <xi:include href="systemd.link.xml" xpointer="firmware" />
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[NetDev] Section Options</title>
+
+    <para>The [NetDev] section accepts the
+    following keys:</para>
+
+    <variablelist class='network-directives'>
+      <varlistentry>
+        <term><varname>Description=</varname></term>
+        <listitem>
+          <para>A free-form description of the netdev.</para>
+
+        <xi:include href="version-info.xml" xpointer="v215"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>Name=</varname></term>
+        <listitem>
+          <para>The interface name used when creating the netdev.
+          This setting is compulsory.</para>
+
+          <xi:include href="version-info.xml" xpointer="v211"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>Kind=</varname></term>
+        <listitem>
+          <para>The netdev kind. This setting is compulsory. See the
+          <literal>Supported netdev kinds</literal> section for the
+          valid keys.</para>
+
+          <xi:include href="version-info.xml" xpointer="v211"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>MTUBytes=</varname></term>
+        <listitem>
+          <para>The maximum transmission unit in bytes to set for the device. The usual suffixes K, M, G
+          are supported and are understood to the base of 1024. For <literal>tun</literal> or
+          <literal>tap</literal> devices, <varname>MTUBytes=</varname> setting is not currently supported in
+          [NetDev] section. Please specify it in [Link] section of
+          corresponding
+          <citerefentry><refentrytitle>systemd.network</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+          files.</para>
+
+          <xi:include href="version-info.xml" xpointer="v215"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>MACAddress=</varname></term>
+        <listitem>
+          <para>Specifies the MAC address to use for the device, or takes the special value
+          <literal>none</literal>. When <literal>none</literal>, <command>systemd-networkd</command>
+          does not request the MAC address for the device, and the kernel will assign a random MAC
+          address. For <literal>tun</literal>, <literal>tap</literal>, or <literal>l2tp</literal>
+          devices, the <varname>MACAddress=</varname> setting in the [NetDev] section is not
+          supported and will be ignored. Please specify it in the [Link] section of the corresponding
+          <citerefentry><refentrytitle>systemd.network</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+          file. If this option is not set, <literal>vlan</literal> device inherits the MAC address of
+          the master interface. For other kind of netdevs, if this option is not set, then the MAC
+          address is generated based on the interface name and the
+          <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+          </para>
+          <para>Note, even if <literal>none</literal> is specified, <command>systemd-udevd</command>
+          will assign the persistent MAC address for the device, as <filename>99-default.link</filename>
+          has <varname>MACAddressPolicy=persistent</varname>. So, it is also necessary to create a
+          custom .link file for the device, if the MAC address assignment is not desired.</para>
+
+          <xi:include href="version-info.xml" xpointer="v215"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[Bridge] Section Options</title>
+
+    <para>The [Bridge] section only applies for
+    netdevs of kind <literal>bridge</literal>, and accepts the
+    following keys:</para>
+
+    <variablelist class='network-directives'>
+      <varlistentry>
+        <term><varname>HelloTimeSec=</varname></term>
+        <listitem>
+          <para>HelloTimeSec specifies the number of seconds between two hello packets
+          sent out by the root bridge and the designated bridges. Hello packets are
+          used to communicate information about the topology throughout the entire
+          bridged local area network.</para>
+
+          <xi:include href="version-info.xml" xpointer="v227"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>MaxAgeSec=</varname></term>
+        <listitem>
+          <para>MaxAgeSec specifies the number of seconds of maximum message age.
+          If the last seen (received) hello packet is more than this number of
+          seconds old, the bridge in question will start the takeover procedure
+          in attempt to become the Root Bridge itself.</para>
+
+          <xi:include href="version-info.xml" xpointer="v227"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>ForwardDelaySec=</varname></term>
+        <listitem>
+          <para>ForwardDelaySec specifies the number of seconds spent in each
+          of the Listening and Learning states before the Forwarding state is entered.</para>
+
+          <xi:include href="version-info.xml" xpointer="v227"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>AgeingTimeSec=</varname></term>
+        <listitem>
+          <para>This specifies the number of seconds a MAC Address will be kept in
+          the forwarding database after having a packet received from this MAC Address.</para>
+
+          <xi:include href="version-info.xml" xpointer="v232"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>Priority=</varname></term>
+        <listitem>
+          <para>The priority of the bridge. An integer between 0 and 65535. A lower value
+          means higher priority. The bridge having the lowest priority will be elected as root bridge.</para>
+
+          <xi:include href="version-info.xml" xpointer="v232"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>GroupForwardMask=</varname></term>
+        <listitem>
+          <para>A 16-bit bitmask represented as an integer which allows forwarding of link
+          local frames with 802.1D reserved addresses (01:80:C2:00:00:0X). A logical AND
+          is performed between the specified bitmask and the exponentiation of 2^X, the
+          lower nibble of the last octet of the MAC address. For example, a value of 8
+          would allow forwarding of frames addressed to 01:80:C2:00:00:03 (802.1X PAE).</para>
+
+          <xi:include href="version-info.xml" xpointer="v235"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>DefaultPVID=</varname></term>
+        <listitem>
+          <para>This specifies the default port VLAN ID of a newly attached bridge port.
+          Set this to an integer in the range 1…4094 or <literal>none</literal> to disable the PVID.</para>
+
+          <xi:include href="version-info.xml" xpointer="v232"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>MulticastQuerier=</varname></term>
+        <listitem>
+          <para>Takes a boolean. This setting controls the IFLA_BR_MCAST_QUERIER option in the kernel.
+          If enabled, the kernel will send general ICMP queries from a zero source address.
+          This feature should allow faster convergence on startup, but it causes some
+          multicast-aware switches to misbehave and disrupt forwarding of multicast packets.
+          When unset, the kernel's default will be used.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v230"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>MulticastSnooping=</varname></term>
+        <listitem>
+          <para>Takes a boolean. This setting controls the IFLA_BR_MCAST_SNOOPING option in the kernel.
+          If enabled, IGMP snooping monitors the Internet Group Management Protocol (IGMP) traffic
+          between hosts and multicast routers. When unset, the kernel's default will be used.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v230"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>VLANFiltering=</varname></term>
+        <listitem>
+          <para>Takes a boolean. This setting controls the IFLA_BR_VLAN_FILTERING option in the kernel.
+          If enabled, the bridge will be started in VLAN-filtering mode. When unset, the kernel's default will be used.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v231"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>VLANProtocol=</varname></term>
+        <listitem>
+          <para>Allows setting the protocol used for VLAN filtering. Takes
+          <option>802.1q</option> or,
+          <option>802.1ad</option>, and defaults to unset and kernel's default is used.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>STP=</varname></term>
+        <listitem>
+          <para>Takes a boolean. This enables the bridge's Spanning Tree Protocol (STP).
+          When unset, the kernel's default will be used.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v232"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>MulticastIGMPVersion=</varname></term>
+        <listitem>
+          <para>Allows changing bridge's multicast Internet Group Management Protocol (IGMP) version.
+          Takes an integer 2 or 3. When unset, the kernel's default will be used.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v243"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[VLAN] Section Options</title>
+
+    <para>The [VLAN] section only applies for
+    netdevs of kind <literal>vlan</literal>, and accepts the
+    following key:</para>
+
+    <variablelist class='network-directives'>
+      <varlistentry>
+        <term><varname>Id=</varname></term>
+        <listitem>
+          <para>The VLAN ID to use. An integer in the range 0…4094.
+          This setting is compulsory.</para>
+
+          <xi:include href="version-info.xml" xpointer="v211"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>Protocol=</varname></term>
+        <listitem>
+          <para>Allows setting the protocol used for the VLAN interface. Takes <literal>802.1q</literal> or,
+          <literal>802.1ad</literal>, and defaults to unset and kernel's default is used.</para>
+
+        <xi:include href="version-info.xml" xpointer="v248"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>GVRP=</varname></term>
+        <listitem>
+          <para>Takes a boolean. The Generic VLAN Registration Protocol (GVRP) is a protocol that
+          allows automatic learning of VLANs on a network.
+          When unset, the kernel's default will be used.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v234"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>MVRP=</varname></term>
+        <listitem>
+          <para>Takes a boolean. Multiple VLAN Registration Protocol (MVRP) formerly known as GARP VLAN
+          Registration Protocol (GVRP) is a standards-based Layer 2 network protocol,
+          for automatic configuration of VLAN information on switches. It was defined
+          in the 802.1ak amendment to 802.1Q-2005. When unset, the kernel's default will be used.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v234"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>LooseBinding=</varname></term>
+        <listitem>
+          <para>Takes a boolean. The VLAN loose binding mode, in which only the operational state is passed
+          from the parent to the associated VLANs, but the VLAN device state is not changed.
+          When unset, the kernel's default will be used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v234"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>ReorderHeader=</varname></term>
+        <listitem>
+          <para>Takes a boolean. When enabled, the VLAN reorder header is used and VLAN interfaces behave
+          like physical interfaces. When unset, the kernel's default will be used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v234"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>EgressQOSMaps=</varname></term>
+        <term><varname>IngressQOSMaps=</varname></term>
+        <listitem>
+          <para>Defines a mapping of Linux internal packet priority (<constant>SO_PRIORITY</constant>)
+          to VLAN header PCP field for outgoing and incoming frames, respectively. Takes a
+          whitespace-separated list of integer pairs, where each integer must be in the range
+          1…4294967294, in the format <literal>from</literal>-<literal>to</literal>, e.g.,
+          <literal>21-7 45-5</literal>. Note that <literal>from</literal> must be greater than or equal
+          to <literal>to</literal>. When unset, the kernel's default will be used.</para>
+
+        <xi:include href="version-info.xml" xpointer="v248"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[MACVLAN] Section Options</title>
+
+    <para>The [MACVLAN] section only applies for
+    netdevs of kind <literal>macvlan</literal>, and accepts the
+    following key:</para>
+
+    <variablelist class='network-directives'>
+      <varlistentry>
+        <term><varname>Mode=</varname></term>
+        <listitem>
+          <para>The MACVLAN mode to use. The supported options are
+          <literal>private</literal>,
+          <literal>vepa</literal>,
+          <literal>bridge</literal>,
+          <literal>passthru</literal>, and
+          <literal>source</literal>.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v211"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>SourceMACAddress=</varname></term>
+        <listitem>
+          <para>A whitespace-separated list of remote hardware addresses allowed on the MACVLAN. This
+          option only has an effect in source mode. Use full colon-, hyphen- or dot-delimited
+          hexadecimal. This option may appear more than once, in which case the lists are merged. If
+          the empty string is assigned to this option, the list of hardware addresses defined prior
+          to this is reset. Defaults to unset.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>BroadcastMulticastQueueLength=</varname></term>
+        <listitem>
+          <para>Specifies the length of the receive queue for broadcast/multicast packets. An unsigned
+          integer in the range 0…4294967294. Defaults to unset.</para>
+
+          <xi:include href="version-info.xml" xpointer="v248"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[MACVTAP] Section Options</title>
+
+    <para>The [MACVTAP] section applies for netdevs of kind <literal>macvtap</literal> and accepts the same
+    keys as [MACVLAN].</para>
+  </refsect1>
+
+  <refsect1>
+    <title>[IPVLAN] Section Options</title>
+
+    <para>The [IPVLAN] section only applies for
+    netdevs of kind <literal>ipvlan</literal>, and accepts the
+    following key:</para>
+
+    <variablelist class='network-directives'>
+      <varlistentry>
+        <term><varname>Mode=</varname></term>
+        <listitem>
+          <para>The IPVLAN mode to use. The supported options are
+          <literal>L2</literal>,<literal>L3</literal> and <literal>L3S</literal>.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v219"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>Flags=</varname></term>
+        <listitem>
+          <para>The IPVLAN flags to use. The supported options are
+          <literal>bridge</literal>,<literal>private</literal> and <literal>vepa</literal>.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v237"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[IPVTAP] Section Options</title>
+
+    <para>The [IPVTAP] section only applies for netdevs of kind <literal>ipvtap</literal> and accepts the
+    same keys as [IPVLAN].</para>
+  </refsect1>
+
+  <refsect1>
+    <title>[VXLAN] Section Options</title>
+
+    <para>The [VXLAN] section only applies for
+    netdevs of kind <literal>vxlan</literal>, and accepts the
+    following keys:</para>
+
+    <variablelist class='network-directives'>
+      <varlistentry>
+        <term><varname>VNI=</varname></term>
+        <listitem>
+          <para>The VXLAN Network Identifier (or VXLAN Segment ID). Takes a number in the range 1…16777215.</para>
+
+        <xi:include href="version-info.xml" xpointer="v243"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>Remote=</varname></term>
+        <listitem>
+          <para>Configures destination IP address.</para>
+
+        <xi:include href="version-info.xml" xpointer="v233"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>Local=</varname></term>
+        <listitem>
+          <para>Configures local IP address. It must be an address on the underlying interface of the
+          VXLAN interface, or one of the special values <literal>ipv4_link_local</literal>,
+          <literal>ipv6_link_local</literal>, <literal>dhcp4</literal>, <literal>dhcp6</literal>, and
+          <literal>slaac</literal>. If one of the special values is specified, an address which matches
+          the corresponding type on the underlying interface will be used. Defaults to unset.</para>
+
+          <xi:include href="version-info.xml" xpointer="v233"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>Group=</varname></term>
+        <listitem>
+          <para>Configures VXLAN multicast group IP address. All members of a VXLAN must use the same
+          multicast group address.</para>
+
+          <xi:include href="version-info.xml" xpointer="v243"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>TOS=</varname></term>
+        <listitem>
+          <para>The Type Of Service byte value for a vxlan interface.</para>
+
+        <xi:include href="version-info.xml" xpointer="v215"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>TTL=</varname></term>
+        <listitem>
+          <para>A fixed Time To Live N on Virtual eXtensible Local Area Network packets.
+          Takes <literal>inherit</literal> or a number in the range 0…255. 0 is a special
+          value meaning inherit the inner protocol's TTL value. <literal>inherit</literal>
+          means that it will inherit the outer protocol's TTL value.</para>
+
+          <xi:include href="version-info.xml" xpointer="v215"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>MacLearning=</varname></term>
+        <listitem>
+          <para>Takes a boolean. When true, enables dynamic MAC learning
+          to discover remote MAC addresses.</para>
+
+          <xi:include href="version-info.xml" xpointer="v215"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>FDBAgeingSec=</varname></term>
+        <listitem>
+          <para>The lifetime of Forwarding Database entry learnt by
+          the kernel, in seconds.</para>
+
+          <xi:include href="version-info.xml" xpointer="v218"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>MaximumFDBEntries=</varname></term>
+        <listitem>
+          <para>Configures maximum number of FDB entries.</para>
+
+        <xi:include href="version-info.xml" xpointer="v228"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>ReduceARPProxy=</varname></term>
+        <listitem>
+          <para>Takes a boolean. When true, bridge-connected VXLAN tunnel endpoint answers ARP requests from
+          the local bridge on behalf of remote
+          <ulink url="https://en.wikipedia.org/wiki/Distributed_Overlay_Virtual_Ethernet">
+            Distributed Overlay Virtual Ethernet (DOVE)</ulink>
+          clients. Defaults to false.</para>
+
+          <xi:include href="version-info.xml" xpointer="v233"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>L2MissNotification=</varname></term>
+        <listitem>
+          <para>Takes a boolean. When true, enables netlink LLADDR miss
+          notifications.</para>
+
+          <xi:include href="version-info.xml" xpointer="v218"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>L3MissNotification=</varname></term>
+        <listitem>
+          <para>Takes a boolean. When true, enables netlink IP address miss notifications.</para>
+
+        <xi:include href="version-info.xml" xpointer="v218"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>RouteShortCircuit=</varname></term>
+        <listitem>
+          <para>Takes a boolean. When true, route short circuiting is turned
+          on.</para>
+
+          <xi:include href="version-info.xml" xpointer="v218"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>UDPChecksum=</varname></term>
+        <listitem>
+          <para>Takes a boolean. When true, transmitting UDP checksums when doing VXLAN/IPv4 is turned on.</para>
+
+        <xi:include href="version-info.xml" xpointer="v220"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>UDP6ZeroChecksumTx=</varname></term>
+        <listitem>
+          <para>Takes a boolean. When true, sending zero checksums in VXLAN/IPv6 is turned on.</para>
+
+        <xi:include href="version-info.xml" xpointer="v220"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>UDP6ZeroChecksumRx=</varname></term>
+        <listitem>
+          <para>Takes a boolean. When true, receiving zero checksums in VXLAN/IPv6 is turned on.</para>
+
+        <xi:include href="version-info.xml" xpointer="v220"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>RemoteChecksumTx=</varname></term>
+        <listitem>
+          <para>Takes a boolean. When true, remote transmit checksum offload of VXLAN is turned on.</para>
+
+        <xi:include href="version-info.xml" xpointer="v232"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>RemoteChecksumRx=</varname></term>
+        <listitem>
+          <para>Takes a boolean. When true, remote receive checksum offload in VXLAN is turned on.</para>
+
+        <xi:include href="version-info.xml" xpointer="v232"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>GroupPolicyExtension=</varname></term>
+        <listitem>
+          <para>Takes a boolean. When true, it enables Group Policy VXLAN extension security label mechanism
+          across network peers based on VXLAN. For details about the Group Policy VXLAN, see the
+          <ulink url="https://tools.ietf.org/html/draft-smith-vxlan-group-policy">
+          VXLAN Group Policy </ulink> document. Defaults to false.</para>
+
+          <xi:include href="version-info.xml" xpointer="v224"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>GenericProtocolExtension=</varname></term>
+        <listitem>
+          <para>Takes a boolean. When true, Generic Protocol Extension extends the existing VXLAN protocol
+          to provide protocol typing, OAM, and versioning capabilities. For details about the VXLAN GPE
+          Header, see the <ulink url="https://tools.ietf.org/html/draft-ietf-nvo3-vxlan-gpe-07">
+          Generic Protocol Extension for VXLAN </ulink> document. If destination port is not specified and
+          Generic Protocol Extension is set then default port of 4790 is used. Defaults to false.</para>
+
+          <xi:include href="version-info.xml" xpointer="v243"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>DestinationPort=</varname></term>
+        <listitem>
+          <para>Configures the default destination UDP port. If the destination port is not specified then
+          Linux kernel default will be used. Set to 4789 to get the IANA assigned value.</para>
+
+          <xi:include href="version-info.xml" xpointer="v229"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>PortRange=</varname></term>
+        <listitem>
+          <para>Configures the source port range for the VXLAN. The kernel assigns the source UDP port based
+          on the flow to help the receiver to do load balancing. When this option is not set, the normal
+          range of local UDP ports is used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v229"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>FlowLabel=</varname></term>
+        <listitem>
+          <para>Specifies the flow label to use in outgoing packets.
+          The valid range is 0-1048575.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v234"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>IPDoNotFragment=</varname></term>
+        <listitem>
+          <para>Allows setting the IPv4 Do not Fragment (DF) bit in outgoing packets, or to inherit its
+          value from the IPv4 inner header. Takes a boolean value, or <literal>inherit</literal>. Set
+          to <literal>inherit</literal> if the encapsulated protocol is IPv6. When unset, the kernel's
+          default will be used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v243"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>Independent=</varname></term>
+        <listitem>
+          <para>Takes a boolean. When true, the vxlan interface is created without any underlying network
+          interface. Defaults to false, which means that a .network file that requests this VXLAN interface
+          using <varname>VXLAN=</varname> is required for the VXLAN to be created.</para>
+
+          <xi:include href="version-info.xml" xpointer="v247"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[GENEVE] Section Options</title>
+
+    <para>The [GENEVE] section only applies for
+    netdevs of kind <literal>geneve</literal>, and accepts the
+    following keys:</para>
+
+    <variablelist class='network-directives'>
+      <varlistentry>
+        <term><varname>Id=</varname></term>
+        <listitem>
+          <para>Specifies the Virtual Network Identifier (VNI) to use, a number between 0 and 16777215. This
+          field is mandatory.</para>
+
+          <xi:include href="version-info.xml" xpointer="v234"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>Remote=</varname></term>
+        <listitem>
+          <para>Specifies the unicast destination IP address to use in outgoing packets.</para>
+
+        <xi:include href="version-info.xml" xpointer="v234"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>TOS=</varname></term>
+        <listitem>
+          <para>Specifies the TOS value to use in outgoing packets. Takes a number between 1 and 255.</para>
+
+        <xi:include href="version-info.xml" xpointer="v234"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>TTL=</varname></term>
+        <listitem>
+          <para>Accepts the same values as in the [VXLAN] section, except that when unset
+          or set to 0, the kernel's default will be used, meaning that packet TTL will be set from
+          <filename>/proc/sys/net/ipv4/ip_default_ttl</filename>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v234"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>UDPChecksum=</varname></term>
+        <listitem>
+          <para>Takes a boolean. When true, specifies that UDP checksum is calculated for transmitted packets
+          over IPv4.</para>
+
+          <xi:include href="version-info.xml" xpointer="v234"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>UDP6ZeroChecksumTx=</varname></term>
+        <listitem>
+          <para>Takes a boolean. When true, skip UDP checksum calculation for transmitted packets over IPv6.</para>
+
+        <xi:include href="version-info.xml" xpointer="v234"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>UDP6ZeroChecksumRx=</varname></term>
+        <listitem>
+          <para>Takes a boolean. When true, allows incoming UDP packets over IPv6 with zero checksum field.</para>
+
+        <xi:include href="version-info.xml" xpointer="v234"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>DestinationPort=</varname></term>
+        <listitem>
+          <para>Specifies destination port. Defaults to 6081. If not set or assigned the empty string, the default
+          port of 6081 is used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v234"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>FlowLabel=</varname></term>
+        <listitem>
+          <para>Specifies the flow label to use in outgoing packets.</para>
+
+        <xi:include href="version-info.xml" xpointer="v234"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>IPDoNotFragment=</varname></term>
+        <listitem>
+          <para>Accepts the same key as in [VXLAN] section.</para>
+
+        <xi:include href="version-info.xml" xpointer="v243"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>InheritInnerProtocol=</varname></term>
+        <listitem>
+          <para>Takes a boolean. When true, inner Layer 3 protocol is set as Protocol Type in the GENEVE
+          header instead of Ethernet. Defaults to false.</para>
+
+          <xi:include href="version-info.xml" xpointer="v254"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[BareUDP] Section Options</title>
+
+    <para>The [BareUDP] section only applies for
+    netdevs of kind <literal>bareudp</literal>, and accepts the
+    following keys:</para>
+
+    <variablelist class='network-directives'>
+      <varlistentry>
+        <term><varname>DestinationPort=</varname></term>
+        <listitem>
+          <para>Specifies the destination UDP port (in range 1…65535). This is mandatory.</para>
+
+        <xi:include href="version-info.xml" xpointer="v247"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>EtherType=</varname></term>
+        <listitem>
+          <para>Specifies the L3 protocol. Takes one of <literal>ipv4</literal>, <literal>ipv6</literal>, <literal>mpls-uc</literal>
+          or <literal>mpls-mc</literal>. This is mandatory.</para>
+
+        <xi:include href="version-info.xml" xpointer="v247"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[L2TP] Section Options</title>
+
+    <para>The [L2TP] section only applies for
+    netdevs of kind <literal>l2tp</literal>, and accepts the
+    following keys:</para>
+
+    <variablelist class='network-directives'>
+      <varlistentry>
+        <term><varname>TunnelId=</varname></term>
+        <listitem>
+          <para>Specifies the tunnel identifier. Takes an number in the range 1…4294967295. The value used
+          must match the <literal>PeerTunnelId=</literal> value being used at the peer. This setting is
+          compulsory.</para>
+
+          <xi:include href="version-info.xml" xpointer="v242"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>PeerTunnelId=</varname></term>
+        <listitem>
+          <para>Specifies the peer tunnel id. Takes a number in the range 1…4294967295. The value used must
+          match the <literal>TunnelId=</literal> value being used at the peer. This setting is compulsory.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v242"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>Remote=</varname></term>
+        <listitem>
+          <para>Specifies the IP address of the remote peer. This setting is compulsory.</para>
+
+        <xi:include href="version-info.xml" xpointer="v242"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>Local=</varname></term>
+        <listitem>
+          <para>Specifies the IP address of a local interface. Takes an IP address, or the special
+          values <literal>auto</literal>, <literal>static</literal>, or <literal>dynamic</literal>.
+          Optionally a name of a local interface can be specified after <literal>@</literal>, e.g.
+          <literal>192.168.0.1@eth0</literal> or <literal>auto@eth0</literal>. When an address is
+          specified, then a local or specified interface must have the address, and the remote address
+          must be accessible through the local address. If <literal>auto</literal>, then one of the
+          addresses on a local or specified interface which is accessible to the remote address will be
+          used. Similarly, if <literal>static</literal> or <literal>dynamic</literal> is set, then one
+          of the static or dynamic addresses will be used. Defaults to <literal>auto</literal>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v242"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>EncapsulationType=</varname></term>
+        <listitem>
+          <para>Specifies the encapsulation type of the tunnel. Takes one of <literal>udp</literal> or
+          <literal>ip</literal>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v242"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>UDPSourcePort=</varname></term>
+        <listitem>
+          <para>Specifies the UDP source port to be used for the tunnel. When UDP encapsulation is selected
+          it's mandatory. Ignored when IP encapsulation is selected.</para>
+
+          <xi:include href="version-info.xml" xpointer="v242"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>UDPDestinationPort=</varname></term>
+        <listitem>
+          <para>Specifies destination port. When UDP encapsulation is selected it's mandatory. Ignored when IP
+          encapsulation is selected.</para>
+
+          <xi:include href="version-info.xml" xpointer="v245"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>UDPChecksum=</varname></term>
+        <listitem>
+          <para>Takes a boolean. When true, specifies that UDP checksum is calculated for transmitted packets
+          over IPv4.</para>
+
+          <xi:include href="version-info.xml" xpointer="v242"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>UDP6ZeroChecksumTx=</varname></term>
+        <listitem>
+          <para>Takes a boolean. When true, skip UDP checksum calculation for transmitted packets over IPv6.</para>
+
+        <xi:include href="version-info.xml" xpointer="v242"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>UDP6ZeroChecksumRx=</varname></term>
+        <listitem>
+          <para>Takes a boolean. When true, allows incoming UDP packets over IPv6 with zero checksum field.</para>
+
+        <xi:include href="version-info.xml" xpointer="v242"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[L2TPSession] Section Options</title>
+
+    <para>The [L2TPSession] section only applies for
+    netdevs of kind <literal>l2tp</literal>, and accepts the
+    following keys:</para>
+    <variablelist class='network-directives'>
+      <varlistentry>
+        <term><varname>Name=</varname></term>
+        <listitem>
+          <para>Specifies the name of the session. This setting is compulsory.</para>
+
+        <xi:include href="version-info.xml" xpointer="v242"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>SessionId=</varname></term>
+        <listitem>
+          <para>Specifies the session identifier. Takes an number in the range 1…4294967295. The value used
+          must match the <literal>SessionId=</literal> value being used at the peer. This setting is
+          compulsory.</para>
+
+          <xi:include href="version-info.xml" xpointer="v242"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>PeerSessionId=</varname></term>
+        <listitem>
+          <para>Specifies the peer session identifier. Takes an number in the range 1…4294967295.
+          The value used must match the <literal>PeerSessionId=</literal> value being used at the peer.
+          This setting is compulsory.</para>
+
+          <xi:include href="version-info.xml" xpointer="v242"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>Layer2SpecificHeader=</varname></term>
+        <listitem>
+          <para>Specifies layer2specific header type of the session. One of <literal>none</literal> or <literal>default</literal>. Defaults to <literal>default</literal>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v242"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[MACsec] Section Options</title>
+
+    <para>The [MACsec] section only applies for network devices of kind
+    <literal>macsec</literal>, and accepts the following keys:</para>
+
+    <variablelist class='network-directives'>
+      <varlistentry>
+        <term><varname>Port=</varname></term>
+        <listitem>
+          <para>Specifies the port to be used for the MACsec transmit channel. The port is used to make
+          secure channel identifier (SCI). Takes a value between 1 and 65535. Defaults to unset.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v243"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>Encrypt=</varname></term>
+        <listitem>
+          <para>Takes a boolean. When true, enable encryption. Defaults to unset.</para>
+
+        <xi:include href="version-info.xml" xpointer="v243"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[MACsecReceiveChannel] Section Options</title>
+    <para>The [MACsecReceiveChannel] section only applies for network devices of
+    kind <literal>macsec</literal>, and accepts the following keys:</para>
+
+    <variablelist class='network-directives'>
+      <varlistentry>
+        <term><varname>Port=</varname></term>
+        <listitem>
+          <para>Specifies the port to be used for the MACsec receive channel. The port is used to make
+          secure channel identifier (SCI). Takes a value between 1 and 65535. This option is
+          compulsory, and is not set by default.</para>
+
+          <xi:include href="version-info.xml" xpointer="v243"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>MACAddress=</varname></term>
+        <listitem>
+          <para>Specifies the MAC address to be used for the MACsec receive channel. The MAC address
+          used to make secure channel identifier (SCI). This setting is compulsory, and is not set by
+          default.</para>
+
+          <xi:include href="version-info.xml" xpointer="v243"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[MACsecTransmitAssociation] Section Options</title>
+
+    <para>The [MACsecTransmitAssociation] section only applies for network devices
+    of kind <literal>macsec</literal>, and accepts the following keys:</para>
+
+    <variablelist class='network-directives'>
+      <varlistentry>
+        <term><varname>PacketNumber=</varname></term>
+        <listitem>
+          <para>Specifies the packet number to be used for replay protection and the construction of
+          the initialization vector (along with the secure channel identifier [SCI]). Takes a value
+          between 1-4,294,967,295. Defaults to unset.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v243"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>KeyId=</varname></term>
+        <listitem>
+          <para>Specifies the identification for the key. Takes a number between 0-255. This option
+          is compulsory, and is not set by default.</para>
+
+          <xi:include href="version-info.xml" xpointer="v243"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>Key=</varname></term>
+        <listitem>
+          <para>Specifies the encryption key used in the transmission channel. The same key must be
+          configured on the peer’s matching receive channel. This setting is compulsory, and is not set
+          by default. Takes a 128-bit key encoded in a hexadecimal string, for example
+          <literal>dffafc8d7b9a43d5b9a3dfbbf6a30c16</literal>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v243"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>KeyFile=</varname></term>
+        <listitem>
+          <para>Takes an absolute path to a file which contains a 128-bit key encoded in a hexadecimal string,
+          which will be used in the transmission channel. When this option is specified,
+          <varname>Key=</varname> is ignored. Note that the file must be readable by the user
+          <literal>systemd-network</literal>, so it should be, e.g., owned by
+          <literal>root:systemd-network</literal> with a <literal>0640</literal> file mode. If the path
+          refers to an <constant>AF_UNIX</constant> stream socket in the file system a connection is made to
+          it and the key read from it.</para>
+
+          <xi:include href="version-info.xml" xpointer="v243"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>Activate=</varname></term>
+        <listitem>
+          <para>Takes a boolean. If enabled, then the security association is activated. Defaults to
+          unset.</para>
+
+          <xi:include href="version-info.xml" xpointer="v243"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>UseForEncoding=</varname></term>
+        <listitem>
+          <para>Takes a boolean. If enabled, then the security association is used for encoding. Only
+          one [MACsecTransmitAssociation] section can enable this option. When enabled,
+          <varname>Activate=yes</varname> is implied. Defaults to unset.</para>
+
+          <xi:include href="version-info.xml" xpointer="v243"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[MACsecReceiveAssociation] Section Options</title>
+
+    <para>The [MACsecReceiveAssociation] section only applies for
+    network devices of kind <literal>macsec</literal>, and accepts the
+    following keys:</para>
+
+    <variablelist class='network-directives'>
+      <varlistentry>
+        <term><varname>Port=</varname></term>
+        <listitem>
+          <para>Accepts the same key as in [MACsecReceiveChannel] section.</para>
+
+        <xi:include href="version-info.xml" xpointer="v243"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>MACAddress=</varname></term>
+        <listitem>
+          <para>Accepts the same key as in [MACsecReceiveChannel] section.</para>
+
+        <xi:include href="version-info.xml" xpointer="v243"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>PacketNumber=</varname></term>
+        <listitem>
+          <para>Accepts the same key as in [MACsecTransmitAssociation] section.</para>
+
+        <xi:include href="version-info.xml" xpointer="v243"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>KeyId=</varname></term>
+        <listitem>
+          <para>Accepts the same key as in [MACsecTransmitAssociation] section.</para>
+
+        <xi:include href="version-info.xml" xpointer="v243"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>Key=</varname></term>
+        <listitem>
+          <para>Accepts the same key as in [MACsecTransmitAssociation] section.</para>
+
+        <xi:include href="version-info.xml" xpointer="v243"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>KeyFile=</varname></term>
+        <listitem>
+          <para>Accepts the same key as in [MACsecTransmitAssociation] section.</para>
+
+        <xi:include href="version-info.xml" xpointer="v243"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>Activate=</varname></term>
+        <listitem>
+          <para>Accepts the same key as in [MACsecTransmitAssociation] section.</para>
+
+        <xi:include href="version-info.xml" xpointer="v243"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[Tunnel] Section Options</title>
+
+    <para>The [Tunnel] section only applies for
+    netdevs of kind
+    <literal>ipip</literal>,
+    <literal>sit</literal>,
+    <literal>gre</literal>,
+    <literal>gretap</literal>,
+    <literal>ip6gre</literal>,
+    <literal>ip6gretap</literal>,
+    <literal>vti</literal>,
+    <literal>vti6</literal>,
+    <literal>ip6tnl</literal>, and
+    <literal>erspan</literal> and accepts
+    the following keys:</para>
+
+    <variablelist class='network-directives'>
+      <varlistentry>
+        <term><varname>External=</varname></term>
+        <listitem>
+          <para>Takes a boolean value. When true, then the tunnel is externally controlled, which is
+          also known as collect metadata mode, and most settings below like <varname>Local=</varname>
+          or <varname>Remote=</varname> are ignored. This implies <varname>Independent=</varname>.
+          Defaults to false.</para>
+
+          <xi:include href="version-info.xml" xpointer="v251"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>Local=</varname></term>
+        <listitem>
+          <para>A static local address for tunneled packets. It must be an address on another interface
+          of this host, or one of the special values <literal>any</literal>,
+          <literal>ipv4_link_local</literal>, <literal>ipv6_link_local</literal>,
+          <literal>dhcp4</literal>, <literal>dhcp6</literal>, and <literal>slaac</literal>. If one
+          of the special values except for <literal>any</literal> is specified, an address which
+          matches the corresponding type on the underlying interface will be used. Defaults to
+          <literal>any</literal>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v215"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>Remote=</varname></term>
+        <listitem>
+          <para>The remote endpoint of the tunnel. Takes an IP address or the special value
+          <literal>any</literal>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v215"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>TOS=</varname></term>
+        <listitem>
+          <para>The Type Of Service byte value for a tunnel interface.
+          For details about the TOS, see the
+          <ulink url="http://tools.ietf.org/html/rfc1349"> Type of
+          Service in the Internet Protocol Suite </ulink> document.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v215"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>TTL=</varname></term>
+        <listitem>
+          <para>A fixed Time To Live N on tunneled packets. N is a
+          number in the range 1…255. 0 is a special value meaning that
+          packets inherit the TTL value. The default value for IPv4
+          tunnels is 0 (inherit). The default value for IPv6 tunnels is
+          64.</para>
+
+          <xi:include href="version-info.xml" xpointer="v215"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>DiscoverPathMTU=</varname></term>
+        <listitem>
+          <para>Takes a boolean. When true, enables Path MTU Discovery on
+          the tunnel.
+          When <varname>IgnoreDontFragment=</varname> is enabled,
+          defaults to false. Otherwise, defaults to true.</para>
+
+          <xi:include href="version-info.xml" xpointer="v215"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>IgnoreDontFragment=</varname></term>
+        <listitem>
+          <para>Takes a boolean. When true, enables IPv4 Don't Fragment (DF) suppression on
+          the tunnel. Defaults to false.
+          Note that if <varname>IgnoreDontFragment=</varname> is set to true,
+          <varname>DiscoverPathMTU=</varname> cannot be set to true.
+          Only applicable to GRE, GRETAP, and ERSPAN tunnels.</para>
+
+          <xi:include href="version-info.xml" xpointer="v254"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>IPv6FlowLabel=</varname></term>
+        <listitem>
+          <para>Configures the 20-bit flow label (see <ulink url="https://tools.ietf.org/html/rfc6437">
+          RFC 6437</ulink>) field in the IPv6 header (see <ulink url="https://tools.ietf.org/html/rfc2460">
+          RFC 2460</ulink>), which is used by a node to label packets of a flow.
+          It is only used for IPv6 tunnels.
+          A flow label of zero is used to indicate packets that have
+          not been labeled.
+          It can be configured to a value in the range 0…0xFFFFF, or be
+          set to <literal>inherit</literal>, in which case the original flowlabel is used.</para>
+
+        <xi:include href="version-info.xml" xpointer="v223"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>CopyDSCP=</varname></term>
+        <listitem>
+          <para>Takes a boolean. When true, the Differentiated Service Code
+          Point (DSCP) field will be copied to the inner header from
+          outer header during the decapsulation of an IPv6 tunnel
+          packet. DSCP is a field in an IP packet that enables different
+          levels of service to be assigned to network traffic.
+          Defaults to <literal>no</literal>.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v223"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>EncapsulationLimit=</varname></term>
+        <listitem>
+          <para>The Tunnel Encapsulation Limit option specifies how many additional
+          levels of encapsulation are permitted to be prepended to the packet.
+          For example, a Tunnel Encapsulation Limit option containing a limit
+          value of zero means that a packet carrying that option may not enter
+          another tunnel before exiting the current tunnel.
+          (see <ulink url="https://tools.ietf.org/html/rfc2473#section-4.1.1"> RFC 2473</ulink>).
+          The valid range is 0…255 and <literal>none</literal>. Defaults to 4.
+        </para>
+
+          <xi:include href="version-info.xml" xpointer="v226"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>Key=</varname></term>
+        <listitem>
+          <para>The <varname>Key=</varname> parameter specifies the same key to use in
+          both directions (<varname>InputKey=</varname> and <varname>OutputKey=</varname>).
+          The <varname>Key=</varname> is either a number or an IPv4 address-like dotted quad.
+          It is used as mark-configured SAD/SPD entry as part of the lookup key (both in data
+          and control path) in IP XFRM (framework used to implement IPsec protocol).
+          See <ulink url="https://man7.org/linux/man-pages/man8/ip-xfrm.8.html">
+          ip-xfrm — transform configuration</ulink> for details. It is only used for VTI/VTI6,
+          GRE, GRETAP, and ERSPAN tunnels.</para>
+
+        <xi:include href="version-info.xml" xpointer="v231"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>InputKey=</varname></term>
+        <listitem>
+          <para>The <varname>InputKey=</varname> parameter specifies the key to use for input.
+          The format is same as <varname>Key=</varname>. It is only used for VTI/VTI6, GRE, GRETAP,
+          and ERSPAN tunnels.</para>
+
+        <xi:include href="version-info.xml" xpointer="v231"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>OutputKey=</varname></term>
+        <listitem>
+          <para>The <varname>OutputKey=</varname> parameter specifies the key to use for output.
+          The format is same as <varname>Key=</varname>. It is only used for VTI/VTI6, GRE, GRETAP,
+          and ERSPAN tunnels.</para>
+
+        <xi:include href="version-info.xml" xpointer="v231"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>Mode=</varname></term>
+        <listitem>
+          <para>An <literal>ip6tnl</literal> tunnel can be in one of three
+          modes
+          <literal>ip6ip6</literal> for IPv6 over IPv6,
+          <literal>ipip6</literal> for IPv4 over IPv6 or
+          <literal>any</literal> for either.
+          </para>
+
+        <xi:include href="version-info.xml" xpointer="v219"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>Independent=</varname></term>
+        <listitem>
+          <para>Takes a boolean. When false (the default), the tunnel is always created over some network
+          device, and a .network file that requests this tunnel using <varname>Tunnel=</varname> is required
+          for the tunnel to be created. When true, the tunnel is created independently of any network as
+          "tunnel@NONE".</para>
+
+          <xi:include href="version-info.xml" xpointer="v235"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>AssignToLoopback=</varname></term>
+        <listitem>
+          <para>Takes a boolean. If set to <literal>yes</literal>, the loopback interface <literal>lo</literal>
+          is used as the underlying device of the tunnel interface. Defaults to <literal>no</literal>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v243"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>AllowLocalRemote=</varname></term>
+        <listitem>
+          <para>Takes a boolean. When true allows tunnel traffic on <varname>ip6tnl</varname> devices where the remote endpoint is a local host address.
+          When unset, the kernel's default will be used.
+          </para>
+
+        <xi:include href="version-info.xml" xpointer="v237"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>FooOverUDP=</varname></term>
+        <listitem>
+          <para>Takes a boolean. Specifies whether <varname>FooOverUDP=</varname> tunnel is to be configured.
+          Defaults to false. This takes effects only for IPIP, SIT, GRE, and GRETAP tunnels.
+          For more detail information see
+          <ulink url="https://lwn.net/Articles/614348">Foo over UDP</ulink></para>
+
+        <xi:include href="version-info.xml" xpointer="v240"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>FOUDestinationPort=</varname></term>
+        <listitem>
+          <para>This setting specifies the UDP destination port for encapsulation.
+          This field is mandatory when <varname>FooOverUDP=yes</varname>, and is not set by default.</para>
+
+          <xi:include href="version-info.xml" xpointer="v240"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>FOUSourcePort=</varname></term>
+        <listitem>
+          <para>This setting specifies the UDP source port for encapsulation. Defaults to <constant>0</constant>
+          — that is, the source port for packets is left to the network stack to decide.</para>
+
+        <xi:include href="version-info.xml" xpointer="v240"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>Encapsulation=</varname></term>
+        <listitem>
+          <para>Accepts the same key as in the [FooOverUDP] section.</para>
+
+        <xi:include href="version-info.xml" xpointer="v240"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>IPv6RapidDeploymentPrefix=</varname></term>
+        <listitem>
+          <para>Reconfigure the tunnel for <ulink url="https://tools.ietf.org/html/rfc5569">IPv6 Rapid
+          Deployment</ulink>, also known as 6rd. The value is an ISP-specific IPv6 prefix with a non-zero length. Only
+          applicable to SIT tunnels.</para>
+
+        <xi:include href="version-info.xml" xpointer="v240"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>ISATAP=</varname></term>
+        <listitem>
+          <para>Takes a boolean. If set, configures the tunnel as Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) tunnel.
+          Only applicable to SIT tunnels. When unset, the kernel's default will be used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v240"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>SerializeTunneledPackets=</varname></term>
+        <listitem>
+          <para>Takes a boolean. If set to yes, then packets are serialized. Only applies for GRE,
+          GRETAP, and ERSPAN tunnels. When unset, the kernel's default will be used.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v240"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>ERSPANVersion=</varname></term>
+        <listitem>
+          <para>Specifies the ERSPAN version number. Takes 0 for version 0 (a.k.a. type I), 1 for version 1
+          (a.k.a. type II), or 2 for version 2 (a.k.a. type III). Defaults to 1.</para>
+
+          <xi:include href="version-info.xml" xpointer="v252"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>ERSPANIndex=</varname></term>
+        <listitem>
+          <para>Specifies the ERSPAN v1 index field for the interface. Takes an integer in the range
+          0…1048575, which is associated with the ERSPAN traffic's source port and direction. Only used when
+          <varname>ERSPANVersion=1</varname>. Defaults to 0.</para>
+
+          <xi:include href="version-info.xml" xpointer="v240"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>ERSPANDirection=</varname></term>
+        <listitem>
+          <para>Specifies the ERSPAN v2 mirrored traffic's direction. Takes <literal>ingress</literal> or
+          <literal>egress</literal>. Only used when <varname>ERSPANVersion=2</varname>. Defaults to
+          <literal>ingress</literal>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v252"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>ERSPANHardwareId=</varname></term>
+        <listitem>
+          <para>Specifies an unique identifier of the ERSPAN v2 engine. Takes an integer in the range 0…63.
+          Only used when <varname>ERSPANVersion=2</varname>. Defaults to 0.</para>
+
+          <xi:include href="version-info.xml" xpointer="v252"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[FooOverUDP] Section Options</title>
+
+    <para>The [FooOverUDP] section only applies for
+    netdevs of kind <literal>fou</literal> and accepts the
+    following keys:</para>
+
+    <variablelist class='network-directives'>
+      <varlistentry>
+        <term><varname>Encapsulation=</varname></term>
+        <listitem>
+          <para>Specifies the encapsulation mechanism used to store networking packets of various protocols
+          inside the UDP packets. Supports the following values:
+
+          <literal>FooOverUDP</literal> provides the simplest no-frills model of UDP encapsulation, it simply
+          encapsulates packets directly in the UDP payload. <literal>GenericUDPEncapsulation</literal> is a
+          generic and extensible encapsulation, it allows encapsulation of packets for any IP protocol and
+          optional data as part of the encapsulation. For more detailed information see <ulink
+          url="https://lwn.net/Articles/615044">Generic UDP Encapsulation</ulink>. Defaults to
+          <literal>FooOverUDP</literal>.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v240"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>Port=</varname></term>
+        <listitem>
+          <para>Specifies the port number where the encapsulated packets will arrive. Those packets will be
+          removed and manually fed back into the network stack with the encapsulation removed to be sent to
+          the real destination. This option is mandatory.</para>
+
+          <xi:include href="version-info.xml" xpointer="v240"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>PeerPort=</varname></term>
+        <listitem>
+          <para>Specifies the peer port number. Defaults to unset. Note that when peer port is set
+          <literal>Peer=</literal> address is mandatory.</para>
+
+          <xi:include href="version-info.xml" xpointer="v243"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>Protocol=</varname></term>
+        <listitem>
+          <para>The <varname>Protocol=</varname> specifies the protocol number of the packets arriving
+          at the UDP port. When <varname>Encapsulation=FooOverUDP</varname>, this field is mandatory
+          and is not set by default. Takes an IP protocol name such as <literal>gre</literal> or
+          <literal>ipip</literal>, or an integer within the range 1…255. When
+          <varname>Encapsulation=GenericUDPEncapsulation</varname>, this must not be specified.</para>
+
+        <xi:include href="version-info.xml" xpointer="v240"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>Peer=</varname></term>
+        <listitem>
+          <para>Configures peer IP address. Note that when peer address is set <literal>PeerPort=</literal>
+          is mandatory.</para>
+
+        <xi:include href="version-info.xml" xpointer="v243"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>Local=</varname></term>
+        <listitem>
+          <para>Configures local IP address.</para>
+
+        <xi:include href="version-info.xml" xpointer="v243"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[Peer] Section Options</title>
+
+    <para>The [Peer] section only applies for
+    netdevs of kind <literal>veth</literal> and accepts the
+    following keys:</para>
+
+    <variablelist class='network-directives'>
+      <varlistentry>
+        <term><varname>Name=</varname></term>
+        <listitem>
+          <para>The interface name used when creating the netdev.
+          This setting is compulsory.</para>
+
+          <xi:include href="version-info.xml" xpointer="v215"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>MACAddress=</varname></term>
+        <listitem>
+          <para>The peer MACAddress, if not set, it is generated in
+          the same way as the MAC address of the main
+          interface.</para>
+
+          <xi:include href="version-info.xml" xpointer="v215"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[VXCAN] Section Options</title>
+
+    <para>The [VXCAN] section only applies for
+    netdevs of kind <literal>vxcan</literal> and accepts the
+    following key:</para>
+
+    <variablelist class='network-directives'>
+      <varlistentry>
+        <term><varname>Peer=</varname></term>
+        <listitem>
+          <para>The peer interface name used when creating the netdev.
+          This setting is compulsory.</para>
+
+          <xi:include href="version-info.xml" xpointer="v236"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[Tun] Section Options</title>
+
+    <para>The [Tun] section only applies for
+    netdevs of kind <literal>tun</literal>, and accepts the following
+    keys:</para>
+
+    <variablelist class='network-directives'>
+      <varlistentry>
+        <term><varname>MultiQueue=</varname></term>
+        <listitem><para>Takes a boolean. Configures whether
+        to use multiple file descriptors (queues) to parallelize
+        packets sending and receiving. Defaults to
+        <literal>no</literal>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v215"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>PacketInfo=</varname></term>
+        <listitem><para>Takes a boolean. Configures whether
+        packets should be prepended with four extra bytes (two flag
+        bytes and two protocol bytes). If disabled, it indicates that
+        the packets will be pure IP packets. Defaults to
+        <literal>no</literal>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v215"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>VNetHeader=</varname></term>
+        <listitem><para>Takes a boolean. Configures
+        IFF_VNET_HDR flag for a tun or tap device. It allows sending
+        and receiving larger Generic Segmentation Offload (GSO)
+        packets. This may increase throughput significantly.
+        Defaults to
+        <literal>no</literal>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v223"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>User=</varname></term>
+        <listitem><para>User to grant access to the
+        <filename>/dev/net/tun</filename> device.</para>
+
+        <xi:include href="version-info.xml" xpointer="v215"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>Group=</varname></term>
+        <listitem><para>Group to grant access to the
+        <filename>/dev/net/tun</filename> device.</para>
+
+        <xi:include href="version-info.xml" xpointer="v215"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>KeepCarrier=</varname></term>
+        <listitem>
+          <para>Takes a boolean. If enabled, to make the interface maintain its carrier status, the file
+          descriptor of the interface is kept open. This may be useful to keep the interface in running
+          state, for example while the backing process is temporarily shutdown. Defaults to
+          <literal>no</literal>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v252"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[Tap] Section Options</title>
+
+    <para>The [Tap] section only applies for
+    netdevs of kind <literal>tap</literal>, and accepts the same keys
+    as the [Tun] section.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>[WireGuard] Section Options</title>
+
+    <para>The [WireGuard] section accepts the following
+    keys:</para>
+
+    <variablelist class='network-directives'>
+      <varlistentry>
+        <term><varname>PrivateKey=</varname></term>
+        <listitem>
+          <para>The Base64 encoded private key for the interface. It can be
+          generated using the <command>wg genkey</command> command
+          (see <citerefentry project="wireguard"><refentrytitle>wg</refentrytitle><manvolnum>8</manvolnum></citerefentry>).
+          This option or <varname>PrivateKeyFile=</varname> is mandatory to use WireGuard.
+          Note that because this information is secret, you may want to set
+          the permissions of the .netdev file to be owned by <literal>root:systemd-network</literal>
+          with a <literal>0640</literal> file mode.</para>
+
+          <xi:include href="version-info.xml" xpointer="v237"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>PrivateKeyFile=</varname></term>
+        <listitem>
+          <para>Takes an absolute path to a file which contains the Base64 encoded private key for the
+          interface.  When this option is specified, then <varname>PrivateKey=</varname> is ignored.  Note
+          that the file must be readable by the user <literal>systemd-network</literal>, so it should be,
+          e.g., owned by <literal>root:systemd-network</literal> with a <literal>0640</literal> file mode. If
+          the path refers to an <constant>AF_UNIX</constant> stream socket in the file system a connection is
+          made to it and the key read from it.</para>
+
+          <xi:include href="version-info.xml" xpointer="v242"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>ListenPort=</varname></term>
+        <listitem>
+          <para>Sets UDP port for listening. Takes either value between 1 and 65535
+          or <literal>auto</literal>. If <literal>auto</literal> is specified,
+          the port is automatically generated based on interface name.
+          Defaults to <literal>auto</literal>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v237"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>FirewallMark=</varname></term>
+        <listitem>
+          <para>Sets a firewall mark on outgoing WireGuard packets from this interface. Takes a number between 1 and 4294967295.</para>
+
+        <xi:include href="version-info.xml" xpointer="v243"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>RouteTable=</varname></term>
+        <listitem>
+          <para>The table identifier for the routes to the addresses specified in the
+          <varname>AllowedIPs=</varname>. Takes a negative boolean value, one of the predefined names
+          <literal>default</literal>, <literal>main</literal>, and <literal>local</literal>, names
+          defined in <varname>RouteTable=</varname> in
+          <citerefentry><refentrytitle>networkd.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+          or a number in the range 1…4294967295. When <literal>off</literal> the routes to the
+          addresses specified in the <varname>AllowedIPs=</varname> setting will not be configured.
+          Defaults to false. This setting will be ignored when the same setting is specified in the
+          [WireGuardPeer] section.</para>
+
+          <xi:include href="version-info.xml" xpointer="v250"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>RouteMetric=</varname></term>
+        <listitem>
+          <para>The priority of the routes to the addresses specified in the
+          <varname>AllowedIPs=</varname>. Takes an integer in the range 0…4294967295. Defaults to 0
+          for IPv4 addresses, and 1024 for IPv6 addresses. This setting will be ignored when the same
+          setting is specified in the [WireGuardPeer] section.</para>
+
+          <xi:include href="version-info.xml" xpointer="v250"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[WireGuardPeer] Section Options</title>
+
+    <para>The [WireGuardPeer] section accepts the following
+    keys:</para>
+
+    <variablelist class='network-directives'>
+      <varlistentry>
+        <term><varname>PublicKey=</varname></term>
+        <listitem>
+          <para>Sets a Base64 encoded public key calculated by <command>wg pubkey</command>
+          (see <citerefentry project="wireguard"><refentrytitle>wg</refentrytitle><manvolnum>8</manvolnum></citerefentry>)
+          from a private key, and usually transmitted out of band to the
+          author of the configuration file. This option is mandatory for this
+          section.</para>
+
+        <xi:include href="version-info.xml" xpointer="v237"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>PresharedKey=</varname></term>
+        <listitem>
+          <para>Optional preshared key for the interface. It can be generated
+          by the <command>wg genpsk</command> command. This option adds an
+          additional layer of symmetric-key cryptography to be mixed into the
+          already existing public-key cryptography, for post-quantum
+          resistance.
+          Note that because this information is secret, you may want to set
+          the permissions of the .netdev file to be owned by <literal>root:systemd-network</literal>
+          with a <literal>0640</literal> file mode.</para>
+
+          <xi:include href="version-info.xml" xpointer="v237"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>PresharedKeyFile=</varname></term>
+        <listitem>
+          <para>Takes an absolute path to a file which contains the Base64 encoded preshared key for the
+          peer. When this option is specified, then <varname>PresharedKey=</varname> is ignored.  Note that
+          the file must be readable by the user <literal>systemd-network</literal>, so it should be, e.g.,
+          owned by <literal>root:systemd-network</literal> with a <literal>0640</literal> file mode. If the
+          path refers to an <constant>AF_UNIX</constant> stream socket in the file system a connection is
+          made to it and the key read from it.</para>
+
+          <xi:include href="version-info.xml" xpointer="v242"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>AllowedIPs=</varname></term>
+        <listitem>
+          <para>Sets a comma-separated list of IP (v4 or v6) addresses with CIDR masks from which this peer
+          is allowed to send incoming traffic and to which outgoing traffic for this peer is directed. This
+          setting can be specified multiple times. If an empty string is assigned, then the all previous
+          assignments are cleared.</para>
+
+          <para>The catch-all 0.0.0.0/0 may be specified for matching all IPv4 addresses,
+          and ::/0 may be specified for matching all IPv6 addresses.</para>
+
+          <para>Note that this only affects <emphasis>routing inside the network interface itself</emphasis>,
+          i.e. the packets that pass through the tunnel itself. To cause packets to be sent via the tunnel in
+          the first place, an appropriate route needs to be added as well — either in the
+          <literal>[Routes]</literal> section on the <literal>.network</literal> matching the wireguard
+          interface, or externally to <filename>systemd-networkd</filename>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v237"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>Endpoint=</varname></term>
+        <listitem>
+          <para>Sets an endpoint IP address or hostname, followed by a colon, and then
+          a port number. IPv6 address must be in the square brackets. For example,
+          <literal>111.222.333.444:51820</literal> for IPv4 and <literal>[1111:2222::3333]:51820</literal>
+          for IPv6 address. This endpoint will be updated automatically once to
+          the most recent source IP address and port of correctly
+          authenticated packets from the peer at configuration time.</para>
+
+          <xi:include href="version-info.xml" xpointer="v237"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>PersistentKeepalive=</varname></term>
+        <listitem>
+          <para>Sets a seconds interval, between 1 and 65535 inclusive, of how often
+          to send an authenticated empty packet to the peer for the purpose
+          of keeping a stateful firewall or NAT mapping valid persistently.
+          For example, if the interface very rarely sends traffic, but it
+          might at anytime receive traffic from a peer, and it is behind NAT,
+          the interface might benefit from having a persistent keepalive
+          interval of 25 seconds. If set to 0 or "off", this option is
+          disabled. By default or when unspecified, this option is off.
+          Most users will not need this.</para>
+
+          <xi:include href="version-info.xml" xpointer="v237"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>RouteTable=</varname></term>
+        <listitem>
+          <para>The table identifier for the routes to the addresses specified in the
+          <varname>AllowedIPs=</varname>. Takes a negative boolean value, one of the predefined names
+          <literal>default</literal>, <literal>main</literal>, and <literal>local</literal>, names
+          defined in <varname>RouteTable=</varname> in
+          <citerefentry><refentrytitle>networkd.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+          or a number in the range 1…4294967295. Defaults to unset, and the value specified in the
+          same setting in the [WireGuard] section will be used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v250"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>RouteMetric=</varname></term>
+        <listitem>
+          <para>The priority of the routes to the addresses specified in the
+          <varname>AllowedIPs=</varname>. Takes an integer in the range 0…4294967295. Defaults to
+          unset, and the value specified in the same setting in the [WireGuard] section will be used.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v250"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[Bond] Section Options</title>
+
+    <para>The [Bond] section accepts the following
+    key:</para>
+
+    <variablelist class='network-directives'>
+      <varlistentry>
+        <term><varname>Mode=</varname></term>
+        <listitem>
+          <para>Specifies one of the bonding policies. The default is
+          <literal>balance-rr</literal> (round robin). Possible values are
+          <literal>balance-rr</literal>,
+          <literal>active-backup</literal>,
+          <literal>balance-xor</literal>,
+          <literal>broadcast</literal>,
+          <literal>802.3ad</literal>,
+          <literal>balance-tlb</literal>, and
+          <literal>balance-alb</literal>.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v216"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>TransmitHashPolicy=</varname></term>
+        <listitem>
+          <para>Selects the transmit hash policy to use for slave
+          selection in balance-xor, 802.3ad, and tlb modes. Possible
+          values are
+          <literal>layer2</literal>,
+          <literal>layer3+4</literal>,
+          <literal>layer2+3</literal>,
+          <literal>encap2+3</literal>, and
+          <literal>encap3+4</literal>.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v216"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>LACPTransmitRate=</varname></term>
+        <listitem>
+          <para>Specifies the rate with which link partner transmits
+          Link Aggregation Control Protocol Data Unit packets in
+          802.3ad mode. Possible values are <literal>slow</literal>,
+          which requests partner to transmit LACPDUs every 30 seconds,
+          and <literal>fast</literal>, which requests partner to
+          transmit LACPDUs every second. The default value is
+          <literal>slow</literal>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v216"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>MIIMonitorSec=</varname></term>
+        <listitem>
+          <para>Specifies the frequency that Media Independent
+          Interface link monitoring will occur. A value of zero
+          disables MII link monitoring. This value is rounded down to
+          the nearest millisecond. The default value is 0.</para>
+
+          <xi:include href="version-info.xml" xpointer="v216"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>UpDelaySec=</varname></term>
+        <listitem>
+          <para>Specifies the delay before a link is enabled after a
+          link up status has been detected. This value is rounded down
+          to a multiple of <varname>MIIMonitorSec=</varname>. The default value is
+          0.</para>
+
+          <xi:include href="version-info.xml" xpointer="v216"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>DownDelaySec=</varname></term>
+        <listitem>
+          <para>Specifies the delay before a link is disabled after a
+          link down status has been detected. This value is rounded
+          down to a multiple of <varname>MIIMonitorSec=</varname>. The default value is
+          0.</para>
+
+          <xi:include href="version-info.xml" xpointer="v216"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>LearnPacketIntervalSec=</varname></term>
+        <listitem>
+          <para>Specifies the number of seconds between instances where the bonding
+          driver sends learning packets to each slave peer switch.
+          The valid range is 1…0x7fffffff; the default value is 1. This option
+          has an effect only for the balance-tlb and balance-alb modes.</para>
+
+          <xi:include href="version-info.xml" xpointer="v220"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>AdSelect=</varname></term>
+        <listitem>
+          <para>Specifies the 802.3ad aggregation selection logic to use. Possible values are
+          <literal>stable</literal>,
+          <literal>bandwidth</literal> and
+          <literal>count</literal>.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v220"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>AdActorSystemPriority=</varname></term>
+        <listitem>
+          <para>Specifies the 802.3ad actor system priority. Takes a number in the range 1…65535.</para>
+
+        <xi:include href="version-info.xml" xpointer="v240"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>AdUserPortKey=</varname></term>
+        <listitem>
+          <para>Specifies the 802.3ad user defined portion of the port key. Takes a number in the range
+          0…1023.</para>
+
+          <xi:include href="version-info.xml" xpointer="v240"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>AdActorSystem=</varname></term>
+        <listitem>
+          <para>Specifies the 802.3ad system MAC address. This cannot be a null or multicast address.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v240"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>FailOverMACPolicy=</varname></term>
+        <listitem>
+          <para>Specifies whether the active-backup mode should set all slaves to
+          the same MAC address at the time of enslavement or, when enabled, to perform special handling of the
+          bond's MAC address in accordance with the selected policy. The default policy is none.
+          Possible values are
+          <literal>none</literal>,
+          <literal>active</literal> and
+          <literal>follow</literal>.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v220"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ARPValidate=</varname></term>
+        <listitem>
+          <para>Specifies whether or not ARP probes and replies should be
+          validated in any mode that supports ARP monitoring, or whether
+          non-ARP traffic should be filtered (disregarded) for link
+          monitoring purposes. Possible values are
+          <literal>none</literal>,
+          <literal>active</literal>,
+          <literal>backup</literal> and
+          <literal>all</literal>.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v220"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ARPIntervalSec=</varname></term>
+        <listitem>
+          <para>Specifies the ARP link monitoring frequency. A value of 0 disables ARP monitoring. The
+          default value is 0, and the default unit seconds.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v220"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ARPIPTargets=</varname></term>
+        <listitem>
+          <para>Specifies the IP addresses to use as ARP monitoring peers when
+          <varname>ARPIntervalSec=</varname> is greater than 0. These are the targets of the ARP
+          request sent to determine the health of the link to the targets.
+          Specify these values in IPv4 dotted decimal format. At least one IP
+          address must be given for ARP monitoring to function. The
+          maximum number of targets that can be specified is 16. The
+          default value is no IP addresses.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v220"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ARPAllTargets=</varname></term>
+        <listitem>
+          <para>Specifies the quantity of <varname>ARPIPTargets=</varname> that must be reachable
+          in order for the ARP monitor to consider a slave as being up.
+          This option affects only active-backup mode for slaves with
+          ARPValidate enabled. Possible values are
+          <literal>any</literal> and
+          <literal>all</literal>.
+          </para>
+
+        <xi:include href="version-info.xml" xpointer="v220"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>PrimaryReselectPolicy=</varname></term>
+        <listitem>
+          <para>Specifies the reselection policy for the primary slave.  This
+          affects how the primary slave is chosen to become the active slave
+          when failure of the active slave or recovery of the primary slave
+          occurs. This option is designed to prevent flip-flopping between
+          the primary slave and other slaves.  Possible values are
+          <literal>always</literal>,
+          <literal>better</literal> and
+          <literal>failure</literal>.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v220"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ResendIGMP=</varname></term>
+        <listitem>
+          <para>Specifies the number of IGMP membership reports to be issued after
+          a failover event. One membership report is issued immediately after
+          the failover, subsequent packets are sent in each 200ms interval.
+          The valid range is 0…255. Defaults to 1. A value of 0
+          prevents the IGMP membership report from being issued in response
+          to the failover event.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v220"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>PacketsPerSlave=</varname></term>
+        <listitem>
+          <para>Specify the number of packets to transmit through a slave before
+          moving to the next one. When set to 0, then a slave is chosen at
+          random. The valid range is 0…65535. Defaults to 1. This option
+          only has effect when in balance-rr mode.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v220"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>GratuitousARP=</varname></term>
+        <listitem>
+          <para>Specify the number of peer notifications (gratuitous ARPs and
+          unsolicited IPv6 Neighbor Advertisements) to be issued after a
+          failover event.  As soon as the link is up on the new slave,
+          a peer notification is sent on the  bonding device and each
+          VLAN sub-device.  This is repeated at each link monitor interval
+          (ARPIntervalSec or MIIMonitorSec, whichever is active) if the number is
+          greater than 1. The valid range is 0…255. The default value is 1.
+          These options affect only the active-backup mode.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v220"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>AllSlavesActive=</varname></term>
+        <listitem>
+          <para>Takes a boolean. Specifies that duplicate frames (received on inactive ports)
+          should be dropped when false, or delivered when true. Normally, bonding will drop
+          duplicate frames (received on inactive ports), which is desirable for
+          most users. But there are some times it is nice to allow duplicate
+          frames to be delivered. The default value is false (drop duplicate frames
+          received on inactive ports).
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v220"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>DynamicTransmitLoadBalancing=</varname></term>
+        <listitem>
+          <para>Takes a boolean. Specifies if dynamic shuffling of flows is enabled. Applies only
+          for balance-tlb mode. Defaults to unset.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v240"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>MinLinks=</varname></term>
+        <listitem>
+          <para>Specifies the minimum number of links that must be active before
+          asserting carrier. The default value is 0.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v220"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+
+    <para>For more detail information see
+    <ulink url="https://docs.kernel.org/networking/bonding.html">
+    Linux Ethernet Bonding Driver HOWTO</ulink></para>
+  </refsect1>
+
+  <refsect1>
+    <title>[Xfrm] Section Options</title>
+
+    <para>The [Xfrm] section accepts the following
+    keys:</para>
+
+    <variablelist class='network-directives'>
+      <varlistentry>
+        <term><varname>InterfaceId=</varname></term>
+        <listitem>
+          <para>Sets the ID/key of the xfrm interface which needs to be associated with a SA/policy.
+          Can be decimal or hexadecimal, valid range is 1-0xffffffff. This is mandatory.</para>
+
+          <xi:include href="version-info.xml" xpointer="v243"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>Independent=</varname></term>
+        <listitem>
+          <para>Takes a boolean. If false (the default), the xfrm interface must have an underlying device
+          which can be used for hardware offloading.</para>
+
+          <xi:include href="version-info.xml" xpointer="v243"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+
+    <para>For more detail information see
+      <ulink url="https://lwn.net/Articles/757391">Virtual XFRM Interfaces</ulink>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>[VRF] Section Options</title>
+    <para>The [VRF] section only applies for
+    netdevs of kind <literal>vrf</literal> and accepts the
+    following key:</para>
+
+    <variablelist class='network-directives'>
+      <varlistentry>
+        <term><varname>Table=</varname></term>
+        <listitem>
+          <para>The numeric routing table identifier. This setting is compulsory.</para>
+
+        <xi:include href="version-info.xml" xpointer="v243"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[BatmanAdvanced] Section Options</title>
+
+    <para>The [BatmanAdvanced] section only applies for netdevs of kind <literal>batadv</literal> and accepts
+    the following keys:</para>
+
+    <variablelist class='network-directives'>
+      <varlistentry>
+        <term><varname>GatewayMode=</varname></term>
+        <listitem>
+          <para>Takes one of <literal>off</literal>, <literal>server</literal>, or <literal>client</literal>.
+          A batman-adv node can either run in server mode (sharing its internet
+          connection with the mesh) or in client mode (searching for the most suitable internet connection
+          in the mesh) or having the gateway support turned off entirely (which is the default setting).
+          </para>
+
+        <xi:include href="version-info.xml" xpointer="v248"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>Aggregation=</varname></term>
+        <listitem>
+          <para>Takes a boolean value. Enables or disables aggregation of originator messages. Defaults to
+           true.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v248"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>BridgeLoopAvoidance=</varname></term>
+        <listitem>
+          <para>Takes a boolean value. Enables or disables avoidance of loops on bridges. Defaults to true.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v248"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>DistributedArpTable=</varname></term>
+        <listitem>
+          <para>Takes a boolean value. Enables or disables the distributed ARP table. Defaults to true.</para>
+
+        <xi:include href="version-info.xml" xpointer="v248"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>Fragmentation=</varname></term>
+        <listitem>
+          <para>Takes a boolean value. Enables or disables fragmentation. Defaults to true.</para>
+
+        <xi:include href="version-info.xml" xpointer="v248"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>HopPenalty=</varname></term>
+        <listitem>
+          <para>The hop penalty setting allows one to modify
+          <citerefentry project='mankier'><refentrytitle>batctl</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+          preference for multihop routes vs. short routes. This integer value is applied to the
+          TQ (Transmit Quality) of each forwarded OGM (Originator Message), thereby propagating the
+          cost of an extra hop (the packet has to be received and retransmitted which costs airtime).
+          A higher hop penalty will make it more unlikely that other nodes will choose this node as
+          intermediate hop towards any given destination. The default hop penalty of '15' is a reasonable
+          value for most setups and probably does not need to be changed. However, mobile nodes could
+          choose a value of 255 (maximum value) to avoid being chosen as a router by other nodes.
+          The minimum value is 0.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v248"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>OriginatorIntervalSec=</varname></term>
+        <listitem>
+          <para>The value specifies the interval in seconds, unless another time unit is specified in which
+          batman-adv floods the network with its protocol information.
+          See <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+          for more information.</para>
+
+          <xi:include href="version-info.xml" xpointer="v248"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>GatewayBandwidthDown=</varname></term>
+        <listitem>
+          <para>If the node is a server, this
+          parameter is used to inform other nodes in the network about
+          this node's internet connection download bandwidth in bits per second. Just enter any number
+          suffixed with K, M, G or T (base 1000) and the batman-adv
+          module will propagate the entered value in the mesh.</para>
+
+          <xi:include href="version-info.xml" xpointer="v248"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>GatewayBandwidthUp=</varname></term>
+        <listitem>
+          <para>If the node is a server, this
+          parameter is used to inform other nodes in the network about
+          this node's internet connection upload bandwidth in bits per second. Just enter any number
+          suffixed with K, M, G or T (base 1000) and the batman-adv
+          module will propagate the entered value in the mesh.</para>
+
+          <xi:include href="version-info.xml" xpointer="v248"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>RoutingAlgorithm=</varname></term>
+        <listitem>
+          <para>This can be either <literal>batman-v</literal> or <literal>batman-iv</literal> and describes which routing_algo
+          of <citerefentry project='mankier'><refentrytitle>batctl</refentrytitle><manvolnum>8</manvolnum></citerefentry> to use. The algorithm
+          cannot be changed after interface creation. Defaults to <literal>batman-v</literal>.
+          </para>
+
+        <xi:include href="version-info.xml" xpointer="v248"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[IPoIB] Section Options</title>
+    <para>The [IPoIB] section only applies for netdevs of kind <literal>ipoib</literal> and accepts the
+    following keys:</para>
+
+    <variablelist class='network-directives'>
+      <varlistentry>
+        <term><varname>PartitionKey=</varname></term>
+        <listitem>
+          <para>Takes an integer in the range 1…0xffff, except for 0x8000. Defaults to unset, and the
+          kernel's default is used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v250"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry id='ipoib_mode'>
+        <term><varname>Mode=</varname></term>
+        <listitem>
+          <para>Takes one of the special values <literal>datagram</literal> or
+          <literal>connected</literal>. Defaults to unset, and the kernel's default is used.</para>
+
+          <para>When <literal>datagram</literal>, the Infiniband unreliable datagram (UD) transport is
+          used, and so the interface MTU is equal to the IB L2 MTU minus the IPoIB encapsulation
+          header (4 bytes). For example, in a typical IB fabric with a 2K MTU, the IPoIB MTU will be
+          2048 - 4 = 2044 bytes.</para>
+
+          <para>When <literal>connected</literal>, the Infiniband reliable connected (RC) transport is
+          used. Connected mode takes advantage of the connected nature of the IB transport and allows
+          an MTU up to the maximal IP packet size of 64K, which reduces the number of IP packets needed
+          for handling large UDP datagrams, TCP segments, etc and increases the performance for large
+          messages.</para>
+
+          <xi:include href="version-info.xml" xpointer="v250"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry id='ipoib_umcast'>
+        <term><varname>IgnoreUserspaceMulticastGroup=</varname></term>
+        <listitem>
+          <para>Takes an boolean value. When true, the kernel ignores multicast groups handled by
+          userspace. Defaults to unset, and the kernel's default is used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v250"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[WLAN] Section Options</title>
+    <para>The [WLAN] section only applies to WLAN interfaces, and accepts the following keys:</para>
+
+    <variablelist class='network-directives'>
+      <varlistentry>
+        <term><varname>PhysicalDevice=</varname></term>
+        <listitem>
+          <para>Specifies the name or index of the physical WLAN device (e.g. <literal>0</literal> or
+          <literal>phy0</literal>). The list of the physical WLAN devices that exist on the host can be
+          obtained by <command>iw phy</command> command. This option is mandatory.</para>
+
+        <xi:include href="version-info.xml" xpointer="v251"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Type=</varname></term>
+        <listitem>
+          <para>Specifies the type of the interface. Takes one of the <literal>ad-hoc</literal>,
+          <literal>station</literal>, <literal>ap</literal>, <literal>ap-vlan</literal>,
+          <literal>wds</literal>, <literal>monitor</literal>, <literal>mesh-point</literal>,
+          <literal>p2p-client</literal>, <literal>p2p-go</literal>, <literal>p2p-device</literal>,
+          <literal>ocb</literal>, and <literal>nan</literal>. This option is mandatory.</para>
+
+        <xi:include href="version-info.xml" xpointer="v251"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>WDS=</varname></term>
+        <listitem>
+          <para>Enables the Wireless Distribution System (WDS) mode on the interface. The mode is also
+          known as the <literal>4 address mode</literal>. Takes a boolean value. Defaults to unset, and
+          the kernel's default will be used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v251"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Examples</title>
+    <example>
+      <title>/etc/systemd/network/25-bridge.netdev</title>
+
+      <programlisting>[NetDev]
+Name=bridge0
+Kind=bridge</programlisting>
+    </example>
+
+    <example>
+      <title>/etc/systemd/network/25-vlan1.netdev</title>
+
+      <programlisting>[Match]
+Virtualization=no
+
+[NetDev]
+Name=vlan1
+Kind=vlan
+
+[VLAN]
+Id=1</programlisting>
+    </example>
+    <example>
+      <title>/etc/systemd/network/25-ipip.netdev</title>
+      <programlisting>[NetDev]
+Name=ipip-tun
+Kind=ipip
+MTUBytes=1480
+
+[Tunnel]
+Local=192.168.223.238
+Remote=192.169.224.239
+TTL=64</programlisting>
+    </example>
+    <example>
+      <title>/etc/systemd/network/1-fou-tunnel.netdev</title>
+      <programlisting>[NetDev]
+Name=fou-tun
+Kind=fou
+
+[FooOverUDP]
+Port=5555
+Protocol=4
+      </programlisting>
+    </example>
+    <example>
+      <title>/etc/systemd/network/25-fou-ipip.netdev</title>
+      <programlisting>[NetDev]
+Name=ipip-tun
+Kind=ipip
+
+[Tunnel]
+Independent=yes
+Local=10.65.208.212
+Remote=10.65.208.211
+FooOverUDP=yes
+FOUDestinationPort=5555
+      </programlisting>
+    </example>
+    <example>
+      <title>/etc/systemd/network/25-tap.netdev</title>
+      <programlisting>[NetDev]
+Name=tap-test
+Kind=tap
+
+[Tap]
+MultiQueue=yes
+PacketInfo=yes</programlisting> </example>
+
+    <example>
+      <title>/etc/systemd/network/25-sit.netdev</title>
+      <programlisting>[NetDev]
+Name=sit-tun
+Kind=sit
+MTUBytes=1480
+
+[Tunnel]
+Local=10.65.223.238
+Remote=10.65.223.239</programlisting>
+    </example>
+
+    <example>
+      <title>/etc/systemd/network/25-6rd.netdev</title>
+      <programlisting>[NetDev]
+Name=6rd-tun
+Kind=sit
+MTUBytes=1480
+
+[Tunnel]
+Local=10.65.223.238
+IPv6RapidDeploymentPrefix=2602::/24</programlisting>
+    </example>
+
+    <example>
+      <title>/etc/systemd/network/25-gre.netdev</title>
+      <programlisting>[NetDev]
+Name=gre-tun
+Kind=gre
+MTUBytes=1480
+
+[Tunnel]
+Local=10.65.223.238
+Remote=10.65.223.239</programlisting>
+    </example>
+
+    <example>
+      <title>/etc/systemd/network/25-ip6gre.netdev</title>
+      <programlisting>[NetDev]
+Name=ip6gre-tun
+Kind=ip6gre
+
+[Tunnel]
+Key=123</programlisting>
+    </example>
+
+    <example>
+      <title>/etc/systemd/network/25-vti.netdev</title>
+
+      <programlisting>[NetDev]
+Name=vti-tun
+Kind=vti
+MTUBytes=1480
+
+[Tunnel]
+Local=10.65.223.238
+Remote=10.65.223.239</programlisting>
+    </example>
+
+    <example>
+      <title>/etc/systemd/network/25-veth.netdev</title>
+      <programlisting>[NetDev]
+Name=veth-test
+Kind=veth
+
+[Peer]
+Name=veth-peer</programlisting>
+    </example>
+
+    <example>
+      <title>/etc/systemd/network/25-bond.netdev</title>
+      <programlisting>[NetDev]
+Name=bond1
+Kind=bond
+
+[Bond]
+Mode=802.3ad
+TransmitHashPolicy=layer3+4
+MIIMonitorSec=1s
+LACPTransmitRate=fast
+</programlisting>
+    </example>
+
+    <example>
+      <title>/etc/systemd/network/25-dummy.netdev</title>
+      <programlisting>[NetDev]
+Name=dummy-test
+Kind=dummy
+MACAddress=12:34:56:78:9a:bc</programlisting>
+    </example>
+    <example>
+      <title>/etc/systemd/network/25-vrf.netdev</title>
+      <para>Create a VRF interface with table 42.</para>
+      <programlisting>[NetDev]
+Name=vrf-test
+Kind=vrf
+
+[VRF]
+Table=42</programlisting>
+    </example>
+
+    <example>
+      <title>/etc/systemd/network/25-macvtap.netdev</title>
+      <para>Create a MacVTap device.</para>
+      <programlisting>[NetDev]
+Name=macvtap-test
+Kind=macvtap
+      </programlisting>
+    </example>
+    <example>
+      <title>/etc/systemd/network/25-wireguard.netdev</title>
+      <programlisting>[NetDev]
+Name=wg0
+Kind=wireguard
+
+[WireGuard]
+PrivateKey=EEGlnEPYJV//kbvvIqxKkQwOiS+UENyPncC4bF46ong=
+ListenPort=51820
+
+[WireGuardPeer]
+PublicKey=RDf+LSpeEre7YEIKaxg+wbpsNV7du+ktR99uBEtIiCA=
+AllowedIPs=fd31:bf08:57cb::/48,192.168.26.0/24
+Endpoint=wireguard.example.com:51820</programlisting>
+    </example>
+
+    <example>
+      <title>/etc/systemd/network/27-xfrm.netdev</title>
+      <programlisting>[NetDev]
+Name=xfrm0
+Kind=xfrm
+
+[Xfrm]
+Independent=yes</programlisting>
+    </example>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-networkd</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.link</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.network</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-network-generator.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd.network.xml b/man/systemd.network.xml
new file mode 100644
index 0000000..6dd38ea
--- /dev/null
+++ b/man/systemd.network.xml
@@ -0,0 +1,6230 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd.network" conditional='ENABLE_NETWORKD'
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd.network</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd.network</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd.network</refname>
+    <refpurpose>Network configuration</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename><replaceable>network</replaceable>.network</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>A plain ini-style text file that encodes network configuration for matching network
+    interfaces, used by
+    <citerefentry><refentrytitle>systemd-networkd</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+    See <citerefentry><refentrytitle>systemd.syntax</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+    for a general description of the syntax.</para>
+
+    <para>The main network file must have the extension <filename>.network</filename>; other
+    extensions are ignored. Networks are applied to links whenever the links appear.</para>
+
+    <para>The <filename>.network</filename> files are read from the files located in the system network
+    directories <filename>/usr/lib/systemd/network</filename> and
+    <filename>/usr/local/lib/systemd/network</filename>, the volatile runtime network directory
+    <filename>/run/systemd/network</filename> and the local administration network directory
+    <filename>/etc/systemd/network</filename>. All configuration files are collectively sorted and
+    processed in alphanumeric order, regardless of the directories in which they live. However, files
+    with identical filenames replace each other. It is recommended that each filename is prefixed with
+    a number smaller than <literal>70</literal> (e.g. <filename>10-eth0.network</filename>). Otherwise, the
+    default <filename>.network</filename> files or those generated by
+    <citerefentry><refentrytitle>systemd-network-generator.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    may take precedence over user configured files. Files in <filename>/etc/</filename> have the highest
+    priority, files in <filename>/run/</filename> take precedence over files with the same name under
+    <filename>/usr/</filename>. This can be used to override a system-supplied configuration file with
+    a local file if needed. As a special case, an empty file (file size 0) or symlink with the same
+    name pointing to <filename>/dev/null</filename> disables the configuration file entirely (it is
+    "masked").</para>
+
+    <para>Along with the network file <filename>foo.network</filename>, a "drop-in" directory
+    <filename>foo.network.d/</filename> may exist. All files with the suffix
+    <literal>.conf</literal> from this directory will be merged in the alphanumeric order and parsed
+    after the main file itself has been parsed. This is useful to alter or add configuration settings,
+    without having to modify the main configuration file. Each drop-in file must have appropriate
+    section headers.</para>
+
+    <para>In addition to <filename>/etc/systemd/network</filename>, drop-in <literal>.d</literal>
+    directories can be placed in <filename>/usr/lib/systemd/network</filename> or
+    <filename>/run/systemd/network</filename> directories. Drop-in files in
+    <filename>/etc/</filename> take precedence over those in <filename>/run/</filename> which in turn
+    take precedence over those in <filename>/usr/lib/</filename>. Drop-in files under any of these
+    directories take precedence over the main network file wherever located.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>[Match] Section Options</title>
+
+    <para>The network file contains a [Match] section, which determines if a given network file may
+    be applied to a given interface; and a [Network] section specifying how the interface should be
+    configured. The first (in alphanumeric order) of the network files that matches a given interface
+    is applied, all later files are ignored, even if they match as well.</para>
+
+    <para>Note that any network interfaces that have the <varname>ID_NET_MANAGED_BY=</varname> udev property
+    set will never be matched by any .network files – unless the property's value is the string
+    <literal>io.systemd.Network</literal> – even if the [Match] section would otherwise match. This may be
+    used to exclude specific network interfaces from <command>systemd-networkd</command>'s management, while
+    keeping the [Match] section generic. The <varname>ID_NET_MANAGED_BY=</varname> property thus declares
+    intended <emphasis>ownership</emphasis> of the device, and permits ensuring that concurrent network
+    management implementations do not compete for management of specific devices.</para>
+
+    <para>A network file is said to match a network interface if all matches specified by the [Match]
+    section are satisfied. When a network file does not contain valid settings in [Match] section, then
+    the file will match all interfaces and <command>systemd-networkd</command> warns about that. Hint:
+    to avoid the warning and to make it clear that all interfaces shall be matched, add the following:
+    <programlisting>Name=*</programlisting> The following keys are accepted:</para>
+
+    <variablelist class='network-directives'>
+      <xi:include href="systemd.link.xml" xpointer="mac-address" />
+      <xi:include href="systemd.link.xml" xpointer="permanent-mac-address" />
+      <xi:include href="systemd.link.xml" xpointer="path" />
+      <xi:include href="systemd.link.xml" xpointer="driver" />
+      <xi:include href="systemd.link.xml" xpointer="type" />
+      <xi:include href="systemd.link.xml" xpointer="kind" />
+      <xi:include href="systemd.link.xml" xpointer="property" />
+
+      <varlistentry>
+        <term><varname>Name=</varname></term>
+        <listitem>
+          <para>A whitespace-separated list of shell-style globs matching the device name, as exposed
+          by the udev property <literal>INTERFACE</literal>, or device's alternative names. If the
+          list is prefixed with a "!", the test is inverted.</para>
+
+          <xi:include href="version-info.xml" xpointer="v211"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>WLANInterfaceType=</varname></term>
+        <listitem>
+          <para>A whitespace-separated list of wireless network type. Supported values are
+          <literal>ad-hoc</literal>, <literal>station</literal>, <literal>ap</literal>,
+          <literal>ap-vlan</literal>, <literal>wds</literal>, <literal>monitor</literal>,
+          <literal>mesh-point</literal>, <literal>p2p-client</literal>, <literal>p2p-go</literal>,
+          <literal>p2p-device</literal>, <literal>ocb</literal>, and <literal>nan</literal>. If the
+          list is prefixed with a "!", the test is inverted. </para>
+
+          <xi:include href="version-info.xml" xpointer="v244"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SSID=</varname></term>
+        <listitem>
+          <para>A whitespace-separated list of shell-style globs matching the SSID of the currently
+          connected wireless LAN. If the list is prefixed with a "!", the test is inverted.</para>
+
+          <xi:include href="version-info.xml" xpointer="v244"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>BSSID=</varname></term>
+        <listitem>
+          <para>A whitespace-separated list of hardware address of the currently connected wireless
+          LAN. Use full colon-, hyphen- or dot-delimited hexadecimal. See the example in
+          <varname>MACAddress=</varname>. This option may appear more than once, in which case the
+          lists are merged. If the empty string is assigned to this option, the list is reset.</para>
+
+          <xi:include href="version-info.xml" xpointer="v244"/>
+        </listitem>
+      </varlistentry>
+
+      <xi:include href="systemd.link.xml" xpointer="host" />
+      <xi:include href="systemd.link.xml" xpointer="virtualization" />
+      <xi:include href="systemd.link.xml" xpointer="kernel-command-line" />
+      <xi:include href="systemd.link.xml" xpointer="kernel-version" />
+      <xi:include href="systemd.link.xml" xpointer="credential" />
+      <xi:include href="systemd.link.xml" xpointer="architecture" />
+      <xi:include href="systemd.link.xml" xpointer="firmware" />
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[Link] Section Options</title>
+
+    <para>The [Link] section accepts the following keys:</para>
+
+    <variablelist class='network-directives'>
+      <varlistentry>
+        <term><varname>MACAddress=</varname></term>
+        <listitem>
+          <para>The hardware address to set for the device.</para>
+
+        <xi:include href="version-info.xml" xpointer="v218"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>MTUBytes=</varname></term>
+        <listitem>
+          <para>The maximum transmission unit in bytes to set for the device. The usual suffixes K, M,
+          G, are supported and are understood to the base of 1024.</para>
+          <para>Note that if IPv6 is enabled on the interface, and the MTU is chosen below 1280 (the
+          minimum MTU for IPv6) it will automatically be increased to this value.</para>
+
+          <xi:include href="version-info.xml" xpointer="v218"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ARP=</varname></term>
+        <listitem>
+          <para>Takes a boolean. If set to true, the ARP (low-level Address Resolution Protocol)
+          for this interface is enabled. When unset, the kernel's default will be used.</para>
+          <para> For example, disabling ARP is useful when creating multiple MACVLAN or VLAN virtual
+          interfaces atop a single lower-level physical interface, which will then only serve as a
+          link/"bridge" device aggregating traffic to the same physical link and not participate in
+          the network otherwise. Defaults to unset.</para>
+
+          <xi:include href="version-info.xml" xpointer="v232"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Multicast=</varname></term>
+        <listitem>
+          <para>Takes a boolean. If set to true, the multicast flag on the device is enabled. Defaults
+          to unset.</para>
+
+          <xi:include href="version-info.xml" xpointer="v239"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>AllMulticast=</varname></term>
+        <listitem>
+          <para>Takes a boolean. If set to true, the driver retrieves all multicast packets from the
+          network. This happens when multicast routing is enabled. Defaults to unset.</para>
+
+          <xi:include href="version-info.xml" xpointer="v239"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Promiscuous=</varname></term>
+        <listitem>
+          <para>Takes a boolean. If set to true, promiscuous mode of the interface is enabled. Defaults
+          to unset.</para>
+          <para>If this is set to false for the underlying link of a <literal>passthru</literal> mode
+          MACVLAN/MACVTAP, the virtual interface will be created with the <literal>nopromisc</literal>
+          flag set.</para>
+
+          <xi:include href="version-info.xml" xpointer="v248"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Unmanaged=</varname></term>
+        <listitem>
+          <para>Takes a boolean. When <literal>yes</literal>, no attempts are made to bring up or
+          configure matching links, equivalent to when there are no matching network files. Defaults to
+          <literal>no</literal>.</para>
+          <para>This is useful for preventing later matching network files from interfering with
+          certain interfaces that are fully controlled by other applications.</para>
+
+          <xi:include href="version-info.xml" xpointer="v233"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Group=</varname></term>
+        <listitem>
+          <para>Link groups are similar to port ranges found in managed switches. When network
+          interfaces are added to a numbered group, operations on all the interfaces from that group
+          can be performed at once. Takes an unsigned integer in the range 0…2147483647. Defaults to
+          unset.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RequiredForOnline=</varname></term>
+        <listitem>
+          <para>Takes a boolean or a minimum operational state and an optional maximum operational
+          state. Please see
+          <citerefentry><refentrytitle>networkctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+          for possible operational states. When <literal>yes</literal>, the network is deemed required
+          when determining whether the system is online (including when running
+          <command>systemd-networkd-wait-online</command>). When <literal>no</literal>, the network is
+          ignored when determining the online state. When a minimum operational state and an optional
+          maximum operational state are set, <literal>yes</literal> is implied, and this controls the
+          minimum and maximum operational state required for the network interface to be considered
+          online.</para>
+
+          <para>Defaults to <literal>yes</literal> when <varname>ActivationPolicy=</varname> is not
+          set, or set to <literal>up</literal>, <literal>always-up</literal>, or
+          <literal>bound</literal>. Defaults to <literal>no</literal> when
+          <varname>ActivationPolicy=</varname> is set to <literal>manual</literal> or
+          <literal>down</literal>. This is forced to <literal>no</literal> when
+          <varname>ActivationPolicy=</varname> is set to <literal>always-down</literal>.</para>
+
+          <para>The network will be brought up normally (as configured by
+          <varname>ActivationPolicy=</varname>), but in the event that there is no address being
+          assigned by DHCP or the cable is not plugged in, the link will simply remain offline and be
+          skipped automatically by <command>systemd-networkd-wait-online</command> if
+          <literal>RequiredForOnline=no</literal>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v236"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RequiredFamilyForOnline=</varname></term>
+        <listitem>
+          <para>Takes an address family. When specified, an IP address in the given family is deemed
+          required when determining whether the link is online (including when running
+          <command>systemd-networkd-wait-online</command>). Takes one of <literal>ipv4</literal>,
+          <literal>ipv6</literal>, <literal>both</literal>, or <literal>any</literal>. Defaults to
+          <literal>no</literal>. Note that this option has no effect if
+          <literal>RequiredForOnline=no</literal>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v249"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ActivationPolicy=</varname></term>
+        <listitem>
+          <para>Specifies the policy for <command>systemd-networkd</command> managing the link
+          administrative state. Specifically, this controls how <command>systemd-networkd</command>
+          changes the network device's <literal>IFF_UP</literal> flag, which is sometimes
+          controlled by system administrators by running e.g.,
+          <command>ip link set dev eth0 up</command> or <command>ip link set dev eth0 down</command>,
+          and can also be changed with <command>networkctl up eth0</command> or
+          <command>networkctl down eth0</command>.</para>
+
+          <para>Takes one of <literal>up</literal>, <literal>always-up</literal>,
+          <literal>manual</literal>, <literal>always-down</literal>, <literal>down</literal>,
+          or <literal>bound</literal>. When <literal>manual</literal>,
+          <command>systemd-networkd</command> will not change the link's admin state automatically;
+          the system administrator must bring the interface up or down manually, as desired. When
+          <literal>up</literal> (the default) or <literal>always-up</literal>, or
+          <literal>down</literal> or <literal>always-down</literal>,
+          <command>systemd-networkd</command> will set the link up or down, respectively, when the
+          interface is (re)configured. When <literal>always-up</literal> or
+          <literal>always-down</literal>, <command>systemd-networkd</command> will set the link up or
+          down, respectively, any time <command>systemd-networkd</command> detects a change in the
+          administrative state. When <varname>BindCarrier=</varname> is also set, this is automatically
+          set to <literal>bound</literal> and any other value is ignored.</para>
+
+          <para>When the policy is set to <literal>down</literal> or <literal>manual</literal>, the
+          default value of <varname>RequiredForOnline=</varname> is <literal>no</literal>. When the
+          policy is set to <literal>always-down</literal>, the value of
+          <varname>RequiredForOnline=</varname> forced to <literal>no</literal>.</para>
+
+          <para>The administrative state is not the same as the carrier state, so using
+          <literal>always-up</literal> does not mean the link will never lose carrier. The link carrier
+          depends on both the administrative state as well as the network device's physical connection.
+          However, to avoid reconfiguration failures, when using <literal>always-up</literal>,
+          <varname>IgnoreCarrierLoss=</varname> is forced to true.</para>
+
+          <xi:include href="version-info.xml" xpointer="v248"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <xi:include href="systemd.link.xml" xpointer="sr-iov" />
+
+  <refsect1>
+    <title>[Network] Section Options</title>
+
+    <para>The [Network] section accepts the following keys:</para>
+
+    <variablelist class='network-directives'>
+      <varlistentry>
+        <term><varname>Description=</varname></term>
+        <listitem>
+          <para>A description of the device. This is only used for presentation purposes.</para>
+
+        <xi:include href="version-info.xml" xpointer="v211"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>DHCP=</varname></term>
+        <listitem>
+          <para>Enables DHCPv4 and/or DHCPv6 client support. Accepts <literal>yes</literal>,
+          <literal>no</literal>, <literal>ipv4</literal>, or <literal>ipv6</literal>. Defaults to
+          <literal>no</literal>.</para>
+
+          <para>Note that DHCPv6 will by default be triggered by Router Advertisements, if reception is
+          enabled, regardless of this parameter. By explicitly enabling DHCPv6 support here, the DHCPv6
+          client will be started in the mode specified by the <varname>WithoutRA=</varname> setting in the
+          [DHCPv6] section, regardless of the presence of routers on the link, or what flags the routers
+          pass. See <varname>IPv6AcceptRA=</varname>.</para>
+
+          <para>Furthermore, note that by default the domain name specified through DHCP is not used
+          for name resolution. See option <option>UseDomains=</option> below.</para>
+
+          <para>See the [DHCPv4] or [DHCPv6] sections below for further configuration options for the
+          DHCP client support.</para>
+
+          <xi:include href="version-info.xml" xpointer="v211"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>DHCPServer=</varname></term>
+        <listitem>
+          <para>Takes a boolean. If set to <literal>yes</literal>, DHCPv4 server will be started.
+          Defaults to <literal>no</literal>. Further settings for the DHCP server may be set in the
+          [DHCPServer] section described below.</para>
+
+        <xi:include href="version-info.xml" xpointer="v215"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>LinkLocalAddressing=</varname></term>
+        <listitem>
+          <para>Enables link-local address autoconfiguration. Accepts <option>yes</option>,
+          <option>no</option>, <option>ipv4</option>, and <option>ipv6</option>. An IPv6 link-local
+          address is configured when <option>yes</option> or <option>ipv6</option>. An IPv4 link-local
+          address is configured when <option>yes</option> or <option>ipv4</option> and when DHCPv4
+          autoconfiguration has been unsuccessful for some time. (IPv4 link-local address
+          autoconfiguration will usually happen in parallel with repeated attempts to acquire a DHCPv4
+          lease).</para>
+
+          <para>Defaults to <option>no</option> when <varname>KeepMaster=</varname> or
+          <varname>Bridge=</varname> is set or when the specified
+          <varname>MACVLAN=</varname>/<varname>MACVTAP=</varname> has <varname>Mode=passthru</varname>,
+          or <option>ipv6</option> otherwise.</para>
+
+          <xi:include href="version-info.xml" xpointer="v219"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>IPv6LinkLocalAddressGenerationMode=</varname></term>
+        <listitem>
+          <para>Specifies how IPv6 link-local address is generated. Takes one of
+          <literal>eui64</literal>, <literal>none</literal>, <literal>stable-privacy</literal> and
+          <literal>random</literal>. When unset, <literal>stable-privacy</literal> is used if
+          <varname>IPv6StableSecretAddress=</varname> is specified, and if not,
+          <literal>eui64</literal> is used. Note that if <varname>LinkLocalAddressing=</varname> is
+          <literal>no</literal> or <literal>ipv4</literal>, then
+          <varname>IPv6LinkLocalAddressGenerationMode=</varname> will be ignored. Also, even if
+          <varname>LinkLocalAddressing=</varname> is <literal>yes</literal> or <literal>ipv6</literal>,
+          setting <varname>IPv6LinkLocalAddressGenerationMode=none</varname>
+          disables to configure an IPv6 link-local address.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>IPv6StableSecretAddress=</varname></term>
+        <listitem>
+          <para>Takes an IPv6 address. The specified address will be used as a stable secret for
+          generating IPv6 link-local address. If this setting is specified, and
+          <varname>IPv6LinkLocalAddressGenerationMode=</varname> is unset, then
+          <varname>IPv6LinkLocalAddressGenerationMode=stable-privacy</varname> is implied.
+          If this setting is not specified, and <literal>stable-privacy</literal> is set to
+          <varname>IPv6LinkLocalAddressGenerationMode=</varname>,
+          then a stable secret address will be generated from the local machine ID and the interface
+          name.</para>
+
+          <xi:include href="version-info.xml" xpointer="v249"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>IPv4LLStartAddress=</varname></term>
+        <listitem>
+          <para>Specifies the first IPv4 link-local address to try. Takes an IPv4 address for example
+          169.254.1.2, from the link-local address range: 169.254.0.0/16 except for 169.254.0.0/24 and
+          169.254.255.0/24. This setting may be useful if the device should always have the same address
+          as long as there is no address conflict. When unset, a random address will be automatically
+          selected. Defaults to unset.</para>
+
+          <xi:include href="version-info.xml" xpointer="v252"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>IPv4LLRoute=</varname></term>
+        <listitem>
+          <para>Takes a boolean. If set to true, sets up the route needed for non-IPv4LL hosts to
+          communicate with IPv4LL-only hosts. Defaults to false.</para>
+
+          <xi:include href="version-info.xml" xpointer="v216"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>DefaultRouteOnDevice=</varname></term>
+        <listitem>
+          <para>Takes a boolean. If set to true, sets up the IPv4 default route bound to the interface.
+          Defaults to false. This is useful when creating routes on point-to-point interfaces. This is
+          equivalent to e.g. the following,
+          <programlisting>ip route add default dev veth99</programlisting>
+          or,
+          <programlisting>[Route]
+Gateway=0.0.0.0</programlisting></para>
+          <para>Currently, there are no way to specify e.g., the table for the route configured by this
+          setting. To configure the default route with such an additional property, please use the
+          following instead:
+          <programlisting>[Route]
+Gateway=0.0.0.0
+Table=1234</programlisting></para>
+          <para>If you'd like to create an IPv6 default route bound to the interface, please use the
+          following:
+          <programlisting>[Route]
+Gateway=::
+Table=1234</programlisting></para>
+
+          <xi:include href="version-info.xml" xpointer="v243"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>LLMNR=</varname></term>
+        <listitem>
+          <para>Takes a boolean or <literal>resolve</literal>. When true, enables
+          <ulink url="https://tools.ietf.org/html/rfc4795">Link-Local Multicast Name Resolution</ulink>
+          on the link. When set to <literal>resolve</literal>, only resolution is enabled, but not host
+          registration and announcement. Defaults to true. This setting is read by
+          <citerefentry><refentrytitle>systemd-resolved.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+          </para>
+
+        <xi:include href="version-info.xml" xpointer="v216"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>MulticastDNS=</varname></term>
+        <listitem>
+          <para>Takes a boolean or <literal>resolve</literal>. When true, enables
+          <ulink url="https://tools.ietf.org/html/rfc6762">Multicast DNS</ulink> support on the link.
+          When set to <literal>resolve</literal>, only resolution is enabled, but not host or service
+          registration and announcement. Defaults to false. This setting is read by
+          <citerefentry><refentrytitle>systemd-resolved.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+          </para>
+
+        <xi:include href="version-info.xml" xpointer="v229"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>DNSOverTLS=</varname></term>
+        <listitem>
+          <para>Takes a boolean or <literal>opportunistic</literal>. When true, enables
+          <ulink url="https://tools.ietf.org/html/rfc7858">DNS-over-TLS</ulink> support on the link.
+          When set to <literal>opportunistic</literal>, compatibility with non-DNS-over-TLS servers is
+          increased, by automatically turning off DNS-over-TLS servers in this case. This option
+          defines a per-interface setting for
+          <citerefentry><refentrytitle>resolved.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>'s
+          global <varname>DNSOverTLS=</varname> option. Defaults to unset, and the global setting will
+          be used. This setting is read by
+          <citerefentry><refentrytitle>systemd-resolved.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+          </para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>DNSSEC=</varname></term>
+        <listitem>
+          <para>Takes a boolean or <literal>allow-downgrade</literal>. When true, enables
+          <ulink url="https://tools.ietf.org/html/rfc4033">DNSSEC</ulink> DNS validation support on the
+          link. When set to <literal>allow-downgrade</literal>, compatibility with non-DNSSEC capable
+          networks is increased, by automatically turning off DNSSEC in this case. This option defines
+          a per-interface setting for
+          <citerefentry><refentrytitle>resolved.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>'s
+          global <varname>DNSSEC=</varname> option. Defaults to unset, and the global setting will be
+          used. This setting is read by
+          <citerefentry><refentrytitle>systemd-resolved.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+          </para>
+
+        <xi:include href="version-info.xml" xpointer="v229"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>DNSSECNegativeTrustAnchors=</varname></term>
+        <listitem>
+          <para>A space-separated list of DNSSEC negative trust anchor domains. If specified and DNSSEC
+          is enabled, look-ups done via the interface's DNS server will be subject to the list of
+          negative trust anchors, and not require authentication for the specified domains, or anything
+          below it. Use this to disable DNSSEC authentication for specific private domains, that cannot
+          be proven valid using the Internet DNS hierarchy. Defaults to the empty list. This setting is
+          read by
+          <citerefentry><refentrytitle>systemd-resolved.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v229"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>LLDP=</varname></term>
+        <listitem>
+          <para>Controls support for Ethernet LLDP packet reception. LLDP is a link-layer protocol
+          commonly implemented on professional routers and bridges which announces which physical port
+          a system is connected to, as well as other related data. Accepts a boolean or the special
+          value <literal>routers-only</literal>. When true, incoming LLDP packets are accepted and a
+          database of all LLDP neighbors maintained. If <literal>routers-only</literal> is set only
+          LLDP data of various types of routers is collected and LLDP data about other types of devices
+          ignored (such as stations, telephones and others). If false, LLDP reception is disabled.
+          Defaults to <literal>routers-only</literal>. Use
+          <citerefentry><refentrytitle>networkctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+          to query the collected neighbor data. LLDP is only available on Ethernet links. See
+          <varname>EmitLLDP=</varname> below for enabling LLDP packet emission from the local system.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v219"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>EmitLLDP=</varname></term>
+        <listitem>
+          <para>Controls support for Ethernet LLDP packet emission. Accepts a boolean parameter or the
+          special values <literal>nearest-bridge</literal>, <literal>non-tpmr-bridge</literal> and
+          <literal>customer-bridge</literal>. Defaults to false, which turns off LLDP packet emission.
+          If not false, a short LLDP packet with information about the local system is sent out in
+          regular intervals on the link. The LLDP packet will contain information about the local
+          hostname, the local machine ID (as stored in
+          <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>)
+          and the local interface name, as well as the pretty hostname of the system (as set in
+          <citerefentry><refentrytitle>machine-info</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
+          LLDP emission is only available on Ethernet links. Note that this setting passes data
+          suitable for identification of host to the network and should thus not be enabled on
+          untrusted networks, where such identification data should not be made available. Use this
+          option to permit other systems to identify on which interfaces they are connected to this
+          system. The three special values control propagation of the LLDP packets. The
+          <literal>nearest-bridge</literal> setting permits propagation only to the nearest connected
+          bridge, <literal>non-tpmr-bridge</literal> permits propagation across Two-Port MAC Relays,
+          but not any other bridges, and <literal>customer-bridge</literal> permits propagation until
+          a customer bridge is reached. For details about these concepts, see
+          <ulink url="https://standards.ieee.org/findstds/standard/802.1AB-2016.html">IEEE 802.1AB-2016</ulink>.
+          Note that configuring this setting to true is equivalent to
+          <literal>nearest-bridge</literal>, the recommended and most restricted level of propagation.
+          See <varname>LLDP=</varname> above for an option to enable LLDP reception.</para>
+
+          <xi:include href="version-info.xml" xpointer="v230"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>BindCarrier=</varname></term>
+        <listitem>
+          <para>A link name or a list of link names. When set, controls the behavior of the current
+          link. When all links in the list are in an operational down state, the current link is
+          brought down. When at least one link has carrier, the current interface is brought up.</para>
+
+          <para>This forces <varname>ActivationPolicy=</varname> to be set to <literal>bound</literal>.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v220"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Address=</varname></term>
+        <listitem>
+          <para>A static IPv4 or IPv6 address and its prefix length, separated by a
+          <literal>/</literal> character. Specify this key more than once to configure several
+          addresses. The format of the address must be as described in
+          <citerefentry project='man-pages'><refentrytitle>inet_pton</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+          This is a short-hand for an [Address] section only containing an Address key (see below).
+          This option may be specified more than once.</para>
+
+          <para>If the specified address is <literal>0.0.0.0</literal> (for IPv4) or
+          <literal>::</literal> (for IPv6), a new address range of the requested size is automatically
+          allocated from a system-wide pool of unused ranges. Note that the prefix length must be equal
+          or larger than 8 for IPv4, and 64 for IPv6. The allocated range is checked against all
+          current network interfaces and all known network configuration files to avoid address range
+          conflicts. The default system-wide pool consists of 192.168.0.0/16, 172.16.0.0/12 and
+          10.0.0.0/8 for IPv4, and fd00::/8 for IPv6. This functionality is useful to manage a large
+          number of dynamically created network interfaces with the same network configuration and
+          automatic address range assignment.</para>
+
+          <xi:include href="version-info.xml" xpointer="v211"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Gateway=</varname></term>
+        <listitem>
+          <para>The gateway address, which must be in the format described in
+          <citerefentry project='man-pages'><refentrytitle>inet_pton</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+          This is a short-hand for a [Route] section only containing a <varname>Gateway=</varname> key.
+          This option may be specified more than once.</para>
+
+          <xi:include href="version-info.xml" xpointer="v211"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>DNS=</varname></term>
+        <listitem>
+          <para>A DNS server address, which must be in the format described in
+          <citerefentry project='man-pages'><refentrytitle>inet_pton</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+          This option may be specified more than once. Each address can optionally take a port number
+          separated with <literal>:</literal>, a network interface name or index separated with
+          <literal>%</literal>, and a Server Name Indication (SNI) separated with <literal>#</literal>.
+          When IPv6 address is specified with a port number, then the address must be in the square
+          brackets. That is, the acceptable full formats are
+          <literal>111.222.333.444:9953%ifname#example.com</literal> for IPv4 and
+          <literal>[1111:2222::3333]:9953%ifname#example.com</literal> for IPv6. If an empty string is
+          assigned, then the all previous assignments are cleared. This setting is read by
+          <citerefentry><refentrytitle>systemd-resolved.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v211"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Domains=</varname></term>
+        <listitem>
+          <para>A whitespace-separated list of domains which should be resolved using the DNS servers
+          on this link. Each item in the list should be a domain name, optionally prefixed with a tilde
+          (<literal>~</literal>). The domains with the prefix are called "routing-only domains". The
+          domains without the prefix are called "search domains" and are first used as search suffixes
+          for extending single-label hostnames (hostnames containing no dots) to become fully qualified
+          domain names (FQDNs). If a single-label hostname is resolved on this interface, each of the
+          specified search domains are appended to it in turn, converting it into a fully qualified
+          domain name, until one of them may be successfully resolved.</para>
+
+          <para>Both "search" and "routing-only" domains are used for routing of DNS queries: look-ups
+          for hostnames ending in those domains (hence also single label names, if any "search domains"
+          are listed), are routed to the DNS servers configured for this interface. The domain routing
+          logic is particularly useful on multi-homed hosts with DNS servers serving particular private
+          DNS zones on each interface.</para>
+
+          <para>The "routing-only" domain <literal>~.</literal> (the tilde indicating definition of a
+          routing domain, the dot referring to the DNS root domain which is the implied suffix of all
+          valid DNS names) has special effect. It causes all DNS traffic which does not match another
+          configured domain routing entry to be routed to DNS servers specified for this interface.
+          This setting is useful to prefer a certain set of DNS servers if a link on which they are
+          connected is available.</para>
+
+          <para>This setting is read by
+          <citerefentry><refentrytitle>systemd-resolved.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+          "Search domains" correspond to the <varname>domain</varname> and <varname>search</varname>
+          entries in
+          <citerefentry project='man-pages'><refentrytitle>resolv.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+          Domain name routing has no equivalent in the traditional glibc API, which has no concept of
+          domain name servers limited to a specific link.</para>
+
+          <xi:include href="version-info.xml" xpointer="v216"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>DNSDefaultRoute=</varname></term>
+        <listitem>
+          <para>Takes a boolean argument. If true, this link's configured DNS servers are used for
+          resolving domain names that do not match any link's configured <varname>Domains=</varname>
+          setting. If false, this link's configured DNS servers are never used for such domains, and
+          are exclusively used for resolving names that match at least one of the domains configured on
+          this link. If not specified defaults to an automatic mode: queries not matching any link's
+          configured domains will be routed to this link if it has no routing-only domains configured.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v240"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>NTP=</varname></term>
+        <listitem>
+          <para>An NTP server address (either an IP address, or a hostname). This option may be
+          specified more than once. This setting is read by
+          <citerefentry><refentrytitle>systemd-timesyncd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v216"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>IPForward=</varname></term>
+        <listitem>
+          <para>Configures IP packet forwarding for the system. If enabled, incoming packets on any
+          network interface will be forwarded to any other interfaces according to the routing table.
+          Takes a boolean, or the values <literal>ipv4</literal> or <literal>ipv6</literal>, which only
+          enable IP packet forwarding for the specified address family. This controls the
+          <filename>net.ipv4.ip_forward</filename> and <filename>net.ipv6.conf.all.forwarding</filename>
+          sysctl options of the network interface (see
+          <ulink url="https://docs.kernel.org/networking/ip-sysctl.html">IP Sysctl</ulink>
+          for details about sysctl options). Defaults to <literal>no</literal>.</para>
+
+          <para>Note: this setting controls a global kernel option, and does so one way only: if a
+          network that has this setting enabled is set up the global setting is turned on. However,
+          it is never turned off again, even after all networks with this setting enabled are shut
+          down again.</para>
+
+          <para>To allow IP packet forwarding only between specific network interfaces use a firewall.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v219"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>IPMasquerade=</varname></term>
+        <listitem>
+          <para>Configures IP masquerading for the network interface. If enabled, packets forwarded
+          from the network interface will be appear as coming from the local host. Takes one of
+          <literal>ipv4</literal>, <literal>ipv6</literal>, <literal>both</literal>, or
+          <literal>no</literal>. Defaults to <literal>no</literal>. If enabled, this automatically sets
+          <varname>IPForward=</varname> to one of <literal>ipv4</literal>, <literal>ipv6</literal> or
+          <literal>yes</literal>.</para>
+          <para>Note. Any positive boolean values such as <literal>yes</literal> or
+          <literal>true</literal> are now deprecated. Please use one of the values in the above.</para>
+
+          <xi:include href="version-info.xml" xpointer="v219"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>IPv6PrivacyExtensions=</varname></term>
+        <listitem>
+          <para>Configures use of stateless temporary addresses that change over time (see
+          <ulink url="https://tools.ietf.org/html/rfc4941">RFC 4941</ulink>,
+          Privacy Extensions for Stateless Address Autoconfiguration in IPv6). Takes a boolean or the
+          special values <literal>prefer-public</literal> and <literal>kernel</literal>. When true,
+          enables the privacy extensions and prefers temporary addresses over public addresses. When
+          <literal>prefer-public</literal>, enables the privacy extensions, but prefers public
+          addresses over temporary addresses. When false, the privacy extensions remain disabled. When
+          <literal>kernel</literal>, the kernel's default setting will be left in place. When unspecified,
+          the value specified in the same setting in
+          <citerefentry><refentrytitle>networkd.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+          which defaults to <literal>no</literal>, will be used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v222"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>IPv6AcceptRA=</varname></term>
+        <listitem>
+          <para>Takes a boolean. Controls IPv6 Router Advertisement (RA) reception support for the
+          interface. If true, RAs are accepted; if false, RAs are ignored. When RAs are accepted, they
+          may trigger the start of the DHCPv6 client if the relevant flags are set in the RA data, or
+          if no routers are found on the link. The default is to disable RA reception for bridge
+          devices or when IP forwarding is enabled, and to enable it otherwise. Cannot be enabled on
+          devices aggregated in a bond device or when link-local addressing is disabled.</para>
+
+          <para>Further settings for the IPv6 RA support may be configured in the [IPv6AcceptRA]
+          section, see below.</para>
+
+          <para>Also see
+          <ulink url="https://docs.kernel.org/networking/ip-sysctl.html">IP Sysctl</ulink>
+          in the kernel documentation regarding <literal>accept_ra</literal>, but note that systemd's
+          setting of <constant>1</constant> (i.e. true) corresponds to kernel's setting of
+          <constant>2</constant>.</para>
+
+          <para>Note that kernel's implementation of the IPv6 RA protocol is always disabled,
+          regardless of this setting. If this option is enabled, a userspace implementation of the IPv6
+          RA protocol is used, and the kernel's own implementation remains disabled, since
+          <command>systemd-networkd</command> needs to know all details supplied in the advertisements,
+          and these are not available from the kernel if the kernel's own implementation is used.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v231"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>IPv6DuplicateAddressDetection=</varname></term>
+        <listitem>
+          <para>Configures the amount of IPv6 Duplicate Address Detection (DAD) probes to send. When
+          unset, the kernel's default will be used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v228"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>IPv6HopLimit=</varname></term>
+        <listitem>
+          <para>Configures IPv6 Hop Limit. Takes an integer in the range 1…255. For each router that
+          forwards the packet, the hop limit is decremented by 1. When the hop limit field reaches zero, the
+          packet is discarded. When unset, the kernel's default will be used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v228"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>IPv4ReversePathFilter=</varname></term>
+        <listitem>
+          <para>Configure IPv4 Reverse Path Filtering. If enabled, when an IPv4 packet is received, the machine will first check
+          whether the <emphasis>source</emphasis> of the packet would be routed through the interface it came in. If there is no
+          route to the source on that interface, the machine will drop the packet. Takes one of
+          <literal>no</literal>, <literal>strict</literal>, or <literal>loose</literal>. When <literal>no</literal>,
+          no source validation will be done. When <literal>strict</literal>, mode each incoming packet is tested against the FIB and
+          if the incoming interface is not the best reverse path, the packet check will fail. By default failed packets are discarded.
+          When <literal>loose</literal>,  mode each incoming packet's source address is tested against the FIB. The packet is dropped
+          only if the source address is not reachable via any interface on that router.
+          See <ulink url="https://tools.ietf.org/html/rfc1027">RFC 3704</ulink>.
+          When unset, the kernel's default will be used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v255"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>IPv4AcceptLocal=</varname></term>
+        <listitem>
+          <para>Takes a boolean. Accept packets with local source addresses. In combination with
+          suitable routing, this can be used to direct packets between two local interfaces over the
+          wire and have them accepted properly. When unset, the kernel's default will be used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>IPv4RouteLocalnet=</varname></term>
+        <listitem>
+          <para>Takes a boolean. When true, the kernel does not consider loopback addresses as martian
+          source or destination while routing. This enables the use of 127.0.0.0/8 for local routing
+          purposes. When unset, the kernel's default will be used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v248"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>IPv4ProxyARP=</varname></term>
+        <listitem>
+          <para>Takes a boolean. Configures proxy ARP for IPv4. Proxy ARP is the technique in which one
+          host, usually a router, answers ARP requests intended for another machine. By "faking" its
+          identity, the router accepts responsibility for routing packets to the "real" destination.
+          See <ulink url="https://tools.ietf.org/html/rfc1027">RFC 1027</ulink>. When unset, the
+          kernel's default will be used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v233"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>IPv6ProxyNDP=</varname></term>
+        <listitem>
+          <para>Takes a boolean. Configures proxy NDP for IPv6. Proxy NDP (Neighbor Discovery Protocol)
+          is a technique for IPv6 to allow routing of addresses to a different destination when peers
+          expect them to be present on a certain physical link. In this case a router answers Neighbour
+          Advertisement messages intended for another machine by offering its own MAC address as
+          destination. Unlike proxy ARP for IPv4, it is not enabled globally, but will only send
+          Neighbour Advertisement messages for addresses in the IPv6 neighbor proxy table, which can
+          also be shown by <command>ip -6 neighbour show proxy</command>. systemd-networkd will control
+          the per-interface `proxy_ndp` switch for each configured interface depending on this option.
+          When unset, the kernel's default will be used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v234"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>IPv6ProxyNDPAddress=</varname></term>
+        <listitem>
+          <para>An IPv6 address, for which Neighbour Advertisement messages will be proxied. This
+          option may be specified more than once. systemd-networkd will add the
+          <varname>IPv6ProxyNDPAddress=</varname> entries to the kernel's IPv6 neighbor proxy table.
+          This setting implies <varname>IPv6ProxyNDP=yes</varname> but has no effect if
+          <varname>IPv6ProxyNDP=</varname> has been set to false. When unset, the kernel's default will
+          be used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v233"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>IPv6SendRA=</varname></term>
+        <listitem>
+          <para>Whether to enable or disable Router Advertisement sending on a link. Takes a boolean
+          value. When enabled, prefixes configured in [IPv6Prefix] sections and routes configured in
+          the [IPv6RoutePrefix] sections are distributed as defined in the [IPv6SendRA] section. If
+          <varname>DHCPPrefixDelegation=</varname> is enabled, then the delegated prefixes are also
+          distributed. See <varname>DHCPPrefixDelegation=</varname> setting and the [IPv6SendRA],
+          [IPv6Prefix], [IPv6RoutePrefix], and [DHCPPrefixDelegation] sections for more configuration
+          options.</para>
+
+          <xi:include href="version-info.xml" xpointer="v247"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>DHCPPrefixDelegation=</varname></term>
+        <listitem>
+          <para>Takes a boolean value. When enabled, requests subnet prefixes on another link via the DHCPv6
+          protocol or via the 6RD option in the DHCPv4 protocol. An address within each delegated prefix will
+          be assigned, and the prefixes will be announced through IPv6 Router Advertisement if
+          <varname>IPv6SendRA=</varname> is enabled. This behaviour can be configured in the
+          [DHCPPrefixDelegation] section. Defaults to disabled.</para>
+
+          <xi:include href="version-info.xml" xpointer="v250"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>IPv6MTUBytes=</varname></term>
+        <listitem>
+          <para>Configures IPv6 maximum transmission unit (MTU). An integer greater than or equal to
+          1280 bytes. When unset, the kernel's default will be used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v239"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>KeepMaster=</varname></term>
+        <listitem>
+          <para>Takes a boolean value. When enabled, the current master interface index will not be
+          changed, and <varname>BatmanAdvanced=</varname>, <varname>Bond=</varname>,
+          <varname>Bridge=</varname>, and <varname>VRF=</varname> settings are ignored. This may be
+          useful when a netdev with a master interface is created by another program, e.g.
+          <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
+          Defaults to false.</para>
+
+          <xi:include href="version-info.xml" xpointer="v250"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>BatmanAdvanced=</varname></term>
+        <term><varname>Bond=</varname></term>
+        <term><varname>Bridge=</varname></term>
+        <term><varname>VRF=</varname></term>
+        <listitem>
+          <para>The name of the B.A.T.M.A.N. Advanced, bond, bridge, or VRF interface to add the link
+          to. See
+          <citerefentry><refentrytitle>systemd.netdev</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v211"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>IPoIB=</varname></term>
+        <term><varname>IPVLAN=</varname></term>
+        <term><varname>IPVTAP=</varname></term>
+        <term><varname>MACsec=</varname></term>
+        <term><varname>MACVLAN=</varname></term>
+        <term><varname>MACVTAP=</varname></term>
+        <term><varname>Tunnel=</varname></term>
+        <term><varname>VLAN=</varname></term>
+        <term><varname>VXLAN=</varname></term>
+        <term><varname>Xfrm=</varname></term>
+        <listitem>
+          <para>The name of an IPoIB, IPVLAN, IPVTAP, MACsec, MACVLAN, MACVTAP, tunnel, VLAN,
+          VXLAN, or Xfrm to be created on the link. See
+          <citerefentry><refentrytitle>systemd.netdev</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+          This option may be specified more than once.</para>
+
+          <xi:include href="version-info.xml" xpointer="v211"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ActiveSlave=</varname></term>
+        <listitem>
+          <para>Takes a boolean. Specifies the new active slave. The <literal>ActiveSlave=</literal>
+          option is only valid for following modes: <literal>active-backup</literal>,
+          <literal>balance-alb</literal>, and <literal>balance-tlb</literal>. Defaults to false.</para>
+
+        <xi:include href="version-info.xml" xpointer="v235"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>PrimarySlave=</varname></term>
+        <listitem>
+          <para>Takes a boolean. Specifies which slave is the primary device. The specified device will
+          always be the active slave while it is available. Only when the primary is off-line will
+          alternate devices be used.  This is useful when one slave is preferred over another, e.g.
+          when one slave has higher throughput than another. The <literal>PrimarySlave=</literal>
+          option is only valid for following modes: <literal>active-backup</literal>,
+          <literal>balance-alb</literal>, and <literal>balance-tlb</literal>. Defaults to false.</para>
+
+          <xi:include href="version-info.xml" xpointer="v235"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ConfigureWithoutCarrier=</varname></term>
+        <listitem>
+          <para>Takes a boolean. Allows networkd to configure a specific link even if it has no
+          carrier. Defaults to false. If enabled, and the <varname>IgnoreCarrierLoss=</varname> setting
+          is not explicitly set, then it is enabled as well.</para>
+
+          <xi:include href="version-info.xml" xpointer="v235"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>IgnoreCarrierLoss=</varname></term>
+        <listitem>
+          <para>Takes a boolean or a timespan. When true, <command>systemd-networkd</command> retains
+          both the static and dynamic configuration of the interface even if its carrier is lost. When
+          false, <command>systemd-networkd</command> drops both the static and dynamic configuration of
+          the interface. When a timespan is specified, <command>systemd-networkd</command> waits for
+          the specified timespan, and ignores the carrier loss if the link regain its carrier within
+          the timespan. Setting 0 seconds is equivalent to <literal>no</literal>, and
+          <literal>infinite</literal> is equivalent to <literal>yes</literal>.</para>
+
+          <para>Setting a finite timespan may be useful when e.g. in the following cases:
+          <itemizedlist>
+            <listitem>
+              <para>A wireless interface connecting to a network which has multiple access points with
+              the same SSID.</para>
+            </listitem>
+            <listitem>
+              <para>Enslaving a wireless interface to a bond interface, which may disconnect from the
+              connected access point and causes its carrier to be lost.</para>
+            </listitem>
+            <listitem>
+              <para>The driver of the interface resets when the MTU is changed.</para>
+            </listitem>
+          </itemizedlist>
+          </para>
+
+          <para>When <varname>Bond=</varname> is specified to a wireless interface, defaults to 3
+          seconds. When the DHCPv4 client is enabled and <varname>UseMTU=</varname> in the [DHCPv4]
+          section enabled, defaults to 5 seconds. Otherwise, defaults to the value specified with
+          <varname>ConfigureWithoutCarrier=</varname>. When <varname>ActivationPolicy=</varname> is set
+          to <literal>always-up</literal>, this is forced to <literal>yes</literal>, and ignored any
+          user specified values.</para>
+
+          <xi:include href="version-info.xml" xpointer="v242"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>KeepConfiguration=</varname></term>
+        <listitem>
+          <para>Takes a boolean or one of <literal>static</literal>, <literal>dhcp-on-stop</literal>,
+          <literal>dhcp</literal>. When <literal>static</literal>, <command>systemd-networkd</command>
+          will not drop static addresses and routes on starting up process. When set to
+          <literal>dhcp-on-stop</literal>, <command>systemd-networkd</command> will not drop addresses
+          and routes on stopping the daemon. When <literal>dhcp</literal>,
+          the addresses and routes provided by a DHCP server will never be dropped even if the DHCP
+          lease expires. This is contrary to the DHCP specification, but may be the best choice if,
+          e.g., the root filesystem relies on this connection. The setting <literal>dhcp</literal>
+          implies <literal>dhcp-on-stop</literal>, and <literal>yes</literal> implies
+          <literal>dhcp</literal> and <literal>static</literal>. Defaults to
+          <literal>dhcp-on-stop</literal> when <command>systemd-networkd</command> is running in
+          initrd, <literal>yes</literal> when the root filesystem is a network filesystem, and
+          <literal>no</literal> otherwise.</para>
+
+        <xi:include href="version-info.xml" xpointer="v243"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[Address] Section Options</title>
+
+    <para>An [Address] section accepts the following keys. Specify several [Address] sections to
+    configure several addresses.</para>
+
+    <variablelist class='network-directives'>
+      <varlistentry>
+        <term><varname>Address=</varname></term>
+        <listitem>
+          <para>As in the [Network] section. This setting is mandatory. Each [Address] section can
+          contain one <varname>Address=</varname> setting.</para>
+
+          <xi:include href="version-info.xml" xpointer="v211"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Peer=</varname></term>
+        <listitem>
+          <para>The peer address in a point-to-point connection. Accepts the same format as the
+          <varname>Address=</varname> setting.</para>
+
+          <xi:include href="version-info.xml" xpointer="v216"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Broadcast=</varname></term>
+        <listitem>
+          <para>Takes an IPv4 address or boolean value. The address must be in the format described in
+          <citerefentry project='man-pages'><refentrytitle>inet_pton</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+          If set to true, then the IPv4 broadcast address will be derived from the
+          <varname>Address=</varname> setting. If set to false, then the broadcast address will not be
+          set. Defaults to true, except for wireguard interfaces, where it default to false.</para>
+
+          <xi:include href="version-info.xml" xpointer="v211"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Label=</varname></term>
+        <listitem>
+          <para>Specifies the label for the IPv4 address. The label must be a 7-bit ASCII string with
+          a length of 1…15 characters. Defaults to unset.</para>
+
+          <xi:include href="version-info.xml" xpointer="v211"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>PreferredLifetime=</varname></term>
+        <listitem>
+          <para>Allows the default "preferred lifetime" of the address to be overridden. Only three
+          settings are accepted: <literal>forever</literal>, <literal>infinity</literal>, which is the
+          default and means that the address never expires, and <literal>0</literal>, which means that
+          the address is considered immediately "expired" and will not be used, unless explicitly
+          requested. A setting of <option>PreferredLifetime=0</option> is useful for addresses which
+          are added to be used only by a specific application, which is then configured to use them
+          explicitly.</para>
+
+          <xi:include href="version-info.xml" xpointer="v230"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Scope=</varname></term>
+        <listitem>
+          <para>The scope of the address, which can be <literal>global</literal> (valid everywhere on
+          the network, even through a gateway), <literal>link</literal> (only valid on this device,
+          will not traverse a gateway) or <literal>host</literal> (only valid within the device itself,
+          e.g. 127.0.0.1) or an integer in the range 0…255. Defaults to <literal>global</literal>.
+          IPv4 only - IPv6 scope is automatically assigned by the kernel and cannot be set manually.
+          </para>
+
+        <xi:include href="version-info.xml" xpointer="v235"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RouteMetric=</varname></term>
+        <listitem>
+          <para>The metric of the prefix route, which is pointing to the subnet of the configured IP
+          address, taking the configured prefix length into account. Takes an unsigned integer in the
+          range 0…4294967295. When unset or set to 0, the kernel's default value is used. This
+          setting will be ignored when <varname>AddPrefixRoute=</varname> is false.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>HomeAddress=</varname></term>
+        <listitem>
+          <para>Takes a boolean. Designates this address the "home address" as defined in
+          <ulink url="https://tools.ietf.org/html/rfc6275">RFC 6275</ulink>. Supported only on IPv6.
+          Defaults to false.</para>
+
+          <xi:include href="version-info.xml" xpointer="v232"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>DuplicateAddressDetection=</varname></term>
+        <listitem>
+          <para>Takes one of <literal>ipv4</literal>, <literal>ipv6</literal>, <literal>both</literal>,
+          or <literal>none</literal>. When <literal>ipv4</literal>, performs IPv4 Address Conflict
+          Detection. See <ulink url="https://tools.ietf.org/html/rfc5227">RFC 5227</ulink>.
+          When <literal>ipv6</literal>, performs IPv6 Duplicate Address Detection. See
+          <ulink url="https://tools.ietf.org/html/rfc4862">RFC 4862</ulink>. Defaults to
+          <literal>ipv4</literal> for IPv4 link-local addresses, <literal>ipv6</literal> for IPv6
+          addresses, and <literal>none</literal> otherwise.</para>
+
+        <xi:include href="version-info.xml" xpointer="v232"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ManageTemporaryAddress=</varname></term>
+        <listitem>
+          <para>Takes a boolean. If true the kernel manage temporary addresses created from this one as
+          template on behalf of Privacy Extensions
+          <ulink url="https://tools.ietf.org/html/rfc3041">RFC 3041</ulink>. For this to become active,
+          the use_tempaddr sysctl setting has to be set to a value greater than zero. The given address
+          needs to have a prefix length of 64. This flag allows using privacy extensions in a manually
+          configured network, just like if stateless auto-configuration was active. Defaults to false.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v232"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>AddPrefixRoute=</varname></term>
+        <listitem>
+          <para>Takes a boolean. When true, the prefix route for the address is automatically added.
+          Defaults to true.</para>
+
+          <xi:include href="version-info.xml" xpointer="v245"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>AutoJoin=</varname></term>
+        <listitem>
+          <para>Takes a boolean. Joining multicast group on ethernet level via
+          <command>ip maddr</command> command would not work if we have an Ethernet switch that does
+          IGMP snooping since the switch would not replicate multicast packets on  ports that did not
+          have IGMP reports for the multicast addresses. Linux vxlan interfaces created via
+          <command>ip link add vxlan</command> or networkd's netdev kind vxlan have the group option
+          that enables them to do the required join. By extending <command>ip address</command> command
+          with option <literal>autojoin</literal> we can get similar functionality for openvswitch (OVS)
+          vxlan interfaces as well as other tunneling mechanisms that need to receive multicast traffic.
+          Defaults to <literal>no</literal>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v232"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>NetLabel=</varname><replaceable>label</replaceable></term>
+        <listitem>
+
+          <para>This setting provides a method for integrating static and dynamic network configuration into
+          Linux <ulink url="https://docs.kernel.org/netlabel/index.html">NetLabel</ulink> subsystem rules,
+          used by <ulink url="https://en.wikipedia.org/wiki/Linux_Security_Modules">Linux Security Modules
+          (LSMs)</ulink> for network access control. The label, with suitable LSM rules, can be used to
+          control connectivity of (for example) a service with peers in the local network. At least with
+          SELinux, only the ingress can be controlled but not egress. The benefit of using this setting is
+          that it may be possible to apply interface independent part of NetLabel configuration at very early
+          stage of system boot sequence, at the time when the network interfaces are not available yet, with
+          <citerefentry
+          project='man-pages'><refentrytitle>netlabelctl</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+          and the per-interface configuration with <command>systemd-networkd</command> once the interfaces
+          appear later. Currently this feature is only implemented for SELinux.</para>
+
+          <para>The option expects a single NetLabel label. The label must conform to lexical restrictions of
+          LSM labels. When an interface is configured with IP addresses, the addresses and subnetwork masks
+          will be appended to the <ulink
+          url="https://github.com/SELinuxProject/selinux-notebook/blob/main/src/network_support.md">NetLabel
+          Fallback Peer Labeling</ulink> rules. They will be removed when the interface is
+          deconfigured. Failures to manage the labels will be ignored.</para>
+
+          <para>Warning: Once labeling is enabled for network traffic, a lot of LSM access control points in
+          Linux networking stack go from dormant to active. Care should be taken to avoid getting into a
+          situation where for example remote connectivity is broken, when the security policy hasn't been
+          updated to consider LSM per-packet access controls and no rules would allow any network
+          traffic. Also note that additional configuration with <citerefentry
+          project='man-pages'><refentrytitle>netlabelctl</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+          is needed.</para>
+
+          <para>Example:
+          <programlisting>[Address]
+NetLabel=system_u:object_r:localnet_peer_t:s0</programlisting>
+
+          With the example rules applying for interface <literal>eth0</literal>, when the interface is
+          configured with an IPv4 address of 10.0.0.123/8, <command>systemd-networkd</command> performs the
+          equivalent of <command>netlabelctl</command> operation
+
+          <programlisting>netlabelctl unlbl add interface eth0 address:10.0.0.0/8 label:system_u:object_r:localnet_peer_t:s0</programlisting>
+
+          and the reverse operation when the IPv4 address is deconfigured. The configuration can be used with
+          LSM rules; in case of SELinux to allow a SELinux domain to receive data from objects of SELinux
+          <literal>peer</literal> class. For example:
+
+          <programlisting>type localnet_peer_t;
+allow my_server_t localnet_peer_t:peer recv;</programlisting>
+
+          The effect of the above configuration and rules (in absence of other rules as may be the case) is
+          to only allow <literal>my_server_t</literal> (and nothing else) to receive data from local subnet
+          10.0.0.0/8 of interface <literal>eth0</literal>.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v252"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>NFTSet=</varname><replaceable>source</replaceable>:<replaceable>family</replaceable>:<replaceable>table</replaceable>:<replaceable>set</replaceable></term>
+        <listitem>
+          <para>This setting provides a method for integrating network configuration into firewall rules with
+          <ulink url="https://netfilter.org/projects/nftables/index.html">NFT</ulink> sets. The benefit of
+          using the setting is that static network configuration (or dynamically obtained network addresses,
+          see similar directives in other sections) can be used in firewall rules with the indirection of NFT
+          set types. For example, access could be granted for hosts in the local subnetwork only. Firewall
+          rules using IP address of an interface are also instantly updated when the network configuration
+          changes, for example via DHCP.</para>
+
+          <para>This option expects a whitespace separated list of NFT set definitions. Each definition
+          consists of a colon-separated tuple of source type (one of <literal>address</literal>,
+          <literal>prefix</literal> or <literal>ifindex</literal>), NFT address family (one of
+          <literal>arp</literal>, <literal>bridge</literal>, <literal>inet</literal>, <literal>ip</literal>,
+          <literal>ip6</literal>, or <literal>netdev</literal>), table name and set name. The names of tables
+          and sets must conform to lexical restrictions of NFT table names. The type of the element used in
+          the NFT filter must match the type implied by the directive (<literal>address</literal>,
+          <literal>prefix</literal> or <literal>ifindex</literal>) and address type (IPv4 or IPv6) as shown
+          in the table below.</para>
+
+          <table>
+            <title>Defined <varname>source type</varname> values</title>
+            <tgroup cols='3'>
+              <colspec colname='source type'/>
+              <colspec colname='description'/>
+              <colspec colname='NFT type name'/>
+              <thead>
+                <row>
+                  <entry>Source type</entry>
+                  <entry>Description</entry>
+                  <entry>Corresponding NFT type name</entry>
+                </row>
+              </thead>
+
+              <tbody>
+                <row>
+                  <entry><literal>address</literal></entry>
+                  <entry>host IP address</entry>
+                  <entry><literal>ipv4_addr</literal> or <literal>ipv6_addr</literal></entry>
+                </row>
+                <row>
+                  <entry><literal>prefix</literal></entry>
+                  <entry>network prefix</entry>
+                  <entry><literal>ipv4_addr</literal> or <literal>ipv6_addr</literal>, with <literal>flags interval</literal></entry>
+                </row>
+                <row>
+                  <entry><literal>ifindex</literal></entry>
+                  <entry>interface index</entry>
+                  <entry><literal>iface_index</literal></entry>
+                </row>
+              </tbody>
+            </tgroup>
+          </table>
+
+          <para>When an interface is configured with IP addresses, the addresses, subnetwork masks or
+          interface index will be appended to the NFT sets. The information will be removed when the
+          interface is deconfigured. <command>systemd-networkd</command> only inserts elements to (or removes
+          from) the sets, so the related NFT rules, tables and sets must be prepared elsewhere in
+          advance. Failures to manage the sets will be ignored.</para>
+
+          <para>Example:
+          <programlisting>[Address]
+NFTSet=prefix:netdev:filter:eth_ipv4_prefix</programlisting>
+          Corresponding NFT rules:
+          <programlisting>table netdev filter {
+        set eth_ipv4_prefix {
+                type ipv4_addr
+                flags interval
+        }
+        chain eth_ingress {
+                type filter hook ingress device "eth0" priority filter; policy drop;
+                ip daddr != @eth_ipv4_prefix drop
+                accept
+        }
+}</programlisting>
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v255"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[Neighbor] Section Options</title>
+
+    <para>A [Neighbor] section accepts the following keys. The neighbor section adds a permanent,
+    static entry to the neighbor table (IPv6) or ARP table (IPv4) for the given hardware address on the
+    links matched for the network. Specify several [Neighbor] sections to configure several static
+    neighbors.</para>
+
+    <variablelist class='network-directives'>
+      <varlistentry>
+        <term><varname>Address=</varname></term>
+        <listitem>
+          <para>The IP address of the neighbor.</para>
+
+        <xi:include href="version-info.xml" xpointer="v240"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>LinkLayerAddress=</varname></term>
+        <listitem>
+          <para>The link layer address (MAC address or IP address) of the neighbor.</para>
+
+        <xi:include href="version-info.xml" xpointer="v243"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[IPv6AddressLabel] Section Options</title>
+
+    <para>An [IPv6AddressLabel] section accepts the following keys. Specify several [IPv6AddressLabel]
+    sections to configure several address labels. IPv6 address labels are used for address selection.
+    See <ulink url="https://tools.ietf.org/html/rfc3484">RFC 3484</ulink>. Precedence is managed by
+    userspace, and only the label itself is stored in the kernel.</para>
+
+    <variablelist class='network-directives'>
+      <varlistentry>
+        <term><varname>Label=</varname></term>
+        <listitem>
+          <para>The label for the prefix, an unsigned integer in the range 0…4294967294. 0xffffffff is
+          reserved. This setting is mandatory.</para>
+
+          <xi:include href="version-info.xml" xpointer="v234"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Prefix=</varname></term>
+        <listitem>
+          <para>IPv6 prefix is an address with a prefix length, separated by a slash
+          <literal>/</literal> character. This setting is mandatory. </para>
+
+          <xi:include href="version-info.xml" xpointer="v234"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[RoutingPolicyRule] Section Options</title>
+
+    <para>An [RoutingPolicyRule] section accepts the following settings. Specify several
+    [RoutingPolicyRule] sections to configure several rules.</para>
+
+    <variablelist class='network-directives'>
+      <varlistentry>
+        <term><varname>TypeOfService=</varname></term>
+        <listitem>
+          <para>
+            This specifies the Type of Service (ToS) field of packets to match;
+            it takes an unsigned integer in the range 0…255.
+            The field can be used to specify precedence (the first 3 bits) and ToS (the next 3 bits).
+            The field can be also used to specify Differentiated Services Code Point (DSCP) (the first 6 bits) and
+            Explicit Congestion Notification (ECN) (the last 2 bits).
+            See <ulink url="https://en.wikipedia.org/wiki/Type_of_service">Type of Service</ulink>
+            and <ulink url="https://en.wikipedia.org/wiki/Differentiated_services">Differentiated services</ulink>
+            for more details.
+          </para>
+
+            <xi:include href="version-info.xml" xpointer="v235"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>From=</varname></term>
+        <listitem>
+          <para>Specifies the source address prefix to match. Possibly followed by a slash and the
+          prefix length.</para>
+
+          <xi:include href="version-info.xml" xpointer="v235"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>To=</varname></term>
+        <listitem>
+          <para>Specifies the destination address prefix to match. Possibly followed by a slash and the
+          prefix length.</para>
+
+          <xi:include href="version-info.xml" xpointer="v235"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>FirewallMark=</varname></term>
+        <listitem>
+          <para>Specifies the iptables firewall mark value to match (a number in the range
+          1…4294967295). Optionally, the firewall mask (also a number between 1…4294967295) can be
+          suffixed with a slash (<literal>/</literal>), e.g., <literal>7/255</literal>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v235"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Table=</varname></term>
+        <listitem>
+          <para>Specifies the routing table identifier to look up if the rule selector matches. Takes
+          one of predefined names <literal>default</literal>, <literal>main</literal>, and
+          <literal>local</literal>, and names defined in <varname>RouteTable=</varname> in
+          <citerefentry><refentrytitle>networkd.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+          or a number between 1 and 4294967295. Defaults to <literal>main</literal>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v235"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Priority=</varname></term>
+        <listitem>
+          <para>Specifies the priority of this rule. <varname>Priority=</varname> is an integer in the
+          range 0…4294967295. Higher number means lower priority, and rules get processed in order of
+          increasing number. Defaults to unset, and the kernel will pick a value dynamically.</para>
+
+        <xi:include href="version-info.xml" xpointer="v235"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>IncomingInterface=</varname></term>
+        <listitem>
+          <para>Specifies incoming device to match. If the interface is loopback, the rule only matches
+          packets originating from this host.</para>
+
+          <xi:include href="version-info.xml" xpointer="v236"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>OutgoingInterface=</varname></term>
+        <listitem>
+          <para>Specifies the outgoing device to match. The outgoing interface is only available for
+          packets originating from local sockets that are bound to a device.</para>
+
+          <xi:include href="version-info.xml" xpointer="v236"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SourcePort=</varname></term>
+        <listitem>
+          <para>Specifies the source IP port or IP port range match in forwarding information base
+          (FIB) rules. A port range is specified by the lower and upper port separated by a dash.
+          Defaults to unset.</para>
+
+          <xi:include href="version-info.xml" xpointer="v240"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>DestinationPort=</varname></term>
+        <listitem>
+          <para>Specifies the destination IP port or IP port range match in forwarding information base
+          (FIB) rules. A port range is specified by the lower and upper port separated by a dash.
+          Defaults to unset.</para>
+
+          <xi:include href="version-info.xml" xpointer="v240"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>IPProtocol=</varname></term>
+        <listitem>
+          <para>Specifies the IP protocol to match in forwarding information base (FIB) rules. Takes IP
+          protocol name such as <literal>tcp</literal>, <literal>udp</literal> or
+          <literal>sctp</literal>, or IP protocol number such as <literal>6</literal> for
+          <literal>tcp</literal> or <literal>17</literal> for <literal>udp</literal>. Defaults to unset.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v240"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>InvertRule=</varname></term>
+        <listitem>
+          <para>A boolean. Specifies whether the rule is to be inverted. Defaults to false.</para>
+
+        <xi:include href="version-info.xml" xpointer="v240"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Family=</varname></term>
+        <listitem>
+          <para>Takes a special value <literal>ipv4</literal>, <literal>ipv6</literal>, or
+          <literal>both</literal>. By default, the address family is determined by the address
+          specified in <varname>To=</varname> or <varname>From=</varname>. If neither
+          <varname>To=</varname> nor <varname>From=</varname> are specified, then defaults to
+          <literal>ipv4</literal>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v243"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>User=</varname></term>
+        <listitem>
+          <para>Takes a username, a user ID, or a range of user IDs separated by a dash. Defaults to
+          unset.</para>
+
+          <xi:include href="version-info.xml" xpointer="v245"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SuppressPrefixLength=</varname></term>
+        <listitem>
+          <para>Takes a number <replaceable>N</replaceable> in the range 0…128 and rejects routing
+          decisions that have a prefix length of <replaceable>N</replaceable> or less. Defaults to
+          unset.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SuppressInterfaceGroup=</varname></term>
+        <listitem>
+          <para>Takes an integer in the range 0…2147483647 and rejects routing decisions that have
+          an interface with the same group id. It has the same meaning as
+          <option>suppress_ifgroup</option> in <command>ip rule</command>. Defaults to unset.</para>
+
+          <xi:include href="version-info.xml" xpointer="v250"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Type=</varname></term>
+        <listitem>
+          <para>Specifies Routing Policy Database (RPDB) rule type. Takes one of
+          <literal>blackhole</literal>, <literal>unreachable</literal> or <literal>prohibit</literal>.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v248"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[NextHop] Section Options</title>
+
+    <para>The [NextHop] section is used to manipulate entries in the kernel's "nexthop" tables. The
+    [NextHop] section accepts the following settings. Specify several [NextHop] sections to configure
+    several hops.</para>
+
+    <variablelist class='network-directives'>
+      <varlistentry>
+        <term><varname>Id=</varname></term>
+        <listitem>
+          <para>The id of the next hop. Takes an integer in the range 1…4294967295. If unspecified,
+          then automatically chosen by kernel.</para>
+
+          <xi:include href="version-info.xml" xpointer="v244"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Gateway=</varname></term>
+        <listitem>
+          <para>As in the [Network] section.</para>
+
+        <xi:include href="version-info.xml" xpointer="v244"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Family=</varname></term>
+        <listitem>
+          <para>Takes one of the special values <literal>ipv4</literal> or <literal>ipv6</literal>.
+          By default, the family is determined by the address specified in
+          <varname>Gateway=</varname>. If <varname>Gateway=</varname> is not specified, then defaults
+          to <literal>ipv4</literal>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v248"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>OnLink=</varname></term>
+        <listitem>
+          <para>Takes a boolean. If set to true, the kernel does not have to check if the gateway is
+          reachable directly by the current machine (i.e., attached to the local network), so that we
+          can insert the nexthop in the kernel table without it being complained about. Defaults to
+          <literal>no</literal>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v248"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Blackhole=</varname></term>
+        <listitem>
+          <para>Takes a boolean. If enabled, packets to the corresponding routes are discarded
+          silently, and <varname>Gateway=</varname> cannot be specified. Defaults to
+          <literal>no</literal>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v248"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Group=</varname></term>
+        <listitem>
+          <para>Takes a whitespace separated list of nexthop IDs. Each ID must be in the range
+          1…4294967295. Optionally, each nexthop ID can take a weight after a colon
+          (<literal><replaceable>id</replaceable><optional>:<replaceable>weight</replaceable></optional></literal>).
+          The weight must be in the range 1…255. If the weight is not specified, then it is assumed
+          that the weight is 1. This setting cannot be specified with <varname>Gateway=</varname>,
+          <varname>Family=</varname>, <varname>Blackhole=</varname>. This setting can be specified
+          multiple times. If an empty string is assigned, then the all previous assignments are
+          cleared. Defaults to unset.</para>
+
+          <xi:include href="version-info.xml" xpointer="v249"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[Route] Section Options</title>
+
+    <para>The [Route] section accepts the following settings. Specify several [Route] sections to
+    configure several routes.</para>
+
+    <variablelist class='network-directives'>
+      <varlistentry>
+        <term><varname>Gateway=</varname></term>
+        <listitem>
+          <para>Takes the gateway address or the special values <literal>_dhcp4</literal> and
+          <literal>_ipv6ra</literal>. If <literal>_dhcp4</literal> or <literal>_ipv6ra</literal> is
+          set, then the gateway address provided by DHCPv4 or IPv6 RA is used.</para>
+
+        <xi:include href="version-info.xml" xpointer="v211"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>GatewayOnLink=</varname></term>
+        <listitem>
+          <para>Takes a boolean. If set to true, the kernel does not have to check if the gateway is
+          reachable directly by the current machine (i.e., attached to the local network), so that we
+          can insert the route in the kernel table without it being complained about. Defaults to
+          <literal>no</literal>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v234"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Destination=</varname></term>
+        <listitem>
+          <para>The destination prefix of the route. Possibly followed by a slash and the prefix
+          length. If omitted, a full-length host route is assumed.</para>
+
+          <xi:include href="version-info.xml" xpointer="v211"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Source=</varname></term>
+        <listitem>
+          <para>The source prefix of the route. Possibly followed by a slash and the prefix length. If
+          omitted, a full-length host route is assumed.</para>
+
+          <xi:include href="version-info.xml" xpointer="v218"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Metric=</varname></term>
+        <listitem>
+          <para>The metric of the route. Takes an unsigned integer in the range 0…4294967295. Defaults
+          to unset, and the kernel's default will be used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v216"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>IPv6Preference=</varname></term>
+        <listitem>
+          <para>Specifies the route preference as defined in
+          <ulink url="https://tools.ietf.org/html/rfc4191">RFC 4191</ulink> for Router Discovery
+          messages. Which can be one of <literal>low</literal> the route has a lowest priority,
+          <literal>medium</literal> the route has a default priority or <literal>high</literal> the
+          route has a highest priority.</para>
+
+          <xi:include href="version-info.xml" xpointer="v234"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Scope=</varname></term>
+        <listitem>
+          <para>The scope of the IPv4 route, which can be <literal>global</literal>,
+          <literal>site</literal>, <literal>link</literal>, <literal>host</literal>, or
+          <literal>nowhere</literal>:</para>
+          <itemizedlist>
+            <listitem>
+              <para><literal>global</literal> means the route can reach hosts more than one hop away.
+              </para>
+            </listitem>
+
+            <listitem>
+              <para><literal>site</literal> means an interior route in the local autonomous system.
+              </para>
+            </listitem>
+
+            <listitem>
+              <para><literal>link</literal> means the route can only reach hosts on the local network
+              (one hop away).</para>
+            </listitem>
+
+            <listitem>
+              <para><literal>host</literal> means the route will not leave the local machine (used for
+              internal addresses like 127.0.0.1).</para>
+            </listitem>
+
+            <listitem>
+              <para><literal>nowhere</literal> means the destination doesn't exist.</para>
+            </listitem>
+          </itemizedlist>
+
+          <para>For IPv4 route, defaults to <literal>host</literal> if <varname>Type=</varname> is
+          <literal>local</literal> or <literal>nat</literal>, and <literal>link</literal> if
+          <varname>Type=</varname> is <literal>broadcast</literal>, <literal>multicast</literal>,
+          <literal>anycast</literal>, or <literal>unicast</literal>. In other cases,
+          defaults to <literal>global</literal>. The value is not used for IPv6.</para>
+
+          <xi:include href="version-info.xml" xpointer="v219"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>PreferredSource=</varname></term>
+        <listitem>
+          <para>The preferred source address of the route. The address must be in the format described
+          in
+          <citerefentry project='man-pages'><refentrytitle>inet_pton</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v227"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Table=</varname></term>
+        <listitem>
+          <para>The table identifier for the route. Takes one of predefined names
+          <literal>default</literal>, <literal>main</literal>, and <literal>local</literal>, and names
+          defined in <varname>RouteTable=</varname> in
+          <citerefentry><refentrytitle>networkd.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+          or a number between 1 and 4294967295. The table can be retrieved using
+          <command>ip route show table <replaceable>num</replaceable></command>. If unset and
+          <varname>Type=</varname> is <literal>local</literal>, <literal>broadcast</literal>,
+          <literal>anycast</literal>, or <literal>nat</literal>, then <literal>local</literal> is used.
+          In other cases, defaults to <literal>main</literal>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v230"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>HopLimit=</varname></term>
+        <listitem>
+          <para>Configures per route hop limit. Takes an integer in the range 1…255. See also
+          <varname>IPv6HopLimit=</varname>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v255"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Protocol=</varname></term>
+        <listitem>
+          <para>The protocol identifier for the route. Takes a number between 0 and 255 or the special
+          values <literal>kernel</literal>, <literal>boot</literal>, <literal>static</literal>,
+          <literal>ra</literal> and <literal>dhcp</literal>. Defaults to <literal>static</literal>.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v234"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Type=</varname></term>
+        <listitem>
+          <para>Specifies the type for the route. Takes one of <literal>unicast</literal>,
+          <literal>local</literal>, <literal>broadcast</literal>, <literal>anycast</literal>,
+          <literal>multicast</literal>, <literal>blackhole</literal>, <literal>unreachable</literal>,
+          <literal>prohibit</literal>, <literal>throw</literal>, <literal>nat</literal>, and
+          <literal>xresolve</literal>. If <literal>unicast</literal>, a regular route is defined, i.e.
+          a route indicating the path to take to a destination network address. If
+          <literal>blackhole</literal>, packets to the defined route are discarded silently. If
+          <literal>unreachable</literal>, packets to the defined route are discarded and the ICMP
+          message "Host Unreachable" is generated. If <literal>prohibit</literal>, packets to the
+          defined route are discarded and the ICMP message "Communication Administratively Prohibited"
+          is generated. If <literal>throw</literal>, route lookup in the current routing table will
+          fail and the route selection process will return to Routing Policy Database (RPDB). Defaults
+          to <literal>unicast</literal>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v235"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>InitialCongestionWindow=</varname></term>
+        <listitem>
+          <para>The TCP initial congestion window is used during the start of a TCP connection.
+          During the start of a TCP session, when a client requests a resource, the server's initial
+          congestion window determines how many packets will be sent during the initial burst of data
+          without waiting for acknowledgement. Takes a number between 1 and 1023. Note that 100 is
+          considered an extremely large value for this option. When unset, the kernel's default
+          (typically 10) will be used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v237"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>InitialAdvertisedReceiveWindow=</varname></term>
+        <listitem>
+          <para>The TCP initial advertised receive window is the amount of receive data (in bytes)
+          that can initially be buffered at one time on a connection. The sending host can send only
+          that amount of data before waiting for an acknowledgment and window update from the
+          receiving host. Takes a number between 1 and 1023. Note that 100 is considered an extremely
+          large value for this option. When unset, the kernel's default will be used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v237"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>QuickAck=</varname></term>
+        <listitem>
+          <para>Takes a boolean. When true, the TCP quick ACK mode for the route is enabled. When unset,
+          the kernel's default will be used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v237"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>FastOpenNoCookie=</varname></term>
+        <listitem>
+          <para>Takes a boolean. When true enables TCP fastopen without a cookie on a per-route basis.
+          When unset, the kernel's default will be used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v243"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>TTLPropagate=</varname></term>
+        <listitem>
+          <para>Takes a boolean. When true enables TTL propagation at Label Switched Path (LSP) egress.
+          When unset, the kernel's default will be used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v243"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>MTUBytes=</varname></term>
+        <listitem>
+          <para>The maximum transmission unit in bytes to set for the route. The usual suffixes K, M,
+          G, are supported and are understood to the base of 1024.</para>
+
+          <xi:include href="version-info.xml" xpointer="v239"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>TCPAdvertisedMaximumSegmentSize=</varname></term>
+        <listitem>
+          <para>Specifies the Path MSS (in bytes) hints given on TCP layer. The usual suffixes K, M, G,
+          are supported and are understood to the base of 1024. An unsigned integer in the range
+          1…4294967294. When unset, the kernel's default will be used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v248"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>TCPCongestionControlAlgorithm=</varname></term>
+        <listitem>
+          <para>Specifies the TCP congestion control algorithm for the route. Takes a name of the algorithm,
+          e.g. <literal>bbr</literal>, <literal>dctcp</literal>, or <literal>vegas</literal>. When unset,
+          the kernel's default will be used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v252"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>TCPRetransmissionTimeoutSec=</varname></term>
+        <listitem>
+          <para>Specifies the TCP Retransmission Timeout (RTO) for the route. Takes time values in seconds.
+          This value specifies the timeout of an alive TCP connection, when retransmissions remain
+          unacknowledged. When unset, the kernel's default will be used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v255"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>MultiPathRoute=<replaceable>address</replaceable>[@<replaceable>name</replaceable>] [<replaceable>weight</replaceable>]</varname></term>
+        <listitem>
+          <para>Configures multipath route. Multipath routing is the technique of using multiple
+          alternative paths through a network. Takes gateway address. Optionally, takes a network
+          interface name or index separated with <literal>@</literal>, and a weight in 1..256 for this
+          multipath route separated with whitespace. This setting can be specified multiple times. If
+          an empty string is assigned, then the all previous assignments are cleared.</para>
+
+          <xi:include href="version-info.xml" xpointer="v245"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>NextHop=</varname></term>
+        <listitem>
+          <para>Specifies the nexthop id. Takes an unsigned integer in the range 1…4294967295. If set,
+          the corresponding [NextHop] section must be configured. Defaults to unset.</para>
+
+          <xi:include href="version-info.xml" xpointer="v248"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[DHCPv4] Section Options</title>
+
+    <para>The [DHCPv4] section configures the DHCPv4 client, if it is enabled with the
+    <varname>DHCP=</varname> setting described above:</para>
+
+    <variablelist class='network-directives'>
+
+      <!-- DHCP packet contents -->
+
+      <varlistentry>
+        <term><varname>RequestAddress=</varname></term>
+        <listitem>
+          <para>Takes an IPv4 address. When specified, the Requested IP Address option (option code 50) is
+          added with it to the initial DHCPDISCOVER message sent by the DHCP client. Defaults to unset, and
+          an already assigned dynamic address to the interface is automatically picked.</para>
+
+          <xi:include href="version-info.xml" xpointer="v255"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SendHostname=</varname></term>
+        <listitem>
+          <para>When true (the default), the machine's hostname (or the value specified with
+          <varname>Hostname=</varname>, described below) will be sent to the DHCP server. Note that the
+          hostname must consist only of 7-bit ASCII lower-case characters and no spaces or dots, and be
+          formatted as a valid DNS domain name. Otherwise, the hostname is not sent even if this option
+          is true.</para>
+
+          <xi:include href="version-info.xml" xpointer="v215"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Hostname=</varname></term>
+        <listitem>
+          <para>Use this value for the hostname which is sent to the DHCP server, instead of machine's
+          hostname. Note that the specified hostname must consist only of 7-bit ASCII lower-case
+          characters and no spaces or dots, and be formatted as a valid DNS domain name.</para>
+
+          <xi:include href="version-info.xml" xpointer="v223"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>MUDURL=</varname></term>
+        <listitem>
+          <para>When configured, the specified Manufacturer Usage Description (MUD) URL will be sent
+          to the DHCPv4 server. Takes a URL of length up to 255 characters. A superficial verification
+          that the string is a valid URL will be performed. DHCPv4 clients are intended to have at most
+          one MUD URL associated with them. See
+          <ulink url="https://tools.ietf.org/html/rfc8520">RFC 8520</ulink>.</para>
+
+          <para>MUD is an embedded software standard defined by the IETF that allows IoT device makers
+          to advertise device specifications, including the intended communication patterns for their
+          device when it connects to the network. The network can then use this to author a
+          context-specific access policy, so the device functions only within those parameters.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ClientIdentifier=</varname></term>
+        <listitem>
+          <para>The DHCPv4 client identifier to use. Takes one of <option>mac</option> or
+          <option>duid</option>. If set to <option>mac</option>, the MAC address of the link is used. If set
+          to <option>duid</option>, an RFC4361-compliant Client ID, which is the combination of IAID and
+          DUID, is used. IAID can be configured by <varname>IAID=</varname>. DUID can be configured by
+          <varname>DUIDType=</varname> and <varname>DUIDRawData=</varname>. Defaults to
+          <option>duid</option>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v220"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>VendorClassIdentifier=</varname></term>
+        <listitem>
+          <para>The vendor class identifier used to identify vendor type and configuration.</para>
+
+        <xi:include href="version-info.xml" xpointer="v216"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>UserClass=</varname></term>
+        <listitem>
+          <para>A DHCPv4 client can use UserClass option to identify the type or category of user or
+          applications it represents. The information contained in this option is a string that
+          represents the user class of which the client is a member. Each class sets an identifying
+          string of information to be used by the DHCP service to classify clients. Takes a
+          whitespace-separated list of strings.</para>
+
+          <xi:include href="version-info.xml" xpointer="v239"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>DUIDType=</varname></term>
+        <listitem>
+          <para>Override the global <varname>DUIDType=</varname> setting for this network. See
+          <citerefentry><refentrytitle>networkd.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+          for a description of possible values.</para>
+
+        <xi:include href="version-info.xml" xpointer="v230"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>DUIDRawData=</varname></term>
+        <listitem>
+          <para>Override the global <varname>DUIDRawData=</varname> setting for this network. See
+          <citerefentry><refentrytitle>networkd.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+          for a description of possible values.</para>
+
+        <xi:include href="version-info.xml" xpointer="v230"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>IAID=</varname></term>
+        <listitem>
+          <para>The DHCP Identity Association Identifier (IAID) for the interface, a 32-bit unsigned
+          integer.</para>
+
+          <xi:include href="version-info.xml" xpointer="v230"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RapidCommit=</varname></term>
+        <listitem>
+          <para>Takes a boolean. The DHCPv4 client can obtain configuration parameters from a DHCPv4 server
+          through a rapid two-message exchange (discover and ack). When the rapid commit option is set by
+          both the DHCPv4 client and the DHCPv4 server, the two-message exchange is used. Otherwise, the
+          four-message exchange (discover, offer, request, and ack) is used. The two-message exchange
+          provides faster client configuration. See
+          <ulink url="https://tools.ietf.org/html/rfc4039">RFC 4039</ulink> for details.
+          Defaults to true when <varname>Anonymize=no</varname> and neither <varname>AllowList=</varname>
+          nor <varname>DenyList=</varname> is specified, and false otherwise.</para>
+
+          <xi:include href="version-info.xml" xpointer="v255"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Anonymize=</varname></term>
+        <listitem>
+          <para>Takes a boolean. When true, the options sent to the DHCP server will follow the
+          <ulink url="https://tools.ietf.org/html/rfc7844">RFC 7844</ulink> (Anonymity Profiles for
+          DHCP Clients) to minimize disclosure of identifying information. Defaults to false.</para>
+
+          <para>This option should only be set to true when <varname>MACAddressPolicy=</varname> is set
+          to <option>random</option> (see
+          <citerefentry><refentrytitle>systemd.link</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
+          </para>
+
+          <para>When true,
+          <varname>ClientIdentifier=mac</varname>,
+          <varname>RapidCommit=no</varname>,
+          <varname>SendHostname=no</varname>,
+          <varname>Use6RD=no</varname>,
+          <varname>UseCaptivePortal=no</varname>,
+          <varname>UseMTU=no</varname>,
+          <varname>UseNTP=no</varname>,
+          <varname>UseSIP=no</varname>, and
+          <varname>UseTimezone=no</varname>
+          are implied and these settings in the .network file are silently ignored. Also,
+          <varname>Hostname=</varname>,
+          <varname>MUDURL=</varname>,
+          <varname>RequestAddress</varname>,
+          <varname>RequestOptions=</varname>,
+          <varname>SendOption=</varname>,
+          <varname>SendVendorOption=</varname>,
+          <varname>UserClass=</varname>, and
+          <varname>VendorClassIdentifier=</varname>
+          are silently ignored.</para>
+
+          <para>With this option enabled DHCP requests will mimic those generated by Microsoft
+          Windows, in order to reduce the ability to fingerprint and recognize installations. This
+          means DHCP request sizes will grow and lease data will be more comprehensive than normally,
+          though most of the requested data is not actually used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v235"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RequestOptions=</varname></term>
+        <listitem>
+          <para>Sets request options to be sent to the server in the DHCPv4 request options list. A
+          whitespace-separated list of integers in the range 1…254. Defaults to unset.</para>
+
+          <xi:include href="version-info.xml" xpointer="v244"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SendOption=</varname></term>
+        <listitem>
+          <para>Send an arbitrary raw option in the DHCPv4 request. Takes a DHCP option number, data
+          type and data separated with a colon
+          (<literal><replaceable>option</replaceable>:<replaceable>type</replaceable>:<replaceable>value</replaceable></literal>).
+          The option number must be an integer in the range 1…254. The type takes one of
+          <literal>uint8</literal>, <literal>uint16</literal>, <literal>uint32</literal>,
+          <literal>ipv4address</literal>, or <literal>string</literal>. Special characters in the data
+          string may be escaped using
+          <ulink url="https://en.wikipedia.org/wiki/Escape_sequences_in_C#Table_of_escape_sequences">C-style
+          escapes</ulink>. This setting can be specified multiple times. If an empty string is
+          specified, then all options specified earlier are cleared. Defaults to unset.</para>
+
+          <xi:include href="version-info.xml" xpointer="v244"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SendVendorOption=</varname></term>
+        <listitem>
+          <para>Send an arbitrary vendor option in the DHCPv4 request. Takes a DHCP option number, data
+          type and data separated with a colon
+          (<literal><replaceable>option</replaceable>:<replaceable>type</replaceable>:<replaceable>value</replaceable></literal>).
+          The option number must be an integer in the range 1…254. The type takes one of
+          <literal>uint8</literal>, <literal>uint16</literal>, <literal>uint32</literal>,
+          <literal>ipv4address</literal>, or <literal>string</literal>. Special characters in the data
+          string may be escaped using
+          <ulink url="https://en.wikipedia.org/wiki/Escape_sequences_in_C#Table_of_escape_sequences">C-style
+          escapes</ulink>. This setting can be specified multiple times. If an empty string is specified,
+          then all options specified earlier are cleared. Defaults to unset.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>IPServiceType=</varname></term>
+        <listitem>
+          <para>Takes one of the special values <literal>none</literal>, <literal>CS6</literal>, or
+          <literal>CS4</literal>. When <literal>none</literal> no IP service type is set to the packet
+          sent from the DHCPv4 client. When <literal>CS6</literal> (network control) or
+          <literal>CS4</literal> (realtime), the corresponding service type will be set. Defaults to
+          <literal>CS6</literal>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v244"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SocketPriority=</varname></term>
+        <listitem>
+          <para>The Linux socket option <constant>SO_PRIORITY</constant> applied to the raw IP socket used for
+          initial DHCPv4 messages. Unset by default. Usual values range from 0 to 6.
+          More details about <constant>SO_PRIORITY</constant> socket option in
+          <citerefentry project='man-pages'><refentrytitle>socket</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
+          Can be used in conjunction with [VLAN] section <varname>EgressQOSMaps=</varname> setting of .netdev
+          file to set the 802.1Q VLAN ethernet tagged header priority, see
+          <citerefentry><refentrytitle>systemd.netdev</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+          </para>
+
+        <xi:include href="version-info.xml" xpointer="v253"/>
+        </listitem>
+      </varlistentry>
+
+      <!-- How to use the DHCP lease -->
+
+      <varlistentry>
+        <term><varname>Label=</varname></term>
+        <listitem>
+          <para>Specifies the label for the IPv4 address received from the DHCP server. The label must
+          be a 7-bit ASCII string with a length of 1…15 characters. Defaults to unset.</para>
+
+          <xi:include href="version-info.xml" xpointer="v250"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>UseDNS=</varname></term>
+        <listitem>
+          <para>When true (the default), the DNS servers received from the DHCP server will be used.
+          </para>
+
+          <para>This corresponds to the <option>nameserver</option> option in
+          <citerefentry project='man-pages'><refentrytitle>resolv.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v211"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RoutesToDNS=</varname></term>
+        <listitem>
+          <para>When true, the routes to the DNS servers received from the DHCP server will be
+          configured. When <varname>UseDNS=</varname> is disabled, this setting is ignored. Defaults to
+          true.</para>
+
+          <xi:include href="version-info.xml" xpointer="v243"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>UseNTP=</varname></term>
+        <listitem>
+          <para>When true (the default), the NTP servers received from the DHCP server will be used by
+          <filename>systemd-timesyncd.service</filename>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v220"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RoutesToNTP=</varname></term>
+        <listitem>
+          <para>When true, the routes to the NTP servers received from the DHCP server will be
+          configured. When <varname>UseNTP=</varname> is disabled, this setting is ignored. Defaults to
+          true.</para>
+
+          <xi:include href="version-info.xml" xpointer="v249"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>UseSIP=</varname></term>
+        <listitem>
+          <para>When true (the default), the SIP servers received from the DHCP server will be collected
+          and made available to client programs.</para>
+
+          <xi:include href="version-info.xml" xpointer="v244"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>UseCaptivePortal=</varname></term>
+        <listitem>
+          <para>When true (the default), the captive portal advertised by the DHCP server will be recorded
+          and made available to client programs and displayed in the
+          <citerefentry><refentrytitle>networkctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+          status output per-link.</para>
+
+          <xi:include href="version-info.xml" xpointer="v254"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>UseMTU=</varname></term>
+        <listitem>
+          <para>When true, the interface maximum transmission unit from the DHCP server will be used on
+          the current link. If <varname>MTUBytes=</varname> is set, then this setting is ignored.
+          Defaults to false.</para>
+
+          <para>Note, some drivers will reset the interfaces if the MTU is changed. For such
+          interfaces, please try to use <varname>IgnoreCarrierLoss=</varname> with a short timespan,
+          e.g. <literal>3 seconds</literal>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v211"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>UseHostname=</varname></term>
+        <listitem>
+          <para>When true (the default), the hostname received from the DHCP server will be set as the
+          transient hostname of the system.</para>
+
+          <xi:include href="version-info.xml" xpointer="v211"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>UseDomains=</varname></term>
+        <listitem>
+          <para>Takes a boolean, or the special value <option>route</option>. When true, the domain name
+          received from the DHCP server will be used as DNS search domain over this link, similarly to the
+          effect of the <option>Domains=</option> setting. If set to <option>route</option>, the domain name
+          received from the DHCP server will be used for routing DNS queries only, but not for searching,
+          similarly to the effect of the <option>Domains=</option> setting when the argument is prefixed with
+          <literal>~</literal>. Defaults to false.</para>
+
+          <para>It is recommended to enable this option only on trusted networks, as setting this
+          affects resolution of all hostnames, in particular of single-label names. It is generally
+          safer to use the supplied domain only as routing domain, rather than as search domain, in
+          order to not have it affect local resolution of single-label names.</para>
+
+          <para>When set to true, this setting corresponds to the <option>domain</option> option in
+          <citerefentry project='man-pages'><refentrytitle>resolv.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v216"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>UseRoutes=</varname></term>
+        <listitem>
+          <para>When true (the default), the static routes will be requested from the DHCP server and
+          added to the routing table with a metric of 1024, and a scope of <option>global</option>,
+          <option>link</option> or <option>host</option>, depending on the route's destination and
+          gateway. If the destination is on the local host, e.g., 127.x.x.x, or the same as the link's
+          own address, the scope will be set to <option>host</option>. Otherwise if the gateway is null
+          (a direct route), a <option>link</option> scope will be used. For anything else, scope
+          defaults to <option>global</option>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v215"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RouteMetric=</varname></term>
+        <listitem>
+          <para>Set the routing metric for routes specified by the DHCP server (including the prefix
+          route added for the specified prefix). Takes an unsigned integer in the range 0…4294967295.
+          Defaults to 1024.</para>
+
+          <xi:include href="version-info.xml" xpointer="v217"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RouteTable=<replaceable>num</replaceable></varname></term>
+        <listitem>
+          <para>The table identifier for DHCP routes. Takes one of predefined names
+          <literal>default</literal>, <literal>main</literal>, and <literal>local</literal>, and names
+          defined in <varname>RouteTable=</varname> in
+          <citerefentry><refentrytitle>networkd.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+          or a number between 1…4294967295.</para>
+
+          <para>When used in combination with <varname>VRF=</varname>, the VRF's routing table is
+          used when this parameter is not specified.</para>
+
+          <xi:include href="version-info.xml" xpointer="v232"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RouteMTUBytes=</varname></term>
+        <listitem>
+          <para>Specifies the MTU for the DHCP routes. Please see the [Route] section for further
+          details.</para>
+
+          <xi:include href="version-info.xml" xpointer="v245"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>QuickAck=</varname></term>
+        <listitem>
+          <para>Takes a boolean. When true, the TCP quick ACK mode is enabled for the routes configured by
+          the acquired DHCPv4 lease. When unset, the kernel's default will be used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v253"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>InitialCongestionWindow=</varname></term>
+        <listitem>
+          <para>As in the [Route] section.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>InitialAdvertisedReceiveWindow=</varname></term>
+        <listitem>
+          <para>As in the [Route] section.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>UseGateway=</varname></term>
+        <listitem>
+          <para>When true, and the DHCP server provides a Router option, the default gateway based on the
+          router address will be configured. Defaults to unset, and the value specified with
+          <varname>UseRoutes=</varname> will be used.</para>
+
+          <para>Note, when the server provides both the Router and Classless Static Routes option, and
+          <varname>UseRoutes=</varname> is enabled, the Router option is always ignored regardless of this
+          setting. See <ulink url="https://datatracker.ietf.org/doc/html/rfc3442">RFC 3442</ulink>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>UseTimezone=</varname></term>
+        <listitem><para>When true, the timezone received from the DHCP server will be set as timezone
+        of the local system. Defaults to false.</para>
+
+        <xi:include href="version-info.xml" xpointer="v226"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Use6RD=</varname></term>
+        <listitem>
+          <para>When true, subnets of the received IPv6 prefix are assigned to downstream interfaces
+          which enables <varname>DHCPPrefixDelegation=</varname>. See also
+          <varname>DHCPPrefixDelegation=</varname> in the [Network] section, the [DHCPPrefixDelegation]
+          section, and <ulink url="https://tools.ietf.org/html/rfc5969">RFC 5969</ulink>. Defaults to
+          false.</para>
+
+          <xi:include href="version-info.xml" xpointer="v250"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>IPv6OnlyMode=</varname></term>
+        <listitem>
+          <para>When true, the DHCPv4 configuration will be delayed by the timespan provided by the DHCP
+          server and skip to configure dynamic IPv4 network connectivity if IPv6 connectivity is provided
+          within the timespan. See <ulink url="https://tools.ietf.org/html/rfc8925">RFC 8925</ulink>.
+          Defaults to false.</para>
+
+          <xi:include href="version-info.xml" xpointer="v255"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>FallbackLeaseLifetimeSec=</varname></term>
+        <listitem>
+          <para>Allows one to set DHCPv4 lease lifetime when DHCPv4 server does not send the lease
+          lifetime. Takes one of <literal>forever</literal> or <literal>infinity</literal>. If
+          specified, the acquired address never expires. Defaults to unset.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+        </listitem>
+      </varlistentry>
+
+      <!-- How to communicate with the server -->
+
+      <varlistentry>
+        <term><varname>RequestBroadcast=</varname></term>
+        <listitem>
+          <para>Request the server to use broadcast messages before the IP address has been configured.
+          This is necessary for devices that cannot receive RAW packets, or that cannot receive packets
+          at all before an IP address has been configured. On the other hand, this must not be enabled
+          on networks where broadcasts are filtered out.</para>
+
+          <xi:include href="version-info.xml" xpointer="v216"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>MaxAttempts=</varname></term>
+        <listitem>
+          <para>Specifies how many times the DHCPv4 client configuration should be attempted. Takes a
+          number or <literal>infinity</literal>. Defaults to <literal>infinity</literal>. Note that the
+          time between retries is increased exponentially, up to approximately one per minute, so the
+          network will not be overloaded even if this number is high. The default is suitable in most
+          circumstances.</para>
+
+          <xi:include href="version-info.xml" xpointer="v243"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ListenPort=</varname></term>
+        <listitem>
+          <para>Set the port from which the DHCP client packets originate.</para>
+
+        <xi:include href="version-info.xml" xpointer="v233"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>DenyList=</varname></term>
+        <listitem>
+          <para>A whitespace-separated list of IPv4 addresses. Each address can optionally take a
+          prefix length after <literal>/</literal>. DHCP offers from servers in the list are rejected.
+          Note that if <varname>AllowList=</varname> is configured then <varname>DenyList=</varname> is
+          ignored.</para>
+          <para>Note that this filters only DHCP offers, so the filtering may not work when
+          <varname>RapidCommit=</varname> is enabled. See also <varname>RapidCommit=</varname> in the above.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>AllowList=</varname></term>
+        <listitem>
+          <para>A whitespace-separated list of IPv4 addresses. Each address can optionally take a
+          prefix length after <literal>/</literal>. DHCP offers from servers in the list are accepted.
+          </para>
+          <para>Note that this filters only DHCP offers, so the filtering may not work when
+          <varname>RapidCommit=</varname> is enabled. See also <varname>RapidCommit=</varname> in the above.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SendRelease=</varname></term>
+        <listitem>
+          <para>When true, the DHCPv4 client sends a DHCP release packet when it stops. Defaults to
+          true.</para>
+
+          <xi:include href="version-info.xml" xpointer="v243"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SendDecline=</varname></term>
+        <listitem>
+          <para>A boolean. When true, <command>systemd-networkd</command> performs IPv4 Duplicate
+          Address Detection to the acquired address by the DHCPv4 client. If duplicate is detected,
+          the DHCPv4 client rejects the address by sending a <constant>DHCPDECLINE</constant> packet to
+          the DHCP server, and tries to obtain an IP address again. See
+          <ulink url="https://tools.ietf.org/html/rfc5227">RFC 5227</ulink>. Defaults to false.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>NetLabel=</varname></term>
+        <listitem>
+          <para>This applies the NetLabel for the addresses received with DHCP, like
+          <varname>NetLabel=</varname> in [Address] section applies it to statically configured
+          addresses. See <varname>NetLabel=</varname> in [Address] section for more details.</para>
+
+          <xi:include href="version-info.xml" xpointer="v252"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>NFTSet=</varname></term>
+        <listitem>
+          <para>This applies the NFT set for the network configuration received with DHCP, like
+          <varname>NFTSet=</varname> in [Address] section applies it to static configuration. See
+          <varname>NFTSet=</varname> in [Address] section for more details. For <literal>address</literal> or
+          <literal>prefix</literal> source types, the type of the element used in the NFT filter must be
+          <literal>ipv4_addr</literal>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v255"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[DHCPv6] Section Options</title>
+
+    <para>The [DHCPv6] section configures the DHCPv6 client, if it is enabled with the
+    <varname>DHCP=</varname> setting described above, or invoked by the IPv6 Router Advertisement:
+    </para>
+
+    <variablelist class='network-directives'>
+
+      <!-- DHCP packet contents -->
+
+      <varlistentry>
+        <term><varname>MUDURL=</varname></term>
+        <term><varname>IAID=</varname></term>
+        <term><varname>DUIDType=</varname></term>
+        <term><varname>DUIDRawData=</varname></term>
+        <term><varname>RequestOptions=</varname></term>
+        <listitem>
+          <para>As in the [DHCPv4] section.</para>
+
+        <xi:include href="version-info.xml" xpointer="v246"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SendOption=</varname></term>
+        <listitem>
+          <para>As in the [DHCPv4] section, however because DHCPv6 uses 16-bit fields to store option
+          numbers, the option number is an integer in the range 1…65536.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SendVendorOption=</varname></term>
+        <listitem>
+          <para>Send an arbitrary vendor option in the DHCPv6 request. Takes an enterprise identifier,
+          DHCP option number, data type, and data separated with a colon
+          (<literal><replaceable>enterprise identifier</replaceable>:<replaceable>option</replaceable>:<replaceable>type</replaceable>:<replaceable>value</replaceable></literal>).
+          Enterprise identifier is an unsigned integer in the range 1…4294967294. The option number
+          must be an integer in the range 1…254. Data type takes one of <literal>uint8</literal>,
+          <literal>uint16</literal>, <literal>uint32</literal>, <literal>ipv4address</literal>,
+          <literal>ipv6address</literal>, or <literal>string</literal>. Special characters in the data
+          string may be escaped using
+          <ulink url="https://en.wikipedia.org/wiki/Escape_sequences_in_C#Table_of_escape_sequences">C-style
+          escapes</ulink>. This setting can be specified multiple times. If an empty string is
+          specified, then all options specified earlier are cleared. Defaults to unset.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>UserClass=</varname></term>
+        <listitem>
+          <para>A DHCPv6 client can use User Class option to identify the type or category of user or
+          applications it represents. The information contained in this option is a string that
+          represents the user class of which the client is a member. Each class sets an identifying
+          string of information to be used by the DHCP service to classify clients. Special characters
+          in the data string may be escaped using
+          <ulink url="https://en.wikipedia.org/wiki/Escape_sequences_in_C#Table_of_escape_sequences">C-style
+          escapes</ulink>. This setting can be specified multiple times. If an empty string is
+          specified, then all options specified earlier are cleared. Takes a whitespace-separated list
+          of strings. Note that currently <constant>NUL</constant> bytes are not allowed.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>VendorClass=</varname></term>
+        <listitem>
+          <para>A DHCPv6 client can use VendorClass option to identify the vendor that manufactured the
+          hardware on which the client is running. The information contained in the data area of this
+          option is contained in one or more opaque fields that identify details of the hardware
+          configuration. Takes a whitespace-separated list of strings.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>PrefixDelegationHint=</varname></term>
+        <listitem>
+          <para>Takes an IPv6 address with prefix length in the same format as the
+          <varname>Address=</varname> in the [Network] section. The DHCPv6 client will include a prefix
+          hint in the DHCPv6 solicitation sent to the server. The prefix length must be in the range
+          1…128. Defaults to unset.</para>
+
+          <xi:include href="version-info.xml" xpointer="v244"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RapidCommit=</varname></term>
+        <listitem>
+          <para>Takes a boolean. The DHCPv6 client can obtain configuration parameters from a DHCPv6 server
+          through a rapid two-message exchange (solicit and reply). When the rapid commit option is set by
+          both the DHCPv6 client and the DHCPv6 server, the two-message exchange is used. Otherwise, the
+          four-message exchange (solicit, advertise, request, and reply) is used. The two-message exchange
+          provides faster client configuration. See
+          <ulink url="https://tools.ietf.org/html/rfc3315#section-17.2.1">RFC 3315</ulink> for details.
+          Defaults to true, and the two-message exchange will be used if the server support it.</para>
+
+          <xi:include href="version-info.xml" xpointer="v252"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SendHostname=</varname></term>
+        <listitem>
+          <para>When true (the default), the machine's hostname (or the value specified with
+          <varname>Hostname=</varname>, described below) will be sent to the DHCPv6 server. Note that the
+          hostname must consist only of 7-bit ASCII lower-case characters and no spaces or dots, and be
+          formatted as a valid DNS domain name. Otherwise, the hostname is not sent even if this option
+          is true.</para>
+
+          <xi:include href="version-info.xml" xpointer="v255"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Hostname=</varname></term>
+        <listitem>
+          <para>Use this value for the hostname which is sent to the DHCPv6 server, instead of machine's
+          hostname. Note that the specified hostname must consist only of 7-bit ASCII lower-case
+          characters and no spaces or dots, and be formatted as a valid DNS domain name.</para>
+
+          <xi:include href="version-info.xml" xpointer="v255"/>
+        </listitem>
+      </varlistentry>
+
+      <!-- How to use the DHCP lease -->
+
+      <varlistentry>
+        <term><varname>UseAddress=</varname></term>
+        <listitem>
+          <para>When true (the default), the IP addresses provided by the DHCPv6 server will be
+          assigned.</para>
+
+          <xi:include href="version-info.xml" xpointer="v248"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>UseCaptivePortal=</varname></term>
+        <listitem>
+          <para>When true (the default), the captive portal advertised by the DHCPv6 server will be recorded
+          and made available to client programs and displayed in the
+          <citerefentry><refentrytitle>networkctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+          status output per-link.</para>
+
+          <xi:include href="version-info.xml" xpointer="v254"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>UseDelegatedPrefix=</varname></term>
+        <listitem>
+          <para>When true (the default), the client will request the DHCPv6 server to delegate
+          prefixes. If the server provides prefixes to be delegated, then subnets of the prefixes are
+          assigned to the interfaces that have <varname>DHCPPrefixDelegation=yes</varname>.
+          See also the <varname>DHCPPrefixDelegation=</varname> setting in the [Network] section,
+          settings in the [DHCPPrefixDelegation] section, and
+          <ulink url="https://www.rfc-editor.org/rfc/rfc8415.html#section-6.3">RFC 8415</ulink>.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v250"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>UseDNS=</varname></term>
+        <term><varname>UseNTP=</varname></term>
+        <term><varname>UseHostname=</varname></term>
+        <term><varname>UseDomains=</varname></term>
+        <term><varname>NetLabel=</varname></term>
+        <term><varname>SendRelease=</varname></term>
+        <listitem>
+          <para>As in the [DHCPv4] section.</para>
+
+        <xi:include href="version-info.xml" xpointer="v243"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>NFTSet=</varname></term>
+        <listitem>
+          <para>This applies the NFT set for the network configuration received with DHCP, like
+          <varname>NFTSet=</varname> in [Address] section applies it to static configuration. See
+          <varname>NFTSet=</varname> in [Address] section for more details. For <literal>address</literal>
+          or <literal>prefix</literal> source types, the type of the element used in the NFT filter must be
+          <literal>ipv6_addr</literal>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v255"/>
+        </listitem>
+      </varlistentry>
+
+      <!-- How to communicate with the server -->
+
+      <varlistentry>
+        <term><varname>WithoutRA=</varname></term>
+        <listitem>
+          <para>Allows DHCPv6 client to start without router advertisements's
+          <literal>managed</literal> or <literal>other configuration</literal> flag. Takes one of
+          <literal>no</literal>, <literal>solicit</literal>, or
+          <literal>information-request</literal>. If this is not specified,
+          <literal>solicit</literal> is used when <varname>DHCPPrefixDelegation=</varname> is enabled
+          and <varname>UplinkInterface=:self</varname> is specified in the [DHCPPrefixDelegation]
+          section. Otherwise, defaults to <literal>no</literal>, and the DHCPv6 client will be started
+          when an RA is received. See also the <varname>DHCPv6Client=</varname> setting in the
+          [IPv6AcceptRA] section.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[DHCPPrefixDelegation] Section Options</title>
+    <para>The [DHCPPrefixDelegation] section configures subnet prefixes of the delegated prefixes
+    acquired by a DHCPv6 client or by a DHCPv4 client through the 6RD option on another interface.
+    The settings in this section are used only when the <varname>DHCPPrefixDelegation=</varname>
+    setting in the [Network] section is enabled.</para>
+
+    <variablelist class='network-directives'>
+      <varlistentry>
+        <term><varname>UplinkInterface=</varname></term>
+        <listitem>
+          <para>Specifies the name or the index of the uplink interface, or one of the special values
+          <literal>:self</literal> and <literal>:auto</literal>. When <literal>:self</literal>, the
+          interface itself is considered the uplink interface, and
+          <varname>WithoutRA=solicit</varname> is implied if the setting is not explicitly specified.
+          When <literal>:auto</literal>, the first link which acquired prefixes to be delegated from
+          the DHCPv6 or DHCPv4 server is selected. Defaults to <literal>:auto</literal>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v250"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SubnetId=</varname></term>
+        <listitem>
+          <para>Configure a specific subnet ID on the interface from a (previously) received prefix
+          delegation. You can either set "auto" (the default) or a specific subnet ID (as defined in
+          <ulink url="https://tools.ietf.org/html/rfc4291#section-2.5.4">RFC 4291</ulink>, section
+          2.5.4), in which case the allowed value is hexadecimal, from 0 to 0x7fffffffffffffff
+          inclusive.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Announce=</varname></term>
+        <listitem>
+          <para>Takes a boolean. When enabled, and <varname>IPv6SendRA=</varname> in [Network] section
+          is enabled, the delegated prefixes are distributed through the IPv6 Router Advertisement.
+          This setting will be ignored when the <varname>DHCPPrefixDelegation=</varname> setting is
+          enabled on the upstream interface. Defaults to yes.</para>
+
+        <xi:include href="version-info.xml" xpointer="v247"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Assign=</varname></term>
+        <listitem>
+          <para>Takes a boolean. Specifies whether to add an address from the delegated prefixes which
+          are received from the WAN interface by the DHCPv6 Prefix Delegation. When true (on LAN
+          interface), the EUI-64 algorithm will be used by default to form an interface identifier from
+          the delegated prefixes. See also <varname>Token=</varname> setting below. Defaults to yes.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Token=</varname></term>
+        <listitem>
+          <para>Specifies an optional address generation mode for assigning an address in each
+          delegated prefix. This accepts the same syntax as <varname>Token=</varname> in the
+          [IPv6AcceptRA] section. If <varname>Assign=</varname> is set to false, then this setting will
+          be ignored. Defaults to unset, which means the EUI-64 algorithm will be used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ManageTemporaryAddress=</varname></term>
+        <listitem>
+          <para>As in the [Address] section, but defaults to true.</para>
+
+        <xi:include href="version-info.xml" xpointer="v248"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RouteMetric=</varname></term>
+        <listitem>
+          <para>The metric of the route to the delegated prefix subnet. Takes an unsigned integer in
+          the range 0…4294967295. When set to 0, the kernel's default value is used. Defaults to 256.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v249"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>NetLabel=</varname></term>
+        <listitem>
+          <para>This applies the NetLabel for the addresses received with DHCP, like
+          <varname>NetLabel=</varname> in [Address] section applies it to statically configured
+          addresses. See <varname>NetLabel=</varname> in [Address] section for more details.</para>
+
+          <xi:include href="version-info.xml" xpointer="v252"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>NFTSet=</varname></term>
+        <listitem>
+          <para>This applies the NFT set for the network configuration received with DHCP, like
+          <varname>NFTSet=</varname> in [Address] section applies it to static configuration. See
+          <varname>NFTSet=</varname> in [Address] section for more details. For <literal>address</literal> or
+          <literal>prefix</literal> source types, the type of the element used in the NFT filter must be
+          <literal>ipv6_addr</literal>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v255"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[IPv6AcceptRA] Section Options</title>
+    <para>The [IPv6AcceptRA] section configures the IPv6 Router Advertisement (RA) client, if it is enabled
+    with the <varname>IPv6AcceptRA=</varname> setting described above:</para>
+
+    <variablelist class='network-directives'>
+      <varlistentry>
+        <term><varname>Token=</varname></term>
+        <listitem>
+          <para>Specifies an optional address generation mode for the Stateless Address
+          Autoconfiguration (SLAAC). The following values are supported:</para>
+
+          <variablelist>
+            <varlistentry>
+              <term><option>eui64</option></term>
+              <listitem>
+                <para>
+                  The EUI-64 algorithm will be used to generate an address for that prefix. Only
+                  supported by Ethernet or InfiniBand interfaces.
+                </para>
+
+                <xi:include href="version-info.xml" xpointer="v250"/>
+              </listitem>
+            </varlistentry>
+            <varlistentry>
+              <term><option>static:<replaceable>ADDRESS</replaceable></option></term>
+              <listitem>
+                <para>
+                  An IPv6 address must be specified after a colon (<literal>:</literal>), and the
+                  lower bits of the supplied address are combined with the upper bits of a prefix
+                  received in a Router Advertisement (RA) message to form a complete address. Note
+                  that if multiple prefixes are received in an RA message, or in multiple RA messages,
+                  addresses will be formed from each of them using the supplied address. This mode
+                  implements SLAAC but uses a static interface identifier instead of an identifier
+                  generated by using the EUI-64 algorithm. Because the interface identifier is static,
+                  if Duplicate Address Detection detects that the computed address is a duplicate
+                  (in use by another node on the link), then this mode will fail to provide an address
+                  for that prefix. If an IPv6 address without mode is specified, then
+                  <literal>static</literal> mode is assumed.
+                </para>
+
+                  <xi:include href="version-info.xml" xpointer="v250"/>
+              </listitem>
+            </varlistentry>
+            <varlistentry>
+              <term><option>prefixstable[:<replaceable>ADDRESS</replaceable>][,<replaceable>UUID</replaceable>]</option></term>
+              <listitem>
+                <para>
+                  The algorithm specified in
+                  <ulink url="https://tools.ietf.org/html/rfc7217">RFC 7217</ulink> will be used to
+                  generate interface identifiers. This mode can optionally take an IPv6 address
+                  separated with a colon (<literal>:</literal>). If an IPv6 address is specified,
+                  then an interface identifier is generated only when a prefix received in an RA
+                  message matches the supplied address.
+                </para>
+                <para>
+                  This mode can also optionally take a non-null UUID in the format which
+                  <function>sd_id128_from_string()</function> accepts, e.g.
+                  <literal>86b123b969ba4b7eb8b3d8605123525a</literal> or
+                  <literal>86b123b9-69ba-4b7e-b8b3-d8605123525a</literal>. If a UUID is specified, the
+                  value is used as the secret key to generate interface identifiers. If not specified,
+                  then an application specific ID generated with the system's machine-ID will be used
+                  as the secret key. See
+                  <citerefentry><refentrytitle>sd-id128</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+                  <citerefentry><refentrytitle>sd_id128_from_string</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+                  and
+                  <citerefentry><refentrytitle>sd_id128_get_machine</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+                </para>
+                <para>
+                  Note that the <literal>prefixstable</literal> algorithm uses both the interface
+                  name and MAC address as input to the hash to compute the interface identifier, so
+                  if either of those are changed the resulting interface identifier (and address)
+                  will be changed, even if the prefix received in the RA message has not been
+                  changed.
+                </para>
+
+                  <xi:include href="version-info.xml" xpointer="v250"/>
+              </listitem>
+            </varlistentry>
+          </variablelist>
+
+          <para>If no address generation mode is specified (which is the default), or a received
+          prefix does not match any of the addresses provided in <literal>prefixstable</literal>
+          mode, then the EUI-64 algorithm will be used for Ethernet or InfiniBand interfaces,
+          otherwise <literal>prefixstable</literal> will be used to form an interface identifier for
+          that prefix.</para>
+
+          <para>This setting can be specified multiple times. If an empty string is assigned, then
+          the all previous assignments are cleared.</para>
+
+          <para>Examples:
+          <programlisting>Token=eui64
+Token=::1a:2b:3c:4d
+Token=static:::1a:2b:3c:4d
+Token=prefixstable
+Token=prefixstable:2002:da8:1::</programlisting></para>
+
+          <xi:include href="version-info.xml" xpointer="v250"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>UseDNS=</varname></term>
+        <listitem>
+          <para>When true (the default), the DNS servers received in the Router Advertisement will be used.</para>
+
+          <para>This corresponds to the <option>nameserver</option> option in <citerefentry
+          project='man-pages'><refentrytitle>resolv.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v231"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>UseDomains=</varname></term>
+        <listitem>
+          <para>Takes a boolean, or the special value <literal>route</literal>. When true, the domain name
+          received via IPv6 Router Advertisement (RA) will be used as DNS search domain over this link,
+          similarly to the effect of the <option>Domains=</option> setting. If set to
+          <literal>route</literal>, the domain name received via IPv6 RA will be used for routing DNS queries
+          only, but not for searching, similarly to the effect of the <option>Domains=</option> setting when
+          the argument is prefixed with <literal>~</literal>. Defaults to false.</para>
+
+          <para>It is recommended to enable this option only on trusted networks, as setting this affects resolution
+          of all hostnames, in particular of single-label names. It is generally safer to use the supplied domain
+          only as routing domain, rather than as search domain, in order to not have it affect local resolution of
+          single-label names.</para>
+
+          <para>When set to true, this setting corresponds to the <option>domain</option> option in <citerefentry
+          project='man-pages'><refentrytitle>resolv.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v231"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RouteTable=<replaceable>num</replaceable></varname></term>
+        <listitem>
+          <para>The table identifier for the routes received in the Router Advertisement. Takes one of
+          predefined names <literal>default</literal>, <literal>main</literal>, and <literal>local</literal>,
+          and names defined in <varname>RouteTable=</varname> in
+          <citerefentry><refentrytitle>networkd.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+          or a number between 1…4294967295.</para>
+
+          <para>When used in combination with <varname>VRF=</varname>, the VRF's routing table is
+          used when this parameter is not specified.</para>
+
+          <xi:include href="version-info.xml" xpointer="v232"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RouteMetric=</varname></term>
+        <listitem>
+          <para>Set the routing metric for the routes received in the Router Advertisement. Takes an unsigned
+          integer in the range 0…4294967295, or three unsigned integer separated with <literal>:</literal>,
+          in that case the first one is used when the router preference is high, the second is for medium
+          preference, and the last is for low preference
+          (<literal><replaceable>high</replaceable>:<replaceable>medium</replaceable>:<replaceable>low</replaceable></literal>).
+          Defaults to <literal>512:1024:2048</literal>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v249"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>QuickAck=</varname></term>
+        <listitem>
+          <para>Takes a boolean. When true, the TCP quick ACK mode is enabled for the routes configured by
+          the received RAs. When unset, the kernel's default will be used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v253"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>UseMTU=</varname></term>
+        <listitem>
+          <para>Takes a boolean. When true, the MTU received in the Router Advertisement will be
+          used. Defaults to true.</para>
+
+          <xi:include href="version-info.xml" xpointer="v250"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>UseHopLimit=</varname></term>
+        <listitem>
+          <para>Takes a boolean. When true, the hop limit received in the Router Advertisement will be set to routes
+          configured based on the advertisement. See also <varname>IPv6HopLimit=</varname>. Defaults to true.</para>
+
+          <xi:include href="version-info.xml" xpointer="v255"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>UseICMP6RateLimit=</varname></term>
+        <listitem>
+          <para>Takes a boolean. When true, the ICMP6 rate limit received in the Router Advertisement will be set to ICMP6
+          rate limit based on the advertisement. Defaults to true.</para>
+
+          <xi:include href="version-info.xml" xpointer="v255"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>UseGateway=</varname></term>
+        <listitem>
+          <para>When true (the default), the router address will be configured as the default gateway.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v250"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>UseRoutePrefix=</varname></term>
+        <listitem>
+          <para>When true (the default), the routes corresponding to the route prefixes received in
+          the Router Advertisement will be configured.</para>
+
+          <xi:include href="version-info.xml" xpointer="v250"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>UseCaptivePortal=</varname></term>
+        <listitem>
+          <para>When true (the default), the captive portal received in the Router Advertisement will be recorded
+          and made available to client programs and displayed in the
+          <citerefentry><refentrytitle>networkctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+          status output per-link.</para>
+
+          <xi:include href="version-info.xml" xpointer="v254"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>UsePREF64=</varname></term>
+        <listitem>
+          <para>When true, the IPv6 PREF64 (or NAT64) prefixes received in the Router Advertisement will be
+          recorded and made available to client programs and displayed in the
+          <citerefentry><refentrytitle>networkctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+          status output per-link. See <ulink url="https://tools.ietf.org/html/rfc8781">RFC 8781</ulink>.
+          Defaults to false.</para>
+
+          <xi:include href="version-info.xml" xpointer="v255"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>UseAutonomousPrefix=</varname></term>
+        <listitem>
+          <para>When true (the default), the autonomous prefix received in the Router Advertisement will be used and take
+          precedence over any statically configured ones.</para>
+
+          <xi:include href="version-info.xml" xpointer="v242"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>UseOnLinkPrefix=</varname></term>
+        <listitem>
+          <para>When true (the default), the onlink prefix received in the Router Advertisement will be
+          used and takes precedence over any statically configured ones.</para>
+
+          <xi:include href="version-info.xml" xpointer="v242"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RouterDenyList=</varname></term>
+        <listitem>
+          <para>A whitespace-separated list of IPv6 router addresses. Each address can optionally
+          take a prefix length after <literal>/</literal>. Any information advertised by the listed
+          router is ignored.</para>
+
+          <xi:include href="version-info.xml" xpointer="v248"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RouterAllowList=</varname></term>
+        <listitem>
+          <para>A whitespace-separated list of IPv6 router addresses. Each address can optionally
+          take a prefix length after <literal>/</literal>. Only information advertised by the listed
+          router is accepted. Note that if <varname>RouterAllowList=</varname> is configured then
+          <varname>RouterDenyList=</varname> is ignored.</para>
+
+          <xi:include href="version-info.xml" xpointer="v248"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>PrefixDenyList=</varname></term>
+        <listitem>
+          <para>A whitespace-separated list of IPv6 prefixes. Each prefix can optionally take its
+          prefix length after <literal>/</literal>. IPv6 prefixes supplied via router advertisements
+          in the list are ignored.</para>
+
+          <xi:include href="version-info.xml" xpointer="v248"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>PrefixAllowList=</varname></term>
+        <listitem>
+          <para>A whitespace-separated list of IPv6 prefixes. Each prefix can optionally take its
+          prefix length after <literal>/</literal>. IPv6 prefixes supplied via router advertisements
+          in the list are allowed. Note that if <varname>PrefixAllowList=</varname> is configured
+          then <varname>PrefixDenyList=</varname> is ignored.</para>
+
+          <xi:include href="version-info.xml" xpointer="v248"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RouteDenyList=</varname></term>
+        <listitem>
+          <para>A whitespace-separated list of IPv6 route prefixes. Each prefix can optionally take
+          its prefix length after <literal>/</literal>. IPv6 route prefixes supplied via router
+          advertisements in the list are ignored.</para>
+
+          <xi:include href="version-info.xml" xpointer="v248"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RouteAllowList=</varname></term>
+        <listitem>
+          <para>A whitespace-separated list of IPv6 route prefixes. Each prefix can optionally take
+          its prefix length after <literal>/</literal>. IPv6 route prefixes supplied via router
+          advertisements in the list are allowed. Note that if <varname>RouteAllowList=</varname> is
+          configured then <varname>RouteDenyList=</varname> is ignored.</para>
+
+          <xi:include href="version-info.xml" xpointer="v248"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>DHCPv6Client=</varname></term>
+        <listitem>
+          <para>Takes a boolean, or the special value <literal>always</literal>. When true, the
+          DHCPv6 client will be started in <literal>solicit</literal> mode if the RA has the
+          <literal>managed</literal> flag or <literal>information-request</literal> mode if the RA
+          lacks the <literal>managed</literal> flag but has the
+          <literal>other configuration</literal> flag. If set to <literal>always</literal>, the
+          DHCPv6 client will be started in <literal>solicit</literal> mode when an RA is received,
+          even if neither the <literal>managed</literal> nor the
+          <literal>other configuration</literal> flag is set in the RA. This will be ignored when
+          <varname>WithoutRA=</varname> in the [DHCPv6] section is enabled, or
+          <varname>UplinkInterface=:self</varname> in the [DHCPPrefixDelegation] section is
+          specified. Defaults to true.</para>
+
+        <xi:include href="version-info.xml" xpointer="v246"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>NetLabel=</varname></term>
+        <listitem>
+          <para>This applies the NetLabel for the addresses received with RA, like
+          <varname>NetLabel=</varname> in [Address] section applies it to statically configured
+          addresses. See <varname>NetLabel=</varname> in [Address] section for more details.</para>
+
+          <xi:include href="version-info.xml" xpointer="v252"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>NFTSet=</varname></term>
+        <listitem>
+          <para>This applies the NFT set for the network configuration received with RA, like
+          <varname>NFTSet=</varname> in [Address] section applies it to static configuration. See
+          <varname>NFTSet=</varname> in [Address] section for more details. For <literal>address</literal> or
+          <literal>prefix</literal> source types, the type of the element used in the NFT filter must be
+          <literal>ipv6_addr</literal>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v255"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[DHCPServer] Section Options</title>
+    <para>The [DHCPServer] section contains settings for the DHCP server, if enabled via the
+    <varname>DHCPServer=</varname> option described above:</para>
+
+    <variablelist class='network-directives'>
+
+      <varlistentry>
+        <term><varname>ServerAddress=</varname></term>
+        <listitem>
+          <para>Specifies the server address for the DHCP server. Takes an IPv4 address with prefix length
+          separated with a slash, e.g. <literal>192.168.0.1/24</literal>. Defaults to unset, and one of
+          static IPv4 addresses configured in [Network] or [Address] section will be automatically selected.
+          This setting may be useful when the interface on which the DHCP server is running has multiple
+          static IPv4 addresses.</para>
+          <para>This implies <varname>Address=</varname> in [Network] or [Address] section with the same
+          address and prefix length. That is,
+          <programlisting>[Network]
+DHCPServer=yes
+Address=192.168.0.1/24
+Address=192.168.0.2/24
+[DHCPServer]
+ServerAddress=192.168.0.1/24</programlisting>
+          or
+          <programlisting>[Network]
+DHCPServer=yes
+[Address]
+Address=192.168.0.1/24
+[Address]
+Address=192.168.0.2/24
+[DHCPServer]
+ServerAddress=192.168.0.1/24</programlisting>
+          are equivalent to the following.
+          <programlisting>[Network]
+DHCPServer=yes
+Address=192.168.0.2/24
+[DHCPServer]
+ServerAddress=192.168.0.1/24</programlisting>
+          </para>
+          <para>Since version 255, like the <varname>Address=</varname> setting in [Network] or [Address]
+          section, this also supports a null address, e.g. <literal>0.0.0.0/24</literal>, and an unused
+          address will be automatically selected. For more details about the automatic address selection,
+          see <varname>Address=</varname> setting in [Network] section in the above.</para>
+
+          <xi:include href="version-info.xml" xpointer="v249"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>PoolOffset=</varname></term>
+        <term><varname>PoolSize=</varname></term>
+
+        <listitem><para>Configures the pool of addresses to hand out. The pool
+        is a contiguous sequence of IP addresses in the subnet configured for
+        the server address, which does not include the subnet nor the broadcast
+        address. <varname>PoolOffset=</varname> takes the offset of the pool
+        from the start of subnet, or zero to use the default value.
+        <varname>PoolSize=</varname> takes the number of IP addresses in the
+        pool or zero to use the default value. By default, the pool starts at
+        the first address after the subnet address and takes up the rest of
+        the subnet, excluding the broadcast address. If the pool includes
+        the server address (the default), this is reserved and not handed
+        out to clients.</para>
+
+        <xi:include href="version-info.xml" xpointer="v226"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>DefaultLeaseTimeSec=</varname></term>
+        <term><varname>MaxLeaseTimeSec=</varname></term>
+
+        <listitem><para>Control the default and maximum DHCP lease
+        time to pass to clients. These settings take time values in seconds or
+        another common time unit, depending on the suffix. The default
+        lease time is used for clients that did not ask for a specific
+        lease time. If a client asks for a lease time longer than the
+        maximum lease time, it is automatically shortened to the
+        specified time. The default lease time defaults to 1h, the
+        maximum lease time to 12h. Shorter lease times are beneficial
+        if the configuration data in DHCP leases changes frequently
+        and clients shall learn the new settings with shorter
+        latencies. Longer lease times reduce the generated DHCP
+        network traffic.</para>
+
+        <xi:include href="version-info.xml" xpointer="v226"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>UplinkInterface=</varname></term>
+        <listitem><para>Specifies the name or the index of the uplink interface, or one of the special
+        values <literal>:none</literal> and <literal>:auto</literal>. When emitting DNS, NTP, or SIP
+        servers is enabled but no servers are specified, the servers configured in the uplink interface
+        will be emitted. When <literal>:auto</literal>, the link which has a default gateway with the
+        highest priority will be automatically selected. When <literal>:none</literal>, no uplink
+        interface will be selected. Defaults to <literal>:auto</literal>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v249"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>EmitDNS=</varname></term>
+        <term><varname>DNS=</varname></term>
+
+        <listitem><para><varname>EmitDNS=</varname> takes a boolean. Configures whether the DHCP leases
+        handed out to clients shall contain DNS server information. Defaults to <literal>yes</literal>.
+        The DNS servers to pass to clients may be configured with the <varname>DNS=</varname> option,
+        which takes a list of IPv4 addresses, or special value <literal>_server_address</literal> which
+        will be converted to the address used by the DHCP server.</para>
+
+        <para>If the <varname>EmitDNS=</varname> option is enabled but no servers configured, the
+        servers are automatically propagated from an "uplink" interface that has appropriate servers
+        set. The "uplink" interface is determined by the default route of the system with the highest
+        priority. Note that this information is acquired at the time the lease is handed out, and does
+        not take uplink interfaces into account that acquire DNS server information at a later point.
+        If no suitable uplink interface is found the DNS server data from
+        <filename>/etc/resolv.conf</filename> is used. Also, note that the leases are not refreshed if
+        the uplink network configuration changes. To ensure clients regularly acquire the most current
+        uplink DNS server information, it is thus advisable to shorten the DHCP lease time via
+        <varname>MaxLeaseTimeSec=</varname> described above.</para>
+
+        <para>This setting can be specified multiple times. If an empty string is specified, then all
+        DNS servers specified earlier are cleared.</para>
+
+        <xi:include href="version-info.xml" xpointer="v226"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>EmitNTP=</varname></term>
+        <term><varname>NTP=</varname></term>
+        <term><varname>EmitSIP=</varname></term>
+        <term><varname>SIP=</varname></term>
+        <term><varname>EmitPOP3=</varname></term>
+        <term><varname>POP3=</varname></term>
+        <term><varname>EmitSMTP=</varname></term>
+        <term><varname>SMTP=</varname></term>
+        <term><varname>EmitLPR=</varname></term>
+        <term><varname>LPR=</varname></term>
+
+        <listitem><para>Similar to the <varname>EmitDNS=</varname> and <varname>DNS=</varname> settings
+        described above, these settings configure whether and what server information for the indicate
+        protocol shall be emitted as part of the DHCP lease. The same syntax, propagation semantics and
+        defaults apply as for <varname>EmitDNS=</varname> and <varname>DNS=</varname>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v226"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>EmitRouter=</varname></term>
+        <term><varname>Router=</varname></term>
+
+        <listitem><para>The <varname>EmitRouter=</varname> setting takes a boolean value, and configures
+        whether the DHCP lease should contain the router option. The <varname>Router=</varname> setting
+        takes an IPv4 address, and configures the router address to be emitted. When the
+        <varname>Router=</varname> setting is not specified, then the server address will be used for
+        the router option. When the <varname>EmitRouter=</varname> setting is disabled, the
+        <varname>Router=</varname> setting will be ignored. The <varname>EmitRouter=</varname> setting
+        defaults to true, and the <varname>Router=</varname> setting defaults to unset.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v230"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>EmitTimezone=</varname></term>
+        <term><varname>Timezone=</varname></term>
+
+        <listitem><para>Takes a boolean. Configures whether the DHCP leases handed out
+        to clients shall contain timezone information. Defaults to <literal>yes</literal>. The
+        <varname>Timezone=</varname> setting takes a timezone string
+        (such as <literal>Europe/Berlin</literal> or
+        <literal>UTC</literal>) to pass to clients. If no explicit
+        timezone is set, the system timezone of the local host is
+        propagated, as determined by the
+        <filename>/etc/localtime</filename> symlink.</para>
+
+        <xi:include href="version-info.xml" xpointer="v226"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>BootServerAddress=</varname></term>
+
+        <listitem>
+          <para>Takes an IPv4 address of the boot server used by e.g. PXE boot systems. When specified, this
+          address is sent in the <option>siaddr</option> field of the DHCP message header. See <ulink
+          url="https://www.rfc-editor.org/rfc/rfc2131.html">RFC 2131</ulink> for more details. Defaults to
+          unset.</para>
+
+          <xi:include href="version-info.xml" xpointer="v251"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>BootServerName=</varname></term>
+
+        <listitem>
+          <para>Takes a name of the boot server used by e.g. PXE boot systems. When specified, this name is
+          sent in the DHCP option 66 ("TFTP server name"). See <ulink
+          url="https://www.rfc-editor.org/rfc/rfc2132.html">RFC 2132</ulink> for more details. Defaults to
+          unset.</para>
+
+          <para>Note that typically setting one of <varname>BootServerName=</varname> or
+          <varname>BootServerAddress=</varname> is sufficient, but both can be set too, if desired.</para>
+
+          <xi:include href="version-info.xml" xpointer="v251"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>BootFilename=</varname></term>
+
+        <listitem>
+          <para>Takes a path or URL to a file loaded by e.g. a PXE boot loader. When specified, this path is
+          sent in the DHCP option 67 ("Bootfile name"). See <ulink
+          url="https://www.rfc-editor.org/rfc/rfc2132.html">RFC 2132</ulink> for more details. Defaults to
+          unset.</para>
+
+          <xi:include href="version-info.xml" xpointer="v251"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>IPv6OnlyPreferredSec=</varname></term>
+
+        <listitem>
+          <para>Takes a timespan. Controls the
+          <ulink url="https://tools.ietf.org/html/rfc8925">RFC 8925</ulink> IPv6-Only Preferred option.
+          Specifies the DHCPv4 option to indicate that a host supports an IPv6-only mode and is willing to
+          forgo obtaining an IPv4 address if the network provides IPv6 connectivity. Defaults to unset, and
+          not send the option. The minimum allowed value is 300 seconds.</para>
+
+          <xi:include href="version-info.xml" xpointer="v255"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SendOption=</varname></term>
+        <listitem>
+          <para>Send a raw option with value via DHCPv4 server. Takes a DHCP option number, data type
+          and data (<literal><replaceable>option</replaceable>:<replaceable>type</replaceable>:<replaceable>value</replaceable></literal>).
+          The option number is an integer in the range 1…254. The type takes one of <literal>uint8</literal>,
+          <literal>uint16</literal>, <literal>uint32</literal>, <literal>ipv4address</literal>, <literal>ipv6address</literal>, or
+          <literal>string</literal>. Special characters in the data string may be escaped using
+          <ulink url="https://en.wikipedia.org/wiki/Escape_sequences_in_C#Table_of_escape_sequences">C-style
+          escapes</ulink>. This setting can be specified multiple times. If an empty string is specified,
+          then all options specified earlier are cleared. Defaults to unset.</para>
+
+          <xi:include href="version-info.xml" xpointer="v244"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SendVendorOption=</varname></term>
+        <listitem>
+          <para>Send a vendor option with value via DHCPv4 server. Takes a DHCP option number, data type
+          and data (<literal><replaceable>option</replaceable>:<replaceable>type</replaceable>:<replaceable>value</replaceable></literal>).
+          The option number is an integer in the range 1…254. The type takes one of <literal>uint8</literal>,
+          <literal>uint16</literal>, <literal>uint32</literal>, <literal>ipv4address</literal>, or
+          <literal>string</literal>. Special characters in the data string may be escaped using
+          <ulink url="https://en.wikipedia.org/wiki/Escape_sequences_in_C#Table_of_escape_sequences">C-style
+          escapes</ulink>. This setting can be specified multiple times. If an empty string is specified,
+          then all options specified earlier are cleared. Defaults to unset.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>BindToInterface=</varname></term>
+        <listitem>
+          <para>Takes a boolean value. When <literal>yes</literal>, DHCP server socket will be bound
+          to its network interface and all socket communication will be restricted to this interface.
+          Defaults to <literal>yes</literal>, except if <varname>RelayTarget=</varname> is used (see below),
+          in which case it defaults to <literal>no</literal>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v249"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>RelayTarget=</varname></term>
+        <listitem>
+          <para>Takes an IPv4 address, which must be in the format described in
+          <citerefentry project='man-pages'><refentrytitle>inet_pton</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+          Turns this DHCP server into a DHCP relay agent. See <ulink url="https://tools.ietf.org/html/rfc1542">RFC 1542</ulink>.
+          The address is the address of DHCP server or another relay agent to forward DHCP messages to and from.</para>
+
+          <xi:include href="version-info.xml" xpointer="v249"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>RelayAgentCircuitId=</varname></term>
+        <listitem>
+          <para>Specifies value for Agent Circuit ID suboption of Relay Agent Information option.
+          Takes a string, which must be in the format <literal>string:<replaceable>value</replaceable></literal>,
+          where <literal><replaceable>value</replaceable></literal> should be replaced with the value of the suboption.
+          Defaults to unset (means no Agent Circuit ID suboption is generated).
+          Ignored if <varname>RelayTarget=</varname> is not specified.</para>
+
+          <xi:include href="version-info.xml" xpointer="v249"/>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>RelayAgentRemoteId=</varname></term>
+        <listitem>
+          <para>Specifies value for Agent Remote ID suboption of Relay Agent Information option.
+          Takes a string, which must be in the format <literal>string:<replaceable>value</replaceable></literal>,
+          where <literal><replaceable>value</replaceable></literal> should be replaced with the value of the suboption.
+          Defaults to unset (means no Agent Remote ID suboption is generated).
+          Ignored if <varname>RelayTarget=</varname> is not specified.</para>
+
+          <xi:include href="version-info.xml" xpointer="v249"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RapidCommit=</varname></term>
+        <listitem>
+          <para>Takes a boolean. When true, the server supports
+          <ulink url="https://datatracker.ietf.org/doc/html/rfc4039">RFC 4039</ulink>. When a client sends
+          a DHCPDISCOVER message with the Rapid Commit option to the server, then the server will reply with
+          a DHCPACK message to the client, instead of DHCPOFFER. Defaults to true.</para>
+
+          <xi:include href="version-info.xml" xpointer="v255"/>
+        </listitem>
+      </varlistentry>
+
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[DHCPServerStaticLease] Section Options</title>
+    <para>The <literal>[DHCPServerStaticLease]</literal> section configures a static DHCP lease to assign a
+    fixed IPv4 address to a specific device based on its MAC address. This section can be specified multiple
+    times.</para>
+
+    <variablelist class='network-directives'>
+      <varlistentry>
+        <term><varname>MACAddress=</varname></term>
+
+        <listitem><para>The hardware address of a device to match. This key is mandatory.</para>
+
+        <xi:include href="version-info.xml" xpointer="v249"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Address=</varname></term>
+
+        <listitem><para>The IPv4 address that should be assigned to the device that was matched with
+        <varname>MACAddress=</varname>. This key is mandatory.</para>
+
+        <xi:include href="version-info.xml" xpointer="v249"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[IPv6SendRA] Section Options</title>
+    <para>The [IPv6SendRA] section contains settings for sending IPv6 Router Advertisements and whether
+    to act as a router, if enabled via the <varname>IPv6SendRA=</varname> option described above. IPv6
+    network prefixes or routes are defined with one or more [IPv6Prefix] or [IPv6RoutePrefix] sections.
+    </para>
+
+    <variablelist class='network-directives'>
+
+      <varlistentry>
+        <term><varname>Managed=</varname></term>
+        <term><varname>OtherInformation=</varname></term>
+
+        <listitem><para>Takes a boolean. Controls whether a DHCPv6 server is used to acquire IPv6
+        addresses on the network link when <varname>Managed=</varname>
+        is set to <literal>true</literal> or if only additional network
+        information can be obtained via DHCPv6 for the network link when
+        <varname>OtherInformation=</varname> is set to
+        <literal>true</literal>. Both settings default to
+        <literal>false</literal>, which means that a DHCPv6 server is not being
+        used.</para>
+
+        <xi:include href="version-info.xml" xpointer="v235"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RouterLifetimeSec=</varname></term>
+
+        <listitem><para>Takes a timespan. Configures the IPv6 router lifetime in seconds. The value must be 0
+        seconds, or between 4 seconds and 9000 seconds. When set to 0, the host is not acting as a router.
+        Defaults to 1800 seconds (30 minutes).</para>
+
+        <xi:include href="version-info.xml" xpointer="v235"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RetransmitSec=</varname></term>
+
+        <listitem><para>Takes a timespan. Configures the retransmit time, used by clients to retransmit Neighbor
+        Solicitation messages on address resolution and the Neighbor Unreachability Detection algorithm.
+        An integer the default unit of seconds, in the range 0…4294967295 msec. Defaults to 0.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RouterPreference=</varname></term>
+
+        <listitem><para>Configures IPv6 router preference if
+        <varname>RouterLifetimeSec=</varname> is non-zero. Valid values are
+        <literal>high</literal>, <literal>medium</literal> and
+        <literal>low</literal>, with <literal>normal</literal> and
+        <literal>default</literal> added as synonyms for
+        <literal>medium</literal> just to make configuration easier. See
+        <ulink url="https://tools.ietf.org/html/rfc4191">RFC 4191</ulink>
+        for details. Defaults to <literal>medium</literal>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v235"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>HopLimit=</varname></term>
+        <listitem>
+          <para>Configures hop limit. Takes an integer in the range 0…255. See also
+          <varname>IPv6HopLimit=</varname>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v255"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>UplinkInterface=</varname></term>
+        <listitem><para>Specifies the name or the index of the uplink interface, or one of the special
+        values <literal>:none</literal> and <literal>:auto</literal>. When emitting DNS servers or
+        search domains is enabled but no servers are specified, the servers configured in the uplink
+        interface will be emitted. When <literal>:auto</literal>, the value specified to the same
+        setting in the [DHCPPrefixDelegation] section will be used if
+        <varname>DHCPPrefixDelegation=</varname> is enabled, otherwise the link which has a default
+        gateway with the highest priority will be automatically selected. When <literal>:none</literal>,
+        no uplink interface will be selected. Defaults to <literal>:auto</literal>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>EmitDNS=</varname></term>
+        <term><varname>DNS=</varname></term>
+
+        <listitem><para><varname>DNS=</varname> specifies a list of recursive DNS server IPv6 addresses
+        that are distributed via Router Advertisement messages when <varname>EmitDNS=</varname> is true.
+        <varname>DNS=</varname> also takes special value <literal>_link_local</literal>; in that case
+        the IPv6 link-local address is distributed. If <varname>DNS=</varname> is empty, DNS servers are
+        read from the [Network] section. If the [Network] section does not contain any DNS servers
+        either, DNS servers from the uplink interface specified in <varname>UplinkInterface=</varname>
+        will be used. When <varname>EmitDNS=</varname> is false, no DNS server information is sent in
+        Router Advertisement messages. <varname>EmitDNS=</varname> defaults to true.</para>
+
+        <xi:include href="version-info.xml" xpointer="v235"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>EmitDomains=</varname></term>
+        <term><varname>Domains=</varname></term>
+
+        <listitem><para>A list of DNS search domains distributed via Router Advertisement messages when
+        <varname>EmitDomains=</varname> is true. If <varname>Domains=</varname> is empty, DNS search
+        domains are read from the [Network] section. If the [Network] section does not contain any DNS
+        search domains either, DNS search domains from the uplink interface specified in
+        <varname>UplinkInterface=</varname> will be used. When <varname>EmitDomains=</varname> is false,
+        no DNS search domain information is sent in Router Advertisement messages.
+        <varname>EmitDomains=</varname> defaults to true.</para>
+
+        <xi:include href="version-info.xml" xpointer="v235"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>DNSLifetimeSec=</varname></term>
+
+        <listitem><para>Lifetime in seconds for the DNS server addresses listed in
+        <varname>DNS=</varname> and search domains listed in <varname>Domains=</varname>. Defaults to
+        3600 seconds (one hour).</para>
+
+        <xi:include href="version-info.xml" xpointer="v235"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>HomeAgent=</varname></term>
+
+        <listitem><para>Takes a boolean. Specifies that IPv6 router advertisements which indicates to hosts that
+        the router acts as a Home Agent and includes a Home Agent Option. Defaults to false. See
+        <ulink url="https://tools.ietf.org/html/rfc6275">RFC 6275</ulink> for further details.</para>
+
+         <xi:include href="version-info.xml" xpointer="v255"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>HomeAgentLifetimeSec=</varname></term>
+
+        <listitem><para>Takes a timespan. Specifies the lifetime of the Home Agent. An integer the default unit of seconds,
+        in the range 1…65535. Defaults to the value set to <varname>RouterLifetimeSec=</varname>.</para>
+
+         <xi:include href="version-info.xml" xpointer="v255"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>HomeAgentPreference=</varname></term>
+
+        <listitem><para>Configures IPv6 Home Agent preference. Takes an integer in the range 0…65535.
+        Defaults to 0.</para>
+
+         <xi:include href="version-info.xml" xpointer="v255"/>
+        </listitem>
+      </varlistentry>
+
+    </variablelist>
+    </refsect1>
+
+    <refsect1>
+    <title>[IPv6Prefix] Section Options</title>
+    <para>One or more [IPv6Prefix] sections contain the IPv6 prefixes that are announced via Router
+    Advertisements. See <ulink url="https://tools.ietf.org/html/rfc4861">RFC 4861</ulink> for further
+    details.</para>
+
+    <variablelist class='network-directives'>
+
+      <varlistentry>
+        <term><varname>AddressAutoconfiguration=</varname></term>
+        <term><varname>OnLink=</varname></term>
+
+        <listitem><para>Takes a boolean to specify whether IPv6 addresses can be
+        autoconfigured with this prefix and whether the prefix can be used for
+        onlink determination. Both settings default to <literal>true</literal>
+        in order to ease configuration.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v235"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Prefix=</varname></term>
+
+        <listitem><para>The IPv6 prefix that is to be distributed to hosts. Similarly to configuring static
+        IPv6 addresses, the setting is configured as an IPv6 prefix and its prefix length, separated by a
+        <literal>/</literal> character. Use multiple [IPv6Prefix] sections to configure multiple IPv6
+        prefixes since prefix lifetimes, address autoconfiguration and onlink status may differ from one
+        prefix to another.</para>
+
+        <xi:include href="version-info.xml" xpointer="v235"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>PreferredLifetimeSec=</varname></term>
+        <term><varname>ValidLifetimeSec=</varname></term>
+
+        <listitem><para>Preferred and valid lifetimes for the prefix measured in seconds.
+        <varname>PreferredLifetimeSec=</varname> defaults to 1800 seconds (30 minutes) and
+        <varname>ValidLifetimeSec=</varname> defaults to 3600 seconds (one hour).</para>
+
+        <xi:include href="version-info.xml" xpointer="v235"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Assign=</varname></term>
+        <listitem><para>Takes a boolean. When true, adds an address from the prefix. Default to false.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Token=</varname></term>
+        <listitem>
+          <para>Specifies an optional address generation mode for assigning an address in each
+          prefix. This accepts the same syntax as <varname>Token=</varname> in the [IPv6AcceptRA]
+          section. If <varname>Assign=</varname> is set to false, then this setting will be ignored.
+          Defaults to unset, which means the EUI-64 algorithm will be used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v250"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RouteMetric=</varname></term>
+        <listitem>
+          <para>The metric of the prefix route. Takes an unsigned integer in the range 0…4294967295.
+          When unset or set to 0, the kernel's default value is used. This setting is ignored when
+          <varname>Assign=</varname> is false.</para>
+
+          <xi:include href="version-info.xml" xpointer="v249"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+    </refsect1>
+
+    <refsect1>
+    <title>[IPv6RoutePrefix] Section Options</title>
+    <para>One or more [IPv6RoutePrefix] sections contain the IPv6
+    prefix routes that are announced via Router Advertisements. See
+    <ulink url="https://tools.ietf.org/html/rfc4191">RFC 4191</ulink>
+    for further details.</para>
+
+    <variablelist class='network-directives'>
+
+      <varlistentry>
+        <term><varname>Route=</varname></term>
+
+        <listitem><para>The IPv6 route that is to be distributed to hosts. Similarly to configuring static
+        IPv6 routes, the setting is configured as an IPv6 prefix routes and its prefix route length,
+        separated by a <literal>/</literal> character. Use multiple [IPv6RoutePrefix] sections to configure
+        multiple IPv6 prefix routes.</para>
+
+        <xi:include href="version-info.xml" xpointer="v244"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>LifetimeSec=</varname></term>
+
+        <listitem><para>Lifetime for the route prefix measured in seconds.
+        <varname>LifetimeSec=</varname> defaults to 3600 seconds (one hour).</para>
+
+        <xi:include href="version-info.xml" xpointer="v244"/></listitem>
+      </varlistentry>
+
+    </variablelist>
+    </refsect1>
+
+    <refsect1>
+    <title>[IPv6PREF64Prefix] Section Options</title>
+    <para>One or more [IPv6PREF64Prefix] sections contain the IPv6 PREF64 (or NAT64) prefixes that are announced via Router
+    Advertisements. See <ulink url="https://tools.ietf.org/html/rfc8781">RFC 8781</ulink> for further
+    details.</para>
+
+    <variablelist class='network-directives'>
+
+      <varlistentry>
+        <term><varname>Prefix=</varname></term>
+
+        <listitem><para>The IPv6 PREF64 (or NAT64) prefix that is to be distributed to hosts. The setting holds
+        an IPv6 prefix that should be set up for NAT64 translation (PLAT) to allow 464XLAT on the network segment.
+        Use multiple [IPv6PREF64Prefix] sections to configure multiple IPv6 prefixes since prefix lifetime may differ
+        from one prefix to another. The prefix is an address with a prefix length, separated by a slash
+        <literal>/</literal> character. Valid NAT64 prefix length are 96, 64, 56, 48, 40, and 32 bits.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem></varlistentry>
+
+      <varlistentry>
+        <term><varname>LifetimeSec=</varname></term>
+        <listitem><para>Lifetime for the prefix measured in seconds. Should be greater than or equal to <varname>RouterLifetimeSec=</varname>.
+        <varname>LifetimeSec=</varname> defaults to 1800 seconds.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+    </variablelist>
+    </refsect1>
+
+    <refsect1>
+    <title>[Bridge] Section Options</title>
+      <para>The [Bridge] section accepts the following keys:</para>
+      <variablelist class='network-directives'>
+        <varlistentry>
+          <term><varname>UnicastFlood=</varname></term>
+          <listitem>
+            <para>Takes a boolean. Controls whether the bridge should flood
+            traffic for which an FDB entry is missing and the destination
+            is unknown through this port. When unset, the kernel's default will be used.
+            </para>
+
+            <xi:include href="version-info.xml" xpointer="v223"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>MulticastFlood=</varname></term>
+          <listitem>
+            <para>Takes a boolean. Controls whether the bridge should flood
+            traffic for which an MDB entry is missing and the destination
+            is unknown through this port. When unset, the kernel's default will be used.
+            </para>
+
+            <xi:include href="version-info.xml" xpointer="v242"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>MulticastToUnicast=</varname></term>
+          <listitem>
+            <para>Takes a boolean. Multicast to unicast works on top of the multicast snooping feature of
+            the bridge. Which means unicast copies are only delivered to hosts which are interested in it.
+            When unset, the kernel's default will be used.
+            </para>
+
+            <xi:include href="version-info.xml" xpointer="v240"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>NeighborSuppression=</varname></term>
+          <listitem>
+            <para>Takes a boolean. Configures whether ARP and ND neighbor suppression is enabled for
+            this port. When unset, the kernel's default will be used.
+            </para>
+
+            <xi:include href="version-info.xml" xpointer="v242"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>Learning=</varname></term>
+          <listitem>
+            <para>Takes a boolean. Configures whether MAC address learning is enabled for
+            this port. When unset, the kernel's default will be used.
+            </para>
+
+            <xi:include href="version-info.xml" xpointer="v242"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>HairPin=</varname></term>
+          <listitem>
+            <para>Takes a boolean. Configures whether traffic may be sent back out of the port on which it
+            was received. When this flag is false, then the bridge will not forward traffic back out of the
+            receiving port. When unset, the kernel's default will be used.</para>
+
+            <xi:include href="version-info.xml" xpointer="v223"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>Isolated=</varname></term>
+          <listitem>
+            <para>Takes a boolean. Configures whether this port is isolated or not. Within a bridge,
+            isolated ports can only communicate with non-isolated ports. When set to true, this port can only
+            communicate with other ports whose Isolated setting is false.  When set to false, this port
+            can communicate with any other ports. When unset, the kernel's default will be used.</para>
+
+            <xi:include href="version-info.xml" xpointer="v251"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>UseBPDU=</varname></term>
+          <listitem>
+            <para>Takes a boolean. Configures whether STP Bridge Protocol Data Units will be
+            processed by the bridge port. When unset, the kernel's default will be used.</para>
+
+            <xi:include href="version-info.xml" xpointer="v223"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>FastLeave=</varname></term>
+          <listitem>
+            <para>Takes a boolean. This flag allows the bridge to immediately stop multicast
+            traffic on a port that receives an IGMP Leave message. It is only used with
+            IGMP snooping if enabled on the bridge. When unset, the kernel's default will be used.</para>
+
+            <xi:include href="version-info.xml" xpointer="v223"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>AllowPortToBeRoot=</varname></term>
+          <listitem>
+            <para>Takes a boolean. Configures whether a given port is allowed to
+            become a root port. Only used when STP is enabled on the bridge.
+            When unset, the kernel's default will be used.</para>
+
+            <xi:include href="version-info.xml" xpointer="v223"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>ProxyARP=</varname></term>
+          <listitem>
+            <para>Takes a boolean. Configures whether proxy ARP to be enabled on this port.
+            When unset, the kernel's default will be used.</para>
+
+            <xi:include href="version-info.xml" xpointer="v243"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>ProxyARPWiFi=</varname></term>
+          <listitem>
+            <para>Takes a boolean. Configures whether proxy ARP to be enabled on this port
+            which meets extended requirements by IEEE 802.11 and Hotspot 2.0 specifications.
+            When unset, the kernel's default will be used.</para>
+
+            <xi:include href="version-info.xml" xpointer="v243"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>MulticastRouter=</varname></term>
+          <listitem>
+            <para>Configures this port for having multicast routers attached. A port with a multicast
+            router will receive all multicast traffic. Takes one of <literal>no</literal>
+            to disable multicast routers on this port, <literal>query</literal> to let the system detect
+            the presence of routers, <literal>permanent</literal> to permanently enable multicast traffic
+            forwarding on this port, or <literal>temporary</literal> to enable multicast routers temporarily
+            on this port, not depending on incoming queries. When unset, the kernel's default will be used.</para>
+
+            <xi:include href="version-info.xml" xpointer="v243"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>Cost=</varname></term>
+          <listitem>
+            <para>Sets the "cost" of sending packets of this interface.
+            Each port in a bridge may have a different speed and the cost
+            is used to decide which link to use. Faster interfaces
+            should have lower costs. It is an integer value between 1 and
+            65535.</para>
+
+            <xi:include href="version-info.xml" xpointer="v218"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>Priority=</varname></term>
+          <listitem>
+            <para>Sets the "priority" of sending packets on this interface.
+            Each port in a bridge may have a different priority which is used
+            to decide which link to use. Lower value means higher priority.
+            It is an integer value between 0 to 63. Networkd does not set any
+            default, meaning the kernel default value of 32 is used.</para>
+
+            <xi:include href="version-info.xml" xpointer="v234"/>
+          </listitem>
+        </varlistentry>
+      </variablelist>
+  </refsect1>
+  <refsect1>
+    <title>[BridgeFDB] Section Options</title>
+      <para>The [BridgeFDB] section manages the forwarding database table of a port and accepts the following
+      keys. Specify several [BridgeFDB] sections to configure several static MAC table entries.</para>
+
+      <variablelist class='network-directives'>
+        <varlistentry>
+          <term><varname>MACAddress=</varname></term>
+          <listitem>
+            <para>As in the [Network] section. This key is mandatory.</para>
+
+          <xi:include href="version-info.xml" xpointer="v219"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>Destination=</varname></term>
+          <listitem>
+            <para>Takes an IP address of the destination VXLAN tunnel endpoint.</para>
+
+          <xi:include href="version-info.xml" xpointer="v243"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>VLANId=</varname></term>
+          <listitem>
+            <para>The VLAN ID for the new static MAC table entry. If
+            omitted, no VLAN ID information is appended to the new static MAC
+            table entry.</para>
+
+            <xi:include href="version-info.xml" xpointer="v219"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>VNI=</varname></term>
+          <listitem>
+            <para>The VXLAN Network Identifier (or VXLAN Segment ID) to use to connect to
+            the remote VXLAN tunnel endpoint. Takes a number in the range 1…16777215.
+            Defaults to unset.</para>
+
+            <xi:include href="version-info.xml" xpointer="v243"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>AssociatedWith=</varname></term>
+          <listitem>
+            <para>Specifies where the address is associated with. Takes one of <literal>use</literal>,
+            <literal>self</literal>, <literal>master</literal> or <literal>router</literal>.
+            <literal>use</literal> means the address is in use. User space can use this option to
+            indicate to the kernel that the fdb entry is in use. <literal>self</literal> means
+            the address is associated with the port drivers fdb. Usually hardware. <literal>master</literal>
+            means the address is associated with master devices fdb. <literal>router</literal> means
+            the destination address is associated with a router. Note that it's valid if the referenced
+            device is a VXLAN type device and has route shortcircuit enabled. Defaults to <literal>self</literal>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v243"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>OutgoingInterface=</varname></term>
+          <listitem>
+            <para>Specifies the name or index of the outgoing interface for the VXLAN device driver to
+            reach the remote VXLAN tunnel endpoint. Defaults to unset.</para>
+
+            <xi:include href="version-info.xml" xpointer="v249"/>
+          </listitem>
+        </varlistentry>
+      </variablelist>
+  </refsect1>
+  <refsect1>
+    <title>[BridgeMDB] Section Options</title>
+      <para>The [BridgeMDB] section manages the multicast membership entries forwarding database table of a port and accepts the following
+      keys. Specify several [BridgeMDB] sections to configure several permanent multicast membership entries.</para>
+
+      <variablelist class='network-directives'>
+        <varlistentry>
+          <term><varname>MulticastGroupAddress=</varname></term>
+          <listitem>
+            <para>Specifies the IPv4 or IPv6 multicast group address to add. This setting is mandatory.</para>
+
+          <xi:include href="version-info.xml" xpointer="v247"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>VLANId=</varname></term>
+          <listitem>
+            <para>The VLAN ID for the new entry. Valid ranges are 0 (no VLAN) to 4094. Optional, defaults to 0.</para>
+
+          <xi:include href="version-info.xml" xpointer="v247"/>
+          </listitem>
+        </varlistentry>
+      </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[LLDP] Section Options</title>
+      <para>The [LLDP] section manages the Link Layer Discovery Protocol (LLDP) and accepts the following
+      keys:</para>
+      <variablelist class='network-directives'>
+        <varlistentry>
+          <term><varname>MUDURL=</varname></term>
+          <listitem>
+            <para>When configured, the specified Manufacturer Usage Descriptions (MUD) URL will be sent in
+            LLDP packets. The syntax and semantics are the same as for <varname>MUDURL=</varname> in the
+            [DHCPv4] section described above.</para>
+
+            <para>The MUD URLs received via LLDP packets are saved and can be read using the
+            <function>sd_lldp_neighbor_get_mud_url()</function> function.</para>
+
+            <xi:include href="version-info.xml" xpointer="v246"/>
+          </listitem>
+        </varlistentry>
+      </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[CAN] Section Options</title>
+      <para>The [CAN] section manages the Controller Area Network (CAN bus) and accepts the
+      following keys:</para>
+      <variablelist class='network-directives'>
+        <varlistentry>
+          <term><varname>BitRate=</varname></term>
+          <listitem>
+            <para>The bitrate of CAN device in bits per second. The usual SI prefixes (K, M) with the base of 1000 can
+            be used here. Takes a number in the range 1…4294967295.</para>
+
+            <xi:include href="version-info.xml" xpointer="v239"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>SamplePoint=</varname></term>
+          <listitem>
+            <para>Optional sample point in percent with one decimal (e.g. <literal>75%</literal>,
+            <literal>87.5%</literal>) or permille (e.g. <literal>875‰</literal>). This will be ignored when
+            <varname>BitRate=</varname> is unspecified.</para>
+
+          <xi:include href="version-info.xml" xpointer="v239"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>TimeQuantaNSec=</varname></term>
+          <term><varname>PropagationSegment=</varname></term>
+          <term><varname>PhaseBufferSegment1=</varname></term>
+          <term><varname>PhaseBufferSegment2=</varname></term>
+          <term><varname>SyncJumpWidth=</varname></term>
+          <listitem>
+            <para>Specifies the time quanta, propagation segment, phase buffer segment 1 and 2, and the
+            synchronization jump width, which allow one to define the CAN bit-timing in a hardware
+            independent format as proposed by the Bosch CAN 2.0 Specification.
+            <varname>TimeQuantaNSec=</varname> takes a timespan in nanoseconds.
+            <varname>PropagationSegment=</varname>, <varname>PhaseBufferSegment1=</varname>,
+            <varname>PhaseBufferSegment2=</varname>, and <varname>SyncJumpWidth=</varname> take number
+            of time quantum specified in <varname>TimeQuantaNSec=</varname> and must be an unsigned
+            integer in the range 0…4294967295. These settings except for
+            <varname>SyncJumpWidth=</varname> will be ignored when <varname>BitRate=</varname> is
+            specified.</para>
+
+            <xi:include href="version-info.xml" xpointer="v250"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>DataBitRate=</varname></term>
+          <term><varname>DataSamplePoint=</varname></term>
+          <listitem>
+            <para>The bitrate and sample point for the data phase, if CAN-FD is used. These settings are
+            analogous to the <varname>BitRate=</varname> and <varname>SamplePoint=</varname> keys.</para>
+
+            <xi:include href="version-info.xml" xpointer="v246"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>DataTimeQuantaNSec=</varname></term>
+          <term><varname>DataPropagationSegment=</varname></term>
+          <term><varname>DataPhaseBufferSegment1=</varname></term>
+          <term><varname>DataPhaseBufferSegment2=</varname></term>
+          <term><varname>DataSyncJumpWidth=</varname></term>
+          <listitem>
+            <para>Specifies the time quanta, propagation segment, phase buffer segment 1 and 2, and the
+            synchronization jump width for the data phase, if CAN-FD is used. These settings are
+            analogous to the <varname>TimeQuantaNSec=</varname> or related settings.</para>
+
+            <xi:include href="version-info.xml" xpointer="v250"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>FDMode=</varname></term>
+          <listitem>
+            <para>Takes a boolean. When <literal>yes</literal>, CAN-FD mode is enabled for the interface.
+            Note, that a bitrate and optional sample point should also be set for the CAN-FD data phase using
+            the <varname>DataBitRate=</varname> and <varname>DataSamplePoint=</varname> keys, or
+            <varname>DataTimeQuanta=</varname> and related settings.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>FDNonISO=</varname></term>
+          <listitem>
+            <para>Takes a boolean. When <literal>yes</literal>, non-ISO CAN-FD mode is enabled for the
+            interface. When unset, the kernel's default will be used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>RestartSec=</varname></term>
+          <listitem>
+            <para>Automatic restart delay time. If set to a non-zero value, a restart of the CAN controller will be
+            triggered automatically in case of a bus-off condition after the specified delay time. Subsecond delays can
+            be specified using decimals (e.g. <literal>0.1s</literal>) or a <literal>ms</literal> or
+            <literal>us</literal> postfix. Using <literal>infinity</literal> or <literal>0</literal> will turn the
+            automatic restart off. By default automatic restart is disabled.</para>
+
+            <xi:include href="version-info.xml" xpointer="v239"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>Termination=</varname></term>
+          <listitem>
+            <para>Takes a boolean or a termination resistor value in ohm in the range 0…65535. When
+            <literal>yes</literal>, the termination resistor is set to 120 ohm. When
+            <literal>no</literal> or <literal>0</literal> is set, the termination resistor is disabled.
+            When unset, the kernel's default will be used.</para>
+
+            <xi:include href="version-info.xml" xpointer="v246"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>TripleSampling=</varname></term>
+          <listitem>
+            <para>Takes a boolean. When <literal>yes</literal>, three samples (instead of one) are used to determine
+            the value of a received bit by majority rule. When unset, the kernel's default will be used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v242"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>BusErrorReporting=</varname></term>
+          <listitem>
+            <para>Takes a boolean. When <literal>yes</literal>, reporting of CAN bus errors is activated
+            (those include single bit, frame format, and bit stuffing errors, unable to send dominant bit,
+            unable to send recessive bit, bus overload, active error announcement, error occurred on
+            transmission). When unset, the kernel's default will be used. Note: in case of a CAN bus with a
+            single CAN device, sending a CAN frame may result in a huge number of CAN bus errors.</para>
+
+          <xi:include href="version-info.xml" xpointer="v248"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>ListenOnly=</varname></term>
+          <listitem>
+            <para>Takes a boolean. When <literal>yes</literal>, listen-only mode is enabled. When the
+            interface is in listen-only mode, the interface neither transmit CAN frames nor send ACK
+            bit. Listen-only mode is important to debug CAN networks without interfering with the
+            communication or acknowledge the CAN frame. When unset, the kernel's default will be used.
+            </para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>Loopback=</varname></term>
+          <listitem>
+            <para>Takes a boolean. When <literal>yes</literal>, loopback mode is enabled. When the
+            loopback mode is enabled, the interface treats messages transmitted by itself as received
+            messages. The loopback mode is important to debug CAN networks. When unset, the kernel's
+            default will be used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v250"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>OneShot=</varname></term>
+          <listitem>
+            <para>Takes a boolean. When <literal>yes</literal>, one-shot mode is enabled. When unset,
+            the kernel's default will be used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v250"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>PresumeAck=</varname></term>
+          <listitem>
+            <para>Takes a boolean. When <literal>yes</literal>, the interface will ignore missing CAN
+            ACKs. When unset, the kernel's default will be used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v250"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>ClassicDataLengthCode=</varname></term>
+          <listitem>
+            <para>Takes a boolean. When <literal>yes</literal>, the interface will handle the 4bit data
+            length code (DLC). When unset, the kernel's default will be used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v250"/>
+          </listitem>
+        </varlistentry>
+      </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[IPoIB] Section Options</title>
+      <para>The [IPoIB] section manages the IP over Infiniband and accepts the following keys:</para>
+      <variablelist class='network-directives'>
+        <xi:include href="systemd.netdev.xml" xpointer="ipoib_mode" />
+        <xi:include href="systemd.netdev.xml" xpointer="ipoib_umcast" />
+      </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[QDisc] Section Options</title>
+    <para>The [QDisc] section manages the traffic control queueing discipline (qdisc).</para>
+
+    <variablelist class='network-directives'>
+      <varlistentry>
+        <term><varname>Parent=</varname></term>
+        <listitem>
+          <para>Specifies the parent Queueing Discipline (qdisc). Takes one of <literal>clsact</literal>
+          or <literal>ingress</literal>. This is mandatory.</para>
+
+        <xi:include href="version-info.xml" xpointer="v244"/>
+        </listitem>
+      </varlistentry>
+
+      <xi:include href="tc.xml" xpointer="qdisc-handle" />
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[NetworkEmulator] Section Options</title>
+    <para>The [NetworkEmulator] section manages the queueing discipline (qdisc) of the network emulator. It
+    can be used to configure the kernel packet scheduler and simulate packet delay and loss for UDP or TCP
+    applications, or limit the bandwidth usage of a particular service to simulate internet connections.
+    </para>
+
+    <variablelist class='network-directives'>
+      <xi:include href="tc.xml" xpointer="qdisc-parent" />
+      <xi:include href="tc.xml" xpointer="qdisc-handle" />
+
+      <varlistentry>
+        <term><varname>DelaySec=</varname></term>
+        <listitem>
+          <para>Specifies the fixed amount of delay to be added to all packets going out of the
+          interface. Defaults to unset.</para>
+
+          <xi:include href="version-info.xml" xpointer="v245"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>DelayJitterSec=</varname></term>
+        <listitem>
+          <para>Specifies the chosen delay to be added to the packets outgoing to the network
+          interface. Defaults to unset.</para>
+
+          <xi:include href="version-info.xml" xpointer="v245"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>PacketLimit=</varname></term>
+        <listitem>
+          <para>Specifies the maximum number of packets the qdisc may hold queued at a time.
+          An unsigned integer in the range 0…4294967294. Defaults to 1000.</para>
+
+          <xi:include href="version-info.xml" xpointer="v245"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>LossRate=</varname></term>
+        <listitem>
+          <para>Specifies an independent loss probability to be added to the packets outgoing from the
+          network interface. Takes a percentage value, suffixed with "%". Defaults to unset.</para>
+
+          <xi:include href="version-info.xml" xpointer="v245"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>DuplicateRate=</varname></term>
+        <listitem>
+          <para>Specifies that the chosen percent of packets is duplicated before queuing them.
+          Takes a percentage value, suffixed with "%". Defaults to unset.</para>
+
+          <xi:include href="version-info.xml" xpointer="v245"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[TokenBucketFilter] Section Options</title>
+    <para>The [TokenBucketFilter] section manages the queueing discipline (qdisc) of token bucket filter
+    (tbf).</para>
+
+    <variablelist class='network-directives'>
+      <xi:include href="tc.xml" xpointer="qdisc-parent" />
+      <xi:include href="tc.xml" xpointer="qdisc-handle" />
+
+      <varlistentry>
+        <term><varname>LatencySec=</varname></term>
+        <listitem>
+          <para>Specifies the latency parameter, which specifies the maximum amount of time a
+          packet can sit in the Token Bucket Filter (TBF). Defaults to unset.</para>
+
+          <xi:include href="version-info.xml" xpointer="v245"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>LimitBytes=</varname></term>
+        <listitem>
+          <para>Takes the number of bytes that can be queued waiting for tokens to become available.
+          When the size is suffixed with K, M, or G, it is parsed as Kilobytes, Megabytes, or Gigabytes,
+          respectively, to the base of 1024. Defaults to unset.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>BurstBytes=</varname></term>
+        <listitem>
+          <para>Specifies the size of the bucket. This is the maximum amount of bytes that tokens
+          can be available for instantaneous transfer. When the size is suffixed with K, M, or G, it is
+          parsed as Kilobytes, Megabytes, or Gigabytes, respectively, to the base of 1024. Defaults to
+          unset.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Rate=</varname></term>
+        <listitem>
+          <para>Specifies the device specific bandwidth. When suffixed with K, M, or G, the specified
+          bandwidth is parsed as Kilobits, Megabits, or Gigabits, respectively, to the base of 1000.
+          Defaults to unset.</para>
+
+          <xi:include href="version-info.xml" xpointer="v245"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>MPUBytes=</varname></term>
+        <listitem>
+          <para>The Minimum Packet Unit (MPU) determines the minimal token usage (specified in bytes)
+          for a packet. When suffixed with K, M, or G, the specified size is parsed as Kilobytes,
+          Megabytes, or Gigabytes, respectively, to the base of 1024. Defaults to zero.</para>
+
+          <xi:include href="version-info.xml" xpointer="v245"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>PeakRate=</varname></term>
+        <listitem>
+          <para>Takes the maximum depletion rate of the bucket. When suffixed with K, M, or G, the
+          specified size is parsed as Kilobits, Megabits, or Gigabits, respectively, to the base of
+          1000. Defaults to unset.</para>
+
+          <xi:include href="version-info.xml" xpointer="v245"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>MTUBytes=</varname></term>
+        <listitem>
+          <para>Specifies the size of the peakrate bucket. When suffixed with K, M, or G, the specified
+          size is parsed as Kilobytes, Megabytes, or Gigabytes, respectively, to the base of 1024.
+          Defaults to unset.</para>
+
+          <xi:include href="version-info.xml" xpointer="v245"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[PIE] Section Options</title>
+    <para>The [PIE] section manages the queueing discipline (qdisc) of Proportional Integral
+    controller-Enhanced (PIE).</para>
+
+    <variablelist class='network-directives'>
+      <xi:include href="tc.xml" xpointer="qdisc-parent" />
+      <xi:include href="tc.xml" xpointer="qdisc-handle" />
+
+      <varlistentry>
+        <term><varname>PacketLimit=</varname></term>
+        <listitem>
+          <para>Specifies the hard limit on the queue size in number of packets. When this limit is reached,
+          incoming packets are dropped. An unsigned integer in the range 1…4294967294. Defaults to unset and
+          kernel's default is used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[FlowQueuePIE] Section Options</title>
+    <para>The <literal>[FlowQueuePIE]</literal> section manages the queueing discipline
+    (qdisc) of Flow Queue Proportional Integral controller-Enhanced (fq_pie).</para>
+
+    <variablelist class='network-directives'>
+      <xi:include href="tc.xml" xpointer="qdisc-parent" />
+      <xi:include href="tc.xml" xpointer="qdisc-handle" />
+
+      <varlistentry>
+        <term><varname>PacketLimit=</varname></term>
+        <listitem>
+          <para>Specifies the hard limit on the queue size in number of packets. When this limit is reached,
+          incoming packets are dropped. An unsigned integer ranges 1 to 4294967294. Defaults to unset and
+          kernel's default is used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v247"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[StochasticFairBlue] Section Options</title>
+    <para>The [StochasticFairBlue] section manages the queueing discipline (qdisc) of stochastic fair blue
+    (sfb).</para>
+
+    <variablelist class='network-directives'>
+      <xi:include href="tc.xml" xpointer="qdisc-parent" />
+      <xi:include href="tc.xml" xpointer="qdisc-handle" />
+
+      <varlistentry>
+        <term><varname>PacketLimit=</varname></term>
+        <listitem>
+          <para>Specifies the hard limit on the queue size in number of packets. When this limit is reached,
+          incoming packets are dropped. An unsigned integer in the range 0…4294967294. Defaults to unset and
+          kernel's default is used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[StochasticFairnessQueueing] Section Options</title>
+    <para>The [StochasticFairnessQueueing] section manages the queueing discipline (qdisc) of stochastic
+    fairness queueing (sfq).</para>
+
+    <variablelist class='network-directives'>
+      <xi:include href="tc.xml" xpointer="qdisc-parent" />
+      <xi:include href="tc.xml" xpointer="qdisc-handle" />
+
+      <varlistentry>
+        <term><varname>PerturbPeriodSec=</varname></term>
+        <listitem>
+          <para>Specifies the interval in seconds for queue algorithm perturbation. Defaults to unset.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[BFIFO] Section Options</title>
+    <para>The [BFIFO] section manages the queueing discipline (qdisc) of Byte limited Packet First In First
+    Out (bfifo).</para>
+
+    <variablelist class='network-directives'>
+      <xi:include href="tc.xml" xpointer="qdisc-parent" />
+      <xi:include href="tc.xml" xpointer="qdisc-handle" />
+
+      <varlistentry>
+        <term><varname>LimitBytes=</varname></term>
+        <listitem>
+          <para>Specifies the hard limit in bytes on the FIFO buffer size. The size limit prevents overflow
+          in case the kernel is unable to dequeue packets as quickly as it receives them. When this limit is
+          reached, incoming packets are dropped. When suffixed with K, M, or G, the specified size is parsed
+          as Kilobytes, Megabytes, or Gigabytes, respectively, to the base of 1024. Defaults to unset and
+          kernel default is used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[PFIFO] Section Options</title>
+    <para>The [PFIFO] section manages the queueing discipline (qdisc) of Packet First In First Out
+    (pfifo).</para>
+
+    <variablelist class='network-directives'>
+      <xi:include href="tc.xml" xpointer="qdisc-parent" />
+      <xi:include href="tc.xml" xpointer="qdisc-handle" />
+
+      <varlistentry>
+        <term><varname>PacketLimit=</varname></term>
+        <listitem>
+          <para>Specifies the hard limit on the number of packets in the FIFO queue. The size limit prevents
+          overflow in case the kernel is unable to dequeue packets as quickly as it receives them. When this
+          limit is reached, incoming packets are dropped. An unsigned integer in the range
+          0…4294967294. Defaults to unset and kernel's default is used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[PFIFOHeadDrop] Section Options</title>
+    <para>The [PFIFOHeadDrop] section manages the queueing discipline (qdisc) of Packet First In First Out
+    Head Drop (pfifo_head_drop).</para>
+
+    <variablelist class='network-directives'>
+      <xi:include href="tc.xml" xpointer="qdisc-parent" />
+      <xi:include href="tc.xml" xpointer="qdisc-handle" />
+
+      <varlistentry>
+        <term><varname>PacketLimit=</varname></term>
+        <listitem>
+          <para>As in [PFIFO] section.</para>
+
+        <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+     <title>[PFIFOFast] Section Options</title>
+     <para>The [PFIFOFast] section manages the queueing discipline (qdisc) of Packet First In First Out Fast
+     (pfifo_fast).</para>
+
+     <variablelist class='network-directives'>
+       <xi:include href="tc.xml" xpointer="qdisc-parent" />
+       <xi:include href="tc.xml" xpointer="qdisc-handle" />
+     </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[CAKE] Section Options</title>
+    <para>The [CAKE] section manages the queueing discipline (qdisc) of Common Applications Kept Enhanced
+    (CAKE).</para>
+
+    <variablelist class='network-directives'>
+      <xi:include href="tc.xml" xpointer="qdisc-parent" />
+      <xi:include href="tc.xml" xpointer="qdisc-handle" />
+
+      <varlistentry>
+        <term><varname>Bandwidth=</varname></term>
+        <listitem>
+          <para>Specifies the shaper bandwidth. When suffixed with K, M, or G, the specified size is
+          parsed as Kilobits, Megabits, or Gigabits, respectively, to the base of 1000. Defaults to
+          unset and kernel's default is used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>AutoRateIngress=</varname></term>
+        <listitem>
+          <para>Takes a boolean value. Enables automatic capacity estimation based on traffic arriving
+          at this qdisc. This is most likely to be useful with cellular links, which tend to change
+          quality randomly. If this setting is enabled, the <varname>Bandwidth=</varname> setting is
+          used as an initial estimate. Defaults to unset, and the kernel's default is used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v250"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>OverheadBytes=</varname></term>
+        <listitem>
+          <para>Specifies that bytes to be addeded to the size of each packet. Bytes may be negative.
+          Takes an integer in the range -64…256. Defaults to unset and kernel's default is used.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>MPUBytes=</varname></term>
+        <listitem>
+          <para>Rounds each packet (including overhead) up to the specified bytes. Takes an integer in
+          the range 1…256. Defaults to unset and kernel's default is used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v250"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>CompensationMode=</varname></term>
+        <listitem>
+          <para>Takes one of <literal>none</literal>, <literal>atm</literal>, or <literal>ptm</literal>.
+          Specifies the compensation mode for overhead calculation. When <literal>none</literal>, no
+          compensation is taken into account. When <literal>atm</literal>, enables the compensation for
+          ATM cell framing, which is normally found on ADSL links. When <literal>ptm</literal>, enables
+          the compensation for PTM encoding, which is normally found on VDSL2 links and uses a 64b/65b
+          encoding scheme. Defaults to unset and the kernel's default is used.</para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>UseRawPacketSize=</varname></term>
+        <listitem>
+          <para>Takes a boolean value. When true, the packet size reported by the Linux kernel will be
+          used, instead of the underlying IP packet size. Defaults to unset, and the kernel's default
+          is used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v250"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>FlowIsolationMode=</varname></term>
+        <listitem>
+          <para>CAKE places packets from different flows into different queues, then packets from each
+          queue are delivered fairly. This specifies whether the fairness is based on source address,
+          destination address, individual flows, or any combination of those. The available values are:
+          </para>
+
+          <variablelist>
+            <varlistentry>
+              <term><option>none</option></term>
+              <listitem><para>
+                The flow isolation is disabled, and all traffic passes through a single queue.
+              </para>
+
+              <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+            </varlistentry>
+            <varlistentry>
+              <term><option>src-host</option></term>
+              <listitem><para>
+                Flows are defined only by source address. Equivalent to the <literal>srchost</literal>
+                option for <command>tc qdisc</command> command. See also
+                <citerefentry project='man-pages'><refentrytitle>tc-cake</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+              </para>
+
+                <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+            </varlistentry>
+            <varlistentry>
+              <term><option>dst-host</option></term>
+              <listitem><para>
+                Flows are defined only by destination address. Equivalent to the
+                <literal>dsthost</literal> option for <command>tc qdisc</command> command. See also
+                <citerefentry project='man-pages'><refentrytitle>tc-cake</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+              </para>
+
+                <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+            </varlistentry>
+            <varlistentry>
+              <term><option>hosts</option></term>
+              <listitem><para>
+                Flows are defined by source-destination host pairs. Equivalent to the same option for
+                <command>tc qdisc</command> command. See also
+                <citerefentry project='man-pages'><refentrytitle>tc-cake</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+              </para>
+
+                <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+            </varlistentry>
+            <varlistentry>
+              <term><option>flows</option></term>
+              <listitem><para>
+                Flows are defined by the entire 5-tuple of source address, destination address,
+                transport protocol, source port and destination port. Equivalent to the same option for
+                <command>tc qdisc</command> command. See also
+                <citerefentry project='man-pages'><refentrytitle>tc-cake</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+              </para>
+
+                <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+            </varlistentry>
+            <varlistentry>
+              <term><option>dual-src-host</option></term>
+              <listitem><para>
+                Flows are defined by the 5-tuple (see <literal>flows</literal> in the above), and
+                fairness is applied first over source addresses, then over individual flows. Equivalent
+                to the <literal>dual-srchost</literal> option for <command>tc qdisc</command> command.
+                See also
+                <citerefentry project='man-pages'><refentrytitle>tc-cake</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+              </para>
+
+                <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+            </varlistentry>
+            <varlistentry>
+              <term><option>dual-dst-host</option></term>
+              <listitem><para>
+                Flows are defined by the 5-tuple (see <literal>flows</literal> in the above), and
+                fairness is applied first over destination addresses, then over individual flows.
+                Equivalent to the <literal>dual-dsthost</literal> option for
+                <command>tc qdisc</command> command. See also
+                <citerefentry project='man-pages'><refentrytitle>tc-cake</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+              </para>
+
+                <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+            </varlistentry>
+            <varlistentry>
+              <term><option>triple</option></term>
+              <listitem><para>
+                Flows are defined by the 5-tuple (see <literal>flows</literal>), and fairness is
+                applied over source and destination addresses, and also over individual flows.
+                Equivalent to the <literal>triple-isolate</literal> option for
+                <command>tc qdisc</command> command. See also
+                <citerefentry project='man-pages'><refentrytitle>tc-cake</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+              </para>
+
+                <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+            </varlistentry>
+          </variablelist>
+
+          <para>Defaults to unset and the kernel's default is used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v250"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>NAT=</varname></term>
+        <listitem>
+          <para>Takes a boolean value. When true, CAKE performs a NAT lookup before applying
+          flow-isolation rules, to determine the true addresses and port numbers of the packet, to
+          improve fairness between hosts inside the NAT. This has no practical effect when
+          <varname>FlowIsolationMode=</varname> is <literal>none</literal> or <literal>flows</literal>,
+          or if NAT is performed on a different host. Defaults to unset, and the kernel's default is
+          used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v250"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>PriorityQueueingPreset=</varname></term>
+        <listitem>
+          <para>CAKE divides traffic into <literal>tins</literal>, and each tin has its own independent
+          set of flow-isolation queues, bandwidth threshold, and priority. This specifies the preset of
+          tin profiles. The available values are:</para>
+
+          <variablelist>
+            <varlistentry>
+              <term><option>besteffort</option></term>
+              <listitem><para>
+                Disables priority queueing by placing all traffic in one tin.
+              </para>
+
+              <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+            </varlistentry>
+            <varlistentry>
+              <term><option>precedence</option></term>
+              <listitem><para>
+                Enables priority queueing based on the legacy interpretation of TOS
+                <literal>Precedence</literal> field. Use of this preset on the modern Internet is
+                firmly discouraged.
+              </para>
+
+                <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+            </varlistentry>
+            <varlistentry>
+              <term><option>diffserv8</option></term>
+              <listitem><para>
+                Enables priority queueing based on the Differentiated Service
+                (<literal>DiffServ</literal>) field with eight tins: Background Traffic, High
+                Throughput, Best Effort, Video Streaming, Low Latency Transactions, Interactive Shell,
+                Minimum Latency, and Network Control.
+              </para>
+
+                <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+            </varlistentry>
+            <varlistentry>
+              <term><option>diffserv4</option></term>
+              <listitem><para>
+                Enables priority queueing based on the Differentiated Service
+                (<literal>DiffServ</literal>) field with four tins: Background Traffic, Best Effort,
+                Streaming Media, and Latency Sensitive.
+              </para>
+
+                <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+            </varlistentry>
+            <varlistentry>
+              <term><option>diffserv3</option></term>
+              <listitem><para>
+                Enables priority queueing based on the Differentiated Service
+                (<literal>DiffServ</literal>) field with three tins: Background Traffic, Best Effort,
+                and Latency Sensitive.
+              </para>
+
+                <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+            </varlistentry>
+          </variablelist>
+
+          <para>Defaults to unset, and the kernel's default is used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v250"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>FirewallMark=</varname></term>
+        <listitem>
+          <para>Takes an integer in the range 1…4294967295. When specified, firewall-mark-based
+          overriding of CAKE's tin selection is enabled. Defaults to unset, and the kernel's default is
+          used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v250"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Wash=</varname></term>
+        <listitem>
+          <para>Takes a boolean value. When true, CAKE clears the DSCP fields, except for ECN bits, of
+          any packet passing through CAKE. Defaults to unset, and the kernel's default is used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v250"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SplitGSO=</varname></term>
+        <listitem>
+          <para>Takes a boolean value. When true, CAKE will split General Segmentation Offload (GSO)
+          super-packets into their on-the-wire components and dequeue them individually. Defaults to
+          unset, and the kernel's default is used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v250"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RTTSec=</varname></term>
+        <listitem>
+          <para>Specifies the RTT for the filter. Takes a timespan. Typical values are e.g. 100us for
+          extremely high-performance 10GigE+ networks like datacentre, 1ms for non-WiFi LAN connections,
+          100ms for typical internet connections. Defaults to unset, and the kernel's default will be used.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v253"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>AckFilter=</varname></term>
+        <listitem>
+          <para>Takes a boolean value, or special value <literal>aggressive</literal>. If enabled, ACKs in
+          each flow are queued and redundant ACKs to the upstream are dropped. If yes, the filter will always
+          keep at least two redundant ACKs in the queue, while in <literal>aggressive</literal> mode, it will
+          filter down to a single ACK. This may improve download throughput on links with very asymmetrical
+          rate limits. Defaults to unset, and the kernel's default will be used.</para>
+
+        <xi:include href="version-info.xml" xpointer="v253"/>
+        </listitem>
+      </varlistentry>
+
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[ControlledDelay] Section Options</title>
+    <para>The [ControlledDelay] section manages the queueing discipline (qdisc) of
+    controlled delay (CoDel).</para>
+
+    <variablelist class='network-directives'>
+      <xi:include href="tc.xml" xpointer="qdisc-parent" />
+      <xi:include href="tc.xml" xpointer="qdisc-handle" />
+
+      <varlistentry>
+        <term><varname>PacketLimit=</varname></term>
+        <listitem>
+          <para>Specifies the hard limit on the queue size in number of packets. When this limit is reached,
+          incoming packets are dropped. An unsigned integer in the range 0…4294967294. Defaults to unset and
+          kernel's default is used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v245"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>TargetSec=</varname></term>
+        <listitem>
+          <para>Takes a timespan. Specifies the acceptable minimum standing/persistent queue delay.
+          Defaults to unset and kernel's default is used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v245"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>IntervalSec=</varname></term>
+        <listitem>
+          <para>Takes a timespan. This is used to ensure that the measured minimum delay does not
+          become too stale. Defaults to unset and kernel's default is used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v245"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ECN=</varname></term>
+        <listitem>
+          <para>Takes a boolean. This can be used to mark packets instead of dropping them. Defaults to
+          unset and kernel's default is used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v245"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>CEThresholdSec=</varname></term>
+        <listitem>
+          <para>Takes a timespan. This sets a threshold above which all packets are marked with ECN
+          Congestion Experienced (CE). Defaults to unset and kernel's default is used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v245"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[DeficitRoundRobinScheduler] Section Options</title>
+    <para>The [DeficitRoundRobinScheduler] section manages the queueing discipline (qdisc) of Deficit Round
+    Robin Scheduler (DRR).</para>
+
+    <variablelist class='network-directives'>
+      <xi:include href="tc.xml" xpointer="qdisc-parent" />
+      <xi:include href="tc.xml" xpointer="qdisc-handle" />
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[DeficitRoundRobinSchedulerClass] Section Options</title>
+    <para>The [DeficitRoundRobinSchedulerClass] section manages the traffic control class of Deficit Round
+    Robin Scheduler (DRR).</para>
+
+    <variablelist class='network-directives'>
+      <xi:include href="tc.xml" xpointer="tclass-parent" />
+      <xi:include href="tc.xml" xpointer="tclass-classid" />
+
+      <varlistentry>
+        <term><varname>QuantumBytes=</varname></term>
+        <listitem>
+          <para>Specifies the amount of bytes a flow is allowed to dequeue before the scheduler moves
+          to the next class. When suffixed with K, M, or G, the specified size is parsed as Kilobytes,
+          Megabytes, or Gigabytes, respectively, to the base of 1024. Defaults to the MTU of the
+          interface.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+        </listitem>
+      </varlistentry>
+
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[EnhancedTransmissionSelection] Section Options</title>
+    <para>The [EnhancedTransmissionSelection] section manages the queueing discipline (qdisc) of Enhanced
+    Transmission Selection (ETS).</para>
+
+    <variablelist class='network-directives'>
+      <xi:include href="tc.xml" xpointer="qdisc-parent" />
+      <xi:include href="tc.xml" xpointer="qdisc-handle" />
+
+      <varlistentry>
+        <term><varname>Bands=</varname></term>
+        <listitem>
+          <para>Specifies the number of bands. An unsigned integer in the range 1…16. This value has to be at
+          least large enough to cover the strict bands specified through the <varname>StrictBands=</varname>
+          and bandwidth-sharing bands specified in <varname>QuantumBytes=</varname>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>StrictBands=</varname></term>
+        <listitem>
+          <para>Specifies the number of bands that should be created in strict mode. An unsigned integer in
+          the range 1…16.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>QuantumBytes=</varname></term>
+        <listitem>
+          <para>Specifies the white-space separated list of quantum used in band-sharing bands. When
+          suffixed with K, M, or G, the specified size is parsed as Kilobytes, Megabytes, or Gigabytes,
+          respectively, to the base of 1024. This setting can be specified multiple times. If an empty
+          string is assigned, then the all previous assignments are cleared.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>PriorityMap=</varname></term>
+        <listitem>
+          <para>The priority map maps the priority of a packet to a band. The argument is a whitespace
+          separated list of numbers. The first number indicates which band the packets with priority 0 should
+          be put to, the second is for priority 1, and so on. There can be up to 16 numbers in the list. If
+          there are fewer, the default band that traffic with one of the unmentioned priorities goes to is
+          the last one. Each band number must be in the range 0…255. This setting can be specified multiple
+          times. If an empty string is assigned, then the all previous assignments are cleared.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[GenericRandomEarlyDetection] Section Options</title>
+    <para>The [GenericRandomEarlyDetection] section manages the queueing discipline (qdisc) of Generic Random
+    Early Detection (GRED).</para>
+
+    <variablelist class='network-directives'>
+      <xi:include href="tc.xml" xpointer="qdisc-parent" />
+      <xi:include href="tc.xml" xpointer="qdisc-handle" />
+
+      <varlistentry>
+        <term><varname>VirtualQueues=</varname></term>
+        <listitem>
+          <para>Specifies the number of virtual queues. Takes an integer in the range 1…16. Defaults to unset
+          and kernel's default is used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>DefaultVirtualQueue=</varname></term>
+        <listitem>
+          <para>Specifies the number of default virtual queue. This must be less than <varname>VirtualQueue=</varname>.
+          Defaults to unset and kernel's default is used.</para>
+
+        <xi:include href="version-info.xml" xpointer="v246"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>GenericRIO=</varname></term>
+        <listitem>
+          <para>Takes a boolean. It turns on the RIO-like buffering scheme. Defaults to
+          unset and kernel's default is used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[FairQueueingControlledDelay] Section Options</title>
+    <para>The [FairQueueingControlledDelay] section manages the queueing discipline (qdisc) of fair queuing
+    controlled delay (FQ-CoDel).</para>
+
+    <variablelist class='network-directives'>
+      <xi:include href="tc.xml" xpointer="qdisc-parent" />
+      <xi:include href="tc.xml" xpointer="qdisc-handle" />
+
+      <varlistentry>
+        <term><varname>PacketLimit=</varname></term>
+        <listitem>
+          <para>Specifies the hard limit on the real queue size. When this limit is reached, incoming packets are
+          dropped. Defaults to unset and kernel's default is used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v245"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>MemoryLimitBytes=</varname></term>
+        <listitem>
+          <para>Specifies the limit on the total number of bytes that can be queued in this FQ-CoDel instance.
+          When suffixed with K, M, or G, the specified size is parsed as Kilobytes, Megabytes, or Gigabytes,
+          respectively, to the base of 1024. Defaults to unset and kernel's default is used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Flows=</varname></term>
+        <listitem>
+          <para>Specifies the number of flows into which the incoming packets are classified.
+          Defaults to unset and kernel's default is used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v245"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>TargetSec=</varname></term>
+        <listitem>
+          <para>Takes a timespan. Specifies the acceptable minimum standing/persistent queue delay.
+          Defaults to unset and kernel's default is used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v245"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>IntervalSec=</varname></term>
+        <listitem>
+          <para>Takes a timespan. This is used to ensure that the measured minimum delay does not
+          become too stale. Defaults to unset and kernel's default is used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v245"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>QuantumBytes=</varname></term>
+        <listitem>
+          <para>Specifies the number of bytes used as the "deficit" in the fair queuing algorithm timespan.
+          When suffixed with K, M, or G, the specified size is parsed as Kilobytes, Megabytes, or Gigabytes,
+          respectively, to the base of 1024. Defaults to unset and kernel's default is used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ECN=</varname></term>
+        <listitem>
+          <para>Takes a boolean. This can be used to mark packets instead of dropping them. Defaults to
+          unset and kernel's default is used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v245"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>CEThresholdSec=</varname></term>
+        <listitem>
+          <para>Takes a timespan. This sets a threshold above which all packets are marked with ECN
+          Congestion Experienced (CE). Defaults to unset and kernel's default is used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v245"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[FairQueueing] Section Options</title>
+    <para>The [FairQueueing] section manages the queueing discipline (qdisc) of fair queue traffic policing
+    (FQ).</para>
+
+    <variablelist class='network-directives'>
+      <xi:include href="tc.xml" xpointer="qdisc-parent" />
+      <xi:include href="tc.xml" xpointer="qdisc-handle" />
+
+      <varlistentry>
+        <term><varname>PacketLimit=</varname></term>
+        <listitem>
+          <para>Specifies the hard limit on the real queue size. When this limit is reached, incoming packets are
+          dropped. Defaults to unset and kernel's default is used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v245"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>FlowLimit=</varname></term>
+        <listitem>
+          <para>Specifies the hard limit on the maximum number of packets queued per flow. Defaults to
+          unset and kernel's default is used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v245"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>QuantumBytes=</varname></term>
+        <listitem>
+          <para>Specifies the credit per dequeue RR round, i.e. the amount of bytes a flow is allowed
+          to dequeue at once. When suffixed with K, M, or G, the specified size is parsed as Kilobytes,
+          Megabytes, or Gigabytes, respectively, to the base of 1024. Defaults to unset and kernel's
+          default is used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>InitialQuantumBytes=</varname></term>
+        <listitem>
+          <para>Specifies the initial sending rate credit, i.e. the amount of bytes a new flow is
+          allowed to dequeue initially. When suffixed with K, M, or G, the specified size is parsed as
+          Kilobytes, Megabytes, or Gigabytes, respectively, to the base of 1024. Defaults to unset and
+          kernel's default is used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v245"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>MaximumRate=</varname></term>
+        <listitem>
+          <para>Specifies the maximum sending rate of a flow. When suffixed with K, M, or G, the
+          specified size is parsed as Kilobits, Megabits, or Gigabits, respectively, to the base of
+          1000. Defaults to unset and kernel's default is used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v245"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Buckets=</varname></term>
+        <listitem>
+          <para>Specifies the size of the hash table used for flow lookups. Defaults to unset and
+          kernel's default is used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v245"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>OrphanMask=</varname></term>
+        <listitem>
+          <para>Takes an unsigned integer. For packets not owned by a socket, fq is able to mask a part
+          of hash and reduce number of buckets associated with the traffic. Defaults to unset and
+          kernel's default is used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v245"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Pacing=</varname></term>
+        <listitem>
+          <para>Takes a boolean, and enables or disables flow pacing. Defaults to unset and kernel's
+          default is used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v245"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>CEThresholdSec=</varname></term>
+        <listitem>
+          <para>Takes a timespan. This sets a threshold above which all packets are marked with ECN
+          Congestion Experienced (CE). Defaults to unset and kernel's default is used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v245"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[TrivialLinkEqualizer] Section Options</title>
+    <para>The [TrivialLinkEqualizer] section manages the queueing discipline (qdisc) of trivial link
+    equalizer (teql).</para>
+
+    <variablelist class='network-directives'>
+      <xi:include href="tc.xml" xpointer="qdisc-parent" />
+      <xi:include href="tc.xml" xpointer="qdisc-handle" />
+
+      <varlistentry>
+        <term><varname>Id=</varname></term>
+        <listitem>
+          <para>Specifies the interface ID <literal>N</literal> of teql. Defaults to <literal>0</literal>.
+          Note that when teql is used, currently, the module <constant>sch_teql</constant> with
+          <constant>max_equalizers=N+1</constant> option must be loaded before
+          <command>systemd-networkd</command> is started.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[HierarchyTokenBucket] Section Options</title>
+    <para>The [HierarchyTokenBucket] section manages the queueing discipline (qdisc) of hierarchy token
+    bucket (htb).</para>
+
+    <variablelist class='network-directives'>
+      <xi:include href="tc.xml" xpointer="qdisc-parent" />
+      <xi:include href="tc.xml" xpointer="qdisc-handle" />
+
+      <varlistentry>
+        <term><varname>DefaultClass=</varname></term>
+        <listitem>
+          <para>Takes the minor id in hexadecimal of the default class. Unclassified traffic gets sent
+          to the class. Defaults to unset.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RateToQuantum=</varname></term>
+        <listitem>
+          <para>Takes an unsigned integer. The DRR quantums are calculated by dividing the value
+          configured in <varname>Rate=</varname> by <varname>RateToQuantum=</varname>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[HierarchyTokenBucketClass] Section Options</title>
+    <para>The [HierarchyTokenBucketClass] section manages the traffic control class of hierarchy token bucket
+    (htb).</para>
+
+    <variablelist class='network-directives'>
+      <xi:include href="tc.xml" xpointer="tclass-parent" />
+      <xi:include href="tc.xml" xpointer="tclass-classid" />
+
+      <varlistentry>
+        <term><varname>Priority=</varname></term>
+        <listitem>
+          <para>Specifies the priority of the class. In the round-robin process, classes with the lowest
+          priority field are tried for packets first.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>QuantumBytes=</varname></term>
+        <listitem>
+          <para>Specifies how many bytes to serve from leaf at once. When suffixed with K, M, or G, the
+          specified size is parsed as Kilobytes, Megabytes, or Gigabytes, respectively, to the base of
+          1024.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>MTUBytes=</varname></term>
+        <listitem>
+          <para>Specifies the maximum packet size we create. When suffixed with K, M, or G, the specified
+          size is parsed as Kilobytes, Megabytes, or Gigabytes, respectively, to the base of 1024.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>OverheadBytes=</varname></term>
+        <listitem>
+          <para>Takes an unsigned integer which specifies per-packet size overhead used in rate
+          computations. When suffixed with K, M, or G, the specified size is parsed as Kilobytes,
+          Megabytes, or Gigabytes, respectively, to the base of 1024.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Rate=</varname></term>
+        <listitem>
+          <para>Specifies the maximum rate this class and all its children are guaranteed. When suffixed
+          with K, M, or G, the specified size is parsed as Kilobits, Megabits, or Gigabits, respectively,
+          to the base of 1000. This setting is mandatory.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>CeilRate=</varname></term>
+        <listitem>
+          <para>Specifies the maximum rate at which a class can send, if its parent has bandwidth to spare.
+          When suffixed with K, M, or G, the specified size is parsed as Kilobits, Megabits, or Gigabits,
+          respectively, to the base of 1000. When unset, the value specified with <varname>Rate=</varname>
+          is used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>BufferBytes=</varname></term>
+        <listitem>
+          <para>Specifies the maximum bytes burst which can be accumulated during idle period. When suffixed
+          with K, M, or G, the specified size is parsed as Kilobytes, Megabytes, or Gigabytes, respectively,
+          to the base of 1024.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>CeilBufferBytes=</varname></term>
+        <listitem>
+          <para>Specifies the maximum bytes burst for ceil which can be accumulated during idle period.
+          When suffixed with K, M, or G, the specified size is parsed as Kilobytes, Megabytes, or Gigabytes,
+          respectively, to the base of 1024.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[HeavyHitterFilter] Section Options</title>
+    <para>The [HeavyHitterFilter] section manages the queueing discipline (qdisc) of Heavy Hitter Filter
+    (hhf).</para>
+
+    <variablelist class='network-directives'>
+      <xi:include href="tc.xml" xpointer="qdisc-parent" />
+      <xi:include href="tc.xml" xpointer="qdisc-handle" />
+
+      <varlistentry>
+        <term><varname>PacketLimit=</varname></term>
+        <listitem>
+          <para>Specifies the hard limit on the queue size in number of packets. When this limit is reached,
+          incoming packets are dropped. An unsigned integer in the range 0…4294967294. Defaults to unset and
+          kernel's default is used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[QuickFairQueueing] Section Options</title>
+    <para>The [QuickFairQueueing] section manages the queueing discipline (qdisc) of Quick Fair Queueing
+    (QFQ).</para>
+
+    <variablelist class='network-directives'>
+      <xi:include href="tc.xml" xpointer="qdisc-parent" />
+      <xi:include href="tc.xml" xpointer="qdisc-handle" />
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[QuickFairQueueingClass] Section Options</title>
+    <para>The [QuickFairQueueingClass] section manages the traffic control class of Quick Fair Queueing
+    (qfq).</para>
+
+    <variablelist class='network-directives'>
+      <xi:include href="tc.xml" xpointer="tclass-parent" />
+      <xi:include href="tc.xml" xpointer="tclass-classid" />
+
+      <varlistentry>
+        <term><varname>Weight=</varname></term>
+        <listitem>
+          <para>Specifies the weight of the class. Takes an integer in the range 1…1023. Defaults to
+          unset in which case the kernel default is used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>MaxPacketBytes=</varname></term>
+        <listitem>
+          <para>Specifies the maximum packet size in bytes for the class. When suffixed with K, M, or G, the
+          specified size is parsed as Kilobytes, Megabytes, or Gigabytes, respectively, to the base of
+          1024. When unset, the kernel default is used.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[BridgeVLAN] Section Options</title>
+      <para>The [BridgeVLAN] section manages the VLAN ID configuration of a bridge port and accepts the
+      following keys. Specify several [BridgeVLAN] sections to configure several VLAN entries. The
+      <varname>VLANFiltering=</varname> option has to be enabled, see the [Bridge] section in
+      <citerefentry><refentrytitle>systemd.netdev</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+
+      <variablelist class='network-directives'>
+        <varlistentry>
+          <term><varname>VLAN=</varname></term>
+          <listitem>
+            <para>The VLAN ID allowed on the port. This can be either a single ID or a range M-N. Takes
+            an integer in the range 1…4094.</para>
+
+            <xi:include href="version-info.xml" xpointer="v231"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>EgressUntagged=</varname></term>
+          <listitem>
+            <para>The VLAN ID specified here will be used to untag frames on egress. Configuring
+            <varname>EgressUntagged=</varname> implicates the use of <varname>VLAN=</varname> above and will enable the
+            VLAN ID for ingress as well. This can be either a single ID or a range M-N.</para>
+
+            <xi:include href="version-info.xml" xpointer="v231"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><varname>PVID=</varname></term>
+          <listitem>
+            <para>The Port VLAN ID specified here is assigned to all untagged frames at ingress.
+            <varname>PVID=</varname> can be used only once. Configuring <varname>PVID=</varname> implicates the use of
+            <varname>VLAN=</varname> above and will enable the VLAN ID for ingress as well.</para>
+
+            <xi:include href="version-info.xml" xpointer="v231"/>
+          </listitem>
+        </varlistentry>
+      </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Examples</title>
+    <example>
+      <title>Static network configuration</title>
+
+      <programlisting># /etc/systemd/network/50-static.network
+[Match]
+Name=enp2s0
+
+[Network]
+Address=192.168.0.15/24
+Gateway=192.168.0.1</programlisting>
+
+      <para>This brings interface <literal>enp2s0</literal> up with a static address. The
+      specified gateway will be used for a default route.</para>
+    </example>
+
+    <example>
+      <title>DHCP on ethernet links</title>
+
+      <programlisting># /etc/systemd/network/80-dhcp.network
+[Match]
+Name=en*
+
+[Network]
+DHCP=yes</programlisting>
+
+      <para>This will enable DHCPv4 and DHCPv6 on all interfaces with names starting with
+      <literal>en</literal> (i.e. ethernet interfaces).</para>
+    </example>
+
+    <example>
+      <title>IPv6 Prefix Delegation (DHCPv6 PD)</title>
+
+      <programlisting># /etc/systemd/network/55-dhcpv6-pd-upstream.network
+[Match]
+Name=enp1s0
+
+[Network]
+DHCP=ipv6
+
+# The below setting is optional, to also assign an address in the delegated prefix
+# to the upstream interface. If not necessary, then comment out the line below and
+# the [DHCPPrefixDelegation] section.
+DHCPPrefixDelegation=yes
+
+# If the upstream network provides Router Advertisement with Managed bit set,
+# then comment out the line below and WithoutRA= setting in the [DHCPv6] section.
+IPv6AcceptRA=no
+
+[DHCPv6]
+WithoutRA=solicit
+
+[DHCPPrefixDelegation]
+UplinkInterface=:self
+SubnetId=0
+Announce=no</programlisting>
+
+      <programlisting># /etc/systemd/network/55-dhcpv6-pd-downstream.network
+[Match]
+Name=enp2s0
+
+[Network]
+DHCPPrefixDelegation=yes
+IPv6SendRA=yes
+
+# It is expected that the host is acting as a router. So, usually it is not
+# necessary to receive Router Advertisement from other hosts in the downstream network.
+IPv6AcceptRA=no
+
+[DHCPPrefixDelegation]
+UplinkInterface=enp1s0
+SubnetId=1
+Announce=yes</programlisting>
+
+      <para>This will enable DHCPv6-PD on the interface enp1s0 as an upstream interface where the
+      DHCPv6 client is running and enp2s0 as a downstream interface where the prefix is delegated to.
+      The delegated prefixes are distributed by IPv6 Router Advertisement on the downstream network.
+      </para>
+    </example>
+
+    <example>
+      <title>IPv6 Prefix Delegation (DHCPv4 6RD)</title>
+
+      <programlisting># /etc/systemd/network/55-dhcpv4-6rd-upstream.network
+[Match]
+Name=enp1s0
+
+[Network]
+DHCP=ipv4
+
+# When DHCPv4-6RD is used, the upstream network does not support IPv6.
+# Hence, it is not necessary to wait for Router Advertisement, which is enabled by default.
+IPv6AcceptRA=no
+
+[DHCPv4]
+Use6RD=yes</programlisting>
+
+      <programlisting># /etc/systemd/network/55-dhcpv4-6rd-downstream.network
+[Match]
+Name=enp2s0
+
+[Network]
+DHCPPrefixDelegation=yes
+IPv6SendRA=yes
+
+# It is expected that the host is acting as a router. So, usually it is not
+# necessary to receive Router Advertisement from other hosts in the downstream network.
+IPv6AcceptRA=no
+
+[DHCPPrefixDelegation]
+UplinkInterface=enp1s0
+SubnetId=1
+Announce=yes</programlisting>
+
+      <para>This will enable DHCPv4-6RD on the interface enp1s0 as an upstream interface where the
+      DHCPv4 client is running and enp2s0 as a downstream interface where the prefix is delegated to.
+      The delegated prefixes are distributed by IPv6 Router Advertisement on the downstream network.
+      </para>
+    </example>
+
+    <example>
+      <title>A bridge with two enslaved links</title>
+
+      <programlisting># /etc/systemd/network/25-bridge-static.netdev
+[NetDev]
+Name=bridge0
+Kind=bridge</programlisting>
+
+      <programlisting># /etc/systemd/network/25-bridge-static.network
+[Match]
+Name=bridge0
+
+[Network]
+Address=192.168.0.15/24
+Gateway=192.168.0.1
+DNS=192.168.0.1</programlisting>
+
+      <programlisting># /etc/systemd/network/25-bridge-slave-interface-1.network
+[Match]
+Name=enp2s0
+
+[Network]
+Bridge=bridge0</programlisting>
+
+      <programlisting># /etc/systemd/network/25-bridge-slave-interface-2.network
+[Match]
+Name=wlp3s0
+
+[Network]
+Bridge=bridge0</programlisting>
+
+      <para>This creates a bridge and attaches devices <literal>enp2s0</literal> and
+      <literal>wlp3s0</literal> to it. The bridge will have the specified static address
+      and network assigned, and a default route via the specified gateway will be
+      added. The specified DNS server will be added to the global list of DNS resolvers.
+      </para>
+    </example>
+
+    <example>
+      <title>Bridge port with VLAN forwarding</title>
+
+      <programlisting>
+# /etc/systemd/network/25-bridge-slave-interface-1.network
+[Match]
+Name=enp2s0
+
+[Network]
+Bridge=bridge0
+
+[BridgeVLAN]
+VLAN=1-32
+PVID=42
+EgressUntagged=42
+
+[BridgeVLAN]
+VLAN=100-200
+
+[BridgeVLAN]
+EgressUntagged=300-400</programlisting>
+
+    <para>This overrides the configuration specified in the previous example for the
+    interface <literal>enp2s0</literal>, and enables VLAN on that bridge port. VLAN IDs
+    1-32, 42, 100-400 will be allowed. Packets tagged with VLAN IDs 42, 300-400 will be
+    untagged when they leave on this interface. Untagged packets which arrive on this
+    interface will be assigned VLAN ID 42.</para>
+    </example>
+
+    <example>
+      <title>Various tunnels</title>
+
+      <programlisting>/etc/systemd/network/25-tunnels.network
+[Match]
+Name=ens1
+
+[Network]
+Tunnel=ipip-tun
+Tunnel=sit-tun
+Tunnel=gre-tun
+Tunnel=vti-tun
+      </programlisting>
+
+      <programlisting>/etc/systemd/network/25-tunnel-ipip.netdev
+[NetDev]
+Name=ipip-tun
+Kind=ipip
+      </programlisting>
+
+      <programlisting>/etc/systemd/network/25-tunnel-sit.netdev
+[NetDev]
+Name=sit-tun
+Kind=sit
+      </programlisting>
+
+      <programlisting>/etc/systemd/network/25-tunnel-gre.netdev
+[NetDev]
+Name=gre-tun
+Kind=gre
+      </programlisting>
+
+      <programlisting>/etc/systemd/network/25-tunnel-vti.netdev
+[NetDev]
+Name=vti-tun
+Kind=vti
+      </programlisting>
+
+      <para>This will bring interface <literal>ens1</literal> up and create an IPIP tunnel,
+      a SIT tunnel, a GRE tunnel, and a VTI tunnel using it.</para>
+    </example>
+
+    <example>
+      <title>A bond device</title>
+
+      <programlisting># /etc/systemd/network/30-bond1.network
+[Match]
+Name=bond1
+
+[Network]
+DHCP=ipv6
+</programlisting>
+
+      <programlisting># /etc/systemd/network/30-bond1.netdev
+[NetDev]
+Name=bond1
+Kind=bond
+</programlisting>
+
+      <programlisting># /etc/systemd/network/30-bond1-dev1.network
+[Match]
+MACAddress=52:54:00:e9:64:41
+
+[Network]
+Bond=bond1
+</programlisting>
+
+      <programlisting># /etc/systemd/network/30-bond1-dev2.network
+[Match]
+MACAddress=52:54:00:e9:64:42
+
+[Network]
+Bond=bond1
+</programlisting>
+
+    <para>This will create a bond device <literal>bond1</literal> and enslave the two
+    devices with MAC addresses 52:54:00:e9:64:41 and 52:54:00:e9:64:42 to it. IPv6 DHCP
+    will be used to acquire an address.</para>
+    </example>
+
+    <example>
+      <title>Virtual Routing and Forwarding (VRF)</title>
+      <para>Add the <literal>bond1</literal> interface to the VRF master interface
+      <literal>vrf1</literal>. This will redirect routes generated on this interface to be
+      within the routing table defined during VRF creation. For kernels before 4.8 traffic
+      won't be redirected towards the VRFs routing table unless specific ip-rules are added.
+      </para>
+      <programlisting># /etc/systemd/network/25-vrf.network
+[Match]
+Name=bond1
+
+[Network]
+VRF=vrf1
+</programlisting>
+    </example>
+
+    <example>
+      <title>MacVTap</title>
+      <para>This brings up a network interface <literal>macvtap-test</literal>
+      and attaches it to <literal>enp0s25</literal>.</para>
+      <programlisting># /usr/lib/systemd/network/25-macvtap.network
+[Match]
+Name=enp0s25
+
+[Network]
+MACVTAP=macvtap-test
+</programlisting>
+    </example>
+
+    <example>
+      <title>A Xfrm interface with physical underlying device.</title>
+
+      <programlisting># /etc/systemd/network/27-xfrm.netdev
+[NetDev]
+Name=xfrm0
+Kind=xfrm
+
+[Xfrm]
+InterfaceId=7</programlisting>
+
+      <programlisting># /etc/systemd/network/27-eth0.network
+[Match]
+Name=eth0
+
+[Network]
+Xfrm=xfrm0</programlisting>
+
+      <para>This creates a <literal>xfrm0</literal> interface and binds it to the <literal>eth0</literal> device.
+      This allows hardware based ipsec offloading to the <literal>eth0</literal> nic.
+      If offloading is not needed, xfrm interfaces can be assigned to the <literal>lo</literal> device.
+      </para>
+    </example>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.link</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.netdev</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-network-generator.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-resolved.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd.nspawn.xml b/man/systemd.nspawn.xml
new file mode 100644
index 0000000..7980619
--- /dev/null
+++ b/man/systemd.nspawn.xml
@@ -0,0 +1,685 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [
+<!ENTITY % entities SYSTEM "custom-entities.ent" >
+%entities;
+]>
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd.nspawn" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd.nspawn</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd.nspawn</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd.nspawn</refname>
+    <refpurpose>Container settings</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>/etc/systemd/nspawn/<replaceable>machine</replaceable>.nspawn</filename></para>
+    <para><filename>/run/systemd/nspawn/<replaceable>machine</replaceable>.nspawn</filename></para>
+    <para><filename>/var/lib/machines/<replaceable>machine</replaceable>.nspawn</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>An nspawn container settings file (suffix <filename>.nspawn</filename>) contains runtime
+    configuration for a local container, and is used by
+    <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
+    Files of this type are named after the containers they define settings for. They are optional, and only
+    required for containers whose execution environment shall differ from the defaults. Files of this type
+    mostly contain settings that may also be set on the <command>systemd-nspawn</command> command line, and
+    make it easier to persistently attach specific settings to specific containers. The syntax of these files
+    is inspired by <filename>.desktop</filename> files, similarly to other configuration files supported by
+    the systemd project. See
+    <citerefentry><refentrytitle>systemd.syntax</refentrytitle><manvolnum>7</manvolnum></citerefentry> for an
+    overview.</para>
+  </refsect1>
+
+  <refsect1>
+    <title><filename>.nspawn</filename> File Discovery</title>
+
+    <para>Files are searched for by appending the <filename>.nspawn</filename> suffix to the machine name of
+    the container, as specified with the <option>--machine=</option> switch of
+    <command>systemd-nspawn</command>, or derived from the directory or image file name. This file is first
+    searched for in <filename>/etc/systemd/nspawn/</filename> and
+    <filename>/run/systemd/nspawn/</filename>. If found there, the settings are read and all of them take
+    full effect (but may still be overridden by corresponding command line arguments). Otherwise, the file
+    will then be searched for next to the image file or in the immediate parent of the root directory of the
+    container. If the file is found there, only a subset of the settings will take effect however. All
+    settings that possibly elevate privileges or grant additional access to resources of the host (such as
+    files or directories) are ignored. To which options this applies is documented below.</para>
+
+    <para>Persistent settings files created and maintained by the
+    administrator (and thus trusted) should be placed in
+    <filename>/etc/systemd/nspawn/</filename>, while automatically
+    downloaded (and thus potentially untrusted) settings files are
+    placed in <filename>/var/lib/machines/</filename> instead (next to
+    the container images), where their security impact is limited. In
+    order to add privileged settings to <filename>.nspawn</filename>
+    files acquired from the image vendor, it is recommended to copy the
+    settings files into <filename>/etc/systemd/nspawn/</filename> and
+    edit them there, so that the privileged options become
+    available. The precise algorithm for how the files are searched and
+    interpreted may be configured with
+    <command>systemd-nspawn</command>'s <option>--settings=</option>
+    switch, see
+    <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    for details.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>[Exec] Section Options</title>
+
+    <para>Settings files may include an [Exec]
+    section, which carries various execution parameters:</para>
+
+    <variablelist class='nspawn-directives'>
+
+      <varlistentry>
+        <term><varname>Boot=</varname></term>
+
+        <listitem><para>Takes a boolean argument, which defaults to off. If enabled, <command>systemd-nspawn</command>
+        will automatically search for an <filename>init</filename> executable and invoke it. In this case, the
+        specified parameters using <varname>Parameters=</varname> are passed as additional arguments to the
+        <filename>init</filename> process. This setting corresponds to the <option>--boot</option> switch on the
+        <command>systemd-nspawn</command> command line. This option may not be combined with
+        <varname>ProcessTwo=yes</varname>. This option is specified by default in the
+        <filename>systemd-nspawn@.service</filename> template unit.</para>
+
+        <xi:include href="version-info.xml" xpointer="v226"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Ephemeral=</varname></term>
+
+        <listitem><para>Takes a boolean argument, which defaults to off, If enabled, the container is run with
+        a temporary snapshot of its file system that is removed immediately when the container terminates.
+        This is equivalent to the <option>--ephemeral</option> command line switch. See
+        <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry> for details
+        about the specific options supported.</para>
+
+        <xi:include href="version-info.xml" xpointer="v240"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ProcessTwo=</varname></term>
+
+        <listitem><para>Takes a boolean argument, which defaults to off. If enabled, the specified program is run as
+        PID 2. A stub init process is run as PID 1. This setting corresponds to the <option>--as-pid2</option> switch
+        on the <command>systemd-nspawn</command> command line. This option may not be combined with
+        <varname>Boot=yes</varname>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v229"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Parameters=</varname></term>
+
+        <listitem><para>Takes a whitespace-separated list of arguments. Single (<literal>'</literal>) and
+        double (<literal>"</literal>) quotes may be used around arguments with whitespace. This is either a
+        command line, beginning with the binary name to execute, or – if <varname>Boot=</varname> is enabled
+        – the list of arguments to pass to the init process. This setting corresponds to the command line
+        parameters passed on the <command>systemd-nspawn</command> command line.</para>
+
+        <para>Note: <option>Boot=no</option>, <option>Parameters=a b "c c"</option> is the same as
+        <command>systemd-nspawn a b "c c"</command>, and <option>Boot=yes</option>, <option>Parameters=b 'c c'</option>
+        is the same as <command>systemd-nspawn --boot b 'c c'</command>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v226"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Environment=</varname></term>
+
+        <listitem><para>Takes an environment variable assignment
+        consisting of key and value, separated by
+        <literal>=</literal>. Sets an environment variable for the
+        main process invoked in the container. This setting may be
+        used multiple times to set multiple environment variables. It
+        corresponds to the <option>--setenv=</option> command line
+        switch.</para>
+
+        <xi:include href="version-info.xml" xpointer="v226"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>User=</varname></term>
+
+        <listitem><para>Takes a UNIX user name. Specifies the user
+        name to invoke the main process of the container as. This user
+        must be known in the container's user database. This
+        corresponds to the <option>--user=</option> command line
+        switch.</para>
+
+        <xi:include href="version-info.xml" xpointer="v226"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>WorkingDirectory=</varname></term>
+
+        <listitem><para>Selects the working directory for the process invoked in the container. Expects an absolute
+        path in the container's file system namespace. This corresponds to the <option>--chdir=</option> command line
+        switch.</para>
+
+        <xi:include href="version-info.xml" xpointer="v229"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>PivotRoot=</varname></term>
+
+        <listitem><para>Selects a directory to pivot to <filename>/</filename> inside the container when starting up.
+        Takes a single path, or a pair of two paths separated by a colon. Both paths must be absolute, and are resolved
+        in the container's file system namespace. This corresponds to the <option>--pivot-root=</option> command line
+        switch.</para>
+
+        <xi:include href="version-info.xml" xpointer="v233"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Capability=</varname></term>
+        <term><varname>DropCapability=</varname></term>
+
+        <listitem><para>Takes a space-separated list of Linux process
+        capabilities (see
+        <citerefentry project='man-pages'><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+        for details). The <varname>Capability=</varname> setting
+        specifies additional capabilities to pass on top of the
+        default set of capabilities. The
+        <varname>DropCapability=</varname> setting specifies
+        capabilities to drop from the default set. These settings
+        correspond to the <option>--capability=</option> and
+        <option>--drop-capability=</option> command line
+        switches. Note that <varname>Capability=</varname> is a
+        privileged setting, and only takes effect in
+        <filename>.nspawn</filename> files in
+        <filename>/etc/systemd/nspawn/</filename> and
+        <filename>/run/system/nspawn/</filename> (see above). On the
+        other hand, <varname>DropCapability=</varname> takes effect in
+        all cases. If the special value <literal>all</literal> is passed, all
+        capabilities are retained (or dropped).</para>
+        <para>These settings change the bounding set of capabilities which
+        also limits the ambient capabilities as given with the
+        <varname>AmbientCapability=</varname>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v226"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>AmbientCapability=</varname></term>
+        <listitem><para>Takes a space-separated list of Linux process
+        capabilities (see
+        <citerefentry project='man-pages'><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+        for details). The <varname>AmbientCapability=</varname> setting
+        specifies capabilities which will be passed to the started program
+        in the inheritable and ambient capability sets. This will grant
+        these capabilities to this process. This setting correspond to
+        the <option>--ambient-capability=</option> command line switch.
+        </para>
+
+        <para>The value <literal>all</literal> is not supported for this
+        setting.</para>
+
+        <para>The setting of <varname>AmbientCapability=</varname> must
+        be covered by the bounding set settings which were established by
+        <varname>Capability=</varname> and <varname>DropCapability=</varname>.
+        </para>
+
+        <para>Note that <varname>AmbientCapability=</varname> is a privileged
+        setting (see above).</para>
+
+        <xi:include href="version-info.xml" xpointer="v248"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>NoNewPrivileges=</varname></term>
+
+        <listitem><para>Takes a boolean argument that controls the <constant>PR_SET_NO_NEW_PRIVS</constant> flag for
+        the container payload. This is equivalent to the
+        <option>--no-new-privileges=</option> command line switch. See
+        <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry> for
+        details.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>KillSignal=</varname></term>
+
+        <listitem><para>Specify the process signal to send to the
+        container's PID 1 when nspawn itself receives SIGTERM, in
+        order to trigger an orderly shutdown of the container.
+        Defaults to SIGRTMIN+3 if <option>Boot=</option> is used
+        (on systemd-compatible init systems SIGRTMIN+3 triggers an
+        orderly shutdown). For a list of valid signals, see
+        <citerefentry project='man-pages'><refentrytitle>signal</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v230"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Personality=</varname></term>
+
+        <listitem><para>Configures the kernel personality for the
+        container. This is equivalent to the
+        <option>--personality=</option> switch.</para>
+
+        <xi:include href="version-info.xml" xpointer="v226"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>MachineID=</varname></term>
+
+        <listitem><para>Configures the 128-bit machine ID (UUID) to pass to
+        the container. This is equivalent to the
+        <option>--uuid=</option> command line switch. This option is
+        privileged (see above). </para>
+
+        <xi:include href="version-info.xml" xpointer="v226"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>PrivateUsers=</varname></term>
+
+        <listitem><para>Configures support for usernamespacing. This is equivalent to the
+        <option>--private-users=</option> command line switch, and takes the same options. This option is privileged
+        (see above). This option is the default if the <filename>systemd-nspawn@.service</filename> template unit file
+        is used.</para>
+
+        <xi:include href="version-info.xml" xpointer="v230"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>NotifyReady=</varname></term>
+
+        <listitem><para>Configures support for notifications from the container's init process.  This is equivalent to
+        the <option>--notify-ready=</option> command line switch, and takes the same parameters. See
+        <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry> for details
+        about the specific options supported.</para>
+
+        <xi:include href="version-info.xml" xpointer="v231"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SystemCallFilter=</varname></term>
+
+        <listitem><para>Configures the system call filter applied to containers. This is equivalent to the
+        <option>--system-call-filter=</option> command line switch, and takes the same list parameter. See
+        <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry> for
+        details.</para>
+
+        <xi:include href="version-info.xml" xpointer="v235"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>LimitCPU=</varname></term>
+        <term><varname>LimitFSIZE=</varname></term>
+        <term><varname>LimitDATA=</varname></term>
+        <term><varname>LimitSTACK=</varname></term>
+        <term><varname>LimitCORE=</varname></term>
+        <term><varname>LimitRSS=</varname></term>
+        <term><varname>LimitNOFILE=</varname></term>
+        <term><varname>LimitAS=</varname></term>
+        <term><varname>LimitNPROC=</varname></term>
+        <term><varname>LimitMEMLOCK=</varname></term>
+        <term><varname>LimitLOCKS=</varname></term>
+        <term><varname>LimitSIGPENDING=</varname></term>
+        <term><varname>LimitMSGQUEUE=</varname></term>
+        <term><varname>LimitNICE=</varname></term>
+        <term><varname>LimitRTPRIO=</varname></term>
+        <term><varname>LimitRTTIME=</varname></term>
+
+        <listitem><para>Configures various types of resource limits applied to containers. This is equivalent to the
+        <option>--rlimit=</option> command line switch, and takes the same arguments. See
+        <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry> for
+        details.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>OOMScoreAdjust=</varname></term>
+
+        <listitem><para>Configures the OOM score adjustment value. This is equivalent to the
+        <option>--oom-score-adjust=</option> command line switch, and takes the same argument. See
+        <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry> for
+        details.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>CPUAffinity=</varname></term>
+
+        <listitem><para>Configures the CPU affinity. This is equivalent to the <option>--cpu-affinity=</option> command
+        line switch, and takes the same argument. See
+        <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry> for
+        details.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Hostname=</varname></term>
+
+        <listitem><para>Configures the kernel hostname set for the container. This is equivalent to the
+        <option>--hostname=</option> command line switch, and takes the same argument. See
+        <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry> for
+        details.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ResolvConf=</varname></term>
+
+        <listitem><para>Configures how <filename>/etc/resolv.conf</filename> in the container shall be handled. This is
+        equivalent to the <option>--resolv-conf=</option> command line switch, and takes the same argument. See
+        <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry> for
+        details.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Timezone=</varname></term>
+
+        <listitem><para>Configures how <filename>/etc/localtime</filename> in the container shall be handled. This is
+        equivalent to the <option>--timezone=</option> command line switch, and takes the same argument. See
+        <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry> for
+        details.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>LinkJournal=</varname></term>
+
+        <listitem><para>Configures how to link host and container journal setups. This is equivalent to the
+        <option>--link-journal=</option> command line switch, and takes the same parameter. See
+        <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry> for
+        details.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SuppressSync=</varname></term>
+
+        <listitem><para>Configures whether to suppress disk synchronization for the container payload. This
+        is equivalent to the <option>--suppress-sync=</option> command line switch, and takes the same
+        parameter. See
+        <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+        for details.</para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[Files] Section Options</title>
+
+    <para>Settings files may include a [Files]
+    section, which carries various parameters configuring the file
+    system of the container:</para>
+
+    <variablelist class='nspawn-directives'>
+
+      <varlistentry>
+        <term><varname>ReadOnly=</varname></term>
+
+        <listitem><para>Takes a boolean argument, which defaults to off. If
+        specified, the container will be run with a read-only file
+        system. This setting corresponds to the
+        <option>--read-only</option> command line
+        switch.</para>
+
+        <xi:include href="version-info.xml" xpointer="v226"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Volatile=</varname></term>
+
+        <listitem><para>Takes a boolean argument, or the special value
+        <literal>state</literal>. This configures whether to run the
+        container with volatile state and/or configuration. This
+        option is equivalent to <option>--volatile=</option>, see
+        <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+        for details about the specific options
+        supported.</para>
+
+        <xi:include href="version-info.xml" xpointer="v226"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Bind=</varname></term>
+        <term><varname>BindReadOnly=</varname></term>
+
+        <listitem><para>Adds a bind mount from the host into the
+        container. Takes a single path, a pair of two paths separated
+        by a colon, or a triplet of two paths plus an option string
+        separated by colons. This option may be used multiple times to
+        configure multiple bind mounts. This option is equivalent to
+        the command line switches <option>--bind=</option> and
+        <option>--bind-ro=</option>, see
+        <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+        for details about the specific options supported. This setting
+        is privileged (see above).</para>
+
+        <xi:include href="version-info.xml" xpointer="v226"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>BindUser=</varname></term>
+
+        <listitem><para>Binds a user from the host into the container. This option is equivalent to the
+        command line switch <option>--bind-user=</option>, see
+        <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+        for details about the specific options supported. This setting is privileged (see
+        above).</para>
+
+        <xi:include href="version-info.xml" xpointer="v249"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>TemporaryFileSystem=</varname></term>
+
+        <listitem><para>Adds a <literal>tmpfs</literal> mount to the
+        container. Takes a path or a pair of path and option string,
+        separated by a colon. This option may be used multiple times to
+        configure multiple <literal>tmpfs</literal> mounts. This
+        option is equivalent to the command line switch
+        <option>--tmpfs=</option>, see
+        <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+        for details about the specific options supported. This setting
+        is privileged (see above).</para>
+
+        <xi:include href="version-info.xml" xpointer="v226"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Inaccessible=</varname></term>
+
+        <listitem><para>Masks the specified file or directory in the container, by over-mounting it with an empty file
+        node of the same type with the most restrictive access mode. Takes a file system path as argument. This option
+        may be used multiple times to mask multiple files or directories. This option is equivalent to the command line
+        switch <option>--inaccessible=</option>, see
+        <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry> for details
+        about the specific options supported. This setting is privileged (see above).</para>
+
+        <xi:include href="version-info.xml" xpointer="v242"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Overlay=</varname></term>
+        <term><varname>OverlayReadOnly=</varname></term>
+
+        <listitem><para>Adds an overlay mount point. Takes a colon-separated list of paths.  This option may be used
+        multiple times to configure multiple overlay mounts. This option is equivalent to the command line switches
+        <option>--overlay=</option> and <option>--overlay-ro=</option>, see
+        <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry> for details
+        about the specific options supported. This setting is privileged (see above).</para>
+
+        <xi:include href="version-info.xml" xpointer="v233"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>PrivateUsersOwnership=</varname></term>
+
+        <listitem><para>Configures whether the ownership of the files and directories in the container tree
+        shall be adjusted to the UID/GID range used, if necessary and user namespacing is enabled. This is
+        equivalent to the <option>--private-users-ownership=</option> command line switch. This option is
+        privileged (see above).</para>
+
+        <xi:include href="version-info.xml" xpointer="v249"/></listitem>
+      </varlistentry>
+
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[Network] Section Options</title>
+
+    <para>Settings files may include a [Network]
+    section, which carries various parameters configuring the network
+    connectivity of the container:</para>
+
+    <variablelist class='nspawn-directives'>
+
+      <varlistentry>
+        <term><varname>Private=</varname></term>
+
+        <listitem><para>Takes a boolean argument, which defaults to off. If
+        enabled, the container will run in its own network namespace
+        and not share network interfaces and configuration with the
+        host. This setting corresponds to the
+        <option>--private-network</option> command line
+        switch.</para>
+
+        <xi:include href="version-info.xml" xpointer="v226"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>VirtualEthernet=</varname></term>
+
+        <listitem><para>Takes a boolean argument. Configures whether to create a virtual Ethernet connection
+        (<literal>veth</literal>) between host and the container. This setting implies
+        <varname>Private=yes</varname>. This setting corresponds to the <option>--network-veth</option> command line
+        switch. This option is privileged (see above). This option is the default if the
+        <filename>systemd-nspawn@.service</filename> template unit file is used.</para>
+
+        <xi:include href="version-info.xml" xpointer="v226"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>VirtualEthernetExtra=</varname></term>
+
+        <listitem><para>Takes a colon-separated pair of interface names. Configures an additional virtual
+        Ethernet connection (<literal>veth</literal>) between host and the container. The first specified
+        name is the interface name on the host, the second the interface name in the container. The latter
+        may be omitted in which case it is set to the same name as the host side interface. This setting
+        implies <varname>Private=yes</varname>. This setting corresponds to the
+        <option>--network-veth-extra=</option> command line switch, and may be used multiple times. It is
+        independent of <varname>VirtualEthernet=</varname>. Note that this option is unrelated to the
+        <varname>Bridge=</varname> setting below, and thus any connections created this way are not
+        automatically added to any bridge device on the host side. This option is privileged (see
+        above).</para>
+
+        <xi:include href="version-info.xml" xpointer="v228"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Interface=</varname></term>
+
+        <listitem><para>Takes a space-separated list of interfaces to add to the container.
+        The interface object is defined either by a single interface name, referencing the name on the host,
+        or a colon-separated pair of interfaces, in which case the first one references the name on the host,
+        and the second one the name in the container.
+        This option corresponds to the
+        <option>--network-interface=</option> command line switch and
+        implies <varname>Private=yes</varname>. This option is
+        privileged (see above).</para>
+
+        <xi:include href="version-info.xml" xpointer="v226"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>MACVLAN=</varname></term>
+        <term><varname>IPVLAN=</varname></term>
+
+        <listitem><para>Takes a space-separated list of interfaces to
+        add MACLVAN or IPVLAN interfaces to, which are then added to
+        the container. The interface object is defined either by a single interface name, referencing the name
+        on the host, or a colon-separated pair of interfaces, in which case the first one references the name
+        on the host, and the second one the name in the container. These options correspond to the
+        <option>--network-macvlan=</option> and
+        <option>--network-ipvlan=</option> command line switches and
+        imply <varname>Private=yes</varname>. These options are
+        privileged (see above).</para>
+
+        <xi:include href="version-info.xml" xpointer="v226"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Bridge=</varname></term>
+
+        <listitem><para>Takes an interface name. This setting implies
+        <varname>VirtualEthernet=yes</varname> and
+        <varname>Private=yes</varname> and has the effect that the
+        host side of the created virtual Ethernet link is connected to
+        the specified bridge interface. This option corresponds to the
+        <option>--network-bridge=</option> command line switch. This
+        option is privileged (see above).</para>
+
+        <xi:include href="version-info.xml" xpointer="v226"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Zone=</varname></term>
+
+        <listitem><para>Takes a network zone name. This setting implies <varname>VirtualEthernet=yes</varname> and
+        <varname>Private=yes</varname> and has the effect that the host side of the created virtual Ethernet link is
+        connected to an automatically managed bridge interface named after the passed argument, prefixed with
+        <literal>vz-</literal>. This option corresponds to the <option>--network-zone=</option> command line
+        switch. This option is privileged (see above).</para>
+
+        <xi:include href="version-info.xml" xpointer="v230"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Port=</varname></term>
+
+        <listitem><para>Exposes a TCP or UDP port of the container on
+        the host. This option corresponds to the
+        <option>--port=</option> command line switch, see
+        <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+        for the precise syntax of the argument this option takes. This
+        option is privileged (see above).</para>
+
+        <xi:include href="version-info.xml" xpointer="v226"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd.offline-updates.xml b/man/systemd.offline-updates.xml
new file mode 100644
index 0000000..7285f9e
--- /dev/null
+++ b/man/systemd.offline-updates.xml
@@ -0,0 +1,169 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd.offline-updates">
+  <refentryinfo>
+    <title>systemd.offline-updates</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd.offline-updates</refentrytitle>
+    <manvolnum>7</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd.offline-updates</refname>
+    <refpurpose>Implementation of offline updates in systemd</refpurpose>
+  </refnamediv>
+
+  <refsect1>
+    <title>Implementing Offline System Updates</title>
+
+    <para>This man page describes how to implement "offline" system updates with systemd. By "offline"
+    OS updates we mean package installations and updates that are run with the system booted into a
+    special system update mode, in order to avoid problems related to conflicts of libraries and
+    services that are currently running with those on disk. This document is inspired by this
+    <ulink url="https://wiki.gnome.org/Design/OS/SoftwareUpdates">GNOME design whiteboard</ulink>.
+    </para>
+
+    <para>The logic:</para>
+
+    <orderedlist>
+      <listitem>
+        <para>The package manager prepares system updates by downloading all (.rpm or .deb or
+        whatever) packages to update off-line in a special directory
+        <filename index="false">/var/lib/system-update</filename> (or
+        another directory of the package/upgrade manager's choice).</para>
+      </listitem>
+
+      <listitem>
+        <para>When the user OK'ed the update, the symlink <filename>/system-update</filename> or
+        <filename>/etc/system-update</filename> is created that points to
+        <filename index="false">/var/lib/system-update</filename> (or wherever the directory with
+        the upgrade files is located) and the system is rebooted. This symlink is in the root
+        directory, since we need to check for it very early at boot, at a time where
+        <filename>/var/</filename> is not available yet.</para>
+      </listitem>
+
+      <listitem>
+        <para>Very early in the new boot
+        <citerefentry><refentrytitle>systemd-system-update-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        checks whether <filename>/system-update</filename> or
+        <filename>/etc/system-update</filename> exists. If so, it (temporarily and for this boot
+        only) redirects (i.e. symlinks) <filename>default.target</filename> to
+        <filename>system-update.target</filename>, a special target that pulls in the base system
+        (i.e. <filename>sysinit.target</filename>, so that all file systems are mounted but little
+        else) and the system update units.</para>
+      </listitem>
+
+      <listitem>
+        <para>The system now continues to boot into <filename>default.target</filename>, and
+        thus into <filename>system-update.target</filename>. This target pulls in all system
+        update units. Only one service should perform an update (see the next point), and all
+        the other ones should exit cleanly with a "success" return code and without doing
+        anything. Update services should be ordered after <filename>sysinit.target</filename>
+        so that the update starts after all file systems have been mounted.</para>
+      </listitem>
+
+      <listitem>
+        <para>As the first step, an update service should check if the
+        <filename>/system-update</filename> or <filename>/etc/system-update</filename> symlink
+        points to the location used by that update service. In case it does not exist or points to a
+        different location, the service must exit without error. It is possible for multiple update
+        services to be installed, and for multiple update services to be launched in parallel, and
+        only the one that corresponds to the tool that <emphasis>created</emphasis> the symlink
+        before reboot should perform any actions. It is unsafe to run multiple updates in
+        parallel.</para>
+      </listitem>
+
+      <listitem>
+        <para>The update service should now do its job. If applicable and possible, it should
+        create a file system snapshot, then install all packages.  After completion (regardless
+        whether the update succeeded or failed) the machine must be rebooted, for example by
+        calling <command>systemctl reboot</command>. In addition, on failure the script should
+        revert to the old file system snapshot (without the symlink).</para>
+      </listitem>
+
+      <listitem>
+        <para>The update scripts should exit only after the update is finished. It is expected
+        that the service which performs the update will cause the machine to reboot after it
+        is done. If the <filename>system-update.target</filename> is successfully reached, i.e.
+        all update services have run, and the <filename>/system-update</filename> or
+        <filename>/etc/system-update</filename> symlink still exists, it will be removed and
+        the machine rebooted as a safety measure.</para>
+      </listitem>
+
+      <listitem>
+        <para>After a reboot, now that the <filename>/system-update</filename> and
+        <filename>/etc/system-update</filename> symlink is gone, the generator won't redirect
+        <filename>default.target</filename> anymore and the system now boots into the default
+        target again.</para>
+      </listitem>
+    </orderedlist>
+  </refsect1>
+
+  <refsect1>
+    <title>Recommendations</title>
+
+    <orderedlist>
+      <listitem>
+        <para>To make things a bit more robust we recommend hooking the update script into
+        <filename>system-update.target</filename> via a <filename index="false">.wants/</filename>
+        symlink in the distribution package, rather than depending on <command>systemctl
+        enable</command> in the postinst scriptlets of your package. More specifically, for your
+        update script create a .service file, without [Install] section, and then add a symlink like
+        <filename index="false">/usr/lib/systemd/system/system-update.target.wants/foobar.service</filename>
+        → <filename index="false">../foobar.service</filename> to your package.</para>
+      </listitem>
+
+      <listitem>
+        <para>Make sure to remove the <filename>/system-update</filename> and
+        <filename>/etc/system-update</filename> symlinks as early as possible in the update
+        script to avoid reboot loops in case the update fails.</para>
+      </listitem>
+
+      <listitem>
+        <para>Use <varname>FailureAction=reboot</varname> in the service file for your update script
+        to ensure that a reboot is automatically triggered if the update fails.
+        <varname>FailureAction=</varname> makes sure that the specified unit is activated if your
+        script exits uncleanly (by non-zero error code, or signal/coredump). If your script succeeds
+        you should trigger the reboot in your own code, for example by invoking logind's
+        <command>Reboot()</command> call or calling <command>systemctl reboot</command>. See
+        <citerefentry><refentrytitle>org.freedesktop.login1</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for details about the logind D-Bus API.</para>
+      </listitem>
+
+      <listitem>
+        <para>The update service should declare <varname>DefaultDependencies=no</varname>,
+        <varname>Requires=sysinit.target</varname>, <varname>After=sysinit.target</varname>,
+        <varname>After=system-update-pre.target</varname>, <varname>Before=system-update.target</varname>
+        and explicitly pull in any other services it requires.</para>
+      </listitem>
+
+      <listitem>
+        <para>It may be desirable to always run an auxiliary unit when booting
+        into offline-updates mode, which itself does not install updates. To
+        do this create a .service file with
+        <varname>Wants=system-update-pre.target</varname> and
+        <varname>Before=system-update-pre.target</varname> and add a symlink
+        to that file under
+        <filename index="false">/usr/lib/systemd/system-update.target.wants</filename>
+        .</para>
+      </listitem>
+    </orderedlist>
+  </refsect1>
+
+  <refsect1>
+    <title>See also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-system-update-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry project='mankier'><refentrytitle>dnf.plugin.system-upgrade</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+</refentry>
diff --git a/man/systemd.path.xml b/man/systemd.path.xml
new file mode 100644
index 0000000..7037465
--- /dev/null
+++ b/man/systemd.path.xml
@@ -0,0 +1,227 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd.path" xmlns:xi="http://www.w3.org/2001/XInclude">
+  <refentryinfo>
+    <title>systemd.path</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd.path</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd.path</refname>
+    <refpurpose>Path unit configuration</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename><replaceable>path</replaceable>.path</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>A unit configuration file whose name ends in
+    <literal>.path</literal> encodes information about a path
+    monitored by systemd, for path-based activation.</para>
+
+    <para>This man page lists the configuration options specific to
+    this unit type. See
+    <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for the common options of all unit configuration files. The common
+    configuration items are configured in the generic [Unit] and
+    [Install] sections. The path specific configuration options are
+    configured in the [Path] section.</para>
+
+    <para>For each path file, a matching unit file must exist,
+    describing the unit to activate when the path changes. By default,
+    a service by the same name as the path (except for the suffix) is
+    activated. Example: a path file <filename>foo.path</filename>
+    activates a matching service <filename>foo.service</filename>. The
+    unit to activate may be controlled by <varname>Unit=</varname>
+    (see below).</para>
+
+    <para>Internally, path units use the
+    <citerefentry project='man-pages'><refentrytitle>inotify</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+    API to monitor file systems. Due to that, it suffers by the same
+    limitations as inotify, and for example cannot be used to monitor
+    files or directories changed by other machines on remote NFS file
+    systems.</para>
+
+    <para>When a service unit triggered by a path unit terminates (regardless whether it exited successfully
+    or failed), monitored paths are checked immediately again, and the service accordingly restarted
+    instantly. As protection against busy looping in this trigger/start cycle, a start rate limit is enforced
+    on the service unit, see <varname>StartLimitIntervalSec=</varname> and
+    <varname>StartLimitBurst=</varname> in
+    <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>. Unlike
+    other service failures, the error condition that the start rate limit is hit is propagated from the
+    service unit to the path unit and causes the path unit to fail as well, thus ending the loop.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Automatic Dependencies</title>
+
+    <refsect2>
+      <title>Implicit Dependencies</title>
+
+      <para>The following dependencies are implicitly added:</para>
+
+      <itemizedlist>
+        <listitem><para>If a path unit is beneath another mount unit in the file
+        system hierarchy, both a requirement and an ordering dependency
+        between both units are created automatically.</para></listitem>
+
+        <listitem><para>An implicit <varname>Before=</varname> dependency is added
+        between a path unit and the unit it is supposed to activate.</para></listitem>
+      </itemizedlist>
+    </refsect2>
+
+    <refsect2>
+      <title>Default Dependencies</title>
+
+      <para>The following dependencies are added unless <varname>DefaultDependencies=no</varname> is set:</para>
+
+      <itemizedlist>
+        <listitem><para>Path units will automatically have dependencies of type <varname>Before=</varname> on
+        <filename>paths.target</filename>,
+        dependencies of type <varname>After=</varname> and <varname>Requires=</varname> on
+        <filename>sysinit.target</filename>, and have dependencies of type <varname>Conflicts=</varname> and
+        <varname>Before=</varname> on <filename>shutdown.target</filename>. These ensure that path units are terminated
+        cleanly prior to system shutdown. Only path units involved with early boot or late system shutdown should
+        disable <varname>DefaultDependencies=</varname> option.</para></listitem>
+      </itemizedlist>
+
+      <para></para>
+    </refsect2>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>Path unit files may include [Unit] and [Install] sections, which are described in
+    <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+    </para>
+
+    <para>Path unit files must include a [Path] section, which carries information about the path or paths it
+    monitors. The options specific to the [Path] section of path units are the following:</para>
+
+    <variablelist class='unit-directives'>
+      <varlistentry>
+        <term><varname>PathExists=</varname></term>
+        <term><varname>PathExistsGlob=</varname></term>
+        <term><varname>PathChanged=</varname></term>
+        <term><varname>PathModified=</varname></term>
+        <term><varname>DirectoryNotEmpty=</varname></term>
+
+        <listitem><para>Defines paths to monitor for certain changes:
+        <varname>PathExists=</varname> may be used to watch the mere
+        existence of a file or directory. If the file specified
+        exists, the configured unit is activated.
+        <varname>PathExistsGlob=</varname> works similarly, but checks
+        for the existence of at least one file matching the globbing
+        pattern specified. <varname>PathChanged=</varname> may be used
+        to watch a file or directory and activate the configured unit
+        whenever it changes. It is not activated on every write to the
+        watched file but it is activated if the file which was open
+        for writing gets closed. <varname>PathModified=</varname> is
+        similar, but additionally it is activated also on simple
+        writes to the watched file.
+        <varname>DirectoryNotEmpty=</varname> may be used to watch a
+        directory and activate the configured unit whenever it
+        contains at least one file.</para>
+
+        <para>The arguments of these directives must be absolute file
+        system paths.</para>
+
+        <para>Multiple directives may be combined, of the same and of
+        different types, to watch multiple paths. If the empty string
+        is assigned to any of these options, the list of paths to
+        watch is reset, and any prior assignments of these options
+        will not have any effect.</para>
+
+        <para>If a path already exists (in case of
+        <varname>PathExists=</varname> and
+        <varname>PathExistsGlob=</varname>) or a directory already is
+        not empty (in case of <varname>DirectoryNotEmpty=</varname>)
+        at the time the path unit is activated, then the configured
+        unit is immediately activated as well. Something similar does
+        not apply to <varname>PathChanged=</varname> and
+        <varname>PathModified=</varname>.</para>
+
+        <para>If the path itself or any of the containing directories
+        are not accessible, <command>systemd</command> will watch for
+        permission changes and notice that conditions are satisfied
+        when permissions allow that. </para></listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>Unit=</varname></term>
+
+        <listitem><para>The unit to activate when any of the
+        configured paths changes. The argument is a unit name, whose
+        suffix is not <literal>.path</literal>. If not specified, this
+        value defaults to a service that has the same name as the path
+        unit, except for the suffix. (See above.) It is recommended
+        that the unit name that is activated and the unit name of the
+        path unit are named identical, except for the
+        suffix.</para></listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>MakeDirectory=</varname></term>
+
+        <listitem><para>Takes a boolean argument. If true, the
+        directories to watch are created before watching. This option
+        is ignored for <varname>PathExists=</varname> settings.
+        Defaults to <option>false</option>.</para></listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>DirectoryMode=</varname></term>
+
+        <listitem><para>If <varname>MakeDirectory=</varname> is
+        enabled, use the mode specified here to create the directories
+        in question. Takes an access mode in octal notation. Defaults
+        to <option>0755</option>.</para></listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><varname>TriggerLimitIntervalSec=</varname></term>
+        <term><varname>TriggerLimitBurst=</varname></term>
+
+        <listitem><para>Configures a limit on how often this path unit may be activated within a specific
+        time interval. The <varname>TriggerLimitIntervalSec=</varname> may be used to configure the length of
+        the time interval in the usual time units <literal>us</literal>, <literal>ms</literal>,
+        <literal>s</literal>, <literal>min</literal>, <literal>h</literal>, … and defaults to 2s. See
+        <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
+        details on the various time units understood. The <varname>TriggerLimitBurst=</varname> setting takes
+        a positive integer value and specifies the number of permitted activations per time interval, and
+        defaults to 200. Set either to 0 to disable any form of trigger rate limiting. If the limit is hit,
+        the unit is placed into a failure mode, and will not watch the paths anymore until restarted. Note
+        that this limit is enforced before the service activation is enqueued.</para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+    </variablelist>
+
+    <xi:include href="systemd.service.xml" xpointer="shared-unit-options" />
+  </refsect1>
+
+  <refsect1>
+      <title>See Also</title>
+      <para>Environment variables with details on the trigger will be set for triggered units. See the
+      section <literal>Environment Variables Set or Propagated by the Service Manager</literal> in
+      <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+      for more details.</para>
+      <para>
+        <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry project='man-pages'><refentrytitle>inotify</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+      </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd.pcrlock.xml b/man/systemd.pcrlock.xml
new file mode 100644
index 0000000..5687db5
--- /dev/null
+++ b/man/systemd.pcrlock.xml
@@ -0,0 +1,298 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<refentry id="systemd.pcrlock"
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd.pcrlock</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd.pcrlock</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd.pcrlock</refname>
+    <refname>systemd.pcrlock.d</refname>
+    <refpurpose>PCR measurement prediction files</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><literallayout>
+<filename>/etc/pcrlock.d/*.pcrlock</filename>
+<filename>/etc/pcrlock.d/*.pcrlock.d/*.pcrlock</filename>
+<filename>/run/pcrlock.d/*.pcrlock</filename>
+<filename>/run/pcrlock.d/*.pcrlock.d/*.pcrlock</filename>
+<filename>/var/lib/pcrlock.d/*.pcrlock</filename>
+<filename>/var/lib/pcrlock.d/*.pcrlock.d/*.pcrlock</filename>
+<filename>/usr/local/pcrlock.d/*.pcrlock</filename>
+<filename>/usr/local/pcrlock.d/*.pcrlock.d/*.pcrlock</filename>
+<filename>/usr/lib/pcrlock.d/*.pcrlock</filename>
+<filename>/usr/lib/pcrlock.d/*.pcrlock.d/*.pcrlock</filename></literallayout></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><filename>*.pcrlock</filename> files define expected TPM2 PCR measurements of components involved
+    in the boot
+    process. <citerefentry><refentrytitle>systemd-pcrlock</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    uses such pcrlock files to analyze and predict TPM2 PCR measurements. The pcrlock files are JSON arrays
+    that follow a subset of the <ulink
+    url="https://trustedcomputinggroup.org/resource/canonical-event-log-format/">TCG Common Event Log Format
+    (CEL-JSON)</ulink> specification. Specifically the <literal>recnum</literal>, <literal>content</literal>,
+    and <literal>content_type</literal> record fields are not used and ignored if present. Each pcrlock file
+    defines one set of expected, ordered PCR measurements of a specific component of the boot.</para>
+
+    <para>*.pcrlock files may be placed in various <filename>.d/</filename> drop-in directories (see above
+    for a full list). All matching files discovered in these directories are sorted alphabetically by their
+    file name (without taking the actual directory they were found in into account): pcrlock files with
+    alphabetically earlier names are expected to cover measurements done before those with alphabetically
+    later names. In order to make positioning pcrlock files in the boot process convenient the files are
+    expected (by convention, this is not enforced) to be named
+    <literal><replaceable>NNN</replaceable>-<replaceable>component</replaceable>.pcrlock</literal> (where
+    <replaceable>NNN</replaceable> is a three-digit decimal number), for example
+    <filename>750-enter-initrd.pcrlock</filename>.</para>
+
+    <para>For various components of the boot process more than one alternative pcrlock file shall be
+    supported (i.e. "variants"). For example to cover multiple kernels installed in parallel in the access
+    policy, or multiple versions of the boot loader. This can be done by placing
+    <filename>*.pcrlock.d/*.pcrlock</filename> in the drop-in dirs, i.e. a common directory for a specific
+    component, that contains one or more pcrlock files each covering one <emphasis>variant</emphasis> of the
+    component. Example: <filename>650-kernel.pcrlock.d/6.5.5-200.fc38.x86_64.pcrlock</filename> and
+    <filename>650-kernel.pcrlock.d/6.5.7-100.fc38.x86_64.pcrlock</filename></para>
+
+    <para>Use <command>systemd-pcrlock list-components</command> to list all pcrlock files currently
+    installed.</para>
+
+    <para>Use the various <command>lock-*</command> commands of <command>systemd-pcrlock</command> to
+    automatically generate suitable pcrlock files for various types of resources.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Well-known Components</title>
+
+    <para>Components of the boot process may be defined freely by the administrator or OS vendor. The
+    following components are well-known however, and are defined by systemd. The list below is useful for
+    ordering local pcrlock files properly against these components of the boot.</para>
+
+    <variablelist>
+
+      <varlistentry>
+        <term><filename>240-secureboot-policy.pcrlock</filename></term>
+
+        <listitem><para>The SecureBoot policy, as recorded to PCR 7. May be generated via
+        <command>systemd-pcrlock lock-secureboot-policy</command>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>250-firmware-code-early.pcrlock</filename></term>
+
+        <listitem><para>Firmware code measurements, as recorded to PCR 0 and 2, up to the separator
+        measurement (see <filename>400-secureboot-separator.pcrlock.</filename> below). May be generated via
+        <command>systemd-pcrlock lock-firmware-code</command>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>250-firmware-config-early.pcrlock</filename></term>
+
+        <listitem><para>Firmware configuration measurements, as recorded to PCR 1 and 3, up to the separator
+        measurement (see <filename>400-secureboot-separator.pcrlock.</filename> below). May be generated via
+        <command>systemd-pcrlock lock-firmware-config</command>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>350-action-efi-application.pcrlock</filename></term>
+
+        <listitem><para>The EFI "Application" measurement done once by the firmware. Statically defined.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>400-secureboot-separator.pcrlock</filename></term>
+
+        <listitem><para>The EFI "separator" measurement on PCR 7 done once by the firmware to indicate where
+        firmware control transitions into boot loader/OS control. Statically defined.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>500-separator.pcrlock</filename></term>
+
+        <listitem><para>The EFI "separator" measurements on PCRs 0-6 done once by the firmware to indicate
+        where firmware control transitions into boot loader/OS control. Statically defined.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>550-firmware-code-late.pcrlock</filename></term>
+
+        <listitem><para>Firmware code measurements, as recorded to PCR 0 and 2, after the separator
+        measurement (see <filename>400-secureboot-separator.pcrlock.</filename> above). May be generated via
+        <command>systemd-pcrlock lock-firmware-code</command>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>550-firmware-config-late.pcrlock</filename></term>
+
+        <listitem><para>Firmware configuration measurements, as recorded to PCR 1 and 3, after the separator
+        measurement (see <filename>400-secureboot-separator.pcrlock.</filename> above). May be generated via
+        <command>systemd-pcrlock lock-firmware-config</command>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>600-gpt.pcrlock</filename></term>
+
+        <listitem><para>The GPT partition table of the booted medium, as recorded to PCR 5 by the
+        firmware. May be generated via <command>systemd-pcrlock lock-gpt</command>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>620-secureboot-authority.pcrlock</filename></term>
+
+        <listitem><para>The SecureBoot authority, as recorded to PCR 7. May be generated via
+        <command>systemd-pcrlock lock-secureboot-authority</command>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>700-action-efi-exit-boot-services.pcrlock</filename></term>
+
+        <listitem><para>The EFI action generated when <function>ExitBootServices()</function> is generated,
+        i.e. the UEFI environment is left and the OS takes over. Covers the PCR 5 measurement. Statically
+        defined.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>710-kernel-cmdline.pcrlock</filename></term>
+
+        <listitem><para>The kernel command line, as measured by the Linux kernel to PCR 9. May be generated
+        via <command>systemd-pcrlock lock-kernel-cmdline</command>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>720-kernel-initrd.pcrlock</filename></term>
+
+        <listitem><para>The kernel initrd, as measured by the Linux kernel to PCR 9. May be generated
+        via <command>systemd-pcrlock lock-kernel-initrd</command>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>750-enter-initrd.pcrlock</filename></term>
+
+        <listitem><para>The measurement to PCR 11
+        <citerefentry><refentrytitle>systemd-pcrphase-initrd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        makes when the initrd initializes. Statically defined.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>800-leave-initrd.pcrlock</filename></term>
+
+        <listitem><para>The measurement to PCR 11
+        <citerefentry><refentrytitle>systemd-pcrphase-initrd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        makes when the initrd finishes. Statically defined.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>820-machine-id.pcrlock</filename></term>
+
+        <listitem><para>The measurement to PCR 15
+        <citerefentry><refentrytitle>systemd-pcrmachine.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        makes at boot, covering <filename>/etc/machine-id</filename> contents. May be generated via
+        <command>systemd-pcrlock lock-machine-id</command>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>830-root-file-system.pcrlock</filename></term>
+
+        <listitem><para>The measurement to PCR 15
+        <citerefentry><refentrytitle>systemd-pcrfs-root.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        makes at boot, covering the root file system identity. May be generated
+        via <command>systemd-pcrlock lock-file-system</command>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>850-sysinit.pcrlock</filename></term>
+
+        <listitem><para>The measurement to PCR 11
+        <citerefentry><refentrytitle>systemd-pcrphase-sysinit.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        makes when the main userspace did basic initialization and will now proceed to start regular system
+        services. Statically defined.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>900-ready.pcrlock</filename></term>
+
+        <listitem><para>The measurement to PCR 11
+        <citerefentry><refentrytitle>systemd-pcrphase.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        makes when the system fully booted up. Statically defined.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>950-shutdown.pcrlock</filename></term>
+
+        <listitem><para>The measurement to PCR 11
+        <citerefentry><refentrytitle>systemd-pcrphase.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        makes when the system begins shutdown. Statically defined.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>990-final.pcrlock</filename></term>
+
+        <listitem><para>The measurement to PCR 11
+        <citerefentry><refentrytitle>systemd-pcrphase-sysinit.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        makes when the system is close to finishing shutdown. Statically defined.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-pcrlock</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd.preset.xml b/man/systemd.preset.xml
new file mode 100644
index 0000000..5d46a88
--- /dev/null
+++ b/man/systemd.preset.xml
@@ -0,0 +1,222 @@
+<?xml version="1.0"?>
+<!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+<refentry id="systemd.preset">
+
+  <refentryinfo>
+    <title>systemd.preset</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd.preset</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd.preset</refname>
+    <refpurpose>Service enablement presets</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>/etc/systemd/system-preset/*.preset</filename></para>
+    <para><filename>/run/systemd/system-preset/*.preset</filename></para>
+    <para><filename>/usr/lib/systemd/system-preset/*.preset</filename></para>
+    <para><filename>/etc/systemd/user-preset/*.preset</filename></para>
+    <para><filename>/run/systemd/user-preset/*.preset</filename></para>
+    <para><filename>/usr/lib/systemd/user-preset/*.preset</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>Preset files may be used to encode policy which units shall be enabled by default and which ones
+    shall be disabled. They are read by <command>systemctl preset</command> which uses this information to
+    enable or disable a unit. Depending on that policy, <command>systemctl preset</command> is identical to
+    <command>systemctl enable</command> or <command>systemctl disable</command>.
+
+    <command>systemctl preset</command> is used by the post install scriptlets of rpm packages (or other OS
+    package formats), to enable/disable specific units by default on package installation, enforcing
+    distribution, spin or administrator preset policy. This allows choosing a certain set of units to be
+    enabled/disabled even before installing the actual package. For more information, see
+    <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>.</para>
+
+    <para>It is not recommended to ship preset files within the respective software packages implementing the
+    units, but rather centralize them in a distribution or spin default policy, which can be amended by
+    administrator policy, see below.</para>
+
+    <para>If no preset files exist, preset operations will enable all units that are installed by default. If
+    this is not desired and all units shall rather be disabled, it is necessary to ship a preset file with a
+    single, catchall "<filename>disable *</filename>" line. (See example 1, below.)</para>
+
+    <para>When the machine is booted for the first time,
+    <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> will
+    enable/disable all units according to preset policy, similarly to <command>systemctl
+    preset-all</command>. Also see "First Boot Semantics" in
+    <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+    </para>
+  </refsect1>
+
+  <refsect1>
+    <title>Preset File Format</title>
+
+    <para>The preset files contain a list of directives, one per line. Empty lines and lines whose first
+    non-whitespace character is <literal>#</literal> or <literal>;</literal> are ignored.  Each directive
+    consists of one of the words <literal>enable</literal>, <literal>disable</literal>, or
+    <literal>ignore</literal>, followed by whitespace and a unit name. The unit name may contain shell-style
+    wildcards.</para>
+
+    <para>For the enable directive for template units, one or more instance names may be specified as a
+    space-separated list after the unit name. In this case, those instances will be enabled instead of the
+    instance specified via DefaultInstance= in the unit.</para>
+
+    <para>Presets must refer to the "real" unit file, and not to any aliases. See
+    <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for a description of unit aliasing.</para>
+
+    <para>Three different directives are understood: <literal>enable</literal> may be used to enable units by
+    default, <literal>disable</literal> to disable units by default, and <literal>ignore</literal> to ignore
+    units and leave existing configuration intact.</para>
+
+    <para>If multiple lines apply to a unit name, the first matching
+    one takes precedence over all others.</para>
+
+    <para>Each preset file shall be named in the style of
+    <filename>&lt;priority&gt;-&lt;policy-name&gt;.preset</filename>. Files
+    in <filename>/etc/</filename> override files with the same name in
+    <filename>/usr/lib/</filename> and <filename>/run/</filename>.
+    Files in <filename>/run/</filename> override files with the same
+    name in <filename>/usr/lib/</filename>. Packages should install
+    their preset files in <filename>/usr/lib/</filename>. Files in
+    <filename>/etc/</filename> are reserved for the local
+    administrator, who may use this logic to override the preset files
+    installed by vendor packages. All preset files are sorted by their
+    filename in lexicographic order, regardless of which of the
+    directories they reside in. If multiple files specify the same
+    unit name, the entry in the file with the lexicographically
+    earliest name will be applied. It is recommended to prefix all
+    filenames with a two-digit number and a dash, to simplify the
+    ordering of the files.</para>
+
+    <para>If the administrator wants to disable a preset file supplied
+    by the vendor, the recommended way is to place a symlink to
+    <filename>/dev/null</filename> in
+    <filename>/etc/systemd/system-preset/</filename> bearing the same
+    filename.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Examples</title>
+
+    <example>
+      <title>Default to off</title>
+
+      <programlisting># /usr/lib/systemd/system-preset/99-default.preset
+
+disable *</programlisting>
+    </example>
+
+    <para>This disables all units. Due to the filename prefix
+    <literal>99-</literal>, it will be read last and hence can easily
+    be overridden by spin or administrator preset policy.</para>
+
+    <example>
+      <title>Enable multiple template instances</title>
+
+      <programlisting># /usr/lib/systemd/system-preset/80-dirsrv.preset
+
+enable dirsrv@.service foo bar baz</programlisting>
+    </example>
+
+    <para>This enables all three of <filename>dirsrv@foo.service</filename>,
+    <filename>dirsrv@bar.service</filename> and <filename>dirsrv@baz.service</filename>.</para>
+
+    <example>
+      <title>A GNOME spin</title>
+
+      <programlisting># /usr/lib/systemd/system-preset/50-gnome.preset
+
+enable gdm.service
+enable colord.service
+enable accounts-daemon.service
+enable avahi-daemon.*</programlisting>
+
+    </example>
+
+    <para>This enables the three mentioned units, plus all
+    <filename>avahi-daemon</filename> regardless of which unit type. A
+    file like this could be useful for inclusion in a GNOME spin of a
+    distribution. It will ensure that the units necessary for GNOME
+    are properly enabled as they are installed. It leaves all other
+    units untouched, and subject to other (later) preset files, for
+    example like the one from the first example above.</para>
+
+    <example>
+      <title>Administrator policy</title>
+
+      <programlisting># /etc/systemd/system-preset/00-lennart.preset
+
+enable httpd.service
+enable sshd.service
+enable postfix.service
+disable *</programlisting>
+    </example>
+
+    <para>This enables three specific services and disables all
+    others. This is useful for administrators to specifically select
+    the units to enable, and disable all others. Due to the filename
+    prefix <literal>00-</literal> it will be read early and
+    override all other preset policy files.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Motivation for the preset logic</title>
+
+    <para>Different distributions have different policies on which services shall be enabled by default when
+    the package they are shipped in is installed. On Fedora all services stay off by default, so that
+    installing a package will not cause a service to be enabled (with some exceptions). On Debian all
+    services are immediately enabled by default, so that installing a package will cause its services to be
+    enabled right-away.</para>
+
+    <para>Even within a single distribution, different spins (flavours, remixes, whatever you might want to
+    call them) of a distribution also have different policies on what services to enable, and what services
+    to leave off. For example, Fedora Workstation will enable <command>gdm</command> as display manager by
+    default, while the Fedora KDE spin will enable <command>sddm</command> instead.</para>
+
+    <para>Different sites might also have different policies what to turn on by default and what to turn
+    off. For example, one administrator would prefer to enforce the policy of "<command>sshd</command> should
+    be always on, but everything else off", while another one might say "<command>snmpd</command> always on,
+    and for everything else use the distribution policy defaults".</para>
+
+    <para>Traditionally, policy about which services shall be enabled were implemented in each package
+    individually. This made it cumbersome to implement different policies per spin or per site, or to create
+    software packages that do the right thing on more than one distribution. The enablement mechanism was
+    also encoding the enablement policy.</para>
+
+    <para>The preset mechanism allows clean separation of the enablement mechanism (inside the package
+    scriptlets, by invoking <command>systemctl preset</command>) and enablement policy (centralized in the
+    preset files), and lifts the configuration out of individual packages. Preset files may be written for
+    specific distributions, for specific spins or for specific sites, in order to enforce different policies
+    as needed. It is recommended to apply the policy encoded in preset files in package installation
+    scriptlets.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-delta</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    </para>
+
+    <para><citerefentry><refentrytitle>daemon</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+    has a discussion of packaging scriptlets.</para>
+
+    <para>Fedora page introducing the use of presets:
+    <ulink url="https://fedoraproject.org/wiki/Features/PackagePresets">Features/PackagePresets</ulink>.
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd.resource-control.xml b/man/systemd.resource-control.xml
new file mode 100644
index 0000000..42f265c
--- /dev/null
+++ b/man/systemd.resource-control.xml
@@ -0,0 +1,1675 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd.resource-control" xmlns:xi="http://www.w3.org/2001/XInclude">
+  <refentryinfo>
+    <title>systemd.resource-control</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd.resource-control</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd.resource-control</refname>
+    <refpurpose>Resource control unit settings</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para>
+      <filename><replaceable>slice</replaceable>.slice</filename>,
+      <filename><replaceable>scope</replaceable>.scope</filename>,
+      <filename><replaceable>service</replaceable>.service</filename>,
+      <filename><replaceable>socket</replaceable>.socket</filename>,
+      <filename><replaceable>mount</replaceable>.mount</filename>,
+      <filename><replaceable>swap</replaceable>.swap</filename>
+    </para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>Unit configuration files for services, slices, scopes, sockets, mount points, and swap devices share a subset
+    of configuration options for resource control of spawned processes. Internally, this relies on the Linux Control
+    Groups (cgroups) kernel concept for organizing processes in a hierarchical tree of named groups for the purpose of
+    resource management.</para>
+
+    <para>This man page lists the configuration options shared by
+    those six unit types. See
+    <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for the common options of all unit configuration files, and
+    <citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>systemd.scope</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    and
+    <citerefentry><refentrytitle>systemd.swap</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for more information on the specific unit configuration files. The
+    resource control configuration options are configured in the
+    [Slice], [Scope], [Service], [Socket], [Mount], or [Swap]
+    sections, depending on the unit type.</para>
+
+    <para>In addition, options which control resources available to programs
+    <emphasis>executed</emphasis> by systemd are listed in
+    <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+    Those options complement options listed here.</para>
+
+    <refsect2>
+      <title>Enabling and disabling controllers</title>
+
+      <para>Controllers in the cgroup hierarchy are hierarchical, and resource control is realized by
+      distributing resource assignments between siblings in branches of the cgroup hierarchy. There is no
+      need to explicitly <emphasis>enable</emphasis> a cgroup controller for a unit.
+      <command>systemd</command> will instruct the kernel to enable a controller for a given unit when this
+      unit has configuration for a given controller. For example, when <varname>CPUWeight=</varname> is set,
+      the <option>cpu</option> controller will be enabled, and when <varname>TasksMax=</varname> are set, the
+      <option>pids</option> controller will be enabled. In addition, various controllers may be also be
+      enabled explicitly via the
+      <varname>MemoryAccounting=</varname>/<varname>TasksAccounting=</varname>/<varname>IOAccounting=</varname>
+      settings. Because of how the cgroup hierarchy works, controllers will be automatically enabled for all
+      parent units and for any sibling units starting with the lowest level at which a controller is enabled.
+      Units for which a controller is enabled may be subject to resource control even if they don't have any
+      explicit configuration.</para>
+
+      <para>Setting <varname>Delegate=</varname> enables any delegated controllers for that unit (see below).
+      The delegatee may then enable controllers for its children as appropriate. In particular, if the
+      delegatee is <command>systemd</command> (in the <filename>user@.service</filename> unit), it will
+      repeat the same logic as the system instance and enable controllers for user units which have resource
+      limits configured, and their siblings and parents and parents' siblings.</para>
+
+      <para>Controllers may be <emphasis>disabled</emphasis> for parts of the cgroup hierarchy with
+      <varname>DisableControllers=</varname> (see below).</para>
+
+      <example>
+        <title>Enabling and disabling controllers</title>
+
+        <programlisting>
+                      -.slice
+                     /       \
+              /-----/         \--------------\
+             /                                \
+      system.slice                       user.slice
+        /       \                          /      \
+       /         \                        /        \
+      /           \              user@42.service  user@1000.service
+     /             \             Delegate=        Delegate=yes
+a.service       b.slice                             /        \
+CPUWeight=20   DisableControllers=cpu              /          \
+                 /  \                      app.slice      session.slice
+                /    \                     CPUWeight=100  CPUWeight=100
+               /      \
+       b1.service   b2.service
+                    CPUWeight=1000
+        </programlisting>
+
+        <para>In this hierarchy, the <option>cpu</option> controller is enabled for all units shown except
+        <filename>b1.service</filename> and <filename>b2.service</filename>. Because there is no explicit
+        configuration for <filename>system.slice</filename> and <filename>user.slice</filename>, CPU
+        resources will be split equally between them. Similarly, resources are allocated equally between
+        children of <filename>user.slice</filename> and between the child slices beneath
+        <filename>user@1000.service</filename>. Assuming that there is no further configuration of resources
+        or delegation below slices <filename>app.slice</filename> or <filename>session.slice</filename>, the
+        <option>cpu</option> controller would not be enabled for units in those slices and CPU resources
+        would be further allocated using other mechanisms, e.g. based on nice levels. The manager for user
+        42 has delegation enabled without any controllers, i.e. it can manipulate its subtree of the cgroup
+        hierarchy, but without resource control.</para>
+
+        <para>In the slice <filename>system.slice</filename>, CPU resources are split 1:6 for service
+        <filename>a.service</filename>, and 5:6 for slice <filename>b.slice</filename>, because slice
+        <filename>b.slice</filename> gets the default value of 100 for <filename>cpu.weight</filename> when
+        <varname>CPUWeight=</varname> is not set.</para>
+
+        <para><varname>CPUWeight=</varname> setting in service <filename>b2.service</filename> is neutralized
+        by <varname>DisableControllers=</varname> in slice <filename>b.slice</filename>, so the
+        <option>cpu</option> controller would not be enabled for services <filename>b1.service</filename> and
+        <filename>b2.service</filename>, and CPU resources would be further allocated using other mechanisms,
+        e.g. based on nice levels.</para>
+      </example>
+    </refsect2>
+
+    <refsect2>
+      <title>Setting resource controls for a group of related units</title>
+
+      <para>As described in
+      <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>, the
+      settings listed here may be set through the main file of a unit and drop-in snippets in
+      <filename index="false">*.d/</filename> directories. The list of directories searched for drop-ins
+      includes names formed by repeatedly truncating the unit name after all dashes. This is particularly
+      convenient to set resource limits for a group of units with similar names.</para>
+
+      <para>For example, every user gets their own slice
+      <filename>user-<replaceable>nnn</replaceable>.slice</filename>. Drop-ins with local configuration that
+      affect user 1000 may be placed in
+      <filename index="false">/etc/systemd/system/user-1000.slice</filename>,
+      <filename index="false">/etc/systemd/system/user-1000.slice.d/*.conf</filename>, but also
+      <filename index="false">/etc/systemd/system/user-.slice.d/*.conf</filename>. This last directory
+      applies to all user slices.</para>
+    </refsect2>
+
+    <para>See the <ulink
+    url="https://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface">New
+    Control Group Interfaces</ulink> for an introduction on how to make
+    use of resource control APIs from programs.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Implicit Dependencies</title>
+
+    <para>The following dependencies are implicitly added:</para>
+
+    <itemizedlist>
+      <listitem><para>Units with the <varname>Slice=</varname> setting set automatically acquire
+      <varname>Requires=</varname> and <varname>After=</varname> dependencies on the specified
+      slice unit.</para></listitem>
+    </itemizedlist>
+  </refsect1>
+
+  <!-- We don't have any default dependency here. -->
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>Units of the types listed above can have settings for resource control configuration:</para>
+
+    <refsect2><title>CPU Accounting and Control</title>
+
+    <variablelist class='unit-directives'>
+
+      <varlistentry>
+        <term><varname>CPUAccounting=</varname></term>
+
+        <listitem>
+          <para>Turn on CPU usage accounting for this unit. Takes a
+          boolean argument. Note that turning on CPU accounting for
+          one unit will also implicitly turn it on for all units
+          contained in the same slice and for all its parent slices
+          and the units contained therein. The system default for this
+          setting may be controlled with
+          <varname>DefaultCPUAccounting=</varname> in
+          <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+
+          <para>Under the unified cgroup hierarchy, CPU accounting is available for all units and this
+          setting has no effect.</para>
+
+          <xi:include href="version-info.xml" xpointer="v208"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>CPUWeight=<replaceable>weight</replaceable></varname></term>
+        <term><varname>StartupCPUWeight=<replaceable>weight</replaceable></varname></term>
+
+        <listitem>
+          <para>These settings control the <option>cpu</option> controller in the unified hierarchy.</para>
+
+          <para>These options accept an integer value or a the special string "idle":</para>
+            <itemizedlist>
+              <listitem>
+                <para>If set to an integer value, assign the specified CPU time weight to the processes
+                executed, if the unified control group hierarchy is used on the system. These options control
+                the <literal>cpu.weight</literal> control group attribute. The allowed range is 1 to 10000.
+                Defaults to unset, but the kernel default is 100. For details about this control group
+                attribute, see <ulink url="https://docs.kernel.org/admin-guide/cgroup-v2.html">Control Groups
+                v2</ulink> and <ulink url="https://docs.kernel.org/scheduler/sched-design-CFS.html">CFS
+                Scheduler</ulink>. The available CPU time is split up among all units within one slice
+                relative to their CPU time weight. A higher weight means more CPU time, a lower weight means
+                less.</para>
+              </listitem>
+              <listitem>
+                <para>If set to the special string "idle", mark the cgroup for "idle scheduling", which means
+                that it will get CPU resources only when there are no processes not marked in this way to execute in this
+                cgroup or its siblings. This setting corresponds to the <literal>cpu.idle</literal> cgroup attribute.</para>
+
+                <para>Note that this value only has an effect on cgroup-v2, for cgroup-v1 it is equivalent to the minimum weight.</para>
+              </listitem>
+            </itemizedlist>
+
+          <para>While <varname>StartupCPUWeight=</varname> applies to the startup and shutdown phases of the system,
+          <varname>CPUWeight=</varname> applies to normal runtime of the system, and if the former is not set also to
+          the startup and shutdown phases. Using <varname>StartupCPUWeight=</varname> allows prioritizing specific services at
+          boot-up and shutdown differently than during normal runtime.</para>
+
+          <para>In addition to the resource allocation performed by the <option>cpu</option> controller, the
+          kernel may automatically divide resources based on session-id grouping, see "The autogroup feature"
+          in <citerefentry
+          project='man-pages'><refentrytitle>sched</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
+          The effect of this feature is similar to the <option>cpu</option> controller with no explicit
+          configuration, so users should be careful to not mistake one for the other.</para>
+
+          <xi:include href="version-info.xml" xpointer="v232"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>CPUQuota=</varname></term>
+
+        <listitem>
+          <para>This setting controls the <option>cpu</option> controller in the unified hierarchy.</para>
+
+          <para>Assign the specified CPU time quota to the processes executed. Takes a percentage value, suffixed with
+          "%". The percentage specifies how much CPU time the unit shall get at maximum, relative to the total CPU time
+          available on one CPU. Use values &gt; 100% for allotting CPU time on more than one CPU. This controls the
+          <literal>cpu.max</literal> attribute on the unified control group hierarchy and
+          <literal>cpu.cfs_quota_us</literal> on legacy. For details about these control group attributes, see <ulink
+          url="https://docs.kernel.org/admin-guide/cgroup-v2.html">Control Groups v2</ulink> and <ulink
+          url="https://docs.kernel.org/scheduler/sched-bwc.html">CFS Bandwidth Control</ulink>.
+          Setting <varname>CPUQuota=</varname> to an empty value unsets the quota.</para>
+
+          <para>Example: <varname>CPUQuota=20%</varname> ensures that the executed processes will never get more than
+          20% CPU time on one CPU.</para>
+
+          <xi:include href="version-info.xml" xpointer="v213"/>
+
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>CPUQuotaPeriodSec=</varname></term>
+
+        <listitem>
+          <para>This setting controls the <option>cpu</option> controller in the unified hierarchy.</para>
+
+          <para>Assign the duration over which the CPU time quota specified by <varname>CPUQuota=</varname> is measured.
+          Takes a time duration value in seconds, with an optional suffix such as "ms" for milliseconds (or "s" for seconds.)
+          The default setting is 100ms. The period is clamped to the range supported by the kernel, which is [1ms, 1000ms].
+          Additionally, the period is adjusted up so that the quota interval is also at least 1ms.
+          Setting <varname>CPUQuotaPeriodSec=</varname> to an empty value resets it to the default.</para>
+
+          <para>This controls the second field of <literal>cpu.max</literal> attribute on the unified control group hierarchy
+          and <literal>cpu.cfs_period_us</literal> on legacy. For details about these control group attributes, see
+          <ulink url="https://docs.kernel.org/admin-guide/cgroup-v2.html">Control Groups v2</ulink> and
+          <ulink url="https://docs.kernel.org/scheduler/sched-design-CFS.html">CFS Scheduler</ulink>.</para>
+
+          <para>Example: <varname>CPUQuotaPeriodSec=10ms</varname> to request that the CPU quota is measured in periods of 10ms.</para>
+
+          <xi:include href="version-info.xml" xpointer="v242"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>AllowedCPUs=</varname></term>
+        <term><varname>StartupAllowedCPUs=</varname></term>
+
+        <listitem>
+          <para>This setting controls the <option>cpuset</option> controller in the unified hierarchy.</para>
+
+          <para>Restrict processes to be executed on specific CPUs. Takes a list of CPU indices or ranges separated by either
+          whitespace or commas. CPU ranges are specified by the lower and upper CPU indices separated by a dash.</para>
+
+          <para>Setting <varname>AllowedCPUs=</varname> or <varname>StartupAllowedCPUs=</varname> doesn't guarantee that all
+          of the CPUs will be used by the processes as it may be limited by parent units. The effective configuration is
+          reported as <varname>EffectiveCPUs=</varname>.</para>
+
+          <para>While <varname>StartupAllowedCPUs=</varname> applies to the startup and shutdown phases of the system,
+          <varname>AllowedCPUs=</varname> applies to normal runtime of the system, and if the former is not set also to
+          the startup and shutdown phases. Using <varname>StartupAllowedCPUs=</varname> allows prioritizing specific services at
+          boot-up and shutdown differently than during normal runtime.</para>
+
+          <para>This setting is supported only with the unified control group hierarchy.</para>
+
+          <xi:include href="version-info.xml" xpointer="v244"/>
+        </listitem>
+      </varlistentry>
+
+    </variablelist>
+
+    </refsect2><refsect2><title>Memory Accounting and Control</title>
+
+    <variablelist class='unit-directives'>
+
+      <varlistentry>
+        <term><varname>MemoryAccounting=</varname></term>
+
+        <listitem>
+          <para>This setting controls the <option>memory</option> controller in the unified hierarchy.</para>
+
+          <para>Turn on process and kernel memory accounting for this
+          unit. Takes a boolean argument. Note that turning on memory
+          accounting for one unit will also implicitly turn it on for
+          all units contained in the same slice and for all its parent
+          slices and the units contained therein. The system default
+          for this setting may be controlled with
+          <varname>DefaultMemoryAccounting=</varname> in
+          <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v208"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>MemoryMin=<replaceable>bytes</replaceable></varname>, <varname>MemoryLow=<replaceable>bytes</replaceable></varname></term>
+        <term><varname>StartupMemoryLow=<replaceable>bytes</replaceable></varname>, <varname>DefaultStartupMemoryLow=<replaceable>bytes</replaceable></varname></term>
+
+        <listitem>
+          <para>These settings control the <option>memory</option> controller in the unified hierarchy.</para>
+
+          <para>Specify the memory usage protection of the executed processes in this unit.
+          When reclaiming memory, the unit is treated as if it was using less memory resulting in memory
+          to be preferentially reclaimed from unprotected units.
+          Using <varname>MemoryLow=</varname> results in a weaker protection where memory may still
+          be reclaimed to avoid invoking the OOM killer in case there is no other reclaimable memory.</para>
+          <para>
+          For a protection to be effective, it is generally required to set a corresponding
+          allocation on all ancestors, which is then distributed between children
+          (with the exception of the root slice).
+          Any <varname>MemoryMin=</varname> or <varname>MemoryLow=</varname> allocation that is not
+          explicitly distributed to specific children is used to create a shared protection for all children.
+          As this is a shared protection, the children will freely compete for the memory.</para>
+
+          <para>Takes a memory size in bytes. If the value is suffixed with K, M, G or T, the specified memory size is
+          parsed as Kilobytes, Megabytes, Gigabytes, or Terabytes (with the base 1024), respectively. Alternatively, a
+          percentage value may be specified, which is taken relative to the installed physical memory on the
+          system. If assigned the special value <literal>infinity</literal>, all available memory is protected, which may be
+          useful in order to always inherit all of the protection afforded by ancestors.
+          This controls the <literal>memory.min</literal> or <literal>memory.low</literal> control group attribute.
+          For details about this control group attribute, see <ulink
+          url="https://docs.kernel.org/admin-guide/cgroup-v2.html#memory-interface-files">Memory Interface Files</ulink>.</para>
+
+          <para>Units may have their children use a default <literal>memory.min</literal> or
+          <literal>memory.low</literal> value by specifying <varname>DefaultMemoryMin=</varname> or
+          <varname>DefaultMemoryLow=</varname>, which has the same semantics as
+          <varname>MemoryMin=</varname> and <varname>MemoryLow=</varname>, or <varname>DefaultStartupMemoryLow=</varname>
+          which has the same semantics as <varname>StartupMemoryLow=</varname>.
+          This setting does not affect <literal>memory.min</literal> or <literal>memory.low</literal>
+          in the unit itself.
+          Using it to set a default child allocation is only useful on kernels older than 5.7,
+          which do not support the <literal>memory_recursiveprot</literal> cgroup2 mount option.</para>
+
+          <para>While <varname>StartupMemoryLow=</varname> applies to the startup and shutdown phases of the system,
+          <varname>MemoryMin=</varname> applies to normal runtime of the system, and if the former is not set also to
+          the startup and shutdown phases. Using <varname>StartupMemoryLow=</varname> allows prioritizing specific services at
+          boot-up and shutdown differently than during normal runtime.</para>
+
+          <xi:include href="version-info.xml" xpointer="v240"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>MemoryHigh=<replaceable>bytes</replaceable></varname></term>
+        <term><varname>StartupMemoryHigh=<replaceable>bytes</replaceable></varname></term>
+
+        <listitem>
+          <para>These settings control the <option>memory</option> controller in the unified hierarchy.</para>
+
+          <para>Specify the throttling limit on memory usage of the executed processes in this unit. Memory usage may go
+          above the limit if unavoidable, but the processes are heavily slowed down and memory is taken away
+          aggressively in such cases. This is the main mechanism to control memory usage of a unit.</para>
+
+          <para>Takes a memory size in bytes. If the value is suffixed with K, M, G or T, the specified memory size is
+          parsed as Kilobytes, Megabytes, Gigabytes, or Terabytes (with the base 1024), respectively. Alternatively, a
+          percentage value may be specified, which is taken relative to the installed physical memory on the
+          system. If assigned the
+          special value <literal>infinity</literal>, no memory throttling is applied. This controls the
+          <literal>memory.high</literal> control group attribute. For details about this control group attribute, see
+          <ulink url="https://docs.kernel.org/admin-guide/cgroup-v2.html#memory-interface-files">Memory Interface Files</ulink>.</para>
+
+          <para>While <varname>StartupMemoryHigh=</varname> applies to the startup and shutdown phases of the system,
+          <varname>MemoryHigh=</varname> applies to normal runtime of the system, and if the former is not set also to
+          the startup and shutdown phases. Using <varname>StartupMemoryHigh=</varname> allows prioritizing specific services at
+          boot-up and shutdown differently than during normal runtime.</para>
+
+          <xi:include href="version-info.xml" xpointer="v231"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>MemoryMax=<replaceable>bytes</replaceable></varname></term>
+        <term><varname>StartupMemoryMax=<replaceable>bytes</replaceable></varname></term>
+
+        <listitem>
+          <para>These settings control the <option>memory</option> controller in the unified hierarchy.</para>
+
+          <para>Specify the absolute limit on memory usage of the executed processes in this unit. If memory usage
+          cannot be contained under the limit, out-of-memory killer is invoked inside the unit. It is recommended to
+          use <varname>MemoryHigh=</varname> as the main control mechanism and use <varname>MemoryMax=</varname> as the
+          last line of defense.</para>
+
+          <para>Takes a memory size in bytes. If the value is suffixed with K, M, G or T, the specified memory size is
+          parsed as Kilobytes, Megabytes, Gigabytes, or Terabytes (with the base 1024), respectively. Alternatively, a
+          percentage value may be specified, which is taken relative to the installed physical memory on the system. If
+          assigned the special value <literal>infinity</literal>, no memory limit is applied. This controls the
+          <literal>memory.max</literal> control group attribute. For details about this control group attribute, see
+          <ulink url="https://docs.kernel.org/admin-guide/cgroup-v2.html#memory-interface-files">Memory Interface Files</ulink>.</para>
+
+          <para>While <varname>StartupMemoryMax=</varname> applies to the startup and shutdown phases of the system,
+          <varname>MemoryMax=</varname> applies to normal runtime of the system, and if the former is not set also to
+          the startup and shutdown phases. Using <varname>StartupMemoryMax=</varname> allows prioritizing specific services at
+          boot-up and shutdown differently than during normal runtime.</para>
+
+          <xi:include href="version-info.xml" xpointer="v231"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>MemorySwapMax=<replaceable>bytes</replaceable></varname></term>
+        <term><varname>StartupMemorySwapMax=<replaceable>bytes</replaceable></varname></term>
+
+        <listitem>
+          <para>These settings control the <option>memory</option> controller in the unified hierarchy.</para>
+
+          <para>Specify the absolute limit on swap usage of the executed processes in this unit.</para>
+
+          <para>Takes a swap size in bytes. If the value is suffixed with K, M, G or T, the specified swap size is
+          parsed as Kilobytes, Megabytes, Gigabytes, or Terabytes (with the base 1024), respectively. If assigned the
+          special value <literal>infinity</literal>, no swap limit is applied. These settings control the
+          <literal>memory.swap.max</literal> control group attribute. For details about this control group attribute,
+          see <ulink url="https://docs.kernel.org/admin-guide/cgroup-v2.html#memory-interface-files">Memory Interface Files</ulink>.</para>
+
+          <para>While <varname>StartupMemorySwapMax=</varname> applies to the startup and shutdown phases of the system,
+          <varname>MemorySwapMax=</varname> applies to normal runtime of the system, and if the former is not set also to
+          the startup and shutdown phases. Using <varname>StartupMemorySwapMax=</varname> allows prioritizing specific services at
+          boot-up and shutdown differently than during normal runtime.</para>
+
+          <xi:include href="version-info.xml" xpointer="v232"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>MemoryZSwapMax=<replaceable>bytes</replaceable></varname></term>
+        <term><varname>StartupMemoryZSwapMax=<replaceable>bytes</replaceable></varname></term>
+
+        <listitem>
+          <para>These settings control the <option>memory</option> controller in the unified hierarchy.</para>
+
+          <para>Specify the absolute limit on zswap usage of the processes in this unit. Zswap is a lightweight compressed
+          cache for swap pages. It takes pages that are in the process of being swapped out and attempts to compress them into a
+          dynamically allocated RAM-based memory pool. If the limit specified is hit, no entries from this unit will be
+          stored in the pool until existing entries are faulted back or written out to disk. See the kernel's
+          <ulink url="https://www.kernel.org/doc/html/latest/admin-guide/mm/zswap.html">Zswap</ulink> documentation for more details.</para>
+
+          <para>Takes a size in bytes. If the value is suffixed with K, M, G or T, the specified size is
+          parsed as Kilobytes, Megabytes, Gigabytes, or Terabytes (with the base 1024), respectively. If assigned the
+          special value <literal>infinity</literal>, no limit is applied. These settings control the
+          <literal>memory.zswap.max</literal> control group attribute. For details about this control group attribute,
+          see <ulink url="https://docs.kernel.org/admin-guide/cgroup-v2.html#memory-interface-files">Memory Interface Files</ulink>.</para>
+
+          <para>While <varname>StartupMemoryZSwapMax=</varname> applies to the startup and shutdown phases of the system,
+          <varname>MemoryZSwapMax=</varname> applies to normal runtime of the system, and if the former is not set also to
+          the startup and shutdown phases. Using <varname>StartupMemoryZSwapMax=</varname> allows prioritizing specific services at
+          boot-up and shutdown differently than during normal runtime.</para>
+
+          <xi:include href="version-info.xml" xpointer="v253"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>AllowedMemoryNodes=</varname></term>
+        <term><varname>StartupAllowedMemoryNodes=</varname></term>
+
+        <listitem>
+          <para>These settings control the <option>cpuset</option> controller in the unified hierarchy.</para>
+
+          <para>Restrict processes to be executed on specific memory NUMA nodes. Takes a list of memory NUMA nodes indices
+          or ranges separated by either whitespace or commas. Memory NUMA nodes ranges are specified by the lower and upper
+          NUMA nodes indices separated by a dash.</para>
+
+          <para>Setting <varname>AllowedMemoryNodes=</varname> or <varname>StartupAllowedMemoryNodes=</varname> doesn't
+          guarantee that all of the memory NUMA nodes will be used by the processes as it may be limited by parent units.
+          The effective configuration is reported as <varname>EffectiveMemoryNodes=</varname>.</para>
+
+          <para>While <varname>StartupAllowedMemoryNodes=</varname> applies to the startup and shutdown phases of the system,
+          <varname>AllowedMemoryNodes=</varname> applies to normal runtime of the system, and if the former is not set also to
+          the startup and shutdown phases. Using <varname>StartupAllowedMemoryNodes=</varname> allows prioritizing specific services at
+          boot-up and shutdown differently than during normal runtime.</para>
+
+          <para>This setting is supported only with the unified control group hierarchy.</para>
+
+          <xi:include href="version-info.xml" xpointer="v244"/>
+        </listitem>
+      </varlistentry>
+
+    </variablelist>
+
+    </refsect2><refsect2><title>Process Accounting and Control</title>
+
+    <variablelist class='unit-directives'>
+
+      <varlistentry>
+        <term><varname>TasksAccounting=</varname></term>
+
+        <listitem>
+          <para>This setting controls the <option>pids</option> controller in the unified hierarchy.</para>
+
+          <para>Turn on task accounting for this unit. Takes a boolean argument. If enabled, the kernel will
+          keep track of the total number of tasks in the unit and its children. This number includes both
+          kernel threads and userspace processes, with each thread counted individually. Note that turning on
+          tasks accounting for one unit will also implicitly turn it on for all units contained in the same
+          slice and for all its parent slices and the units contained therein. The system default for this
+          setting may be controlled with <varname>DefaultTasksAccounting=</varname> in
+          <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v227"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>TasksMax=<replaceable>N</replaceable></varname></term>
+
+        <listitem>
+          <para>This setting controls the <option>pids</option> controller in the unified hierarchy.</para>
+
+          <para>Specify the maximum number of tasks that may be created in the unit. This ensures that the
+          number of tasks accounted for the unit (see above) stays below a specific limit. This either takes
+          an absolute number of tasks or a percentage value that is taken relative to the configured maximum
+          number of tasks on the system. If assigned the special value <literal>infinity</literal>, no tasks
+          limit is applied. This controls the <literal>pids.max</literal> control group attribute. For
+          details about this control group attribute, the
+          <ulink url="https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#pid">pids controller
+          </ulink>.</para>
+
+          <para>The system default for this setting may be controlled with
+          <varname>DefaultTasksMax=</varname> in
+          <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v227"/>
+        </listitem>
+      </varlistentry>
+
+    </variablelist>
+
+    </refsect2><refsect2><title>IO Accounting and Control</title>
+
+    <variablelist class='unit-directives'>
+
+      <varlistentry>
+        <term><varname>IOAccounting=</varname></term>
+
+        <listitem>
+          <para>This setting controls the <option>io</option> controller in the unified hierarchy.</para>
+
+          <para>Turn on Block I/O accounting for this unit, if the unified control group hierarchy is used on the
+          system. Takes a boolean argument. Note that turning on block I/O accounting for one unit will also implicitly
+          turn it on for all units contained in the same slice and all for its parent slices and the units contained
+          therein. The system default for this setting may be controlled with <varname>DefaultIOAccounting=</varname>
+          in
+          <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v230"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>IOWeight=<replaceable>weight</replaceable></varname></term>
+        <term><varname>StartupIOWeight=<replaceable>weight</replaceable></varname></term>
+
+        <listitem>
+          <para>These settings control the <option>io</option> controller in the unified hierarchy.</para>
+
+          <para>Set the default overall block I/O weight for the executed processes, if the unified control
+          group hierarchy is used on the system. Takes a single weight value (between 1 and 10000) to set the
+          default block I/O weight. This controls the <literal>io.weight</literal> control group attribute,
+          which defaults to 100. For details about this control group attribute, see <ulink
+          url="https://docs.kernel.org/admin-guide/cgroup-v2.html#io-interface-files">IO
+          Interface Files</ulink>.  The available I/O bandwidth is split up among all units within one slice
+          relative to their block I/O weight. A higher weight means more I/O bandwidth, a lower weight means
+          less.</para>
+
+          <para>While <varname>StartupIOWeight=</varname> applies
+          to the startup and shutdown phases of the system,
+          <varname>IOWeight=</varname> applies to the later runtime of
+          the system, and if the former is not set also to the startup
+          and shutdown phases. This allows prioritizing specific services at boot-up
+          and shutdown differently than during runtime.</para>
+
+          <xi:include href="version-info.xml" xpointer="v230"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>IODeviceWeight=<replaceable>device</replaceable> <replaceable>weight</replaceable></varname></term>
+
+        <listitem>
+          <para>This setting controls the <option>io</option> controller in the unified hierarchy.</para>
+
+          <para>Set the per-device overall block I/O weight for the executed processes, if the unified control group
+          hierarchy is used on the system. Takes a space-separated pair of a file path and a weight value to specify
+          the device specific weight value, between 1 and 10000. (Example: <literal>/dev/sda 1000</literal>). The file
+          path may be specified as path to a block device node or as any other file, in which case the backing block
+          device of the file system of the file is determined. This controls the <literal>io.weight</literal> control
+          group attribute, which defaults to 100. Use this option multiple times to set weights for multiple devices.
+          For details about this control group attribute, see <ulink
+          url="https://docs.kernel.org/admin-guide/cgroup-v2.html#io-interface-files">IO Interface Files</ulink>.</para>
+
+          <para>The specified device node should reference a block device that has an I/O scheduler
+          associated, i.e. should not refer to partition or loopback block devices, but to the originating,
+          physical device. When a path to a regular file or directory is specified it is attempted to
+          discover the correct originating device backing the file system of the specified path. This works
+          correctly only for simpler cases, where the file system is directly placed on a partition or
+          physical block device, or where simple 1:1 encryption using dm-crypt/LUKS is used. This discovery
+          does not cover complex storage and in particular RAID and volume management storage devices.</para>
+
+          <xi:include href="version-info.xml" xpointer="v230"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>IOReadBandwidthMax=<replaceable>device</replaceable> <replaceable>bytes</replaceable></varname></term>
+        <term><varname>IOWriteBandwidthMax=<replaceable>device</replaceable> <replaceable>bytes</replaceable></varname></term>
+
+        <listitem>
+          <para>These settings control the <option>io</option> controller in the unified hierarchy.</para>
+
+          <para>Set the per-device overall block I/O bandwidth maximum limit for the executed processes, if the unified
+          control group hierarchy is used on the system. This limit is not work-conserving and the executed processes
+          are not allowed to use more even if the device has idle capacity.  Takes a space-separated pair of a file
+          path and a bandwidth value (in bytes per second) to specify the device specific bandwidth. The file path may
+          be a path to a block device node, or as any other file in which case the backing block device of the file
+          system of the file is used. If the bandwidth is suffixed with K, M, G, or T, the specified bandwidth is
+          parsed as Kilobytes, Megabytes, Gigabytes, or Terabytes, respectively, to the base of 1000. (Example:
+          "/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0 5M"). This controls the <literal>io.max</literal> control
+          group attributes. Use this option multiple times to set bandwidth limits for multiple devices. For details
+          about this control group attribute, see <ulink
+          url="https://docs.kernel.org/admin-guide/cgroup-v2.html#io-interface-files">IO Interface Files</ulink>.
+          </para>
+
+          <para>Similar restrictions on block device discovery as for <varname>IODeviceWeight=</varname> apply, see above.</para>
+
+          <xi:include href="version-info.xml" xpointer="v230"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>IOReadIOPSMax=<replaceable>device</replaceable> <replaceable>IOPS</replaceable></varname></term>
+        <term><varname>IOWriteIOPSMax=<replaceable>device</replaceable> <replaceable>IOPS</replaceable></varname></term>
+
+        <listitem>
+          <para>These settings control the <option>io</option> controller in the unified hierarchy.</para>
+
+          <para>Set the per-device overall block I/O IOs-Per-Second maximum limit for the executed processes, if the
+          unified control group hierarchy is used on the system. This limit is not work-conserving and the executed
+          processes are not allowed to use more even if the device has idle capacity.  Takes a space-separated pair of
+          a file path and an IOPS value to specify the device specific IOPS. The file path may be a path to a block
+          device node, or as any other file in which case the backing block device of the file system of the file is
+          used. If the IOPS is suffixed with K, M, G, or T, the specified IOPS is parsed as KiloIOPS, MegaIOPS,
+          GigaIOPS, or TeraIOPS, respectively, to the base of 1000. (Example:
+          "/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0 1K"). This controls the <literal>io.max</literal> control
+          group attributes. Use this option multiple times to set IOPS limits for multiple devices. For details about
+          this control group attribute, see <ulink
+          url="https://docs.kernel.org/admin-guide/cgroup-v2.html#io-interface-files">IO Interface Files</ulink>.
+          </para>
+
+          <para>Similar restrictions on block device discovery as for <varname>IODeviceWeight=</varname> apply, see above.</para>
+
+          <xi:include href="version-info.xml" xpointer="v230"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>IODeviceLatencyTargetSec=<replaceable>device</replaceable> <replaceable>target</replaceable></varname></term>
+
+        <listitem>
+          <para>This setting controls the <option>io</option> controller in the unified hierarchy.</para>
+
+          <para>Set the per-device average target I/O latency for the executed processes, if the unified control group
+          hierarchy is used on the system. Takes a file path and a timespan separated by a space to specify
+          the device specific latency target. (Example: "/dev/sda 25ms"). The file path may be specified
+          as path to a block device node or as any other file, in which case the backing block device of the file
+          system of the file is determined. This controls the <literal>io.latency</literal> control group
+          attribute. Use this option multiple times to set latency target for multiple devices. For details about this
+          control group attribute, see <ulink
+          url="https://docs.kernel.org/admin-guide/cgroup-v2.html#io-interface-files">IO Interface Files</ulink>.</para>
+
+          <para>Implies <literal>IOAccounting=yes</literal>.</para>
+
+          <para>These settings are supported only if the unified control group hierarchy is used.</para>
+
+          <para>Similar restrictions on block device discovery as for <varname>IODeviceWeight=</varname> apply, see above.</para>
+
+          <xi:include href="version-info.xml" xpointer="v240"/>
+        </listitem>
+      </varlistentry>
+
+    </variablelist>
+
+    </refsect2><refsect2><title>Network Accounting and Control</title>
+
+    <variablelist class='unit-directives'>
+
+      <varlistentry>
+        <term><varname>IPAccounting=</varname></term>
+
+        <listitem>
+          <para>Takes a boolean argument. If true, turns on IPv4 and IPv6 network traffic accounting for packets sent
+          or received by the unit. When this option is turned on, all IPv4 and IPv6 sockets created by any process of
+          the unit are accounted for.</para>
+
+          <para>When this option is used in socket units, it applies to all IPv4 and IPv6 sockets
+          associated with it (including both listening and connection sockets where this applies). Note that for
+          socket-activated services, this configuration setting and the accounting data of the service unit and the
+          socket unit are kept separate, and displayed separately. No propagation of the setting and the collected
+          statistics is done, in either direction. Moreover, any traffic sent or received on any of the socket unit's
+          sockets is accounted to the socket unit — and never to the service unit it might have activated, even if the
+          socket is used by it.</para>
+
+          <para>The system default for this setting may be controlled with <varname>DefaultIPAccounting=</varname> in
+          <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v235"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>IPAddressAllow=<replaceable>ADDRESS[/PREFIXLENGTH]…</replaceable></varname></term>
+        <term><varname>IPAddressDeny=<replaceable>ADDRESS[/PREFIXLENGTH]…</replaceable></varname></term>
+
+        <listitem>
+          <para>Turn on network traffic filtering for IP packets sent and received over
+          <constant>AF_INET</constant> and <constant>AF_INET6</constant> sockets. Both directives take a
+          space separated list of IPv4 or IPv6 addresses, each optionally suffixed with an address prefix
+          length in bits after a <literal>/</literal> character. If the suffix is omitted, the address is
+          considered a host address, i.e. the filter covers the whole address (32 bits for IPv4, 128 bits for
+          IPv6).</para>
+
+          <para>The access lists configured with this option are applied to all sockets created by processes
+          of this unit (or in the case of socket units, associated with it). The lists are implicitly
+          combined with any lists configured for any of the parent slice units this unit might be a member
+          of. By default both access lists are empty. Both ingress and egress traffic is filtered by these
+          settings. In case of ingress traffic the source IP address is checked against these access lists,
+          in case of egress traffic the destination IP address is checked. The following rules are applied in
+          turn:</para>
+
+          <itemizedlist>
+            <listitem><para>Access is granted when the checked IP address matches an entry in the
+            <varname>IPAddressAllow=</varname> list.</para></listitem>
+
+            <listitem><para>Otherwise, access is denied when the checked IP address matches an entry in the
+            <varname>IPAddressDeny=</varname> list.</para></listitem>
+
+            <listitem><para>Otherwise, access is granted.</para></listitem>
+          </itemizedlist>
+
+          <para>In order to implement an allow-listing IP firewall, it is recommended to use a
+          <varname>IPAddressDeny=</varname><constant>any</constant> setting on an upper-level slice unit
+          (such as the root slice <filename>-.slice</filename> or the slice containing all system services
+          <filename>system.slice</filename> – see
+          <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+          for details on these slice units), plus individual per-service <varname>IPAddressAllow=</varname>
+          lines permitting network access to relevant services, and only them.</para>
+
+          <para>Note that for socket-activated services, the IP access list configured on the socket unit
+          applies to all sockets associated with it directly, but not to any sockets created by the
+          ultimately activated services for it. Conversely, the IP access list configured for the service is
+          not applied to any sockets passed into the service via socket activation. Thus, it is usually a
+          good idea to replicate the IP access lists on both the socket and the service unit. Nevertheless,
+          it may make sense to maintain one list more open and the other one more restricted, depending on
+          the use case.</para>
+
+          <para>If these settings are used multiple times in the same unit the specified lists are combined. If an
+          empty string is assigned to these settings the specific access list is reset and all previous settings undone.</para>
+
+          <para>In place of explicit IPv4 or IPv6 address and prefix length specifications a small set of symbolic
+          names may be used. The following names are defined:</para>
+
+          <table>
+            <title>Special address/network names</title>
+
+            <tgroup cols='3'>
+              <colspec colname='name'/>
+              <colspec colname='definition'/>
+              <colspec colname='meaning'/>
+
+              <thead>
+                <row>
+                  <entry>Symbolic Name</entry>
+                  <entry>Definition</entry>
+                  <entry>Meaning</entry>
+                </row>
+              </thead>
+
+            <tbody>
+              <row>
+                <entry><constant>any</constant></entry>
+                <entry>0.0.0.0/0 ::/0</entry>
+                <entry>Any host</entry>
+              </row>
+
+              <row>
+                <entry><constant>localhost</constant></entry>
+                <entry>127.0.0.0/8 ::1/128</entry>
+                <entry>All addresses on the local loopback</entry>
+              </row>
+
+              <row>
+                <entry><constant>link-local</constant></entry>
+                <entry>169.254.0.0/16 fe80::/64</entry>
+                <entry>All link-local IP addresses</entry>
+              </row>
+
+              <row>
+                <entry><constant>multicast</constant></entry>
+                <entry>224.0.0.0/4 ff00::/8</entry>
+                <entry>All IP multicasting addresses</entry>
+              </row>
+            </tbody>
+            </tgroup>
+          </table>
+
+          <para>Note that these settings might not be supported on some systems (for example if eBPF control group
+          support is not enabled in the underlying kernel or container manager). These settings will have no effect in
+          that case. If compatibility with such systems is desired it is hence recommended to not exclusively rely on
+          them for IP security.</para>
+
+          <xi:include href="cgroup-sandboxing.xml" xpointer="singular"/>
+
+          <xi:include href="version-info.xml" xpointer="v235"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SocketBindAllow=<replaceable>bind-rule</replaceable></varname></term>
+        <term><varname>SocketBindDeny=<replaceable>bind-rule</replaceable></varname></term>
+
+        <listitem>
+          <para>Allow or deny binding a socket address to a socket by matching it with the <replaceable>bind-rule</replaceable> and
+          applying a corresponding action if there is a match.</para>
+
+          <para><replaceable>bind-rule</replaceable> describes socket properties such as <replaceable>address-family</replaceable>,
+          <replaceable>transport-protocol</replaceable> and <replaceable>ip-ports</replaceable>.</para>
+
+          <para><replaceable>bind-rule</replaceable> :=
+          { [<replaceable>address-family</replaceable><constant>:</constant>][<replaceable>transport-protocol</replaceable><constant>:</constant>][<replaceable>ip-ports</replaceable>] | <constant>any</constant> }</para>
+
+          <para><replaceable>address-family</replaceable> := { <constant>ipv4</constant> | <constant>ipv6</constant> }</para>
+
+          <para><replaceable>transport-protocol</replaceable> := { <constant>tcp</constant> | <constant>udp</constant> }</para>
+
+          <para><replaceable>ip-ports</replaceable> := { <replaceable>ip-port</replaceable> | <replaceable>ip-port-range</replaceable> }</para>
+
+          <para>An optional <replaceable>address-family</replaceable> expects <constant>ipv4</constant> or <constant>ipv6</constant> values.
+          If not specified, a rule will be matched for both IPv4 and IPv6 addresses and applied depending on other socket fields, e.g. <replaceable>transport-protocol</replaceable>,
+          <replaceable>ip-port</replaceable>.</para>
+
+          <para>An optional <replaceable>transport-protocol</replaceable> expects <constant>tcp</constant> or <constant>udp</constant> transport protocol names.
+          If not specified, a rule will be matched for any transport protocol.</para>
+
+          <para>An optional <replaceable>ip-port</replaceable> value must lie within 1…65535 interval inclusively, i.e.
+          dynamic port <constant>0</constant> is not allowed. A range of sequential ports is described by
+          <replaceable>ip-port-range</replaceable> := <replaceable>ip-port-low</replaceable><constant>-</constant><replaceable>ip-port-high</replaceable>,
+          where <replaceable>ip-port-low</replaceable> is smaller than or equal to <replaceable>ip-port-high</replaceable>
+          and both are within 1…65535 inclusively.</para>
+
+          <para>A special value <constant>any</constant> can be used to apply a rule to any address family, transport protocol and any port with a positive value.</para>
+
+          <para>To allow multiple rules assign <varname>SocketBindAllow=</varname> or <varname>SocketBindDeny=</varname> multiple times.
+          To clear the existing assignments pass an empty <varname>SocketBindAllow=</varname> or <varname>SocketBindDeny=</varname>
+          assignment.</para>
+
+          <para>For each of <varname>SocketBindAllow=</varname> and <varname>SocketBindDeny=</varname>, maximum allowed number of assignments is
+          <constant>128</constant>.</para>
+
+          <itemizedlist>
+            <listitem><para>Binding to a socket is allowed when a socket address matches an entry in the
+            <varname>SocketBindAllow=</varname> list.</para></listitem>
+
+            <listitem><para>Otherwise, binding is denied when the socket address matches an entry in the
+            <varname>SocketBindDeny=</varname> list.</para></listitem>
+
+            <listitem><para>Otherwise, binding is allowed.</para></listitem>
+          </itemizedlist>
+
+          <para>The feature is implemented with <constant>cgroup/bind4</constant> and <constant>cgroup/bind6</constant> cgroup-bpf hooks.</para>
+          <para>Examples:<programlisting>…
+# Allow binding IPv6 socket addresses with a port greater than or equal to 10000.
+[Service]
+SocketBindAllow=ipv6:10000-65535
+SocketBindDeny=any
+…
+# Allow binding IPv4 and IPv6 socket addresses with 1234 and 4321 ports.
+[Service]
+SocketBindAllow=1234
+SocketBindAllow=4321
+SocketBindDeny=any
+…
+# Deny binding IPv6 socket addresses.
+[Service]
+SocketBindDeny=ipv6
+…
+# Deny binding IPv4 and IPv6 socket addresses.
+[Service]
+SocketBindDeny=any
+…
+# Allow binding only over TCP
+[Service]
+SocketBindAllow=tcp
+SocketBindDeny=any
+…
+# Allow binding only over IPv6/TCP
+[Service]
+SocketBindAllow=ipv6:tcp
+SocketBindDeny=any
+…
+# Allow binding ports within 10000-65535 range over IPv4/UDP.
+[Service]
+SocketBindAllow=ipv4:udp:10000-65535
+SocketBindDeny=any
+…</programlisting></para>
+
+          <xi:include href="cgroup-sandboxing.xml" xpointer="singular"/>
+
+          <xi:include href="version-info.xml" xpointer="v249"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RestrictNetworkInterfaces=</varname></term>
+
+        <listitem>
+          <para>Takes a list of space-separated network interface names. This option restricts the network
+          interfaces that processes of this unit can use. By default processes can only use the network interfaces
+          listed (allow-list). If the first character of the rule is <literal>~</literal>, the effect is inverted:
+          the processes can only use network interfaces not listed (deny-list).
+          </para>
+
+          <para>This option can appear multiple times, in which case the network interface names are merged. If the
+          empty string is assigned the set is reset, all prior assignments will have not effect.
+          </para>
+
+          <para>If you specify both types of this option (i.e. allow-listing and deny-listing), the first encountered
+          will take precedence and will dictate the default action (allow vs deny). Then the next occurrences of this
+          option will add or delete the listed network interface names from the set, depending of its type and the
+          default action.
+          </para>
+
+          <para>The loopback interface ("lo") is not treated in any special way, you have to configure it explicitly
+          in the unit file.
+          </para>
+          <para>Example 1: allow-list
+          <programlisting>
+RestrictNetworkInterfaces=eth1
+RestrictNetworkInterfaces=eth2</programlisting>
+          Programs in the unit will be only able to use the eth1 and eth2 network
+          interfaces.
+          </para>
+
+          <para>Example 2: deny-list
+          <programlisting>
+RestrictNetworkInterfaces=~eth1 eth2</programlisting>
+          Programs in the unit will be able to use any network interface but eth1 and eth2.
+          </para>
+
+          <para>Example 3: mixed
+          <programlisting>
+RestrictNetworkInterfaces=eth1 eth2
+RestrictNetworkInterfaces=~eth1</programlisting>
+          Programs in the unit will be only able to use the eth2 network interface.
+          </para>
+
+          <xi:include href="cgroup-sandboxing.xml" xpointer="singular"/>
+
+          <xi:include href="version-info.xml" xpointer="v250"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>NFTSet=</varname><replaceable>family</replaceable>:<replaceable>table</replaceable>:<replaceable>set</replaceable></term>
+        <listitem>
+          <para>This setting provides a method for integrating dynamic cgroup, user and group IDs into
+          firewall rules with <ulink url="https://netfilter.org/projects/nftables/index.html">NFT</ulink>
+          sets. The benefit of using this setting is to be able to use the IDs as selectors in firewall rules
+          easily and this in turn allows more fine grained filtering. NFT rules for cgroup matching use
+          numeric cgroup IDs, which change every time a service is restarted, making them hard to use in
+          systemd environment otherwise. Dynamic and random IDs used by <varname>DynamicUser=</varname> can
+          be also integrated with this setting.</para>
+
+          <para>This option expects a whitespace separated list of NFT set definitions. Each definition
+          consists of a colon-separated tuple of source type (one of <literal>cgroup</literal>,
+          <literal>user</literal> or <literal>group</literal>), NFT address family (one of
+          <literal>arp</literal>, <literal>bridge</literal>, <literal>inet</literal>, <literal>ip</literal>,
+          <literal>ip6</literal>, or <literal>netdev</literal>), table name and set name. The names of tables
+          and sets must conform to lexical restrictions of NFT table names. The type of the element used in
+          the NFT filter must match the type implied by the directive (<literal>cgroup</literal>,
+          <literal>user</literal> or <literal>group</literal>) as shown in the table below. When a control
+          group or a unit is realized, the corresponding ID will be appended to the NFT sets and it will be
+          be removed when the control group or unit is removed. <command>systemd</command> only inserts
+          elements to (or removes from) the sets, so the related NFT rules, tables and sets must be prepared
+          elsewhere in advance. Failures to manage the sets will be ignored.</para>
+
+          <table>
+            <title>Defined <varname>source type</varname> values</title>
+            <tgroup cols='3'>
+              <colspec colname='source type'/>
+              <colspec colname='description'/>
+              <colspec colname='NFT type name'/>
+              <thead>
+                <row>
+                  <entry>Source type</entry>
+                  <entry>Description</entry>
+                  <entry>Corresponding NFT type name</entry>
+                </row>
+              </thead>
+
+              <tbody>
+                <row>
+                  <entry><literal>cgroup</literal></entry>
+                  <entry>control group ID</entry>
+                  <entry><literal>cgroupsv2</literal></entry>
+                </row>
+                <row>
+                  <entry><literal>user</literal></entry>
+                  <entry>user ID</entry>
+                  <entry><literal>meta skuid</literal></entry>
+                </row>
+                <row>
+                  <entry><literal>group</literal></entry>
+                  <entry>group ID</entry>
+                  <entry><literal>meta skgid</literal></entry>
+                </row>
+              </tbody>
+            </tgroup>
+          </table>
+
+          <para>If the firewall rules are reinstalled so that the contents of NFT sets are destroyed, command
+          <command>systemctl daemon-reload</command> can be used to refill the sets.</para>
+
+          <para>Example:
+          <programlisting>[Unit]
+NFTSet=cgroup:inet:filter:my_service user:inet:filter:serviceuser
+</programlisting>
+          Corresponding NFT rules:
+          <programlisting>table inet filter {
+        set my_service {
+                type cgroupsv2
+        }
+        set serviceuser {
+                typeof meta skuid
+        }
+        chain x {
+                socket cgroupv2 level 2 @my_service accept
+                drop
+        }
+        chain y {
+                meta skuid @serviceuser accept
+                drop
+        }
+}</programlisting>
+          </para>
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+
+    </variablelist>
+
+    </refsect2><refsect2><title>BPF Programs</title>
+
+    <variablelist class='unit-directives'>
+
+      <varlistentry>
+        <term><varname>IPIngressFilterPath=<replaceable>BPF_FS_PROGRAM_PATH</replaceable></varname></term>
+        <term><varname>IPEgressFilterPath=<replaceable>BPF_FS_PROGRAM_PATH</replaceable></varname></term>
+
+        <listitem>
+          <para>Add custom network traffic filters implemented as BPF programs, applying to all IP packets
+          sent and received over <constant>AF_INET</constant> and <constant>AF_INET6</constant> sockets.
+          Takes an absolute path to a pinned BPF program in the BPF virtual filesystem (<filename>/sys/fs/bpf/</filename>).
+          </para>
+
+          <para>The filters configured with this option are applied to all sockets created by processes
+          of this unit (or in the case of socket units, associated with it). The filters are loaded in addition
+          to filters any of the parent slice units this unit might be a member of as well as any
+          <varname>IPAddressAllow=</varname> and <varname>IPAddressDeny=</varname> filters in any of these units.
+          By default there are no filters specified.</para>
+
+          <para>If these settings are used multiple times in the same unit all the specified programs are attached. If an
+          empty string is assigned to these settings the program list is reset and all previous specified programs ignored.</para>
+
+          <para>If the path <replaceable>BPF_FS_PROGRAM_PATH</replaceable> in <varname>IPIngressFilterPath=</varname> assignment
+          is already being handled by <varname>BPFProgram=</varname> ingress hook, e.g.
+          <varname>BPFProgram=</varname><constant>ingress</constant>:<replaceable>BPF_FS_PROGRAM_PATH</replaceable>,
+          the assignment will be still considered valid and the program will be attached to a cgroup. Same for
+          <varname>IPEgressFilterPath=</varname> path and <constant>egress</constant> hook.</para>
+
+          <para>Note that for socket-activated services, the IP filter programs configured on the socket unit apply to
+          all sockets associated with it directly, but not to any sockets created by the ultimately activated services
+          for it. Conversely, the IP filter programs configured for the service are not applied to any sockets passed into
+          the service via socket activation. Thus, it is usually a good idea, to replicate the IP filter programs on both
+          the socket and the service unit, however it often makes sense to maintain one configuration more open and the other
+          one more restricted, depending on the use case.</para>
+
+          <para>Note that these settings might not be supported on some systems (for example if eBPF control group
+          support is not enabled in the underlying kernel or container manager). These settings will fail the service in
+          that case. If compatibility with such systems is desired it is hence recommended to attach your filter manually
+          (requires <varname>Delegate=</varname><constant>yes</constant>) instead of using this setting.</para>
+
+          <xi:include href="version-info.xml" xpointer="v243"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>BPFProgram=<replaceable>type</replaceable>:<replaceable>program-path</replaceable></varname></term>
+        <listitem>
+          <para><varname>BPFProgram=</varname> allows attaching custom BPF programs to the cgroup of a
+          unit. (This generalizes the functionality exposed via <varname>IPEgressFilterPath=</varname> and
+          <varname>IPIngressFilterPath=</varname> for other hooks.)  Cgroup-bpf hooks in the form of BPF
+          programs loaded to the BPF filesystem are attached with cgroup-bpf attach flags determined by the
+          unit. For details about attachment types and flags see <ulink
+          url="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/include/uapi/linux/bpf.h"><filename>bpf.h</filename></ulink>. Also
+          refer to the general <ulink url="https://docs.kernel.org/bpf/">BPF documentation</ulink>.</para>
+
+          <para>The specification of BPF program consists of a pair of BPF program type and program path in
+          the file system, with <literal>:</literal> as the separator:
+          <replaceable>type</replaceable>:<replaceable>program-path</replaceable>.</para>
+
+          <para>The BPF program type is equivalent to the BPF attach type used in
+          <citerefentry project='mankier'><refentrytitle>bpftool</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+          It may be one of
+          <constant>egress</constant>,
+          <constant>ingress</constant>,
+          <constant>sock_create</constant>,
+          <constant>sock_ops</constant>,
+          <constant>device</constant>,
+          <constant>bind4</constant>,
+          <constant>bind6</constant>,
+          <constant>connect4</constant>,
+          <constant>connect6</constant>,
+          <constant>post_bind4</constant>,
+          <constant>post_bind6</constant>,
+          <constant>sendmsg4</constant>,
+          <constant>sendmsg6</constant>,
+          <constant>sysctl</constant>,
+          <constant>recvmsg4</constant>,
+          <constant>recvmsg6</constant>,
+          <constant>getsockopt</constant>,
+          or <constant>setsockopt</constant>.
+          </para>
+
+          <para>The specified program path must be an absolute path referencing a BPF program inode in the
+          bpffs file system (which generally means it must begin with <filename>/sys/fs/bpf/</filename>). If
+          a specified program does not exist (i.e. has not been uploaded to the BPF subsystem of the kernel
+          yet), it will not be installed but unit activation will continue (a warning will be printed to the
+          logs).</para>
+
+          <para>Setting <varname>BPFProgram=</varname> to an empty value makes previous assignments
+          ineffective.</para>
+
+          <para>Multiple assignments of the same program type/path pair have the same effect as a single
+          assignment: the program will be attached just once.</para>
+
+          <para>If BPF <constant>egress</constant> pinned to <replaceable>program-path</replaceable> path is already being
+          handled by <varname>IPEgressFilterPath=</varname>, <varname>BPFProgram=</varname>
+          assignment will be considered valid and <varname>BPFProgram=</varname> will be attached to a cgroup.
+          Similarly for <constant>ingress</constant> hook and <varname>IPIngressFilterPath=</varname> assignment.</para>
+
+          <para>BPF programs passed with <varname>BPFProgram=</varname> are attached to the cgroup of a unit
+          with BPF attach flag <constant>multi</constant>, that allows further attachments of the same
+          <replaceable>type</replaceable> within cgroup hierarchy topped by the unit cgroup.</para>
+
+          <para>Examples:<programlisting>BPFProgram=egress:/sys/fs/bpf/egress-hook
+BPFProgram=bind6:/sys/fs/bpf/sock-addr-hook
+</programlisting></para>
+
+          <xi:include href="version-info.xml" xpointer="v249"/>
+        </listitem>
+      </varlistentry>
+
+    </variablelist>
+
+    </refsect2><refsect2><title>Device Access</title>
+
+    <variablelist class='unit-directives'>
+
+      <varlistentry>
+        <term><varname>DeviceAllow=</varname></term>
+
+        <listitem>
+          <para>Control access to specific device nodes by the executed processes. Takes two space-separated
+          strings: a device node specifier followed by a combination of <constant>r</constant>,
+          <constant>w</constant>, <constant>m</constant> to control <emphasis>r</emphasis>eading,
+          <emphasis>w</emphasis>riting, or creation of the specific device nodes by the unit
+          (<emphasis>m</emphasis>knod), respectively. This functionality is implemented using eBPF
+          filtering.</para>
+
+          <para>When access to <emphasis>all</emphasis> physical devices should be disallowed,
+          <varname>PrivateDevices=</varname> may be used instead. See
+          <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+          </para>
+
+          <para>The device node specifier is either a path to a device node in the file system, starting with
+          <filename>/dev/</filename>, or a string starting with either <literal>char-</literal> or
+          <literal>block-</literal> followed by a device group name, as listed in
+          <filename>/proc/devices</filename>. The latter is useful to allow-list all current and future
+          devices belonging to a specific device group at once. The device group is matched according to
+          filename globbing rules, you may hence use the <literal>*</literal> and <literal>?</literal>
+          wildcards. (Note that such globbing wildcards are not available for device node path
+          specifications!) In order to match device nodes by numeric major/minor, use device node paths in
+          the <filename>/dev/char/</filename> and <filename>/dev/block/</filename> directories. However,
+          matching devices by major/minor is generally not recommended as assignments are neither stable nor
+          portable between systems or different kernel versions.</para>
+
+          <para>Examples: <filename>/dev/sda5</filename> is a path to a device node, referring to an ATA or
+          SCSI block device. <literal>char-pts</literal> and <literal>char-alsa</literal> are specifiers for
+          all pseudo TTYs and all ALSA sound devices, respectively. <literal>char-cpu/*</literal> is a
+          specifier matching all CPU related device groups.</para>
+
+          <para>Note that allow lists defined this way should only reference device groups which are
+          resolvable at the time the unit is started. Any device groups not resolvable then are not added to
+          the device allow list. In order to work around this limitation, consider extending service units
+          with a pair of <command>After=modprobe@xyz.service</command> and
+          <command>Wants=modprobe@xyz.service</command> lines that load the necessary kernel module
+          implementing the device group if missing.
+          Example: <programlisting>…
+[Unit]
+Wants=modprobe@loop.service
+After=modprobe@loop.service
+
+[Service]
+DeviceAllow=block-loop
+DeviceAllow=/dev/loop-control
+…</programlisting></para>
+
+          <xi:include href="cgroup-sandboxing.xml" xpointer="singular"/>
+
+          <xi:include href="version-info.xml" xpointer="v208"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>DevicePolicy=auto|closed|strict</varname></term>
+
+        <listitem>
+          <para>
+            Control the policy for allowing device access:
+          </para>
+          <variablelist>
+            <varlistentry>
+              <term><option>strict</option></term>
+              <listitem>
+                <para>means to only allow types of access that are
+                explicitly specified.</para>
+
+                <xi:include href="version-info.xml" xpointer="v208"/>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><option>closed</option></term>
+              <listitem>
+                <para>in addition, allows access to standard pseudo
+                devices including
+                <filename>/dev/null</filename>,
+                <filename>/dev/zero</filename>,
+                <filename>/dev/full</filename>,
+                <filename>/dev/random</filename>, and
+                <filename>/dev/urandom</filename>.
+                </para>
+
+                <xi:include href="version-info.xml" xpointer="v208"/>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
+              <term><option>auto</option></term>
+              <listitem>
+                <para>
+                  in addition, allows access to all devices if no
+                  explicit <varname>DeviceAllow=</varname> is present.
+                  This is the default.
+                </para>
+
+                  <xi:include href="version-info.xml" xpointer="v208"/>
+              </listitem>
+            </varlistentry>
+          </variablelist>
+
+          <xi:include href="cgroup-sandboxing.xml" xpointer="singular"/>
+
+          <xi:include href="version-info.xml" xpointer="v208"/>
+        </listitem>
+      </varlistentry>
+
+    </variablelist>
+
+    </refsect2><refsect2><title>Control Group Management</title>
+
+    <variablelist class='unit-directives'>
+
+      <varlistentry>
+        <term><varname>Slice=</varname></term>
+
+        <listitem>
+          <para>The name of the slice unit to place the unit
+          in. Defaults to <filename>system.slice</filename> for all
+          non-instantiated units of all unit types (except for slice
+          units themselves see below). Instance units are by default
+          placed in a subslice of <filename>system.slice</filename>
+          that is named after the template name.</para>
+
+          <para>This option may be used to arrange systemd units in a
+          hierarchy of slices each of which might have resource
+          settings applied.</para>
+
+          <para>For units of type slice, the only accepted value for
+          this setting is the parent slice. Since the name of a slice
+          unit implies the parent slice, it is hence redundant to ever
+          set this parameter directly for slice units.</para>
+
+          <para>Special care should be taken when relying on the default slice assignment in templated service units
+          that have <varname>DefaultDependencies=no</varname> set, see
+          <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>, section
+          "Default Dependencies" for details.</para>
+
+          <xi:include href="version-info.xml" xpointer="v208"/>
+
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Delegate=</varname></term>
+
+        <listitem>
+          <para>Turns on delegation of further resource control partitioning to processes of the unit. Units
+          where this is enabled may create and manage their own private subhierarchy of control groups below
+          the control group of the unit itself. For unprivileged services (i.e. those using the
+          <varname>User=</varname> setting) the unit's control group will be made accessible to the relevant
+          user.</para>
+
+          <para>When enabled the service manager will refrain from manipulating control groups or moving
+          processes below the unit's control group, so that a clear concept of ownership is established: the
+          control group tree at the level of the unit's control group and above (i.e. towards the root
+          control group) is owned and managed by the service manager of the host, while the control group
+          tree below the unit's control group is owned and managed by the unit itself.</para>
+
+          <para>Takes either a boolean argument or a (possibly empty) list of control group controller names.
+          If true, delegation is turned on, and all supported controllers are enabled for the unit, making
+          them available to the unit's processes for management. If false, delegation is turned off entirely
+          (and no additional controllers are enabled). If set to a list of controllers, delegation is turned
+          on, and the specified controllers are enabled for the unit. Assigning the empty string will enable
+          delegation, but reset the list of controllers, and all assignments prior to this will have no
+          effect. Note that additional controllers other than the ones specified might be made available as
+          well, depending on configuration of the containing slice unit or other units contained in it.
+          Defaults to false.</para>
+
+          <para>Note that controller delegation to less privileged code is only safe on the unified control
+          group hierarchy. Accordingly, access to the specified controllers will not be granted to
+          unprivileged services on the legacy hierarchy, even when requested.</para>
+
+          <xi:include href="supported-controllers.xml"  xpointer="controllers-text" />
+
+          <para>Not all of these controllers are available on all kernels however, and some are specific to
+          the unified hierarchy while others are specific to the legacy hierarchy. Also note that the kernel
+          might support further controllers, which aren't covered here yet as delegation is either not
+          supported at all for them or not defined cleanly.</para>
+
+          <para>Note that because of the hierarchical nature of cgroup hierarchy, any controllers that are
+          delegated will be enabled for the parent and sibling units of the unit with delegation.</para>
+
+          <para>For further details on the delegation model consult <ulink
+          url="https://systemd.io/CGROUP_DELEGATION">Control Group APIs and Delegation</ulink>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v218"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>DelegateSubgroup=</varname></term>
+
+        <listitem>
+          <para>Place unit processes in the specified subgroup of the unit's control group. Takes a valid
+          control group name (not a path!) as parameter, or an empty string to turn this feature
+          off. Defaults to off. The control group name must be usable as filename and avoid conflicts with
+          the kernel's control group attribute files (i.e. <filename>cgroup.procs</filename> is not an
+          acceptable name, since the kernel exposes a native control group attribute file by that name). This
+          option has no effect unless control group delegation is turned on via <varname>Delegate=</varname>,
+          see above. Note that this setting only applies to "main" processes of a unit, i.e. for services to
+          <varname>ExecStart=</varname>, but not for <varname>ExecReload=</varname> and similar. If
+          delegation is enabled, the latter are always placed inside a subgroup named
+          <filename>.control</filename>. The specified subgroup is automatically created (and potentially
+          ownership is passed to the unit's configured user/group) when a process is started in it.</para>
+
+          <para>This option is useful to avoid manually moving the invoked process into a subgroup after it
+          has been started. Since no processes should live in inner nodes of the control group tree it's
+          almost always necessary to run the main ("supervising") process of a unit that has delegation
+          turned on in a subgroup.</para>
+
+          <xi:include href="version-info.xml" xpointer="v254"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>DisableControllers=</varname></term>
+
+        <listitem>
+          <para>Disables controllers from being enabled for a unit's children. If a controller listed is
+          already in use in its subtree, the controller will be removed from the subtree. This can be used to
+          avoid configuration in child units from being able to implicitly or explicitly enable a controller.
+          Defaults to empty.</para>
+
+          <para>Multiple controllers may be specified, separated by spaces. You may also pass
+          <varname>DisableControllers=</varname> multiple times, in which case each new instance adds another controller
+          to disable. Passing <varname>DisableControllers=</varname> by itself with no controller name present resets
+          the disabled controller list.</para>
+
+          <para>It may not be possible to disable a controller after units have been started, if the unit or
+          any child of the unit in question delegates controllers to its children, as any delegated subtree
+          of the cgroup hierarchy is unmanaged by systemd.</para>
+
+          <xi:include href="supported-controllers.xml"  xpointer="controllers-text" />
+
+          <xi:include href="version-info.xml" xpointer="v240"/>
+        </listitem>
+      </varlistentry>
+
+    </variablelist>
+
+    </refsect2><refsect2><title>Memory Pressure Control</title>
+
+    <variablelist class='unit-directives'>
+
+      <varlistentry>
+        <term><varname>ManagedOOMSwap=auto|kill</varname></term>
+        <term><varname>ManagedOOMMemoryPressure=auto|kill</varname></term>
+
+        <listitem>
+          <para>Specifies how
+          <citerefentry><refentrytitle>systemd-oomd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+          will act on this unit's cgroups. Defaults to <option>auto</option>.</para>
+
+          <para>When set to <option>kill</option>, the unit becomes a candidate for monitoring by
+          <command>systemd-oomd</command>. If the cgroup passes the limits set by
+          <citerefentry><refentrytitle>oomd.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> or
+          the unit configuration, <command>systemd-oomd</command> will select a descendant cgroup and send
+          <constant>SIGKILL</constant> to all of the processes under it. You can find more details on
+          candidates and kill behavior at
+          <citerefentry><refentrytitle>systemd-oomd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+          and
+          <citerefentry><refentrytitle>oomd.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+
+          <para>Setting either of these properties to <option>kill</option> will also result in
+          <varname>After=</varname> and <varname>Wants=</varname> dependencies on
+          <filename>systemd-oomd.service</filename> unless <varname>DefaultDependencies=no</varname>.</para>
+
+          <para>When set to <option>auto</option>, <command>systemd-oomd</command> will not actively use this
+          cgroup's data for monitoring and detection. However, if an ancestor cgroup has one of these
+          properties set to <option>kill</option>, a unit with <option>auto</option> can still be a candidate
+          for <command>systemd-oomd</command> to terminate.</para>
+
+          <xi:include href="version-info.xml" xpointer="v247"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ManagedOOMMemoryPressureLimit=</varname></term>
+
+        <listitem>
+          <para>Overrides the default memory pressure limit set by
+          <citerefentry><refentrytitle>oomd.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
+          this unit (cgroup). Takes a percentage value between 0% and 100%, inclusive. This property is
+          ignored unless <varname>ManagedOOMMemoryPressure=</varname><option>kill</option>. Defaults to 0%,
+          which means to use the default set by
+          <citerefentry><refentrytitle>oomd.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v247"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ManagedOOMPreference=none|avoid|omit</varname></term>
+
+        <listitem>
+          <para>Allows deprioritizing or omitting this unit's cgroup as a candidate when
+          <command>systemd-oomd</command> needs to act. Requires support for extended attributes (see
+          <citerefentry project='man-pages'><refentrytitle>xattr</refentrytitle><manvolnum>7</manvolnum></citerefentry>)
+          in order to use <option>avoid</option> or <option>omit</option>.</para>
+
+          <para>When calculating candidates to relieve swap usage, <command>systemd-oomd</command> will
+          only respect these extended attributes if the unit's cgroup is owned by root.</para>
+
+          <para>When calculating candidates to relieve memory pressure, <command>systemd-oomd</command>
+          will only respect these extended attributes if the unit's cgroup is owned by root, or if the
+          unit's cgroup owner, and the owner of the monitored ancestor cgroup are the same. For example,
+          if <command>systemd-oomd</command> is calculating candidates for <filename>-.slice</filename>,
+          then extended attributes set on descendants of <filename>/user.slice/user-1000.slice/user@1000.service/</filename>
+          will be ignored because the descendants are owned by UID 1000, and <filename>-.slice</filename>
+          is owned by UID 0. But, if calculating candidates for
+          <filename>/user.slice/user-1000.slice/user@1000.service/</filename>, then extended attributes set
+          on the descendants would be respected.</para>
+
+          <para>If this property is set to <option>avoid</option>, the service manager will convey this to
+          <command>systemd-oomd</command>, which will only select this cgroup if there are no other viable
+          candidates.</para>
+
+          <para>If this property is set to <option>omit</option>, the service manager will convey this to
+          <command>systemd-oomd</command>, which will ignore this cgroup as a candidate and will not perform
+          any actions on it.</para>
+
+          <para>It is recommended to use <option>avoid</option> and <option>omit</option> sparingly, as it
+          can adversely affect <command>systemd-oomd</command>'s kill behavior. Also note that these extended
+          attributes are not applied recursively to cgroups under this unit's cgroup.</para>
+
+          <para>Defaults to <option>none</option> which means <command>systemd-oomd</command> will rank this
+          unit's cgroup as defined in
+          <citerefentry><refentrytitle>systemd-oomd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+          and <citerefentry><refentrytitle>oomd.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v248"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>MemoryPressureWatch=</varname></term>
+
+        <listitem><para>Controls memory pressure monitoring for invoked processes. Takes one of
+        <literal>off</literal>, <literal>on</literal>, <literal>auto</literal> or <literal>skip</literal>. If
+        <literal>off</literal> tells the service not to watch for memory pressure events, by setting the
+        <varname>$MEMORY_PRESSURE_WATCH</varname> environment variable to the literal string
+        <filename>/dev/null</filename>. If <literal>on</literal> tells the service to watch for memory
+        pressure events. This enables memory accounting for the service, and ensures the
+        <filename>memory.pressure</filename> cgroup attribute file is accessible for reading and writing by the
+        service's user. It then sets the <varname>$MEMORY_PRESSURE_WATCH</varname> environment variable for
+        processes invoked by the unit to the file system path to this file. The threshold information
+        configured with <varname>MemoryPressureThresholdSec=</varname> is encoded in the
+        <varname>$MEMORY_PRESSURE_WRITE</varname> environment variable. If the <literal>auto</literal> value
+        is set the protocol is enabled if memory accounting is anyway enabled for the unit, and disabled
+        otherwise. If set to <literal>skip</literal> the logic is neither enabled, nor disabled and the two
+        environment variables are not set.</para>
+
+        <para>Note that services are free to use the two environment variables, but it's unproblematic if
+        they ignore them. Memory pressure handling must be implemented individually in each service, and
+        usually means different things for different software. For further details on memory pressure
+        handling see <ulink url="https://systemd.io/MEMORY_PRESSURE">Memory Pressure Handling in
+        systemd</ulink>.</para>
+
+        <para>Services implemented using
+        <citerefentry><refentrytitle>sd-event</refentrytitle><manvolnum>3</manvolnum></citerefentry> may use
+        <citerefentry><refentrytitle>sd_event_add_memory_pressure</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+        to watch for and handle memory pressure events.</para>
+
+        <para>If not explicit set, defaults to the <varname>DefaultMemoryPressureWatch=</varname> setting in
+        <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>MemoryPressureThresholdSec=</varname></term>
+
+        <listitem><para>Sets the memory pressure threshold time for memory pressure monitor as configured via
+        <varname>MemoryPressureWatch=</varname>. Specifies the maximum allocation latency before a memory
+        pressure event is signalled to the service, per 2s window. If not specified defaults to the
+        <varname>DefaultMemoryPressureThresholdSec=</varname> setting in
+        <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        (which in turn defaults to 200ms). The specified value expects a time unit such as
+        <literal>ms</literal> or <literal>μs</literal>, see
+        <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
+        details on the permitted syntax.</para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+      </varlistentry>
+    </variablelist>
+
+    </refsect2><refsect2><title>Coredump Control</title>
+
+    <variablelist class='unit-directives'>
+
+      <varlistentry>
+        <term><varname>CoredumpReceive=</varname></term>
+
+        <listitem><para>Takes a boolean argument. This setting is used to enable coredump forwarding for containers
+        that belong to this unit's cgroup. Units with <varname>CoredumpReceive=yes</varname> must also be configured
+        with <varname>Delegate=yes</varname>. Defaults to false.</para>
+
+        <para>When <command>systemd-coredump</command> is handling a coredump for a process from a container,
+        if the container's leader process is a descendant of a cgroup with <varname>CoredumpReceive=yes</varname>
+        and <varname>Delegate=yes</varname>, then <command>systemd-coredump</command> will attempt to forward
+        the coredump to <command>systemd-coredump</command> within the container.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+
+    </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <refsect1>
+      <title>History</title>
+
+      <variablelist>
+        <varlistentry>
+          <term>systemd 252</term>
+          <listitem><para> Options for controlling the Legacy Control Group Hierarchy (<ulink
+          url="https://docs.kernel.org/admin-guide/cgroup-v1/index.html">Control Groups version 1</ulink>)
+          are now fully deprecated:
+          <varname>CPUShares=<replaceable>weight</replaceable></varname>,
+          <varname>StartupCPUShares=<replaceable>weight</replaceable></varname>,
+          <varname>MemoryLimit=<replaceable>bytes</replaceable></varname>,
+          <varname>BlockIOAccounting=</varname>,
+          <varname>BlockIOWeight=<replaceable>weight</replaceable></varname>,
+          <varname>StartupBlockIOWeight=<replaceable>weight</replaceable></varname>,
+          <varname>BlockIODeviceWeight=<replaceable>device</replaceable>
+          <replaceable>weight</replaceable></varname>,
+          <varname>BlockIOReadBandwidth=<replaceable>device</replaceable>
+          <replaceable>bytes</replaceable></varname>,
+          <varname>BlockIOWriteBandwidth=<replaceable>device</replaceable> <replaceable>bytes</replaceable></varname>.
+          Please switch to the unified cgroup hierarchy.</para>
+
+ <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+        </varlistentry>
+      </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.scope</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.swap</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-oomd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      The documentation for control groups and specific controllers in the Linux kernel:
+      <ulink url="https://docs.kernel.org/admin-guide/cgroup-v2.html">Control Groups v2</ulink>.
+    </para>
+  </refsect1>
+</refentry>
diff --git a/man/systemd.scope.xml b/man/systemd.scope.xml
new file mode 100644
index 0000000..ae9bc2b
--- /dev/null
+++ b/man/systemd.scope.xml
@@ -0,0 +1,147 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd.scope" xmlns:xi="http://www.w3.org/2001/XInclude">
+  <refentryinfo>
+    <title>systemd.scope</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd.scope</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd.scope</refname>
+    <refpurpose>Scope unit configuration</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename><replaceable>scope</replaceable>.scope</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>Scope units are not configured via unit configuration files,
+    but are only created programmatically using the bus interfaces of
+    systemd. They are named similar to filenames. A unit whose name
+    ends in <literal>.scope</literal> refers to a scope unit. Scopes
+    units manage a set of system processes. Unlike service units, scope
+    units manage externally created processes, and do not fork off
+    processes on its own.</para>
+
+    <para>The main purpose of scope units is grouping worker processes
+    of a system service for organization and for managing resources.</para>
+
+    <para><command>systemd-run <option>--scope</option></command> may
+    be used to easily launch a command in a new scope unit from the
+    command line.</para>
+
+    <para>See the <ulink
+    url="https://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface">New
+    Control Group Interfaces</ulink> for an introduction on how to make
+    use of scope units from programs.</para>
+
+    <para>Note that, unlike service units, scope units have no "main" process: all processes in the scope are
+    equivalent. The lifecycle of the scope unit is thus not bound to the lifetime of one specific process,
+    but to the existence of at least one process in the scope. This also means that the exit statuses of
+    these processes are not relevant for the scope unit failure state. Scope units may still enter a failure
+    state, for example due to resource exhaustion or stop timeouts being reached, but not due to programs
+    inside of them terminating uncleanly. Since processes managed as scope units generally remain children of
+    the original process that forked them off, it is also the job of that process to collect their exit
+    statuses and act on them as needed.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Automatic Dependencies</title>
+
+    <refsect2>
+      <title>Implicit Dependencies</title>
+
+      <para>Implicit dependencies may be added as result of
+      resource control parameters as documented in
+      <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+    </refsect2>
+
+    <refsect2>
+      <title>Default Dependencies</title>
+
+      <para>The following dependencies are added unless
+      <varname>DefaultDependencies=no</varname> is set:</para>
+
+      <itemizedlist>
+        <listitem><para>Scope units will automatically have dependencies of
+        type <varname>Conflicts=</varname> and
+        <varname>Before=</varname> on
+        <filename>shutdown.target</filename>. These ensure
+        that scope units are removed prior to system
+        shutdown. Only scope units involved with early boot or
+        late system shutdown should disable
+        <varname>DefaultDependencies=</varname> option.</para></listitem>
+      </itemizedlist>
+    </refsect2>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>Scope files may include a [Unit] section, which is described in
+    <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+    </para>
+
+    <para>Scope files may include a [Scope]
+    section, which carries information about the scope and the
+    units it contains. A number of options that may be used in
+    this section are shared with other unit types. These options are
+    documented in
+    <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    and
+    <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+    The options specific to the [Scope] section
+    of scope units are the following:</para>
+
+    <variablelist class='unit-directives'>
+      <xi:include href="systemd.service.xml" xpointer="oom-policy" />
+
+      <varlistentry>
+        <term><varname>RuntimeMaxSec=</varname></term>
+
+        <listitem><para>Configures a maximum time for the scope to run. If this is used and the scope has been
+        active for longer than the specified time it is terminated and put into a failure state. Pass
+        <literal>infinity</literal> (the default) to configure no runtime limit.</para>
+
+        <xi:include href="version-info.xml" xpointer="v244"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RuntimeRandomizedExtraSec=</varname></term>
+
+        <listitem><para>This option modifies <varname>RuntimeMaxSec=</varname> by increasing the maximum runtime by an
+        evenly distributed duration between 0 and the specified value (in seconds). If <varname>RuntimeMaxSec=</varname> is
+        unspecified, then this feature will be disabled.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+    </variablelist>
+
+    <xi:include href="systemd.service.xml" xpointer="shared-unit-options" />
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-run</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd.service.xml b/man/systemd.service.xml
new file mode 100644
index 0000000..a5f6179
--- /dev/null
+++ b/man/systemd.service.xml
@@ -0,0 +1,1758 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd.service" xmlns:xi="http://www.w3.org/2001/XInclude">
+  <refentryinfo>
+    <title>systemd.service</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd.service</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd.service</refname>
+    <refpurpose>Service unit configuration</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename><replaceable>service</replaceable>.service</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>A unit configuration file whose name ends in
+    <literal>.service</literal> encodes information about a process
+    controlled and supervised by systemd.</para>
+
+    <para>This man page lists the configuration options specific to
+    this unit type. See
+    <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for the common options of all unit configuration files. The common
+    configuration items are configured in the generic
+    [Unit] and [Install]
+    sections. The service specific configuration options are
+    configured in the [Service] section.</para>
+
+    <para>Additional options are listed in
+    <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    which define the execution environment the commands are executed
+    in, and in
+    <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    which define the way the processes of the service are terminated,
+    and in
+    <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    which configure resource control settings for the processes of the
+    service.</para>
+
+    <para>If SysV init compat is enabled, systemd automatically creates service units that wrap SysV init
+    scripts (the service name is the same as the name of the script, with a <literal>.service</literal>
+    suffix added); see
+    <citerefentry><refentrytitle>systemd-sysv-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+    </para>
+
+    <para>The <citerefentry><refentrytitle>systemd-run</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    command allows creating <filename>.service</filename> and <filename>.scope</filename> units dynamically
+    and transiently from the command line.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Service Templates</title>
+
+    <para>It is possible for <command>systemd</command> services to take a single argument via the
+    <literal><replaceable>service</replaceable>@<replaceable>argument</replaceable>.service</literal>
+    syntax. Such services are called "instantiated" services, while the unit definition without the
+    <replaceable>argument</replaceable> parameter is called a "template". An example could be a
+    <filename>dhcpcd@.service</filename> service template which takes a network interface as a
+    parameter to form an instantiated service. Within the service file, this parameter or "instance
+    name" can be accessed with %-specifiers. See
+    <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for details.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Automatic Dependencies</title>
+
+    <refsect2>
+      <title>Implicit Dependencies</title>
+
+      <para>The following dependencies are implicitly added:</para>
+
+      <itemizedlist>
+        <listitem><para>Services with <varname>Type=dbus</varname> set automatically
+        acquire dependencies of type <varname>Requires=</varname> and
+        <varname>After=</varname> on
+        <filename>dbus.socket</filename>.</para></listitem>
+
+        <listitem><para>Socket activated services are automatically ordered after
+        their activating <filename>.socket</filename> units via an
+        automatic <varname>After=</varname> dependency.
+        Services also pull in all <filename>.socket</filename> units
+        listed in <varname>Sockets=</varname> via automatic
+        <varname>Wants=</varname> and <varname>After=</varname> dependencies.</para></listitem>
+      </itemizedlist>
+
+      <para>Additional implicit dependencies may be added as result of
+      execution and resource control parameters as documented in
+      <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+      and
+      <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+    </refsect2>
+
+    <refsect2>
+      <title>Default Dependencies</title>
+
+      <para>The following dependencies are added unless <varname>DefaultDependencies=no</varname> is set:</para>
+
+      <itemizedlist>
+        <listitem><para>Service units will have dependencies of type <varname>Requires=</varname> and
+        <varname>After=</varname> on <filename>sysinit.target</filename>, a dependency of type <varname>After=</varname> on
+        <filename>basic.target</filename> as well as dependencies of type <varname>Conflicts=</varname> and
+        <varname>Before=</varname> on <filename>shutdown.target</filename>. These ensure that normal service units pull in
+        basic system initialization, and are terminated cleanly prior to system shutdown. Only services involved with early
+        boot or late system shutdown should disable this option.</para></listitem>
+
+        <listitem><para>Instanced service units (i.e. service units with an <literal>@</literal> in their name) are assigned by
+        default a per-template slice unit (see
+        <citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry>), named after the
+        template unit, containing all instances of the specific template. This slice is normally stopped at shutdown,
+        together with all template instances. If that is not desired, set <varname>DefaultDependencies=no</varname> in the
+        template unit, and either define your own per-template slice unit file that also sets
+        <varname>DefaultDependencies=no</varname>, or set <varname>Slice=system.slice</varname> (or another suitable slice)
+        in the template unit. Also see
+        <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+        </para></listitem>
+      </itemizedlist>
+    </refsect2>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>Service unit files may include [Unit] and [Install] sections, which are described in
+    <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+    </para>
+
+    <para>Service unit files must include a [Service]
+    section, which carries information about the service and the
+    process it supervises. A number of options that may be used in
+    this section are shared with other unit types. These options are
+    documented in
+    <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    and
+    <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+    The options specific to the [Service] section
+    of service units are the following:</para>
+
+    <variablelist class='unit-directives'>
+      <varlistentry>
+        <term><varname>Type=</varname></term>
+
+        <listitem>
+          <para>Configures the mechanism via which the service notifies the manager that the service start-up
+          has finished. One of <option>simple</option>, <option>exec</option>, <option>forking</option>,
+          <option>oneshot</option>, <option>dbus</option>, <option>notify</option>,
+          <option>notify-reload</option>, or <option>idle</option>:</para>
+
+          <itemizedlist>
+            <listitem><para>If set to <option>simple</option> (the default if <varname>ExecStart=</varname>
+            is specified but neither <varname>Type=</varname> nor <varname>BusName=</varname> are), the
+            service manager will consider the unit started immediately after the main service process has
+            been forked off (i.e. immediately after <function>fork()</function>, and before various process
+            attributes have been configured and in particular before the new process has called
+            <function>execve()</function> to invoke the actual service binary). Typically,
+            <varname>Type=</varname><option>exec</option> is the better choice, see below.</para>
+
+            <para>It is expected that the process configured with <varname>ExecStart=</varname> is the main
+            process of the service. In this mode, if the process offers functionality to other processes on
+            the system, its communication channels should be installed before the service is started up
+            (e.g. sockets set up by systemd, via socket activation), as the service manager will immediately
+            proceed starting follow-up units, right after creating the main service process, and before
+            executing the service's binary. Note that this means <command>systemctl start</command> command
+            lines for <option>simple</option> services will report success even if the service's binary
+            cannot be invoked successfully (for example because the selected <varname>User=</varname> doesn't
+            exist, or the service binary is missing).</para></listitem>
+
+            <listitem><para>The <option>exec</option> type is similar to <option>simple</option>, but the
+            service manager will consider the unit started immediately after the main service binary has been
+            executed. The service manager will delay starting of follow-up units until that point. (Or in
+            other words: <option>simple</option> proceeds with further jobs right after
+            <function>fork()</function> returns, while <option>exec</option> will not proceed before both
+            <function>fork()</function> and <function>execve()</function> in the service process succeeded.)
+            Note that this means <command>systemctl start</command> command lines for <option>exec</option>
+            services will report failure when the service's binary cannot be invoked successfully (for
+            example because the selected <varname>User=</varname> doesn't exist, or the service binary is
+            missing).</para></listitem>
+
+            <listitem><para>If set to <option>forking</option>, the manager will consider the unit started
+            immediately after the binary that forked off by the manager exits. <emphasis>The use of this type
+            is discouraged, use <option>notify</option>, <option>notify-reload</option>, or
+            <option>dbus</option> instead.</emphasis></para>
+
+            <para>It is expected that the process configured with <varname>ExecStart=</varname> will call
+            <function>fork()</function> as part of its start-up. The parent process is expected to exit when
+            start-up is complete and all communication channels are set up. The child continues to run as the
+            main service process, and the service manager will consider the unit started when the parent
+            process exits. This is the behavior of traditional UNIX services. If this setting is used, it is
+            recommended to also use the <varname>PIDFile=</varname> option, so that systemd can reliably
+            identify the main process of the service. The manager will proceed with starting follow-up units
+            after the parent process exits.</para></listitem>
+
+            <listitem><para>Behavior of <option>oneshot</option> is similar to <option>simple</option>;
+            however, the service manager will consider the unit up after the main process exits. It will then
+            start follow-up units. <varname>RemainAfterExit=</varname> is particularly useful for this type
+            of service. <varname>Type=</varname><option>oneshot</option> is the implied default if neither
+            <varname>Type=</varname> nor <varname>ExecStart=</varname> are specified. Note that if this
+            option is used without <varname>RemainAfterExit=</varname> the service will never enter
+            <literal>active</literal> unit state, but will directly transition from
+            <literal>activating</literal> to <literal>deactivating</literal> or <literal>dead</literal>,
+            since no process is configured that shall run continuously. In particular this means that after a
+            service of this type ran (and which has <varname>RemainAfterExit=</varname> not set) it will not
+            show up as started afterwards, but as dead.</para></listitem>
+
+            <listitem><para>Behavior of <option>dbus</option> is similar to <option>simple</option>; however,
+            units of this type must have the <varname>BusName=</varname> specified and the service manager
+            will consider the unit up when the specified bus name has been acquired. This type is the default
+            if <varname>BusName=</varname> is specified.</para>
+
+            <para>Service units with this option configured implicitly gain dependencies on the
+            <filename>dbus.socket</filename> unit. A service unit of this type is considered to be in the
+            activating state until the specified bus name is acquired. It is considered activated while the
+            bus name is taken. Once the bus name is released the service is considered being no longer
+            functional which has the effect that the service manager attempts to terminate any remaining
+            processes belonging to the service. Services that drop their bus name as part of their shutdown
+            logic thus should be prepared to receive a <constant>SIGTERM</constant> (or whichever signal is
+            configured in <varname>KillSignal=</varname>) as result.</para></listitem>
+
+            <listitem><para>Behavior of <option>notify</option> is similar to <option>exec</option>; however,
+            it is expected that the service sends a <literal>READY=1</literal> notification message via
+            <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry> or
+            an equivalent call when it has finished starting up. systemd will proceed with starting follow-up
+            units after this notification message has been sent. If this option is used,
+            <varname>NotifyAccess=</varname> (see below) should be set to open access to the notification
+            socket provided by systemd. If <varname>NotifyAccess=</varname> is missing or set to
+            <option>none</option>, it will be forcibly set to <option>main</option>.</para>
+
+            <para>If the service supports reloading, and uses a signal to start the reload, using
+            <option>notify-reload</option> instead is recommended.</para></listitem>
+
+            <listitem><para>Behavior of <option>notify-reload</option> is similar to <option>notify</option>,
+            with one difference: the <constant>SIGHUP</constant> UNIX process signal is sent to the service's
+            main process when the service is asked to reload and the manager will wait for a notification
+            about the reload being finished.</para>
+
+            <para>When initiating the reload process the service is expected to reply with a notification
+            message via
+            <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+            that contains the <literal>RELOADING=1</literal> field in combination with
+            <literal>MONOTONIC_USEC=</literal> set to the current monotonic time
+            (i.e. <constant>CLOCK_MONOTONIC</constant> in
+            <citerefentry><refentrytitle>clock_gettime</refentrytitle><manvolnum>2</manvolnum></citerefentry>)
+            in μs, formatted as decimal string. Once reloading is complete another notification message must
+            be sent, containing <literal>READY=1</literal>. Using this service type and implementing this
+            reload protocol is an efficient alternative to providing an <varname>ExecReload=</varname>
+            command for reloading of the service's configuration.</para>
+
+            <para>The signal to send can be tweaked via <varname>ReloadSignal=</varname>, see below.</para>
+            </listitem>
+
+            <listitem><para>Behavior of <option>idle</option> is very similar to <option>simple</option>; however,
+            actual execution of the service program is delayed until all active jobs are dispatched. This may be used
+            to avoid interleaving of output of shell services with the status output on the console. Note that this
+            type is useful only to improve console output, it is not useful as a general unit ordering tool, and the
+            effect of this service type is subject to a 5s timeout, after which the service program is invoked
+            anyway.</para></listitem>
+          </itemizedlist>
+
+          <para>It is recommended to use <varname>Type=</varname><option>exec</option> for long-running
+          services, as it ensures that process setup errors (e.g. errors such as a missing service
+          executable, or missing user) are properly tracked. However, as this service type won't propagate
+          the failures in the service's own startup code (as opposed to failures in the preparatory steps the
+          service manager executes before <function>execve()</function>) and doesn't allow ordering of other
+          units against completion of initialization of the service code itself (which for example is useful
+          if clients need to connect to the service through some form of IPC, and the IPC channel is only
+          established by the service itself — in contrast to doing this ahead of time through socket or bus
+          activation or similar), it might not be sufficient for many cases. If so, <option>notify</option>,
+          <option>notify-reload</option>, or <option>dbus</option> (the latter only in case the service
+          provides a D-Bus interface) are the preferred options as they allow service program code to
+          precisely schedule when to consider the service started up successfully and when to proceed with
+          follow-up units. The <option>notify</option>/<option>notify-reload</option> service types require
+          explicit support in the service codebase (as <function>sd_notify()</function> or an equivalent API
+          needs to be invoked by the service at the appropriate time) — if it's not supported, then
+          <option>forking</option> is an alternative: it supports the traditional heavy-weight UNIX service
+          start-up protocol. Note that using any type other than <option>simple</option> possibly delays the
+          boot process, as the service manager needs to wait for at least some service initialization to
+          complete. (Also note it is generally not recommended to use <option>idle</option> or
+          <option>oneshot</option> for long-running services.)</para>
+
+          <para>Note that various service settings (e.g. <varname>User=</varname>, <varname>Group=</varname>
+          through libc NSS) might result in "hidden" blocking IPC calls to other services when
+          used. Sometimes it might be advisable to use the <option>simple</option> service type to ensure
+          that the service manager's transaction logic is not affected by such potentially slow operations
+          and hidden dependencies, as this is the only service type where the service manager will not wait
+          for such service execution setup operations to complete before proceeding.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ExitType=</varname></term>
+
+        <listitem>
+          <para>Specifies when the manager should consider the service to be finished. One of <option>main</option> or
+          <option>cgroup</option>:</para>
+
+          <itemizedlist>
+            <listitem><para>If set to <option>main</option> (the default), the service manager
+            will consider the unit stopped when the main process, which is determined according to the
+            <varname>Type=</varname>, exits. Consequently, it cannot be used with
+            <varname>Type=</varname><option>oneshot</option>.</para></listitem>
+
+            <listitem><para>If set to <option>cgroup</option>, the service will be considered running as long as at
+            least one process in the cgroup has not exited.</para></listitem>
+          </itemizedlist>
+
+          <para>It is generally recommended to use <varname>ExitType=</varname><option>main</option> when a service has
+          a known forking model and a main process can reliably be determined. <varname>ExitType=</varname>
+          <option>cgroup</option> is meant for applications whose forking model is not known ahead of time and which
+          might not have a specific main process. It is well suited for transient or automatically generated services,
+          such as graphical applications inside of a desktop environment.</para>
+
+          <xi:include href="version-info.xml" xpointer="v250"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RemainAfterExit=</varname></term>
+
+        <listitem><para>Takes a boolean value that specifies whether
+        the service shall be considered active even when all its
+        processes exited. Defaults to <option>no</option>.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>GuessMainPID=</varname></term>
+
+        <listitem><para>Takes a boolean value that specifies whether
+        systemd should try to guess the main PID of a service if it
+        cannot be determined reliably. This option is ignored unless
+        <option>Type=forking</option> is set and
+        <option>PIDFile=</option> is unset because for the other types
+        or with an explicitly configured PID file, the main PID is
+        always known. The guessing algorithm might come to incorrect
+        conclusions if a daemon consists of more than one process. If
+        the main PID cannot be determined, failure detection and
+        automatic restarting of a service will not work reliably.
+        Defaults to <option>yes</option>.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>PIDFile=</varname></term>
+
+        <listitem><para>Takes a path referring to the PID file of the service. Usage of this option is recommended for
+        services where <varname>Type=</varname> is set to <option>forking</option>. The path specified typically points
+        to a file below <filename>/run/</filename>. If a relative path is specified it is hence prefixed with
+        <filename>/run/</filename>. The service manager will read the PID of the main process of the service from this
+        file after start-up of the service. The service manager will not write to the file configured here, although it
+        will remove the file after the service has shut down if it still exists. The PID file does not need to be owned
+        by a privileged user, but if it is owned by an unprivileged user additional safety restrictions are enforced:
+        the file may not be a symlink to a file owned by a different user (neither directly nor indirectly), and the
+        PID file must refer to a process already belonging to the service.</para>
+
+        <para>Note that PID files should be avoided in modern projects. Use <option>Type=notify</option>,
+        <option>Type=notify-reload</option> or <option>Type=simple</option> where possible, which does not
+        require use of PID files to determine the main process of a service and avoids needless
+        forking.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>BusName=</varname></term>
+
+        <listitem><para>Takes a D-Bus destination name that this service shall use. This option is mandatory
+        for services where <varname>Type=</varname> is set to <option>dbus</option>. It is recommended to
+        always set this property if known to make it easy to map the service name to the D-Bus destination.
+        In particular, <command>systemctl service-log-level/service-log-target</command> verbs make use of
+        this.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ExecStart=</varname></term>
+        <listitem><para>Commands that are executed when this service is started. The value is split into zero
+        or more command lines according to the rules described in the section "Command Lines" below.</para>
+
+        <para>Unless <varname>Type=</varname> is <option>oneshot</option>, exactly one command must be given. When
+        <varname>Type=oneshot</varname> is used, zero or more commands may be specified. Commands may be specified by
+        providing multiple command lines in the same directive, or alternatively, this directive may be specified more
+        than once with the same effect. If the empty string is assigned to this option, the list of commands to start
+        is reset, prior assignments of this option will have no effect. If no <varname>ExecStart=</varname> is
+        specified, then the service must have <varname>RemainAfterExit=yes</varname> and at least one
+        <varname>ExecStop=</varname> line set. (Services lacking both <varname>ExecStart=</varname> and
+        <varname>ExecStop=</varname> are not valid.)</para>
+
+        <para>If more than one command is specified, the commands are
+        invoked sequentially in the order they appear in the unit
+        file. If one of the commands fails (and is not prefixed with
+        <literal>-</literal>), other lines are not executed, and the
+        unit is considered failed.</para>
+
+        <para>Unless <varname>Type=forking</varname> is set, the
+        process started via this command line will be considered the
+        main process of the daemon.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ExecStartPre=</varname></term>
+        <term><varname>ExecStartPost=</varname></term>
+        <listitem><para>Additional commands that are executed before
+        or after the command in <varname>ExecStart=</varname>,
+        respectively. Syntax is the same as for
+        <varname>ExecStart=</varname>, except that multiple command
+        lines are allowed and the commands are executed one after the
+        other, serially.</para>
+
+        <para>If any of those commands (not prefixed with
+        <literal>-</literal>) fail, the rest are not executed and the
+        unit is considered failed.</para>
+
+        <para><varname>ExecStart=</varname> commands are only run after
+        all <varname>ExecStartPre=</varname> commands that were not prefixed
+        with a <literal>-</literal> exit successfully.</para>
+
+        <para><varname>ExecStartPost=</varname> commands are only run after the commands specified in
+        <varname>ExecStart=</varname> have been invoked successfully, as determined by
+        <varname>Type=</varname> (i.e. the process has been started for <varname>Type=simple</varname> or
+        <varname>Type=idle</varname>, the last <varname>ExecStart=</varname> process exited successfully for
+        <varname>Type=oneshot</varname>, the initial process exited successfully for
+        <varname>Type=forking</varname>, <literal>READY=1</literal> is sent for
+        <varname>Type=notify</varname>/<varname>Type=notify-reload</varname>, or the
+        <varname>BusName=</varname> has been taken for <varname>Type=dbus</varname>).</para>
+
+        <para>Note that <varname>ExecStartPre=</varname> may not be
+        used to start long-running processes. All processes forked
+        off by processes invoked via <varname>ExecStartPre=</varname> will
+        be killed before the next service process is run.</para>
+
+        <para>Note that if any of the commands specified in <varname>ExecStartPre=</varname>,
+        <varname>ExecStart=</varname>, or <varname>ExecStartPost=</varname> fail (and are not prefixed with
+        <literal>-</literal>, see above) or time out before the service is fully up, execution continues with commands
+        specified in <varname>ExecStopPost=</varname>, the commands in <varname>ExecStop=</varname> are skipped.</para>
+
+        <para>Note that the execution of <varname>ExecStartPost=</varname> is taken into account for the purpose of
+        <varname>Before=</varname>/<varname>After=</varname> ordering constraints.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ExecCondition=</varname></term>
+        <listitem><para>Optional commands that are executed before the commands in <varname>ExecStartPre=</varname>.
+        Syntax is the same as for <varname>ExecStart=</varname>, except that multiple command lines are allowed and the
+        commands are executed one after the other, serially.</para>
+
+        <para>The behavior is like an <varname>ExecStartPre=</varname> and condition check hybrid: when an
+        <varname>ExecCondition=</varname> command exits with exit code 1 through 254 (inclusive), the remaining
+        commands are skipped and the unit is <emphasis>not</emphasis> marked as failed. However, if an
+        <varname>ExecCondition=</varname> command exits with 255 or abnormally (e.g. timeout, killed by a
+        signal, etc.), the unit will be considered failed (and remaining commands will be skipped). Exit code of 0 or
+        those matching <varname>SuccessExitStatus=</varname> will continue execution to the next commands.</para>
+
+        <para>The same recommendations about not running long-running processes in <varname>ExecStartPre=</varname>
+        also applies to <varname>ExecCondition=</varname>. <varname>ExecCondition=</varname> will also run the commands
+        in <varname>ExecStopPost=</varname>, as part of stopping the service, in the case of any non-zero or abnormal
+        exits, like the ones described above.</para>
+
+        <xi:include href="version-info.xml" xpointer="v243"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ExecReload=</varname></term>
+
+        <listitem><para>Commands to execute to trigger a configuration reload in the service. This argument
+        takes multiple command lines, following the same scheme as described for
+        <varname>ExecStart=</varname> above. Use of this setting is optional. Specifier and environment
+        variable substitution is supported here following the same scheme as for
+        <varname>ExecStart=</varname>.</para>
+
+        <para>One additional, special environment variable is set: if known, <varname>$MAINPID</varname> is
+        set to the main process of the daemon, and may be used for command lines like the following:</para>
+
+        <programlisting>ExecReload=kill -HUP $MAINPID</programlisting>
+
+        <para>Note however that reloading a daemon by enqueuing a signal (as with the example line above) is
+        usually not a good choice, because this is an asynchronous operation and hence not suitable when
+        ordering reloads of multiple services against each other. It is thus strongly recommended to either
+        use <varname>Type=</varname><option>notify-reload</option> in place of
+        <varname>ExecReload=</varname>, or to set <varname>ExecReload=</varname> to a command that not only
+        triggers a configuration reload of the daemon, but also synchronously waits for it to complete. For
+        example, <citerefentry
+        project='mankier'><refentrytitle>dbus-broker</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+        uses the following:</para>
+
+        <programlisting>ExecReload=busctl call org.freedesktop.DBus \
+        /org/freedesktop/DBus org.freedesktop.DBus \
+        ReloadConfig
+</programlisting>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ExecStop=</varname></term>
+        <listitem><para>Commands to execute to stop the service started via
+        <varname>ExecStart=</varname>. This argument takes multiple command lines, following the same scheme
+        as described for <varname>ExecStart=</varname> above. Use of this setting is optional. After the
+        commands configured in this option are run, it is implied that the service is stopped, and any
+        processes remaining for it are terminated according to the <varname>KillMode=</varname> setting (see
+        <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
+        If this option is not specified, the process is terminated by sending the signal specified in
+        <varname>KillSignal=</varname> or <varname>RestartKillSignal=</varname> when service stop is
+        requested. Specifier and environment variable substitution is supported (including
+        <varname>$MAINPID</varname>, see above).</para>
+
+        <para>Note that it is usually not sufficient to specify a command for this setting that only asks the
+        service to terminate (for example, by sending some form of termination signal to it), but does not
+        wait for it to do so. Since the remaining processes of the services are killed according to
+        <varname>KillMode=</varname> and <varname>KillSignal=</varname> or
+        <varname>RestartKillSignal=</varname> as described above immediately after the command exited, this
+        may not result in a clean stop. The specified command should hence be a synchronous operation, not an
+        asynchronous one.</para>
+
+        <para>Note that the commands specified in <varname>ExecStop=</varname> are only executed when the service
+        started successfully first. They are not invoked if the service was never started at all, or in case its
+        start-up failed, for example because any of the commands specified in <varname>ExecStart=</varname>,
+        <varname>ExecStartPre=</varname> or <varname>ExecStartPost=</varname> failed (and weren't prefixed with
+        <literal>-</literal>, see above) or timed out. Use <varname>ExecStopPost=</varname> to invoke commands when a
+        service failed to start up correctly and is shut down again. Also note that the stop operation is always
+        performed if the service started successfully, even if the processes in the service terminated on their
+        own or were killed. The stop commands must be prepared to deal with that case. <varname>$MAINPID</varname>
+        will be unset if systemd knows that the main process exited by the time the stop commands are called.</para>
+
+        <para>Service restart requests are implemented as stop operations followed by start operations. This
+        means that <varname>ExecStop=</varname> and <varname>ExecStopPost=</varname> are executed during a
+        service restart operation.</para>
+
+        <para>It is recommended to use this setting for commands that communicate with the service requesting
+        clean termination. For post-mortem clean-up steps use <varname>ExecStopPost=</varname> instead.
+        </para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ExecStopPost=</varname></term>
+        <listitem><para>Additional commands that are executed after the service is stopped. This includes cases where
+        the commands configured in <varname>ExecStop=</varname> were used, where the service does not have any
+        <varname>ExecStop=</varname> defined, or where the service exited unexpectedly. This argument takes multiple
+        command lines, following the same scheme as described for <varname>ExecStart=</varname>. Use of these settings
+        is optional. Specifier and environment variable substitution is supported. Note that – unlike
+        <varname>ExecStop=</varname> – commands specified with this setting are invoked when a service failed to start
+        up correctly and is shut down again.</para>
+
+        <para>It is recommended to use this setting for clean-up operations that shall be executed even when the
+        service failed to start up correctly. Commands configured with this setting need to be able to operate even if
+        the service failed starting up half-way and left incompletely initialized data around. As the service's
+        processes have been terminated already when the commands specified with this setting are executed they should
+        not attempt to communicate with them.</para>
+
+        <para>Note that all commands that are configured with this setting are invoked with the result code of the
+        service, as well as the main process' exit code and status, set in the <varname>$SERVICE_RESULT</varname>,
+        <varname>$EXIT_CODE</varname> and <varname>$EXIT_STATUS</varname> environment variables, see
+        <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
+        details.</para>
+
+        <para>Note that the execution of <varname>ExecStopPost=</varname> is taken into account for the purpose of
+        <varname>Before=</varname>/<varname>After=</varname> ordering constraints.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RestartSec=</varname></term>
+        <listitem><para>Configures the time to sleep before restarting
+        a service (as configured with <varname>Restart=</varname>).
+        Takes a unit-less value in seconds, or a time span value such
+        as "5min 20s". Defaults to 100ms.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RestartSteps=</varname></term>
+        <listitem><para>Configures the number of steps to take to increase the interval
+        of auto-restarts from <varname>RestartSec=</varname> to <varname>RestartMaxDelaySec=</varname>.
+        Takes a positive integer or 0 to disable it. Defaults to 0.</para>
+
+        <para>This setting is effective only if <varname>RestartMaxDelaySec=</varname> is also set.</para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RestartMaxDelaySec=</varname></term>
+        <listitem><para>Configures the longest time to sleep before restarting a service
+        as the interval goes up with <varname>RestartSteps=</varname>. Takes a value
+        in the same format as <varname>RestartSec=</varname>, or <literal>infinity</literal>
+        to disable the setting. Defaults to <literal>infinity</literal>.</para>
+
+        <para>This setting is effective only if <varname>RestartSteps=</varname> is also set.</para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>TimeoutStartSec=</varname></term>
+        <listitem><para>Configures the time to wait for start-up. If a daemon service does not signal
+        start-up completion within the configured time, the service will be considered failed and will be
+        shut down again. The precise action depends on the <varname>TimeoutStartFailureMode=</varname>
+        option. Takes a unit-less value in seconds, or a time span value such as "5min 20s". Pass
+        <literal>infinity</literal> to disable the timeout logic. Defaults to
+        <varname>DefaultTimeoutStartSec=</varname> set in the manager, except when
+        <varname>Type=oneshot</varname> is used, in which case the timeout is disabled by default (see
+        <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
+        </para>
+
+        <para>If a service of <varname>Type=notify</varname>/<varname>Type=notify-reload</varname> sends
+        <literal>EXTEND_TIMEOUT_USEC=…</literal>, this may cause the start time to be extended beyond
+        <varname>TimeoutStartSec=</varname>. The first receipt of this message must occur before
+        <varname>TimeoutStartSec=</varname> is exceeded, and once the start time has extended beyond
+        <varname>TimeoutStartSec=</varname>, the service manager will allow the service to continue to start,
+        provided the service repeats <literal>EXTEND_TIMEOUT_USEC=…</literal> within the interval specified
+        until the service startup status is finished by <literal>READY=1</literal>. (see
+        <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>).
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v188"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>TimeoutStopSec=</varname></term>
+        <listitem><para>This option serves two purposes. First, it configures the time to wait for each
+        <varname>ExecStop=</varname> command. If any of them times out, subsequent <varname>ExecStop=</varname> commands
+        are skipped and the service will be terminated by <constant>SIGTERM</constant>. If no <varname>ExecStop=</varname>
+        commands are specified, the service gets the <constant>SIGTERM</constant> immediately. This default behavior
+        can be changed by the <varname>TimeoutStopFailureMode=</varname> option. Second, it configures the time
+        to wait for the service itself to stop. If it doesn't terminate in the specified time, it will be forcibly terminated
+        by <constant>SIGKILL</constant> (see <varname>KillMode=</varname> in
+        <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
+        Takes a unit-less value in seconds, or a time span value such
+        as "5min 20s". Pass <literal>infinity</literal> to disable the
+        timeout logic. Defaults to
+        <varname>DefaultTimeoutStopSec=</varname> from the manager
+        configuration file (see
+        <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
+        </para>
+
+        <para>If a service of <varname>Type=notify</varname>/<varname>Type=notify-reload</varname> sends
+        <literal>EXTEND_TIMEOUT_USEC=…</literal>, this may cause the stop time to be extended beyond
+        <varname>TimeoutStopSec=</varname>. The first receipt of this message must occur before
+        <varname>TimeoutStopSec=</varname> is exceeded, and once the stop time has extended beyond
+        <varname>TimeoutStopSec=</varname>, the service manager will allow the service to continue to stop,
+        provided the service repeats <literal>EXTEND_TIMEOUT_USEC=…</literal> within the interval specified,
+        or terminates itself (see
+        <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>).
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v188"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>TimeoutAbortSec=</varname></term>
+        <listitem><para>This option configures the time to wait for the service to terminate when it was aborted due to a
+        watchdog timeout (see <varname>WatchdogSec=</varname>). If the service has a short <varname>TimeoutStopSec=</varname>
+        this option can be used to give the system more time to write a core dump of the service. Upon expiration the service
+        will be forcibly terminated by <constant>SIGKILL</constant> (see <varname>KillMode=</varname> in
+        <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>). The core file will
+        be truncated in this case. Use <varname>TimeoutAbortSec=</varname> to set a sensible timeout for the core dumping per
+        service that is large enough to write all expected data while also being short enough to handle the service failure
+        in due time.
+        </para>
+
+        <para>Takes a unit-less value in seconds, or a time span value such as "5min 20s". Pass an empty value to skip
+        the dedicated watchdog abort timeout handling and fall back <varname>TimeoutStopSec=</varname>. Pass
+        <literal>infinity</literal> to disable the timeout logic. Defaults to <varname>DefaultTimeoutAbortSec=</varname> from
+        the manager configuration file (see
+        <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
+        </para>
+
+        <para>If a service of <varname>Type=notify</varname>/<varname>Type=notify-reload</varname> handles
+        <constant>SIGABRT</constant> itself (instead of relying on the kernel to write a core dump) it can
+        send <literal>EXTEND_TIMEOUT_USEC=…</literal> to extended the abort time beyond
+        <varname>TimeoutAbortSec=</varname>. The first receipt of this message must occur before
+        <varname>TimeoutAbortSec=</varname> is exceeded, and once the abort time has extended beyond
+        <varname>TimeoutAbortSec=</varname>, the service manager will allow the service to continue to abort,
+        provided the service repeats <literal>EXTEND_TIMEOUT_USEC=…</literal> within the interval specified,
+        or terminates itself (see
+        <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>).
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v243"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>TimeoutSec=</varname></term>
+        <listitem><para>A shorthand for configuring both
+        <varname>TimeoutStartSec=</varname> and
+        <varname>TimeoutStopSec=</varname> to the specified value.
+        </para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>TimeoutStartFailureMode=</varname></term>
+        <term><varname>TimeoutStopFailureMode=</varname></term>
+
+        <listitem><para>These options configure the action that is taken in case a daemon service does not signal
+        start-up within its configured <varname>TimeoutStartSec=</varname>, respectively if it does not stop within
+        <varname>TimeoutStopSec=</varname>. Takes one of <option>terminate</option>, <option>abort</option> and
+        <option>kill</option>. Both options default to <option>terminate</option>.</para>
+
+        <para>If <option>terminate</option> is set the service will be gracefully terminated by sending the signal
+        specified in <varname>KillSignal=</varname> (defaults to <constant>SIGTERM</constant>, see
+        <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>). If the
+        service does not terminate the <varname>FinalKillSignal=</varname> is sent after
+        <varname>TimeoutStopSec=</varname>. If <option>abort</option> is set, <varname>WatchdogSignal=</varname> is sent
+        instead and <varname>TimeoutAbortSec=</varname> applies before sending <varname>FinalKillSignal=</varname>.
+        This setting may be used to analyze services that fail to start-up or shut-down intermittently.
+        By using <option>kill</option> the service is immediately terminated by sending
+        <varname>FinalKillSignal=</varname> without any further timeout. This setting can be used to expedite the
+        shutdown of failing services.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RuntimeMaxSec=</varname></term>
+
+        <listitem><para>Configures a maximum time for the service to run. If this is used and the service has been
+        active for longer than the specified time it is terminated and put into a failure state. Note that this setting
+        does not have any effect on <varname>Type=oneshot</varname> services, as they terminate immediately after
+        activation completed. Pass <literal>infinity</literal> (the default) to configure no runtime
+        limit.</para>
+
+        <para>If a service of <varname>Type=notify</varname>/<varname>Type=notify-reload</varname> sends
+        <literal>EXTEND_TIMEOUT_USEC=…</literal>, this may cause the runtime to be extended beyond
+        <varname>RuntimeMaxSec=</varname>. The first receipt of this message must occur before
+        <varname>RuntimeMaxSec=</varname> is exceeded, and once the runtime has extended beyond
+        <varname>RuntimeMaxSec=</varname>, the service manager will allow the service to continue to run,
+        provided the service repeats <literal>EXTEND_TIMEOUT_USEC=…</literal> within the interval specified
+        until the service shutdown is achieved by <literal>STOPPING=1</literal> (or termination). (see
+        <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>).
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v229"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RuntimeRandomizedExtraSec=</varname></term>
+
+        <listitem><para>This option modifies <varname>RuntimeMaxSec=</varname> by increasing the maximum runtime by an
+        evenly distributed duration between 0 and the specified value (in seconds). If <varname>RuntimeMaxSec=</varname> is
+        unspecified, then this feature will be disabled.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>WatchdogSec=</varname></term>
+        <listitem><para>Configures the watchdog timeout for a service.
+        The watchdog is activated when the start-up is completed. The
+        service must call
+        <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+        regularly with <literal>WATCHDOG=1</literal> (i.e. the
+        "keep-alive ping"). If the time between two such calls is
+        larger than the configured time, then the service is placed in
+        a failed state and it will be terminated with
+        <constant>SIGABRT</constant> (or the signal specified by
+        <varname>WatchdogSignal=</varname>). By setting
+        <varname>Restart=</varname> to <option>on-failure</option>,
+        <option>on-watchdog</option>, <option>on-abnormal</option> or
+        <option>always</option>, the service will be automatically
+        restarted. The time configured here will be passed to the
+        executed service process in the
+        <varname>WATCHDOG_USEC=</varname> environment variable. This
+        allows daemons to automatically enable the keep-alive pinging
+        logic if watchdog support is enabled for the service. If this
+        option is used, <varname>NotifyAccess=</varname> (see below)
+        should be set to open access to the notification socket
+        provided by systemd. If <varname>NotifyAccess=</varname> is
+        not set, it will be implicitly set to <option>main</option>.
+        Defaults to 0, which disables this feature. The service can
+        check whether the service manager expects watchdog keep-alive
+        notifications. See
+        <citerefentry><refentrytitle>sd_watchdog_enabled</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+        for details.
+        <citerefentry><refentrytitle>sd_event_set_watchdog</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+        may be used to enable automatic watchdog notification support.
+        </para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Restart=</varname></term>
+        <listitem><para>Configures whether the service shall be restarted when the service process exits,
+        is killed, or a timeout is reached. The service process may be the main service process, but it may
+        also be one of the processes specified with <varname>ExecStartPre=</varname>,
+        <varname>ExecStartPost=</varname>, <varname>ExecStop=</varname>, <varname>ExecStopPost=</varname>,
+        or <varname>ExecReload=</varname>. When the death of the process is a result of systemd operation
+        (e.g. service stop or restart), the service will not be restarted. Timeouts include missing the watchdog
+        "keep-alive ping" deadline and a service start, reload, and stop operation timeouts.</para>
+
+        <para>Takes one of <option>no</option>, <option>on-success</option>, <option>on-failure</option>,
+        <option>on-abnormal</option>, <option>on-watchdog</option>, <option>on-abort</option>, or
+        <option>always</option>. If set to <option>no</option> (the default), the service will not be restarted.
+        If set to <option>on-success</option>, it will be restarted only when the service process exits cleanly.
+        In this context, a clean exit means any of the following:
+        <itemizedlist>
+            <listitem><simpara>exit code of 0;</simpara></listitem>
+            <listitem><simpara>for types other than <varname>Type=oneshot</varname>, one of the signals
+                <constant>SIGHUP</constant>, <constant>SIGINT</constant>,
+                <constant>SIGTERM</constant>, or <constant>SIGPIPE</constant>;
+            </simpara></listitem>
+            <listitem><simpara>exit statuses and signals specified in
+                <varname>SuccessExitStatus=</varname>.</simpara></listitem>
+        </itemizedlist>
+        If set to <option>on-failure</option>, the service will be restarted when the process exits with
+        a non-zero exit code, is terminated by a signal (including on core dump, but excluding the aforementioned
+        four signals), when an operation (such as service reload) times out, and when the configured watchdog
+        timeout is triggered. If set to <option>on-abnormal</option>, the service will be restarted when
+        the process is terminated by a signal (including on core dump, excluding the aforementioned four signals),
+        when an operation times out, or when the watchdog timeout is triggered. If set to <option>on-abort</option>,
+        the service will be restarted only if the service process exits due to an uncaught signal not specified
+        as a clean exit status. If set to <option>on-watchdog</option>, the service will be restarted
+        only if the watchdog timeout for the service expires. If set to <option>always</option>, the service
+        will be restarted regardless of whether it exited cleanly or not, got terminated abnormally by
+        a signal, or hit a timeout. Note that <varname>Type=oneshot</varname> services will never be restarted
+        on a clean exit status, i.e. <option>always</option> and <option>on-success</option> are rejected
+        for them.</para>
+
+        <table>
+          <title>Exit causes and the effect of the <varname>Restart=</varname> settings</title>
+
+          <tgroup cols='2'>
+            <colspec colname='path' />
+            <colspec colname='expl' />
+            <thead>
+              <row>
+                <entry>Restart settings/Exit causes</entry>
+                <entry><option>no</option></entry>
+                <entry><option>always</option></entry>
+                <entry><option>on-success</option></entry>
+                <entry><option>on-failure</option></entry>
+                <entry><option>on-abnormal</option></entry>
+                <entry><option>on-abort</option></entry>
+                <entry><option>on-watchdog</option></entry>
+              </row>
+            </thead>
+            <tbody>
+              <row>
+                <entry>Clean exit code or signal</entry>
+                <entry/>
+                <entry>X</entry>
+                <entry>X</entry>
+                <entry/>
+                <entry/>
+                <entry/>
+                <entry/>
+              </row>
+              <row>
+                <entry>Unclean exit code</entry>
+                <entry/>
+                <entry>X</entry>
+                <entry/>
+                <entry>X</entry>
+                <entry/>
+                <entry/>
+                <entry/>
+              </row>
+              <row>
+                <entry>Unclean signal</entry>
+                <entry/>
+                <entry>X</entry>
+                <entry/>
+                <entry>X</entry>
+                <entry>X</entry>
+                <entry>X</entry>
+                <entry/>
+              </row>
+              <row>
+                <entry>Timeout</entry>
+                <entry/>
+                <entry>X</entry>
+                <entry/>
+                <entry>X</entry>
+                <entry>X</entry>
+                <entry/>
+                <entry/>
+              </row>
+              <row>
+                <entry>Watchdog</entry>
+                <entry/>
+                <entry>X</entry>
+                <entry/>
+                <entry>X</entry>
+                <entry>X</entry>
+                <entry/>
+                <entry>X</entry>
+              </row>
+            </tbody>
+          </tgroup>
+        </table>
+
+        <para>As exceptions to the setting above, the service will not
+        be restarted if the exit code or signal is specified in
+        <varname>RestartPreventExitStatus=</varname> (see below) or
+        the service is stopped with <command>systemctl stop</command>
+        or an equivalent operation. Also, the services will always be
+        restarted if the exit code or signal is specified in
+        <varname>RestartForceExitStatus=</varname> (see below).</para>
+
+        <para>Note that service restart is subject to unit start rate
+        limiting configured with <varname>StartLimitIntervalSec=</varname>
+        and <varname>StartLimitBurst=</varname>, see
+        <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for details.</para>
+
+        <para>Setting this to <option>on-failure</option> is the
+        recommended choice for long-running services, in order to
+        increase reliability by attempting automatic recovery from
+        errors. For services that shall be able to terminate on their
+        own choice (and avoid immediate restarting),
+        <option>on-abnormal</option> is an alternative choice.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RestartMode=</varname></term>
+
+        <listitem>
+          <para>Takes a string value that specifies how a service should restart:
+            <itemizedlist>
+              <listitem><para>If set to <option>normal</option> (the default), the service restarts by
+              going through a failed/inactive state.</para></listitem>
+
+              <listitem><para>If set to <option>direct</option>, the service transitions to the activating
+              state directly during auto-restart, skipping failed/inactive state.
+              <varname>ExecStopPost=</varname> is invoked.
+              <varname>OnSuccess=</varname> and <varname>OnFailure=</varname> are skipped.</para></listitem>
+            </itemizedlist>
+          </para>
+
+          <para>This option is useful in cases where a dependency can fail temporarily
+          but we don't want these temporary failures to make the dependent units fail.
+          When this option is set to <option>direct</option>, dependent units are not notified of these temporary failures.</para>
+
+          <xi:include href="version-info.xml" xpointer="v254"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SuccessExitStatus=</varname></term>
+
+        <listitem><para>Takes a list of exit status definitions that, when returned by the main service
+        process, will be considered successful termination, in addition to the normal successful exit status
+        0 and, except for <varname>Type=oneshot</varname>, the signals <constant>SIGHUP</constant>, <constant>SIGINT</constant>,
+        <constant>SIGTERM</constant>, and <constant>SIGPIPE</constant>. Exit status definitions can be
+        numeric termination statuses, termination status names, or termination signal names, separated by
+        spaces. See the Process Exit Codes section in
+        <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
+        a list of termination status names (for this setting only the part without the
+        <literal>EXIT_</literal> or <literal>EX_</literal> prefix should be used). See <citerefentry
+        project='man-pages'><refentrytitle>signal</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
+        a list of signal names.</para>
+
+        <para>Note that this setting does not change the mapping between numeric exit statuses and their
+        names, i.e. regardless how this setting is used 0 will still be mapped to <literal>SUCCESS</literal>
+        (and thus typically shown as <literal>0/SUCCESS</literal> in tool outputs) and 1 to
+        <literal>FAILURE</literal> (and thus typically shown as <literal>1/FAILURE</literal>), and so on. It
+        only controls what happens as effect of these exit statuses, and how it propagates to the state of
+        the service as a whole.</para>
+
+        <para>This option may appear more than once, in which case the list of successful exit statuses is
+        merged. If the empty string is assigned to this option, the list is reset, all prior assignments of
+        this option will have no effect.</para>
+
+        <example>
+          <title>A service with the <varname>SuccessExitStatus=</varname> setting</title>
+
+          <programlisting>SuccessExitStatus=TEMPFAIL 250 SIGKILL</programlisting>
+
+          <para>Exit status 75 (<constant>TEMPFAIL</constant>), 250, and the termination signal
+          <constant>SIGKILL</constant> are considered clean service terminations.</para>
+        </example>
+
+        <para>Note: <command>systemd-analyze exit-status</command> may be used to list exit statuses and
+        translate between numerical status values and names.</para>
+
+        <xi:include href="version-info.xml" xpointer="v189"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RestartPreventExitStatus=</varname></term>
+
+        <listitem><para>Takes a list of exit status definitions that, when returned by the main service
+        process, will prevent automatic service restarts, regardless of the restart setting configured with
+        <varname>Restart=</varname>. Exit status definitions can either be numeric exit codes or termination
+        signal names, and are separated by spaces. Defaults to the empty list, so that, by default, no exit
+        status is excluded from the configured restart logic. For example:
+
+        <programlisting>RestartPreventExitStatus=1 6 SIGABRT</programlisting>
+
+        ensures that exit codes 1 and 6 and the termination signal <constant>SIGABRT</constant> will not
+        result in automatic service restarting. This option may appear more than once, in which case the list
+        of restart-preventing statuses is merged. If the empty string is assigned to this option, the list is
+        reset and all prior assignments of this option will have no effect.</para>
+
+        <para>Note that this setting has no effect on processes configured via
+        <varname>ExecStartPre=</varname>, <varname>ExecStartPost=</varname>, <varname>ExecStop=</varname>,
+        <varname>ExecStopPost=</varname> or <varname>ExecReload=</varname>, but only on the main service
+        process, i.e. either the one invoked by <varname>ExecStart=</varname> or (depending on
+        <varname>Type=</varname>, <varname>PIDFile=</varname>, …) the otherwise configured main
+        process.</para>
+
+        <xi:include href="version-info.xml" xpointer="v189"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RestartForceExitStatus=</varname></term>
+        <listitem><para>Takes a list of exit status definitions that,
+        when returned by the main service process, will force automatic
+        service restarts, regardless of the restart setting configured
+        with <varname>Restart=</varname>. The argument format is
+        similar to
+        <varname>RestartPreventExitStatus=</varname>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v215"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RootDirectoryStartOnly=</varname></term>
+        <listitem><para>Takes a boolean argument. If true, the root
+        directory, as configured with the
+        <varname>RootDirectory=</varname> option (see
+        <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for more information), is only applied to the process started
+        with <varname>ExecStart=</varname>, and not to the various
+        other <varname>ExecStartPre=</varname>,
+        <varname>ExecStartPost=</varname>,
+        <varname>ExecReload=</varname>, <varname>ExecStop=</varname>,
+        and <varname>ExecStopPost=</varname> commands. If false, the
+        setting is applied to all configured commands the same way.
+        Defaults to false.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>NonBlocking=</varname></term>
+        <listitem><para>Set the <constant>O_NONBLOCK</constant> flag for all file descriptors passed via
+        socket-based activation. If true, all file descriptors >= 3 (i.e. all except stdin, stdout, stderr),
+        excluding those passed in via the file descriptor storage logic (see
+        <varname>FileDescriptorStoreMax=</varname> for details), will have the
+        <constant>O_NONBLOCK</constant> flag set and hence are in non-blocking mode. This option is only
+        useful in conjunction with a socket unit, as described in
+        <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        and has no effect on file descriptors which were previously saved in the file-descriptor store for
+        example.  Defaults to false.</para>
+
+        <para>Note that if the same socket unit is configured to be passed to multiple service units (via the
+        <varname>Sockets=</varname> setting, see below), and these services have different
+        <varname>NonBlocking=</varname> configurations, the precise state of <constant>O_NONBLOCK</constant>
+        depends on the order in which these services are invoked, and will possibly change after service code
+        already took possession of the socket file descriptor, simply because the
+        <constant>O_NONBLOCK</constant> state of a socket is shared by all file descriptors referencing
+        it. Hence it is essential that all services sharing the same socket use the same
+        <varname>NonBlocking=</varname> configuration, and do not change the flag in service code
+        either.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>NotifyAccess=</varname></term>
+        <listitem><para>Controls access to the service status notification socket, as accessible via the
+        <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+        call. Takes one of <option>none</option> (the default), <option>main</option>, <option>exec</option>
+        or <option>all</option>. If <option>none</option>, no daemon status updates are accepted from the
+        service processes, all status update messages are ignored. If <option>main</option>, only service
+        updates sent from the main process of the service are accepted. If <option>exec</option>, only
+        service updates sent from any of the main or control processes originating from one of the
+        <varname>Exec*=</varname> commands are accepted. If <option>all</option>, all services updates from
+        all members of the service's control group are accepted. This option should be set to open access to
+        the notification socket when using
+        <varname>Type=notify</varname>/<varname>Type=notify-reload</varname> or
+        <varname>WatchdogSec=</varname> (see above). If those options are used but
+        <varname>NotifyAccess=</varname> is not configured, it will be implicitly set to
+        <option>main</option>.</para>
+
+        <para>Note that <function>sd_notify()</function> notifications may be attributed to units correctly only if
+        either the sending process is still around at the time PID 1 processes the message, or if the sending process
+        is explicitly runtime-tracked by the service manager. The latter is the case if the service manager originally
+        forked off the process, i.e. on all processes that match <option>main</option> or
+        <option>exec</option>. Conversely, if an auxiliary process of the unit sends an
+        <function>sd_notify()</function> message and immediately exits, the service manager might not be able to
+        properly attribute the message to the unit, and thus will ignore it, even if
+        <varname>NotifyAccess=</varname><option>all</option> is set for it.</para>
+
+        <para>Hence, to eliminate all race conditions involving lookup of the client's unit and attribution of notifications
+        to units correctly, <function>sd_notify_barrier()</function> may be used. This call acts as a synchronization point
+        and ensures all notifications sent before this call have been picked up by the service manager when it returns
+        successfully. Use of <function>sd_notify_barrier()</function> is needed for clients which are not invoked by the
+        service manager, otherwise this synchronization mechanism is unnecessary for attribution of notifications to the
+        unit.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Sockets=</varname></term>
+        <listitem><para>Specifies the name of the socket units this
+        service shall inherit socket file descriptors from when the
+        service is started. Normally, it should not be necessary to use
+        this setting, as all socket file descriptors whose unit shares
+        the same name as the service (subject to the different unit
+        name suffix of course) are passed to the spawned
+        process.</para>
+
+        <para>Note that the same socket file descriptors may be passed
+        to multiple processes simultaneously. Also note that a
+        different service may be activated on incoming socket traffic
+        than the one which is ultimately configured to inherit the
+        socket file descriptors. Or, in other words: the
+        <varname>Service=</varname> setting of
+        <filename>.socket</filename> units does not have to match the
+        inverse of the <varname>Sockets=</varname> setting of the
+        <filename>.service</filename> it refers to.</para>
+
+        <para>This option may appear more than once, in which case the list of socket units is merged. Note
+        that once set, clearing the list of sockets again (for example, by assigning the empty string to this
+        option) is not supported.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>FileDescriptorStoreMax=</varname></term>
+        <listitem><para>Configure how many file descriptors may be stored in the service manager for the
+        service using
+        <citerefentry><refentrytitle>sd_pid_notify_with_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry>'s
+        <literal>FDSTORE=1</literal> messages. This is useful for implementing services that can restart
+        after an explicit request or a crash without losing state. Any open sockets and other file
+        descriptors which should not be closed during the restart may be stored this way. Application state
+        can either be serialized to a file in <varname>RuntimeDirectory=</varname>, or stored in a
+        <citerefentry><refentrytitle>memfd_create</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+        memory file descriptor. Defaults to 0, i.e. no file descriptors may be stored in the service
+        manager. All file descriptors passed to the service manager from a specific service are passed back
+        to the service's main process on the next service restart (see
+        <citerefentry><refentrytitle>sd_listen_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry> for
+        details about the precise protocol used and the order in which the file descriptors are passed). Any
+        file descriptors passed to the service manager are automatically closed when
+        <constant>POLLHUP</constant> or <constant>POLLERR</constant> is seen on them, or when the service is
+        fully stopped and no job is queued or being executed for it (the latter can be tweaked with
+        <varname>FileDescriptorStorePreserve=</varname>, see below). If this option is used,
+        <varname>NotifyAccess=</varname> (see above) should be set to open access to the notification socket
+        provided by systemd. If <varname>NotifyAccess=</varname> is not set, it will be implicitly set to
+        <option>main</option>.</para>
+
+        <para>The <command>fdstore</command> command of
+        <citerefentry><refentrytitle>systemd-analyze</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+        may be used to list the current contents of a service's file descriptor store.</para>
+
+        <para>Note that the service manager will only pass file descriptors contained in the file descriptor
+        store to the service's own processes, never to other clients via IPC or similar. However, it does
+        allow unprivileged clients to query the list of currently open file descriptors of a
+        service. Sensitive data may hence be safely placed inside the referenced files, but should not be
+        attached to the metadata (e.g. included in filenames) of the stored file
+        descriptors.</para>
+
+        <para>If this option is set to a non-zero value the <varname>$FDSTORE</varname> environment variable
+        will be set for processes invoked for this service. See
+        <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
+        details.</para>
+
+        <para>For further information on the file descriptor store see the <ulink
+        url="https://systemd.io/FILE_DESCRIPTOR_STORE">File Descriptor Store</ulink> overview.</para>
+
+        <xi:include href="version-info.xml" xpointer="v219"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>FileDescriptorStorePreserve=</varname></term>
+        <listitem><para>Takes one of <constant>no</constant>, <constant>yes</constant>,
+        <constant>restart</constant> and controls when to release the service's file descriptor store
+        (i.e. when to close the contained file descriptors, if any). If set to <constant>no</constant> the
+        file descriptor store is automatically released when the service is stopped; if
+        <constant>restart</constant> (the default) it is kept around as long as the unit is neither inactive
+        nor failed, or a job is queued for the service, or the service is expected to be restarted. If
+        <constant>yes</constant> the file descriptor store is kept around until the unit is removed from
+        memory (i.e. is not referenced anymore and inactive). The latter is useful to keep entries in the
+        file descriptor store pinned until the service manager exits.</para>
+
+        <para>Use <command>systemctl clean --what=fdstore …</command> to release the file descriptor store
+        explicitly.</para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>USBFunctionDescriptors=</varname></term>
+        <listitem><para>Configure the location of a file containing
+        <ulink
+        url="https://docs.kernel.org/usb/functionfs.html">USB
+        FunctionFS</ulink> descriptors, for implementation of USB
+        gadget functions. This is used only in conjunction with a
+        socket unit with <varname>ListenUSBFunction=</varname>
+        configured. The contents of this file are written to the
+        <filename>ep0</filename> file after it is
+        opened.</para>
+
+        <xi:include href="version-info.xml" xpointer="v227"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>USBFunctionStrings=</varname></term>
+        <listitem><para>Configure the location of a file containing
+        USB FunctionFS strings.  Behavior is similar to
+        <varname>USBFunctionDescriptors=</varname>
+        above.</para>
+
+        <xi:include href="version-info.xml" xpointer="v227"/></listitem>
+      </varlistentry>
+
+      <varlistentry id='oom-policy'>
+        <term><varname>OOMPolicy=</varname></term>
+
+        <listitem><para>Configure the out-of-memory (OOM) killing policy for the kernel and the userspace OOM
+        killer
+        <citerefentry><refentrytitle>systemd-oomd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+        On Linux, when memory becomes scarce to the point that the kernel has trouble allocating memory for
+        itself, it might decide to kill a running process in order to free up memory and reduce memory
+        pressure. Note that <filename>systemd-oomd.service</filename> is a more flexible solution that aims
+        to prevent out-of-memory situations for the userspace too, not just the kernel, by attempting to
+        terminate services earlier, before the kernel would have to act.</para>
+
+        <para>This setting takes one of <constant>continue</constant>, <constant>stop</constant> or
+        <constant>kill</constant>. If set to <constant>continue</constant> and a process in the unit is
+        killed by the OOM killer, this is logged but the unit continues running. If set to
+        <constant>stop</constant> the event is logged but the unit is terminated cleanly by the service
+        manager. If set to <constant>kill</constant> and one of the unit's processes is killed by the OOM
+        killer the kernel is instructed to kill all remaining processes of the unit too, by setting the
+        <filename>memory.oom.group</filename> attribute to <constant>1</constant>; also see kernel
+        page <ulink url="https://docs.kernel.org/admin-guide/cgroup-v2.html">Control Group v2</ulink>.
+        </para>
+
+        <para>Defaults to the setting <varname>DefaultOOMPolicy=</varname> in
+        <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        is set to, except for units where <varname>Delegate=</varname> is turned on, where it defaults to
+        <constant>continue</constant>.</para>
+
+        <para>Use the <varname>OOMScoreAdjust=</varname> setting to configure whether processes of the unit
+        shall be considered preferred or less preferred candidates for process termination by the Linux OOM
+        killer logic. See
+        <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
+        details.</para>
+
+        <para>This setting also applies to
+        <citerefentry><refentrytitle>systemd-oomd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+        Similarly to the kernel OOM kills performed by the kernel, this setting determines the state of the
+        unit after <command>systemd-oomd</command> kills a cgroup associated with it.</para>
+
+        <xi:include href="version-info.xml" xpointer="v243"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>OpenFile=</varname></term>
+        <listitem><para>Takes an argument of the form <literal>path<optional><replaceable>:fd-name:options</replaceable></optional></literal>,
+        where:
+        <itemizedlist>
+            <listitem><simpara><literal>path</literal> is a path to a file or an <constant>AF_UNIX</constant> socket in the file system;</simpara></listitem>
+            <listitem><simpara><literal>fd-name</literal> is a name that will be associated with the file descriptor;
+            the name may contain any ASCII character, but must exclude control characters and ":", and must be at most 255 characters in length;
+            it is optional and, if not provided, defaults to the file name;</simpara></listitem>
+            <listitem><simpara><literal>options</literal> is a comma-separated list of access options;
+            possible values are
+            <literal>read-only</literal>,
+            <literal>append</literal>,
+            <literal>truncate</literal>,
+            <literal>graceful</literal>;
+            if not specified, files will be opened in <constant>rw</constant> mode;
+            if <literal>graceful</literal> is specified, errors during file/socket opening are ignored.
+            Specifying the same option several times is treated as an error.</simpara></listitem>
+        </itemizedlist>
+        The file or socket is opened by the service manager and the file descriptor is passed to the service.
+        If the path is a socket, we call <function>connect()</function> on it.
+        See <citerefentry><refentrytitle>sd_listen_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+        for more details on how to retrieve these file descriptors.</para>
+
+        <para>This setting is useful to allow services to access files/sockets that they can't access themselves
+        (due to running in a separate mount namespace, not having privileges, ...).</para>
+
+        <para>This setting can be specified multiple times, in which case all the specified paths are opened and the file descriptors passed to the service.
+        If the empty string is assigned, the entire list of open files defined prior to this is reset.</para>
+
+        <xi:include href="version-info.xml" xpointer="v253"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ReloadSignal=</varname></term>
+        <listitem><para>Configures the UNIX process signal to send to the service's main process when asked
+        to reload the service's configuration. Defaults to <constant>SIGHUP</constant>. This option has no
+        effect unless <varname>Type=</varname><option>notify-reload</option> is used, see
+        above.</para>
+
+        <xi:include href="version-info.xml" xpointer="v253"/></listitem>
+      </varlistentry>
+
+    </variablelist>
+
+    <para id='shared-unit-options'>Check
+    <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>, and
+    <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry> for more
+    settings.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Command lines</title>
+
+    <para>This section describes command line parsing and
+    variable and specifier substitutions for
+    <varname>ExecStart=</varname>,
+    <varname>ExecStartPre=</varname>,
+    <varname>ExecStartPost=</varname>,
+    <varname>ExecReload=</varname>,
+    <varname>ExecStop=</varname>, and
+    <varname>ExecStopPost=</varname> options.</para>
+
+    <para>Multiple command lines may be concatenated in a single directive by separating them with semicolons
+    (these semicolons must be passed as separate words). Lone semicolons may be escaped as
+    <literal>\;</literal>.</para>
+
+    <para>Each command line is unquoted using the rules described in "Quoting" section in
+    <citerefentry><refentrytitle>systemd.syntax</refentrytitle><manvolnum>7</manvolnum></citerefentry>. The
+    first item becomes the command to execute, and the subsequent items the arguments.</para>
+
+    <para>This syntax is inspired by shell syntax, but only the meta-characters and expansions
+    described in the following paragraphs are understood, and the expansion of variables is
+    different. Specifically, redirection using
+    <literal>&lt;</literal>,
+    <literal>&lt;&lt;</literal>,
+    <literal>&gt;</literal>, and
+    <literal>&gt;&gt;</literal>, pipes using
+    <literal>|</literal>, running programs in the background using
+    <literal>&amp;</literal>, and <emphasis>other elements of shell
+    syntax are not supported</emphasis>.</para>
+
+    <para>The command to execute may contain spaces, but control characters are not allowed.</para>
+
+    <para>Each command may be prefixed with a number of special characters:</para>
+
+    <table>
+      <title>Special executable prefixes</title>
+
+      <tgroup cols='2'>
+        <colspec colname='prefix'/>
+        <colspec colname='meaning'/>
+
+        <thead>
+          <row>
+            <entry>Prefix</entry>
+            <entry>Effect</entry>
+          </row>
+        </thead>
+        <tbody>
+          <row>
+            <entry><literal>@</literal></entry>
+            <entry>If the executable path is prefixed with <literal>@</literal>, the second specified token will be passed as <constant>argv[0]</constant> to the executed process (instead of the actual filename), followed by the further arguments specified.</entry>
+          </row>
+
+          <row>
+            <entry><literal>-</literal></entry>
+            <entry>If the executable path is prefixed with <literal>-</literal>, an exit code of the command normally considered a failure (i.e. non-zero exit status or abnormal exit due to signal) is recorded, but has no further effect and is considered equivalent to success.</entry>
+          </row>
+
+          <row>
+            <entry><literal>:</literal></entry>
+            <entry>If the executable path is prefixed with <literal>:</literal>, environment variable substitution (as described by the "Command Lines" section below) is not applied.</entry>
+          </row>
+
+          <row>
+            <entry><literal>+</literal></entry>
+            <entry>If the executable path is prefixed with <literal>+</literal> then the process is executed with full privileges. In this mode privilege restrictions configured with <varname>User=</varname>, <varname>Group=</varname>, <varname>CapabilityBoundingSet=</varname> or the various file system namespacing options (such as <varname>PrivateDevices=</varname>, <varname>PrivateTmp=</varname>) are not applied to the invoked command line (but still affect any other <varname>ExecStart=</varname>, <varname>ExecStop=</varname>, … lines). However, note that this will not bypass options that apply to the whole control group, such as <varname>DevicePolicy=</varname>, see <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry> for the full list.</entry>
+          </row>
+
+          <row>
+            <entry><literal>!</literal></entry>
+
+            <entry>Similar to the <literal>+</literal> character discussed above this permits invoking command lines with elevated privileges. However, unlike <literal>+</literal> the <literal>!</literal> character exclusively alters the effect of <varname>User=</varname>, <varname>Group=</varname> and <varname>SupplementaryGroups=</varname>, i.e. only the stanzas that affect user and group credentials. Note that this setting may be combined with <varname>DynamicUser=</varname>, in which case a dynamic user/group pair is allocated before the command is invoked, but credential changing is left to the executed process itself.</entry>
+          </row>
+
+          <row>
+            <entry><literal>!!</literal></entry>
+
+            <entry>This prefix is very similar to <literal>!</literal>, however it only has an effect on systems lacking support for ambient process capabilities, i.e. without support for <varname>AmbientCapabilities=</varname>. It's intended to be used for unit files that take benefit of ambient capabilities to run processes with minimal privileges wherever possible while remaining compatible with systems that lack ambient capabilities support. Note that when <literal>!!</literal> is used, and a system lacking ambient capability support is detected any configured <varname>SystemCallFilter=</varname> and <varname>CapabilityBoundingSet=</varname> stanzas are implicitly modified, in order to permit spawned processes to drop credentials and capabilities themselves, even if this is configured to not be allowed. Moreover, if this prefix is used and a system lacking ambient capability support is detected <varname>AmbientCapabilities=</varname> will be skipped and not be applied. On systems supporting ambient capabilities, <literal>!!</literal> has no effect and is redundant.</entry>
+          </row>
+        </tbody>
+      </tgroup>
+    </table>
+
+    <para><literal>@</literal>, <literal>-</literal>, <literal>:</literal>, and one of
+    <literal>+</literal>/<literal>!</literal>/<literal>!!</literal> may be used together and they can appear in any
+    order. However, only one of <literal>+</literal>, <literal>!</literal>, <literal>!!</literal> may be used at a
+    time.</para>
+
+    <para>For each command, the first argument must be either an absolute path to an executable or a simple
+    file name without any slashes. If the command is not a full (absolute) path, it will be resolved to a
+    full path using a fixed search path determined at compilation time. Searched directories include
+    <filename>/usr/local/bin/</filename>, <filename>/usr/bin/</filename>, <filename>/bin/</filename> on
+    systems using split <filename>/usr/bin/</filename> and <filename>/bin/</filename> directories, and their
+    <filename>sbin/</filename> counterparts on systems using split <filename>bin/</filename> and
+    <filename>sbin/</filename>. It is thus safe to use just the executable name in case of executables
+    located in any of the "standard" directories, and an absolute path must be used in other cases.
+    Hint: this search path may be queried using <command>systemd-path search-binaries-default</command>.
+    </para>
+
+    <para>The command line accepts <literal>%</literal> specifiers as described in
+    <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+
+    <para>Basic environment variable substitution is supported. Use
+    <literal>${FOO}</literal> as part of a word, or as a word of its
+    own, on the command line, in which case it will be erased and replaced
+    by the exact value of the environment variable (if any) including all
+    whitespace it contains, always resulting in exactly a single argument.
+    Use <literal>$FOO</literal> as a separate word on the command line, in
+    which case it will be replaced by the value of the environment
+    variable split at whitespace, resulting in zero or more arguments.
+    For this type of expansion, quotes are respected when splitting
+    into words, and afterwards removed.</para>
+
+    <para>Example:</para>
+
+    <programlisting>Environment="ONE=one" 'TWO=two two'
+ExecStart=echo $ONE $TWO ${TWO}</programlisting>
+
+    <para>This will execute <command>/bin/echo</command> with four
+    arguments: <literal>one</literal>, <literal>two</literal>,
+    <literal>two</literal>, and <literal>two two</literal>.</para>
+
+    <para>Example:</para>
+    <programlisting>Environment=ONE='one' "TWO='two two' too" THREE=
+ExecStart=/bin/echo ${ONE} ${TWO} ${THREE}
+ExecStart=/bin/echo $ONE $TWO $THREE</programlisting>
+    <para>This results in <filename>/bin/echo</filename> being
+    called twice, the first time with arguments
+    <literal>'one'</literal>,
+    <literal>'two two' too</literal>, <literal></literal>,
+    and the second time with arguments
+    <literal>one</literal>, <literal>two two</literal>,
+    <literal>too</literal>.
+    </para>
+
+    <para>To pass a literal dollar sign, use <literal>$$</literal>.
+    Variables whose value is not known at expansion time are treated
+    as empty strings. Note that the first argument (i.e. the program
+    to execute) may not be a variable.</para>
+
+    <para>Variables to be used in this fashion may be defined through
+    <varname>Environment=</varname> and
+    <varname>EnvironmentFile=</varname>. In addition, variables listed
+    in the section "Environment variables in spawned processes" in
+    <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    which are considered "static configuration", may be used (this
+    includes e.g. <varname>$USER</varname>, but not
+    <varname>$TERM</varname>).</para>
+
+    <para>Note that shell command lines are not directly supported. If
+    shell command lines are to be used, they need to be passed
+    explicitly to a shell implementation of some kind. Example:</para>
+    <programlisting>ExecStart=sh -c 'dmesg | tac'</programlisting>
+
+    <para>Example:</para>
+
+    <programlisting>ExecStart=echo one ; echo "two two"</programlisting>
+
+    <para>This will execute <command>echo</command> two times,
+    each time with one argument: <literal>one</literal> and
+    <literal>two two</literal>, respectively. Because two commands are
+    specified, <varname>Type=oneshot</varname> must be used.</para>
+
+    <para>Example:</para>
+
+    <programlisting>Type=oneshot
+ExecStart=:echo $USER ; -false ; +:@true $TEST</programlisting>
+
+    <para>This will execute <command>/usr/bin/echo</command> with the literal argument
+    <literal>$USER</literal> (<literal>:</literal> suppresses variable expansion), and then
+    <command>/usr/bin/false</command> (the return value will be ignored because <literal>-</literal>
+    suppresses checking of the return value), and <command>/usr/bin/true</command> (with elevated privileges,
+    with <literal>$TEST</literal> as <constant>argv[0]</constant>).</para>
+
+    <para>Example:</para>
+
+    <programlisting>ExecStart=echo / &gt;/dev/null &amp; \; \
+ls</programlisting>
+
+    <para>This will execute <command>echo</command>
+    with five arguments: <literal>/</literal>,
+    <literal>&gt;/dev/null</literal>,
+    <literal>&amp;</literal>, <literal>;</literal>, and
+    <literal>ls</literal>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Examples</title>
+
+    <example>
+      <title>Simple service</title>
+
+      <para>The following unit file creates a service that will
+      execute <filename index="false">/usr/sbin/foo-daemon</filename>. Since no
+      <varname>Type=</varname> is specified, the default
+      <varname>Type=</varname><option>simple</option> will be assumed.
+      systemd will assume the unit to be started immediately after the
+      program has begun executing.</para>
+
+      <programlisting>[Unit]
+Description=Foo
+
+[Service]
+ExecStart=/usr/sbin/foo-daemon
+
+[Install]
+WantedBy=multi-user.target</programlisting>
+
+      <para>Note that systemd assumes here that the process started by
+      systemd will continue running until the service terminates. If
+      the program daemonizes itself (i.e. forks), please use
+      <varname>Type=</varname><option>forking</option> instead.</para>
+
+      <para>Since no <varname>ExecStop=</varname> was specified,
+      systemd will send SIGTERM to all processes started from this
+      service, and after a timeout also SIGKILL. This behavior can be
+      modified, see
+      <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+      for details.</para>
+
+      <para>Note that this unit type does not include any type of notification when a service has completed
+      initialization. For this, you should use other unit types, such as
+      <varname>Type=</varname><option>notify</option>/<varname>Type=</varname><option>notify-reload</option>
+      if the service understands systemd's notification protocol,
+      <varname>Type=</varname><option>forking</option> if the service can background itself or
+      <varname>Type=</varname><option>dbus</option> if the unit acquires a DBus name once initialization is
+      complete. See below.</para>
+    </example>
+
+    <example>
+      <title>Oneshot service</title>
+
+      <para>Sometimes, units should just execute an action without
+      keeping active processes, such as a filesystem check or a
+      cleanup action on boot. For this,
+      <varname>Type=</varname><option>oneshot</option> exists. Units
+      of this type will wait until the process specified terminates
+      and then fall back to being inactive. The following unit will
+      perform a cleanup action:</para>
+
+      <programlisting>[Unit]
+Description=Cleanup old Foo data
+
+[Service]
+Type=oneshot
+ExecStart=/usr/sbin/foo-cleanup
+
+[Install]
+WantedBy=multi-user.target</programlisting>
+
+      <para>Note that systemd will consider the unit to be in the
+      state "starting" until the program has terminated, so ordered
+      dependencies will wait for the program to finish before starting
+      themselves. The unit will revert to the "inactive" state after
+      the execution is done, never reaching the "active" state. That
+      means another request to start the unit will perform the action
+      again.</para>
+
+      <para><varname>Type=</varname><option>oneshot</option> are the
+      only service units that may have more than one
+      <varname>ExecStart=</varname> specified. For units with multiple
+      commands (<varname index="false">Type=oneshot</varname>), all commands will be run again.</para>
+      <para> For <varname index="false">Type=oneshot</varname>, <varname>Restart=</varname><option>always</option>
+      and <varname>Restart=</varname><option>on-success</option> are <emphasis>not</emphasis> allowed.</para>
+    </example>
+
+    <example>
+      <title>Stoppable oneshot service</title>
+
+      <para>Similarly to the oneshot services, there are sometimes
+      units that need to execute a program to set up something and
+      then execute another to shut it down, but no process remains
+      active while they are considered "started". Network
+      configuration can sometimes fall into this category. Another use
+      case is if a oneshot service shall not be executed each time
+      when they are pulled in as a dependency, but only the first
+      time.</para>
+
+      <para>For this, systemd knows the setting
+      <varname>RemainAfterExit=</varname><option>yes</option>, which
+      causes systemd to consider the unit to be active if the start
+      action exited successfully. This directive can be used with all
+      types, but is most useful with
+      <varname>Type=</varname><option>oneshot</option> and
+      <varname>Type=</varname><option>simple</option>. With
+      <varname>Type=</varname><option>oneshot</option>, systemd waits
+      until the start action has completed before it considers the
+      unit to be active, so dependencies start only after the start
+      action has succeeded. With
+      <varname>Type=</varname><option>simple</option>, dependencies
+      will start immediately after the start action has been
+      dispatched. The following unit provides an example for a simple
+      static firewall.</para>
+
+      <programlisting>[Unit]
+Description=Simple firewall
+
+[Service]
+Type=oneshot
+RemainAfterExit=yes
+ExecStart=/usr/local/sbin/simple-firewall-start
+ExecStop=/usr/local/sbin/simple-firewall-stop
+
+[Install]
+WantedBy=multi-user.target</programlisting>
+
+      <para>Since the unit is considered to be running after the start
+      action has exited, invoking <command>systemctl start</command>
+      on that unit again will cause no action to be taken.</para>
+    </example>
+
+    <example>
+      <title>Traditional forking services</title>
+
+      <para>Many traditional daemons/services background (i.e. fork,
+      daemonize) themselves when starting. Set
+      <varname>Type=</varname><option>forking</option> in the
+      service's unit file to support this mode of operation. systemd
+      will consider the service to be in the process of initialization
+      while the original program is still running. Once it exits
+      successfully and at least a process remains (and
+      <varname>RemainAfterExit=</varname><option>no</option>), the
+      service is considered started.</para>
+
+      <para>Often, a traditional daemon only consists of one process.
+      Therefore, if only one process is left after the original
+      process terminates, systemd will consider that process the main
+      process of the service. In that case, the
+      <varname>$MAINPID</varname> variable will be available in
+      <varname>ExecReload=</varname>, <varname>ExecStop=</varname>,
+      etc.</para>
+
+      <para>In case more than one process remains, systemd will be
+      unable to determine the main process, so it will not assume
+      there is one. In that case, <varname>$MAINPID</varname> will not
+      expand to anything. However, if the process decides to write a
+      traditional PID file, systemd will be able to read the main PID
+      from there. Please set <varname>PIDFile=</varname> accordingly.
+      Note that the daemon should write that file before finishing
+      with its initialization. Otherwise, systemd might try to read the
+      file before it exists.</para>
+
+      <para>The following example shows a simple daemon that forks and
+      just starts one process in the background:</para>
+
+      <programlisting>[Unit]
+Description=Some simple daemon
+
+[Service]
+Type=forking
+ExecStart=/usr/sbin/my-simple-daemon -d
+
+[Install]
+WantedBy=multi-user.target</programlisting>
+
+      <para>Please see
+      <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+      for details on how you can influence the way systemd terminates
+      the service.</para>
+    </example>
+
+    <example>
+      <title>DBus services</title>
+
+      <para>For services that acquire a name on the DBus system bus,
+      use <varname>Type=</varname><option>dbus</option> and set
+      <varname>BusName=</varname> accordingly. The service should not
+      fork (daemonize). systemd will consider the service to be
+      initialized once the name has been acquired on the system bus.
+      The following example shows a typical DBus service:</para>
+
+      <programlisting>[Unit]
+Description=Simple DBus service
+
+[Service]
+Type=dbus
+BusName=org.example.simple-dbus-service
+ExecStart=/usr/sbin/simple-dbus-service
+
+[Install]
+WantedBy=multi-user.target</programlisting>
+
+      <para>For <emphasis>bus-activatable</emphasis> services, do not
+      include a [Install] section in the systemd
+      service file, but use the <varname>SystemdService=</varname>
+      option in the corresponding DBus service file, for example
+      (<filename>/usr/share/dbus-1/system-services/org.example.simple-dbus-service.service</filename>):</para>
+
+      <programlisting>[D-BUS Service]
+Name=org.example.simple-dbus-service
+Exec=/usr/sbin/simple-dbus-service
+User=root
+SystemdService=simple-dbus-service.service</programlisting>
+
+      <para>Please see
+      <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+      for details on how you can influence the way systemd terminates
+      the service.</para>
+    </example>
+
+    <example>
+      <title>Services that notify systemd about their initialization</title>
+
+      <para><varname>Type=</varname><option>simple</option> services are really easy to write, but have the
+      major disadvantage of systemd not being able to tell when initialization of the given service is
+      complete. For this reason, systemd supports a simple notification protocol that allows daemons to make
+      systemd aware that they are done initializing. Use <varname>Type=</varname><option>notify</option> or
+      <varname>Type=</varname><option>notify-reload</option> for this. A typical service file for such a
+      daemon would look like this:</para>
+
+      <programlisting>[Unit]
+Description=Simple notifying service
+
+[Service]
+Type=notify
+ExecStart=/usr/sbin/simple-notifying-service
+
+[Install]
+WantedBy=multi-user.target</programlisting>
+
+      <para>Note that the daemon has to support systemd's notification
+      protocol, else systemd will think the service has not started yet
+      and kill it after a timeout. For an example of how to update
+      daemons to support this protocol transparently, take a look at
+      <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+      systemd will consider the unit to be in the 'starting' state
+      until a readiness notification has arrived.</para>
+
+      <para>Please see
+      <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+      for details on how you can influence the way systemd terminates
+      the service.</para>
+    </example>
+  </refsect1>
+
+  <refsect1>
+      <title>See Also</title>
+      <para>
+        <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd-run</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+      </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd.slice.xml b/man/systemd.slice.xml
new file mode 100644
index 0000000..5e61199
--- /dev/null
+++ b/man/systemd.slice.xml
@@ -0,0 +1,122 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd.slice">
+  <refentryinfo>
+    <title>systemd.slice</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd.slice</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd.slice</refname>
+    <refpurpose>Slice unit configuration</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename><replaceable>slice</replaceable>.slice</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>A unit configuration file whose name ends in <literal>.slice</literal> encodes information about a slice
+    unit. A slice unit is a concept for hierarchically managing resources of a group of processes. This management is
+    performed by creating a node in the Linux Control Group (cgroup) tree. Units that manage processes (primarily scope
+    and service units) may be assigned to a specific slice. For each slice, certain resource limits may be set that
+    apply to all processes of all units contained in that slice. Slices are organized hierarchically in a tree. The
+    name of the slice encodes the location in the tree. The name consists of a dash-separated series of names, which
+    describes the path to the slice from the root slice. The root slice is named <filename>-.slice</filename>. Example:
+    <filename>foo-bar.slice</filename> is a slice that is located within <filename>foo.slice</filename>, which in turn
+    is located in the root slice <filename>-.slice</filename>.
+    </para>
+
+    <para>Note that slice units cannot be templated, nor is possible to add multiple names to a slice unit by creating
+    additional symlinks to its unit file.</para>
+
+    <para>By default, service and scope units are placed in
+    <filename>system.slice</filename>, virtual machines and containers
+    registered with
+    <citerefentry><refentrytitle>systemd-machined</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    are found in <filename>machine.slice</filename>, and user sessions
+    handled by
+    <citerefentry><refentrytitle>systemd-logind</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    in <filename>user.slice</filename>. See
+    <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+    for more information.</para>
+
+    <para>See
+    <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for the common options of all unit configuration
+    files. The common configuration items are configured
+    in the generic [Unit] and [Install] sections. The
+    slice specific configuration options are configured in
+    the [Slice] section. Currently, only generic resource control settings
+    as described in
+    <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry> are allowed.
+    </para>
+
+    <para>See the <ulink
+    url="https://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface">New
+    Control Group Interfaces</ulink> for an introduction on how to make
+    use of slice units from programs.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Automatic Dependencies</title>
+
+    <refsect2>
+      <title>Implicit Dependencies</title>
+
+      <para>The following dependencies are implicitly added:</para>
+
+      <itemizedlist>
+        <listitem><para>Slice units automatically gain dependencies of type
+        <varname>After=</varname> and <varname>Requires=</varname> on
+        their immediate parent slice unit.</para></listitem>
+      </itemizedlist>
+    </refsect2>
+
+    <refsect2>
+      <title>Default Dependencies</title>
+
+      <para>The following dependencies are added unless <varname>DefaultDependencies=no</varname> is set:</para>
+
+      <itemizedlist>
+        <listitem><para>Slice units will automatically have dependencies of type <varname>Conflicts=</varname> and
+        <varname>Before=</varname> on
+        <filename>shutdown.target</filename>. These ensure that slice units are removed prior to system shutdown.
+        Only slice units involved with late system shutdown should disable
+        <varname>DefaultDependencies=</varname> option.</para></listitem>
+      </itemizedlist>
+    </refsect2>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>Slice unit files may include [Unit] and [Install] sections, which are described in
+    <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+    No options specific to this file type are supported.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.scope</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd.socket.xml b/man/systemd.socket.xml
new file mode 100644
index 0000000..647b7db
--- /dev/null
+++ b/man/systemd.socket.xml
@@ -0,0 +1,951 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd.socket" xmlns:xi="http://www.w3.org/2001/XInclude">
+  <refentryinfo>
+    <title>systemd.socket</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd.socket</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd.socket</refname>
+    <refpurpose>Socket unit configuration</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename><replaceable>socket</replaceable>.socket</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>A unit configuration file whose name ends in
+    <literal>.socket</literal> encodes information about an IPC or
+    network socket or a file system FIFO controlled and supervised by
+    systemd, for socket-based activation.</para>
+
+    <para>This man page lists the configuration options specific to
+    this unit type. See
+    <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for the common options of all unit configuration files. The common
+    configuration items are configured in the generic [Unit] and
+    [Install] sections. The socket specific configuration options are
+    configured in the [Socket] section.</para>
+
+    <para>Additional options are listed in
+    <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    which define the execution environment the
+    <option>ExecStartPre=</option>, <option>ExecStartPost=</option>,
+    <option>ExecStopPre=</option> and <option>ExecStopPost=</option>
+    commands are executed in, and in
+    <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    which define the way the processes are terminated, and in
+    <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    which configure resource control settings for the processes of the
+    socket.</para>
+
+    <para>For each socket unit, a matching service unit must exist,
+    describing the service to start on incoming traffic on the socket
+    (see
+    <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for more information about .service units). The name of the
+    .service unit is by default the same as the name of the .socket
+    unit, but can be altered with the <option>Service=</option> option
+    described below. Depending on the setting of the
+    <option>Accept=</option> option described below, this .service
+    unit must either be named like the .socket unit, but with the
+    suffix replaced, unless overridden with <option>Service=</option>;
+    or it must be a template unit named the same way. Example: a
+    socket file <filename>foo.socket</filename> needs a matching
+    service <filename>foo.service</filename> if
+    <option>Accept=no</option> is set. If
+    <option>Accept=yes</option> is set, a service template
+    <filename>foo@.service</filename> must exist from which services
+    are instantiated for each incoming connection.</para>
+
+    <para>No implicit <varname>WantedBy=</varname> or
+    <varname>RequiredBy=</varname> dependency from the socket to the
+    service is added. This means that the service may be started
+    without the socket, in which case it must be able to open sockets
+    by itself. To prevent this, an explicit
+    <varname>Requires=</varname> dependency may be added.</para>
+
+    <para>Socket units may be used to implement on-demand starting of
+    services, as well as parallelized starting of services. See the
+    blog stories linked at the end for an introduction.</para>
+
+    <para>Note that the daemon software configured for socket activation with socket units needs to be able
+    to accept sockets from systemd, either via systemd's native socket passing interface (see
+    <citerefentry><refentrytitle>sd_listen_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry> for
+    details about the precise protocol used and the order in which the file descriptors are passed) or via
+    traditional <citerefentry
+    project='freebsd'><refentrytitle>inetd</refentrytitle><manvolnum>8</manvolnum></citerefentry>-style
+    socket passing (i.e. sockets passed in via standard input and output, using
+    <varname>StandardInput=socket</varname> in the service file).</para>
+
+    <para>All network sockets allocated through <filename>.socket</filename> units are allocated in the host's network
+    namespace (see <citerefentry
+    project='man-pages'><refentrytitle>network_namespaces</refentrytitle><manvolnum>7</manvolnum></citerefentry>). This
+    does not mean however that the service activated by a configured socket unit has to be part of the host's network
+    namespace as well.  It is supported and even good practice to run services in their own network namespace (for
+    example through <varname>PrivateNetwork=</varname>, see
+    <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>), receiving only
+    the sockets configured through socket-activation from the host's namespace. In such a set-up communication within
+    the host's network namespace is only permitted through the activation sockets passed in while all sockets allocated
+    from the service code itself will be associated with the service's own namespace, and thus possibly subject to a
+    restrictive configuration.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Automatic Dependencies</title>
+
+    <refsect2>
+      <title>Implicit Dependencies</title>
+
+      <para>The following dependencies are implicitly added:</para>
+
+      <itemizedlist>
+        <listitem><para>Socket units automatically gain a <varname>Before=</varname>
+        dependency on the service units they activate.</para></listitem>
+
+        <listitem><para>Socket units referring to file system paths (such as <constant>AF_UNIX</constant>
+        sockets or FIFOs) implicitly gain <varname>Requires=</varname> and <varname>After=</varname>
+        dependencies on all mount units necessary to access those paths.</para></listitem>
+
+        <listitem><para>Socket units using the <varname>BindToDevice=</varname>
+        setting automatically gain a <varname>BindsTo=</varname> and
+        <varname>After=</varname> dependency on the device unit
+        encapsulating the specified network interface.</para></listitem>
+      </itemizedlist>
+
+      <para>Additional implicit dependencies may be added as result of
+      execution and resource control parameters as documented in
+      <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+      and
+      <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+    </refsect2>
+
+    <refsect2>
+      <title>Default Dependencies</title>
+
+      <para>The following dependencies are added unless
+      <varname>DefaultDependencies=no</varname> is set:</para>
+
+      <itemizedlist>
+        <listitem><para>Socket units automatically gain a
+        <varname>Before=</varname> dependency on
+        <filename>sockets.target</filename>.</para></listitem>
+
+        <listitem><para>Socket units automatically gain a pair of
+        <varname>After=</varname> and <varname>Requires=</varname>
+        dependency on <filename>sysinit.target</filename>, and a pair of
+        <varname>Before=</varname> and <varname>Conflicts=</varname>
+        dependencies on <filename>shutdown.target</filename>. These
+        dependencies ensure that the socket unit is started before normal
+        services at boot, and is stopped on shutdown. Only sockets
+        involved with early boot or late system shutdown should disable
+        <varname>DefaultDependencies=</varname> option.</para></listitem>
+      </itemizedlist>
+    </refsect2>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>Socket unit files may include [Unit] and [Install] sections, which are described in
+    <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+    </para>
+
+    <para>Socket unit files must include a [Socket] section, which carries
+    information about the socket or FIFO it supervises. A number of
+    options that may be used in this section are shared with other
+    unit types. These options are documented in
+    <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    and
+    <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+    The options specific to the [Socket] section of socket units are
+    the following:</para>
+
+    <variablelist class='unit-directives'>
+      <varlistentry>
+        <term><varname>ListenStream=</varname></term>
+        <term><varname>ListenDatagram=</varname></term>
+        <term><varname>ListenSequentialPacket=</varname></term>
+        <listitem><para>Specifies an address to listen on for a stream
+        (<constant>SOCK_STREAM</constant>), datagram
+        (<constant>SOCK_DGRAM</constant>), or sequential packet
+        (<constant>SOCK_SEQPACKET</constant>) socket, respectively.
+        The address can be written in various formats:</para>
+
+        <para>If the address starts with a slash
+        (<literal>/</literal>), it is read as file system socket in
+        the <constant>AF_UNIX</constant> socket family.</para>
+
+        <para>If the address starts with an at symbol
+        (<literal>@</literal>), it is read as abstract namespace
+        socket in the <constant>AF_UNIX</constant> family. The
+        <literal>@</literal> is replaced with a
+        <constant>NUL</constant> character before binding. For
+        details, see
+        <citerefentry project='man-pages'><refentrytitle>unix</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
+
+        <para>If the address string is a single number, it is read as
+        port number to listen on via IPv6. Depending on the value of
+        <varname>BindIPv6Only=</varname> (see below) this might result
+        in the service being available via both IPv6 and IPv4
+        (default) or just via IPv6.
+        </para>
+
+        <para>If the address string is a string in the format
+        <literal><replaceable>v.w.x.y</replaceable>:<replaceable>z</replaceable></literal>, it is interpreted
+        as IPv4 address <replaceable>v.w.x.y</replaceable> and port <replaceable>z</replaceable>.</para>
+
+        <para>If the address string is a string in the format
+        <literal>[<replaceable>x</replaceable>]:<replaceable>y</replaceable></literal>, it is interpreted as
+        IPv6 address <replaceable>x</replaceable> and port <replaceable>y</replaceable>. An optional
+        interface scope (interface name or number) may be specified after a <literal>%</literal> symbol:
+        <literal>[<replaceable>x</replaceable>]:<replaceable>y</replaceable>%<replaceable>dev</replaceable></literal>.
+        Interface scopes are only useful with link-local addresses, because the kernel ignores them in other
+        cases. Note that if an address is specified as IPv6, it might still make the service available via
+        IPv4 too, depending on the <varname>BindIPv6Only=</varname> setting (see below).</para>
+
+        <para>If the address string is a string in the format
+        <literal>vsock:<replaceable>x</replaceable>:<replaceable>y</replaceable></literal>, it is read as CID
+        <replaceable>x</replaceable> on a port <replaceable>y</replaceable> address in the
+        <constant>AF_VSOCK</constant> family.  The CID is a unique 32-bit integer identifier in
+        <constant>AF_VSOCK</constant> analogous to an IP address.  Specifying the CID is optional, and may be
+        set to the empty string.</para>
+
+        <para>Note that <constant>SOCK_SEQPACKET</constant> (i.e.
+        <varname>ListenSequentialPacket=</varname>) is only available
+        for <constant>AF_UNIX</constant> sockets.
+        <constant>SOCK_STREAM</constant> (i.e.
+        <varname>ListenStream=</varname>) when used for IP sockets
+        refers to TCP sockets, <constant>SOCK_DGRAM</constant> (i.e.
+        <varname>ListenDatagram=</varname>) to UDP.</para>
+
+        <para>These options may be specified more than once, in which
+        case incoming traffic on any of the sockets will trigger
+        service activation, and all listed sockets will be passed to
+        the service, regardless of whether there is incoming traffic
+        on them or not. If the empty string is assigned to any of
+        these options, the list of addresses to listen on is reset,
+        all prior uses of any of these options will have no
+        effect.</para>
+
+        <para>It is also possible to have more than one socket unit
+        for the same service when using <varname>Service=</varname>,
+        and the service will receive all the sockets configured in all
+        the socket units. Sockets configured in one unit are passed in
+        the order of configuration, but no ordering between socket
+        units is specified.</para>
+
+        <para>If an IP address is used here, it is often desirable to
+        listen on it before the interface it is configured on is up
+        and running, and even regardless of whether it will be up and
+        running at any point. To deal with this, it is recommended to
+        set the <varname>FreeBind=</varname> option described
+        below.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ListenFIFO=</varname></term>
+        <listitem><para>Specifies a file system FIFO (see <citerefentry
+        project='man-pages'><refentrytitle>fifo</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
+        details) to listen on.  This expects an absolute file system path as argument.  Behavior otherwise is
+        very similar to the <varname>ListenDatagram=</varname> directive above.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ListenSpecial=</varname></term>
+        <listitem><para>Specifies a special file in the file system to
+        listen on. This expects an absolute file system path as
+        argument. Behavior otherwise is very similar to the
+        <varname>ListenFIFO=</varname> directive above. Use this to
+        open character device nodes as well as special files in
+        <filename>/proc/</filename> and
+        <filename>/sys/</filename>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ListenNetlink=</varname></term>
+        <listitem><para>Specifies a Netlink family to create a socket
+        for to listen on. This expects a short string referring to the
+        <constant>AF_NETLINK</constant> family name (such as
+        <varname>audit</varname> or <varname>kobject-uevent</varname>)
+        as argument, optionally suffixed by a whitespace followed by a
+        multicast group integer. Behavior otherwise is very similar to
+        the <varname>ListenDatagram=</varname> directive
+        above.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ListenMessageQueue=</varname></term>
+        <listitem><para>Specifies a POSIX message queue name to listen on (see <citerefentry
+        project='man-pages'><refentrytitle>mq_overview</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+        for details). This expects a valid message queue name (i.e. beginning with
+        <literal>/</literal>). Behavior otherwise is very similar to the <varname>ListenFIFO=</varname>
+        directive above. On Linux message queue descriptors are actually file descriptors and can be
+        inherited between processes.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ListenUSBFunction=</varname></term>
+        <listitem><para>Specifies a <ulink
+        url="https://docs.kernel.org/usb/functionfs.html">USB
+        FunctionFS</ulink> endpoints location to listen on, for
+        implementation of USB gadget functions. This expects an
+        absolute file system path of a FunctionFS mount point as the argument.
+        Behavior otherwise is very similar to the <varname>ListenFIFO=</varname>
+        directive above. Use this to open the FunctionFS endpoint
+        <filename>ep0</filename>. When using this option, the
+        activated service has to have the
+        <varname>USBFunctionDescriptors=</varname> and
+        <varname>USBFunctionStrings=</varname> options set.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v227"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SocketProtocol=</varname></term>
+        <listitem><para>Takes one of <option>udplite</option>
+        or <option>sctp</option>. The socket will use the UDP-Lite
+        (<constant>IPPROTO_UDPLITE</constant>) or SCTP
+        (<constant>IPPROTO_SCTP</constant>) protocol, respectively.</para>
+
+        <xi:include href="version-info.xml" xpointer="v229"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>BindIPv6Only=</varname></term>
+        <listitem><para>Takes one of <option>default</option>,
+        <option>both</option> or <option>ipv6-only</option>. Controls
+        the IPV6_V6ONLY socket option (see
+        <citerefentry project='die-net'><refentrytitle>ipv6</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+        for details). If <option>both</option>, IPv6 sockets bound
+        will be accessible via both IPv4 and IPv6. If
+        <option>ipv6-only</option>, they will be accessible via IPv6
+        only. If <option>default</option> (which is the default,
+        surprise!), the system wide default setting is used, as
+        controlled by
+        <filename>/proc/sys/net/ipv6/bindv6only</filename>, which in
+        turn defaults to the equivalent of
+        <option>both</option>.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Backlog=</varname></term>
+        <listitem><para>Takes an unsigned 32-bit integer argument. Specifies the number of connections to
+        queue that have not been accepted yet. This setting matters only for stream and sequential packet
+        sockets. See
+        <citerefentry><refentrytitle>listen</refentrytitle><manvolnum>2</manvolnum></citerefentry> for
+        details. Defaults to 4294967295. Note that this value is silently capped by the
+        <literal>net.core.somaxconn</literal> sysctl, which typically defaults to 4096, so typically
+        the sysctl is the setting that actually matters.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>BindToDevice=</varname></term>
+        <listitem><para>Specifies a network interface name to bind this socket to. If set, traffic will only
+        be accepted from the specified network interfaces. This controls the
+        <constant>SO_BINDTODEVICE</constant> socket option (see <citerefentry
+        project='man-pages'><refentrytitle>socket</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
+        details). If this option is used, an implicit dependency from this socket unit on the network
+        interface device unit is created
+        (see <citerefentry><refentrytitle>systemd.device</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
+        Note that setting this parameter might result in additional dependencies to be added to the unit (see
+        above).</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SocketUser=</varname></term>
+        <term><varname>SocketGroup=</varname></term>
+
+        <listitem><para>Takes a UNIX user/group name. When specified, all <constant>AF_UNIX</constant>
+        sockets and FIFO nodes in the file system are owned by the specified user and group. If unset (the
+        default), the nodes are owned by the root user/group (if run in system context) or the invoking
+        user/group (if run in user context).  If only a user is specified but no group, then the group is
+        derived from the user's default group.</para>
+
+        <xi:include href="version-info.xml" xpointer="v214"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SocketMode=</varname></term>
+        <listitem><para>If listening on a file system socket or FIFO,
+        this option specifies the file system access mode used when
+        creating the file node. Takes an access mode in octal
+        notation. Defaults to 0666.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>DirectoryMode=</varname></term>
+        <listitem><para>If listening on a file system socket or FIFO,
+        the parent directories are automatically created if needed.
+        This option specifies the file system access mode used when
+        creating these directories. Takes an access mode in octal
+        notation. Defaults to 0755.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Accept=</varname></term>
+        <listitem><para>Takes a boolean argument. If yes, a service instance is spawned for each incoming
+        connection and only the connection socket is passed to it. If no, all listening sockets themselves
+        are passed to the started service unit, and only one service unit is spawned for all connections
+        (also see above). This value is ignored for datagram sockets and FIFOs where a single service unit
+        unconditionally handles all incoming traffic. Defaults to <option>no</option>. For performance
+        reasons, it is recommended to write new daemons only in a way that is suitable for
+        <option>Accept=no</option>. A daemon listening on an <constant>AF_UNIX</constant> socket may, but
+        does not need to, call
+        <citerefentry><refentrytitle>close</refentrytitle><manvolnum>2</manvolnum></citerefentry> on the
+        received socket before exiting. However, it must not unlink the socket from a file system. It should
+        not invoke
+        <citerefentry><refentrytitle>shutdown</refentrytitle><manvolnum>2</manvolnum></citerefentry> on
+        sockets it got with <varname>Accept=no</varname>, but it may do so for sockets it got with
+        <varname>Accept=yes</varname> set. Setting <varname>Accept=yes</varname> is mostly useful to allow
+        daemons designed for usage with <citerefentry
+        project='freebsd'><refentrytitle>inetd</refentrytitle><manvolnum>8</manvolnum></citerefentry> to work
+        unmodified with systemd socket activation.</para>
+
+        <para>Note that depending on this setting the services activated by units of this type are either
+        regular services (in case of <varname>Accept=</varname><option>no</option>) or instances of templated
+        services (in case of <varname>Accept=</varname><option>yes</option>). See the Description section
+        above for a more detailed discussion of the naming rules of triggered services.</para>
+
+        <para>For IPv4 and IPv6 connections, the <varname>REMOTE_ADDR</varname> environment variable will
+        contain the remote IP address, and <varname>REMOTE_PORT</varname> will contain the remote port. This
+        is the same as the format used by CGI. For <constant>SOCK_RAW</constant>, the port is the IP
+        protocol.</para>
+
+        <para>It is recommended to set <varname>CollectMode=inactive-or-failed</varname> for service
+        instances activated via <varname>Accept=yes</varname>, to ensure that failed connection services are
+        cleaned up and released from memory, and do not accumulate.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Writable=</varname></term>
+        <listitem><para>Takes a boolean argument. May only be used in
+        conjunction with <varname>ListenSpecial=</varname>. If true,
+        the specified special file is opened in read-write mode, if
+        false, in read-only mode. Defaults to false.</para>
+
+        <xi:include href="version-info.xml" xpointer="v227"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>FlushPending=</varname></term>
+        <listitem><para>Takes a boolean argument. May only be used when
+        <option>Accept=no</option>. If yes, the socket's buffers are cleared after the
+        triggered service exited. This causes any pending data to be
+        flushed and any pending incoming connections to be rejected. If no, the
+        socket's buffers won't be cleared, permitting the service to handle any
+        pending connections after restart, which is the usually expected behaviour.
+        Defaults to <option>no</option>.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v247"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>MaxConnections=</varname></term>
+        <listitem><para>The maximum number of connections to
+        simultaneously run services instances for, when
+        <option>Accept=yes</option> is set. If more concurrent
+        connections are coming in, they will be refused until at least
+        one existing connection is terminated. This setting has no
+        effect on sockets configured with
+        <option>Accept=no</option> or datagram sockets. Defaults to
+        64.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>MaxConnectionsPerSource=</varname></term>
+        <listitem><para>The maximum number of connections for a service per source IP address.
+        This is very similar to the <varname>MaxConnections=</varname> directive
+        above. Disabled by default.</para>
+
+        <xi:include href="version-info.xml" xpointer="v232"/>
+        </listitem>
+      </varlistentry>
+
+       <varlistentry>
+        <term><varname>KeepAlive=</varname></term>
+        <listitem><para>Takes a boolean argument. If true, the TCP/IP stack will send a keep alive message
+        after 2h (depending on the configuration of
+        <filename>/proc/sys/net/ipv4/tcp_keepalive_time</filename>) for all TCP streams accepted on this
+        socket. This controls the <constant>SO_KEEPALIVE</constant> socket option (see <citerefentry
+        project='man-pages'><refentrytitle>socket</refentrytitle><manvolnum>7</manvolnum></citerefentry> and
+        the <ulink url="http://www.tldp.org/HOWTO/html_single/TCP-Keepalive-HOWTO/">TCP Keepalive
+        HOWTO</ulink> for details.) Defaults to <option>false</option>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>KeepAliveTimeSec=</varname></term>
+        <listitem><para>Takes time (in seconds) as argument. The connection needs to remain
+        idle before TCP starts sending keepalive probes. This controls the TCP_KEEPIDLE
+        socket option (see
+        <citerefentry project='man-pages'><refentrytitle>socket</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+        and the <ulink
+        url="http://www.tldp.org/HOWTO/html_single/TCP-Keepalive-HOWTO/">TCP
+        Keepalive HOWTO</ulink> for details.)
+        Default value is 7200 seconds (2 hours).</para>
+
+        <xi:include href="version-info.xml" xpointer="v216"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>KeepAliveIntervalSec=</varname></term>
+        <listitem><para>Takes time (in seconds) as argument between individual keepalive probes, if the
+        socket option <constant>SO_KEEPALIVE</constant> has been set on this socket. This controls the
+        <constant>TCP_KEEPINTVL</constant> socket option (see <citerefentry
+        project='man-pages'><refentrytitle>socket</refentrytitle><manvolnum>7</manvolnum></citerefentry> and
+        the <ulink url="http://www.tldp.org/HOWTO/html_single/TCP-Keepalive-HOWTO/">TCP Keepalive
+        HOWTO</ulink> for details.) Default value is 75 seconds.</para>
+
+        <xi:include href="version-info.xml" xpointer="v216"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>KeepAliveProbes=</varname></term>
+        <listitem><para>Takes an integer as argument. It is the number of
+        unacknowledged probes to send before considering the
+        connection dead and notifying the application layer. This
+        controls the TCP_KEEPCNT socket option (see
+        <citerefentry project='man-pages'><refentrytitle>socket</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+        and the <ulink
+        url="http://www.tldp.org/HOWTO/html_single/TCP-Keepalive-HOWTO/">TCP
+        Keepalive HOWTO</ulink> for details.) Default value is
+        9.</para>
+
+        <xi:include href="version-info.xml" xpointer="v216"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>NoDelay=</varname></term>
+        <listitem><para>Takes a boolean argument. TCP Nagle's
+        algorithm works by combining a number of small outgoing
+        messages, and sending them all at once. This controls the
+        TCP_NODELAY socket option (see
+        <citerefentry project='die-net'><refentrytitle>tcp</refentrytitle><manvolnum>7</manvolnum></citerefentry>).
+        Defaults to <option>false</option>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v216"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Priority=</varname></term>
+        <listitem><para>Takes an integer argument controlling the priority for all traffic sent from this
+        socket. This controls the <constant>SO_PRIORITY</constant> socket option (see <citerefentry
+        project='man-pages'><refentrytitle>socket</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
+        details.).</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>DeferAcceptSec=</varname></term>
+
+        <listitem><para>Takes time (in seconds) as argument. If set,
+        the listening process will be awakened only when data arrives
+        on the socket, and not immediately when connection is
+        established. When this option is set, the
+        <constant>TCP_DEFER_ACCEPT</constant> socket option will be
+        used (see
+        <citerefentry project='die-net'><refentrytitle>tcp</refentrytitle><manvolnum>7</manvolnum></citerefentry>),
+        and the kernel will ignore initial ACK packets without any
+        data. The argument specifies the approximate amount of time
+        the kernel should wait for incoming data before falling back
+        to the normal behavior of honoring empty ACK packets. This
+        option is beneficial for protocols where the client sends the
+        data first (e.g. HTTP, in contrast to SMTP), because the
+        server process will not be woken up unnecessarily before it
+        can take any action.
+        </para>
+
+        <para>If the client also uses the
+        <constant>TCP_DEFER_ACCEPT</constant> option, the latency of
+        the initial connection may be reduced, because the kernel will
+        send data in the final packet establishing the connection (the
+        third packet in the "three-way handshake").</para>
+
+        <para>Disabled by default.</para>
+
+        <xi:include href="version-info.xml" xpointer="v216"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ReceiveBuffer=</varname></term>
+        <term><varname>SendBuffer=</varname></term>
+        <listitem><para>Takes an integer argument controlling the receive or send buffer sizes of this
+        socket, respectively.  This controls the <constant>SO_RCVBUF</constant> and
+        <constant>SO_SNDBUF</constant> socket options (see <citerefentry
+        project='man-pages'><refentrytitle>socket</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
+        details.). The usual suffixes K, M, G are supported and are understood to the base of
+        1024.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>IPTOS=</varname></term>
+        <listitem><para>Takes an integer argument controlling the IP Type-Of-Service field for packets
+        generated from this socket.  This controls the <constant>IP_TOS</constant> socket option (see
+        <citerefentry
+        project='die-net'><refentrytitle>ip</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
+        details.). Either a numeric string or one of <option>low-delay</option>, <option>throughput</option>,
+        <option>reliability</option> or <option>low-cost</option> may be specified.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>IPTTL=</varname></term>
+        <listitem><para>Takes an integer argument controlling the IPv4 Time-To-Live/IPv6 Hop-Count field for
+        packets generated from this socket. This sets the
+        <constant>IP_TTL</constant>/<constant>IPV6_UNICAST_HOPS</constant> socket options (see <citerefentry
+        project='die-net'><refentrytitle>ip</refentrytitle><manvolnum>7</manvolnum></citerefentry> and
+        <citerefentry
+        project='die-net'><refentrytitle>ipv6</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
+        details.)</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Mark=</varname></term>
+        <listitem><para>Takes an integer value. Controls the firewall mark of packets generated by this
+        socket. This can be used in the firewall logic to filter packets from this socket. This sets the
+        <constant>SO_MARK</constant> socket option. See <citerefentry
+        project='die-net'><refentrytitle>iptables</refentrytitle><manvolnum>8</manvolnum></citerefentry> for
+        details.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ReusePort=</varname></term>
+        <listitem><para>Takes a boolean value. If true, allows multiple
+        <citerefentry><refentrytitle>bind</refentrytitle><manvolnum>2</manvolnum></citerefentry>s to this TCP
+        or UDP port. This controls the <constant>SO_REUSEPORT</constant> socket option. See <citerefentry
+        project='man-pages'><refentrytitle>socket</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
+        details.</para>
+
+        <xi:include href="version-info.xml" xpointer="v206"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SmackLabel=</varname></term>
+        <term><varname>SmackLabelIPIn=</varname></term>
+        <term><varname>SmackLabelIPOut=</varname></term>
+        <listitem><para>Takes a string value. Controls the extended
+        attributes <literal>security.SMACK64</literal>,
+        <literal>security.SMACK64IPIN</literal> and
+        <literal>security.SMACK64IPOUT</literal>, respectively, i.e.
+        the security label of the FIFO, or the security label for the
+        incoming or outgoing connections of the socket, respectively.
+        See <ulink
+        url="https://docs.kernel.org/admin-guide/LSM/Smack.html">Smack</ulink>
+        for details.</para>
+
+        <xi:include href="version-info.xml" xpointer="v196"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SELinuxContextFromNet=</varname></term>
+         <listitem><para>Takes a boolean argument. When true, systemd
+         will attempt to figure out the SELinux label used for the
+         instantiated service from the information handed by the peer
+         over the network. Note that only the security level is used
+         from the information provided by the peer. Other parts of the
+         resulting SELinux context originate from either the target
+         binary that is effectively triggered by socket unit or from
+         the value of the <varname>SELinuxContext=</varname> option.
+         This configuration option applies only when activated service
+         is passed in single socket file descriptor, i.e. service
+         instances that have standard input connected to a socket or
+         services triggered by exactly one socket unit. Also note
+         that this option is useful only when MLS/MCS SELinux policy
+         is deployed. Defaults to
+         <literal>false</literal>. </para>
+
+         <xi:include href="version-info.xml" xpointer="v217"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>PipeSize=</varname></term>
+        <listitem><para>Takes a size in bytes. Controls the pipe
+        buffer size of FIFOs configured in this socket unit. See
+        <citerefentry><refentrytitle>fcntl</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+        for details. The usual suffixes K, M, G are supported and are
+        understood to the base of 1024.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>MessageQueueMaxMessages=</varname>,
+        <varname>MessageQueueMessageSize=</varname></term>
+        <listitem><para>These two settings take integer values and
+        control the mq_maxmsg field or the mq_msgsize field,
+        respectively, when creating the message queue. Note that
+        either none or both of these variables need to be set. See
+        <citerefentry project='die-net'><refentrytitle>mq_setattr</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+        for details.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>FreeBind=</varname></term>
+        <listitem><para>Takes a boolean value. Controls whether the socket can be bound to non-local IP
+        addresses. This is useful to configure sockets listening on specific IP addresses before those IP
+        addresses are successfully configured on a network interface. This sets the
+        <constant>IP_FREEBIND</constant>/<constant>IPV6_FREEBIND</constant> socket option. For robustness
+        reasons it is recommended to use this option whenever you bind a socket to a specific IP
+        address. Defaults to <option>false</option>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Transparent=</varname></term>
+        <listitem><para>Takes a boolean value. Controls the
+        <constant>IP_TRANSPARENT</constant>/<constant>IPV6_TRANSPARENT</constant> socket option. Defaults to
+        <option>false</option>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Broadcast=</varname></term>
+        <listitem><para>Takes a boolean value. This controls the <constant>SO_BROADCAST</constant> socket
+        option, which allows broadcast datagrams to be sent from this socket. Defaults to
+        <option>false</option>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>PassCredentials=</varname></term>
+        <listitem><para>Takes a boolean value. This controls the <constant>SO_PASSCRED</constant> socket
+        option, which allows <constant>AF_UNIX</constant> sockets to receive the credentials of the sending
+        process in an ancillary message. Defaults to <option>false</option>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>PassSecurity=</varname></term>
+        <listitem><para>Takes a boolean value. This controls the <constant>SO_PASSSEC</constant> socket
+        option, which allows <constant>AF_UNIX</constant> sockets to receive the security context of the
+        sending process in an ancillary message.  Defaults to <option>false</option>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>PassPacketInfo=</varname></term>
+        <listitem><para>Takes a boolean value. This controls the <constant>IP_PKTINFO</constant>,
+        <constant>IPV6_RECVPKTINFO</constant>, <constant>NETLINK_PKTINFO</constant> or
+        <constant>PACKET_AUXDATA</constant> socket options, which enable reception of additional per-packet
+        metadata as ancillary message, on <constant>AF_INET</constant>, <constant>AF_INET6</constant>,
+        <constant>AF_UNIX</constant> and <constant>AF_PACKET</constant> sockets.  Defaults to
+        <option>false</option>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Timestamping=</varname></term>
+        <listitem><para>Takes one of <literal>off</literal>, <literal>us</literal> (alias:
+        <literal>usec</literal>, <literal>μs</literal>) or <literal>ns</literal> (alias:
+        <literal>nsec</literal>). This controls the <constant>SO_TIMESTAMP</constant> or
+        <constant>SO_TIMESTAMPNS</constant> socket options, and enables whether ingress network traffic shall
+        carry timestamping metadata. Defaults to <option>off</option>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v247"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>TCPCongestion=</varname></term>
+        <listitem><para>Takes a string value. Controls the TCP congestion algorithm used by this
+        socket. Should be one of <literal>westwood</literal>, <literal>veno</literal>,
+        <literal>cubic</literal>, <literal>lp</literal> or any other available algorithm supported by the IP
+        stack. This setting applies only to stream sockets.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ExecStartPre=</varname></term>
+        <term><varname>ExecStartPost=</varname></term>
+        <listitem><para>Takes one or more command lines, which are
+        executed before or after the listening sockets/FIFOs are
+        created and bound, respectively. The first token of the
+        command line must be an absolute filename, then followed by
+        arguments for the process. Multiple command lines may be
+        specified following the same scheme as used for
+        <varname>ExecStartPre=</varname> of service unit
+        files.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ExecStopPre=</varname></term>
+        <term><varname>ExecStopPost=</varname></term>
+        <listitem><para>Additional commands that are executed before
+        or after the listening sockets/FIFOs are closed and removed,
+        respectively. Multiple command lines may be specified
+        following the same scheme as used for
+        <varname>ExecStartPre=</varname> of service unit
+        files.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>TimeoutSec=</varname></term>
+        <listitem><para>Configures the time to wait for the commands
+        specified in <varname>ExecStartPre=</varname>,
+        <varname>ExecStartPost=</varname>,
+        <varname>ExecStopPre=</varname> and
+        <varname>ExecStopPost=</varname> to finish. If a command does
+        not exit within the configured time, the socket will be
+        considered failed and be shut down again. All commands still
+        running will be terminated forcibly via
+        <constant>SIGTERM</constant>, and after another delay of this
+        time with <constant>SIGKILL</constant>. (See
+        <option>KillMode=</option> in
+        <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>.)
+        Takes a unit-less value in seconds, or a time span value such
+        as "5min 20s". Pass <literal>0</literal> to disable the
+        timeout logic. Defaults to
+        <varname>DefaultTimeoutStartSec=</varname> from the manager
+        configuration file (see
+        <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
+        </para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Service=</varname></term>
+        <listitem><para>Specifies the service unit name to activate on
+        incoming traffic. This setting is only allowed for sockets
+        with <varname>Accept=no</varname>. It defaults to the service
+        that bears the same name as the socket (with the suffix
+        replaced). In most cases, it should not be necessary to use
+        this option. Note that setting this parameter might result in
+        additional dependencies to be added to the unit (see
+        above).</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RemoveOnStop=</varname></term>
+        <listitem><para>Takes a boolean argument. If enabled, any file nodes created by this socket unit are
+        removed when it is stopped. This applies to <constant>AF_UNIX</constant> sockets in the file system,
+        POSIX message queues, FIFOs, as well as any symlinks to them configured with
+        <varname>Symlinks=</varname>. Normally, it should not be necessary to use this option, and is not
+        recommended as services might continue to run after the socket unit has been terminated and it should
+        still be possible to communicate with them via their file system node. Defaults to
+        off.</para>
+
+        <xi:include href="version-info.xml" xpointer="v214"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Symlinks=</varname></term>
+        <listitem><para>Takes a list of file system paths. The specified paths will be created as symlinks to the
+        <constant>AF_UNIX</constant> socket path or FIFO path of this socket unit. If this setting is used, only one
+        <constant>AF_UNIX</constant> socket in the file system or one FIFO may be configured for the socket unit. Use
+        this option to manage one or more symlinked alias names for a socket, binding their lifecycle together. Note
+        that if creation of a symlink fails this is not considered fatal for the socket unit, and the socket unit may
+        still start. If an empty string is assigned, the list of paths is reset. Defaults to an empty
+        list.</para>
+
+        <xi:include href="version-info.xml" xpointer="v214"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>FileDescriptorName=</varname></term>
+        <listitem><para>Assigns a name to all file descriptors this
+        socket unit encapsulates. This is useful to help activated
+        services identify specific file descriptors, if multiple fds
+        are passed. Services may use the
+        <citerefentry><refentrytitle>sd_listen_fds_with_names</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+        call to acquire the names configured for the received file
+        descriptors. Names may contain any ASCII character, but must
+        exclude control characters and <literal>:</literal>, and must
+        be at most 255 characters in length. If this setting is not
+        used, the file descriptor name defaults to the name of the
+        socket unit, including its <filename>.socket</filename>
+        suffix.</para>
+
+        <xi:include href="version-info.xml" xpointer="v227"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>TriggerLimitIntervalSec=</varname></term>
+        <term><varname>TriggerLimitBurst=</varname></term>
+
+        <listitem><para>Configures a limit on how often this socket unit may be activated within a specific
+        time interval. The <varname>TriggerLimitIntervalSec=</varname> setting may be used to configure the
+        length of the time interval in the usual time units <literal>us</literal>, <literal>ms</literal>,
+        <literal>s</literal>, <literal>min</literal>, <literal>h</literal>, … and defaults to 2s (See
+        <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
+        details on the various time units understood). The <varname>TriggerLimitBurst=</varname> setting
+        takes a positive integer value and specifies the number of permitted activations per time interval,
+        and defaults to 200 for <varname>Accept=yes</varname> sockets (thus by default permitting 200
+        activations per 2s), and 20 otherwise (20 activations per 2s). Set either to 0 to disable any form of
+        trigger rate limiting.</para>
+
+        <para>If the limit is hit, the socket unit is placed into a failure mode, and will not be connectible
+        anymore until restarted. Note that this limit is enforced before the service activation is
+        enqueued.</para>
+
+        <para>Compare with <varname>PollLimitIntervalSec=</varname>/<varname>PollLimitBurst=</varname>
+        described below, which implements a temporary slowdown if a socket unit is flooded with incoming
+        traffic, as opposed to the permanent failure state
+        <varname>TriggerLimitIntervalSec=</varname>/<varname>TriggerLimitBurst=</varname> results in.</para>
+
+        <xi:include href="version-info.xml" xpointer="v230"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>PollLimitIntervalSec=</varname></term>
+        <term><varname>PollLimitBurst=</varname></term>
+
+        <listitem><para>Configures a limit on how often polling events on the file descriptors backing this
+        socket unit will be considered. This pair of settings is similar to
+        <varname>TriggerLimitIntervalSec=</varname>/<varname>TriggerLimitBurst=</varname> but instead of
+        putting a (fatal) limit on the activation frequency puts a (transient) limit on the polling
+        frequency. The expected parameter syntax and range are identical to that of the aforementioned
+        options, and can be disabled the same way.</para>
+
+        <para>If the polling limit is hit polling is temporarily disabled on it until the specified time
+        window passes. The polling limit hence slows down connection attempts if hit, but unlike the trigger
+        limit won't cause permanent failures. It's the recommended mechanism to deal with DoS attempts
+        through packet flooding.</para>
+
+        <para>The polling limit is enforced per file descriptor to listen on, as opposed to the trigger limit
+        which is enforced for the entire socket unit. This distinction matters for socket units that listen
+        on multiple file descriptors (i.e. have multiple <varname>ListenXYZ=</varname> stanzas).</para>
+
+        <para>These setting defaults to 150 (in case of <varname>Accept=yes</varname>) and 15 (otherwise)
+        polling events per 2s. This is considerably lower than the default values for the trigger limit (see
+        above) and means that the polling limit should typically ensure the trigger limit is never hit,
+        unless one of them is reconfigured or disabled.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+
+    </variablelist>
+
+    <xi:include href="systemd.service.xml" xpointer="shared-unit-options" />
+  </refsect1>
+
+  <refsect1>
+      <title>See Also</title>
+      <para>
+        <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>sd_listen_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>sd_listen_fds_with_names</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+      </para>
+      <para>
+        For more extensive descriptions see the "systemd for Developers" series:
+        <ulink url="https://0pointer.de/blog/projects/socket-activation.html">Socket Activation</ulink>,
+        <ulink url="https://0pointer.de/blog/projects/socket-activation2.html">Socket Activation, part II</ulink>,
+        <ulink url="https://0pointer.de/blog/projects/inetd.html">Converting inetd Services</ulink>,
+        <ulink url="https://0pointer.de/blog/projects/socket-activated-containers.html">Socket Activated Internet Services and OS Containers</ulink>.
+      </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd.special.xml b/man/systemd.special.xml
new file mode 100644
index 0000000..8acad5c
--- /dev/null
+++ b/man/systemd.special.xml
@@ -0,0 +1,1513 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd.special" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd.special</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd.special</refentrytitle>
+    <manvolnum>7</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd.special</refname>
+    <refpurpose>Special systemd units</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv><para>
+    <!-- sort alphabetically, targets first --><filename>basic.target</filename>,
+    <filename>bluetooth.target</filename>,
+    <filename>cryptsetup-pre.target</filename>,
+    <filename>cryptsetup.target</filename>,
+    <filename>veritysetup-pre.target</filename>,
+    <filename>veritysetup.target</filename>,
+    <filename>ctrl-alt-del.target</filename>,
+    <filename>blockdev@.target</filename>,
+    <filename>boot-complete.target</filename>,
+    <filename>default.target</filename>,
+    <filename>emergency.target</filename>,
+    <filename>exit.target</filename>,
+    <filename>factory-reset.target</filename>,
+    <filename>final.target</filename>,
+    <filename>first-boot-complete.target</filename>,
+    <filename>getty.target</filename>,
+    <filename>getty-pre.target</filename>,
+    <filename>graphical.target</filename>,
+    <filename>halt.target</filename>,
+    <filename>hibernate.target</filename>,
+    <filename>hybrid-sleep.target</filename>,
+    <filename>suspend-then-hibernate.target</filename>,
+    <filename>initrd.target</filename>,
+    <filename>initrd-fs.target</filename>,
+    <filename>initrd-root-device.target</filename>,
+    <filename>initrd-root-fs.target</filename>,
+    <filename>initrd-usr-fs.target</filename>,
+    <filename>integritysetup-pre.target</filename>,
+    <filename>integritysetup.target</filename>,
+    <filename>kbrequest.target</filename>,
+    <filename>kexec.target</filename>,
+    <filename>local-fs-pre.target</filename>,
+    <filename>local-fs.target</filename>,
+    <filename>machines.target</filename>
+    <filename>multi-user.target</filename>,
+    <filename>network-online.target</filename>,
+    <filename>network-pre.target</filename>,
+    <filename>network.target</filename>,
+    <filename>nss-lookup.target</filename>,
+    <filename>nss-user-lookup.target</filename>,
+    <filename>paths.target</filename>,
+    <filename>poweroff.target</filename>,
+    <filename>printer.target</filename>,
+    <filename>reboot.target</filename>,
+    <filename>remote-cryptsetup.target</filename>,
+    <filename>remote-veritysetup.target</filename>,
+    <filename>remote-fs-pre.target</filename>,
+    <filename>remote-fs.target</filename>,
+    <filename>rescue.target</filename>,
+    <filename>rpcbind.target</filename>,
+    <filename>runlevel2.target</filename>,
+    <filename>runlevel3.target</filename>,
+    <filename>runlevel4.target</filename>,
+    <filename>runlevel5.target</filename>,
+    <filename>shutdown.target</filename>,
+    <filename>sigpwr.target</filename>,
+    <filename>sleep.target</filename>,
+    <filename>slices.target</filename>,
+    <filename>smartcard.target</filename>,
+    <filename>sockets.target</filename>,
+    <filename>soft-reboot.target</filename>,
+    <filename>sound.target</filename>,
+    <filename>storage-target-mode.target</filename>,
+    <filename>suspend.target</filename>,
+    <filename>swap.target</filename>,
+    <filename>sysinit.target</filename>,
+    <filename>system-update.target</filename>,
+    <filename>system-update-pre.target</filename>,
+    <filename>time-set.target</filename>,
+    <filename>time-sync.target</filename>,
+    <filename>timers.target</filename>,
+    <filename>umount.target</filename>,
+    <filename>usb-gadget.target</filename>,
+    <!-- slices --><filename>-.slice</filename>,
+    <filename>system.slice</filename>,
+    <filename>user.slice</filename>,
+    <filename>machine.slice</filename>,
+    <!-- the rest --><filename>-.mount</filename>,
+    <filename>dbus.service</filename>,
+    <filename>dbus.socket</filename>,
+    <filename>display-manager.service</filename>,
+    <filename>init.scope</filename>,
+    <filename>syslog.socket</filename>,
+    <filename>system-update-cleanup.service</filename>
+  </para></refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>A few units are treated specially by systemd. Many of them have
+    special internal semantics and cannot be renamed, while others simply
+    have a standard meaning and should be present on all systems.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Units managed by the system service manager</title>
+
+    <refsect2>
+      <title>Special System Units</title>
+
+      <variablelist>
+        <varlistentry>
+          <term><filename>-.mount</filename></term>
+          <listitem>
+            <para>The root mount point, i.e. the mount unit for the <filename>/</filename>
+            path. This unit is unconditionally active, during the entire time the system is up, as
+            this mount point is where the basic userspace is running from.</para>
+
+          <xi:include href="version-info.xml" xpointer="v235"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><filename>basic.target</filename></term>
+          <listitem>
+            <para>A special target unit covering basic boot-up.</para>
+
+            <para>systemd automatically adds dependency of the type
+            <varname>After=</varname> for this target unit to all
+            services (except for those with
+            <varname>DefaultDependencies=no</varname>).</para>
+
+            <para>Usually, this should pull-in all local mount points plus
+            <filename>/var/</filename>, <filename>/tmp/</filename> and
+            <filename>/var/tmp/</filename>, swap devices, sockets, timers,
+            path units and other basic initialization necessary for general
+            purpose daemons. The mentioned mount points are special cased
+            to allow them to be remote.
+            </para>
+
+            <para>This target usually does not pull in any non-target units
+            directly, but rather does so indirectly via other early boot targets.
+            It is instead meant as a synchronization point for late boot
+            services. Refer to
+            <citerefentry><refentrytitle>bootup</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+            for details on the targets involved.
+            </para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><filename>boot-complete.target</filename></term>
+          <listitem>
+            <para>This target is intended as generic synchronization point for services that shall determine or act on
+            whether the boot process completed successfully. Order units that are required to succeed for a boot process
+            to be considered successful before this unit, and add a <varname>Requires=</varname> dependency from the
+            target unit to them. Order units that shall only run when the boot process is considered successful after the
+            target unit and pull in the target from it, also with <varname>Requires=</varname>. Note that by default this
+            target unit is not part of the initial boot transaction, but is supposed to be pulled in only if required by
+            units that want to run only on successful boots.</para>
+
+            <para>See
+            <citerefentry><refentrytitle>systemd-boot-check-no-failures.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+            for a service that implements a generic system health check and orders itself before
+            <filename>boot-complete.target</filename>.</para>
+
+            <para>See
+            <citerefentry><refentrytitle>systemd-bless-boot.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+            for a service that propagates boot success information to the boot loader, and orders itself after
+            <filename>boot-complete.target</filename>.</para>
+
+            <xi:include href="version-info.xml" xpointer="v240"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><filename>ctrl-alt-del.target</filename></term>
+          <listitem>
+            <para>systemd starts this target whenever Control+Alt+Del is
+            pressed on the console. Usually, this should be aliased
+            (symlinked) to <filename>reboot.target</filename>.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><filename>cryptsetup.target</filename></term>
+          <listitem>
+            <para>A target that pulls in setup services for all
+            encrypted block devices.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><filename>veritysetup.target</filename></term>
+          <listitem>
+            <para>A target that pulls in setup services for all
+            verity integrity protected block devices.</para>
+
+            <xi:include href="version-info.xml" xpointer="v248"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><filename>dbus.service</filename></term>
+          <listitem>
+            <para>A special unit for the D-Bus bus daemon. As soon as
+            this service is fully started up systemd will connect to it
+            and register its service.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><filename>dbus.socket</filename></term>
+          <listitem>
+            <para>A special unit for the D-Bus system bus socket. All
+            units with <varname>Type=dbus</varname> automatically gain a
+            dependency on this unit.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><filename>default.target</filename></term>
+          <listitem>
+            <para>The default unit systemd starts at bootup. Usually, this should be aliased (symlinked) to
+            <filename>multi-user.target</filename> or <filename>graphical.target</filename>. See
+            <citerefentry><refentrytitle>bootup</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
+            more discussion.</para>
+
+            <para>The default unit systemd starts at bootup can be overridden with the
+            <varname>systemd.unit=</varname> kernel command line option, or more conveniently, with the short
+            names like <varname>single</varname>, <varname>rescue</varname>, <varname>1</varname>,
+            <varname>3</varname>, <varname>5</varname>, …; see
+            <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><filename>display-manager.service</filename></term>
+          <listitem>
+            <para>The display manager service. Usually, this should be
+            aliased (symlinked) to <filename>gdm.service</filename> or a
+            similar display manager service.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><filename>emergency.target</filename></term>
+          <listitem>
+            <para>A special target unit that starts an emergency shell on the main console. This
+            target does not pull in other services or mounts. It is the most minimal version of
+            starting the system in order to acquire an interactive shell; the only processes running
+            are usually just the system manager (PID 1) and the shell process. This unit may be used
+            by specifying <varname>emergency</varname> on the kernel command line; it is
+            also used when a file system check on a required file system fails and boot-up cannot
+            continue. Compare with <filename>rescue.target</filename>, which serves a similar
+            purpose, but also starts the most basic services and mounts all file systems.</para>
+
+            <para>In many ways booting into <filename>emergency.target</filename> is similar to the
+            effect of booting with <literal>init=/bin/sh</literal> on the kernel command line,
+            except that emergency mode provides you with the full system and service manager, and
+            allows starting individual units in order to continue the boot process in steps.</para>
+
+            <para>Note that depending on how <filename>emergency.target</filename> is reached, the root file
+            system might be mounted read-only or read-write (no remounting is done specially for this
+            target). For example, the system may boot with root mounted read-only when <varname>ro</varname>
+            is used on the kernel command line and remain this way for <filename>emergency.target</filename>,
+            or the system may transition to <filename>emergency.target</filename> after the system has been
+            partially booted and disks have already been remounted read-write.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><filename>exit.target</filename></term>
+          <listitem>
+            <para>A special service unit for shutting down the system or
+            user service manager. It is equivalent to
+            <filename>poweroff.target</filename> on non-container
+            systems, and also works in containers.</para>
+
+            <para>systemd will start this unit when it receives the
+            <constant>SIGTERM</constant> or <constant>SIGINT</constant>
+            signal when running as user service daemon.</para>
+
+            <para>Normally, this (indirectly) pulls in
+            <filename>shutdown.target</filename>, which in turn should be
+            conflicted by all units that want to be scheduled for
+            shutdown when the service manager starts to exit.</para>
+
+            <xi:include href="version-info.xml" xpointer="v186"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><filename>factory-reset.target</filename></term>
+          <listitem>
+            <para>A special target to trigger a factory reset.</para>
+
+          <xi:include href="version-info.xml" xpointer="v250"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><filename>final.target</filename></term>
+          <listitem>
+            <para>A special target unit that is used during the shutdown
+            logic and may be used to pull in late services after all
+            normal services are already terminated and all mounts
+            unmounted.
+            </para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><filename>getty.target</filename></term>
+          <listitem>
+            <para>A special target unit that pulls in statically
+            configured local TTY <filename>getty</filename> instances.
+            </para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><filename>graphical.target</filename></term>
+          <listitem>
+            <para>A special target unit for setting up a graphical login
+            screen. This pulls in
+            <filename>multi-user.target</filename>.</para>
+
+            <para>Units that are needed for graphical logins shall add
+            <varname>Wants=</varname> dependencies for their unit to
+            this unit (or <filename>multi-user.target</filename>) during
+            installation. This is best configured via
+            <varname>WantedBy=graphical.target</varname> in the unit's
+            [Install] section.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><filename>hibernate.target</filename></term>
+          <listitem>
+            <para>A special target unit for hibernating the system. This
+            pulls in <filename>sleep.target</filename>.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><filename>hybrid-sleep.target</filename></term>
+          <listitem>
+            <para>A special target unit for hibernating and suspending
+            the system at the same time. This pulls in
+            <filename>sleep.target</filename>.</para>
+
+            <xi:include href="version-info.xml" xpointer="v196"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><filename>suspend-then-hibernate.target</filename></term>
+          <listitem>
+            <para>A special target unit for suspending the system for a period
+            of time, waking it and putting it into hibernate. This pulls in
+            <filename>sleep.target</filename>.</para>
+
+            <xi:include href="version-info.xml" xpointer="v239"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><filename>halt.target</filename></term>
+          <listitem>
+            <para>A special target unit for shutting down and halting
+            the system. Note that this target is distinct from
+            <filename>poweroff.target</filename> in that it generally
+            really just halts the system rather than powering it
+            down.</para>
+
+            <para>Applications wanting to halt the system should not start this unit
+            directly, but should instead execute <command>systemctl halt</command>
+            (possibly with the <option>--no-block</option> option) or call
+            <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s
+            <command>org.freedesktop.systemd1.Manager.Halt</command> D-Bus method
+            directly.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><filename>init.scope</filename></term>
+          <listitem>
+            <para>This scope unit is where the system and service manager (PID 1) itself resides. It
+            is active as long as the system is running.</para>
+
+            <xi:include href="version-info.xml" xpointer="v235"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><filename>initrd.target</filename></term>
+          <listitem>
+            <para>This is the default target in the initrd, similar to <filename>default.target</filename> in
+            the main system. It is used to mount the real root and transition to it. See
+            <citerefentry><refentrytitle>bootup</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
+            more discussion.</para>
+
+          <xi:include href="version-info.xml" xpointer="v245"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><filename>initrd-fs.target</filename></term>
+          <listitem>
+            <para><citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+            automatically adds dependencies of type <varname>Before=</varname> to
+            <filename>sysroot-usr.mount</filename> and all mount points found in
+            <filename>/etc/fstab</filename> that have the <option>x-initrd.mount</option> mount option set
+            and do not have the <option>noauto</option> mount option set. It is also indirectly ordered after
+            <filename>sysroot.mount</filename>. Thus, once this target is reached the
+            <filename>/sysroot/</filename> hierarchy is fully set up, in preparation for the transition to
+            the host OS.</para>
+
+          <xi:include href="version-info.xml" xpointer="v199"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><filename>initrd-root-device.target</filename></term>
+          <listitem>
+            <para>A special initrd target unit that is reached when the root filesystem device is available, but before
+            it has been mounted.
+            <citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+            and
+            <citerefentry><refentrytitle>systemd-gpt-auto-generator</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+            automatically setup the appropriate dependencies to make this happen.
+            </para>
+
+            <xi:include href="version-info.xml" xpointer="v230"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><filename>initrd-root-fs.target</filename></term>
+          <listitem>
+            <para><citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+            automatically adds dependencies of type <varname>Before=</varname> to the
+            <filename>sysroot.mount</filename> unit, which is generated from the kernel command line's
+            <varname>root=</varname> setting (or equivalent).</para>
+
+          <xi:include href="version-info.xml" xpointer="v199"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><filename>initrd-usr-fs.target</filename></term>
+          <listitem>
+            <para><citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+            automatically adds dependencies of type <varname>Before=</varname> to the
+            <filename>sysusr-usr.mount</filename> unit, which is generated from the kernel command line's
+            <varname>usr=</varname> switch. Services may order themselves after this target unit in order to
+            run once the <filename>/sysusr/</filename> hierarchy becomes available, on systems that come up
+            initially without a root file system, but with an initialized <filename>/usr/</filename> and need
+            to access that before setting up the root file system to ultimately switch to. On systems where
+            <varname>usr=</varname> is not used this target is ordered after
+            <filename>sysroot.mount</filename> and thus mostly equivalent to
+            <filename>initrd-root-fs.target</filename>. In effect on any system once this target is reached
+            the file system backing <filename>/usr/</filename> is mounted, though possibly at two different
+            locations, either below the <filename>/sysusr/</filename> or the <filename>/sysroot/</filename>
+            hierarchies.</para>
+
+          <xi:include href="version-info.xml" xpointer="v249"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><filename>kbrequest.target</filename></term>
+          <listitem>
+            <para>systemd starts this target whenever Alt+ArrowUp is
+            pressed on the console. Note that any user with physical access
+            to the machine will be able to do this, without authentication,
+            so this should be used carefully.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><filename>kexec.target</filename></term>
+          <listitem>
+            <para>A special target unit for shutting down and rebooting the system via kexec.</para>
+
+            <para>Applications wanting to reboot the system should not start this unit directly, but should
+            instead execute <command>systemctl kexec</command> (possibly with the
+            <option>--no-block</option> option) or call
+            <citerefentry><refentrytitle>systemd-logind</refentrytitle><manvolnum>8</manvolnum></citerefentry>'s
+            <function>org.freedesktop.login1.Manager.RebootWithFlags()</function> D-Bus method
+            directly.</para>
+
+            <para>See
+            <citerefentry><refentrytitle>systemd-kexec.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+            for further details of the operation this target pulls in.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><filename>local-fs.target</filename></term>
+          <listitem>
+            <para><citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+            automatically adds dependencies of type
+            <varname>Before=</varname> to all mount units that refer to
+            local mount points for this target unit. In addition, it
+            adds dependencies of type <varname>Wants=</varname> to this
+            target unit for those mounts listed in
+            <filename>/etc/fstab</filename> that have the
+            <option>auto</option> mount option set.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><filename>machines.target</filename></term>
+          <listitem>
+            <para>A standard target unit for starting all the containers
+            and other virtual machines. See <filename>systemd-nspawn@.service</filename>
+            for an example.</para>
+
+            <xi:include href="version-info.xml" xpointer="v233"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><filename>multi-user.target</filename></term>
+          <listitem>
+            <para>A special target unit for setting up a multi-user
+            system (non-graphical). This is pulled in by
+            <filename>graphical.target</filename>.</para>
+
+            <para>Units that are needed for a multi-user system shall
+            add <varname>Wants=</varname> dependencies for their unit to
+            this unit during installation. This is best configured via
+            <varname>WantedBy=multi-user.target</varname> in the unit's
+            [Install] section.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><filename>network-online.target</filename></term>
+          <listitem>
+            <para>Units that strictly require a configured network
+            connection should pull in
+            <filename>network-online.target</filename> (via a
+            <varname>Wants=</varname> type dependency) and order
+            themselves after it. This target unit is intended to pull in
+            a service that delays further execution until the network is
+            sufficiently set up. What precisely this requires is left to
+            the implementation of the network managing service.</para>
+
+            <para>Note the distinction between this unit and <filename>network.target</filename>. This unit
+            is an active unit (i.e. pulled in by the consumer rather than the provider of this functionality)
+            and pulls in a service which possibly adds substantial delays to further execution. In contrast,
+            <filename>network.target</filename> is a passive unit (i.e. pulled in by the provider of the
+            functionality, rather than the consumer) that usually does not delay execution much. Usually,
+            <filename>network.target</filename> is part of the boot of most systems, while
+            <filename>network-online.target</filename> is not, except when at least one unit requires
+            it. Also see <ulink url="https://systemd.io/NETWORK_ONLINE">Running Services After the Network Is
+            Up</ulink> for more information.</para>
+
+            <para>All mount units for remote network file systems automatically pull in this unit, and order
+            themselves after it. Note that networking daemons that simply <emphasis>provide</emphasis>
+            functionality to other hosts (as opposed to <emphasis>consume</emphasis> functionality of other
+            hosts) generally do not need to pull this in.</para>
+
+            <para>systemd automatically adds dependencies of type <varname>Wants=</varname> and
+            <varname>After=</varname> for this target unit to all SysV init script service units
+            with an LSB header referring to the <literal>$network</literal> facility.</para>
+
+            <para>Note that this unit is only useful during the original system start-up
+            logic. After the system has completed booting up, it will not track the online state of
+            the system anymore. Due to this it cannot be used as a network connection monitor
+            concept, it is purely a one-time system start-up concept.</para>
+
+            <xi:include href="version-info.xml" xpointer="v200"/>
+            </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><filename>paths.target</filename></term>
+          <listitem>
+            <para>A special target unit that sets up all path units (see
+            <citerefentry><refentrytitle>systemd.path</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+            for details) that shall be active after boot.</para>
+
+            <para>It is recommended that path units installed by
+            applications get pulled in via <varname>Wants=</varname>
+            dependencies from this unit. This is best configured via a
+            <varname>WantedBy=paths.target</varname> in the path unit's
+            [Install] section.</para>
+
+            <xi:include href="version-info.xml" xpointer="v199"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><filename>poweroff.target</filename></term>
+          <listitem>
+            <para>A special target unit for shutting down and powering
+            off the system.</para>
+
+            <para>Applications wanting to power off the system should not start this unit
+            directly, but should instead execute <command>systemctl poweroff</command>
+            (possibly with the <option>--no-block</option> option) or call
+            <citerefentry><refentrytitle>systemd-logind</refentrytitle><manvolnum>8</manvolnum></citerefentry>'s
+            <command>org.freedesktop.login1.Manager.PowerOff</command> D-Bus method
+            directly.</para>
+
+            <para><filename>runlevel0.target</filename> is an alias for
+            this target unit, for compatibility with SysV.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><filename>reboot.target</filename></term>
+          <listitem>
+            <para>A special target unit for shutting down and rebooting the system.</para>
+
+            <para>Applications wanting to reboot the system should not start this unit directly, but should
+            instead execute <command>systemctl reboot</command> (possibly with the
+            <option>--no-block</option> option) or call
+            <citerefentry><refentrytitle>systemd-logind</refentrytitle><manvolnum>8</manvolnum></citerefentry>'s
+            <function>org.freedesktop.login1.Manager.Reboot()</function> D-Bus method directly.</para>
+
+            <para>See
+            <citerefentry><refentrytitle>systemd-reboot.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+            for further details of the operation this target pulls in.</para>
+
+            <para><filename>runlevel6.target</filename> is an alias for this target unit, for compatibility
+            with SysV.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><filename>remote-cryptsetup.target</filename></term>
+          <listitem>
+            <para>Similar to <filename>cryptsetup.target</filename>, but for encrypted
+            devices which are accessed over the network. It is used for
+            <citerefentry><refentrytitle>crypttab</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+            entries marked with <option>_netdev</option>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v235"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><filename>remote-veritysetup.target</filename></term>
+          <listitem>
+            <para>Similar to <filename>veritysetup.target</filename>, but for verity
+            integrity protected devices which are accessed over the network. It is used for
+            <citerefentry><refentrytitle>veritytab</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+            entries marked with <option>_netdev</option>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v248"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><filename>remote-fs.target</filename></term>
+          <listitem>
+            <para>Similar to <filename>local-fs.target</filename>, but
+            for remote mount points.</para>
+
+            <para>systemd automatically adds dependencies of type
+            <varname>After=</varname> for this target unit to all SysV
+            init script service units with an LSB header referring to
+            the <literal>$remote_fs</literal> facility.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><filename>rescue.target</filename></term>
+          <listitem>
+            <para>A special target unit that pulls in the base system (including system mounts) and
+            spawns a rescue shell. Isolate to this target in order to administer the system in
+            single-user mode with all file systems mounted but with no services running, except for
+            the most basic. Compare with <filename>emergency.target</filename>, which is much more
+            reduced and does not provide the file systems or most basic services. Compare with
+            <filename>multi-user.target</filename>, this target could be seen as
+            <filename>single-user.target</filename>.</para>
+
+            <para><filename>runlevel1.target</filename> is an alias for this target unit, for
+            compatibility with SysV.</para>
+
+            <para>Use the <literal>systemd.unit=rescue.target</literal> kernel command line option
+            to boot into this mode. A short alias for this kernel command line option is
+            <literal>1</literal>, for compatibility with SysV.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><filename>runlevel2.target</filename></term>
+          <term><filename>runlevel3.target</filename></term>
+          <term><filename>runlevel4.target</filename></term>
+          <term><filename>runlevel5.target</filename></term>
+          <listitem>
+            <para>These are targets that are called whenever the SysV
+            compatibility code asks for runlevel 2, 3, 4, 5,
+            respectively. It is a good idea to make this an alias for
+            (i.e. symlink to) <filename>graphical.target</filename>
+            (for runlevel 5) or <filename>multi-user.target</filename>
+            (the others).</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><filename>shutdown.target</filename></term>
+          <listitem>
+            <para>A special target unit that terminates the services on
+            system shutdown.</para>
+
+            <para>Services that shall be terminated on system shutdown
+            shall add <varname>Conflicts=</varname> and
+            <varname>Before=</varname> dependencies to this unit for
+            their service unit, which is implicitly done when
+            <varname>DefaultDependencies=yes</varname> is set (the
+            default).</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><filename>sigpwr.target</filename></term>
+          <listitem>
+            <para>A special target that is started when systemd receives
+            the SIGPWR process signal, which is normally sent by the
+            kernel or UPS daemons when power fails.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><filename>sleep.target</filename></term>
+          <listitem>
+            <para>A special target unit that is pulled in by
+            <filename>suspend.target</filename>,
+            <filename>hibernate.target</filename> and
+            <filename>hybrid-sleep.target</filename> and may be used to
+            hook units into the sleep state logic.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><filename>slices.target</filename></term>
+          <listitem>
+            <para>A special target unit that sets up all slice units (see
+            <citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+            for details) that shall always be active after boot. By default the generic
+            <filename>system.slice</filename> slice unit as well as the root slice unit
+            <filename>-.slice</filename> are pulled in and ordered before this unit (see
+            below).</para>
+
+            <para>Adding slice units to <filename>slices.target</filename> is generally not
+            necessary. Instead, when some unit that uses <varname>Slice=</varname> is started, the
+            specified slice will be started automatically. Adding
+            <varname>WantedBy=slices.target</varname> lines to the [Install]
+            section should only be done for units that need to be always active. In that case care
+            needs to be taken to avoid creating a loop through the automatic dependencies on
+            "parent" slices.</para>
+
+            <xi:include href="version-info.xml" xpointer="v229"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><filename>sockets.target</filename></term>
+          <listitem>
+            <para>A special target unit that sets up all socket
+            units (see
+            <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+            for details) that shall be active after boot.</para>
+
+            <para>Services that can be socket-activated shall add
+            <varname>Wants=</varname> dependencies to this unit for
+            their socket unit during installation. This is best
+            configured via a <varname>WantedBy=sockets.target</varname>
+            in the socket unit's [Install]
+            section.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><filename>soft-reboot.target</filename></term>
+          <listitem>
+            <para>A special target unit for shutting down and rebooting the userspace of the system (leaving
+            the kernel running).</para>
+
+            <para>Applications wanting to reboot the system should not start this unit directly, but should
+            instead execute <command>systemctl soft-reboot</command> (possibly with the
+            <option>--no-block</option> option) or call
+            <citerefentry><refentrytitle>systemd-logind</refentrytitle><manvolnum>8</manvolnum></citerefentry>'s
+            <function>org.freedesktop.login1.Manager.RebootWithFlags()</function> D-Bus method
+            directly.</para>
+
+            <para>See
+            <citerefentry><refentrytitle>systemd-soft-reboot.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+            for further details of the operation this target pulls in.</para>
+
+            <xi:include href="version-info.xml" xpointer="v254"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><filename>storage-target-mode.target</filename></term>
+          <listitem>
+            <para>A special target unit that can be booted into that selects the "Storage Target Mode" for
+            the OS. In this mode all local storage disks are exposed to external systems as block
+            devices. This invokes
+            <citerefentry><refentrytitle>systemd-storagetm.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+            which exposes all local disks as NVMe-TCP devices for access over the network. It might as well
+            invoke other services too that make local disks available via other mechanisms.</para>
+            <xi:include href="version-info.xml" xpointer="v255"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><filename>suspend.target</filename></term>
+          <listitem>
+            <para>A special target unit for suspending the system. This
+            pulls in <filename>sleep.target</filename>.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><filename>swap.target</filename></term>
+          <listitem>
+            <para>Similar to <filename>local-fs.target</filename>, but
+            for swap partitions and swap files.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><filename>sysinit.target</filename></term>
+          <listitem>
+            <para>systemd automatically adds dependencies of the types
+            <varname>Requires=</varname> and <varname>After=</varname>
+            for this target unit to all services (except for those with
+            <varname>DefaultDependencies=no</varname>).</para>
+
+            <para>This target pulls in the services required for system
+            initialization. System services pulled in by this target should
+            declare <varname>DefaultDependencies=no</varname> and specify
+            all their dependencies manually, including access to anything
+            more than a read only root filesystem. For details on the
+            dependencies of this target, refer to
+            <citerefentry><refentrytitle>bootup</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
+            </para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><filename>syslog.socket</filename></term>
+          <listitem>
+            <para>The socket unit syslog implementations should listen
+            on. All userspace log messages will be made available on
+            this socket. For more information about syslog integration,
+            please consult the <ulink
+            url="https://www.freedesktop.org/wiki/Software/systemd/syslog">Syslog
+            Interface</ulink> document.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><filename>system-update.target</filename></term>
+          <term><filename>system-update-pre.target</filename></term>
+          <term><filename>system-update-cleanup.service</filename></term>
+          <listitem>
+            <para>A special target unit that is used for offline system updates.
+            <citerefentry><refentrytitle>systemd-system-update-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+            will redirect the boot process to this target if <filename>/system-update</filename> or
+            <filename>/etc/system-update</filename> exists. For more information see
+            <citerefentry><refentrytitle>systemd.offline-updates</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
+            </para>
+
+            <para>Updates should happen before the <filename>system-update.target</filename> is
+            reached, and the services which implement them should cause the machine to reboot. The
+            main units executing the update should order themselves after
+            <filename>system-update-pre.target</filename> but not pull it in. Services which want to
+            run during system updates only, but before the actual system update is executed should
+            order themselves before this unit and pull it in. As a safety measure, if this does not
+            happen, and <filename>/system-update</filename> or
+            <filename>/etc/system-update</filename> still exists after
+            <filename>system-update.target</filename> is reached,
+            <filename>system-update-cleanup.service</filename> will remove the symlinks and reboot
+            the machine.</para>
+
+            <xi:include href="version-info.xml" xpointer="v186"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><filename>timers.target</filename></term>
+          <listitem>
+            <para>A special target unit that sets up all timer units
+            (see
+            <citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+            for details) that shall be active after boot.</para>
+
+            <para>It is recommended that timer units installed by
+            applications get pulled in via <varname>Wants=</varname>
+            dependencies from this unit. This is best configured via
+            <varname>WantedBy=timers.target</varname> in the timer
+            unit's [Install] section.</para>
+
+            <xi:include href="version-info.xml" xpointer="v199"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><filename>umount.target</filename></term>
+          <listitem>
+            <para>A special target unit that unmounts all mount and
+            automount points on system shutdown.</para>
+
+            <para>Mounts that shall be unmounted on system shutdown
+            shall add Conflicts dependencies to this unit for their
+            mount unit, which is implicitly done when
+            <varname>DefaultDependencies=yes</varname> is set (the
+            default).</para>
+          </listitem>
+        </varlistentry>
+
+      </variablelist>
+    </refsect2>
+
+    <refsect2>
+      <title>Special System Units for Devices</title>
+
+      <para>Some target units are automatically pulled in as devices of
+      certain kinds show up in the system. These may be used to
+      automatically activate various services based on the specific type
+      of the available hardware.</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><filename>bluetooth.target</filename></term>
+          <listitem>
+            <para>This target is started automatically as soon as a
+            Bluetooth controller is plugged in or becomes available at
+            boot.</para>
+
+            <para>This may be used to pull in Bluetooth management
+            daemons dynamically when Bluetooth hardware is found.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><filename>printer.target</filename></term>
+          <listitem>
+            <para>This target is started automatically as soon as a
+            printer is plugged in or becomes available at boot.</para>
+
+            <para>This may be used to pull in printer management daemons
+            dynamically when printer hardware is found.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><filename>smartcard.target</filename></term>
+          <listitem>
+            <para>This target is started automatically as soon as a
+            smartcard controller is plugged in or becomes available at
+            boot.</para>
+
+            <para>This may be used to pull in smartcard management
+            daemons dynamically when smartcard hardware is found.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><filename>sound.target</filename></term>
+          <listitem>
+            <para>This target is started automatically as soon as a
+            sound card is plugged in or becomes available at
+            boot.</para>
+
+            <para>This may be used to pull in audio management daemons
+            dynamically when audio hardware is found.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><filename>usb-gadget.target</filename></term>
+          <listitem>
+            <para>This target is started automatically as soon as a
+            USB Device Controller becomes available at boot.</para>
+
+            <para>This may be used to pull in usb gadget
+            dynamically when UDC hardware is found.</para>
+
+            <xi:include href="version-info.xml" xpointer="v242"/>
+          </listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+
+    <refsect2>
+      <title>Special Passive System Units </title>
+
+      <para>A number of special system targets are defined that can be
+      used to properly order boot-up of optional services. These targets
+      are generally not part of the initial boot transaction, unless
+      they are explicitly pulled in by one of the implementing services.
+      Note specifically that these <emphasis>passive</emphasis> target
+      units are generally not pulled in by the consumer of a service,
+      but by the provider of the service. This means: a consuming
+      service should order itself after these targets (as appropriate),
+      but not pull it in. A providing service should order itself before
+      these targets (as appropriate) and pull it in (via a
+      <varname>Wants=</varname> type dependency).</para>
+
+      <para>Note that these passive units cannot be started manually,
+      i.e. <literal>systemctl start time-sync.target</literal> will fail
+      with an error. They can only be pulled in by dependency. This is
+      enforced since they exist for ordering purposes only and thus are
+      not useful as only unit within a transaction.</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><filename>blockdev@.target</filename></term>
+          <listitem><para>This template unit is used to order mount units and other consumers of block
+          devices after services that synthesize these block devices. In particular, this is intended to be
+          used with storage services (such as
+          <citerefentry><refentrytitle>systemd-cryptsetup@.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>/
+          <citerefentry><refentrytitle>systemd-veritysetup@.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>)
+          that allocate and manage a virtual block device. Storage services are ordered before an instance of
+          <filename>blockdev@.target</filename>, and the consumer units after it. The ordering is
+          particularly relevant during shutdown, as it ensures that the mount is deactivated first and the
+          service backing the mount later. The <filename>blockdev@.target</filename> instance should be
+          pulled in via a <option>Wants=</option> dependency of the storage daemon and thus generally not be
+          part of any transaction unless a storage daemon is used. The instance name for instances of this
+          template unit must be a properly escaped block device node path, e.g.
+          <filename index="false">blockdev@dev-mapper-foobar.target</filename> for the storage device
+          <filename index="false">/dev/mapper/foobar</filename>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><filename>cryptsetup-pre.target</filename></term>
+          <listitem>
+            <para>This passive target unit may be pulled in by services
+            that want to run before any encrypted block device is set
+            up. All encrypted block devices are set up after this target
+            has been reached. Since the shutdown order is implicitly the
+            reverse start-up order between units, this target is
+            particularly useful to ensure that a service is shut down
+            only after all encrypted block devices are fully
+            stopped.</para>
+
+            <xi:include href="version-info.xml" xpointer="v215"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><filename>veritysetup-pre.target</filename></term>
+          <listitem>
+            <para>This passive target unit may be pulled in by services
+            that want to run before any verity integrity protected block
+            device is set up. All verity integrity protected block
+            devices are set up after this target has been reached. Since
+            the shutdown order is implicitly the reverse start-up order
+            between units, this target is particularly useful to ensure
+            that a service is shut down only after all verity integrity
+            protected block devices are fully stopped.</para>
+
+            <xi:include href="version-info.xml" xpointer="v248"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><filename>first-boot-complete.target</filename></term>
+          <listitem>
+            <para>This passive target is intended as a synchronization point for units that need to run once
+            during the first boot.  Only after all units ordered before this target have finished, will the
+            <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+            be committed to disk, marking the first boot as completed.  If the boot is aborted at any time
+            before that, the next boot will re-run any units with <varname>ConditionFirstBoot=yes</varname>.
+            </para>
+
+            <xi:include href="version-info.xml" xpointer="v247"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><filename>getty-pre.target</filename></term>
+          <listitem>
+            <para>A special passive target unit. Users of this target
+            are expected to pull it in the boot transaction via
+            a dependency (e.g. <varname>Wants=</varname>). Order your
+            unit before this unit if you want to make use of the console
+            just before <filename>getty</filename> is started.
+            </para>
+
+            <xi:include href="version-info.xml" xpointer="v235"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><filename>local-fs-pre.target</filename></term>
+          <listitem>
+            <para>This target unit is
+            automatically ordered before
+            all local mount points marked
+            with <option>auto</option>
+            (see above). It can be used to
+            execute certain units before
+            all local mounts.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><filename>network.target</filename></term>
+          <listitem>
+            <para>This unit is supposed to indicate when network functionality is available, but it is only
+            very weakly defined what that is supposed to mean. However, the following should apply at
+            minimum:</para>
+
+            <itemizedlist>
+              <listitem><para>At start-up, any configured synthetic network devices (i.e. not physical ones
+              that require hardware to show up and be probed, but virtual ones like bridge devices and
+              similar which are created programmatically) that do not depend on any underlying hardware
+              should be allocated by the time this target is reached. It is not necessary for these
+              interfaces to also have completed IP level configuration by the time
+              <filename>network.target</filename> is reached.</para></listitem>
+
+              <listitem><para>At shutdown, a unit that is ordered after <filename>network.target</filename>
+              will be stopped before the network — to whatever level it might be set up by then — is shut
+              down. It is hence useful when writing service files that require network access on shutdown,
+              which should order themselves after this target, but not pull it in. Also see <ulink
+              url="https://systemd.io/NETWORK_ONLINE">Running Services After the Network Is Up</ulink> for
+              more information.</para></listitem>
+            </itemizedlist>
+
+            <para>It must emphasized that at start-up there's no guarantee that hardware-based devices have
+            shown up by the time this target is reached, or even acquired complete IP configuration. For that
+            purpose use <filename>network-online.target</filename> as described above.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><filename>network-pre.target</filename></term>
+          <listitem>
+            <para>This passive target unit may be pulled in by services that want to run before any network
+            is set up, for example for the purpose of setting up a firewall. All network management software
+            orders itself after this target, but does not pull it in. Also see <ulink
+            url="https://systemd.io/NETWORK_ONLINE">Running Services After the Network Is Up</ulink> for more
+            information.</para>
+
+            <xi:include href="version-info.xml" xpointer="v214"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><filename>nss-lookup.target</filename></term>
+          <listitem>
+            <para>A target that should be used as synchronization point for all host/network name
+            service lookups. Note that this is independent of UNIX user/group name lookups for which
+            <filename>nss-user-lookup.target</filename> should be used.  All services for which the
+            availability of full host/network name resolution is essential should be ordered after
+            this target, but not pull it in. systemd automatically adds dependencies of type
+            <varname>After=</varname> for this target unit to all SysV init script service units
+            with an LSB header referring to the <literal>$named</literal> facility.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><filename>nss-user-lookup.target</filename></term>
+          <listitem>
+            <para>A target that should be used as synchronization point for all regular UNIX
+            user/group name service lookups. Note that this is independent of host/network name
+            lookups for which <filename>nss-lookup.target</filename> should be used. All services
+            for which the availability of the full user/group database is essential should be
+            ordered after this target, but not pull it in. All services which provide parts of the
+            user/group database should be ordered before this target, and pull it in. Note that this
+            unit is only relevant for regular users and groups — system users and groups are
+            required to be resolvable during earliest boot already, and hence do not need any
+            special ordering against this target.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><filename>remote-fs-pre.target</filename></term>
+          <listitem>
+            <para>This target unit is automatically ordered before all
+            mount point units (see above) and cryptsetup/veritysetup devices
+            marked with the <option>_netdev</option>. It can be used to run
+            certain units before remote encrypted devices and mounts are established.
+            Note that this unit is generally not part of the initial
+            transaction, unless the unit that wants to be ordered before
+            all remote mounts pulls it in via a
+            <varname>Wants=</varname> type dependency. If the unit wants
+            to be pulled in by the first remote mount showing up, it
+            should use <filename>network-online.target</filename> (see
+            above).</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><filename>rpcbind.target</filename></term>
+          <listitem>
+            <para>The portmapper/rpcbind pulls in this target and orders
+            itself before it, to indicate its availability. systemd
+            automatically adds dependencies of type
+            <varname>After=</varname> for this target unit to all SysV
+            init script service units with an LSB header referring to
+            the <literal>$portmap</literal> facility.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><filename>time-set.target</filename></term>
+          <listitem>
+            <para>Services responsible for setting the system clock (<constant>CLOCK_REALTIME</constant>)
+            from a local source (such as a maintained timestamp file or imprecise real-time clock) should
+            pull in this target and order themselves before it. Services where approximate, roughly monotonic
+            time is desired should be ordered after this unit, but not pull it in.</para>
+
+            <para>This target does not provide the accuracy guarantees of
+            <filename>time-sync.target</filename> (see below), however does not depend on remote clock
+            sources to be reachable, i.e. the target is typically not delayed by network problems and
+            similar. Use of this target is recommended for services where approximate clock accuracy and
+            rough monotonicity is desired but activation shall not be delayed for possibly unreliable network
+            communication.</para>
+
+            <para>The service manager automatically adds dependencies of type <varname>After=</varname> for
+            this target unit to all timer units with at least one <varname>OnCalendar=</varname>
+            directive.</para>
+
+            <para>The
+            <citerefentry><refentrytitle>systemd-timesyncd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+            service is a simple daemon that pulls in this target and orders itself before it. Besides
+            implementing the SNTP network protocol it maintains a timestamp file on disk whose modification
+            time is regularly updated. At service start-up the local system clock is set from that modification time,
+            ensuring it increases roughly monotonically.</para>
+
+            <para>Note that ordering a unit after <filename>time-set.target</filename> only has effect if
+            there's actually a service ordered before it that delays it until the clock is adjusted for rough
+            monotonicity. Otherwise, this target might get reached before the clock is adjusted to be roughly
+            monotonic. Enable
+            <citerefentry><refentrytitle>systemd-timesyncd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+            or an alternative NTP implementation to delay the target.</para>
+
+            <xi:include href="version-info.xml" xpointer="v242"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><filename>time-sync.target</filename></term>
+          <listitem>
+            <para>Services indicating completed synchronization of the system clock
+            (<constant>CLOCK_REALTIME</constant>) to a remote source should pull in this target and order
+            themselves before it. Services where accurate time is essential should be ordered after this
+            unit, but not pull it in.</para>
+
+            <para>The service manager automatically adds dependencies of type <varname>After=</varname> for
+            this target unit to all SysV init script service units with an LSB header referring to the
+            <literal>$time</literal> facility, as well to all timer units with at least one
+            <varname>OnCalendar=</varname> directive.</para>
+
+            <para>This target provides stricter clock accuracy guarantees than
+            <filename>time-set.target</filename> (see above), but likely requires
+            network communication and thus introduces unpredictable delays.
+            Services that require clock accuracy and where network
+            communication delays are acceptable should use this target. Services that require a less accurate
+            clock, and only approximate and roughly monotonic clock behaviour should use
+            <filename>time-set.target</filename> instead.</para>
+
+            <para>Note that ordering a unit after <filename>time-sync.target</filename> only has effect if
+            there's actually a service ordered before it that delays it until clock synchronization is
+            reached. Otherwise, this target might get reached before the clock is synchronized to any remote
+            accurate reference clock. When using
+            <citerefentry><refentrytitle>systemd-timesyncd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+            enable
+            <citerefentry><refentrytitle>systemd-time-wait-sync.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+            to delay the target; or use an equivalent service for other NTP implementations.</para>
+
+            <table>
+              <title>Comparison</title>
+              <tgroup cols='2' align='left' colsep='1' rowsep='1'>
+                <colspec colname="time-set" />
+                <colspec colname="time-sync" />
+                <thead>
+                  <row>
+                    <entry><filename>time-set.target</filename></entry>
+                    <entry><filename>time-sync.target</filename></entry>
+                  </row>
+                </thead>
+                <tbody>
+                  <row>
+                    <entry>"quick" to reach</entry>
+                    <entry>"slow" to reach</entry>
+                  </row>
+                  <row>
+                    <entry>typically uses local clock sources, boot process not affected by availability of external resources</entry>
+                    <entry>typically uses remote clock sources, inserts dependencies on remote resources into boot process</entry>
+                  </row>
+                  <row>
+                    <entry>reliable, because local</entry>
+                    <entry>unreliable, because typically network involved</entry>
+                  </row>
+                  <row>
+                    <entry>typically guarantees an approximate and roughly monotonic clock only</entry>
+                    <entry>typically guarantees an accurate clock</entry>
+                  </row>
+                  <row>
+                    <entry>implemented by <filename>systemd-timesyncd.service</filename></entry>
+                    <entry>implemented by <filename>systemd-time-wait-sync.service</filename></entry>
+                  </row>
+                </tbody>
+              </tgroup>
+            </table>
+
+          </listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+
+    <refsect2>
+      <title>Special Slice Units</title>
+
+      <para>There are four <literal>.slice</literal> units which form the basis of the hierarchy for
+      assignment of resources for services, users, and virtual machines or containers. See
+      <citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+      for details about slice units.</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><filename>-.slice</filename></term>
+          <listitem>
+            <para>The root slice is the root of the slice hierarchy. It usually does not contain
+            units directly, but may be used to set defaults for the whole tree.</para>
+
+            <xi:include href="version-info.xml" xpointer="v206"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><filename>system.slice</filename></term>
+          <listitem>
+            <para>By default, all system services started by
+            <command>systemd</command> are found in this slice.</para>
+
+            <xi:include href="version-info.xml" xpointer="v206"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><filename>user.slice</filename></term>
+          <listitem>
+            <para>By default, all user processes and services started on
+            behalf of the user, including the per-user systemd instance
+            are found in this slice.  This is pulled in by
+            <filename>systemd-logind.service</filename>.</para>
+
+            <xi:include href="version-info.xml" xpointer="v206"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><filename>machine.slice</filename></term>
+          <listitem>
+            <para>By default, all virtual machines and containers
+            registered with <command>systemd-machined</command> are
+            found in this slice. This is pulled in by
+            <filename>systemd-machined.service</filename>.</para>
+
+            <xi:include href="version-info.xml" xpointer="v206"/>
+          </listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <refsect1>
+    <title>Units managed by the user service manager</title>
+
+    <refsect2>
+      <title>Special User Units</title>
+
+      <para>When systemd runs as a user instance, the following special
+      units are available:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><filename>default.target</filename></term>
+          <listitem>
+            <para>This is the main target of the user session, started by default. Various services that
+            compose the normal user session should be pulled into this target. In this regard,
+            <filename>default.target</filename> is similar to <filename>multi-user.target</filename> in the
+            system instance, but it is a real unit, not an alias.</para>
+
+            <xi:include href="version-info.xml" xpointer="v242"/>
+          </listitem>
+        </varlistentry>
+      </variablelist>
+
+      <para>In addition, the following units are available which have definitions similar to their
+      system counterparts:
+      <filename>exit.target</filename>,
+      <filename>shutdown.target</filename>,
+      <filename>sockets.target</filename>,
+      <filename>timers.target</filename>,
+      <filename>paths.target</filename>,
+      <filename>bluetooth.target</filename>,
+      <filename>printer.target</filename>,
+      <filename>smartcard.target</filename>,
+      <filename>sound.target</filename>.</para>
+    </refsect2>
+
+    <refsect2>
+      <title>Special Passive User Units</title>
+
+      <variablelist>
+        <varlistentry>
+          <term><filename>graphical-session.target</filename></term>
+          <listitem>
+            <para>This target is active whenever any graphical session is running. It is used to
+            stop user services which only apply to a graphical (X, Wayland, etc.) session when the
+            session is terminated. Such services should have
+            <literal>PartOf=graphical-session.target</literal> in their [Unit]
+            section. A target for a particular session (e. g.
+            <filename>gnome-session.target</filename>) starts and stops
+            <literal>graphical-session.target</literal> with
+            <literal>BindsTo=graphical-session.target</literal>.</para>
+
+            <para>Which services are started by a session target is determined by the
+            <literal>Wants=</literal> and <literal>Requires=</literal> dependencies.  For services
+            that can be enabled independently, symlinks in <literal>.wants/</literal> and
+            <literal>.requires/</literal> should be used, see
+            <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+            Those symlinks should either be shipped in packages, or should be added dynamically
+            after installation, for example using <literal>systemctl add-wants</literal>, see
+            <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
+            </para>
+
+            <example>
+              <title>Nautilus as part of a GNOME session</title>
+
+              <para><literal>gnome-session.target</literal> pulls in Nautilus as top-level service:</para>
+
+              <programlisting>[Unit]
+Description=User systemd services for GNOME graphical session
+Wants=nautilus.service
+BindsTo=graphical-session.target</programlisting>
+
+              <para><literal>nautilus.service</literal> gets stopped when the session stops:</para>
+
+              <programlisting>[Unit]
+Description=Render the desktop icons with Nautilus
+PartOf=graphical-session.target
+
+[Service]
+…</programlisting>
+            </example>
+
+              <xi:include href="version-info.xml" xpointer="v234"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><filename>graphical-session-pre.target</filename></term>
+          <listitem>
+            <para>This target contains services which set up the environment or global configuration
+            of a graphical session, such as SSH/GPG agents (which need to export an environment
+            variable into all desktop processes) or migration of obsolete d-conf keys after an OS
+            upgrade (which needs to happen before starting any process that might use them). This
+            target must be started before starting a graphical session like
+            <filename>gnome-session.target</filename>.</para>
+
+            <xi:include href="version-info.xml" xpointer="v234"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><filename>xdg-desktop-autostart.target</filename></term>
+          <listitem>
+            <para>The XDG specification defines a way to autostart applications using XDG desktop files.
+            systemd ships
+            <citerefentry><refentrytitle>systemd-xdg-autostart-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+            for the XDG desktop files in autostart directories. Desktop Environments can opt-in to use this
+            service by adding a <varname>Wants=</varname> dependency on
+            <filename>xdg-desktop-autostart.target</filename>.</para>
+
+            <xi:include href="version-info.xml" xpointer="v246"/>
+          </listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+
+    <refsect2>
+      <title>Special User Slice Units</title>
+
+      <para>There are four <literal>.slice</literal> units which form the basis of the user hierarchy for
+      assignment of resources for user applications and services. See
+      <citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+      for details about slice units and the documentation about
+      <ulink url="https://systemd.io/DESKTOP_ENVIRONMENTS">Desktop Environments</ulink>
+      for further information.</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><filename>-.slice</filename></term>
+          <listitem>
+            <para>The root slice is the root of the user's slice hierarchy.
+            It usually does not contain units directly, but may be used to set defaults for the whole tree.</para>
+
+            <xi:include href="version-info.xml" xpointer="v247"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><filename>app.slice</filename></term>
+          <listitem>
+            <para>By default, all user services and applications managed by
+            <command>systemd</command> are found in this slice.
+            All interactively launched applications like web browsers and text editors
+            as well as non-critical services should be placed into this slice.</para>
+
+            <xi:include href="version-info.xml" xpointer="v247"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><filename>session.slice</filename></term>
+          <listitem>
+            <para>All essential services and applications required for the
+            session should use this slice.
+            These are services that either cannot be restarted easily
+            or where latency issues may affect the interactivity of the system and applications.
+            This includes the display server, screen readers and other services such as DBus or XDG portals.
+            Such services should be configured to be part of this slice by
+            adding <varname>Slice=session.slice</varname> to their unit files.</para>
+
+            <xi:include href="version-info.xml" xpointer="v247"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><filename>background.slice</filename></term>
+          <listitem>
+            <para>All services running low-priority background tasks should use this slice.
+            This permits resources to be preferentially assigned to the other slices.
+            Examples include non-interactive tasks like file indexing or backup operations
+            where latency is not important.</para>
+
+            <xi:include href="version-info.xml" xpointer="v247"/>
+          </listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <refsect1>
+      <title>See Also</title>
+      <para>
+        <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>bootup</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>user@.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+      </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd.swap.xml b/man/systemd.swap.xml
new file mode 100644
index 0000000..1c019b2
--- /dev/null
+++ b/man/systemd.swap.xml
@@ -0,0 +1,269 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd.swap" xmlns:xi="http://www.w3.org/2001/XInclude">
+  <refentryinfo>
+    <title>systemd.swap</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd.swap</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd.swap</refname>
+    <refpurpose>Swap unit configuration</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename><replaceable>swap</replaceable>.swap</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>A unit configuration file whose name ends in
+    <literal>.swap</literal> encodes information about a swap device
+    or file for memory paging controlled and supervised by
+    systemd.</para>
+
+    <para>This man page lists the configuration options specific to
+    this unit type. See
+    <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for the common options of all unit configuration files. The common
+    configuration items are configured in the generic [Unit] and
+    [Install] sections. The swap specific configuration options are
+    configured in the [Swap] section.</para>
+
+    <para>Additional options are listed in
+    <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    which define the execution environment the <citerefentry
+    project='man-pages'><refentrytitle>swapon</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    program is executed in, in
+    <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    which define the way these processes are
+    terminated, and in
+    <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    which configure resource control settings for these processes of the
+    unit.</para>
+
+    <para>Swap units must be named after the devices or files they control. Example: the swap device <filename
+    index="false">/dev/sda5</filename> must be configured in a unit file <filename>dev-sda5.swap</filename>. For
+    details about the escaping logic used to convert a file system path to a unit name, see
+    <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>. Note that swap
+    units cannot be templated, nor is possible to add multiple names to a swap unit by creating additional symlinks to
+    it.</para>
+
+    <para>Note that swap support on Linux is privileged, swap units are hence only available in the system
+    service manager (and root's user service manager), but not in unprivileged user's service manager.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Automatic Dependencies</title>
+
+    <refsect2>
+      <title>Implicit Dependencies</title>
+
+      <para>The following dependencies are implicitly added:</para>
+
+      <itemizedlist>
+        <listitem><para>All swap units automatically get the
+        <varname>BindsTo=</varname> and <varname>After=</varname>
+        dependencies on the device units or the mount units of the files
+        they are activated from.</para></listitem>
+      </itemizedlist>
+
+      <para>Additional implicit dependencies may be added as result of
+      execution and resource control parameters as documented in
+      <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+      and
+      <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+    </refsect2>
+
+    <refsect2>
+      <title>Default Dependencies</title>
+
+      <para>The following dependencies are added unless <varname>DefaultDependencies=no</varname> is set:</para>
+
+      <itemizedlist>
+        <listitem><para>Swap units automatically acquire a <varname>Conflicts=</varname> and a
+        <varname>Before=</varname> dependency on <filename>umount.target</filename> so that they are deactivated at
+        shutdown as well as a <varname>Before=swap.target</varname> dependency.</para></listitem>
+      </itemizedlist>
+    </refsect2>
+  </refsect1>
+
+  <refsect1>
+    <title><filename>fstab</filename></title>
+
+    <para>Swap units may either be configured via unit files, or via
+    <filename>/etc/fstab</filename> (see
+    <citerefentry project='man-pages'><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for details). Swaps listed in <filename>/etc/fstab</filename> will
+    be converted into native units dynamically at boot and when the
+    configuration of the system manager is reloaded. See
+    <citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    for details about the conversion.</para>
+
+    <para>If a swap device or file is configured in both
+    <filename>/etc/fstab</filename> and a unit file, the configuration
+    in the latter takes precedence.</para>
+
+    <para>When reading <filename>/etc/fstab</filename>, a few special
+    options are understood by systemd which influence how dependencies
+    are created for swap units.</para>
+
+    <variablelist class='fstab-options'>
+      <varlistentry>
+        <term><option>noauto</option></term>
+        <term><option>auto</option></term>
+
+        <listitem><para>With <option>noauto</option>, the swap unit
+        will not be added as a dependency for
+        <filename>swap.target</filename>. This means that it will not
+        be activated automatically during boot, unless it is pulled in
+        by some other unit. The <option>auto</option> option has the
+        opposite meaning and is the default.</para>
+
+        <xi:include href="version-info.xml" xpointer="v218"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>nofail</option></term>
+
+        <listitem><para>With <option>nofail</option>, the swap unit
+        will be only wanted, not required by
+        <filename>swap.target</filename>. This means that the boot
+        will continue even if this swap device is not activated
+        successfully.</para>
+
+        <xi:include href="version-info.xml" xpointer="v218"/>
+        </listitem>
+      </varlistentry>
+
+      <xi:include href="systemd.mount.xml" xpointer="device-timeout" />
+
+      <varlistentry>
+        <term><option>x-systemd.makefs</option></term>
+
+        <listitem><para>The swap structure will be initialized on the device. If the device is not
+        "empty", i.e. it contains any signature, the operation will be skipped. It is hence expected
+        that this option remains set even after the device has been initialized.</para>
+
+        <para>Note that this option can only be used in <filename>/etc/fstab</filename>, and will be
+        ignored when part of the <varname>Options=</varname> setting in a unit file.</para>
+
+        <para>See
+        <citerefentry><refentrytitle>systemd-mkswap@.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        and the discussion of
+        <citerefentry project='man-pages'><refentrytitle>wipefs</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        in <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v240"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>Swap unit files may include [Unit] and [Install] sections, which are described in
+    <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+    </para>
+
+    <para>Swap unit files must include a [Swap] section, which carries
+    information about the swap device it supervises. A number of
+    options that may be used in this section are shared with other
+    unit types. These options are documented in
+    <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    and
+    <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+    The options specific to the [Swap] section of swap units are the
+    following:</para>
+
+    <variablelist class='unit-directives'>
+
+      <varlistentry>
+        <term><varname>What=</varname></term>
+        <listitem><para>Takes an absolute path of a device node or file to use for paging. See <citerefentry
+        project='man-pages'><refentrytitle>swapon</refentrytitle><manvolnum>8</manvolnum></citerefentry> for
+        details. If this refers to a device node, a dependency on the respective device unit is automatically
+        created. (See
+        <citerefentry><refentrytitle>systemd.device</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for more information.) If this refers to a file, a dependency on the respective mount unit is
+        automatically created. (See
+        <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
+        more information.) This option is mandatory. Note that the usual specifier expansion is applied to
+        this setting, literal percent characters should hence be written as
+        <literal class='specifiers'>%%</literal>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Priority=</varname></term>
+
+        <listitem><para>Swap priority to use when activating the swap
+        device or file. This takes an integer. This setting is
+        optional and ignored when the priority is set by <option>pri=</option> in the
+        <varname>Options=</varname> key.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Options=</varname></term>
+
+        <listitem><para>May contain an option string for the swap device. This may be used for controlling discard
+        options among other functionality, if the swap backing device supports the discard or trim operation. (See
+        <citerefentry project='man-pages'><refentrytitle>swapon</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        for more information.) Note that the usual specifier expansion is applied to this setting, literal percent
+        characters should hence be written as <literal>%%</literal>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v217"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>TimeoutSec=</varname></term>
+        <listitem><para>Configures the time to wait for the swapon
+        command to finish. If a command does not exit within the
+        configured time, the swap will be considered failed and be
+        shut down again. All commands still running will be terminated
+        forcibly via <constant>SIGTERM</constant>, and after another
+        delay of this time with <constant>SIGKILL</constant>. (See
+        <option>KillMode=</option> in
+        <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>.)
+        Takes a unit-less value in seconds, or a time span value such
+        as "5min 20s". Pass <literal>0</literal> to disable the
+        timeout logic. Defaults to
+        <varname>DefaultTimeoutStartSec=</varname> from the manager
+        configuration file (see
+        <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
+        </para></listitem>
+      </varlistentry>
+    </variablelist>
+
+    <xi:include href="systemd.service.xml" xpointer="shared-unit-options" />
+  </refsect1>
+
+  <refsect1>
+      <title>See Also</title>
+      <para>
+        <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.device</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry project='man-pages'><refentrytitle>swapon</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+      </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd.syntax.xml b/man/systemd.syntax.xml
new file mode 100644
index 0000000..2fc2288
--- /dev/null
+++ b/man/systemd.syntax.xml
@@ -0,0 +1,232 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [
+<!ENTITY % entities SYSTEM "custom-entities.ent" >
+%entities;
+]>
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd.syntax">
+
+  <refentryinfo>
+    <title>systemd.syntax</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd.syntax</refentrytitle>
+    <manvolnum>7</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd.syntax</refname>
+    <refpurpose>General syntax of systemd configuration files</refpurpose>
+  </refnamediv>
+
+  <refsect1>
+    <title>Introduction</title>
+
+    <para>This page describes the basic principles of configuration files used by
+    <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    and related programs for:
+    <itemizedlist>
+      <listitem><para>systemd unit files, see
+      <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.device</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.automount</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.swap</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.path</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.scope</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+      </para></listitem>
+
+      <listitem><para>link files, see
+      <citerefentry><refentrytitle>systemd.link</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+      </para></listitem>
+
+      <listitem><para>netdev and network files, see
+      <citerefentry><refentrytitle>systemd.netdev</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.network</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+      </para></listitem>
+
+      <listitem><para>daemon config files, see
+      <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-user.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>logind.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>journald.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>journal-remote.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>journal-upload.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-sleep.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>timesyncd.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+      </para></listitem>
+
+      <listitem><para>nspawn files, see
+        <citerefentry><refentrytitle>systemd.nspawn</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+      </para></listitem>
+    </itemizedlist>
+    </para>
+
+    <para>The syntax is inspired by
+    <ulink url="https://standards.freedesktop.org/desktop-entry-spec/latest/">XDG Desktop Entry Specification</ulink>
+    <filename>.desktop</filename> files, which are in turn inspired by Microsoft Windows
+    <filename>.ini</filename> files.
+    </para>
+
+    <para>Each file is a plain text file divided into sections, with configuration entries in the style
+    <replaceable>key</replaceable>=<replaceable>value</replaceable>. Whitespace immediately before or after
+    the <literal>=</literal> is ignored. Empty lines and lines starting with <literal>#</literal> or
+    <literal>;</literal> are ignored, which may be used for commenting.</para>
+
+    <para>Lines ending in a backslash are concatenated with the following line while reading and the
+    backslash is replaced by a space character. This may be used to wrap long lines. The limit on
+    line length is very large (currently 1 MB), but it is recommended to avoid such long lines and
+    use multiple directives, variable substitution, or other mechanism as appropriate for the given
+    file type. When a comment line or lines follow a line ending with a backslash, the comment block
+    is ignored, so the continued line is concatenated with whatever follows the comment block.</para>
+
+    <example><programlisting>[Section A]
+KeyOne=value 1
+KeyTwo=value 2
+
+# a comment
+
+[Section B]
+Setting="something" "some thing" "…"
+KeyTwo=value 2 \
+       value 2 continued
+
+[Section C]
+KeyThree=value 3\
+# this line is ignored
+; this line is ignored too
+       value 3 continued
+</programlisting></example>
+
+    <para>Boolean arguments used in configuration files can be written in
+    various formats. For positive settings the strings
+    <option>1</option>, <option>yes</option>, <option>true</option>
+    and <option>on</option> are equivalent. For negative settings, the
+    strings <option>0</option>, <option>no</option>,
+    <option>false</option> and <option>off</option> are
+    equivalent.</para>
+
+    <para>Time span values encoded in configuration files can be written in various formats. A stand-alone
+    number specifies a time in seconds.  If suffixed with a time unit, the unit is honored. A
+    concatenation of multiple values with units is supported, in which case the values are added
+    up. Example: <literal>50</literal> refers to 50 seconds; <literal>2min 200ms</literal> refers to
+    2 minutes and 200 milliseconds, i.e. 120200 ms.  The following time units are understood:
+    <literal>s</literal>, <literal>min</literal>, <literal>h</literal>, <literal>d</literal>,
+    <literal>w</literal>, <literal>ms</literal>, <literal>us</literal>.  For details see
+    <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
+
+    <para>Various settings are allowed to be specified more than once, in which case the
+    interpretation depends on the setting. Often, multiple settings form a list, and setting to an
+    empty value "resets", which means that previous assignments are ignored. When this is allowed,
+    it is mentioned in the description of the setting. Note that using multiple assignments to the
+    same value makes the file incompatible with parsers for the XDG <filename>.desktop</filename>
+    file format.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Quoting</title>
+
+    <para>For settings where quoting is allowed, the following general rules apply: double quotes ("…") and
+    single quotes ('…') may be used to wrap a whole item (the opening quote may appear only at the beginning
+    or after whitespace that is not quoted, and the closing quote must be followed by whitespace or the end
+    of line), in which case everything until the next matching quote becomes part of the same item. Quotes
+    themselves are removed. C-style escapes are supported. The table below contains the list of known escape
+    patterns. Only escape patterns which match the syntax in the table are allowed; other patterns may be
+    added in the future and unknown patterns will result in a warning. In particular, any backslashes should
+    be doubled. Finally, a trailing backslash (<literal>\</literal>) may be used to merge lines, as described
+    above. UTF-8 is accepted, and hence typical unicode characters do not need to be escaped.</para>
+
+    <table>
+      <title>Supported escapes</title>
+      <tgroup cols='2'>
+        <colspec colname='escape' />
+        <colspec colname='meaning' />
+        <thead>
+          <row>
+            <entry>Literal</entry>
+            <entry>Actual value</entry>
+          </row>
+        </thead>
+        <tbody>
+          <row>
+            <entry><literal>\a</literal></entry>
+            <entry>bell</entry>
+          </row>
+          <row>
+            <entry><literal>\b</literal></entry>
+            <entry>backspace</entry>
+          </row>
+          <row>
+            <entry><literal>\f</literal></entry>
+            <entry>form feed</entry>
+          </row>
+          <row>
+            <entry><literal>\n</literal></entry>
+            <entry>newline</entry>
+          </row>
+          <row>
+            <entry><literal>\r</literal></entry>
+            <entry>carriage return</entry>
+          </row>
+          <row>
+            <entry><literal>\t</literal></entry>
+            <entry>tab</entry>
+          </row>
+          <row>
+            <entry><literal>\v</literal></entry>
+            <entry>vertical tab</entry>
+          </row>
+          <row>
+            <entry><literal>\\</literal></entry>
+            <entry>backslash</entry>
+          </row>
+          <row>
+            <entry><literal>\"</literal></entry>
+            <entry>double quotation mark</entry>
+          </row>
+          <row>
+            <entry><literal>\'</literal></entry>
+            <entry>single quotation mark</entry>
+          </row>
+          <row>
+            <entry><literal>\s</literal></entry>
+            <entry>space</entry>
+          </row>
+          <row>
+            <entry><literal>\x<replaceable>xx</replaceable></literal></entry>
+            <entry>character number <replaceable>xx</replaceable> in hexadecimal encoding</entry>
+          </row>
+          <row>
+            <entry><literal>\<replaceable>nnn</replaceable></literal></entry>
+            <entry>character number <replaceable>nnn</replaceable> in octal encoding</entry>
+          </row>
+          <row>
+            <entry><literal>\u<replaceable>nnnn</replaceable></literal></entry>
+            <entry>unicode code point <replaceable>nnnn</replaceable> in hexadecimal encoding</entry>
+          </row>
+          <row>
+            <entry><literal>\U<replaceable>nnnnnnnn</replaceable></literal></entry>
+            <entry>unicode code point <replaceable>nnnnnnnn</replaceable> in hexadecimal encoding</entry>
+          </row>
+        </tbody>
+      </tgroup>
+    </table>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd.system-credentials.xml b/man/systemd.system-credentials.xml
new file mode 100644
index 0000000..f7f0df1
--- /dev/null
+++ b/man/systemd.system-credentials.xml
@@ -0,0 +1,285 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd.system-credentials" xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd.system-credentials</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd.system-credentials</refentrytitle>
+    <manvolnum>7</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd.system-credentials</refname>
+    <refpurpose>System Credentials</refpurpose>
+  </refnamediv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><ulink url="https://systemd.io/CREDENTIALS">System and Service Credentials</ulink> are data objects
+    that may be passed into booted systems or system services as they are invoked. They can be acquired from
+    various external sources, and propagated into the system and from there into system services. Credentials
+    may optionally be encrypted with a machine-specific key and/or locked to the local TPM2 device, and are
+    only decrypted when the consuming service is invoked.</para>
+
+    <para>System credentials may be used to provision and configure various aspects of the system. Depending
+    on the consuming component credentials are only used on initial invocations or are needed for all
+    invocations.</para>
+
+    <para>Credentials may be used for any kind of data, binary or text, and may carry passwords, secrets,
+    certificates, cryptographic key material, identity information, configuration, and more.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Well known system credentials</title>
+
+    <variablelist class='system-credentials'>
+      <varlistentry>
+        <term><varname>firstboot.keymap</varname></term>
+        <listitem>
+          <para>The console key mapping to set (e.g. <literal>de</literal>).  Read by
+          <citerefentry><refentrytitle>systemd-firstboot</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+          and only honoured if no console keymap has been configured before.</para>
+
+        <xi:include href="version-info.xml" xpointer="v252"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>firstboot.locale</varname></term>
+        <term><varname>firstboot.locale-messages</varname></term>
+        <listitem>
+          <para>The system locale to set (e.g. <literal>de_DE.UTF-8</literal>). Read by
+          <citerefentry><refentrytitle>systemd-firstboot</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+          and only honoured if no locale has been configured before. <varname>firstboot.locale</varname> sets
+          <literal>LANG</literal>, while <varname>firstboot.locale-message</varname> sets
+          <literal>LC_MESSAGES</literal>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v252"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>firstboot.timezone</varname></term>
+        <listitem>
+          <para>The system timezone to set (e.g. <literal>Europe/Berlin</literal>).  Read by
+          <citerefentry><refentrytitle>systemd-firstboot</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+          and only honoured if no system timezone has been configured before.</para>
+
+        <xi:include href="version-info.xml" xpointer="v252"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>login.issue</varname></term>
+        <listitem>
+          <para>The data of this credential is written to
+          <filename>/etc/issue.d/50-provision.conf</filename>, if the file doesn't exist yet.
+          <citerefentry project='man-pages'><refentrytitle>agetty</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+          reads this file and shows its contents at the login prompt of terminal logins. See
+          <citerefentry project='man-pages'><refentrytitle>issue</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+          for details.</para>
+
+          <para>Consumed by <filename>/usr/lib/tmpfiles.d/provision.conf</filename>, see
+          <citerefentry><refentrytitle>tmpfiles.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v252"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>login.motd</varname></term>
+        <listitem>
+          <para>The data of this credential is written to <filename>/etc/motd.d/50-provision.conf</filename>,
+          if the file doesn't exist yet.
+          <citerefentry project='man-pages'><refentrytitle>pam_motd</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+          reads this file and shows its contents as "message of the day" during terminal logins. See
+          <citerefentry project='man-pages'><refentrytitle>motd</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+          for details.</para>
+
+          <para>Consumed by <filename>/usr/lib/tmpfiles.d/provision.conf</filename>, see
+          <citerefentry><refentrytitle>tmpfiles.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v252"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>network.hosts</varname></term>
+        <listitem>
+          <para>The data of this credential is written to <filename>/etc/hosts</filename>, if the file
+          doesn't exist yet. See
+          <citerefentry project='man-pages'><refentrytitle>hosts</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+          for details.</para>
+
+          <para>Consumed by <filename>/usr/lib/tmpfiles.d/provision.conf</filename>, see
+          <citerefentry><refentrytitle>tmpfiles.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v252"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>network.dns</varname></term>
+        <term><varname>network.search_domains</varname></term>
+        <listitem>
+          <para>DNS server information and search domains. Read by
+          <citerefentry><refentrytitle>systemd-resolved.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v253"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>passwd.hashed-password.root</varname></term>
+        <term><varname>passwd.plaintext-password.root</varname></term>
+        <listitem>
+          <para>May contain the password (either in UNIX hashed format, or in plaintext) for the root users.
+          Read by both
+          <citerefentry><refentrytitle>systemd-firstboot</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+          and
+          <citerefentry><refentrytitle>systemd-sysusers</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+          and only honoured if no root password has been configured before.</para>
+
+          <xi:include href="version-info.xml" xpointer="v252"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>passwd.shell.root</varname></term>
+        <listitem>
+          <para>The path to the shell program (e.g. <literal>/bin/bash</literal>) for the root user.  Read by
+          both
+          <citerefentry><refentrytitle>systemd-firstboot</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+          and
+          <citerefentry><refentrytitle>systemd-sysusers</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+          and only honoured if no root shell has been configured before.</para>
+
+        <xi:include href="version-info.xml" xpointer="v252"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ssh.authorized_keys.root</varname></term>
+        <listitem>
+          <para>The data of this credential is written to <filename>/root/.ssh/authorized_keys</filename>, if
+          the file doesn't exist yet. This allows provisioning SSH access for the system's root user.</para>
+
+          <para>Consumed by <filename>/usr/lib/tmpfiles.d/provision.conf</filename>, see
+          <citerefentry><refentrytitle>tmpfiles.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v252"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>sysusers.extra</varname></term>
+        <listitem>
+          <para>Additional
+          <citerefentry><refentrytitle>sysusers.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+          lines to process during boot.</para>
+
+          <xi:include href="version-info.xml" xpointer="v252"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>sysctl.extra</varname></term>
+        <listitem>
+          <para>Additional
+          <citerefentry><refentrytitle>sysctl.d</refentrytitle><manvolnum>5</manvolnum></citerefentry> lines
+          to process during boot.</para>
+
+          <xi:include href="version-info.xml" xpointer="v252"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>tmpfiles.extra</varname></term>
+        <listitem>
+          <para>Additional
+          <citerefentry><refentrytitle>tmpfiles.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+          lines to process during boot.</para>
+
+          <xi:include href="version-info.xml" xpointer="v252"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>fstab.extra</varname></term>
+
+        <listitem>
+          <para>Additional mounts to establish at boot. For details, see
+          <citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v254"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>vconsole.keymap</varname></term>
+        <term><varname>vconsole.keymap_toggle</varname></term>
+        <term><varname>vconsole.font</varname></term>
+        <term><varname>vconsole.font_map</varname></term>
+        <term><varname>vconsole.font_unimap</varname></term>
+        <listitem>
+          <para>Console settings to apply, see
+          <citerefentry><refentrytitle>systemd-vconsole-setup.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> for details.</para>
+
+          <xi:include href="version-info.xml" xpointer="v253"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>getty.ttys.serial</varname></term>
+        <term><varname>getty.ttys.container</varname></term>
+
+        <listitem><para>Used for spawning additional login prompts, see
+        <citerefentry><refentrytitle>systemd-getty-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry> for details.</para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>vmm.notify_socket</varname></term>
+        <listitem>
+          <para>Configures an
+          <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+          compatible <constant>AF_VSOCK</constant> socket the service manager will report status information,
+          ready notification and exit status on. For details see
+          <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v253"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>system.machine_id</varname></term>
+        <listitem>
+          <para>Takes a 128bit ID to initialize the machine ID from (if it is not set yet). Interpreted by
+          the service manager (PID 1). For details see
+          <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v254"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+      <title>See Also</title>
+      <para>
+        <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>kernel-command-line</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>smbios-type-11</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+      </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd.target.xml b/man/systemd.target.xml
new file mode 100644
index 0000000..f650825
--- /dev/null
+++ b/man/systemd.target.xml
@@ -0,0 +1,150 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd.target">
+  <refentryinfo>
+    <title>systemd.target</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd.target</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd.target</refname>
+    <refpurpose>Target unit configuration</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename><replaceable>target</replaceable>.target</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>A unit configuration file whose name ends in <literal>.target</literal> encodes information about a
+    target unit of systemd. Target units are used to group units and to set synchronization points for
+    ordering dependencies with other unit files.</para>
+
+    <para>This unit type has no specific options. See
+    <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> for the
+    common options of all unit configuration files. The common configuration items are configured in the
+    generic [Unit] and [Install] sections. A separate [Target] section does not exist, since no
+    target-specific options may be configured.</para>
+
+    <para>Target units do not offer any additional functionality on top of the generic functionality provided
+    by units. They merely group units, allowing a single target name to be used in <varname>Wants=</varname>
+    and <varname>Requires=</varname> settings to establish a dependency on a set of units defined by the
+    target, and in <varname>Before=</varname> and <varname>After=</varname> settings to establish ordering.
+    Targets establish standardized names for synchronization points during boot and shutdown. Importantly,
+    see <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+    for examples and descriptions of standard systemd targets.</para>
+
+    <para>Target units provide a more flexible replacement for SysV runlevels in the classic SysV init
+    system. For compatibility reasons special target units such as <filename>runlevel3.target</filename>
+    exist which are used by the SysV runlevel compatibility code in systemd, see
+    <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
+    details.</para>
+
+    <para>Note that a target unit file must not be empty, lest it be considered a masked unit. It is
+    recommended to provide a [Unit] section which includes informative <varname>Description=</varname> and
+    <varname>Documentation=</varname> options.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Automatic Dependencies</title>
+
+    <refsect2>
+      <title>Implicit Dependencies</title>
+
+      <para>There are no implicit dependencies for target units.</para>
+    </refsect2>
+
+    <refsect2>
+      <title>Default Dependencies</title>
+
+      <para>The following dependencies are added unless
+      <varname>DefaultDependencies=no</varname> is set:</para>
+
+      <itemizedlist>
+        <listitem><para>Target units will automatically complement all configured dependencies of type
+        <varname>Wants=</varname> or <varname>Requires=</varname> with dependencies of type
+        <varname>After=</varname> unless <varname>DefaultDependencies=no</varname> is set in the specified
+        units.</para>
+
+        <para>Note that the reverse is not true. For example, defining <option>Wants=that.target</option> in
+        <filename index='false'>some.service</filename> will not automatically add the
+        <option>After=that.target</option> ordering dependency for <filename>some.service</filename>.
+        Instead, <filename>some.service</filename> should use the primary synchronization function of target
+        type units, by setting a specific <option>After=that.target</option> or
+        <option>Before=that.target</option> ordering dependency in its .service unit file.
+        </para></listitem>
+
+        <listitem><para>Target units automatically gain <varname>Conflicts=</varname>
+        and <varname>Before=</varname> dependencies against
+        <filename>shutdown.target</filename>.</para></listitem>
+      </itemizedlist>
+    </refsect2>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>Target unit files may include [Unit] and [Install] sections, which are described in
+    <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+    No options specific to this file type are supported.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Example</title>
+
+    <example>
+      <title>Simple standalone target</title>
+
+      <programlisting># emergency-net.target
+
+[Unit]
+Description=Emergency Mode with Networking
+Requires=emergency.target systemd-networkd.service
+After=emergency.target systemd-networkd.service
+AllowIsolate=yes</programlisting>
+
+      <para>When adding dependencies to other units, it's important to check if they set
+      <varname>DefaultDependencies=</varname>. Service units, unless they set
+      <varname>DefaultDependencies=no</varname>, automatically get a dependency on
+      <filename>sysinit.target</filename>. In this case, both
+      <filename>emergency.target</filename> and <filename>systemd-networkd.service</filename>
+      have <varname>DefaultDependencies=no</varname>, so they are suitable for use
+      in this target, and do not pull in <filename>sysinit.target</filename>.</para>
+
+      <para>You can now switch into this emergency mode by running <varname>systemctl
+      isolate emergency-net.target</varname> or by passing the option
+      <varname>systemd.unit=emergency-net.target</varname> on the kernel command
+      line.</para>
+
+      <para>Other units can have <varname>WantedBy=emergency-net.target</varname> in the
+      <varname>[Install]</varname> section. After they are enabled using
+      <command>systemctl enable</command>, they will be started before
+      <varname>emergency-net.target</varname> is started. It is also possible to add
+      arbitrary units as dependencies of <filename>emergency.target</filename> without
+      modifying them by using <command>systemctl add-wants</command>.
+      </para>
+    </example>
+  </refsect1>
+
+  <refsect1>
+      <title>See Also</title>
+      <para>
+        <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+      </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd.time.xml b/man/systemd.time.xml
new file mode 100644
index 0000000..f6a4550
--- /dev/null
+++ b/man/systemd.time.xml
@@ -0,0 +1,330 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd.time">
+
+  <refentryinfo>
+    <title>systemd.time</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd.time</refentrytitle>
+    <manvolnum>7</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd.time</refname>
+    <refpurpose>Time and date specifications</refpurpose>
+  </refnamediv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>In systemd, timestamps, time spans, and calendar events are
+    displayed and may be specified in closely related syntaxes.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Displaying Time Spans</title>
+
+    <para>Time spans refer to time durations. On display, systemd will present time spans as a space-separated series
+    of time values each suffixed by a time unit. Example:</para>
+
+    <programlisting>2h 30min</programlisting>
+
+    <para>All specified time values are meant to be added up. The above hence refers to 150 minutes. Display is
+    locale-independent, only English names for the time units are used.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Parsing Time Spans</title>
+
+    <para>When parsing, systemd will accept the same time span syntax.
+    Separating spaces may be omitted. The following time units are
+    understood:</para>
+
+    <itemizedlist>
+      <listitem><para>usec, us, μs</para></listitem>
+      <listitem><para>msec, ms</para></listitem>
+      <listitem><para>seconds, second, sec, s</para></listitem>
+      <listitem><para>minutes, minute, min, m</para></listitem>
+      <listitem><para>hours, hour, hr, h</para></listitem>
+      <listitem><para>days, day, d</para></listitem>
+      <listitem><para>weeks, week, w</para></listitem>
+      <listitem><para>months, month, M (defined as 30.44 days)</para></listitem>
+      <listitem><para>years, year, y (defined as 365.25 days)</para></listitem>
+    </itemizedlist>
+
+    <para>If no time unit is specified, generally seconds are assumed, but some exceptions exist and are marked as
+    such. In a few cases <literal>ns</literal>, <literal>nsec</literal> is accepted too, where the granularity of the
+    time span permits this. Parsing is generally locale-independent, non-English names for the time units are not
+    accepted.</para>
+
+    <para>Examples for valid time span specifications:</para>
+
+    <programlisting>2 h
+2hours
+48hr
+1y 12month
+55s500ms
+300ms20s 5day</programlisting>
+
+    <para>One can use the <command>timespan</command> command of
+    <citerefentry><refentrytitle>systemd-analyze</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    to normalise a textual time span for testing and validation purposes.</para>
+
+    <para>Internally, systemd generally operates with microsecond time granularity, while the default time
+    unit in user-configurable time spans is usually seconds (see above). This disparity becomes visible when
+    comparing the same settings in the (high-level) unit file syntax with the matching (more low-level) D-Bus
+    properties (which are what
+    <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s
+    <command>show</command> command displays). The former typically are suffixed with <literal>…Sec</literal>
+    to indicate the default unit of seconds, the latter are typically suffixed with <literal>…USec</literal>
+    to indicate the underlying low-level time unit, even if they both encapsulate the very same
+    settings.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Displaying Timestamps</title>
+
+    <para>Timestamps refer to specific, unique points in time. On
+    display, systemd will format these in the local timezone as
+    follows:</para>
+
+    <programlisting>Fri 2012-11-23 23:02:15 CET</programlisting>
+
+    <para>The weekday is printed in the abbreviated English language form. The formatting is locale-independent.</para>
+
+    <para>In some cases timestamps are shown in the UTC timezone instead of the local timezone, which is indicated via
+    the <literal>UTC</literal> timezone specifier in the output.</para>
+
+    <para>In some cases timestamps are shown with microsecond granularity. In this case the sub-second remainder is
+    separated by a full stop from the seconds component.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Parsing Timestamps</title>
+
+    <para>When parsing, systemd will accept a similar syntax, but some fields can be omitted,
+    and the space between the date and time can be replaced with a <literal>T</literal>
+    (à la the <ulink url="https://tools.ietf.org/html/rfc3339">RFC 3339</ulink> profile of ISO 8601);
+    thus, in CET, the following are all identical:
+    <literal>Fri 2012-11-23 23:02:15 CET</literal>,
+    <literal>Fri 2012-11-23T23:02:15</literal>,
+    <literal>2012-11-23T23:02:15 CET</literal>,
+    <literal>2012-11-23 23:02:15</literal>.</para>
+
+    <para>The timezone defaults to the current timezone if not specified explicitly.
+    It may be given after a space, like above, in which case it can be:
+    <literal>UTC</literal>,
+    an entry in the installed IANA timezone database (<literal>CET</literal>, <literal>Asia/Tokyo</literal>, &amp;c.;
+    complete list obtainable with <literal>timedatectl
+    list-timezones</literal> (see
+    <citerefentry><refentrytitle>timedatectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>)),
+    or <literal>±<replaceable>05</replaceable></literal>,
+    <literal>±<replaceable>05</replaceable><replaceable>30</replaceable></literal>,
+    <literal>±<replaceable>05</replaceable>:<replaceable>30</replaceable></literal>,
+    <literal>Z</literal>.</para>   <!-- glibc %z -->
+
+    <para>It may also be affixed directly to the timestamp, in which case it must correspond
+    to one of the formats defined in the
+    <ulink url="https://tools.ietf.org/html/rfc3339">RFC 3339</ulink> profile of ISO 8601:
+    <literal>±<replaceable>05</replaceable>:<replaceable>30</replaceable></literal> or <literal>Z</literal>.
+    Thus, the following are also identical to the above:
+    <literal>2012-11-23T23:02:15+01:00</literal>,
+    <literal>2012-11-23 22:02:15Z</literal>.</para>
+
+    <para>A timestamp can start with a field containing a weekday, which can be in an abbreviated
+    (<literal>Wed</literal>) or non-abbreviated (<literal>Wednesday</literal>) English language form (case
+    does not matter), regardless of the locale.
+    However, if a weekday <emphasis>is</emphasis> specified and doesn't match the date, the timestamp is rejected.</para>
+
+    <para>If the date is omitted, it defaults to today. If the time is omitted, it defaults to 00:00:00.
+    Fractional seconds can be specified down to 1µs precision. The seconds field can also be omitted, defaulting to 0.</para>
+
+    <para>There are special tokens that can be used in place of timestamps:
+    <literal>now</literal> may be
+    used to refer to the current time (or of the invocation of the
+    command that is currently executed). <literal>today</literal>,
+    <literal>yesterday</literal>, and <literal>tomorrow</literal> refer to
+    00:00:00 of the current day, the day before, or the next day,
+    respectively.</para>
+
+    <para>Relative times are also accepted: a time span (see above) prefixed with
+    <literal>+</literal> is evaluated to the current time plus the
+    specified time span. Correspondingly, a time span that is prefixed
+    with <literal>-</literal> is evaluated to the current time minus
+    the specified time span. Instead of prefixing the time span with
+    <literal>+</literal> or <literal>-</literal>, it may also be
+    suffixed with a space and the word <literal>left</literal> or
+    <literal>ago</literal>.</para>
+
+    <para>Finally, an integer prefixed with <literal>@</literal> is
+    evaluated relative to the UNIX epoch – 1970-01-01 00:00:00 UTC.</para>
+
+    <para>Examples for valid timestamps and their normalized form (assuming the current time was 2012-11-23
+    18:15:22 and the timezone was UTC+8, for example <literal>TZ=:Asia/Shanghai</literal>):</para>
+
+    <programlisting>  Fri 2012-11-23 11:12:13 → Fri 2012-11-23 11:12:13
+      2012-11-23 11:12:13 → Fri 2012-11-23 11:12:13
+  2012-11-23 11:12:13 UTC → Fri 2012-11-23 19:12:13
+     2012-11-23T11:12:13Z → Fri 2012-11-23 19:12:13
+   2012-11-23T11:12+02:00 → Fri 2012-11-23 17:12:00
+               2012-11-23 → Fri 2012-11-23 00:00:00
+                 12-11-23 → Fri 2012-11-23 00:00:00
+                 11:12:13 → Fri 2012-11-23 11:12:13
+                    11:12 → Fri 2012-11-23 11:12:00
+                      now → Fri 2012-11-23 18:15:22
+                    today → Fri 2012-11-23 00:00:00
+                today UTC → Fri 2012-11-23 16:00:00
+                yesterday → Fri 2012-11-22 00:00:00
+                 tomorrow → Fri 2012-11-24 00:00:00
+tomorrow Pacific/Auckland → Thu 2012-11-23 19:00:00
+                 +3h30min → Fri 2012-11-23 21:45:22
+                      -5s → Fri 2012-11-23 18:15:17
+                11min ago → Fri 2012-11-23 18:04:22
+              @1395716396 → Tue 2014-03-25 03:59:56</programlisting>
+
+    <para>Note that timestamps displayed by remote systems with a non-matching timezone are usually not parsable
+    locally, as the timezone component is not understood (unless it happens to be <literal>UTC</literal>).</para>
+
+    <para>Timestamps may also be specified with microsecond granularity. The sub-second remainder is expected separated
+    by a full stop from the seconds component. Example:</para>
+
+    <programlisting>2014-03-25 03:59:56.654563</programlisting>
+
+    <para>In some cases, systemd will display a relative timestamp (relative to the current time, or the time of
+    invocation of the command) instead of or in addition to an absolute timestamp as described above. A relative
+    timestamp is formatted as follows:</para>
+
+    <programlisting>2 months 5 days ago</programlisting>
+
+    <para>Note that a relative timestamp is also accepted where a timestamp is expected (see above).</para>
+
+    <para>Use the <command>timestamp</command> command of
+    <citerefentry><refentrytitle>systemd-analyze</refentrytitle><manvolnum>1</manvolnum></citerefentry> to
+    validate and normalize timestamps for testing purposes.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Calendar Events</title>
+
+    <para>Calendar events may be used to refer to one or more points
+    in time in a single expression. They form a superset of the
+    absolute timestamps explained above:</para>
+
+    <programlisting>Thu,Fri 2012-*-1,5 11:12:13</programlisting>
+
+    <para>The above refers to 11:12:13 of the first or fifth day of
+    any month of the year 2012, but only if that day is a Thursday or
+    Friday.</para>
+
+    <para>The weekday specification is optional. If specified, it
+    should consist of one or more English language weekday names,
+    either in the abbreviated (Wed) or non-abbreviated (Wednesday)
+    form (case does not matter), separated by commas. Specifying two
+    weekdays separated by <literal>..</literal> refers to a range of
+    continuous weekdays. <literal>,</literal> and <literal>..</literal>
+    may be combined freely.</para>
+
+    <para>In the date and time specifications, any component may be specified as <literal>*</literal> in
+    which case any value will match. Alternatively, each component can be specified as a list of values
+    separated by commas. Values may be suffixed with <literal>/</literal> and a repetition value, which
+    indicates that the value itself and the value plus all multiples of the repetition value are matched.
+    Two values separated by <literal>..</literal> may be used to indicate a range of values; ranges may also
+    be followed with <literal>/</literal> and a repetition value, in which case the expression matches all
+    times starting with the start value, and continuing with all multiples of the repetition value relative
+    to the start value, ending at the end value the latest.</para>
+
+    <para>A date specification may use <literal>~</literal> to indicate the last day in a month. For example,
+    <literal>*-02~03</literal> means "the third last day in February," and <literal>Mon *-05~07/1</literal>
+    means "the last Monday in May."</para>
+
+    <para>The seconds component may contain decimal fractions both in
+    the value and the repetition. All fractions are rounded to 6
+    decimal places.</para>
+
+    <para>Either time or date specification may be omitted, in which
+    case *-*-* and 00:00:00 is implied, respectively. If the
+    seconds component is not specified, <literal>:00</literal> is
+    assumed.</para>
+
+    <para>Timezone can be specified as the literal string <literal>UTC</literal>, or
+    the local timezone, similar to the supported syntax of timestamps (see above), or the timezone
+    in the IANA timezone database format (also see above).</para>
+
+  <para>The following special expressions may be used as shorthands for longer normalized forms:</para>
+
+    <programlisting>    minutely → *-*-* *:*:00
+      hourly → *-*-* *:00:00
+       daily → *-*-* 00:00:00
+     monthly → *-*-01 00:00:00
+      weekly → Mon *-*-* 00:00:00
+      yearly → *-01-01 00:00:00
+   quarterly → *-01,04,07,10-01 00:00:00
+semiannually → *-01,07-01 00:00:00
+   </programlisting>
+
+    <para>Examples for valid timestamps and their
+    normalized form:</para>
+
+<programlisting>  Sat,Thu,Mon..Wed,Sat..Sun → Mon..Thu,Sat,Sun *-*-* 00:00:00
+      Mon,Sun 12-*-* 2,1:23 → Mon,Sun 2012-*-* 01,02:23:00
+                    Wed *-1 → Wed *-*-01 00:00:00
+           Wed..Wed,Wed *-1 → Wed *-*-01 00:00:00
+                 Wed, 17:48 → Wed *-*-* 17:48:00
+Wed..Sat,Tue 12-10-15 1:2:3 → Tue..Sat 2012-10-15 01:02:03
+                *-*-7 0:0:0 → *-*-07 00:00:00
+                      10-15 → *-10-15 00:00:00
+        monday *-12-* 17:00 → Mon *-12-* 17:00:00
+  Mon,Fri *-*-3,1,2 *:30:45 → Mon,Fri *-*-01,02,03 *:30:45
+       12,14,13,12:20,10,30 → *-*-* 12,13,14:10,20,30:00
+            12..14:10,20,30 → *-*-* 12..14:10,20,30:00
+  mon,fri *-1/2-1,3 *:30:45 → Mon,Fri *-01/2-01,03 *:30:45
+             03-05 08:05:40 → *-03-05 08:05:40
+                   08:05:40 → *-*-* 08:05:40
+                      05:40 → *-*-* 05:40:00
+     Sat,Sun 12-05 08:05:40 → Sat,Sun *-12-05 08:05:40
+           Sat,Sun 08:05:40 → Sat,Sun *-*-* 08:05:40
+           2003-03-05 05:40 → 2003-03-05 05:40:00
+ 05:40:23.4200004/3.1700005 → *-*-* 05:40:23.420000/3.170001
+             2003-02..04-05 → 2003-02..04-05 00:00:00
+       2003-03-05 05:40 UTC → 2003-03-05 05:40:00 UTC
+                 2003-03-05 → 2003-03-05 00:00:00
+                      03-05 → *-03-05 00:00:00
+                     hourly → *-*-* *:00:00
+                      daily → *-*-* 00:00:00
+                  daily UTC → *-*-* 00:00:00 UTC
+                    monthly → *-*-01 00:00:00
+                     weekly → Mon *-*-* 00:00:00
+    weekly Pacific/Auckland → Mon *-*-* 00:00:00 Pacific/Auckland
+                     yearly → *-01-01 00:00:00
+                   annually → *-01-01 00:00:00
+                      *:2/3 → *-*-* *:02/3:00</programlisting>
+
+      <para>Calendar events are used by timer units, see
+      <citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+      for details.</para>
+
+      <para>Use the <command>calendar</command> command of
+      <citerefentry><refentrytitle>systemd-analyze</refentrytitle><manvolnum>1</manvolnum></citerefentry> to validate
+      and normalize calendar time specifications for testing purposes. The tool also calculates when a specified
+      calendar event would occur next.</para>
+  </refsect1>
+
+  <refsect1>
+      <title>See Also</title>
+      <para>
+        <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd-analyze</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+      </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd.timer.xml b/man/systemd.timer.xml
new file mode 100644
index 0000000..e5af7c0
--- /dev/null
+++ b/man/systemd.timer.xml
@@ -0,0 +1,416 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd.timer" xmlns:xi="http://www.w3.org/2001/XInclude">
+  <refentryinfo>
+    <title>systemd.timer</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd.timer</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd.timer</refname>
+    <refpurpose>Timer unit configuration</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename><replaceable>timer</replaceable>.timer</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>A unit configuration file whose name ends in
+    <literal>.timer</literal> encodes information about a timer
+    controlled and supervised by systemd, for timer-based
+    activation.</para>
+
+    <para>This man page lists the configuration options specific to
+    this unit type. See
+    <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for the common options of all unit configuration files. The common
+    configuration items are configured in the generic [Unit] and
+    [Install] sections. The timer specific configuration options are
+    configured in the [Timer] section.</para>
+
+    <para>For each timer file, a matching unit file must exist,
+    describing the unit to activate when the timer elapses. By
+    default, a service by the same name as the timer (except for the
+    suffix) is activated. Example: a timer file
+    <filename>foo.timer</filename> activates a matching service
+    <filename>foo.service</filename>. The unit to activate may be
+    controlled by <varname>Unit=</varname> (see below).</para>
+
+    <para>Note that in case the unit to activate is already active at the time the timer elapses it is not restarted,
+    but simply left running. There is no concept of spawning new service instances in this case. Due to this, services
+    with <varname>RemainAfterExit=yes</varname> set (which stay around continuously even after the service's main
+    process exited) are usually not suitable for activation via repetitive timers, as they will only be activated
+    once, and then stay around forever. Target units, which by default do not deactivate on their own, can be
+    activated repeatedly by timers by setting <varname>StopWhenUnneeded=yes</varname> on them. This will cause a
+    target unit to be stopped immediately after its activation, if it is not a dependency of another running unit.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Automatic Dependencies</title>
+
+    <refsect2>
+      <title>Implicit Dependencies</title>
+
+      <para>The following dependencies are implicitly added:</para>
+
+      <itemizedlist>
+        <listitem><para>Timer units automatically gain a <varname>Before=</varname>
+        dependency on the service they are supposed to activate.</para></listitem>
+      </itemizedlist>
+    </refsect2>
+
+    <refsect2>
+      <title>Default Dependencies</title>
+
+      <para>The following dependencies are added unless <varname>DefaultDependencies=no</varname> is set:</para>
+
+      <itemizedlist>
+        <listitem><para>Timer units will automatically have dependencies of type <varname>Requires=</varname> and
+        <varname>After=</varname> on <filename>sysinit.target</filename>, a dependency of type <varname>Before=</varname>
+        on <filename>timers.target</filename>, as well as <varname>Conflicts=</varname> and <varname>Before=</varname> on
+        <filename>shutdown.target</filename> to ensure that they are stopped cleanly prior to system shutdown. Only timer
+        units involved with early boot or late system shutdown should disable the
+        <varname>DefaultDependencies=</varname> option.</para></listitem>
+
+        <listitem><para>Timer units with at least one <varname>OnCalendar=</varname> directive acquire a pair
+        of additional <varname>After=</varname> dependencies on <filename>time-set.target</filename> and
+        <filename>time-sync.target</filename>, in order to avoid being started before the system clock has
+        been correctly set. See
+        <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+        for details on these two targets.</para></listitem>
+      </itemizedlist>
+    </refsect2>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>Timer unit files may include [Unit] and [Install] sections, which are described in
+    <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+    </para>
+
+    <para>Timer unit files must include a [Timer] section, which carries
+    information about the timer it defines. The options specific to
+    the [Timer] section of timer units are the following:</para>
+
+    <variablelist class='unit-directives'>
+      <varlistentry>
+        <term><varname>OnActiveSec=</varname></term>
+        <term><varname>OnBootSec=</varname></term>
+        <term><varname>OnStartupSec=</varname></term>
+        <term><varname>OnUnitActiveSec=</varname></term>
+        <term><varname>OnUnitInactiveSec=</varname></term>
+
+        <listitem><para>Defines monotonic timers relative to different
+        starting points:</para>
+
+        <table>
+          <title>Settings and their starting points</title>
+
+          <tgroup cols='2'>
+            <thead>
+              <row>
+                <entry>Setting</entry>
+                <entry>Meaning</entry>
+              </row>
+            </thead>
+            <tbody>
+              <row>
+                <entry><varname>OnActiveSec=</varname></entry>
+                <entry>Defines a timer relative to the moment the timer unit itself is activated.</entry>
+              </row>
+              <row>
+                <entry><varname>OnBootSec=</varname></entry>
+                <entry>Defines a timer relative to when the machine was booted up. In containers, for the system manager instance, this is mapped to <varname>OnStartupSec=</varname>, making both equivalent.</entry>
+              </row>
+              <row>
+                <entry><varname>OnStartupSec=</varname></entry>
+                <entry>Defines a timer relative to when the service manager was first started. For system timer units this is very similar to <varname>OnBootSec=</varname> as the system service manager is generally started very early at boot. It's primarily useful when configured in units running in the per-user service manager, as the user service manager is generally started on first login only, not already during boot.</entry>
+              </row>
+              <row>
+                <entry><varname>OnUnitActiveSec=</varname></entry>
+                <entry>Defines a timer relative to when the unit the timer unit is activating was last activated.</entry>
+              </row>
+              <row>
+                <entry><varname>OnUnitInactiveSec=</varname></entry>
+                <entry>Defines a timer relative to when the unit the timer unit is activating was last deactivated.</entry>
+              </row>
+            </tbody>
+          </tgroup>
+        </table>
+
+        <para>Multiple directives may be combined of the same and of different types, in which case the timer
+        unit will trigger whenever any of the specified timer expressions elapse. For example, by combining
+        <varname>OnBootSec=</varname> and <varname>OnUnitActiveSec=</varname>, it is possible to define a
+        timer that elapses in regular intervals and activates a specific service each time. Moreover, both
+        monotonic time expressions and <varname>OnCalendar=</varname> calendar expressions may be combined in
+        the same timer unit.</para>
+
+        <para>The arguments to the directives are time spans
+        configured in seconds. Example: "OnBootSec=50" means 50s after
+        boot-up. The argument may also include time units. Example:
+        "OnBootSec=5h 30min" means 5 hours and 30 minutes after
+        boot-up. For details about the syntax of time spans, see
+        <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
+
+        <para>If a timer configured with <varname>OnBootSec=</varname>
+        or <varname>OnStartupSec=</varname> is already in the past
+        when the timer unit is activated, it will immediately elapse
+        and the configured unit is started. This is not the case for
+        timers defined in the other directives.</para>
+
+        <para>These are monotonic timers, independent of wall-clock time and timezones. If the computer is
+        temporarily suspended, the monotonic clock generally pauses, too. Note that if
+        <varname>WakeSystem=</varname> is used, a different monotonic clock is selected that continues to
+        advance while the system is suspended and thus can be used as the trigger to resume the
+        system.</para>
+
+        <para>If the empty string is assigned to any of these options, the list of timers is reset (both
+        monotonic timers and <varname>OnCalendar=</varname> timers, see below), and all prior assignments
+        will have no effect.</para>
+
+        <para>Note that timers do not necessarily expire at the
+        precise time configured with these settings, as they are
+        subject to the <varname>AccuracySec=</varname> setting
+        below.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>OnCalendar=</varname></term>
+
+        <listitem><para>Defines realtime (i.e. wallclock) timers with calendar event expressions. See
+        <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
+        more information on the syntax of calendar event expressions. Otherwise, the semantics are similar to
+        <varname>OnActiveSec=</varname> and related settings.</para>
+
+        <para>Note that timers do not necessarily expire at the precise time configured with this setting, as
+        it is subject to the <varname>AccuracySec=</varname> setting below.</para>
+
+        <para>May be specified more than once, in which case the timer unit will trigger whenever any of the
+        specified expressions elapse. Moreover calendar timers and monotonic timers (see above) may be
+        combined within the same timer unit.</para>
+
+        <para>If the empty string is assigned to any of these options, the list of timers is reset (both
+        <varname>OnCalendar=</varname> timers and monotonic timers, see above), and all prior assignments
+        will have no effect.</para>
+
+        <para>Note that calendar timers might be triggered at unexpected times if the system's realtime clock
+        is not set correctly. Specifically, on systems that lack a battery-buffered Realtime Clock (RTC) it
+        might be wise to enable <filename>systemd-time-wait-sync.service</filename> to ensure the clock is
+        adjusted to a network time source <emphasis>before</emphasis> the timer event is set up. Timer units
+        with at least one <varname>OnCalendar=</varname> expression are automatically ordered after
+        <filename>time-sync.target</filename>, which <filename>systemd-time-wait-sync.service</filename> is
+        ordered before.</para>
+
+        <para>When a system is temporarily put to sleep (i.e. system suspend or hibernation) the realtime
+        clock does not pause. When a calendar timer elapses while the system is sleeping it will not be acted
+        on immediately, but once the system is later resumed it will catch up and process all timers that
+        triggered while the system was sleeping. Note that if a calendar timer elapsed more than once while
+        the system was continuously sleeping the timer will only result in a single service activation. If
+        <varname>WakeSystem=</varname> (see below) is enabled a calendar time event elapsing while the system
+        is suspended will cause the system to wake up (under the condition the system's hardware supports
+        time-triggered wake-up functionality).</para>
+
+        <xi:include href="version-info.xml" xpointer="v197"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>AccuracySec=</varname></term>
+
+        <listitem><para>Specify the accuracy the timer shall elapse
+        with. Defaults to 1min. The timer is scheduled to elapse
+        within a time window starting with the time specified in
+        <varname>OnCalendar=</varname>,
+        <varname>OnActiveSec=</varname>,
+        <varname>OnBootSec=</varname>,
+        <varname>OnStartupSec=</varname>,
+        <varname>OnUnitActiveSec=</varname> or
+        <varname>OnUnitInactiveSec=</varname> and ending the time
+        configured with <varname>AccuracySec=</varname> later. Within
+        this time window, the expiry time will be placed at a
+        host-specific, randomized, but stable position that is
+        synchronized between all local timer units. This is done in
+        order to optimize power consumption to suppress unnecessary
+        CPU wake-ups. To get best accuracy, set this option to
+        1us. Note that the timer is still subject to the timer slack
+        configured via
+        <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>'s
+        <varname>TimerSlackNSec=</varname> setting. See
+        <citerefentry><refentrytitle>prctl</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+        for details. To optimize power consumption, make sure to set
+        this value as high as possible and as low as
+        necessary.</para>
+
+        <para>Note that this setting is primarily a power saving option that allows coalescing CPU
+        wake-ups. It should not be confused with <varname>RandomizedDelaySec=</varname> (see below) which
+        adds a random value to the time the timer shall elapse next and whose purpose is the opposite: to
+        stretch elapsing of timer events over a longer period to reduce workload spikes. For further details
+        and explanations and how both settings play together, see below.</para>
+
+        <xi:include href="version-info.xml" xpointer="v209"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RandomizedDelaySec=</varname></term>
+
+        <listitem><para>Delay the timer by a randomly selected, evenly distributed amount of time between 0
+        and the specified time value. Defaults to 0, indicating that no randomized delay shall be applied.
+        Each timer unit will determine this delay randomly before each iteration, and the delay will simply
+        be added on top of the next determined elapsing time, unless modified with
+        <varname>FixedRandomDelay=</varname>, see below.</para>
+
+        <para>This setting is useful to stretch dispatching of similarly configured timer events over a
+        certain time interval, to prevent them from firing all at the same time, possibly resulting in
+        resource congestion.</para>
+
+        <para>Note the relation to <varname>AccuracySec=</varname> above: the latter allows the service
+        manager to coalesce timer events within a specified time range in order to minimize wakeups, while
+        this setting does the opposite: it stretches timer events over an interval, to make it unlikely that
+        they fire simultaneously. If <varname>RandomizedDelaySec=</varname> and
+        <varname>AccuracySec=</varname> are used in conjunction, first the randomized delay is added, and
+        then the result is possibly further shifted to coalesce it with other timer events happening on the
+        system. As mentioned above <varname>AccuracySec=</varname> defaults to 1 minute and
+        <varname>RandomizedDelaySec=</varname> to 0, thus encouraging coalescing of timer events. In order to
+        optimally stretch timer events over a certain range of time, set
+        <varname>AccuracySec=1us</varname> and <varname>RandomizedDelaySec=</varname> to some higher value.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v229"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>FixedRandomDelay=</varname></term>
+
+        <listitem><para>Takes a boolean argument. When enabled, the randomized offset specified by
+        <varname>RandomizedDelaySec=</varname> is reused for all firings of the same timer. For a given timer
+        unit, the offset depends on the machine ID, user identifier and timer name, which means that it is
+        stable between restarts of the manager. This effectively creates a fixed offset for an individual
+        timer, reducing the jitter in firings of this timer, while still avoiding firing at the same time as
+        other similarly configured timers.</para>
+
+        <para>This setting has no effect if <varname>RandomizedDelaySec=</varname> is set to 0. Defaults to
+        <option>false</option>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v247"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>OnClockChange=</varname></term>
+        <term><varname>OnTimezoneChange=</varname></term>
+
+        <listitem><para>These options take boolean arguments. When true, the service unit will be triggered
+        when the system clock (<constant>CLOCK_REALTIME</constant>) jumps relative to the monotonic clock
+        (<constant>CLOCK_MONOTONIC</constant>), or when the local system timezone is modified. These options
+        can be used alone or in combination with other timer expressions (see above) within the same timer
+        unit. These options default to <option>false</option>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v242"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Unit=</varname></term>
+
+        <listitem><para>The unit to activate when this timer elapses.
+        The argument is a unit name, whose suffix is not
+        <literal>.timer</literal>. If not specified, this value
+        defaults to a service that has the same name as the timer
+        unit, except for the suffix. (See above.) It is recommended
+        that the unit name that is activated and the unit name of the
+        timer unit are named identically, except for the
+        suffix.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Persistent=</varname></term>
+
+        <listitem><para>Takes a boolean argument. If true, the time when the service unit was last triggered
+        is stored on disk.  When the timer is activated, the service unit is triggered immediately if it
+        would have been triggered at least once during the time when the timer was inactive. Such triggering
+        is nonetheless subject to the delay imposed by <varname>RandomizedDelaySec=</varname>.
+        This is useful to catch up on missed runs of the service when the system was powered down. Note that
+        this setting only has an effect on timers configured with <varname>OnCalendar=</varname>. Defaults to
+        <option>false</option>.</para>
+
+        <para>Use <command>systemctl clean --what=state …</command> on the timer unit to remove the timestamp
+        file maintained by this option from disk. In particular, use this command before uninstalling a timer
+        unit. See
+        <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> for
+        details.</para>
+
+        <xi:include href="version-info.xml" xpointer="v212"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>WakeSystem=</varname></term>
+
+        <listitem><para>Takes a boolean argument. If true, an elapsing timer will cause the system to resume
+        from suspend, should it be suspended and if the system supports this. Note that this option will only
+        make sure the system resumes on the appropriate times, it will not take care of suspending it again
+        after any work that is to be done is finished. Defaults to
+        <option>false</option>.</para>
+
+        <para>Note that this functionality requires privileges and is thus generally only available in the
+        system service manager.</para>
+
+        <para>Note that behaviour of monotonic clock timers (as configured with
+        <varname>OnActiveSec=</varname>, <varname>OnBootSec=</varname>, <varname>OnStartupSec=</varname>,
+        <varname>OnUnitActiveSec=</varname>, <varname>OnUnitInactiveSec=</varname>, see above) is altered
+        depending on this option. If false, a monotonic clock is used that is paused during system suspend
+        (<constant>CLOCK_MONOTONIC</constant>), if true a different monotonic clock is used that continues
+        advancing during system suspend (<constant>CLOCK_BOOTTIME</constant>), see
+        <citerefentry><refentrytitle>clock_getres</refentrytitle><manvolnum>2</manvolnum></citerefentry> for
+        details.</para>
+
+        <xi:include href="version-info.xml" xpointer="v212"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RemainAfterElapse=</varname></term>
+
+        <listitem><para>Takes a boolean argument. If true, a timer will stay loaded, and its state remains
+        queryable even after it elapsed and the associated unit (as configured with <varname>Unit=</varname>,
+        see above) deactivated again. If false, an elapsed timer unit that cannot elapse anymore is unloaded
+        once its associated unit deactivated again. Turning this off is particularly useful for transient
+        timer units. Note that this setting has an effect when repeatedly starting a timer unit: if
+        <varname>RemainAfterElapse=</varname> is on, starting the timer a second time has no effect. However,
+        if <varname>RemainAfterElapse=</varname> is off and the timer unit was already unloaded, it can be
+        started again, and thus the service can be triggered multiple times. Defaults to
+        <option>true</option>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v229"/></listitem>
+      </varlistentry>
+    </variablelist>
+
+    <xi:include href="systemd.service.xml" xpointer="shared-unit-options" />
+  </refsect1>
+
+  <refsect1>
+      <title>See Also</title>
+      <para>Environment variables with details on the trigger will be set for triggered units. See the
+      <literal>Environment Variables Set or Propagated by the Service Manager</literal> section in
+      <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+      for more details.</para>
+      <para>
+        <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>prctl</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+      </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd.unit.xml b/man/systemd.unit.xml
new file mode 100644
index 0000000..301fe77
--- /dev/null
+++ b/man/systemd.unit.xml
@@ -0,0 +1,2656 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [
+<!ENTITY % entities SYSTEM "custom-entities.ent" >
+%entities;
+]>
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd.unit"
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd.unit</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd.unit</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd.unit</refname>
+    <refpurpose>Unit configuration</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename><replaceable>service</replaceable>.service</filename>,
+    <filename><replaceable>socket</replaceable>.socket</filename>,
+    <filename><replaceable>device</replaceable>.device</filename>,
+    <filename><replaceable>mount</replaceable>.mount</filename>,
+    <filename><replaceable>automount</replaceable>.automount</filename>,
+    <filename><replaceable>swap</replaceable>.swap</filename>,
+    <filename><replaceable>target</replaceable>.target</filename>,
+    <filename><replaceable>path</replaceable>.path</filename>,
+    <filename><replaceable>timer</replaceable>.timer</filename>,
+    <filename><replaceable>slice</replaceable>.slice</filename>,
+    <filename><replaceable>scope</replaceable>.scope</filename></para>
+
+    <refsect2>
+      <title>System Unit Search Path</title>
+
+      <para><literallayout><filename>/etc/systemd/system.control/*</filename>
+<filename>/run/systemd/system.control/*</filename>
+<filename>/run/systemd/transient/*</filename>
+<filename>/run/systemd/generator.early/*</filename>
+<filename>/etc/systemd/system/*</filename>
+<filename>/etc/systemd/system.attached/*</filename>
+<filename>/run/systemd/system/*</filename>
+<filename>/run/systemd/system.attached/*</filename>
+<filename>/run/systemd/generator/*</filename>
+<filename index='false'>…</filename>
+<filename>/usr/lib/systemd/system/*</filename>
+<filename>/run/systemd/generator.late/*</filename></literallayout></para>
+    </refsect2>
+
+    <refsect2>
+      <title>User Unit Search Path</title>
+      <para><literallayout><filename>~/.config/systemd/user.control/*</filename>
+<filename>$XDG_RUNTIME_DIR/systemd/user.control/*</filename>
+<filename>$XDG_RUNTIME_DIR/systemd/transient/*</filename>
+<filename>$XDG_RUNTIME_DIR/systemd/generator.early/*</filename>
+<filename>~/.config/systemd/user/*</filename>
+<filename>$XDG_CONFIG_DIRS/systemd/user/*</filename>
+<filename>/etc/systemd/user/*</filename>
+<filename>$XDG_RUNTIME_DIR/systemd/user/*</filename>
+<filename>/run/systemd/user/*</filename>
+<filename>$XDG_RUNTIME_DIR/systemd/generator/*</filename>
+<filename>$XDG_DATA_HOME/systemd/user/*</filename>
+<filename>$XDG_DATA_DIRS/systemd/user/*</filename>
+<filename index='false'>…</filename>
+<filename>/usr/lib/systemd/user/*</filename>
+<filename>$XDG_RUNTIME_DIR/systemd/generator.late/*</filename></literallayout></para>
+    </refsect2>
+
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>A unit file is a plain text ini-style file that encodes information about a service, a
+    socket, a device, a mount point, an automount point, a swap file or partition, a start-up
+    target, a watched file system path, a timer controlled and supervised by
+    <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>, a
+    resource management slice or a group of externally created processes. See
+    <citerefentry><refentrytitle>systemd.syntax</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+    for a general description of the syntax.</para>
+
+    <para>This man page lists the common configuration options of all
+    the unit types. These options need to be configured in the [Unit]
+    or [Install] sections of the unit files.</para>
+
+    <para>In addition to the generic [Unit] and [Install] sections
+    described here, each unit may have a type-specific section, e.g.
+    [Service] for a service unit. See the respective man pages for
+    more information:
+    <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>systemd.device</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>systemd.automount</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>systemd.swap</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>systemd.path</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>systemd.scope</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+    </para>
+
+    <para>Unit files are loaded from a set of paths determined during compilation, described in the next
+    section.</para>
+
+    <para>Valid unit names consist of a "unit name prefix", and a suffix specifying the unit type which
+    begins with a dot. The "unit name prefix" must consist of one or more valid characters (ASCII letters,
+    digits, <literal>:</literal>, <literal>-</literal>, <literal>_</literal>, <literal>.</literal>, and
+    <literal>\</literal>). The total length of the unit name including the suffix must not exceed 255
+    characters. The unit type suffix must be one of <literal>.service</literal>, <literal>.socket</literal>,
+    <literal>.device</literal>, <literal>.mount</literal>, <literal>.automount</literal>,
+    <literal>.swap</literal>, <literal>.target</literal>, <literal>.path</literal>,
+    <literal>.timer</literal>, <literal>.slice</literal>, or <literal>.scope</literal>.</para>
+
+    <para>Unit names can be parameterized by a single argument called the "instance name". The unit is then
+    constructed based on a "template file" which serves as the definition of multiple services or other
+    units. A template unit must have a single <literal>@</literal> at the end of the unit name prefix (right
+    before the type suffix). The name of the full unit is formed by inserting the instance name between
+    <literal>@</literal> and the unit type suffix. In the unit file itself, the instance parameter may be
+    referred to using <literal>%i</literal> and other specifiers, see below.</para>
+
+    <para>Unit files may contain additional options on top of those listed here. If systemd encounters an
+    unknown option, it will write a warning log message but continue loading the unit. If an option or
+    section name is prefixed with <option>X-</option>, it is ignored completely by systemd. Options within an
+    ignored section do not need the prefix. Applications may use this to include additional information in
+    the unit files. To access those options, applications need to parse the unit files on their own.</para>
+
+    <para>Units can be aliased (have an alternative name), by creating a symlink from the new name to the
+    existing name in one of the unit search paths. For example, <filename>systemd-networkd.service</filename>
+    has the alias <filename>dbus-org.freedesktop.network1.service</filename>, created during installation as
+    a symlink, so when <command>systemd</command> is asked through D-Bus to load
+    <filename>dbus-org.freedesktop.network1.service</filename>, it'll load
+    <filename>systemd-networkd.service</filename>. As another example, <filename>default.target</filename> —
+    the default system target started at boot — is commonly aliased to either
+    <filename>multi-user.target</filename> or <filename>graphical.target</filename> to select what is started
+    by default. Alias names may be used in commands like <command>disable</command>,
+    <command>start</command>, <command>stop</command>, <command>status</command>, and similar, and in all
+    unit dependency directives, including <varname>Wants=</varname>, <varname>Requires=</varname>,
+    <varname>Before=</varname>, <varname>After=</varname>. Aliases cannot be used with the
+    <command>preset</command> command.</para>
+
+    <para>Aliases obey the following restrictions: a unit of a certain type (<literal>.service</literal>,
+    <literal>.socket</literal>, …) can only be aliased by a name with the same type suffix. A plain unit (not
+    a template or an instance), may only be aliased by a plain name. A template instance may only be aliased
+    by another template instance, and the instance part must be identical. A template may be aliased by
+    another template (in which case the alias applies to all instances of the template). As a special case, a
+    template instance (e.g. <literal>alias@inst.service</literal>) may be a symlink to different template
+    (e.g. <literal>template@inst.service</literal>). In that case, just this specific instance is aliased,
+    while other instances of the template (e.g. <literal>alias@foo.service</literal>,
+    <literal>alias@bar.service</literal>) are not aliased. Those rules preserve the requirement that the
+    instance (if any) is always uniquely defined for a given unit and all its aliases. The target of alias
+    symlink must point to a valid unit file location, i.e. the symlink target name must match the symlink
+    source name as described, and the destination path must be in one of the unit search paths, see UNIT FILE
+    LOAD PATH section below for more details. Note that the target file may not exist, i.e. the symlink may
+    be dangling.</para>
+
+    <para>Unit files may specify aliases through the <varname>Alias=</varname> directive in the [Install]
+    section. When the unit is enabled, symlinks will be created for those names, and removed when the unit is
+    disabled. For example, <filename>reboot.target</filename> specifies
+    <varname>Alias=ctrl-alt-del.target</varname>, so when enabled, the symlink
+    <filename>/etc/systemd/system/ctrl-alt-del.service</filename> pointing to the
+    <filename>reboot.target</filename> file will be created, and when
+    <keycombo><keycap>Ctrl</keycap><keycap>Alt</keycap><keycap>Del</keycap></keycombo> is invoked,
+    <command>systemd</command> will look for the <filename>ctrl-alt-del.service</filename> and execute
+    <filename>reboot.service</filename>. <command>systemd</command> does not look at the [Install] section at
+    all during normal operation, so any directives in that section only have an effect through the symlinks
+    created during enablement.</para>
+
+    <para>Along with a unit file <filename>foo.service</filename>, the directory
+    <filename>foo.service.wants/</filename> may exist. All unit files symlinked from such a directory are
+    implicitly added as dependencies of type <varname>Wants=</varname> to the unit. Similar functionality
+    exists for <varname>Requires=</varname> type dependencies as well, the directory suffix is
+    <filename>.requires/</filename> in this case. This functionality is useful to hook units into the
+    start-up of other units, without having to modify their unit files. For details about the semantics of
+    <varname>Wants=</varname> and <varname>Requires=</varname>, see below. The preferred way to create
+    symlinks in the <filename>.wants/</filename> or <filename>.requires/</filename> directories is by
+    specifying the dependency in [Install] section of the target unit, and creating the symlink in the file
+    system with the <command>enable</command> or <command>preset</command> commands of
+    <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>.  The
+    target can be a normal unit (either plain or a specific instance of a template unit). In case when the
+    source unit is a template, the target can also be a template, in which case the instance will be
+    "propagated" to the target unit to form a valid unit instance. The target of symlinks in
+    <filename>.wants/</filename> or <filename>.requires/</filename> must thus point to a valid unit file
+    location, i.e. the symlink target name must satisfy the described requirements, and the destination path
+    must be in one of the unit search paths, see UNIT FILE LOAD PATH section below for more details. Note
+    that the target file may not exist, i.e. the symlink may be dangling.</para>
+
+    <para>Along with a unit file <filename>foo.service</filename>, a "drop-in" directory
+    <filename>foo.service.d/</filename> may exist. All files with the suffix
+    <literal>.conf</literal> from this directory will be merged in the alphanumeric order and parsed
+    after the main unit file itself has been parsed. This is useful to alter or add configuration
+    settings for a unit, without having to modify unit files. Each drop-in file must contain appropriate
+    section headers. For instantiated units, this logic will first look for the instance
+    <literal>.d/</literal> subdirectory (e.g. <literal>foo@bar.service.d/</literal>) and read its
+    <literal>.conf</literal> files, followed by the template <literal>.d/</literal> subdirectory (e.g.
+    <literal>foo@.service.d/</literal>) and the <literal>.conf</literal> files there. Moreover for unit
+    names containing dashes (<literal>-</literal>), the set of directories generated by repeatedly
+    truncating the unit name after all dashes is searched too. Specifically, for a unit name
+    <filename>foo-bar-baz.service</filename> not only the regular drop-in directory
+    <filename>foo-bar-baz.service.d/</filename> is searched but also both <filename>foo-bar-.service.d/</filename> and
+    <filename>foo-.service.d/</filename>. This is useful for defining common drop-ins for a set of related units, whose
+    names begin with a common prefix. This scheme is particularly useful for mount, automount and slice units, whose
+    systematic naming structure is built around dashes as component separators. Note that equally named drop-in files
+    further down the prefix hierarchy override those further up,
+    i.e. <filename>foo-bar-.service.d/10-override.conf</filename> overrides
+    <filename>foo-.service.d/10-override.conf</filename>.</para>
+
+    <para>In cases of unit aliases (described above), dropins for the aliased name and all aliases are
+    loaded. In the example of <filename>default.target</filename> aliasing
+    <filename>graphical.target</filename>, <filename>default.target.d/</filename>,
+    <filename>default.target.wants/</filename>, <filename>default.target.requires/</filename>,
+    <filename>graphical.target.d/</filename>, <filename>graphical.target.wants/</filename>,
+    <filename>graphical.target.requires/</filename> would all be read. For templates, dropins for the
+    template, any template aliases, the template instance, and all alias instances are read. When just a
+    specific template instance is aliased, then the dropins for the target template, the target template
+    instance, and the alias template instance are read.</para>
+
+    <para>In addition to <filename>/etc/systemd/system</filename>, the drop-in <literal>.d/</literal>
+    directories for system services can be placed in <filename>/usr/lib/systemd/system</filename> or
+    <filename>/run/systemd/system</filename> directories. Drop-in files in <filename>/etc/</filename>
+    take precedence over those in <filename>/run/</filename> which in turn take precedence over those
+    in <filename>/usr/lib/</filename>. Drop-in files under any of these directories take precedence
+    over unit files wherever located. Multiple drop-in files with different names are applied in
+    lexicographic order, regardless of which of the directories they reside in.</para>
+
+    <para>Units also support a top-level drop-in with <filename><replaceable>type</replaceable>.d/</filename>,
+    where <replaceable>type</replaceable> may be e.g. <literal>service</literal> or <literal>socket</literal>,
+    that allows altering or adding to the settings of all corresponding unit files on the system.
+    The formatting and precedence of applying drop-in configurations follow what is defined above.
+    Files in <filename><replaceable>type</replaceable>.d/</filename> have lower precedence compared
+    to files in name-specific override directories. The usual rules apply: multiple drop-in files
+    with different names are applied in lexicographic order, regardless of which of the directories
+    they reside in, so a file in <filename><replaceable>type</replaceable>.d/</filename> applies
+    to a unit only if there are no drop-ins or masks with that name in directories with higher
+    precedence. See Examples.</para>
+
+    <para>Note that while systemd offers a flexible dependency system
+    between units it is recommended to use this functionality only
+    sparingly and instead rely on techniques such as bus-based or
+    socket-based activation which make dependencies implicit,
+    resulting in a both simpler and more flexible system.</para>
+
+    <para>As mentioned above, a unit may be instantiated from a template file. This allows creation
+    of multiple units from a single configuration file. If systemd looks for a unit configuration
+    file, it will first search for the literal unit name in the file system. If that yields no
+    success and the unit name contains an <literal>@</literal> character, systemd will look for a
+    unit template that shares the same name but with the instance string (i.e. the part between the
+    <literal>@</literal> character and the suffix) removed. Example: if a service
+    <filename>getty@tty3.service</filename> is requested and no file by that name is found, systemd
+    will look for <filename>getty@.service</filename> and instantiate a service from that
+    configuration file if it is found.</para>
+
+    <para>To refer to the instance string from within the
+    configuration file you may use the special <literal>%i</literal>
+    specifier in many of the configuration options. See below for
+    details.</para>
+
+    <para>If a unit file is empty (i.e. has the file size 0) or is
+    symlinked to <filename>/dev/null</filename>, its configuration
+    will not be loaded and it appears with a load state of
+    <literal>masked</literal>, and cannot be activated. Use this as an
+    effective way to fully disable a unit, making it impossible to
+    start it even manually.</para>
+
+    <para>The unit file format is covered by the
+    <ulink url="https://systemd.io/PORTABILITY_AND_STABILITY/">Interface
+    Portability and Stability Promise</ulink>.</para>
+
+  </refsect1>
+
+  <refsect1>
+    <title>String Escaping for Inclusion in Unit Names</title>
+
+    <para>Sometimes it is useful to convert arbitrary strings into unit names. To facilitate this, a method of string
+    escaping is used, in order to map strings containing arbitrary byte values (except <constant>NUL</constant>) into
+    valid unit names and their restricted character set. A common special case are unit names that reflect paths to
+    objects in the file system hierarchy. Example: a device unit <filename>dev-sda.device</filename> refers to a device
+    with the device node <filename index="false">/dev/sda</filename> in the file system.</para>
+
+    <para>The escaping algorithm operates as follows: given a string, any <literal>/</literal> character is
+    replaced by <literal>-</literal>, and all other characters which are not ASCII alphanumerics,
+    <literal>:</literal>, <literal>_</literal> or <literal>.</literal> are replaced by C-style
+    <literal>\x2d</literal> escapes. In addition, <literal>.</literal> is replaced with such a C-style escape
+    when it would appear as the first character in the escaped string.</para>
+
+    <para>When the input qualifies as absolute file system path, this algorithm is extended slightly: the path to the
+    root directory <literal>/</literal> is encoded as single dash <literal>-</literal>. In addition, any leading,
+    trailing or duplicate <literal>/</literal> characters are removed from the string before transformation. Example:
+    <filename index="false">/foo//bar/baz/</filename> becomes <literal>foo-bar-baz</literal>.</para>
+
+    <para>This escaping is fully reversible, as long as it is known whether the escaped string was a path (the
+    unescaping results are different for paths and non-path strings). The
+    <citerefentry><refentrytitle>systemd-escape</refentrytitle><manvolnum>1</manvolnum></citerefentry> command may be
+    used to apply and reverse escaping on arbitrary strings. Use <command>systemd-escape --path</command> to escape
+    path strings, and <command>systemd-escape</command> without <option>--path</option> otherwise.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Automatic dependencies</title>
+
+    <refsect2>
+      <title>Implicit Dependencies</title>
+
+      <para>A number of unit dependencies are implicitly established, depending on unit type and
+      unit configuration. These implicit dependencies can make unit configuration file cleaner. For
+      the implicit dependencies in each unit type, please refer to section "Implicit Dependencies"
+      in respective man pages.</para>
+
+      <para>For example, service units with <varname>Type=dbus</varname> automatically acquire
+      dependencies of type <varname>Requires=</varname> and <varname>After=</varname> on
+      <filename>dbus.socket</filename>. See
+      <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+      for details.</para>
+    </refsect2>
+
+    <refsect2>
+      <title>Default Dependencies</title>
+
+      <para>Default dependencies are similar to implicit dependencies, but can be turned on and off
+      by setting <varname>DefaultDependencies=</varname> to <varname>yes</varname> (the default) and
+      <varname>no</varname>, while implicit dependencies are always in effect. See section "Default
+      Dependencies" in respective man pages for the effect of enabling
+      <varname>DefaultDependencies=</varname> in each unit types.</para>
+
+      <para>For example, target units will complement all configured dependencies of type
+      <varname>Wants=</varname> or <varname>Requires=</varname> with dependencies of type
+      <varname>After=</varname>. See
+      <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+      for details. Note that this behavior can be opted out by setting
+      <varname>DefaultDependencies=no</varname> in the specified units, or it can be selectively
+      overridden via an explicit <varname>Before=</varname> dependency.</para>
+    </refsect2>
+  </refsect1>
+
+  <refsect1>
+    <title>Unit File Load Path</title>
+
+    <para>Unit files are loaded from a set of paths determined during
+    compilation, described in the two tables below. Unit files found
+    in directories listed earlier override files with the same name in
+    directories lower in the list.</para>
+
+    <para>When the variable <varname>$SYSTEMD_UNIT_PATH</varname> is set,
+    the contents of this variable overrides the unit load path. If
+    <varname>$SYSTEMD_UNIT_PATH</varname> ends with an empty component
+    (<literal>:</literal>), the usual unit load path will be appended
+    to the contents of the variable.</para>
+
+    <table>
+      <title>
+        Load path when running in system mode (<option>--system</option>).
+      </title>
+
+      <tgroup cols='2'>
+        <colspec colname='path' />
+        <colspec colname='expl' />
+        <thead>
+          <row>
+            <entry>Path</entry>
+            <entry>Description</entry>
+          </row>
+        </thead>
+        <tbody>
+          <row>
+            <entry><filename>/etc/systemd/system.control</filename></entry>
+            <entry morerows="1">Persistent and transient configuration created using the dbus API</entry>
+          </row>
+          <row>
+            <entry><filename>/run/systemd/system.control</filename></entry>
+          </row>
+          <row>
+            <entry><filename>/run/systemd/transient</filename></entry>
+            <entry>Dynamic configuration for transient units</entry>
+          </row>
+          <row>
+            <entry><filename>/run/systemd/generator.early</filename></entry>
+            <entry>Generated units with high priority (see <replaceable>early-dir</replaceable> in <citerefentry
+            ><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>)</entry>
+          </row>
+          <row>
+            <entry><filename>/etc/systemd/system</filename></entry>
+            <entry>System units created by the administrator</entry>
+          </row>
+          <row>
+            <entry><filename>/run/systemd/system</filename></entry>
+            <entry>Runtime units</entry>
+          </row>
+          <row>
+            <entry><filename>/run/systemd/generator</filename></entry>
+            <entry>Generated units with medium priority (see <replaceable>normal-dir</replaceable> in <citerefentry
+            ><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>)</entry>
+          </row>
+          <row>
+            <entry><filename>/usr/local/lib/systemd/system</filename></entry>
+            <entry>System units installed by the administrator </entry>
+          </row>
+          <row>
+            <entry><filename>/usr/lib/systemd/system</filename></entry>
+            <entry>System units installed by the distribution package manager</entry>
+          </row>
+          <row>
+            <entry><filename>/run/systemd/generator.late</filename></entry>
+            <entry>Generated units with low priority (see <replaceable>late-dir</replaceable> in <citerefentry
+            ><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>)</entry>
+          </row>
+        </tbody>
+      </tgroup>
+    </table>
+
+    <table>
+      <title>
+        Load path when running in user mode (<option>--user</option>).
+      </title>
+
+      <tgroup cols='2'>
+        <colspec colname='path' />
+        <colspec colname='expl' />
+        <thead>
+          <row>
+            <entry>Path</entry>
+            <entry>Description</entry>
+          </row>
+        </thead>
+        <tbody>
+          <row>
+            <entry><filename>$XDG_CONFIG_HOME/systemd/user.control</filename> or <filename
+            >~/.config/systemd/user.control</filename></entry>
+            <entry morerows="1">Persistent and transient configuration created using the dbus API (<varname>$XDG_CONFIG_HOME</varname> is used if set, <filename>~/.config</filename> otherwise)</entry>
+          </row>
+          <row>
+            <entry><filename>$XDG_RUNTIME_DIR/systemd/user.control</filename></entry>
+          </row>
+          <row>
+            <entry><filename>$XDG_RUNTIME_DIR/systemd/transient</filename></entry>
+            <entry>Dynamic configuration for transient units</entry>
+          </row>
+          <row>
+            <entry><filename>$XDG_RUNTIME_DIR/systemd/generator.early</filename></entry>
+            <entry>Generated units with high priority (see <replaceable>early-dir</replaceable> in <citerefentry
+            ><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>)</entry>
+          </row>
+          <row>
+            <entry><filename>$XDG_CONFIG_HOME/systemd/user</filename> or <filename>$HOME/.config/systemd/user</filename></entry>
+            <entry>User configuration (<varname>$XDG_CONFIG_HOME</varname> is used if set, <filename>~/.config</filename> otherwise)</entry>
+          </row>
+          <row>
+            <entry><filename>$XDG_CONFIG_DIRS/systemd/user</filename> or <filename>/etc/xdg/systemd/user</filename></entry>
+            <entry>Additional configuration directories as specified by the XDG base directory specification (<varname>$XDG_CONFIG_DIRS</varname> is used if set, <filename>/etc/xdg</filename> otherwise)</entry>
+          </row>
+          <row>
+            <entry><filename>/etc/systemd/user</filename></entry>
+            <entry>User units created by the administrator</entry>
+          </row>
+          <row>
+            <entry><filename>$XDG_RUNTIME_DIR/systemd/user</filename></entry>
+            <entry>Runtime units (only used when $XDG_RUNTIME_DIR is set)</entry>
+          </row>
+          <row>
+            <entry><filename>/run/systemd/user</filename></entry>
+            <entry>Runtime units</entry>
+          </row>
+          <row>
+            <entry><filename>$XDG_RUNTIME_DIR/systemd/generator</filename></entry>
+            <entry>Generated units with medium priority (see <replaceable>normal-dir</replaceable> in <citerefentry
+            ><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>)</entry>
+          </row>
+          <row>
+            <entry><filename>$XDG_DATA_HOME/systemd/user</filename> or <filename>$HOME/.local/share/systemd/user</filename></entry>
+            <entry>Units of packages that have been installed in the home directory (<varname>$XDG_DATA_HOME</varname> is used if set, <filename>~/.local/share</filename> otherwise)</entry>
+          </row>
+          <row>
+            <entry><filename>$XDG_DATA_DIRS/systemd/user</filename> or <filename>/usr/local/share/systemd/user</filename> and <filename>/usr/share/systemd/user</filename></entry>
+            <entry>Additional data directories as specified by the XDG base directory specification (<varname>$XDG_DATA_DIRS</varname> is used if set, <filename>/usr/local/share</filename> and <filename>/usr/share</filename> otherwise)</entry>
+          </row>
+          <row>
+            <entry><filename>$dir/systemd/user</filename> for each <varname index="false">$dir</varname> in <varname>$XDG_DATA_DIRS</varname></entry>
+            <entry>Additional locations for installed user units, one for each entry in <varname>$XDG_DATA_DIRS</varname></entry>
+          </row>
+          <row>
+            <entry><filename>/usr/local/lib/systemd/user</filename></entry>
+            <entry>User units installed by the administrator</entry>
+          </row>
+          <row>
+            <entry><filename>/usr/lib/systemd/user</filename></entry>
+            <entry>User units installed by the distribution package manager</entry>
+          </row>
+          <row>
+            <entry><filename>$XDG_RUNTIME_DIR/systemd/generator.late</filename></entry>
+            <entry>Generated units with low priority (see <replaceable>late-dir</replaceable> in <citerefentry
+            ><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>)</entry>
+          </row>
+        </tbody>
+      </tgroup>
+    </table>
+
+    <para>The set of load paths for the user manager instance may be augmented or
+    changed using various environment variables. And environment variables may in
+    turn be set using environment generators, see
+    <citerefentry><refentrytitle>systemd.environment-generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
+    In particular, <varname>$XDG_DATA_HOME</varname> and
+    <varname>$XDG_DATA_DIRS</varname> may be easily set using
+    <citerefentry><refentrytitle>systemd-environment-d-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+    Thus, directories listed here are just the defaults. To see the actual list that
+    would be used based on compilation options and current environment use
+    <programlisting>systemd-analyze --user unit-paths</programlisting>
+    </para>
+
+    <para>Moreover, additional units might be loaded into systemd from directories not on the unit load path
+    by creating a symlink pointing to a unit file in the directories. You can use <command>systemctl
+    link</command> for this; see
+    <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>. The file
+    system where the linked unit files are located must be accessible when systemd is started (e.g. anything
+    underneath <filename>/home/</filename> or <filename>/var/</filename> is not allowed, unless those
+    directories are located on the root file system).</para>
+
+    <para>It is important to distinguish "linked unit files" from "unit file aliases": any symlink where the
+    symlink <emphasis>target</emphasis> is within the unit load path becomes an alias: the source name and
+    the target file name must satisfy specific constraints listed above in the discussion of aliases, but the
+    symlink target doesn't have to exist, and in fact the symlink target path is not used, except to check
+    whether the target is within the unit load path. In contrast, a symlink which goes outside of the unit
+    load path signifies a linked unit file. The symlink is followed when loading the file, but the
+    destination name is otherwise unused (and may even not be a valid unit file name). For example, symlinks
+    <filename index='false'>/etc/systemd/system/alias1.service</filename> → <filename index='false'>service1.service</filename>,
+    <filename index='false'>/etc/systemd/system/alias2.service</filename> → <filename index='false'>/usr/lib/systemd/service1.service</filename>,
+    <filename index='false'>/etc/systemd/system/alias3.service</filename> → <filename index='false'>/etc/systemd/system/service1.service</filename>
+    are all valid aliases and <filename index='false'>service1.service</filename> will have
+    four names, even if the unit file is located at
+    <filename index='false'>/run/systemd/system/service1.service</filename>. In contrast,
+    a symlink <filename index='false'>/etc/systemd/system/link1.service</filename> → <filename index='false'>../link1_service_file</filename>
+    means that <filename index='false'>link1.service</filename> is a "linked unit" and the contents of
+    <filename index='false'>/etc/systemd/link1_service_file</filename> provide its configuration.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Unit Garbage Collection</title>
+
+    <para>The system and service manager loads a unit's configuration automatically when a unit is referenced for the
+    first time. It will automatically unload the unit configuration and state again when the unit is not needed anymore
+    ("garbage collection"). A unit may be referenced through a number of different mechanisms:</para>
+
+    <orderedlist>
+      <listitem><para>Another loaded unit references it with a dependency such as <varname>After=</varname>,
+      <varname>Wants=</varname>, …</para></listitem>
+
+      <listitem><para>The unit is currently starting, running, reloading or stopping.</para></listitem>
+
+      <listitem><para>The unit is currently in the <constant>failed</constant> state. (But see below.)</para></listitem>
+
+      <listitem><para>A job for the unit is pending.</para></listitem>
+
+      <listitem><para>The unit is pinned by an active IPC client program.</para></listitem>
+
+      <listitem><para>The unit is a special "perpetual" unit that is always active and loaded. Examples for perpetual
+      units are the root mount unit <filename>-.mount</filename> or the scope unit <filename>init.scope</filename> that
+      the service manager itself lives in.</para></listitem>
+
+      <listitem><para>The unit has running processes associated with it.</para></listitem>
+    </orderedlist>
+
+    <para>The garbage collection logic may be altered with the <varname>CollectMode=</varname> option, which allows
+    configuration whether automatic unloading of units that are in <constant>failed</constant> state is permissible,
+    see below.</para>
+
+    <para>Note that when a unit's configuration and state is unloaded, all execution results, such as exit codes, exit
+    signals, resource consumption and other statistics are lost, except for what is stored in the log subsystem.</para>
+
+    <para>Use <command>systemctl daemon-reload</command> or an equivalent command to reload unit configuration while
+    the unit is already loaded. In this case all configuration settings are flushed out and replaced with the new
+    configuration (which however might not be in effect immediately), however all runtime state is
+    saved/restored.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>[Unit] Section Options</title>
+
+    <para>The unit file may include a [Unit] section, which carries
+    generic information about the unit that is not dependent on the
+    type of unit:</para>
+
+    <variablelist class='unit-directives'>
+      <varlistentry>
+        <term><varname>Description=</varname></term>
+        <listitem><para>A short human readable title of the unit. This may be used by
+        <command>systemd</command> (and other UIs) as a user-visible label for the unit, so this string
+        should identify the unit rather than describe it, despite the name. This string also shouldn't just
+        repeat the unit name. <literal>Apache2 Web Server</literal> is a good example. Bad examples are
+        <literal>high-performance light-weight HTTP server</literal> (too generic) or
+        <literal>Apache2</literal> (meaningless for people who do not know Apache, duplicates the unit
+        name). <command>systemd</command> may use this string as a noun in status messages (<literal>Starting
+        <replaceable>description</replaceable>...</literal>, <literal>Started
+        <replaceable>description</replaceable>.</literal>, <literal>Reached target
+        <replaceable>description</replaceable>.</literal>, <literal>Failed to start
+        <replaceable>description</replaceable>.</literal>), so it should be capitalized, and should not be a
+        full sentence, or a phrase with a continuous verb. Bad examples include <literal>exiting the
+        container</literal> or <literal>updating the database once per day.</literal>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v201"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Documentation=</varname></term>
+        <listitem><para>A space-separated list of URIs referencing
+        documentation for this unit or its configuration. Accepted are
+        only URIs of the types <literal>http://</literal>,
+        <literal>https://</literal>, <literal>file:</literal>,
+        <literal>info:</literal>, <literal>man:</literal>. For more
+        information about the syntax of these URIs, see <citerefentry
+        project='man-pages'><refentrytitle>uri</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
+        The URIs should be listed in order of relevance, starting with
+        the most relevant. It is a good idea to first reference
+        documentation that explains what the unit's purpose is,
+        followed by how it is configured, followed by any other
+        related documentation. This option may be specified more than
+        once, in which case the specified list of URIs is merged. If
+        the empty string is assigned to this option, the list is reset
+        and all prior assignments will have no
+        effect.</para>
+
+        <xi:include href="version-info.xml" xpointer="v201"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Wants=</varname></term>
+
+        <listitem><para>Configures (weak) requirement dependencies on other units. This option may be
+        specified more than once or multiple space-separated units may be specified in one option in which
+        case dependencies for all listed names will be created. Dependencies of this type may also be
+        configured outside of the unit configuration file by adding a symlink to a
+        <filename>.wants/</filename> directory accompanying the unit file. For details, see above.</para>
+
+        <para>Units listed in this option will be started if the configuring unit is. However, if the listed
+        units fail to start or cannot be added to the transaction, this has no impact on the validity of the
+        transaction as a whole, and this unit will still be started. This is the recommended way to hook
+        the start-up of one unit to the start-up of another unit.</para>
+
+        <para>Note that requirement dependencies do not influence the order in which services are started or
+        stopped. This has to be configured independently with the <varname>After=</varname> or
+        <varname>Before=</varname> options. If unit <filename>foo.service</filename> pulls in unit
+        <filename>bar.service</filename> as configured with <varname>Wants=</varname> and no ordering is
+        configured with <varname>After=</varname> or <varname>Before=</varname>, then both units will be
+        started simultaneously and without any delay between them if <filename>foo.service</filename> is
+        activated.</para>
+
+        <xi:include href="version-info.xml" xpointer="v201"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Requires=</varname></term>
+
+        <listitem><para>Similar to <varname>Wants=</varname>, but declares a stronger requirement
+        dependency. Dependencies of this type may also be configured by adding a symlink to a
+        <filename>.requires/</filename> directory accompanying the unit file.</para>
+
+        <para>If this unit gets activated, the units listed will be activated as well. If one of
+        the other units fails to activate, and an ordering dependency <varname>After=</varname> on the
+        failing unit is set, this unit will not be started. Besides, with or without specifying
+        <varname>After=</varname>, this unit will be stopped (or restarted) if one of the other units is
+        explicitly stopped (or restarted).</para>
+
+        <para>Often, it is a better choice to use <varname>Wants=</varname> instead of
+        <varname>Requires=</varname> in order to achieve a system that is more robust when dealing with
+        failing services.</para>
+
+        <para>Note that this dependency type does not imply that the other unit always has to be in active state when
+        this unit is running. Specifically: failing condition checks (such as <varname>ConditionPathExists=</varname>,
+        <varname>ConditionPathIsSymbolicLink=</varname>, … — see below) do not cause the start job of a unit with a
+        <varname>Requires=</varname> dependency on it to fail. Also, some unit types may deactivate on their own (for
+        example, a service process may decide to exit cleanly, or a device may be unplugged by the user), which is not
+        propagated to units having a <varname>Requires=</varname> dependency. Use the <varname>BindsTo=</varname>
+        dependency type together with <varname>After=</varname> to ensure that a unit may never be in active state
+        without a specific other unit also in active state (see below).</para>
+
+        <xi:include href="version-info.xml" xpointer="v201"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Requisite=</varname></term>
+
+        <listitem><para>Similar to <varname>Requires=</varname>. However, if the units listed here
+        are not started already, they will not be started and the starting of this unit will fail
+        immediately. <varname>Requisite=</varname> does not imply an ordering dependency, even if
+        both units are started in the same transaction. Hence this setting should usually be
+        combined with <varname>After=</varname>, to ensure this unit is not started before the other
+        unit.</para>
+
+        <para>When <varname>Requisite=b.service</varname> is used on
+        <filename>a.service</filename>, this dependency will show as
+        <varname>RequisiteOf=a.service</varname> in property listing of
+        <filename>b.service</filename>. <varname>RequisiteOf=</varname>
+        dependency cannot be specified directly.</para>
+
+        <xi:include href="version-info.xml" xpointer="v201"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>BindsTo=</varname></term>
+
+        <listitem><para>Configures requirement dependencies, very similar in style to
+        <varname>Requires=</varname>. However, this dependency type is stronger: in addition to the effect of
+        <varname>Requires=</varname> it declares that if the unit bound to is stopped, this unit will be stopped
+        too. This means a unit bound to another unit that suddenly enters inactive state will be stopped too.
+        Units can suddenly, unexpectedly enter inactive state for different reasons: the main process of a service unit
+        might terminate on its own choice, the backing device of a device unit might be unplugged or the mount point of
+        a mount unit might be unmounted without involvement of the system and service manager.</para>
+
+        <para>When used in conjunction with <varname>After=</varname> on the same unit the behaviour of
+        <varname>BindsTo=</varname> is even stronger. In this case, the unit bound to strictly has to be in active
+        state for this unit to also be in active state. This not only means a unit bound to another unit that suddenly
+        enters inactive state, but also one that is bound to another unit that gets skipped due to an unmet condition
+        check (such as <varname>ConditionPathExists=</varname>, <varname>ConditionPathIsSymbolicLink=</varname>, … —
+        see below) will be stopped, should it be running. Hence, in many cases it is best to combine
+        <varname>BindsTo=</varname> with <varname>After=</varname>.</para>
+
+        <para>When <varname>BindsTo=b.service</varname> is used on
+        <filename>a.service</filename>, this dependency will show as
+        <varname>BoundBy=a.service</varname> in property listing of
+        <filename>b.service</filename>. <varname>BoundBy=</varname>
+        dependency cannot be specified directly.</para>
+
+        <xi:include href="version-info.xml" xpointer="v201"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>PartOf=</varname></term>
+
+        <listitem><para>Configures dependencies similar to
+        <varname>Requires=</varname>, but limited to stopping and
+        restarting of units. When systemd stops or restarts the units
+        listed here, the action is propagated to this unit. Note that
+        this is a one-way dependency — changes to this unit do not
+        affect the listed units.</para>
+
+        <para>When <varname>PartOf=b.service</varname> is used on
+        <filename>a.service</filename>, this dependency will show as
+        <varname>ConsistsOf=a.service</varname> in property listing of
+        <filename>b.service</filename>. <varname>ConsistsOf=</varname>
+        dependency cannot be specified directly.</para>
+
+        <xi:include href="version-info.xml" xpointer="v201"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Upholds=</varname></term>
+
+        <listitem><para>Configures dependencies similar to <varname>Wants=</varname>, but as long as this unit
+        is up, all units listed in <varname>Upholds=</varname> are started whenever found to be inactive or
+        failed, and no job is queued for them. While a <varname>Wants=</varname> dependency on another unit
+        has a one-time effect when this units started, a <varname>Upholds=</varname> dependency on it has a
+        continuous effect, constantly restarting the unit if necessary. This is an alternative to the
+        <varname>Restart=</varname> setting of service units, to ensure they are kept running whatever
+        happens. The restart happens without delay, and usual per-unit rate-limit applies.</para>
+
+        <para>When <varname>Upholds=b.service</varname> is used on <filename>a.service</filename>, this
+        dependency will show as <varname>UpheldBy=a.service</varname> in the property listing of
+        <filename>b.service</filename>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v249"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Conflicts=</varname></term>
+
+        <listitem><para>A space-separated list of unit names. Configures negative requirement
+        dependencies. If a unit has a <varname>Conflicts=</varname> setting on another unit, starting the
+        former will stop the latter and vice versa.</para>
+
+        <para>Note that this setting does not imply an ordering dependency, similarly to the
+        <varname>Wants=</varname> and <varname>Requires=</varname> dependencies described above. This means
+        that to ensure that the conflicting unit is stopped before the other unit is started, an
+        <varname>After=</varname> or <varname>Before=</varname> dependency must be declared. It doesn't
+        matter which of the two ordering dependencies is used, because stop jobs are always ordered before
+        start jobs, see the discussion in <varname>Before=</varname>/<varname>After=</varname> below.</para>
+
+        <para>If unit A that conflicts with unit B is scheduled to
+        be started at the same time as B, the transaction will either
+        fail (in case both are required parts of the transaction) or be
+        modified to be fixed (in case one or both jobs are not a
+        required part of the transaction). In the latter case, the job
+        that is not required will be removed, or in case both are
+        not required, the unit that conflicts will be started and the
+        unit that is conflicted is stopped.</para>
+
+        <xi:include href="version-info.xml" xpointer="v201"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Before=</varname></term>
+        <term><varname>After=</varname></term>
+
+        <listitem><para>These two settings expect a space-separated list of unit names. They may be specified
+        more than once, in which case dependencies for all listed names are created.</para>
+
+        <para>Those two settings configure ordering dependencies between units. If unit
+        <filename>foo.service</filename> contains the setting <option>Before=bar.service</option> and both
+        units are being started, <filename>bar.service</filename>'s start-up is delayed until
+        <filename>foo.service</filename> has finished starting up. <varname>After=</varname> is the inverse
+        of <varname>Before=</varname>, i.e. while <varname>Before=</varname> ensures that the configured unit
+        is started before the listed unit begins starting up, <varname>After=</varname> ensures the opposite,
+        that the listed unit is fully started up before the configured unit is started.</para>
+
+        <para>When two units with an ordering dependency between them are shut down, the inverse of the
+        start-up order is applied. I.e. if a unit is configured with <varname>After=</varname> on another
+        unit, the former is stopped before the latter if both are shut down. Given two units with any
+        ordering dependency between them, if one unit is shut down and the other is started up, the shutdown
+        is ordered before the start-up. It doesn't matter if the ordering dependency is
+        <varname>After=</varname> or <varname>Before=</varname>, in this case. It also doesn't matter which
+        of the two is shut down, as long as one is shut down and the other is started up; the shutdown is
+        ordered before the start-up in all cases. If two units have no ordering dependencies between them,
+        they are shut down or started up simultaneously, and no ordering takes place. It depends on the unit
+        type when precisely a unit has finished starting up. Most importantly, for service units start-up is
+        considered completed for the purpose of <varname>Before=</varname>/<varname>After=</varname> when all
+        its configured start-up commands have been invoked and they either failed or reported start-up
+        success. Note that this does includes <varname>ExecStartPost=</varname> (or
+        <varname>ExecStopPost=</varname> for the shutdown case).</para>
+
+        <para>Note that those settings are independent of and orthogonal to the requirement dependencies as
+        configured by <varname>Requires=</varname>, <varname>Wants=</varname>, <varname>Requisite=</varname>,
+        or <varname>BindsTo=</varname>. It is a common pattern to include a unit name in both the
+        <varname>After=</varname> and <varname>Wants=</varname> options, in which case the unit listed will
+        be started before the unit that is configured with these options.</para>
+
+        <para>Note that <varname>Before=</varname> dependencies on device units have no effect and are not
+        supported.  Devices generally become available as a result of an external hotplug event, and systemd
+        creates the corresponding device unit without delay.</para>
+
+        <xi:include href="version-info.xml" xpointer="v201"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>OnFailure=</varname></term>
+
+        <listitem><para>A space-separated list of one or more units that are activated when this unit enters
+        the <literal>failed</literal> state.</para>
+
+        <xi:include href="version-info.xml" xpointer="v201"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>OnSuccess=</varname></term>
+
+        <listitem><para>A space-separated list of one or more units that are activated when this unit enters
+        the <literal>inactive</literal> state.</para>
+
+        <xi:include href="version-info.xml" xpointer="v249"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>PropagatesReloadTo=</varname></term>
+        <term><varname>ReloadPropagatedFrom=</varname></term>
+
+        <listitem><para>A space-separated list of one or more units to which reload requests from this unit
+        shall be propagated to, or units from which reload requests shall be propagated to this unit,
+        respectively. Issuing a reload request on a unit will automatically also enqueue reload requests on
+        all units that are linked to it using these two settings.</para>
+
+        <xi:include href="version-info.xml" xpointer="v201"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>PropagatesStopTo=</varname></term>
+        <term><varname>StopPropagatedFrom=</varname></term>
+
+        <listitem><para>A space-separated list of one or more units to which stop requests from this unit
+        shall be propagated to, or units from which stop requests shall be propagated to this unit,
+        respectively. Issuing a stop request on a unit will automatically also enqueue stop requests on all
+        units that are linked to it using these two settings.</para>
+
+        <xi:include href="version-info.xml" xpointer="v249"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>JoinsNamespaceOf=</varname></term>
+
+        <listitem><para>For units that start processes (such as service units), lists one or more other units
+        whose network and/or temporary file namespace to join. If this is specified on a unit (say,
+        <filename>a.service</filename> has <varname>JoinsNamespaceOf=b.service</varname>), then the inverse
+        dependency (<varname>JoinsNamespaceOf=a.service</varname> for b.service) is implied. This only
+        applies to unit types which support the <varname>PrivateNetwork=</varname>,
+        <varname>NetworkNamespacePath=</varname>, <varname>PrivateIPC=</varname>,
+        <varname>IPCNamespacePath=</varname>, and <varname>PrivateTmp=</varname> directives (see
+        <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
+        details). If a unit that has this setting set is started, its processes will see the same
+        <filename>/tmp/</filename>, <filename>/var/tmp/</filename>, IPC namespace and network namespace as
+        one listed unit that is started. If multiple listed units are already started and these do not share
+        their namespace, then it is not defined which namespace is joined. Note that this setting only has an
+        effect if <varname>PrivateNetwork=</varname>/<varname>NetworkNamespacePath=</varname>,
+        <varname>PrivateIPC=</varname>/<varname>IPCNamespacePath=</varname> and/or
+        <varname>PrivateTmp=</varname> is enabled for both the unit that joins the namespace and the unit
+        whose namespace is joined.</para>
+
+        <xi:include href="version-info.xml" xpointer="v209"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RequiresMountsFor=</varname></term>
+
+        <listitem><para>Takes a space-separated list of absolute
+        paths. Automatically adds dependencies of type
+        <varname>Requires=</varname> and <varname>After=</varname> for
+        all mount units required to access the specified path.</para>
+
+        <para>Mount points marked with <option>noauto</option> are not
+        mounted automatically through <filename>local-fs.target</filename>,
+        but are still honored for the purposes of this option, i.e. they
+        will be pulled in by this unit.</para>
+
+        <xi:include href="version-info.xml" xpointer="v201"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>OnSuccessJobMode=</varname></term>
+        <term><varname>OnFailureJobMode=</varname></term>
+
+        <listitem><para>Takes a value of
+        <literal>fail</literal>,
+        <literal>replace</literal>,
+        <literal>replace-irreversibly</literal>,
+        <literal>isolate</literal>,
+        <literal>flush</literal>,
+        <literal>ignore-dependencies</literal> or
+        <literal>ignore-requirements</literal>. Defaults to
+        <literal>replace</literal>. Specifies how the units listed in
+        <varname>OnSuccess=</varname>/<varname>OnFailure=</varname> will be enqueued. See
+        <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s
+        <option>--job-mode=</option> option for details on the
+        possible values. If this is set to <literal>isolate</literal>,
+        only a single unit may be listed in
+        <varname>OnSuccess=</varname>/<varname>OnFailure=</varname>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v209"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>IgnoreOnIsolate=</varname></term>
+
+        <listitem><para>Takes a boolean argument. If <option>true</option>, this unit will not be stopped
+        when isolating another unit. Defaults to <option>false</option> for service, target, socket, timer,
+        and path units, and <option>true</option> for slice, scope, device, swap, mount, and automount
+        units.</para>
+
+        <xi:include href="version-info.xml" xpointer="v201"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>StopWhenUnneeded=</varname></term>
+
+        <listitem><para>Takes a boolean argument. If
+        <option>true</option>, this unit will be stopped when it is no
+        longer used. Note that, in order to minimize the work to be
+        executed, systemd will not stop units by default unless they
+        are conflicting with other units, or the user explicitly
+        requested their shut down. If this option is set, a unit will
+        be automatically cleaned up if no other active unit requires
+        it. Defaults to <option>false</option>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v201"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RefuseManualStart=</varname></term>
+        <term><varname>RefuseManualStop=</varname></term>
+
+        <listitem><para>Takes a boolean argument. If
+        <option>true</option>, this unit can only be activated or
+        deactivated indirectly. In this case, explicit start-up or
+        termination requested by the user is denied, however if it is
+        started or stopped as a dependency of another unit, start-up
+        or termination will succeed. This is mostly a safety feature
+        to ensure that the user does not accidentally activate units
+        that are not intended to be activated explicitly, and not
+        accidentally deactivate units that are not intended to be
+        deactivated. These options default to
+        <option>false</option>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v201"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>AllowIsolate=</varname></term>
+
+        <listitem><para>Takes a boolean argument. If
+        <option>true</option>, this unit may be used with the
+        <command>systemctl isolate</command> command. Otherwise, this
+        will be refused. It probably is a good idea to leave this
+        disabled except for target units that shall be used similar to
+        runlevels in SysV init systems, just as a precaution to avoid
+        unusable system states. This option defaults to
+        <option>false</option>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v201"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>DefaultDependencies=</varname></term>
+
+        <listitem><para>Takes a boolean argument. If
+        <option>yes</option>, (the default), a few default
+        dependencies will implicitly be created for the unit. The
+        actual dependencies created depend on the unit type. For
+        example, for service units, these dependencies ensure that the
+        service is started only after basic system initialization is
+        completed and is properly terminated on system shutdown. See
+        the respective man pages for details. Generally, only services
+        involved with early boot or late shutdown should set this
+        option to <option>no</option>. It is highly recommended to
+        leave this option enabled for the majority of common units. If
+        set to <option>no</option>, this option does not disable
+        all implicit dependencies, just non-essential
+        ones.</para>
+
+        <xi:include href="version-info.xml" xpointer="v201"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SurviveFinalKillSignal=</varname></term>
+
+        <listitem><para>Takes a boolean argument. Defaults to <option>no</option>. If <option>yes</option>,
+        processes belonging to this unit will not be sent the final <literal>SIGTERM</literal> and
+        <literal>SIGKILL</literal> signals during the final phase of the system shutdown process.
+        This functionality replaces the older mechanism that allowed a program to set
+        <literal>argv[0][0] = '@'</literal> as described at
+        <ulink url="https://systemd.io/ROOT_STORAGE_DAEMONS">systemd and Storage Daemons for the Root File
+        System</ulink>, which however continues to be supported.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>CollectMode=</varname></term>
+
+        <listitem><para>Tweaks the "garbage collection" algorithm for this unit. Takes one of <option>inactive</option>
+        or <option>inactive-or-failed</option>. If set to <option>inactive</option> the unit will be unloaded if it is
+        in the <constant>inactive</constant> state and is not referenced by clients, jobs or other units — however it
+        is not unloaded if it is in the <constant>failed</constant> state. In <option>failed</option> mode, failed
+        units are not unloaded until the user invoked <command>systemctl reset-failed</command> on them to reset the
+        <constant>failed</constant> state, or an equivalent command. This behaviour is altered if this option is set to
+        <option>inactive-or-failed</option>: in this case the unit is unloaded even if the unit is in a
+        <constant>failed</constant> state, and thus an explicitly resetting of the <constant>failed</constant> state is
+        not necessary. Note that if this mode is used unit results (such as exit codes, exit signals, consumed
+        resources, …) are flushed out immediately after the unit completed, except for what is stored in the logging
+        subsystem. Defaults to <option>inactive</option>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v236"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>FailureAction=</varname></term>
+        <term><varname>SuccessAction=</varname></term>
+
+        <listitem><para>Configure the action to take when the unit stops and enters a failed state or
+        inactive state.  Takes one of <option>none</option>, <option>reboot</option>,
+        <option>reboot-force</option>, <option>reboot-immediate</option>, <option>poweroff</option>,
+        <option>poweroff-force</option>, <option>poweroff-immediate</option>, <option>exit</option>,
+        <option>exit-force</option>, <option>soft-reboot</option>, <option>soft-reboot-force</option>,
+        <option>kexec</option>, <option>kexec-force</option>, <option>halt</option>,
+        <option>halt-force</option> and <option>halt-immediate</option>. In system mode, all options are
+        allowed. In user mode, only <option>none</option>, <option>exit</option>,
+        <option>exit-force</option>, <option>soft-reboot</option> and <option>soft-reboot-force</option> are
+        allowed. Both options default to <option>none</option>.</para>
+
+        <para>If <option>none</option> is set, no action will be triggered. <option>reboot</option> causes a
+        reboot following the normal shutdown procedure (i.e. equivalent to <command>systemctl
+        reboot</command>).  <option>reboot-force</option> causes a forced reboot which will terminate all
+        processes forcibly but should cause no dirty file systems on reboot (i.e. equivalent to
+        <command>systemctl reboot -f</command>) and <option>reboot-immediate</option> causes immediate
+        execution of the
+        <citerefentry><refentrytitle>reboot</refentrytitle><manvolnum>2</manvolnum></citerefentry> system
+        call, which might result in data loss (i.e. equivalent to <command>systemctl reboot -ff</command>).
+        Similarly, <option>poweroff</option>, <option>poweroff-force</option>,
+        <option>poweroff-immediate</option>, <option>kexec</option>, <option>kexec-force</option>,
+        <option>halt</option>, <option>halt-force</option> and <option>halt-immediate</option> have the
+        effect of powering down the system, executing kexec, and halting the system respectively with similar
+        semantics. <option>exit</option> causes the manager to exit following the normal shutdown procedure,
+        and <option>exit-force</option> causes it terminate without shutting down services. When
+        <option>exit</option> or <option>exit-force</option> is used by default the exit status of the main
+        process of the unit (if this applies) is returned from the service manager. However, this may be
+        overridden with
+        <varname>FailureActionExitStatus=</varname>/<varname>SuccessActionExitStatus=</varname>, see below.
+        <option>soft-reboot</option> will trigger a userspace reboot operation.
+        <option>soft-reboot-force</option> does that too, but does not go through the shutdown transaction
+        beforehand.</para>
+
+        <xi:include href="version-info.xml" xpointer="v236"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>FailureActionExitStatus=</varname></term>
+        <term><varname>SuccessActionExitStatus=</varname></term>
+
+        <listitem><para>Controls the exit status to propagate back to an invoking container manager (in case of a
+        system service) or service manager (in case of a user manager) when the
+        <varname>FailureAction=</varname>/<varname>SuccessAction=</varname> are set to <option>exit</option> or
+        <option>exit-force</option> and the action is triggered. By default the exit status of the main process of the
+        triggering unit (if this applies) is propagated. Takes a value in the range 0…255 or the empty string to
+        request default behaviour.</para>
+
+        <xi:include href="version-info.xml" xpointer="v240"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>JobTimeoutSec=</varname></term>
+        <term><varname>JobRunningTimeoutSec=</varname></term>
+
+        <listitem><para><varname>JobTimeoutSec=</varname> specifies a timeout for the whole job that starts
+        running when the job is queued. <varname>JobRunningTimeoutSec=</varname> specifies a timeout that
+        starts running when the queued job is actually started. If either limit is reached, the job will be
+        cancelled, the unit however will not change state or even enter the <literal>failed</literal> mode.
+        </para>
+
+        <para>Both settings take a time span with the default unit of seconds, but other units may be
+        specified, see
+        <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+        The default is <literal>infinity</literal> (job timeouts disabled), except for device units where
+        <varname>JobRunningTimeoutSec=</varname> defaults to <varname>DefaultDeviceTimeoutSec=</varname>.
+        </para>
+
+        <para>Note: these timeouts are independent from any unit-specific timeouts (for example, the timeout
+        set with <varname>TimeoutStartSec=</varname> in service units). The job timeout has no effect on the
+        unit itself. Or in other words: unit-specific timeouts are useful to abort unit state changes, and
+        revert them. The job timeout set with this option however is useful to abort only the job waiting for
+        the unit state to change.</para>
+
+        <xi:include href="version-info.xml" xpointer="v201"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>JobTimeoutAction=</varname></term>
+        <term><varname>JobTimeoutRebootArgument=</varname></term>
+
+        <listitem><para><varname>JobTimeoutAction=</varname> optionally configures an additional action to
+        take when the timeout is hit, see description of <varname>JobTimeoutSec=</varname> and
+        <varname>JobRunningTimeoutSec=</varname> above. It takes the same values as
+        <varname>StartLimitAction=</varname>. Defaults to <option>none</option>.</para>
+
+        <para><varname>JobTimeoutRebootArgument=</varname> configures an optional reboot string to pass to
+        the <citerefentry><refentrytitle>reboot</refentrytitle><manvolnum>2</manvolnum></citerefentry> system
+        call.</para>
+
+        <xi:include href="version-info.xml" xpointer="v240"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>StartLimitIntervalSec=<replaceable>interval</replaceable></varname></term>
+        <term><varname>StartLimitBurst=<replaceable>burst</replaceable></varname></term>
+
+        <listitem><para>Configure unit start rate limiting. Units which are started more than
+        <replaceable>burst</replaceable> times within an <replaceable>interval</replaceable> time span are
+        not permitted to start any more. Use <varname>StartLimitIntervalSec=</varname> to configure the
+        checking interval and <varname>StartLimitBurst=</varname> to configure how many starts per interval
+        are allowed.</para>
+
+        <para><replaceable>interval</replaceable> is a time span with the default unit of seconds, but other
+        units may be specified, see
+        <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+        The special value <literal>infinity</literal> can be used to limit the total number of start
+        attempts, even if they happen at large time intervals.
+        Defaults to <varname>DefaultStartLimitIntervalSec=</varname> in manager configuration file, and may
+        be set to 0 to disable any kind of rate limiting. <replaceable>burst</replaceable> is a number and
+        defaults to <varname>DefaultStartLimitBurst=</varname> in manager configuration file.</para>
+
+        <para>These configuration options are particularly useful in conjunction with the service setting
+        <varname>Restart=</varname> (see
+        <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>);
+        however, they apply to all kinds of starts (including manual), not just those triggered by the
+        <varname>Restart=</varname> logic.</para>
+
+        <para>Note that units which are configured for <varname>Restart=</varname>, and which reach the start
+        limit are not attempted to be restarted anymore; however, they may still be restarted manually or
+        from a timer or socket at a later point, after the <replaceable>interval</replaceable> has passed.
+        From that point on, the restart logic is activated again. <command>systemctl reset-failed</command>
+        will cause the restart rate counter for a service to be flushed, which is useful if the administrator
+        wants to manually start a unit and the start limit interferes with that. Rate-limiting is enforced
+        after any unit condition checks are executed, and hence unit activations with failing conditions do
+        not count towards the rate limit.</para>
+
+        <para>When a unit is unloaded due to the garbage collection logic (see above) its rate limit counters
+        are flushed out too. This means that configuring start rate limiting for a unit that is not
+        referenced continuously has no effect.</para>
+
+        <para>This setting does not apply to slice, target, device, and scope units, since they are unit
+        types whose activation may either never fail, or may succeed only a single time.</para>
+
+        <xi:include href="version-info.xml" xpointer="v229"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>StartLimitAction=</varname></term>
+
+        <listitem><para>Configure an additional action to take if the rate limit configured with
+        <varname>StartLimitIntervalSec=</varname> and <varname>StartLimitBurst=</varname> is hit. Takes the same
+        values as the <varname>FailureAction=</varname>/<varname>SuccessAction=</varname> settings. If
+        <option>none</option> is set, hitting the rate limit will trigger no action except that
+        the start will not be permitted. Defaults to <option>none</option>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v229"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RebootArgument=</varname></term>
+        <listitem><para>Configure the optional argument for the
+        <citerefentry><refentrytitle>reboot</refentrytitle><manvolnum>2</manvolnum></citerefentry> system call if
+        <varname>StartLimitAction=</varname> or <varname>FailureAction=</varname> is a reboot action. This
+        works just like the optional argument to <command>systemctl reboot</command> command.</para>
+
+        <xi:include href="version-info.xml" xpointer="v229"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SourcePath=</varname></term>
+        <listitem><para>A path to a configuration file this unit has
+        been generated from. This is primarily useful for
+        implementation of generator tools that convert configuration
+        from an external configuration file format into native unit
+        files. This functionality should not be used in normal
+        units.</para>
+
+        <xi:include href="version-info.xml" xpointer="v201"/></listitem>
+      </varlistentry>
+    </variablelist>
+
+    <refsect2>
+      <title>Conditions and Asserts</title>
+
+      <para>Unit files may also include a number of <varname index="false">Condition…=</varname> and <varname
+      index="false">Assert…=</varname> settings. Before the unit is started, systemd will verify that the
+      specified conditions and asserts are true. If not, the starting of the unit will be (mostly silently)
+      skipped (in case of conditions), or aborted with an error message (in case of asserts). Failing
+      conditions or asserts will not result in the unit being moved into the <literal>failed</literal>
+      state. The conditions and asserts are checked at the time the queued start job is to be executed. The
+      ordering dependencies are still respected, so other units are still pulled in and ordered as if this
+      unit was successfully activated, and the conditions and asserts are executed the precise moment the
+      unit would normally start and thus can validate system state after the units ordered before completed
+      initialization. Use condition expressions for skipping units that do not apply to the local system, for
+      example because the kernel or runtime environment doesn't require their functionality.
+      </para>
+
+      <para>If multiple conditions are specified, the unit will be executed if all of them apply (i.e. a
+      logical AND is applied). Condition checks can use a pipe symbol (<literal>|</literal>) after the equals
+      sign (<literal>Condition…=|…</literal>), which causes the condition to become a
+      <emphasis>triggering</emphasis> condition. If at least one triggering condition is defined for a unit,
+      then the unit will be started if at least one of the triggering conditions of the unit applies and all
+      of the regular (i.e. non-triggering) conditions apply. If you prefix an argument with the pipe symbol
+      and an exclamation mark, the pipe symbol must be passed first, the exclamation second. If any of these
+      options is assigned the empty string, the list of conditions is reset completely, all previous
+      condition settings (of any kind) will have no effect.</para>
+
+      <para>The <varname>AssertArchitecture=</varname>, <varname>AssertVirtualization=</varname>, … options
+      are similar to conditions but cause the start job to fail (instead of being skipped). The failed check
+      is logged. Units with unmet conditions are considered to be in a clean state and will be garbage
+      collected if they are not referenced. This means that when queried, the condition failure may or may
+      not show up in the state of the unit.</para>
+
+      <para>Note that neither assertion nor condition expressions result in unit state changes. Also note
+      that both are checked at the time the job is to be executed, i.e. long after depending jobs and it
+      itself were queued. Thus, neither condition nor assertion expressions are suitable for conditionalizing
+      unit dependencies.</para>
+
+      <para>The <command>condition</command> verb of
+      <citerefentry><refentrytitle>systemd-analyze</refentrytitle><manvolnum>1</manvolnum></citerefentry> can
+      be used to test condition and assert expressions.</para>
+
+      <para>Except for <varname>ConditionPathIsSymbolicLink=</varname>, all path checks follow symlinks.</para>
+
+      <variablelist class='unit-directives'>
+        <varlistentry>
+          <term><varname>ConditionArchitecture=</varname></term>
+
+          <listitem><para>Check whether the system is running on a specific architecture. Takes one of
+          <literal>x86</literal>,
+          <literal>x86-64</literal>,
+          <literal>ppc</literal>,
+          <literal>ppc-le</literal>,
+          <literal>ppc64</literal>,
+          <literal>ppc64-le</literal>,
+          <literal>ia64</literal>,
+          <literal>parisc</literal>,
+          <literal>parisc64</literal>,
+          <literal>s390</literal>,
+          <literal>s390x</literal>,
+          <literal>sparc</literal>,
+          <literal>sparc64</literal>,
+          <literal>mips</literal>,
+          <literal>mips-le</literal>,
+          <literal>mips64</literal>,
+          <literal>mips64-le</literal>,
+          <literal>alpha</literal>,
+          <literal>arm</literal>,
+          <literal>arm-be</literal>,
+          <literal>arm64</literal>,
+          <literal>arm64-be</literal>,
+          <literal>sh</literal>,
+          <literal>sh64</literal>,
+          <literal>m68k</literal>,
+          <literal>tilegx</literal>,
+          <literal>cris</literal>,
+          <literal>arc</literal>,
+          <literal>arc-be</literal>, or
+          <literal>native</literal>.</para>
+
+          <para>The architecture is determined from the information returned by
+          <citerefentry project='man-pages'><refentrytitle>uname</refentrytitle><manvolnum>2</manvolnum></citerefentry>
+          and is thus subject to
+          <citerefentry><refentrytitle>personality</refentrytitle><manvolnum>2</manvolnum></citerefentry>.
+          Note that a <varname>Personality=</varname> setting in the same unit file has no effect on this
+          condition. A special architecture name <literal>native</literal> is mapped to the architecture the
+          system manager itself is compiled for. The test may be negated by prepending an exclamation
+          mark.</para>
+
+          <xi:include href="version-info.xml" xpointer="v201"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>ConditionFirmware=</varname></term>
+
+          <listitem><para>Check whether the system's firmware is of a certain type. The following values are
+          possible:</para>
+
+          <itemizedlist>
+            <listitem><para><literal>uefi</literal> matches systems with EFI.</para></listitem>
+
+            <listitem><para><literal>device-tree</literal> matches systems with a device tree.
+            </para></listitem>
+
+            <listitem><para><literal>device-tree-compatible(<replaceable>value</replaceable>)</literal>
+            matches systems with a device tree that are compatible with <literal>value</literal>.
+            </para></listitem>
+
+            <listitem><para><literal>smbios-field(<replaceable>field</replaceable>
+            <replaceable>operator</replaceable> <replaceable>value</replaceable>)</literal> matches systems
+            with a SMBIOS field containing a certain value. <replaceable>field</replaceable> is the name of
+            the SMBIOS field exposed as <literal>sysfs</literal> attribute file below
+            <filename>/sys/class/dmi/id/</filename>. <replaceable>operator</replaceable> is one of
+            <literal>&lt;</literal>, <literal>&lt;=</literal>, <literal>&gt;=</literal>,
+            <literal>&gt;</literal>, <literal>==</literal>, <literal>&lt;&gt;</literal> for version
+            comparisons, <literal>=</literal> and <literal>!=</literal> for literal string comparisons, or
+            <literal>$=</literal>, <literal>!$=</literal> for shell-style glob comparisons.
+            <replaceable>value</replaceable> is the expected value of the SMBIOS field value (possibly
+            containing shell style globs in case <literal>$=</literal>/<literal>!$=</literal> is used).
+            </para></listitem>
+          </itemizedlist>
+
+            <xi:include href="version-info.xml" xpointer="v249"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>ConditionVirtualization=</varname></term>
+
+          <listitem><para>Check whether the system is executed in a virtualized environment and optionally
+          test whether it is a specific implementation. Takes either boolean value to check if being executed
+          in any virtualized environment, or one of
+          <literal>vm</literal> and
+          <literal>container</literal> to test against a generic type of virtualization solution, or one of
+          <literal>qemu</literal>,
+          <literal>kvm</literal>,
+          <literal>amazon</literal>,
+          <literal>zvm</literal>,
+          <literal>vmware</literal>,
+          <literal>microsoft</literal>,
+          <literal>oracle</literal>,
+          <literal>powervm</literal>,
+          <literal>xen</literal>,
+          <literal>bochs</literal>,
+          <literal>uml</literal>,
+          <literal>bhyve</literal>,
+          <literal>qnx</literal>,
+          <literal>apple</literal>,
+          <literal>sre</literal>,
+          <literal>openvz</literal>,
+          <literal>lxc</literal>,
+          <literal>lxc-libvirt</literal>,
+          <literal>systemd-nspawn</literal>,
+          <literal>docker</literal>,
+          <literal>podman</literal>,
+          <literal>rkt</literal>,
+          <literal>wsl</literal>,
+          <literal>proot</literal>,
+          <literal>pouch</literal>,
+          <literal>acrn</literal> to test
+          against a specific implementation, or
+          <literal>private-users</literal> to check whether we are running in a user namespace. See
+          <citerefentry><refentrytitle>systemd-detect-virt</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+          for a full list of known virtualization technologies and their identifiers. If multiple
+          virtualization technologies are nested, only the innermost is considered. The test may be negated
+          by prepending an exclamation mark.</para>
+
+          <xi:include href="version-info.xml" xpointer="v244"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>ConditionHost=</varname></term>
+
+          <listitem><para><varname>ConditionHost=</varname> may be used to match against the hostname or
+          machine ID of the host. This either takes a hostname string (optionally with shell style globs)
+          which is tested against the locally set hostname as returned by
+          <citerefentry><refentrytitle>gethostname</refentrytitle><manvolnum>2</manvolnum></citerefentry>, or
+          a machine ID formatted as string (see
+          <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
+          The test may be negated by prepending an exclamation mark.</para>
+
+          <xi:include href="version-info.xml" xpointer="v244"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>ConditionKernelCommandLine=</varname></term>
+
+          <listitem><para><varname>ConditionKernelCommandLine=</varname> may be used to check whether a
+          specific kernel command line option is set (or if prefixed with the exclamation mark — unset). The
+          argument must either be a single word, or an assignment (i.e. two words, separated by
+          <literal>=</literal>). In the former case the kernel command line is searched for the word
+          appearing as is, or as left hand side of an assignment. In the latter case, the exact assignment is
+          looked for with right and left hand side matching. This operates on the kernel command line
+          communicated to userspace via <filename>/proc/cmdline</filename>, except when the service manager
+          is invoked as payload of a container manager, in which case the command line of <filename>PID
+          1</filename> is used instead (i.e. <filename>/proc/1/cmdline</filename>).</para>
+
+          <xi:include href="version-info.xml" xpointer="v244"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>ConditionKernelVersion=</varname></term>
+
+          <listitem><para><varname>ConditionKernelVersion=</varname> may be used to check whether the kernel
+          version (as reported by <command>uname -r</command>) matches a certain expression, or if prefixed
+          with the exclamation mark, does not match. The argument must be a list of (potentially quoted)
+          expressions. Each expression starts with one of <literal>=</literal> or <literal>!=</literal> for
+          string comparisons, <literal>&lt;</literal>, <literal>&lt;=</literal>, <literal>==</literal>,
+          <literal>&lt;&gt;</literal>, <literal>&gt;=</literal>, <literal>&gt;</literal> for version
+          comparisons, or <literal>$=</literal>, <literal>!$=</literal> for a shell-style glob match. If no
+          operator is specified, <literal>$=</literal> is implied.</para>
+
+          <para>Note that using the kernel version string is an unreliable way to determine which features
+          are supported by a kernel, because of the widespread practice of backporting drivers, features, and
+          fixes from newer upstream kernels into older versions provided by distributions. Hence, this check
+          is inherently unportable and should not be used for units which may be used on different
+          distributions.</para>
+
+          <xi:include href="version-info.xml" xpointer="v244"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>ConditionCredential=</varname></term>
+
+          <listitem><para><varname>ConditionCredential=</varname> may be used to check whether a credential
+          by the specified name was passed into the service manager. See <ulink
+          url="https://systemd.io/CREDENTIALS">System and Service Credentials</ulink> for details about
+          credentials. If used in services for the system service manager this may be used to conditionalize
+          services based on system credentials passed in. If used in services for the per-user service
+          manager this may be used to conditionalize services based on credentials passed into the
+          <filename>unit@.service</filename> service instance belonging to the user. The argument must be a
+          valid credential name.</para>
+
+          <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>ConditionEnvironment=</varname></term>
+
+          <listitem><para><varname>ConditionEnvironment=</varname> may be used to check whether a specific
+          environment variable is set (or if prefixed with the exclamation mark — unset) in the service
+          manager's environment block.
+
+          The argument may be a single word, to check if the variable with this name is defined in the
+          environment block, or an assignment
+          (<literal><replaceable>name</replaceable>=<replaceable>value</replaceable></literal>), to check if
+          the variable with this exact value is defined. Note that the environment block of the service
+          manager itself is checked, i.e. not any variables defined with <varname>Environment=</varname> or
+          <varname>EnvironmentFile=</varname>, as described above. This is particularly useful when the
+          service manager runs inside a containerized environment or as per-user service manager, in order to
+          check for variables passed in by the enclosing container manager or PAM.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>ConditionSecurity=</varname></term>
+
+          <listitem><para><varname>ConditionSecurity=</varname> may be used to check whether the given
+          security technology is enabled on the system. Currently, the following values are recognized:</para>
+
+          <table>
+            <title>Recognized security technologies</title>
+
+            <tgroup cols='2'>
+              <colspec colname='value'/>
+              <colspec colname='description'/>
+
+              <thead>
+                <row>
+                  <entry>Value</entry>
+                  <entry>Description</entry>
+                </row>
+              </thead>
+              <tbody>
+                <row>
+                  <entry>selinux</entry>
+                  <entry>SELinux MAC</entry>
+                </row>
+                <row>
+                  <entry>apparmor</entry>
+                  <entry>AppArmor MAC</entry>
+                </row>
+                <row>
+                  <entry>tomoyo</entry>
+                  <entry>Tomoyo MAC</entry>
+                </row>
+                <row>
+                  <entry>smack</entry>
+                  <entry>SMACK MAC</entry>
+                </row>
+                <row>
+                  <entry>ima</entry>
+                  <entry>Integrity Measurement Architecture (IMA)</entry>
+                </row>
+                <row>
+                  <entry>audit</entry>
+                  <entry>Linux Audit Framework</entry>
+                </row>
+                <row>
+                  <entry>uefi-secureboot</entry>
+                  <entry>UEFI SecureBoot</entry>
+                </row>
+                <row>
+                  <entry>tpm2</entry>
+                  <entry>Trusted Platform Module 2.0 (TPM2)</entry>
+                </row>
+                <row>
+                  <entry>cvm</entry>
+                  <entry>Confidential virtual machine (SEV/TDX)</entry>
+                </row>
+                <row>
+                  <entry>measured-uki</entry>
+                  <entry>Unified Kernel Image with PCR 11 Measurements, as per <citerefentry><refentrytitle>systemd-stub</refentrytitle><manvolnum>7</manvolnum></citerefentry>. <xi:include href="version-info.xml" xpointer="v255"/></entry>
+                </row>
+              </tbody>
+            </tgroup>
+          </table>
+
+          <para>The test may be negated by prepending an exclamation mark.</para>
+
+          <xi:include href="version-info.xml" xpointer="v244"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>ConditionCapability=</varname></term>
+
+          <listitem><para>Check whether the given capability exists in the capability bounding set of the
+          service manager (i.e. this does not check whether capability is actually available in the permitted
+          or effective sets, see
+          <citerefentry project='man-pages'><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+          for details). Pass a capability name such as <literal>CAP_MKNOD</literal>, possibly prefixed with
+          an exclamation mark to negate the check.</para>
+
+          <xi:include href="version-info.xml" xpointer="v244"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>ConditionACPower=</varname></term>
+
+          <listitem><para>Check whether the system has AC power, or is exclusively battery powered at the
+          time of activation of the unit. This takes a boolean argument. If set to <literal>true</literal>,
+          the condition will hold only if at least one AC connector of the system is connected to a power
+          source, or if no AC connectors are known. Conversely, if set to <literal>false</literal>, the
+          condition will hold only if there is at least one AC connector known and all AC connectors are
+          disconnected from a power source.</para>
+
+          <xi:include href="version-info.xml" xpointer="v244"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>ConditionNeedsUpdate=</varname></term>
+
+          <listitem><para>Takes one of <filename>/var/</filename> or <filename>/etc/</filename> as argument,
+          possibly prefixed with a <literal>!</literal> (to invert the condition). This condition may be
+          used to conditionalize units on whether the specified directory requires an update because
+          <filename>/usr/</filename>'s modification time is newer than the stamp file
+          <filename>.updated</filename> in the specified directory. This is useful to implement offline
+          updates of the vendor operating system resources in <filename>/usr/</filename> that require updating
+          of <filename>/etc/</filename> or <filename>/var/</filename> on the next following boot. Units making
+          use of this condition should order themselves before
+          <citerefentry><refentrytitle>systemd-update-done.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+          to make sure they run before the stamp file's modification time gets reset indicating a completed
+          update.</para>
+
+          <para>If the <varname>systemd.condition-needs-update=</varname> option is specified on the kernel
+          command line (taking a boolean), it will override the result of this condition check, taking
+          precedence over any file modification time checks. If the kernel command line option is used,
+          <filename>systemd-update-done.service</filename> will not have immediate effect on any following
+          <varname>ConditionNeedsUpdate=</varname> checks, until the system is rebooted where the kernel
+          command line option is not specified anymore.</para>
+
+          <para>Note that to make this scheme effective, the timestamp of <filename>/usr/</filename> should
+          be explicitly updated after its contents are modified. The kernel will automatically update
+          modification timestamp on a directory only when immediate children of a directory are modified; an
+          modification of nested files will not automatically result in mtime of <filename>/usr/</filename>
+          being updated.</para>
+
+          <para>Also note that if the update method includes a call to execute appropriate post-update steps
+          itself, it should not touch the timestamp of <filename>/usr/</filename>. In a typical distribution
+          packaging scheme, packages will do any required update steps as part of the installation or
+          upgrade, to make package contents immediately usable. <varname>ConditionNeedsUpdate=</varname>
+          should be used with other update mechanisms where such an immediate update does not
+          happen.</para>
+
+          <xi:include href="version-info.xml" xpointer="v244"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>ConditionFirstBoot=</varname></term>
+
+          <listitem><para>Takes a boolean argument. This condition may be used to conditionalize units on
+          whether the system is booting up for the first time. This roughly means that <filename>/etc/</filename>
+          was unpopulated when the system started booting (for details, see "First Boot Semantics" in
+          <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
+          First boot is considered finished (this condition will evaluate as false) after the manager
+          has finished the startup phase.</para>
+
+          <para>This condition may be used to populate <filename>/etc/</filename> on the first boot after
+          factory reset, or when a new system instance boots up for the first time.</para>
+
+          <para>For robustness, units with <varname>ConditionFirstBoot=yes</varname> should order themselves
+          before <filename>first-boot-complete.target</filename> and pull in this passive target with
+          <varname>Wants=</varname>. This ensures that in a case of an aborted first boot, these units will
+          be re-run during the next system startup.</para>
+
+          <para>If the <varname>systemd.condition-first-boot=</varname> option is specified on the kernel
+          command line (taking a boolean), it will override the result of this condition check, taking
+          precedence over <filename>/etc/machine-id</filename> existence checks.</para>
+
+          <xi:include href="version-info.xml" xpointer="v244"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>ConditionPathExists=</varname></term>
+
+          <listitem><para>Check for the existence of a file. If the specified absolute path name does not exist,
+          the condition will fail. If the absolute path name passed to
+          <varname>ConditionPathExists=</varname> is prefixed with an exclamation mark
+          (<literal>!</literal>), the test is negated, and the unit is only started if the path does not
+          exist.</para>
+
+          <xi:include href="version-info.xml" xpointer="v244"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>ConditionPathExistsGlob=</varname></term>
+
+          <listitem><para><varname>ConditionPathExistsGlob=</varname> is similar to
+          <varname>ConditionPathExists=</varname>, but checks for the existence of at least one file or
+          directory matching the specified globbing pattern.</para>
+
+          <xi:include href="version-info.xml" xpointer="v244"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>ConditionPathIsDirectory=</varname></term>
+
+          <listitem><para><varname>ConditionPathIsDirectory=</varname> is similar to
+          <varname>ConditionPathExists=</varname> but verifies that a certain path exists and is a
+          directory.</para>
+
+          <xi:include href="version-info.xml" xpointer="v244"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>ConditionPathIsSymbolicLink=</varname></term>
+
+          <listitem><para><varname>ConditionPathIsSymbolicLink=</varname> is similar to
+          <varname>ConditionPathExists=</varname> but verifies that a certain path exists and is a symbolic
+          link.</para>
+
+          <xi:include href="version-info.xml" xpointer="v244"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>ConditionPathIsMountPoint=</varname></term>
+
+          <listitem><para><varname>ConditionPathIsMountPoint=</varname> is similar to
+          <varname>ConditionPathExists=</varname> but verifies that a certain path exists and is a mount
+          point.</para>
+
+          <xi:include href="version-info.xml" xpointer="v244"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>ConditionPathIsReadWrite=</varname></term>
+
+          <listitem><para><varname>ConditionPathIsReadWrite=</varname> is similar to
+          <varname>ConditionPathExists=</varname> but verifies that the underlying file system is readable
+          and writable (i.e. not mounted read-only).</para>
+
+          <xi:include href="version-info.xml" xpointer="v244"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>ConditionPathIsEncrypted=</varname></term>
+
+          <listitem><para><varname>ConditionPathIsEncrypted=</varname> is similar to
+          <varname>ConditionPathExists=</varname> but verifies that the underlying file system's backing
+          block device is encrypted using dm-crypt/LUKS. Note that this check does not cover ext4
+          per-directory encryption, and only detects block level encryption. Moreover, if the specified path
+          resides on a file system on top of a loopback block device, only encryption above the loopback device is
+          detected. It is not detected whether the file system backing the loopback block device is encrypted.</para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>ConditionDirectoryNotEmpty=</varname></term>
+
+          <listitem><para><varname>ConditionDirectoryNotEmpty=</varname> is similar to
+          <varname>ConditionPathExists=</varname> but verifies that a certain path exists and is a non-empty
+          directory.</para>
+
+          <xi:include href="version-info.xml" xpointer="v244"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>ConditionFileNotEmpty=</varname></term>
+
+          <listitem><para><varname>ConditionFileNotEmpty=</varname> is similar to
+          <varname>ConditionPathExists=</varname> but verifies that a certain path exists and refers to a
+          regular file with a non-zero size.</para>
+
+          <xi:include href="version-info.xml" xpointer="v244"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>ConditionFileIsExecutable=</varname></term>
+
+          <listitem><para><varname>ConditionFileIsExecutable=</varname> is similar to
+          <varname>ConditionPathExists=</varname> but verifies that a certain path exists, is a regular file,
+          and marked executable.</para>
+
+          <xi:include href="version-info.xml" xpointer="v244"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>ConditionUser=</varname></term>
+
+          <listitem><para><varname>ConditionUser=</varname> takes a numeric <literal>UID</literal>, a UNIX
+          user name, or the special value <literal>@system</literal>. This condition may be used to check
+          whether the service manager is running as the given user. The special value
+          <literal>@system</literal> can be used to check if the user id is within the system user
+          range. This option is not useful for system services, as the system manager exclusively runs as the
+          root user, and thus the test result is constant.</para>
+
+          <xi:include href="version-info.xml" xpointer="v244"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>ConditionGroup=</varname></term>
+
+          <listitem><para><varname>ConditionGroup=</varname> is similar to <varname>ConditionUser=</varname>
+          but verifies that the service manager's real or effective group, or any of its auxiliary groups,
+          match the specified group or GID. This setting does not support the special value
+          <literal>@system</literal>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v244"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>ConditionControlGroupController=</varname></term>
+
+          <listitem><para>Check whether given cgroup controllers (e.g. <literal>cpu</literal>) are available
+          for use on the system or whether the legacy v1 cgroup or the modern v2 cgroup hierarchy is used.
+          </para>
+
+          <para>Multiple controllers may be passed with a space separating them; in this case the condition
+          will only pass if all listed controllers are available for use. Controllers unknown to systemd are
+          ignored. Valid controllers are <literal>cpu</literal>, <literal>io</literal>,
+          <literal>memory</literal>, and <literal>pids</literal>. Even if available in the kernel, a
+          particular controller may not be available if it was disabled on the kernel command line with
+          <varname>cgroup_disable=controller</varname>.</para>
+
+          <para>Alternatively, two special strings <literal>v1</literal> and <literal>v2</literal> may be
+          specified (without any controller names). <literal>v2</literal> will pass if the unified v2 cgroup
+          hierarchy is used, and <literal>v1</literal> will pass if the legacy v1 hierarchy or the hybrid
+          hierarchy are used. Note that legacy or hybrid hierarchies have been deprecated. See
+          <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> for
+          more information.</para>
+
+          <xi:include href="version-info.xml" xpointer="v244"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>ConditionMemory=</varname></term>
+
+          <listitem><para>Verify that the specified amount of system memory is available to the current
+          system. Takes a memory size in bytes as argument, optionally prefixed with a comparison operator
+          <literal>&lt;</literal>, <literal>&lt;=</literal>, <literal>=</literal> (or <literal>==</literal>),
+          <literal>!=</literal> (or <literal>&lt;&gt;</literal>), <literal>&gt;=</literal>,
+          <literal>&gt;</literal>. On bare-metal systems compares the amount of physical memory in the system
+          with the specified size, adhering to the specified comparison operator. In containers compares the
+          amount of memory assigned to the container instead.</para>
+
+          <xi:include href="version-info.xml" xpointer="v244"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>ConditionCPUs=</varname></term>
+
+          <listitem><para>Verify that the specified number of CPUs is available to the current system. Takes
+          a number of CPUs as argument, optionally prefixed with a comparison operator
+          <literal>&lt;</literal>, <literal>&lt;=</literal>, <literal>=</literal> (or <literal>==</literal>),
+          <literal>!=</literal> (or <literal>&lt;&gt;</literal>), <literal>&gt;=</literal>,
+          <literal>&gt;</literal>. Compares the number of CPUs in the CPU affinity mask configured of the
+          service manager itself with the specified number, adhering to the specified comparison operator. On
+          physical systems the number of CPUs in the affinity mask of the service manager usually matches the
+          number of physical CPUs, but in special and virtual environments might differ. In particular, in
+          containers the affinity mask usually matches the number of CPUs assigned to the container and not
+          the physically available ones.</para>
+
+          <xi:include href="version-info.xml" xpointer="v244"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>ConditionCPUFeature=</varname></term>
+
+          <listitem><para>Verify that a given CPU feature is available via the <literal>CPUID</literal>
+          instruction. This condition only does something on i386 and x86-64 processors. On other
+          processors it is assumed that the CPU does not support the given feature. It checks the leaves
+          <literal>1</literal>, <literal>7</literal>, <literal>0x80000001</literal>, and
+          <literal>0x80000007</literal>. Valid values are:
+          <literal>fpu</literal>,
+          <literal>vme</literal>,
+          <literal>de</literal>,
+          <literal>pse</literal>,
+          <literal>tsc</literal>,
+          <literal>msr</literal>,
+          <literal>pae</literal>,
+          <literal>mce</literal>,
+          <literal>cx8</literal>,
+          <literal>apic</literal>,
+          <literal>sep</literal>,
+          <literal>mtrr</literal>,
+          <literal>pge</literal>,
+          <literal>mca</literal>,
+          <literal>cmov</literal>,
+          <literal>pat</literal>,
+          <literal>pse36</literal>,
+          <literal>clflush</literal>,
+          <literal>mmx</literal>,
+          <literal>fxsr</literal>,
+          <literal>sse</literal>,
+          <literal>sse2</literal>,
+          <literal>ht</literal>,
+          <literal>pni</literal>,
+          <literal>pclmul</literal>,
+          <literal>monitor</literal>,
+          <literal>ssse3</literal>,
+          <literal>fma3</literal>,
+          <literal>cx16</literal>,
+          <literal>sse4_1</literal>,
+          <literal>sse4_2</literal>,
+          <literal>movbe</literal>,
+          <literal>popcnt</literal>,
+          <literal>aes</literal>,
+          <literal>xsave</literal>,
+          <literal>osxsave</literal>,
+          <literal>avx</literal>,
+          <literal>f16c</literal>,
+          <literal>rdrand</literal>,
+          <literal>bmi1</literal>,
+          <literal>avx2</literal>,
+          <literal>bmi2</literal>,
+          <literal>rdseed</literal>,
+          <literal>adx</literal>,
+          <literal>sha_ni</literal>,
+          <literal>syscall</literal>,
+          <literal>rdtscp</literal>,
+          <literal>lm</literal>,
+          <literal>lahf_lm</literal>,
+          <literal>abm</literal>,
+          <literal>constant_tsc</literal>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v248"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>ConditionOSRelease=</varname></term>
+
+          <listitem><para>Verify that a specific <literal>key=value</literal> pair is set in the host's
+          <citerefentry><refentrytitle>os-release</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+
+          <para>Other than exact string matching (with <literal>=</literal> and <literal>!=</literal>),
+          relative comparisons are supported for versioned parameters (e.g. <literal>VERSION_ID</literal>;
+          with <literal>&lt;</literal>, <literal>&lt;=</literal>, <literal>==</literal>,
+          <literal>&lt;&gt;</literal>, <literal>&gt;=</literal>, <literal>&gt;</literal>), and shell-style
+          wildcard comparisons (<literal>*</literal>, <literal>?</literal>, <literal>[]</literal>) are
+          supported with the <literal>$=</literal> (match) and <literal>!$=</literal> (non-match).</para>
+
+          <xi:include href="version-info.xml" xpointer="v249"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>ConditionMemoryPressure=</varname></term>
+          <term><varname>ConditionCPUPressure=</varname></term>
+          <term><varname>ConditionIOPressure=</varname></term>
+
+          <listitem><para>Verify that the overall system (memory, CPU or IO) pressure is below or equal to a threshold.
+          This setting takes a threshold value as argument. It can be specified as a simple percentage value,
+          suffixed with <literal>%</literal>, in which case the pressure will be measured as an average over the last
+          five minutes before the attempt to start the unit is performed.
+          Alternatively, the average timespan can also be specified using <literal>/</literal> as a separator, for
+          example: <literal>10%/1min</literal>. The supported timespans match what the kernel provides, and are
+          limited to <literal>10sec</literal>, <literal>1min</literal> and <literal>5min</literal>. The
+          <literal>full</literal> PSI will be checked first, and if not found <literal>some</literal> will be
+          checked. For more details, see the documentation on <ulink
+          url="https://docs.kernel.org/accounting/psi.html">PSI (Pressure Stall Information)
+          </ulink>.</para>
+
+          <para>Optionally, the threshold value can be prefixed with the slice unit under which the pressure will be checked,
+          followed by a <literal>:</literal>. If the slice unit is not specified, the overall system pressure will be measured,
+          instead of a particular cgroup's.</para>
+
+          <xi:include href="version-info.xml" xpointer="v250"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>AssertArchitecture=</varname></term>
+          <term><varname>AssertVirtualization=</varname></term>
+          <term><varname>AssertHost=</varname></term>
+          <term><varname>AssertKernelCommandLine=</varname></term>
+          <term><varname>AssertKernelVersion=</varname></term>
+          <term><varname>AssertCredential=</varname></term>
+          <term><varname>AssertEnvironment=</varname></term>
+          <term><varname>AssertSecurity=</varname></term>
+          <term><varname>AssertCapability=</varname></term>
+          <term><varname>AssertACPower=</varname></term>
+          <term><varname>AssertNeedsUpdate=</varname></term>
+          <term><varname>AssertFirstBoot=</varname></term>
+          <term><varname>AssertPathExists=</varname></term>
+          <term><varname>AssertPathExistsGlob=</varname></term>
+          <term><varname>AssertPathIsDirectory=</varname></term>
+          <term><varname>AssertPathIsSymbolicLink=</varname></term>
+          <term><varname>AssertPathIsMountPoint=</varname></term>
+          <term><varname>AssertPathIsReadWrite=</varname></term>
+          <term><varname>AssertPathIsEncrypted=</varname></term>
+          <term><varname>AssertDirectoryNotEmpty=</varname></term>
+          <term><varname>AssertFileNotEmpty=</varname></term>
+          <term><varname>AssertFileIsExecutable=</varname></term>
+          <term><varname>AssertUser=</varname></term>
+          <term><varname>AssertGroup=</varname></term>
+          <term><varname>AssertControlGroupController=</varname></term>
+          <term><varname>AssertMemory=</varname></term>
+          <term><varname>AssertCPUs=</varname></term>
+          <term><varname>AssertCPUFeature=</varname></term>
+          <term><varname>AssertOSRelease=</varname></term>
+          <term><varname>AssertMemoryPressure=</varname></term>
+          <term><varname>AssertCPUPressure=</varname></term>
+          <term><varname>AssertIOPressure=</varname></term>
+
+          <listitem><para>Similar to the <varname>ConditionArchitecture=</varname>,
+          <varname>ConditionVirtualization=</varname>, …, condition settings described above, these settings
+          add assertion checks to the start-up of the unit. However, unlike the conditions settings, any
+          assertion setting that is not met results in failure of the start job (which means this is logged
+          loudly). Note that hitting a configured assertion does not cause the unit to enter the
+          <literal>failed</literal> state (or in fact result in any state change of the unit), it affects
+          only the job queued for it. Use assertion expressions for units that cannot operate when specific
+          requirements are not met, and when this is something the administrator or user should look
+          into.</para>
+
+          <xi:include href="version-info.xml" xpointer="v218"/>
+          </listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <refsect1>
+    <title>Mapping of unit properties to their inverses</title>
+
+    <para>Unit settings that create a relationship with a second unit usually show up
+    in properties of both units, for example in <command>systemctl show</command>
+    output. In some cases the name of the property is the same as the name of the
+    configuration setting, but not always. This table lists the properties
+    that are shown on two units which are connected through some dependency, and shows
+    which property on "source" unit corresponds to which property on the "target" unit.
+    </para>
+
+    <table>
+      <title>
+        "Forward" and "reverse" unit properties
+      </title>
+
+      <tgroup cols='4'>
+        <colspec colname='forward' />
+        <colspec colname='reverse' />
+        <colspec colname='fuse' />
+        <colspec colname='ruse' />
+        <thead>
+          <row>
+            <entry>"Forward" property</entry>
+            <entry>"Reverse" property</entry>
+            <entry namest='fuse' nameend='ruse' valign='middle'>Where used</entry>
+          </row>
+        </thead>
+        <tbody>
+          <row>
+            <entry><varname>Before=</varname></entry>
+            <entry><varname>After=</varname></entry>
+            <entry morerows='1' namest='fuse' nameend='ruse' valign='middle'>[Unit] section</entry>
+          </row>
+          <row>
+            <entry><varname>After=</varname></entry>
+            <entry><varname>Before=</varname></entry>
+          </row>
+          <row>
+            <entry><varname>Requires=</varname></entry>
+            <entry><varname>RequiredBy=</varname></entry>
+            <entry>[Unit] section</entry>
+            <entry>[Install] section</entry>
+          </row>
+          <row>
+            <entry><varname>Wants=</varname></entry>
+            <entry><varname>WantedBy=</varname></entry>
+            <entry>[Unit] section</entry>
+            <entry>[Install] section</entry>
+          </row>
+          <row>
+            <entry><varname>Upholds=</varname></entry>
+            <entry><varname>UpheldBy=</varname></entry>
+            <entry>[Unit] section</entry>
+            <entry>[Install] section</entry>
+          </row>
+          <row>
+            <entry><varname>PartOf=</varname></entry>
+            <entry><varname>ConsistsOf=</varname></entry>
+            <entry>[Unit] section</entry>
+            <entry>an automatic property</entry>
+          </row>
+          <row>
+            <entry><varname>BindsTo=</varname></entry>
+            <entry><varname>BoundBy=</varname></entry>
+            <entry>[Unit] section</entry>
+            <entry>an automatic property</entry>
+          </row>
+          <row>
+            <entry><varname>Requisite=</varname></entry>
+            <entry><varname>RequisiteOf=</varname></entry>
+            <entry>[Unit] section</entry>
+            <entry>an automatic property</entry>
+          </row>
+          <row>
+            <entry><varname>Conflicts=</varname></entry>
+            <entry><varname>ConflictedBy=</varname></entry>
+            <entry>[Unit] section</entry>
+            <entry>an automatic property</entry>
+          </row>
+          <row>
+            <entry><varname>Triggers=</varname></entry>
+            <entry><varname>TriggeredBy=</varname></entry>
+            <entry namest='fuse' nameend='ruse' valign='middle'>Automatic properties, see notes below</entry>
+          </row>
+          <row>
+            <entry><varname>PropagatesReloadTo=</varname></entry>
+            <entry><varname>ReloadPropagatedFrom=</varname></entry>
+            <entry morerows='1' namest='fuse' nameend='ruse' valign='middle'>[Unit] section</entry>
+          </row>
+          <row>
+            <entry><varname>ReloadPropagatedFrom=</varname></entry>
+            <entry><varname>PropagatesReloadTo=</varname></entry>
+          </row>
+          <row>
+            <entry><varname>PropagatesStopTo=</varname></entry>
+            <entry><varname>StopPropagatedFrom=</varname></entry>
+            <entry morerows='1' namest='fuse' nameend='ruse' valign='middle'>[Unit] section</entry>
+          </row>
+          <row>
+            <entry><varname>StopPropagatedFrom=</varname></entry>
+            <entry><varname>PropagatesStopTo=</varname></entry>
+          </row>
+          <row>
+            <entry><varname>Following=</varname></entry>
+            <entry>n/a</entry>
+            <entry>An automatic property</entry>
+          </row>
+        </tbody>
+      </tgroup>
+    </table>
+
+    <para>Note: <varname>WantedBy=</varname>, <varname>RequiredBy=</varname>, and <varname>UpheldBy=</varname>
+    are used in the [Install] section to create symlinks in <filename>.wants/</filename>,
+    <filename>.requires/</filename>, and <filename>.upholds/</filename> directories. They cannot be used
+    directly as a unit configuration setting.</para>
+
+    <para>Note: <varname>ConsistsOf=</varname>, <varname>BoundBy=</varname>,
+    <varname>RequisiteOf=</varname>, <varname>ConflictedBy=</varname> are created
+    implicitly along with their reverses and cannot be specified directly.</para>
+
+    <para>Note: <varname>Triggers=</varname> is created implicitly between a socket,
+    path unit, or an automount unit, and the unit they activate. By default a unit
+    with the same name is triggered, but this can be overridden using
+    <varname>Sockets=</varname>, <varname>Service=</varname>, and <varname>Unit=</varname>
+    settings. See
+    <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    <citerefentry><refentrytitle>systemd.path</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    and
+    <citerefentry><refentrytitle>systemd.automount</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for details. <varname>TriggeredBy=</varname> is created implicitly on the
+    triggered unit.</para>
+
+    <para>Note: <varname>Following=</varname> is used to group device aliases and points to the
+    "primary" device unit that systemd is using to track device state, usually corresponding to a
+    sysfs path. It does not show up in the "target" unit.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>[Install] Section Options</title>
+
+    <para>Unit files may include an [Install] section, which carries installation information for
+    the unit. This section is not interpreted by
+    <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> during runtime; it is
+    used by the <command>enable</command> and <command>disable</command> commands of the
+    <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> tool during
+    installation of a unit.</para>
+
+    <variablelist class='unit-directives'>
+      <varlistentry>
+        <term><varname>Alias=</varname></term>
+
+        <listitem><para>A space-separated list of additional names this unit shall be installed under. The names listed
+        here must have the same suffix (i.e. type) as the unit filename. This option may be specified more than once,
+        in which case all listed names are used. At installation time, <command>systemctl enable</command> will create
+        symlinks from these names to the unit filename. Note that not all unit types support such alias names, and this
+        setting is not supported for them. Specifically, mount, slice, swap, and automount units do not support
+        aliasing.</para>
+
+        <xi:include href="version-info.xml" xpointer="v201"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>WantedBy=</varname></term>
+        <term><varname>RequiredBy=</varname></term>
+        <term><varname>UpheldBy=</varname></term>
+
+        <listitem><para>This option may be used more than once, or a space-separated list of unit names may
+        be given. A symbolic link is created in the <filename>.wants/</filename>, <filename>.requires/</filename>,
+        or <filename>.upholds/</filename> directory of each of the listed units when this unit is installed
+        by <command>systemctl enable</command>. This has the effect of a dependency of type
+        <varname>Wants=</varname>, <varname>Requires=</varname>, or <varname>Upholds=</varname> being added
+        from the listed unit to the current unit. See the description of the mentioned dependency types
+        in the [Unit] section for details.</para>
+
+        <para>In case of template units listing non template units, the listing unit must have
+        <varname>DefaultInstance=</varname> set, or <command>systemctl enable</command> must be called with
+        an instance name. The instance (default or specified) will be added to the
+        <filename>.wants/</filename>, <filename>.requires/</filename>, or <filename>.upholds/</filename>
+        list of the listed unit. For example, <command>WantedBy=getty.target</command> in a service
+        <filename>getty@.service</filename> will result in <command>systemctl enable getty@tty2.service</command>
+        creating a <filename>getty.target.wants/getty@tty2.service</filename> link to
+        <filename>getty@.service</filename>. This also applies to listing specific instances of templated
+        units: this specific instance will gain the dependency. A template unit may also list a template
+        unit, in which case a generic dependency will be added where each instance of the listing unit will
+        have a dependency on an instance of the listed template with the same instance value. For example,
+        <command>WantedBy=container@.target</command> in a service <filename>monitor@.service</filename> will
+        result in <command>systemctl enable monitor@.service</command> creating a
+        <filename>container@.target.wants/monitor@.service</filename> link to
+        <filename>monitor@.service</filename>, which applies to all instances of
+        <filename>container@.target</filename>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v201"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Also=</varname></term>
+
+        <listitem><para>Additional units to install/deinstall when
+        this unit is installed/deinstalled. If the user requests
+        installation/deinstallation of a unit with this option
+        configured, <command>systemctl enable</command> and
+        <command>systemctl disable</command> will automatically
+        install/uninstall units listed in this option as well.</para>
+
+        <para>This option may be used more than once, or a
+        space-separated list of unit names may be
+        given.</para>
+
+        <xi:include href="version-info.xml" xpointer="v201"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>DefaultInstance=</varname></term>
+
+        <listitem><para>In template unit files, this specifies for
+        which instance the unit shall be enabled if the template is
+        enabled without any explicitly set instance. This option has
+        no effect in non-template unit files. The specified string
+        must be usable as instance identifier.</para>
+
+        <xi:include href="version-info.xml" xpointer="v215"/></listitem>
+      </varlistentry>
+    </variablelist>
+
+    <para>The following specifiers are interpreted in the Install section:
+    %a, %b, %B, %g, %G, %H, %i, %j, %l, %m, %n, %N, %o, %p, %u, %U, %v, %w, %W, %%.
+    For their meaning see the next section.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Specifiers</title>
+
+    <para>Many settings resolve specifiers which may be used to write
+    generic unit files referring to runtime or unit parameters that
+    are replaced when the unit files are loaded. Specifiers must be known
+    and resolvable for the setting to be valid. The following
+    specifiers are understood:</para>
+
+    <table class='specifiers'>
+      <title>Specifiers available in unit files</title>
+      <tgroup cols='3' align='left' colsep='1' rowsep='1'>
+        <colspec colname="spec" />
+        <colspec colname="mean" />
+        <colspec colname="detail" />
+        <thead>
+          <row>
+            <entry>Specifier</entry>
+            <entry>Meaning</entry>
+            <entry>Details</entry>
+          </row>
+        </thead>
+        <tbody>
+          <row>
+            <!-- We do not use the common definition from standard-specifiers.xml here since it includes a
+                 reference onto our own man page, which would make the rendered version self-referential. -->
+            <entry><literal>%a</literal></entry>
+            <entry>Architecture</entry>
+            <entry>A short string identifying the architecture of the local system. A string such as <constant>x86</constant>, <constant>x86-64</constant> or <constant>arm64</constant>. See the architectures defined for <varname>ConditionArchitecture=</varname> above for a full list.</entry>
+          </row>
+          <xi:include href="standard-specifiers.xml" xpointer="A"/>
+          <xi:include href="standard-specifiers.xml" xpointer="b"/>
+          <xi:include href="standard-specifiers.xml" xpointer="B"/>
+          <row>
+            <entry><literal>%C</literal></entry>
+            <entry>Cache directory root</entry>
+            <entry>This is either <filename>/var/cache</filename> (for the system manager) or the path <literal>$XDG_CACHE_HOME</literal> resolves to (for user managers).</entry>
+          </row>
+          <row>
+            <entry><literal>%d</literal></entry>
+            <entry>Credentials directory</entry>
+            <entry>This is the value of the <literal>$CREDENTIALS_DIRECTORY</literal> environment variable if available. See section "Credentials" in <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> for more information.</entry>
+          </row>
+          <row>
+            <entry><literal>%E</literal></entry>
+            <entry>Configuration directory root</entry>
+            <entry>This is either <filename>/etc/</filename> (for the system manager) or the path <literal>$XDG_CONFIG_HOME</literal> resolves to (for user managers).</entry>
+          </row>
+          <row>
+            <entry><literal>%f</literal></entry>
+            <entry>Unescaped filename</entry>
+            <entry>This is either the unescaped instance name (if applicable) with <filename>/</filename> prepended (if applicable), or the unescaped prefix name prepended with <filename>/</filename>. This implements unescaping according to the rules for escaping absolute file system paths discussed above.</entry>
+          </row>
+          <row>
+            <entry><literal>%g</literal></entry>
+            <entry>User group</entry>
+            <entry>This is the name of the group running the service manager instance. In case of the system manager this resolves to <literal>root</literal>.</entry>
+          </row>
+          <row>
+            <entry><literal>%G</literal></entry>
+            <entry>User GID</entry>
+            <entry>This is the numeric GID of the user running the service manager instance. In case of the system manager this resolves to <literal>0</literal>.</entry>
+          </row>
+          <row>
+            <entry><literal>%h</literal></entry>
+            <entry>User home directory</entry>
+            <entry>This is the home directory of the <emphasis>user running the service manager instance</emphasis>. In case of the system manager this resolves to <literal>/root</literal>.
+
+Note that this setting is <emphasis>not</emphasis> influenced by the <varname>User=</varname> setting configurable in the [Service] section of the service unit.</entry>
+          </row>
+          <row>
+            <!-- We do not use the common definition from standard-specifiers.xml here since we want a
+                 slightly more verbose explanation here, referring to the reload cycle. -->
+            <entry><literal>%H</literal></entry>
+            <entry>Host name</entry>
+            <entry>The hostname of the running system at the point in time the unit configuration is loaded.</entry>
+          </row>
+          <row>
+            <entry><literal>%i</literal></entry>
+            <entry>Instance name</entry>
+            <entry>For instantiated units this is the string between the first <literal>@</literal> character and the type suffix. Empty for non-instantiated units.</entry>
+          </row>
+          <row>
+            <entry><literal>%I</literal></entry>
+            <entry>Unescaped instance name</entry>
+            <entry>Same as <literal>%i</literal>, but with escaping undone.</entry>
+          </row>
+          <row>
+            <entry><literal>%j</literal></entry>
+            <entry>Final component of the prefix</entry>
+            <entry>This is the string between the last <literal>-</literal> and the end of the prefix name. If there is no <literal>-</literal>, this is the same as <literal>%p</literal>.</entry>
+          </row>
+          <row>
+            <entry><literal>%J</literal></entry>
+            <entry>Unescaped final component of the prefix</entry>
+            <entry>Same as <literal>%j</literal>, but with escaping undone.</entry>
+          </row>
+          <row>
+            <entry><literal>%l</literal></entry>
+            <!-- We do not use the common definition from standard-specifiers.xml here since we want a
+                 slightly more verbose explanation here, referring to the reload cycle. -->
+            <entry>Short host name</entry>
+            <entry>The hostname of the running system at the point in time the unit configuration is loaded, truncated at the first dot to remove any domain component.</entry>
+          </row>
+          <row>
+            <entry><literal>%L</literal></entry>
+            <entry>Log directory root</entry>
+            <entry>This is either <filename>/var/log</filename> (for the system manager) or the path <varname>$XDG_STATE_HOME</varname> resolves to with <filename index="false">/log</filename> appended (for user managers).</entry>
+          </row>
+          <xi:include href="standard-specifiers.xml" xpointer="m"/>
+          <xi:include href="standard-specifiers.xml" xpointer="M"/>
+          <row>
+            <entry><literal>%n</literal></entry>
+            <entry>Full unit name</entry>
+            <entry></entry>
+          </row>
+          <row>
+            <entry><literal>%N</literal></entry>
+            <entry>Full unit name</entry>
+            <entry>Same as <literal>%n</literal>, but with the type suffix removed.</entry>
+          </row>
+          <xi:include href="standard-specifiers.xml" xpointer="o"/>
+          <row>
+            <entry><literal>%p</literal></entry>
+            <entry>Prefix name</entry>
+            <entry>For instantiated units, this refers to the string before the first <literal>@</literal> character of the unit name. For non-instantiated units, same as <literal>%N</literal>.</entry>
+          </row>
+          <row>
+            <entry><literal>%P</literal></entry>
+            <entry>Unescaped prefix name</entry>
+            <entry>Same as <literal>%p</literal>, but with escaping undone.</entry>
+          </row>
+          <row>
+            <!-- We do not use the common definition from standard-specifiers.xml here since we want a
+                 slightly more verbose explanation here, referring to the reload cycle. -->
+            <entry><literal>%q</literal></entry>
+            <entry>Pretty host name</entry>
+            <entry>The pretty hostname of the running system at the point in time the unit configuration is loaded, as read from the <varname>PRETTY_HOSTNAME=</varname> field of <filename>/etc/machine-info</filename>. If not set, resolves to the short hostname. See <citerefentry><refentrytitle>machine-info</refentrytitle><manvolnum>5</manvolnum></citerefentry> for more information.</entry>
+          </row>
+          <row>
+            <entry><literal>%s</literal></entry>
+            <entry>User shell</entry>
+            <entry>This is the shell of the user running the service manager instance.</entry>
+          </row>
+          <row>
+            <entry><literal>%S</literal></entry>
+            <entry>State directory root</entry>
+            <entry>This is either <filename>/var/lib</filename> (for the system manager) or the path <varname>$XDG_STATE_HOME</varname> resolves to (for user managers).</entry>
+          </row>
+          <row>
+            <entry><literal>%t</literal></entry>
+            <entry>Runtime directory root</entry>
+            <entry>This is either <filename>/run/</filename> (for the system manager) or the path <literal>$XDG_RUNTIME_DIR</literal> resolves to (for user managers).</entry>
+          </row>
+          <xi:include href="standard-specifiers.xml" xpointer="T"/>
+          <row>
+            <entry><literal>%u</literal></entry>
+            <entry>User name</entry>
+            <entry>This is the name of the <emphasis>user running the service manager instance</emphasis>. In case of the system manager this resolves to <literal>root</literal>.
+
+Note that this setting is <emphasis>not</emphasis> influenced by the <varname>User=</varname> setting configurable in the [Service] section of the service unit.</entry>
+          </row>
+          <row>
+            <entry><literal>%U</literal></entry>
+            <entry>User UID</entry>
+            <entry>This is the numeric UID of the <emphasis>user running the service manager instance</emphasis>. In case of the system manager this resolves to <literal>0</literal>.
+
+Note that this setting is <emphasis>not</emphasis> influenced by the <varname>User=</varname> setting configurable in the [Service] section of the service unit.</entry>
+          </row>
+          <xi:include href="standard-specifiers.xml" xpointer="v"/>
+          <xi:include href="standard-specifiers.xml" xpointer="V"/>
+          <xi:include href="standard-specifiers.xml" xpointer="w"/>
+          <xi:include href="standard-specifiers.xml" xpointer="W"/>
+          <row>
+            <entry><literal>%y</literal></entry>
+            <entry>The path to the fragment</entry>
+            <entry>This is the path where the main part of the unit file is located. For linked unit files, the real path outside of the unit search directories is used. For units that don't have a fragment file, this specifier will raise an error.</entry>
+          </row>
+          <row>
+            <entry><literal>%Y</literal></entry>
+            <entry>The directory of the fragment</entry>
+            <entry>This is the directory part of <literal>%y</literal>.</entry>
+          </row>
+          <xi:include href="standard-specifiers.xml" xpointer="percent"/>
+        </tbody>
+      </tgroup>
+    </table>
+  </refsect1>
+
+  <refsect1>
+    <title>Examples</title>
+
+    <example>
+      <title>Allowing units to be enabled</title>
+
+      <para>The following snippet (highlighted) allows a unit (e.g.
+      <filename>foo.service</filename>) to be enabled via
+      <command>systemctl enable</command>:</para>
+
+      <programlisting>[Unit]
+Description=Foo
+
+[Service]
+ExecStart=/usr/sbin/foo-daemon
+
+<emphasis>[Install]</emphasis>
+<emphasis>WantedBy=multi-user.target</emphasis></programlisting>
+
+      <para>After running <command>systemctl enable</command>, a
+      symlink
+      <filename index="false">/etc/systemd/system/multi-user.target.wants/foo.service</filename>
+      linking to the actual unit will be created. It tells systemd to
+      pull in the unit when starting
+      <filename>multi-user.target</filename>. The inverse
+      <command>systemctl disable</command> will remove that symlink
+      again.</para>
+    </example>
+
+    <example>
+      <title>Overriding vendor settings</title>
+
+      <para>There are two methods of overriding vendor settings in
+      unit files: copying the unit file from
+      <filename>/usr/lib/systemd/system</filename> to
+      <filename>/etc/systemd/system</filename> and modifying the
+      chosen settings. Alternatively, one can create a directory named
+      <filename><replaceable>unit</replaceable>.d/</filename> within
+      <filename>/etc/systemd/system</filename> and place a drop-in
+      file <filename><replaceable>name</replaceable>.conf</filename>
+      there that only changes the specific settings one is interested
+      in. Note that multiple such drop-in files are read if
+      present, processed in lexicographic order of their filename.</para>
+
+      <para>The advantage of the first method is that one easily
+      overrides the complete unit, the vendor unit is not parsed at
+      all anymore. It has the disadvantage that improvements to the
+      unit file by the vendor are not automatically incorporated on
+      updates.</para>
+
+      <para>The advantage of the second method is that one only
+      overrides the settings one specifically wants, where updates to
+      the unit by the vendor automatically apply. This has the
+      disadvantage that some future updates by the vendor might be
+      incompatible with the local changes.</para>
+
+      <para>This also applies for user instances of systemd, but with
+      different locations for the unit files. See the section on unit
+      load paths for further details.</para>
+
+      <para>Suppose there is a vendor-supplied unit
+      <filename>/usr/lib/systemd/system/httpd.service</filename> with
+      the following contents:</para>
+
+      <programlisting>[Unit]
+Description=Some HTTP server
+After=remote-fs.target sqldb.service
+Requires=sqldb.service
+AssertPathExists=/srv/webserver
+
+[Service]
+Type=notify
+ExecStart=/usr/sbin/some-fancy-httpd-server
+Nice=5
+
+[Install]
+WantedBy=multi-user.target</programlisting>
+
+      <para>Now one wants to change some settings as an administrator:
+      firstly, in the local setup, <filename>/srv/webserver</filename>
+      might not exist, because the HTTP server is configured to use
+      <filename>/srv/www</filename> instead. Secondly, the local
+      configuration makes the HTTP server also depend on a memory
+      cache service, <filename>memcached.service</filename>, that
+      should be pulled in (<varname>Requires=</varname>) and also be
+      ordered appropriately (<varname>After=</varname>). Thirdly, in
+      order to harden the service a bit more, the administrator would
+      like to set the <varname>PrivateTmp=</varname> setting (see
+      <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+      for details). And lastly, the administrator would like to reset
+      the niceness of the service to its default value of 0.</para>
+
+      <para>The first possibility is to copy the unit file to
+      <filename>/etc/systemd/system/httpd.service</filename> and
+      change the chosen settings:</para>
+
+      <programlisting>[Unit]
+Description=Some HTTP server
+After=remote-fs.target sqldb.service <emphasis>memcached.service</emphasis>
+Requires=sqldb.service <emphasis>memcached.service</emphasis>
+AssertPathExists=<emphasis>/srv/www</emphasis>
+
+[Service]
+Type=notify
+ExecStart=/usr/sbin/some-fancy-httpd-server
+<emphasis>Nice=0</emphasis>
+<emphasis>PrivateTmp=yes</emphasis>
+
+[Install]
+WantedBy=multi-user.target</programlisting>
+
+      <para>Alternatively, the administrator could create a drop-in
+      file
+      <filename>/etc/systemd/system/httpd.service.d/local.conf</filename>
+      with the following contents:</para>
+
+      <programlisting>[Unit]
+After=memcached.service
+Requires=memcached.service
+# Reset all assertions and then re-add the condition we want
+AssertPathExists=
+AssertPathExists=/srv/www
+
+[Service]
+Nice=0
+PrivateTmp=yes</programlisting>
+
+      <para>Note that for drop-in files, if one wants to remove
+      entries from a setting that is parsed as a list (and is not a
+      dependency), such as <varname>AssertPathExists=</varname> (or
+      e.g. <varname>ExecStart=</varname> in service units), one needs
+      to first clear the list before re-adding all entries except the
+      one that is to be removed. Dependencies (<varname>After=</varname>, etc.)
+      cannot be reset to an empty list, so dependencies can only be
+      added in drop-ins. If you want to remove dependencies, you have
+      to override the entire unit.</para>
+
+    </example>
+
+    <example>
+      <title>Top level drop-ins with template units</title>
+
+      <para>Top level per-type drop-ins can be used to change some aspect of
+      all units of a particular type. For example, by creating the
+      <filename index='false'>/etc/systemd/system/service.d/</filename>
+      directory with a drop-in file, the contents of the drop-in file can be
+      applied to all service units. We can take this further by having the
+      top-level drop-in instantiate a secondary helper unit. Consider for
+      example the following set of units and drop-in files where we install
+      an <varname>OnFailure=</varname> dependency for all service units.</para>
+
+      <para>
+      <filename index='false'>/etc/systemd/system/failure-handler@.service</filename>:</para>
+
+      <programlisting>[Unit]
+Description=My failure handler for %i
+
+[Service]
+Type=oneshot
+# Perform some special action for when %i exits unexpectedly.
+ExecStart=/usr/sbin/myfailurehandler %i
+     </programlisting>
+
+     <para>We can then add an instance of
+     <filename index='false'>failure-handler@.service</filename> as an
+     <varname>OnFailure=</varname> dependency for all service units.</para>
+
+    <para>
+    <filename index='false'>/etc/systemd/system/service.d/10-all.conf</filename>:</para>
+
+    <programlisting>[Unit]
+OnFailure=failure-handler@%N.service
+    </programlisting>
+
+    <para>Now, after running <command>systemctl daemon-reload</command> all
+    services will have acquired an <varname>OnFailure=</varname> dependency on
+    <filename index='false'>failure-handler@%N.service</filename>. The
+    template instance units will also have gained the dependency which results
+    in the creation of a recursive dependency chain. systemd will try to detect
+    these recursive dependency chains where a template unit directly and
+    recursively depends on itself and will remove such dependencies
+    automatically if it finds them. If systemd doesn't detect the recursive
+    dependency chain, we can break the chain ourselves by disabling the drop-in
+    for the template instance units via a symlink to
+    <filename index='false'>/dev/null</filename>:</para>
+
+    <programlisting>
+<command>mkdir /etc/systemd/system/failure-handler@.service.d/</command>
+<command>ln -s /dev/null /etc/systemd/system/failure-handler@.service.d/10-all.conf</command>
+<command>systemctl daemon-reload</command>
+    </programlisting>
+
+    <para>This ensures that if a <filename index='false'>failure-handler@.service</filename> instance fails it will not trigger an instance named
+    <filename index='false'>failure-handler@failure-handler.service</filename>.</para>
+
+    </example>
+
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.device</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.automount</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.swap</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.path</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.scope</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-analyze</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>capabilities</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>uname</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/systemd.xml b/man/systemd.xml
new file mode 100644
index 0000000..42da750
--- /dev/null
+++ b/man/systemd.xml
@@ -0,0 +1,1463 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="systemd"
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>systemd</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>systemd</refentrytitle>
+    <manvolnum>1</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>systemd</refname>
+    <refname>init</refname>
+    <refpurpose>systemd system and service manager</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <cmdsynopsis>
+      <command>/usr/lib/systemd/systemd</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+    </cmdsynopsis>
+    <cmdsynopsis>
+      <command>init</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="req">COMMAND</arg>
+    </cmdsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>systemd is a system and service manager for Linux operating systems. When run as first process on
+    boot (as PID 1), it acts as init system that brings up and maintains userspace services. Separate
+    instances are started for logged-in users to start their services.</para>
+
+    <para><command>systemd</command> is usually not invoked directly by the user, but is installed as the
+    <filename>/sbin/init</filename> symlink and started during early boot. The user manager instances are
+    started automatically through the
+    <citerefentry><refentrytitle>user@.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    service.</para>
+
+    <para>For compatibility with SysV, if the binary is called as <command>init</command> and is not the
+    first process on the machine (PID is not 1), it will execute <command>telinit</command> and pass all
+    command line arguments unmodified. That means <command>init</command> and <command>telinit</command> are
+    mostly equivalent when invoked from normal login sessions. See
+    <citerefentry><refentrytitle>telinit</refentrytitle><manvolnum>8</manvolnum></citerefentry> for more
+    information.</para>
+
+    <para>When run as a system instance, systemd interprets the
+    configuration file <filename>system.conf</filename> and the files
+    in <filename>system.conf.d</filename> directories; when run as a
+    user instance, systemd interprets the configuration file
+    <filename>user.conf</filename> and the files in
+    <filename>user.conf.d</filename> directories. See
+    <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for more information.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Concepts</title>
+
+    <para>systemd provides a dependency system between various
+    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
+    described in
+    <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+    however some are created automatically from other configuration
+    files, dynamically from system state or programmatically at runtime.
+    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
+    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, 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>
+
+    <orderedlist>
+      <listitem><para>Service units, which start and control daemons
+      and the processes they consist of. For details, see
+      <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
+
+      <listitem><para>Socket units, which encapsulate local IPC or
+      network sockets in the system, useful for socket-based
+      activation. For details about socket units, see
+      <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      for details on socket-based activation and other forms of
+      activation, see
+      <citerefentry><refentrytitle>daemon</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para></listitem>
+
+      <listitem><para>Target units are useful to group units, or
+      provide well-known synchronization points during boot-up, see
+      <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
+
+      <listitem><para>Device units expose kernel devices in systemd
+      and may be used to implement device-based activation. For
+      details, see
+      <citerefentry><refentrytitle>systemd.device</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
+
+      <listitem><para>Mount units control mount points in the file
+      system, for details see
+      <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
+
+      <listitem><para>Automount units provide automount capabilities,
+      for on-demand mounting of file systems as well as parallelized
+      boot-up. See
+      <citerefentry><refentrytitle>systemd.automount</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>
+
+      <listitem><para>Swap units are very similar to mount units and
+      encapsulate memory swap partitions or files of the operating
+      system. They are described in
+      <citerefentry><refentrytitle>systemd.swap</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
+
+      <listitem><para>Path units may be used to activate other
+      services when file system objects change or are modified. See
+      <citerefentry><refentrytitle>systemd.path</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
+
+      <listitem><para>Slice units may be used to group units which
+      manage system processes (such as service and scope units) in a
+      hierarchical tree for resource management purposes. See
+      <citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
+
+      <listitem><para>Scope units are similar to service units, but
+      manage foreign processes instead of starting them as well. See
+      <citerefentry><refentrytitle>systemd.scope</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
+
+    </orderedlist>
+
+    <para>Units are named as their configuration files. Some units
+    have special semantics. A detailed list is available in
+    <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
+
+    <para>systemd knows various kinds of dependencies, including
+    positive and negative requirement dependencies (i.e.
+    <varname>Requires=</varname> and <varname>Conflicts=</varname>) as
+    well as ordering dependencies (<varname>After=</varname> and
+    <varname>Before=</varname>). NB: ordering and requirement
+    dependencies are orthogonal. If only a requirement dependency
+    exists between two units (e.g. <filename>foo.service</filename>
+    requires <filename>bar.service</filename>), but no ordering
+    dependency (e.g. <filename>foo.service</filename> after
+    <filename>bar.service</filename>) and both are requested to start,
+    they will be started in parallel. It is a common pattern that both
+    requirement and ordering dependencies are placed between two
+    units. Also note that the majority of dependencies are implicitly
+    created and maintained by systemd. In most cases, it should be
+    unnecessary to declare additional dependencies manually, however
+    it is possible to do this.</para>
+
+    <para>Application programs and units (via dependencies) may
+    request state changes of units. In systemd, these requests are
+    encapsulated as 'jobs' and maintained in a job queue. Jobs may
+    succeed or can fail, their execution is ordered based on the
+    ordering dependencies of the units they have been scheduled
+    for.</para>
+
+    <para>On boot systemd activates the target unit
+    <filename>default.target</filename> whose job is to activate
+    on-boot services and other on-boot units by pulling them in via
+    dependencies. Usually, the unit name is just an alias (symlink) for
+    either <filename>graphical.target</filename> (for fully-featured
+    boots into the UI) or <filename>multi-user.target</filename> (for
+    limited console-only boots for use in embedded or server
+    environments, or similar; a subset of graphical.target). However,
+    it is at the discretion of the administrator to configure it as an
+    alias to any other target unit. See
+    <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+    for details about these target units.</para>
+
+    <para>On first boot, <command>systemd</command> will enable or disable units according to preset policy.
+    See <citerefentry><refentrytitle>systemd.preset</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    and "First Boot Semantics" in
+    <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</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 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://docs.kernel.org/admin-guide/cgroup-v2.html">Control Groups v2</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 via the file system
+    hierarchy (beneath <filename>/sys/fs/cgroup/</filename>), or in tools such as <citerefentry
+    project='man-pages'><refentrytitle>systemd-cgls</refentrytitle><manvolnum>1</manvolnum></citerefentry> or
+    <citerefentry
+    project='man-pages'><refentrytitle>ps</refentrytitle><manvolnum>1</manvolnum></citerefentry> (<command>ps
+    xawf -eo pid,user,cgroup,args</command> is particularly useful to list all processes and the systemd
+    units they belong to.).</para>
+
+    <para>systemd is compatible with the SysV init system to a large
+    degree: SysV init scripts are supported and simply read as an
+    alternative (though limited) configuration file format. The SysV
+    <filename>/dev/initctl</filename> interface is provided, and
+    compatibility implementations of the various SysV client tools are
+    available. In addition to that, various established Unix
+    functionality such as <filename>/etc/fstab</filename> or the
+    <filename>utmp</filename> database are supported.</para>
+
+    <para>systemd has a minimal transaction system: if a unit is
+    requested to start up or shut down it will add it and all its
+    dependencies to a temporary transaction. Then, it will verify if
+    the transaction is consistent (i.e. whether the ordering of all
+    units is cycle-free). If it is not, systemd will try to fix it up,
+    and removes non-essential jobs from the transaction that might
+    remove the loop. Also, systemd tries to suppress non-essential
+    jobs in the transaction that would stop a running service. Finally
+    it is checked whether the jobs of the transaction contradict jobs
+    that have already been queued, and optionally the transaction is
+    aborted then. If all worked out and the transaction is consistent
+    and minimized in its impact it is merged with all already
+    outstanding jobs and added to the run queue. Effectively this
+    means that before executing a requested operation, systemd will
+    verify that it makes sense, fixing it if possible, and only
+    failing if it really cannot work.</para>
+
+    <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
+    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
+    <filename>/sys/</filename> or <filename>/proc/</filename>.</para>
+
+    <para>For more information about the concepts and
+    ideas behind systemd, please refer to the
+    <ulink url="https://0pointer.de/blog/projects/systemd.html">Original Design Document</ulink>.</para>
+
+    <para>Note that some but not all interfaces provided by systemd are covered by the
+    <ulink url="https://systemd.io/PORTABILITY_AND_STABILITY/">Interface Portability and Stability Promise</ulink>.</para>
+
+    <para>Units may be generated dynamically at boot and system
+    manager reload time, for example based on other configuration
+    files or parameters passed on the kernel command line. For details, see
+    <citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
+
+    <para>The D-Bus API of <command>systemd</command> is described in
+    <citerefentry><refentrytitle>org.freedesktop.systemd1</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    and
+    <citerefentry><refentrytitle>org.freedesktop.LogControl1</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+    </para>
+
+    <para>Systems which invoke systemd in a container or initrd environment should implement the <ulink
+    url="https://systemd.io/CONTAINER_INTERFACE">Container Interface</ulink> or
+    <ulink url="https://systemd.io/INITRD_INTERFACE/">initrd Interface</ulink>
+    specifications, respectively.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Directories</title>
+
+    <variablelist>
+      <varlistentry>
+        <term>System unit directories</term>
+
+        <listitem><para>The systemd system manager reads unit
+        configuration from various directories. Packages that want to
+        install unit files shall place them in the directory returned
+        by <command>pkg-config systemd
+        --variable=systemdsystemunitdir</command>. Other directories
+        checked are <filename>/usr/local/lib/systemd/system</filename>
+        and <filename>/usr/lib/systemd/system</filename>. User
+        configuration always takes precedence. <command>pkg-config
+        systemd --variable=systemdsystemconfdir</command> returns the
+        path of the system configuration directory. Packages should
+        alter the content of these directories only with the
+        <command>enable</command> and <command>disable</command>
+        commands of the
+        <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+        tool. Full list of directories is provided in
+        <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+        </para></listitem>
+      </varlistentry>
+    </variablelist>
+
+    <variablelist>
+      <varlistentry>
+        <term>User unit directories</term>
+
+        <listitem><para>Similar rules apply for the user unit
+        directories. However, here the
+        <ulink url="https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html">XDG
+        Base Directory specification</ulink> is followed to find
+        units. Applications should place their unit files in the
+        directory returned by <command>pkg-config systemd
+        --variable=systemduserunitdir</command>. Global configuration
+        is done in the directory reported by <command>pkg-config
+        systemd --variable=systemduserconfdir</command>. The
+        <command>enable</command> and <command>disable</command>
+        commands of the
+        <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+        tool can handle both global (i.e. for all users) and private
+        (for one user) enabling/disabling of units. Full list of
+        directories is provided in
+        <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+        </para></listitem>
+      </varlistentry>
+    </variablelist>
+
+    <variablelist>
+      <varlistentry>
+        <term>SysV init scripts directory</term>
+
+        <listitem><para>The location of the SysV init script directory
+        varies between distributions. If systemd cannot find a native
+        unit file for a requested service, it will look for a SysV
+        init script of the same name (with the
+        <filename>.service</filename> suffix
+        removed).</para></listitem>
+      </varlistentry>
+    </variablelist>
+
+    <variablelist>
+      <varlistentry>
+        <term>SysV runlevel link farm directory</term>
+
+        <listitem><para>The location of the SysV runlevel link farm
+        directory varies between distributions. systemd will take the
+        link farm into account when figuring out whether a service
+        shall be enabled. Note that a service unit with a native unit
+        configuration file cannot be started by activating it in the
+        SysV runlevel link farm.</para></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Signals</title>
+
+    <variablelist>
+      <varlistentry>
+        <term><constant>SIGTERM</constant></term>
+
+        <listitem><para>Upon receiving this signal the systemd system
+        manager serializes its state, reexecutes itself and
+        deserializes the saved state again. This is mostly equivalent
+        to <command>systemctl daemon-reexec</command>.</para>
+
+        <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
+        --job-mode=replace-irreversibly</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 ctrl-alt-del.target --job-mode=replace-irreversibly</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>
+      </varlistentry>
+
+      <varlistentry>
+        <term><constant>SIGWINCH</constant></term>
+
+        <listitem><para>When this signal is received the systemd
+        system manager will start the
+        <filename>kbrequest.target</filename> unit. This is mostly
+        equivalent to <command>systemctl start
+        kbrequest.target</command>.</para>
+
+        <para>This signal is ignored by systemd user
+        managers.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><constant>SIGPWR</constant></term>
+
+        <listitem><para>When this signal is received the systemd
+        manager will start the <filename>sigpwr.target</filename>
+        unit. This is mostly equivalent to <command>systemctl start
+        sigpwr.target</command>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><constant>SIGUSR1</constant></term>
+
+        <listitem><para>When this signal is received the systemd
+        manager will try to reconnect to the D-Bus
+        bus.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><constant>SIGUSR2</constant></term>
+
+        <listitem><para>When this signal is received the systemd
+        manager will log its complete state in human-readable form.
+        The data logged is the same as printed by
+        <command>systemd-analyze dump</command>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><constant>SIGHUP</constant></term>
+
+        <listitem><para>Reloads the complete daemon configuration.
+        This is mostly equivalent to <command>systemctl
+        daemon-reload</command>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><constant>SIGRTMIN+0</constant></term>
+
+        <listitem><para>Enters default mode, starts the
+        <filename>default.target</filename> unit. This is mostly
+        equivalent to <command>systemctl isolate
+        default.target</command>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><constant>SIGRTMIN+1</constant></term>
+
+        <listitem><para>Enters rescue mode, starts the
+        <filename>rescue.target</filename> unit. This is mostly
+        equivalent to <command>systemctl isolate
+        rescue.target</command>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><constant>SIGRTMIN+2</constant></term>
+
+        <listitem><para>Enters emergency mode, starts the
+        <filename>emergency.service</filename> unit. This is mostly
+        equivalent to <command>systemctl isolate
+        emergency.service</command>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><constant>SIGRTMIN+3</constant></term>
+
+        <listitem><para>Halts the machine, starts the
+        <filename>halt.target</filename> unit. This is mostly
+        equivalent to <command>systemctl start halt.target
+        --job-mode=replace-irreversibly</command>.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><constant>SIGRTMIN+4</constant></term>
+
+        <listitem><para>Powers off the machine, starts the
+        <filename>poweroff.target</filename> unit. This is mostly
+        equivalent to <command>systemctl start poweroff.target
+        --job-mode=replace-irreversibly</command>.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><constant>SIGRTMIN+5</constant></term>
+
+        <listitem><para>Reboots the machine, starts the
+        <filename>reboot.target</filename> unit. This is mostly
+        equivalent to <command>systemctl start reboot.target
+        --job-mode=replace-irreversibly</command>.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><constant>SIGRTMIN+6</constant></term>
+
+        <listitem><para>Reboots the machine via kexec, starts the
+        <filename>kexec.target</filename> unit. This is mostly
+        equivalent to <command>systemctl start kexec.target
+        --job-mode=replace-irreversibly</command>.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><constant>SIGRTMIN+7</constant></term>
+
+        <listitem><para>Reboots userspace, starts the <filename>soft-reboot.target</filename> unit. This is
+        mostly equivalent to <command>systemctl start soft-reboot.target
+        --job-mode=replace-irreversibly</command>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><constant>SIGRTMIN+13</constant></term>
+
+        <listitem><para>Immediately halts the machine.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><constant>SIGRTMIN+14</constant></term>
+
+        <listitem><para>Immediately powers off the machine.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><constant>SIGRTMIN+15</constant></term>
+
+        <listitem><para>Immediately reboots the machine.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><constant>SIGRTMIN+16</constant></term>
+
+        <listitem><para>Immediately reboots the machine with kexec.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><constant>SIGRTMIN+17</constant></term>
+
+        <listitem><para>Immediately reboots the userspace.</para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><constant>SIGRTMIN+20</constant></term>
+
+        <listitem><para>Enables display of status messages on the
+        console, as controlled via
+        <varname>systemd.show_status=1</varname> on the kernel command
+        line.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><constant>SIGRTMIN+21</constant></term>
+
+        <listitem><para>Disables display of
+        status messages on the console, as
+        controlled via
+        <varname>systemd.show_status=0</varname>
+        on the kernel command
+        line.</para></listitem>
+      </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>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>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><constant>SIGRTMIN+24</constant></term>
+
+        <listitem><para>Immediately exits the manager (only available
+        for --user instances).</para>
+
+        <xi:include href="version-info.xml" xpointer="v195"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><constant>SIGRTMIN+25</constant></term>
+
+        <listitem><para>Upon receiving this signal the systemd manager will reexecute itself. This
+        is mostly equivalent to <command>systemctl daemon-reexec</command> except that it will be
+        done asynchronously.</para>
+
+        <para>The systemd system manager treats this signal the same way as
+        <constant>SIGTERM</constant>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </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>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><constant>SIGRTMIN+27</constant></term>
+        <term><constant>SIGRTMIN+28</constant></term>
+
+        <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>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Environment</title>
+
+    <para>The environment block for the system manager is initially set by the kernel. (In particular,
+    <literal>key=value</literal> assignments on the kernel command line are turned into environment
+    variables for PID 1). For the user manager, the system manager sets the environment as described in the
+    "Environment Variables in Spawned Processes" section of
+    <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>. The
+    <varname>DefaultEnvironment=</varname> setting in the system manager applies to all services including
+    <filename>user@.service</filename>. Additional entries may be configured (as for any other service)
+    through the <varname>Environment=</varname> and <varname>EnvironmentFile=</varname> settings for
+    <filename>user@.service</filename> (see
+    <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>). Also,
+    additional environment variables may be set through the <varname>ManagerEnvironment=</varname> setting in
+    <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    and
+    <citerefentry><refentrytitle>systemd-user.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+    </para>
+
+    <para>Some of the variables understood by <command>systemd</command>:</para>
+
+    <variablelist class='environment-variables'>
+      <varlistentry>
+        <term><varname>$SYSTEMD_LOG_LEVEL</varname></term>
+        <listitem><xi:include href="common-variables.xml" xpointer="log-level-body" />
+
+        <para>This can be overridden with <option>--log-level=</option>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>$SYSTEMD_LOG_COLOR</varname></term>
+        <listitem><xi:include href="common-variables.xml" xpointer="log-color-body" />
+
+        <para>This can be overridden with <option>--log-color=</option>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>$SYSTEMD_LOG_TIME</varname></term>
+        <listitem><xi:include href="common-variables.xml" xpointer="log-time-body" />
+
+        <para>This can be overridden with <option>--log-time=</option>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>$SYSTEMD_LOG_LOCATION</varname></term>
+        <listitem><xi:include href="common-variables.xml" xpointer="log-location-body" />
+
+        <para>This can be overridden with <option>--log-location=</option>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>$SYSTEMD_LOG_TID</varname></term>
+        <listitem><xi:include href="common-variables.xml" xpointer="log-tid-body" />
+
+        <xi:include href="version-info.xml" xpointer="v247"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>$SYSTEMD_LOG_TARGET</varname></term>
+        <listitem><xi:include href="common-variables.xml" xpointer="log-target-body" />
+
+        <para>This can be overridden with <option>--log-target=</option>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>$SYSTEMD_LOG_RATELIMIT_KMSG</varname></term>
+        <listitem><xi:include href="common-variables.xml" xpointer="log-ratelimit-kmsg-body" />
+
+        <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>$XDG_CONFIG_HOME</varname></term>
+        <term><varname>$XDG_CONFIG_DIRS</varname></term>
+        <term><varname>$XDG_DATA_HOME</varname></term>
+        <term><varname>$XDG_DATA_DIRS</varname></term>
+
+        <listitem><para>The systemd user manager uses these variables
+        in accordance to the <ulink
+        url="https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html">XDG
+        Base Directory specification</ulink> to find its
+        configuration.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>$SYSTEMD_UNIT_PATH</varname></term>
+        <term><varname>$SYSTEMD_GENERATOR_PATH</varname></term>
+        <term><varname>$SYSTEMD_ENVIRONMENT_GENERATOR_PATH</varname></term>
+
+        <listitem><para>Controls where systemd looks for unit files and
+        generators.</para>
+        <para>These variables may contain a list of paths, separated by colons
+        (<literal>:</literal>). When set, if the list ends with an empty
+        component (<literal>...:</literal>), this list is prepended to the
+        usual set of paths. Otherwise, the specified list replaces the usual
+        set of paths.
+        </para></listitem>
+      </varlistentry>
+
+      <xi:include href="common-variables.xml" xpointer="pager"/>
+      <xi:include href="common-variables.xml" xpointer="less"/>
+      <xi:include href="common-variables.xml" xpointer="lesscharset"/>
+      <xi:include href="common-variables.xml" xpointer="lesssecure"/>
+      <xi:include href="common-variables.xml" xpointer="colors"/>
+      <xi:include href="common-variables.xml" xpointer="urlify"/>
+
+      <varlistentry>
+        <term><varname>$LISTEN_PID</varname></term>
+        <term><varname>$LISTEN_FDS</varname></term>
+        <term><varname>$LISTEN_FDNAMES</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>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>$NOTIFY_SOCKET</varname></term>
+
+        <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>
+      </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>
+    <title>Kernel Command Line</title>
+
+    <para>When run as the system instance, systemd parses a number of options listed below. They can be
+    specified as kernel command line arguments which are parsed from a number of sources depending on the
+    environment in which systemd is executed. If run inside a Linux container, these options are parsed from
+    the command line arguments passed to systemd itself, next to any of the command line options listed in
+    the Options section above. If run outside of Linux containers, these arguments are parsed from
+    <filename>/proc/cmdline</filename> and from the <literal>SystemdOptions</literal> EFI variable
+    (on EFI systems) instead. Options from <filename>/proc/cmdline</filename> have higher priority.</para>
+
+    <para>Note: use of <literal>SystemdOptions</literal> is deprecated.</para>
+
+    <para>The following variables are understood:</para>
+
+    <variablelist class='kernel-commandline-options'>
+      <varlistentry>
+        <term><varname>systemd.unit=</varname></term>
+        <term><varname>rd.systemd.unit=</varname></term>
+
+        <listitem><para>Overrides the unit to activate on boot.  Defaults to
+        <filename>default.target</filename>. This may be used to temporarily boot into a different boot unit,
+        for example <filename>rescue.target</filename> or <filename>emergency.service</filename>. See
+        <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+        for details about these units. The option prefixed with <literal>rd.</literal> is honored only in the
+        initrd, while the one that is not prefixed only in the main system.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>systemd.dump_core</varname></term>
+
+        <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>
+
+        <xi:include href="version-info.xml" xpointer="v233"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>systemd.crash_chvt</varname></term>
+
+        <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 when it crashes.
+        Defaults to disabled, meaning that no such switch is attempted. If set to enabled, the virtual
+        terminal the kernel messages are written to is used instead.</para>
+
+        <xi:include href="version-info.xml" xpointer="v233"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>systemd.crash_shell</varname></term>
+
+        <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>
+
+        <xi:include href="version-info.xml" xpointer="v233"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>systemd.crash_reboot</varname></term>
+
+        <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>
+
+        <xi:include href="version-info.xml" xpointer="v227"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>systemd.confirm_spawn</varname></term>
+
+        <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>
+
+        <xi:include href="version-info.xml" xpointer="v233"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <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>
+
+        <xi:include href="version-info.xml" xpointer="v237"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>systemd.show_status</varname></term>
+
+        <listitem><para>Takes a boolean argument or the constants <constant>error</constant> and
+        <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. With <constant>error</constant>, only messages about failures are shown, but
+        boot is otherwise quiet. <constant>auto</constant> behaves like <option>false</option> until 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>error</constant>. If specified overrides
+        the system manager configuration file option <option>ShowStatus=</option>, see
+        <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v233"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>systemd.status_unit_format=</varname></term>
+
+        <listitem><para>Takes <option>name</option>, <option>description</option> or
+        <option>combined</option> as the value. If <option>name</option>, the system manager will use unit
+        names in status messages. If <option>combined</option>, the system manager will use unit names and
+        description in status messages. When specified, overrides the system manager configuration file
+        option <option>StatusUnitFormat=</option>, see
+        <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v243"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>systemd.log_color</varname></term>
+        <term><varname>systemd.log_level=</varname></term>
+        <term><varname>systemd.log_location</varname></term>
+        <term><varname>systemd.log_target=</varname></term>
+        <term><varname>systemd.log_time</varname></term>
+        <term><varname>systemd.log_tid</varname></term>
+        <term><varname>systemd.log_ratelimit_kmsg</varname></term>
+
+        <listitem><para>Controls log output, with the same effect as the
+        <varname>$SYSTEMD_LOG_COLOR</varname>, <varname>$SYSTEMD_LOG_LEVEL</varname>,
+        <varname>$SYSTEMD_LOG_LOCATION</varname>, <varname>$SYSTEMD_LOG_TARGET</varname>,
+        <varname>$SYSTEMD_LOG_TIME</varname>, <varname>$SYSTEMD_LOG_TID</varname> and
+        <varname>$SYSTEMD_LOG_RATELIMIT_KMSG</varname> environment variables described above.
+        <varname>systemd.log_color</varname>, <varname>systemd.log_location</varname>,
+        <varname>systemd.log_time</varname>, <varname>systemd.log_tid</varname> and
+        <varname>systemd.log_ratelimit_kmsg</varname> can be specified without
+        an argument, with the same effect as a positive boolean.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>systemd.default_standard_output=</varname></term>
+        <term><varname>systemd.default_standard_error=</varname></term>
+
+        <listitem><para>Controls default standard output and error output for services and sockets. That is,
+        controls the default for <option>StandardOutput=</option> and <option>StandardError=</option> (see
+        <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
+        details). Takes one of <option>inherit</option>, <option>null</option>, <option>tty</option>,
+        <option>journal</option>, <option>journal+console</option>, <option>kmsg</option>,
+        <option>kmsg+console</option>. If the argument is omitted
+        <varname>systemd.default-standard-output=</varname> defaults to <option>journal</option> and
+        <varname>systemd.default-standard-error=</varname> to <option>inherit</option>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>systemd.setenv=</varname></term>
+
+        <listitem><para>Takes a string argument in the form
+        VARIABLE=VALUE. May be used to set default environment
+        variables to add to forked child processes. May be used more
+        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>
+
+        <xi:include href="version-info.xml" xpointer="v229"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>systemd.set_credential=</varname></term>
+        <term><varname>systemd.set_credential_binary=</varname></term>
+
+        <listitem><para>Sets a system credential, which can then be propagated to system services using the
+        <varname>ImportCredential=</varname> or <varname>LoadCredential=</varname> setting, see
+        <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
+        details. Takes a pair of credential name and value, separated by a colon. The
+        <varname>systemd.set_credential=</varname> parameter expects the credential value in literal text
+        form, the <varname>systemd.set_credential_binary=</varname> parameter takes binary data encoded in
+        Base64. Note that the kernel command line is typically accessible by unprivileged programs in
+        <filename>/proc/cmdline</filename>. Thus, this mechanism is not suitable for transferring sensitive
+        data. Use it only for data that is not sensitive (e.g. public keys/certificates, rather than private
+        keys), or in testing/debugging environments.</para>
+
+        <para>For further information see <ulink url="https://systemd.io/CREDENTIALS">System and Service
+        Credentials</ulink> documentation.</para>
+
+        <xi:include href="version-info.xml" xpointer="v251"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>systemd.import_credentials=</varname></term>
+
+        <listitem><para>Takes a boolean argument. If false disables importing credentials from the kernel
+        command line, the DMI/SMBIOS OEM string table, the qemu_fw_cfg subsystem or the EFI kernel
+        stub.</para>
+
+        <xi:include href="version-info.xml" xpointer="v251"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>quiet</varname></term>
+
+        <listitem><para>Turn off status output at boot, much like
+        <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.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v186"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>debug</varname></term>
+
+        <listitem><para>Turn on debugging output. This is equivalent
+        to <varname>systemd.log_level=debug</varname>. Note that this
+        option is also read by the kernel itself and enables kernel
+        debug output. Passing this option hence turns on the debug
+        output from both the system manager and the
+        kernel.</para>
+
+        <xi:include href="version-info.xml" xpointer="v205"/></listitem>
+      </varlistentry>
+
+      <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> or
+        <varname>rd.systemd.unit=emergency.target</varname>, respectively, and
+        provided for compatibility reasons and to be easier to type.</para>
+
+        <xi:include href="version-info.xml" xpointer="v186"/></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> or
+        <varname>rd.systemd.unit=rescue.target</varname>, respectively, and
+        provided for compatibility reasons and to be easier to type.</para>
+
+        <xi:include href="version-info.xml" xpointer="v186"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>2</varname></term>
+        <term><varname>3</varname></term>
+        <term><varname>4</varname></term>
+        <term><varname>5</varname></term>
+
+        <listitem><para>Boot into the specified legacy SysV runlevel.
+        These are equivalent to
+        <varname>systemd.unit=runlevel2.target</varname>,
+        <varname>systemd.unit=runlevel3.target</varname>,
+        <varname>systemd.unit=runlevel4.target</varname>, and
+        <varname>systemd.unit=runlevel5.target</varname>,
+        respectively, and provided for compatibility reasons and to be
+        easier to type.</para>
+
+        <xi:include href="version-info.xml" xpointer="v186"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>locale.LANG=</varname></term>
+        <term><varname>locale.LANGUAGE=</varname></term>
+        <term><varname>locale.LC_CTYPE=</varname></term>
+        <term><varname>locale.LC_NUMERIC=</varname></term>
+        <term><varname>locale.LC_TIME=</varname></term>
+        <term><varname>locale.LC_COLLATE=</varname></term>
+        <term><varname>locale.LC_MONETARY=</varname></term>
+        <term><varname>locale.LC_MESSAGES=</varname></term>
+        <term><varname>locale.LC_PAPER=</varname></term>
+        <term><varname>locale.LC_NAME=</varname></term>
+        <term><varname>locale.LC_ADDRESS=</varname></term>
+        <term><varname>locale.LC_TELEPHONE=</varname></term>
+        <term><varname>locale.LC_MEASUREMENT=</varname></term>
+        <term><varname>locale.LC_IDENTIFICATION=</varname></term>
+
+        <listitem><para>Set the system locale to use. This overrides
+        the settings in <filename>/etc/locale.conf</filename>. For
+        more information, see
+        <citerefentry project='man-pages'><refentrytitle>locale.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        and
+        <citerefentry project='man-pages'><refentrytitle>locale</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v186"/></listitem>
+      </varlistentry>
+    </variablelist>
+
+    <para>For other kernel command line parameters understood by
+    components of the core OS, please refer to
+    <citerefentry><refentrytitle>kernel-command-line</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>System credentials</title>
+
+    <para>During initialization the service manager will import credentials from various sources into the
+    system's set of credentials, which can then be propagated into services and consumed by
+    generators:</para>
+
+    <itemizedlist>
+      <listitem><para>When the service manager first initializes it will read system credentials from SMBIOS
+      Type 11 vendor strings
+      <varname>io.systemd.credential:<replaceable>name</replaceable>=<replaceable>value</replaceable></varname>,
+      and
+      <varname>io.systemd.credential.binary:<replaceable>name</replaceable>=<replaceable>value</replaceable></varname>.</para></listitem>
+
+      <listitem><para>At the same time it will import credentials from QEMU <literal>fw_cfg</literal>. (Note
+      that the SMBIOS mechanism is generally preferred, because it is faster and generic.)</para></listitem>
+
+      <listitem><para>Credentials may be passed via the kernel command line, using the
+      <varname>systemd.set-credential=</varname> parameter, see above.</para></listitem>
+
+      <listitem><para>Credentials may be passed from the UEFI environment via
+      <citerefentry><refentrytitle>systemd-stub</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para></listitem>
+
+      <listitem><para>When the service manager is invoked during the initrd → host transition it will import
+      all files in <filename>/run/credentials/@initrd/</filename> as system credentials.</para></listitem>
+    </itemizedlist>
+
+    <para>Invoke
+    <citerefentry><refentrytitle>systemd-creds</refentrytitle><manvolnum>1</manvolnum></citerefentry> as
+    follows to see the list of credentials passed into the system:</para>
+
+    <programlisting># systemd-creds --system list</programlisting>
+
+    <para>For further information see <ulink url="https://systemd.io/CREDENTIALS">System and Service
+    Credentials</ulink> documentation.</para>
+
+    <para>The service manager when run as PID 1 consumes the following system credentials:</para>
+
+    <variablelist class='system-credentials'>
+      <varlistentry>
+        <term><varname>vmm.notify_socket</varname></term>
+        <listitem>
+          <para>Contains a <constant>AF_VSOCK</constant> or <constant>AF_UNIX</constant> address where to
+          send a <constant>READY=1</constant> notification datagram when the system has finished booting. See
+          <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry> for
+          more information. Note that in case the hypervisor does not support <constant>SOCK_DGRAM</constant>
+          over <constant>AF_VSOCK</constant>, <constant>SOCK_SEQPACKET</constant> will be tried instead. The
+          credential payload for <constant>AF_VSOCK</constant> should be in the form
+          <literal>vsock:CID:PORT</literal>.</para>
+
+          <para>This feature is useful for hypervisors/VMMs or other processes on the host to receive a
+          notification via VSOCK when a virtual machine has finished booting.</para>
+
+          <xi:include href="version-info.xml" xpointer="v254"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>system.machine_id</varname></term>
+        <listitem>
+          <para>Takes a 128bit hexadecimal ID to initialize <filename>/etc/machine-id</filename> from, if the
+          file is not set up yet. See
+          <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
+          details.</para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para><command>systemd</command> is only very rarely invoked directly, since it is started early and is
+    already running by the time users may interact with it. Normally, tools like
+    <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> are used to
+    give commands to the manager. Since <command>systemd</command> is usually not invoked directly, the
+    options listed below are mostly useful for debugging and special purposes.</para>
+
+    <refsect2>
+      <title>Introspection and debugging options</title>
+
+      <para>Those options are used for testing and introspection, and <command>systemd</command> may
+      be invoked with them at any time:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><option>--dump-configuration-items</option></term>
+
+          <listitem><para>Dump understood unit configuration items. This 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 on D-Bus.</para>
+
+          <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><option>--test</option></term>
+
+          <listitem><para>Determine the initial start-up transaction (i.e. the list of jobs enqueued at
+          start-up), dump it and exit — without actually executing any of the determined jobs. This option is
+          useful for debugging only. Note that during regular service manager start-up additional units not
+          shown by this operation may be started, because hardware, socket, bus or other kinds of activation
+          might add additional jobs as the transaction is executed. Use <option>--system</option> to request
+          the initial transaction of the system service manager (this is also the implied default), combine
+          with <option>--user</option> to request the initial transaction of the per-user service manager
+          instead.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><option>--system</option></term>
+          <term><option>--user</option></term>
+
+          <listitem><para>When used in conjunction with <option>--test</option>, selects whether to calculate
+          the initial transaction for the system instance or for a per-user instance. These options have no
+          effect when invoked without <option>--test</option>, as during regular
+          (i.e. non-<option>--test</option>) invocations the service manager will automatically detect
+          whether it shall operate in system or per-user mode, by checking whether the PID it is run as is 1
+          or not. Note that it is not supported booting and maintaining a system with the service manager
+          running in <option>--system</option> mode but with a PID other than 1.</para></listitem>
+        </varlistentry>
+
+        <xi:include href="standard-options.xml" xpointer="help" />
+        <xi:include href="standard-options.xml" xpointer="version" />
+      </variablelist>
+    </refsect2>
+
+    <refsect2>
+      <title>Options that duplicate kernel command line settings</title>
+
+      <para>Those options correspond directly to options listed above in "Kernel Command Line". Both forms
+      may be used equivalently for the system manager, but it is recommended to use the forms listed above in
+      this context, because they are properly namespaced. When an option is specified both on the kernel
+      command line and as a normal command line argument, the latter has higher precedence.</para>
+
+      <para>When <command>systemd</command> is used as a user manager, the kernel command line is ignored and
+      only the options described below are understood. Nevertheless, <command>systemd</command> is usually
+      started in this mode through the
+      <citerefentry><refentrytitle>user@.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+      service, which is shared between all users. It may be more convenient to use configuration files to
+      modify settings (see
+      <citerefentry><refentrytitle>systemd-user.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>),
+      or environment variables. See the "Environment" section above for a discussion of how the environment
+      block is set.</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><option>--unit=</option></term>
+
+          <listitem><para>Set default unit to activate on startup. If not specified, defaults to
+          <filename>default.target</filename>. See <varname>systemd.unit=</varname> above.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><option>--dump-core</option></term>
+
+          <listitem><para>Enable core dumping on crash. This switch has no effect when running as user
+          instance. Same as <varname>systemd.dump_core=</varname> above.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><option>--crash-vt=</option><replaceable>VT</replaceable></term>
+
+          <listitem><para>Switch to a specific virtual console (VT) on crash. This switch has no effect when
+          running as user instance. Same as <varname>systemd.crash_chvt=</varname> above (but not the
+          different spelling!).</para>
+
+          <xi:include href="version-info.xml" xpointer="v227"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><option>--crash-shell</option></term>
+
+          <listitem><para>Run a shell on crash. This switch has no effect when running as user instance. See
+          <varname>systemd.crash_shell=</varname> above.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><option>--crash-reboot</option></term>
+
+          <listitem><para>Automatically reboot the system on crash. This switch has no effect when running as
+          user instance. See <varname>systemd.crash_reboot</varname> above.</para>
+
+          <xi:include href="version-info.xml" xpointer="v227"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><option>--confirm-spawn</option></term>
+
+          <listitem><para>Ask for confirmation when spawning processes. This switch has no effect when run as
+          user instance. See <varname>systemd.confirm_spawn</varname> above.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><option>--show-status</option></term>
+
+          <listitem><para>Show terse unit status information on the console during boot-up and shutdown. See
+          <varname>systemd.show_status</varname> above.</para>
+
+          <xi:include href="version-info.xml" xpointer="v244"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><option>--log-color</option></term>
+
+          <listitem><para>Highlight important log messages. See <varname>systemd.log_color</varname> above.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v244"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><option>--log-level=</option></term>
+
+          <listitem><para>Set log level. See <varname>systemd.log_level</varname> above.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><option>--log-location</option></term>
+
+          <listitem><para>Include code location in log messages. See <varname>systemd.log_location</varname>
+          above.</para>
+
+          <xi:include href="version-info.xml" xpointer="v244"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><option>--log-target=</option></term>
+
+          <listitem><para>Set log target. See <varname>systemd.log_target</varname> above.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><option>--log-time=</option></term>
+
+          <listitem><para>Prefix console messages with timestamp. See <varname>systemd.log_time</varname> above.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><option>--machine-id=</option></term>
+
+          <listitem><para>Override the machine-id set on the hard drive. See
+          <varname>systemd.machine_id=</varname> above.</para>
+
+          <xi:include href="version-info.xml" xpointer="v229"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><option>--service-watchdogs</option></term>
+
+          <listitem><para>Globally enable/disable all service watchdog timeouts and emergency actions. See
+          <varname>systemd.service_watchdogs</varname> above.</para>
+
+          <xi:include href="version-info.xml" xpointer="v237"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><option>--default-standard-output=</option></term>
+          <term><option>--default-standard-error=</option></term>
+
+          <listitem><para>Sets the default output or error output for all services and sockets,
+          respectively. See <varname>systemd.default_standard_output=</varname> and
+          <varname>systemd.default_standard_error=</varname> above.</para></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <refsect1>
+    <title>Sockets and FIFOs</title>
+
+    <variablelist>
+      <varlistentry>
+        <term><filename>/run/systemd/notify</filename></term>
+
+        <listitem><para>Daemon status notification socket. This is an
+        <constant>AF_UNIX</constant> datagram socket and is used to
+        implement the daemon notification logic as implemented by
+        <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para></listitem>
+
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>/run/systemd/private</filename></term>
+
+        <listitem><para>Used internally as communication channel
+        between
+        <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+        and the systemd process. This is an
+        <constant>AF_UNIX</constant> stream socket. This interface is
+        private to systemd and should not be used in external
+        projects.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><filename>/dev/initctl</filename></term>
+
+        <listitem><para>Limited compatibility support for the SysV
+        client interface, as implemented by the
+        <filename>systemd-initctl.service</filename> unit. This is a
+        named pipe in the file system. This interface is obsolete and
+        should not be used in new applications.</para></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+      <title>History</title>
+
+      <variablelist>
+        <varlistentry>
+          <term>systemd 252</term>
+          <listitem><para>Kernel command-line arguments <varname>systemd.unified_cgroup_hierarchy</varname>
+          and <varname>systemd.legacy_systemd_cgroup_controller</varname> were deprecated. Please switch to
+          the unified cgroup hierarchy.</para>
+
+          <xi:include href="version-info.xml" xpointer="v252"/></listitem>
+        </varlistentry>
+      </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      The <ulink url="https://systemd.io/">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>,
+      <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-notify</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>daemon</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>sd-daemon</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>org.freedesktop.systemd1</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry project='die-net'><refentrytitle>pkg-config</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>kernel-command-line</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>bootup</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sysupdate.d.xml b/man/sysupdate.d.xml
new file mode 100644
index 0000000..00b4ac8
--- /dev/null
+++ b/man/sysupdate.d.xml
@@ -0,0 +1,951 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="sysupdate.d" conditional='ENABLE_SYSUPDATE'
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sysupdate.d</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sysupdate.d</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sysupdate.d</refname>
+    <refpurpose>Transfer Definition Files for Automatic Updates</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><literallayout><filename>/etc/sysupdate.d/*.conf</filename>
+<filename>/run/sysupdate.d/*.conf</filename>
+<filename>/usr/lib/sysupdate.d/*.conf</filename>
+    </literallayout></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><filename>sysupdate.d/*.conf</filename> files describe how specific resources on the local system
+    shall be updated from a remote source. Each such file defines one such transfer: typically a remote
+    HTTP/HTTPS resource as source; and a local file, directory or partition as target. This may be used as a
+    simple, automatic, atomic update mechanism for the OS itself, for containers, portable services or system
+    extension images — but in fact may be used to update any kind of file from a remote source.</para>
+
+    <para>The
+    <citerefentry><refentrytitle>systemd-sysupdate</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    command reads these files and uses them to determine which local resources should be updated, and then
+    executes the update.</para>
+
+    <para>Both the remote HTTP/HTTPS source and the local target typically exist in multiple, concurrent
+    versions, in order to implement flexible update schemes, e.g. A/B updating (or a superset thereof,
+    e.g. A/B/C, A/B/C/D, …).</para>
+
+    <para>Each <filename>*.conf</filename> file defines one transfer, i.e. describes one resource to
+    update. Typically, multiple of these files (i.e. multiple of such transfers) are defined together, and
+    are bound together by a common version identifier in order to update multiple resources at once on each
+    update operation, for example to update a kernel, a root file system and a Verity partition in a single,
+    combined, synchronized operation, so that only a combined update of all three together constitutes a
+    complete update.</para>
+
+    <para>Each <filename>*.conf</filename> file contains three sections: [Transfer], [Source] and [Target].</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Basic Mode of Operation</title>
+
+    <para>Disk-image based OS updates typically consist of multiple different resources that need to be
+    updated together, for example a secure OS update might consist of a root file system image to drop into a
+    partition, a matching Verity integrity data partition image, and a kernel image prepared to boot into the
+    combination of the two partitions. The first two resources are files that are downloaded and placed in a
+    disk partition, the latter is a file that is downloaded and placed in a regular file in the boot file
+    system (e.g. EFI system partition). Hence, during an update of a hypothetical operating system "foobarOS"
+    to a hypothetical version 47 the following operations should take place:</para>
+
+    <orderedlist>
+      <listitem><para>A file <literal>https://download.example.com/foobarOS_47.root.xz</literal> should be
+      downloaded, decompressed and written to a previously unused partition with GPT partition type UUID
+      4f68bce3-e8cd-4db1-96e7-fbcaf984b709 for x86-64, as per <ulink
+      url="https://uapi-group.org/specifications/specs/discoverable_partitions_specification">Discoverable Partitions
+      Specification</ulink>.</para></listitem>
+
+      <listitem><para>Similarly, a file <literal>https://download.example.com/foobarOS_47.verity.xz</literal>
+      should be downloaded, decompressed and written to a previously empty partition with GPT partition type
+      UUID of 2c7357ed-ebd2-46d9-aec1-23d437ec2bf5 (i.e. the partition type for Verity integrity information
+      for x86-64 root file systems).</para></listitem>
+
+      <listitem><para>Finally, a file <literal>https://download.example.com/foobarOS_47.efi.xz</literal> (a
+      unified kernel, as per <ulink url="https://uapi-group.org/specifications/specs/boot_loader_specification">Boot Loader
+      Specification</ulink> Type #2) should be downloaded, decompressed and written to the $BOOT file system,
+      i.e. to <filename>EFI/Linux/foobarOS_47.efi</filename> in the ESP or XBOOTLDR partition.</para></listitem>
+    </orderedlist>
+
+    <para>The version-independent generalization of this would be (using the special marker
+    <literal>@v</literal> as wildcard for the version identifier):</para>
+
+    <orderedlist>
+      <listitem><para>A transfer of a file <literal>https://download.example.com/foobarOS_@v.root.xz</literal>
+      → a local, previously empty GPT partition of type 4f68bce3-e8cd-4db1-96e7-fbcaf984b709, with the label to
+      be set to <literal>foobarOS_@v</literal>.</para></listitem>
+
+      <listitem><para>A transfer of a file <literal>https://download.example.com/foobarOS_@v.verity.xz</literal>
+      → a local, previously empty GPT partition of type 2c7357ed-ebd2-46d9-aec1-23d437ec2bf5, with the label to be
+      set to <literal>foobarOS_@v_verity</literal>.</para></listitem>
+
+      <listitem><para>A transfer of a file <literal>https://download.example.com/foobarOS_@v.efi.xz</literal>
+      → a local file <filename>$BOOT/EFI/Linux/foobarOS_@v.efi</filename>.</para></listitem>
+    </orderedlist>
+
+    <para>An update can only complete if the relevant URLs provide their resources for the same version,
+    i.e. for the same value of <literal>@v</literal>.</para>
+
+    <para>The above may be translated into three <filename>*.conf</filename> files in
+    <filename>sysupdate.d/</filename>, one for each resource to transfer. The <filename>*.conf</filename>
+    files configure the type of download, and what place to write the download to (i.e. whether to a
+    partition or a file in the file system). Most importantly these files contain the URL, partition name and
+    filename patterns shown above that describe how these resources are called on the source and how they
+    shall be called on the target.</para>
+
+    <para>In order to enumerate available versions and figuring out candidates to update to, a mechanism is
+    necessary to list suitable files:</para>
+
+    <itemizedlist>
+      <listitem><para>For partitions: the surrounding GPT partition table contains a list of defined
+      partitions, including a partition type UUID and a partition label (in this scheme the partition label
+      plays a role for the partition similar to the filename for a regular file).</para></listitem>
+
+      <listitem><para>For regular files: the directory listing of the directory the files are contained in
+      provides a list of existing files in a straightforward way.</para></listitem>
+
+      <listitem><para>For HTTP/HTTPS sources a simple scheme is used: a manifest file
+      <filename>SHA256SUMS</filename>, following the format defined by <citerefentry
+      project='man-pages'><refentrytitle>sha256sum</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      lists file names and their SHA256 hashes.</para></listitem>
+    </itemizedlist>
+
+    <para>Transfers are done in the alphabetical order of the <filename>.conf</filename> file names they are
+    defined in. First, the resource data is downloaded directly into a target file/directory/partition. Once
+    this is completed for all defined transfers, in a second step the files/directories/partitions are
+    renamed to their final names as defined by the target <varname>MatchPattern=</varname>, again in the
+    order the <filename>.conf</filename> transfer file names dictate. This step is not atomic, however it is
+    guaranteed to be executed strictly in order with suitable disk synchronization in place. Typically, when
+    updating an OS one of the transfers defines the entry point when booting. Thus it is generally a good idea
+    to order the resources via the transfer configuration file names so that the entry point is written
+    last, ensuring that any abnormal termination does not leave an entry point around whose backing is not
+    established yet. In the example above it would hence make sense to establish the EFI kernel image last
+    and thus give its transfer configuration file the alphabetically last name.</para>
+
+    <para>See below for an extended, more specific example based on the above.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Resource Types</title>
+
+    <para>Each transfer file defines one source resource to transfer to one target resource. The following
+    resource types are supported:</para>
+
+    <orderedlist>
+
+      <listitem><para>Resources of type <literal>url-file</literal> encapsulate a file on a web server,
+      referenced via a HTTP or HTTPS URL. When an update takes place, the file is downloaded and decompressed
+      and then written to the target file or partition. This resource type is only available for sources, not
+      for targets. The list of available versions of resources of this type is encoded in
+      <filename>SHA256SUMS</filename> manifest files, accompanied by
+      <filename>SHA256SUMS.gpg</filename> detached signatures.</para></listitem>
+
+      <listitem><para>The <literal>url-tar</literal> resource type is similar, but the file must be a
+      <filename>.tar</filename> archive. When an update takes place, the file is decompressed and unpacked
+      into a directory or btrfs subvolume. This resource type is only available for sources, not for
+      targets. Just like <literal>url-file</literal>, <literal>url-tar</literal> version enumeration makes
+      use of <filename>SHA256SUMS</filename> files, authenticated via
+      <filename>SHA256SUMS.gpg</filename>.</para></listitem>
+
+      <listitem><para>The <literal>regular-file</literal> resource type encapsulates a local regular file on
+      disk. During updates the file is uncompressed and written to the target file or partition. This
+      resource type is available both as source and as target. When updating no integrity or authentication
+      verification is done for resources of this type.</para></listitem>
+
+      <listitem><para>The <literal>partition</literal> resource type is similar to
+      <literal>regular-file</literal>, and encapsulates a GPT partition on disk. When updating, the partition
+      must exist already, and have the correct GPT partition type. A partition whose GPT partition label is
+      set to <literal>_empty</literal> is considered empty, and a candidate to place a newly downloaded
+      resource in. The GPT partition label is used to store version information, once a partition is
+      updated. This resource type is only available for target resources.</para></listitem>
+
+      <listitem><para>The <literal>tar</literal> resource type encapsulates local <filename>.tar</filename>
+      archive files. When an update takes place, the files are uncompressed and unpacked into a target
+      directory or btrfs subvolume. Behaviour of <literal>tar</literal> and <literal>url-tar</literal> is
+      generally similar, but the latter downloads from remote sources, and does integrity and authentication
+      checks while the former does not. The <literal>tar</literal> resource type is only available for source
+      resources.</para></listitem>
+
+      <listitem><para>The <literal>directory</literal> resource type encapsulates local directory trees. This
+      type is available both for source and target resources. If an update takes place on a source resource
+      of this type, a recursive copy of the directory is done.</para></listitem>
+
+      <listitem><para>The <literal>subvolume</literal> resource type is identical to
+      <literal>directory</literal>, except when used as the target, in which case the file tree is placed in
+      a btrfs subvolume instead of a plain directory, if the backing file system supports it (i.e. is
+      btrfs).</para></listitem>
+    </orderedlist>
+
+    <para>As already indicated, only a subset of source and target resource type combinations are
+    supported:</para>
+
+    <table>
+      <title>Resource Types</title>
+
+      <tgroup cols='3' align='left' colsep='1' rowsep='1'>
+        <colspec colname="name" />
+        <colspec colname="explanation" />
+
+        <thead>
+          <row>
+            <entry>Identifier</entry>
+            <entry>Description</entry>
+            <entry>Usable as Source</entry>
+            <entry>When Used as Source: Compatible Targets</entry>
+            <entry>When Used as Source: Integrity + Authentication</entry>
+            <entry>When Used as Source: Decompression</entry>
+            <entry>Usable as Target</entry>
+            <entry>When Used as Target: Compatible Sources</entry>
+          </row>
+        </thead>
+
+        <tbody>
+          <row>
+            <entry><constant>url-file</constant></entry>
+            <entry>HTTP/HTTPS files</entry>
+            <entry>yes</entry>
+            <entry><constant>regular-file</constant>, <constant>partition</constant></entry>
+            <entry>yes</entry>
+            <entry>yes</entry>
+            <entry>no</entry>
+            <entry>-</entry>
+          </row>
+
+          <row>
+            <entry><constant>url-tar</constant></entry>
+            <entry>HTTP/HTTPS <filename>.tar</filename> archives</entry>
+            <entry>yes</entry>
+            <entry><constant>directory</constant>, <constant>subvolume</constant></entry>
+            <entry>yes</entry>
+            <entry>yes</entry>
+            <entry>no</entry>
+            <entry>-</entry>
+          </row>
+
+          <row>
+            <entry><constant>regular-file</constant></entry>
+            <entry>Local files</entry>
+            <entry>yes</entry>
+            <entry><constant>regular-file</constant>, <constant>partition</constant></entry>
+            <entry>no</entry>
+            <entry>yes</entry>
+            <entry>yes</entry>
+            <entry><constant>url-file</constant>, <constant>regular-file</constant></entry>
+          </row>
+
+          <row>
+            <entry><constant>partition</constant></entry>
+            <entry>Local GPT partitions</entry>
+            <entry>no</entry>
+            <entry>-</entry>
+            <entry>-</entry>
+            <entry>-</entry>
+            <entry>yes</entry>
+            <entry><constant>url-file</constant>, <constant>regular-file</constant></entry>
+          </row>
+
+          <row>
+            <entry><constant>tar</constant></entry>
+            <entry>Local <filename>.tar</filename> archives</entry>
+            <entry>yes</entry>
+            <entry><constant>directory</constant>, <constant>subvolume</constant></entry>
+            <entry>no</entry>
+            <entry>yes</entry>
+            <entry>no</entry>
+            <entry>-</entry>
+          </row>
+
+          <row>
+            <entry><constant>directory</constant></entry>
+            <entry>Local directories</entry>
+            <entry>yes</entry>
+            <entry><constant>directory</constant>, <constant>subvolume</constant></entry>
+            <entry>no</entry>
+            <entry>no</entry>
+            <entry>yes</entry>
+            <entry><constant>url-tar</constant>, <constant>tar</constant>, <constant>directory</constant>, <constant>subvolume</constant></entry>
+          </row>
+
+          <row>
+            <entry><constant>subvolume</constant></entry>
+            <entry>Local btrfs subvolumes</entry>
+            <entry>yes</entry>
+            <entry><constant>directory</constant>, <constant>subvolume</constant></entry>
+            <entry>no</entry>
+            <entry>no</entry>
+            <entry>yes</entry>
+            <entry><constant>url-tar</constant>, <constant>tar</constant>, <constant>directory</constant>, <constant>subvolume</constant></entry>
+          </row>
+
+        </tbody>
+      </tgroup>
+    </table>
+  </refsect1>
+
+  <refsect1>
+    <title>Match Patterns</title>
+
+    <para>Both the source and target resources typically exist in multiple versions concurrently. An update
+    operation is done whenever the newest of the source versions is newer than the newest of the target
+    versions. To determine the newest version of the resources a directory listing, partition listing or
+    manifest listing is used, a subset of qualifying entries selected from that, and the version identifier
+    extracted from the file names or partition labels of these selected entries. Subset selection and
+    extraction of the version identifier (plus potentially other metadata) is done via match patterns,
+    configured in <varname>MatchPattern=</varname> in the [Source] and [Target] sections. These patterns are
+    strings that describe how files or partitions are named, with named wildcards for specific fields such as
+    the version identifier. The following wildcards are defined:</para>
+
+    <table>
+      <title>Match Pattern Wildcards</title>
+
+      <tgroup cols='2' align='left' colsep='1' rowsep='1'>
+        <colspec colname="name" />
+        <colspec colname="explanation" />
+
+        <thead>
+          <row>
+            <entry>Wildcard</entry>
+            <entry>Description</entry>
+            <entry>Format</entry>
+            <entry>Notes</entry>
+          </row>
+        </thead>
+
+        <tbody>
+          <row>
+            <entry><literal>@v</literal></entry>
+            <entry>Version identifier</entry>
+            <entry>Valid version string</entry>
+            <entry>Mandatory</entry>
+          </row>
+
+          <row>
+            <entry><literal>@u</literal></entry>
+            <entry>GPT partition UUID</entry>
+            <entry>Valid 128-Bit UUID string</entry>
+            <entry>Only relevant if target resource type chosen as <constant>partition</constant></entry>
+          </row>
+
+          <row>
+            <entry><literal>@f</literal></entry>
+            <entry>GPT partition flags</entry>
+            <entry>Formatted hexadecimal integer</entry>
+            <entry>Only relevant if target resource type chosen as <constant>partition</constant></entry>
+          </row>
+
+          <row>
+            <entry><literal>@a</literal></entry>
+            <entry>GPT partition flag NoAuto</entry>
+            <entry>Either <literal>0</literal> or <literal>1</literal></entry>
+            <entry>Controls NoAuto bit of the GPT partition flags, as per <ulink url="https://uapi-group.org/specifications/specs/discoverable_partitions_specification">Discoverable Partitions Specification</ulink>; only relevant if target resource type chosen as <constant>partition</constant></entry>
+          </row>
+
+          <row>
+            <entry><literal>@g</literal></entry>
+            <entry>GPT partition flag GrowFileSystem</entry>
+            <entry>Either <literal>0</literal> or <literal>1</literal></entry>
+            <entry>Controls GrowFileSystem bit of the GPT partition flags, as per <ulink url="https://uapi-group.org/specifications/specs/discoverable_partitions_specification">Discoverable Partitions Specification</ulink>; only relevant if target resource type chosen as <constant>partition</constant></entry>
+          </row>
+
+          <row>
+            <entry><literal>@r</literal></entry>
+            <entry>Read-only flag</entry>
+            <entry>Either <literal>0</literal> or <literal>1</literal></entry>
+            <entry>Controls ReadOnly bit of the GPT partition flags, as per <ulink url="https://uapi-group.org/specifications/specs/discoverable_partitions_specification">Discoverable Partitions Specification</ulink> and other output read-only flags, see <varname>ReadOnly=</varname> below</entry>
+          </row>
+
+          <row>
+            <entry><literal>@t</literal></entry>
+            <entry>File modification time</entry>
+            <entry>Formatted decimal integer, μs since UNIX epoch Jan 1st 1970</entry>
+            <entry>Only relevant if target resource type chosen as <constant>regular-file</constant></entry>
+          </row>
+
+          <row>
+            <entry><literal>@m</literal></entry>
+            <entry>File access mode</entry>
+            <entry>Formatted octal integer, in UNIX fashion</entry>
+            <entry>Only relevant if target resource type chosen as <constant>regular-file</constant></entry>
+          </row>
+
+          <row>
+            <entry><literal>@s</literal></entry>
+            <entry>File size after decompression</entry>
+            <entry>Formatted decimal integer</entry>
+            <entry>Useful for measuring progress and to improve partition allocation logic</entry>
+          </row>
+
+          <row>
+            <entry><literal>@d</literal></entry>
+            <entry>Tries done</entry>
+            <entry>Formatted decimal integer</entry>
+            <entry>Useful when operating with kernel image files, as per <ulink url="https://systemd.io/AUTOMATIC_BOOT_ASSESSMENT">Automatic Boot Assessment</ulink></entry>
+          </row>
+
+          <row>
+            <entry><literal>@l</literal></entry>
+            <entry>Tries left</entry>
+            <entry>Formatted decimal integer</entry>
+            <entry>Useful when operating with kernel image files, as per <ulink url="https://systemd.io/AUTOMATIC_BOOT_ASSESSMENT">Automatic Boot Assessment</ulink></entry>
+          </row>
+
+          <row>
+            <entry><literal>@h</literal></entry>
+            <entry>SHA256 hash of compressed file</entry>
+            <entry>64 hexadecimal characters</entry>
+            <entry>The SHA256 hash of the compressed file; not useful for <constant>url-file</constant> or <constant>url-tar</constant> where the SHA256 hash is already included in the manifest file anyway</entry>
+          </row>
+        </tbody>
+      </tgroup>
+    </table>
+
+    <para>Of these wildcards only <literal>@v</literal> must be present in a valid pattern, all other
+    wildcards are optional. Each wildcard may be used at most once in each pattern. A typical wildcard
+    matching a file system source image could be <literal>MatchPattern=foobar_@v.raw.xz</literal>, i.e. any file
+    whose name begins with <literal>foobar_</literal>, followed by a version ID and suffixed by
+    <literal>.raw.xz</literal>.</para>
+
+    <para>Do not confuse the <literal>@</literal> pattern matching wildcard prefix with the
+    <literal>%</literal> specifier expansion prefix. The former encapsulate a variable part of a match
+    pattern string, the latter are simple shortcuts that are expanded while the drop-in files are
+    parsed. For details about specifiers, see below.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>[Transfer] Section Options</title>
+
+    <para>This section defines general properties of this transfer.</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><varname>MinVersion=</varname></term>
+
+        <listitem><para>Specifies the minimum version to require for this transfer to take place. If the
+        source or target patterns in this transfer definition match files older than this version they will
+        be considered obsolete, and never be considered for the update operation.</para>
+
+        <xi:include href="version-info.xml" xpointer="v251"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ProtectVersion=</varname></term>
+
+        <listitem><para>Takes one or more version strings to mark as "protected". Protected versions are
+        never removed while making room for new, updated versions. This is useful to ensure that the
+        currently booted OS version (or auxiliary resources associated with it) is not replaced/overwritten
+        during updates, in order to avoid runtime file system corruptions.</para>
+
+        <para>Like many of the settings in these configuration files this setting supports specifier
+        expansion. It's particularly useful to set this setting to one of the <literal>%A</literal>,
+        <literal>%B</literal> or <literal>%w</literal> specifiers to automatically refer to the current OS
+        version of the running system. See below for details on supported specifiers.</para>
+
+        <xi:include href="version-info.xml" xpointer="v251"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Verify=</varname></term>
+
+        <listitem><para>Takes a boolean, defaults to yes. Controls whether to cryptographically verify
+        downloaded resources (specifically: validate the GPG signatures for downloaded
+        <filename>SHA256SUMS</filename> manifest files, via their detached signature files
+        <filename>SHA256SUMS.gpg</filename> in combination with the system keyring
+        <filename>/usr/lib/systemd/import-pubring.gpg</filename> or
+        <filename>/etc/systemd/import-pubring.gpg</filename>).</para>
+
+        <para>This option is essential to provide integrity guarantees for downloaded resources and thus
+        should be left enabled, outside of test environments.</para>
+
+        <para>Note that the downloaded payload files are unconditionally checked against the SHA256 hashes
+        listed in the manifest. This option only controls whether the signatures of these manifests are
+        verified.</para>
+
+        <para>This option only has an effect if the source resource type is selected as
+        <constant>url-file</constant> or <constant>url-tar</constant>, as integrity and authentication
+        checking is only available for transfers from remote sources.</para>
+
+        <xi:include href="version-info.xml" xpointer="v251"/></listitem>
+      </varlistentry>
+
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[Source] Section Options</title>
+
+    <para>This section defines properties of the transfer source.</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><varname>Type=</varname></term>
+
+        <listitem><para>Specifies the resource type of the source for the transfer. Takes one of
+        <constant>url-file</constant>, <constant>url-tar</constant>, <constant>tar</constant>,
+        <constant>regular-file</constant>, <constant>directory</constant> or
+        <constant>subvolume</constant>. For details about the resource types, see above. This option is
+        mandatory.</para>
+
+        <para>Note that only certain combinations of source and target resource types are supported, see
+        above.</para>
+
+        <xi:include href="version-info.xml" xpointer="v251"/></listitem>
+      </varlistentry>
+    </variablelist>
+
+    <variablelist>
+      <varlistentry>
+        <term><varname>Path=</varname></term>
+
+        <listitem><para>Specifies where to find source versions of this resource.</para>
+
+        <para>If the source type is selected as <constant>url-file</constant> or
+        <constant>url-tar</constant> this must be a HTTP/HTTPS URL. The URL is suffixed with
+        <filename>/SHA256SUMS</filename> to acquire the manifest file, with
+        <filename>/SHA256SUMS.gpg</filename> to acquire the detached signature file for it, and with the file
+        names listed in the manifest file in case an update is executed and a resource shall be
+        downloaded.</para>
+
+        <para>For all other source resource types this must be a local path in the file system, referring to
+        a local directory to find the versions of this resource in.</para>
+
+        <xi:include href="version-info.xml" xpointer="v251"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>MatchPattern=</varname></term>
+
+        <listitem><para>Specifies one or more file name match patterns that select the subset of files that
+        are update candidates as source for this transfer. See above for details on match patterns.</para>
+
+        <para>This option is mandatory. Any pattern listed must contain at least the <literal>@v</literal>
+        wildcard, so that a version identifier may be extracted from the filename. All other wildcards are
+        optional.</para>
+
+        <para>If the source type is <constant>regular-file</constant> or <constant>directory</constant>, the
+        pattern may contain slash characters. In this case it will match the file or directory in
+        corresponding subdirectory. For example <literal>MatchPattern=foo_@v/bar.efi</literal> will match
+        <literal>bar.efi</literal> in directory <literal>foo_1</literal>. </para>
+
+        <xi:include href="version-info.xml" xpointer="v251"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>[Target] Section Options</title>
+
+    <para>This section defines properties of the transfer target.</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><varname>Type=</varname></term>
+
+        <listitem><para>Specifies the resource type of the target for the transfer. Takes one of
+        <constant>partition</constant>, <constant>regular-file</constant>, <constant>directory</constant> or
+        <constant>subvolume</constant>. For details about the resource types, see above. This option is
+        mandatory.</para>
+
+        <para>Note that only certain combinations of source and target resource types are supported, see
+        above.</para>
+
+        <xi:include href="version-info.xml" xpointer="v251"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Path=</varname></term>
+
+        <listitem><para>Specifies a file system path where to look for already installed versions or place
+        newly downloaded versions of this configured resource. If <varname>Type=</varname> is set to
+        <constant>partition</constant>, expects a path to a (whole) block device node, or the special string
+        <literal>auto</literal> in which case the block device which contains the root file system of the
+        currently booted system is automatically determined and used. If <varname>Type=</varname> is set to
+        <constant>regular-file</constant>, <constant>directory</constant> or <constant>subvolume</constant>,
+        must refer to a path in the local file system referencing the directory to find or place the version
+        files or directories under.</para>
+
+        <para>Note that this mechanism cannot be used to create or remove partitions, in case
+        <varname>Type=</varname> is set to <constant>partition</constant>. Partitions must exist already, and
+        a special partition label <literal>_empty</literal> is used to indicate empty partitions. To
+        automatically generate suitable partitions on first boot, use a tool such as
+        <citerefentry><refentrytitle>systemd-repart</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v251"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>PathRelativeTo=</varname></term>
+
+        <listitem><para>Specifies what partition <varname>Path=</varname> should be relative to. Takes one of
+        <constant>root</constant>, <constant>esp</constant>, <constant>xbootldr</constant>, or <constant>boot</constant>.
+        If unspecified, defaults to <constant>root</constant>.</para>
+
+        <para>If set to <constant>boot</constant>, the specified <varname>Path=</varname> will be resolved
+        relative to the mount point of the $BOOT partition (i.e. the ESP or XBOOTLDR), as defined by the
+        <ulink url="https://uapi-group.org/specifications/specs/boot_loader_specification">Boot Loader
+        Specification</ulink>.</para>
+
+        <para>The values <constant>esp</constant>, <constant>xbootldr</constant>, and
+        <constant>boot</constant> are only supported when <varname>Type=</varname> is set to
+        <constant>regular-file</constant> or <constant>directory</constant>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>MatchPattern=</varname></term>
+
+        <listitem><para>Specifies one or more file name or partition label match patterns that select the
+        subset of files or partitions that are update candidates as targets for this transfer. See above for
+        details on match patterns.</para>
+
+        <para>This option is mandatory. Any pattern listed must contain at least the <literal>@v</literal>
+        wildcard, so that a version identifier may be extracted from the filename. All other wildcards are
+        optional.</para>
+
+        <para>This pattern is both used for matching existing installed versions and for determining the name
+        of new versions to install. If multiple patterns are specified, the first specified is used for
+        naming newly installed versions.</para>
+
+        <para>If the target type is <constant>regular-file</constant> or <constant>directory</constant>, the
+        pattern may contain slash characters. In this case it will match the file or directory in
+        corresponding subdirectory. For example <literal>MatchPattern=foo_@v/bar.efi</literal> will match
+        <literal>bar.efi</literal> in directory <literal>foo_1</literal>. Directories in the path will be
+        created when file is installed. Empty directories will be removed when file is removed.</para>
+
+        <xi:include href="version-info.xml" xpointer="v251"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>MatchPartitionType=</varname></term>
+
+        <listitem><para>When the target <varname>Type=</varname> is chosen as <constant>partition</constant>,
+        specifies the GPT partition type to look for. Only partitions of this type are considered, all other
+        partitions are ignored. If not specified, the GPT partition type <constant>linux-generic</constant>
+        is used. Accepts either a literal type UUID or a symbolic type identifier. For a list of supported
+        type identifiers, see the <varname>Type=</varname> setting in
+        <citerefentry><refentrytitle>repart.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v251"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>PartitionUUID=</varname></term>
+        <term><varname>PartitionFlags=</varname></term>
+        <term><varname>PartitionNoAuto=</varname></term>
+        <term><varname>PartitionGrowFileSystem=</varname></term>
+
+        <listitem><para>When the target <varname>Type=</varname> is picked as <constant>partition</constant>,
+        selects the GPT partition UUID and partition flags to use for the updated partition. Expects a valid
+        UUID string, a hexadecimal integer, or booleans, respectively. If not set, but the source match
+        pattern includes wildcards for these fields (i.e. <literal>@u</literal>, <literal>@f</literal>,
+        <literal>@a</literal>, or <literal>@g</literal>), the values from the patterns are used. If neither
+        configured with wildcards or these explicit settings, the values are left untouched. If both the
+        overall <varname>PartitionFlags=</varname> flags setting and the individual flag settings
+        <varname>PartitionNoAuto=</varname> and <varname>PartitionGrowFileSystem=</varname> are used (or the
+        wildcards for them), then the latter override the former, i.e. the individual flag bit overrides the
+        overall flags value. See <ulink url="https://uapi-group.org/specifications/specs/discoverable_partitions_specification">Discoverable
+        Partitions Specification</ulink> for details about these flags.</para>
+
+        <para>Note that these settings are not used for matching, they only have effect on newly written
+        partitions in case a transfer takes place.</para>
+
+        <xi:include href="version-info.xml" xpointer="v251"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ReadOnly=</varname></term>
+
+        <listitem><para>Controls whether to mark the resulting file, subvolume or partition read-only. If the
+        target type is <constant>partition</constant> this controls the ReadOnly partition flag, as per
+        <ulink url="https://uapi-group.org/specifications/specs/discoverable_partitions_specification">Discoverable Partitions
+        Specification</ulink>, similar to the <varname>PartitionNoAuto=</varname> and
+        <varname>PartitionGrowFileSystem=</varname> flags described above. If the target type is
+        <constant>regular-file</constant>, the writable bit is removed from the access mode. If the
+        target type is <constant>subvolume</constant>, the subvolume will be marked read-only as a
+        whole. Finally, if the target <varname>Type=</varname> is selected as <constant>directory</constant>,
+        the "immutable" file attribute is set, see <citerefentry
+        project='man-pages'><refentrytitle>chattr</refentrytitle><manvolnum>1</manvolnum></citerefentry> for
+        details.</para>
+
+        <xi:include href="version-info.xml" xpointer="v251"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>Mode=</varname></term>
+
+        <listitem><para>The UNIX file access mode to use for newly created files in case the target resource
+        type is picked as <constant>regular-file</constant>. Expects an octal integer, in typical UNIX
+        fashion. If not set, but the source match pattern includes a wildcard for this field
+        (i.e. <literal>@t</literal>), the value from the pattern is used.</para>
+
+        <para>Note that this setting is not used for matching, it only has an effect on newly written
+        files when a transfer takes place.</para>
+
+        <xi:include href="version-info.xml" xpointer="v251"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>TriesDone=</varname></term>
+        <term><varname>TriesLeft=</varname></term>
+
+        <listitem><para>These options take positive, decimal integers, and control the number of attempts
+        done and left for this file. These settings are useful for managing kernel images, following the
+        scheme defined in <ulink url="https://systemd.io/AUTOMATIC_BOOT_ASSESSMENT">Automatic Boot
+        Assessment</ulink>, and only have an effect if the target pattern includes the <literal>@d</literal>
+        or <literal>@l</literal> wildcards.</para>
+
+        <xi:include href="version-info.xml" xpointer="v251"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>InstancesMax=</varname></term>
+
+        <listitem><para>Takes a decimal integer equal to or greater than 2. This configures how many concurrent
+        versions of the resource to keep. Whenever a new update is initiated it is made sure that no more
+        than the number of versions specified here minus one exist in the target. Any excess versions are
+        deleted (in case the target <varname>Type=</varname> of <constant>regular-file</constant>,
+        <constant>directory</constant>, <constant>subvolume</constant> is used) or emptied (in case the
+        target <varname>Type=</varname> of <constant>partition</constant> is used; emptying in this case
+        simply means to set the partition label to the special string <literal>_empty</literal>; note that no
+        partitions are actually removed). After an update is completed the number of concurrent versions of
+        the target resources is equal to or below the number specified here.</para>
+
+        <para>Note that this setting may be set differently for each transfer. However, it generally is
+        advisable to keep this setting the same for all transfers, since otherwise incomplete combinations of
+        files or partitions will be left installed.</para>
+
+        <para>If the target <varname>Type=</varname> is selected as <constant>partition</constant>, the number
+        of concurrent versions to keep is additionally restricted by the number of partition slots of the
+        right type in the partition table. I.e. if there are only 2 partition slots for the selected
+        partition type, setting this value larger than 2 is without effect, since no more than 2 concurrent
+        versions could be stored in the image anyway.</para>
+
+        <xi:include href="version-info.xml" xpointer="v251"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RemoveTemporary=</varname></term>
+
+        <listitem><para>Takes a boolean argument. If this option is enabled (which is the default) before
+        initiating an update, all left-over, incomplete updates from a previous attempt are removed from the
+        target directory. This only has an effect if the target resource <varname>Type=</varname> is selected
+        as <constant>regular-file</constant>, <constant>directory</constant> or
+        <constant>subvolume</constant>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v251"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>CurrentSymlink=</varname></term>
+
+        <listitem><para>Takes a symlink name as argument. If this option is used, as the last step of the
+        update a symlink under the specified name is created/updated pointing to the completed update. This
+        is useful in to provide a stable name always pointing to the newest version of the resource. This is
+        only supported if the target resource <varname>Type=</varname> is selected as
+        <constant>regular-file</constant>, <constant>directory</constant> or
+        <constant>subvolume</constant>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v251"/></listitem>
+      </varlistentry>
+
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Specifiers</title>
+
+    <para>Specifiers may be used in the <varname>MinVersion=</varname>, <varname>ProtectVersion=</varname>,
+    <varname>Path=</varname>, <varname>MatchPattern=</varname> and <varname>CurrentSymlink=</varname>
+    settings. The following expansions are understood:</para>
+      <table class='specifiers'>
+        <title>Specifiers available</title>
+        <tgroup cols='3' align='left' colsep='1' rowsep='1'>
+          <colspec colname="spec" />
+          <colspec colname="mean" />
+          <colspec colname="detail" />
+          <thead>
+            <row>
+              <entry>Specifier</entry>
+              <entry>Meaning</entry>
+              <entry>Details</entry>
+            </row>
+          </thead>
+          <tbody>
+            <xi:include href="standard-specifiers.xml" xpointer="a"/>
+            <xi:include href="standard-specifiers.xml" xpointer="A"/>
+            <xi:include href="standard-specifiers.xml" xpointer="b"/>
+            <xi:include href="standard-specifiers.xml" xpointer="B"/>
+            <xi:include href="standard-specifiers.xml" xpointer="H"/>
+            <xi:include href="standard-specifiers.xml" xpointer="l"/>
+            <xi:include href="standard-specifiers.xml" xpointer="m"/>
+            <xi:include href="standard-specifiers.xml" xpointer="M"/>
+            <xi:include href="standard-specifiers.xml" xpointer="o"/>
+            <xi:include href="standard-specifiers.xml" xpointer="v"/>
+            <xi:include href="standard-specifiers.xml" xpointer="w"/>
+            <xi:include href="standard-specifiers.xml" xpointer="W"/>
+            <xi:include href="standard-specifiers.xml" xpointer="T"/>
+            <xi:include href="standard-specifiers.xml" xpointer="V"/>
+            <xi:include href="standard-specifiers.xml" xpointer="percent"/>
+          </tbody>
+        </tgroup>
+      </table>
+
+    <para>Do not confuse the <literal>%</literal> specifier expansion prefix with the <literal>@</literal>
+    pattern matching wildcard prefix. The former are simple shortcuts that are expanded while the drop-in
+    files are parsed, the latter encapsulate a variable part of a match pattern string. For details about
+    pattern matching wildcards, see above.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Examples</title>
+
+    <example>
+      <title>Updates for a Verity Enabled Secure OS</title>
+
+      <para>With the following three files we define a root file system partition, a matching Verity
+      partition, and a unified kernel image to update as one. This example is an extension of the example
+      discussed earlier in this man page.</para>
+
+      <para><programlisting># /usr/lib/sysupdate.d/50-verity.conf
+[Transfer]
+ProtectVersion=%A
+
+[Source]
+Type=url-file
+Path=https://download.example.com/
+MatchPattern=foobarOS_@v_@u.verity.xz
+
+[Target]
+Type=partition
+Path=auto
+MatchPattern=foobarOS_@v_verity
+MatchPartitionType=root-verity
+PartitionFlags=0
+ReadOnly=1</programlisting></para>
+
+      <para>The above defines the update mechanism for the Verity partition of the root file system. Verity
+      partition images are downloaded from
+      <literal>https://download.example.com/foobarOS_@v_@u.verity.xz</literal> and written to a suitable
+      local partition, which is marked read-only. Under the assumption this update is run from the image
+      itself the current image version (i.e. the <literal>%A</literal> specifier) is marked as protected, to
+      ensure it is not corrupted while booted. Note that the partition UUID for the target partition is
+      encoded in the source file name. Fixating the partition UUID can be useful to ensure that
+      <literal>roothash=</literal> on the kernel command line is sufficient to pinpoint both the Verity and
+      root file system partition, and also encode the Verity root level hash (under the assumption the UUID
+      in the file names match their top-level hash, the way
+      <citerefentry><refentrytitle>systemd-gpt-auto-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+      suggests).</para>
+
+      <para><programlisting># /usr/lib/sysupdate.d/60-root.conf
+[Transfer]
+ProtectVersion=%A
+
+[Source]
+Type=url-file
+Path=https://download.example.com/
+MatchPattern=foobarOS_@v_@u.root.xz
+
+[Target]
+Type=partition
+Path=auto
+MatchPattern=foobarOS_@v
+MatchPartitionType=root
+PartitionFlags=0
+ReadOnly=1</programlisting></para>
+
+      <para>The above defines a matching transfer definition for the root file system.</para>
+
+      <para><programlisting># /usr/lib/sysupdate.d/70-kernel.conf
+[Transfer]
+ProtectVersion=%A
+
+[Source]
+Type=url-file
+Path=https://download.example.com/
+MatchPattern=foobarOS_@v.efi.xz
+
+[Target]
+Type=regular-file
+Path=/EFI/Linux
+PathRelativeTo=boot
+MatchPattern=foobarOS_@v+@l-@d.efi \
+             foobarOS_@v+@l.efi \
+             foobarOS_@v.efi
+Mode=0444
+TriesLeft=3
+TriesDone=0
+InstancesMax=2</programlisting></para>
+
+        <para>The above installs a unified kernel image into the $BOOT partition, as per
+        <ulink url="https://uapi-group.org/specifications/specs/boot_loader_specification">Boot Loader
+        Specification</ulink> Type #2. This defines three possible patterns for the names of the kernel
+        images, as per <ulink url="https://systemd.io/AUTOMATIC_BOOT_ASSESSMENT">Automatic Boot Assessment</ulink>,
+        and ensures when installing new kernels, they are set up with 3 tries left. No more than two parallel
+        kernels are kept.</para>
+
+        <para>With this setup the web server would serve the following files, for a hypothetical version 7 of
+        the OS:</para>
+
+        <itemizedlist>
+          <listitem><para><filename>SHA256SUMS</filename> – The manifest file, containing available files and their SHA256 hashes</para></listitem>
+          <listitem><para><filename>SHA256SUMS.gpg</filename> – The detached cryptographic signature for the manifest file</para></listitem>
+          <listitem><para><filename>foobarOS_7_8b8186b1-2b4e-4eb6-ad39-8d4d18d2a8fb.verity.xz</filename> – The Verity image for version 7</para></listitem>
+          <listitem><para><filename>foobarOS_7_f4d1234f-3ebf-47c4-b31d-4052982f9a2f.root.xz</filename> – The root file system image for version 7</para></listitem>
+          <listitem><para><filename>foobarOS_7_efi.xz</filename> – The unified kernel image for version 7</para></listitem>
+        </itemizedlist>
+
+        <para>For each new OS release a new set of the latter three files would be added, each time with an
+        updated version. The <filename>SHA256SUMS</filename> manifest should then be updated accordingly,
+        listing all files for all versions that shall be offered for download.</para>
+    </example>
+
+    <example>
+      <title>Updates for Plain Directory Container Image</title>
+
+      <para><programlisting>
+[Source]
+Type=url-tar
+Path=https://download.example.com/
+MatchPattern=myContainer_@v.tar.gz
+
+[Target]
+Type=subvolume
+Path=/var/lib/machines
+MatchPattern=myContainer_@v
+CurrentSymlink=myContainer</programlisting></para>
+
+      <para>On updates this downloads <literal>https://download.example.com/myContainer_@v.tar.gz</literal>
+      and decompresses/unpacks it to <filename>/var/lib/machines/myContainer_@v</filename>. After each update
+      a symlink <filename>/var/lib/machines/myContainer</filename> is created/updated always pointing to the
+      most recent update.</para>
+    </example>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-sysupdate</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-repart</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/sysusers.d.xml b/man/sysusers.d.xml
new file mode 100644
index 0000000..e7cd285
--- /dev/null
+++ b/man/sysusers.d.xml
@@ -0,0 +1,307 @@
+<?xml version="1.0"?>
+<!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+<refentry id="sysusers.d" conditional='ENABLE_SYSUSERS'
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>sysusers.d</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>sysusers.d</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>sysusers.d</refname>
+    <refpurpose>Declarative allocation of system users and groups</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>/etc/sysusers.d/*.conf</filename></para>
+    <para><filename>/run/sysusers.d/*.conf</filename></para>
+    <para><filename>/usr/lib/sysusers.d/*.conf</filename></para>
+
+    <programlisting>
+#Type Name       ID                  GECOS              Home directory Shell
+u     user_name  uid                 "User Description" /home/dir      /path/to/shell
+u     user_name  uid:gid             "User Description" /home/dir      /path/to/shell
+u     user_name  /file/owned/by/user "User Description" /home/dir      /path/to/shell
+g     group_name gid
+g     group_name /file/owned/by/group
+m     user_name  group_name
+r     -          lowest-highest</programlisting>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>systemd-sysusers</command> uses the files from
+    <filename>sysusers.d</filename> directory to create system users and groups and
+    to add users to groups, at package installation or boot time. This tool may be
+    used to allocate system users and groups only, it is not useful for creating
+    non-system (i.e. regular, "human") users and groups, as it accesses
+    <filename>/etc/passwd</filename> and <filename>/etc/group</filename> directly,
+    bypassing any more complex user databases, for example any database involving NIS
+    or LDAP.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Configuration Directories and Precedence</title>
+
+    <para>Each configuration file shall be named in the style of
+    <filename><replaceable>package</replaceable>.conf</filename> or
+    <filename><replaceable>package</replaceable>-<replaceable>part</replaceable>.conf</filename>.
+    The second variant should be used when it is desirable to make it
+    easy to override just this part of configuration.</para>
+
+    <para>Files in <filename>/etc/sysusers.d</filename> override files
+    with the same name in <filename>/usr/lib/sysusers.d</filename> and
+    <filename>/run/sysusers.d</filename>. Files in
+    <filename>/run/sysusers.d</filename> override files with the same
+    name in <filename>/usr/lib/sysusers.d</filename>. Packages should
+    install their configuration files in
+    <filename>/usr/lib/sysusers.d</filename>. Files in
+    <filename>/etc/sysusers.d</filename> are reserved for the local
+    administrator, who may use this logic to override the
+    configuration files installed by vendor packages. All
+    configuration files are sorted by their filename in lexicographic
+    order, regardless of which of the directories they reside in. If
+    multiple files specify the same path, the entry in the file with
+    the lexicographically earliest name will be applied. All later
+    entries for the same user and group names will be logged as warnings.
+    </para>
+
+    <para>If the administrator wants to disable a configuration file
+    supplied by the vendor, the recommended way is to place a symlink
+    to <filename>/dev/null</filename> in
+    <filename>/etc/sysusers.d/</filename> bearing the same filename.
+    </para>
+  </refsect1>
+
+  <refsect1>
+    <title>Configuration File Format</title>
+
+    <para>The file format is one line per user or group containing name, ID, GECOS
+    field description, home directory, and login shell:</para>
+
+    <programlisting>#Type Name     ID             GECOS                 Home directory Shell
+u     httpd    404            "HTTP User"
+u     _authd   /usr/bin/authd "Authorization user"
+u     postgres -              "Postgresql Database" /var/lib/pgsql /usr/libexec/postgresdb
+g     input    -              -
+m     _authd   input
+u     root     0              "Superuser"           /root          /bin/zsh
+r     -        500-900
+</programlisting>
+
+    <para>Empty lines and lines beginning with the <literal>#</literal> character are ignored, and may be used for
+    commenting.</para>
+
+    <refsect2>
+      <title>Type</title>
+
+      <para>The type consists of a single letter. The following line
+      types are understood:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><varname>u</varname></term>
+          <listitem><para>Create a system user and group of the specified name should
+          they not exist yet. The user's primary group will be set to the group
+          bearing the same name unless the ID field specifies it. The account will be
+          created disabled, so that logins are not allowed.</para>
+
+          <xi:include href="version-info.xml" xpointer="v215"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>g</varname></term>
+          <listitem><para>Create a system group of the specified name
+          should it not exist yet. Note that <varname>u</varname>
+          implicitly creates a matching group. The group will be
+          created with no password set.</para>
+
+          <xi:include href="version-info.xml" xpointer="v215"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>m</varname></term>
+          <listitem><para>Add a user to a group. If the user or group
+          do not exist yet, they will be implicitly
+          created.</para>
+
+          <xi:include href="version-info.xml" xpointer="v215"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>r</varname></term>
+          <listitem><para>Add a range of numeric UIDs/GIDs to the pool
+          to allocate new UIDs and GIDs from. If no line of this type
+          is specified, the range of UIDs/GIDs is set to some
+          compiled-in default. Note that both UIDs and GIDs are
+          allocated from the same pool, in order to ensure that users
+          and groups of the same name are likely to carry the same
+          numeric UID and GID.</para>
+
+          <xi:include href="version-info.xml" xpointer="v216"/></listitem>
+        </varlistentry>
+
+      </variablelist>
+    </refsect2>
+
+    <refsect2>
+      <title>Name</title>
+
+      <para>The name field specifies the user or group name. The specified name must consist only of the characters a-z,
+      A-Z, 0-9, <literal>_</literal> and <literal>-</literal>, except for the first character which must be one of a-z,
+      A-Z or <literal>_</literal> (i.e. numbers and <literal>-</literal> are not permitted as first character). The
+      user/group name must have at least one character, and at most 31.</para>
+
+      <para>For further details about the syntax of user/group names, see <ulink
+      url="https://systemd.io/USER_NAMES">User/Group Name Syntax</ulink>.</para>
+
+      <para>It is strongly recommended to pick user and group names that are unlikely to clash with normal users
+      created by the administrator. A good scheme to guarantee this is by prefixing all system and group names with the
+      underscore, and avoiding too generic names.</para>
+
+      <para>For <varname>m</varname> lines, this field should contain
+      the user name to add to a group.</para>
+
+      <para>For lines of type <varname>r</varname>, this field should
+      be set to <literal>-</literal>.</para>
+    </refsect2>
+
+    <refsect2>
+      <title>ID</title>
+
+      <para>For <varname>u</varname> and <varname>g</varname>, the
+      numeric 32-bit UID or GID of the user/group. Do not use IDs 65535
+      or 4294967295, as they have special placeholder meanings.
+      Specify <literal>-</literal> for automatic UID/GID allocation
+      for the user or group (this is strongly recommended unless it is strictly
+      necessary to use a specific UID or GID). Alternatively, specify an absolute path
+      in the file system. In this case, the UID/GID is read from the
+      path's owner/group. This is useful to create users whose UID/GID
+      match the owners of pre-existing files (such as SUID or SGID
+      binaries).
+      The syntaxes <literal><replaceable>uid</replaceable>:<replaceable>gid</replaceable></literal> and
+      <literal><replaceable>uid</replaceable>:<replaceable>groupname</replaceable></literal> are supported to
+      allow creating users with specific primary groups. The given group must be created explicitly, or it
+      must already exist. Specifying <literal>-</literal> for the UID in these syntaxes is also supported.
+      </para>
+
+      <para>For <varname>m</varname> lines, this field should contain
+      the group name to add to a user to.</para>
+
+      <para>For lines of type <varname>r</varname>, this field should
+      be set to a UID/GID range in the format
+      <literal>FROM-TO</literal>, where both values are formatted as
+      decimal ASCII numbers. Alternatively, a single UID/GID may be
+      specified formatted as decimal ASCII numbers.</para>
+    </refsect2>
+
+    <refsect2>
+      <title>GECOS</title>
+
+      <para>A short, descriptive string for users to be created, enclosed in
+      quotation marks. Note that this field may not contain colons.</para>
+
+      <para>Only applies to lines of type <varname>u</varname> and should otherwise
+      be left unset (or <literal>-</literal>).</para>
+    </refsect2>
+
+    <refsect2>
+      <title>Home Directory</title>
+
+      <para>The home directory for a new system user. If omitted, defaults to the
+      root directory.</para>
+
+      <para>Only applies to lines of type <varname>u</varname> and should otherwise
+      be left unset (or <literal>-</literal>). It is recommended to omit this, unless
+      software strictly requires a home directory to be set.</para>
+
+      <para><command>systemd-sysusers</command> only sets the home directory record in the
+      user database. To actually create the directory, consider adding a corresponding
+      <citerefentry><refentrytitle>tmpfiles.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+      fragment.</para>
+    </refsect2>
+
+    <refsect2>
+      <title>Shell</title>
+
+      <para>The login shell of the user. If not specified, this will be set to
+      <filename>/usr/sbin/nologin</filename>, except if the UID of the user is 0, in
+      which case <filename>/bin/sh</filename> will be used.</para>
+
+      <para>Only applies to lines of type <varname>u</varname> and should otherwise
+      be left unset (or <literal>-</literal>). It is recommended to omit this, unless
+      a shell different <filename>/usr/sbin/nologin</filename> must be used.</para>
+    </refsect2>
+  </refsect1>
+
+  <refsect1>
+    <title>Specifiers</title>
+
+    <para>Specifiers can be used in the <literal>Name</literal>, <literal>ID</literal>,
+    <literal>GECOS</literal>, <literal>Home directory</literal>, and <literal>Shell</literal> fields. An
+    unknown or unresolvable specifier is treated as invalid configuration. The following expansions are
+    understood:</para>
+
+    <table class='specifiers'>
+      <title>Specifiers available</title>
+      <tgroup cols='3' align='left' colsep='1' rowsep='1'>
+        <colspec colname="spec" />
+        <colspec colname="mean" />
+        <colspec colname="detail" />
+        <thead>
+          <row>
+            <entry>Specifier</entry>
+            <entry>Meaning</entry>
+            <entry>Details</entry>
+          </row>
+        </thead>
+        <tbody>
+          <xi:include href="standard-specifiers.xml" xpointer="a"/>
+          <xi:include href="standard-specifiers.xml" xpointer="A"/>
+          <xi:include href="standard-specifiers.xml" xpointer="b"/>
+          <xi:include href="standard-specifiers.xml" xpointer="B"/>
+          <xi:include href="standard-specifiers.xml" xpointer="H"/>
+          <xi:include href="standard-specifiers.xml" xpointer="l"/>
+          <xi:include href="standard-specifiers.xml" xpointer="m"/>
+          <xi:include href="standard-specifiers.xml" xpointer="M"/>
+          <xi:include href="standard-specifiers.xml" xpointer="o"/>
+          <xi:include href="standard-specifiers.xml" xpointer="T"/>
+          <xi:include href="standard-specifiers.xml" xpointer="v"/>
+          <xi:include href="standard-specifiers.xml" xpointer="V"/>
+          <xi:include href="standard-specifiers.xml" xpointer="w"/>
+          <xi:include href="standard-specifiers.xml" xpointer="W"/>
+          <xi:include href="standard-specifiers.xml" xpointer="percent"/>
+        </tbody>
+      </tgroup>
+    </table>
+  </refsect1>
+
+  <refsect1>
+    <title>Idempotence</title>
+
+    <para>Note that <command>systemd-sysusers</command> will do nothing if the
+    specified users or groups already exist or the users are members of specified
+    groups, so normally there is no reason to override
+    <filename>sysusers.d</filename> vendor configuration, except to block certain
+    users or groups from being created.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-sysusers</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/tc.xml b/man/tc.xml
new file mode 100644
index 0000000..8d39be3
--- /dev/null
+++ b/man/tc.xml
@@ -0,0 +1,48 @@
+<?xml version="1.0"?>
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd">
+
+<!--
+  SPDX-License-Identifier: LGPL-2.1-or-later
+-->
+
+<refsect1>
+  <variablelist class='network-directives'>
+    <varlistentry id='qdisc-parent'>
+      <term><varname>Parent=</varname></term>
+      <listitem>
+        <para>Configures the parent Queueing Discipline (qdisc). Takes one of <literal>root</literal>,
+        <literal>clsact</literal>, <literal>ingress</literal> or a class identifier. The class identifier is
+        specified as the major and minor numbers in hexadecimal in the range 0x1–0xffff separated with a
+        colon (<literal>major:minor</literal>). Defaults to <literal>root</literal>.</para>
+      </listitem>
+    </varlistentry>
+
+    <varlistentry id='qdisc-handle'>
+      <term><varname>Handle=</varname></term>
+      <listitem>
+        <para>Configures the major number of unique identifier of the qdisc, known as the handle.
+        Takes a hexadecimal number in the range 0x1–0xffff. Defaults to unset.</para>
+      </listitem>
+    </varlistentry>
+
+    <varlistentry id='tclass-parent'>
+      <term><varname>Parent=</varname></term>
+      <listitem>
+        <para>Configures the parent Queueing Discipline (qdisc). Takes one of <literal>root</literal>, or a
+        qdisc identifier. The qdisc identifier is specified as the major and minor numbers in hexadecimal in
+        the range 0x1–0xffff separated with a colon (<literal>major:minor</literal>). Defaults to
+        <literal>root</literal>.
+        </para>
+      </listitem>
+    </varlistentry>
+
+    <varlistentry id='tclass-classid'>
+      <term><varname>ClassId=</varname></term>
+      <listitem>
+        <para>Configures the unique identifier of the class. It is specified as the major and minor numbers in
+        hexadecimal in the range 0x1–0xffff separated with a colon (<literal>major:minor</literal>).
+        Defaults to unset.</para>
+      </listitem>
+    </varlistentry>
+  </variablelist>
+</refsect1>
diff --git a/man/telinit.xml b/man/telinit.xml
new file mode 100644
index 0000000..294b359
--- /dev/null
+++ b/man/telinit.xml
@@ -0,0 +1,151 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="telinit" conditional='HAVE_SYSV_COMPAT'
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>telinit</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>telinit</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>telinit</refname>
+    <refpurpose>Change SysV runlevel</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <cmdsynopsis>
+      <command>telinit <arg choice="opt" rep="repeat">OPTIONS</arg> <arg choice="req">COMMAND</arg></command>
+    </cmdsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>telinit</command> may be used to change the SysV
+    system runlevel. Since the concept of SysV runlevels is obsolete
+    the runlevel requests will be transparently translated into
+    systemd unit activation requests.</para>
+
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>The following options are understood:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><option>--help</option></term>
+
+        <xi:include href="standard-options.xml" xpointer="help-text" />
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--no-wall</option></term>
+
+        <listitem><para>Do not send wall message before
+        reboot/halt/power-off.</para></listitem>
+      </varlistentry>
+    </variablelist>
+
+    <para>The following commands are understood:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><command>0</command></term>
+
+        <listitem><para>Power-off the machine. This is translated into
+        an activation request for <filename>poweroff.target</filename>
+        and is equivalent to <command>systemctl
+        poweroff</command>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>6</command></term>
+
+        <listitem><para>Reboot the machine. This is translated into an
+        activation request for <filename>reboot.target</filename> and
+        is equivalent to <command>systemctl
+        reboot</command>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>2</command></term>
+        <term><command>3</command></term>
+        <term><command>4</command></term>
+        <term><command>5</command></term>
+
+        <listitem><para>Change the SysV runlevel. This is translated
+        into an activation request for
+        <filename>runlevel2.target</filename>,
+        <filename>runlevel3.target</filename>, … and is equivalent
+        to <command>systemctl isolate runlevel2.target</command>,
+        <command>systemctl isolate runlevel3.target</command>,
+        …</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>1</command></term>
+        <term><command>s</command></term>
+        <term><command>S</command></term>
+
+        <listitem><para>Change into system rescue mode. This is
+        translated into an activation request for
+        <filename>rescue.target</filename> and is equivalent to
+        <command>systemctl rescue</command>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>q</command></term>
+        <term><command>Q</command></term>
+
+        <listitem><para>Reload daemon configuration. This is
+        equivalent to <command>systemctl
+        daemon-reload</command>.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>u</command></term>
+        <term><command>U</command></term>
+
+        <listitem><para>Serialize state, reexecute daemon and
+        deserialize state again. This is equivalent to
+        <command>systemctl daemon-reexec</command>.</para></listitem>
+      </varlistentry>
+
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Exit status</title>
+
+    <para>On success, 0 is returned, a non-zero failure
+    code otherwise.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Notes</title>
+
+    <para>This is a legacy command available for compatibility only.
+    It should not be used anymore, as the concept of runlevels is
+    obsolete.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>wall</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+</refentry>
diff --git a/man/threads-aware.xml b/man/threads-aware.xml
new file mode 100644
index 0000000..442e45b
--- /dev/null
+++ b/man/threads-aware.xml
@@ -0,0 +1,23 @@
+<?xml version="1.0"?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refsect1>
+
+<para id="strict">All functions listed here are thread-agnostic and only a single specific thread may operate on a
+given object during its entire lifetime. It's safe to allocate multiple independent objects and use each from a
+specific thread in parallel. However, it's not safe to allocate such an object in one thread, and operate or free it
+from any other, even if locking is used to ensure these threads don't operate on it at the very same time.</para>
+
+<para id="safe">All functions listed here are thread-safe and may be called in parallel from multiple threads.</para>
+
+<para id='getenv'>The code described here uses
+<citerefentry project='man-pages'><refentrytitle>getenv</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+which is declared to be not multi-thread-safe. This means that the code calling the functions described
+here must not call
+<citerefentry project='man-pages'><refentrytitle>setenv</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+from a parallel thread. It is recommended to only do calls to <function>setenv()</function>
+from an early phase of the program when no other threads have been started.</para>
+
+</refsect1>
diff --git a/man/timedatectl.xml b/man/timedatectl.xml
new file mode 100644
index 0000000..f06441b
--- /dev/null
+++ b/man/timedatectl.xml
@@ -0,0 +1,360 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="timedatectl" conditional='ENABLE_TIMEDATECTL'
+  xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>timedatectl</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>timedatectl</refentrytitle>
+    <manvolnum>1</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>timedatectl</refname>
+    <refpurpose>Control the system time and date</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <cmdsynopsis>
+      <command>timedatectl</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="req">COMMAND</arg>
+    </cmdsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>timedatectl</command> may be used to query and change the system clock and its settings,
+    and enable or disable time synchronization services.</para>
+
+    <para>Use
+    <citerefentry><refentrytitle>systemd-firstboot</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    to initialize the system time zone for mounted (but not booted)
+    system images.</para>
+
+    <para><command>timedatectl</command> may be used to show the current status of time synchronization
+    services, for example
+    <citerefentry><refentrytitle>systemd-timesyncd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+    </para>
+
+  </refsect1>
+
+  <refsect1>
+    <title>Commands</title>
+
+    <para>The following commands are understood:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><command>status</command></term>
+
+        <listitem><para>Show current settings of the system clock and RTC, including whether network time
+        synchronization is active. If no command is specified, this is the implied default.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v195"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>show</command></term>
+
+        <listitem><para>Show the same information as <option>status</option>, but in machine readable form.
+        This command is intended to be used whenever computer-parsable output is required.
+        Use <option>status</option> if you are looking for formatted human-readable output.</para>
+        <para>By default, empty properties are suppressed. Use <option>--all</option> to show those too.
+        To select specific properties to show, use <option>--property=</option>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>set-time [TIME]</command></term>
+
+        <listitem><para>Set the system clock to the specified time.
+        This will also update the RTC time accordingly. The time may
+        be specified in the format "2012-10-30
+        18:17:16".</para>
+
+        <xi:include href="version-info.xml" xpointer="v195"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>set-timezone [TIMEZONE]</command></term>
+
+        <listitem><para>Set the system time zone to the specified
+        value. Available timezones can be listed with
+        <command>list-timezones</command>. If the RTC is configured to
+        be in the local time, this will also update the RTC time. This
+        call will alter the <filename>/etc/localtime</filename>
+        symlink. See
+        <citerefentry><refentrytitle>localtime</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        for more information.</para>
+
+        <xi:include href="version-info.xml" xpointer="v195"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>list-timezones</command></term>
+
+        <listitem><para>List available time zones, one per line.
+        Entries from the list can be set as the system timezone with
+        <command>set-timezone</command>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v195"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>set-local-rtc [BOOL]</command></term>
+
+        <listitem><para>Takes a boolean argument. If
+        <literal>0</literal>, the system is configured to maintain the
+        RTC in universal time. If <literal>1</literal>, it will
+        maintain the RTC in local time instead. Note that maintaining
+        the RTC in the local timezone is not fully supported and will
+        create various problems with time zone changes and daylight
+        saving adjustments. If at all possible, keep the RTC in UTC
+        mode. Note that invoking this will also synchronize the RTC
+        from the system clock, unless
+        <option>--adjust-system-clock</option> is passed (see above).
+        This command will change the 3rd line of
+        <filename>/etc/adjtime</filename>, as documented in
+        <citerefentry project='man-pages'><refentrytitle>hwclock</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v195"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>set-ntp [BOOL]</command></term>
+
+        <listitem><para>Takes a boolean argument. Controls whether network time synchronization is active and
+        enabled (if available). If the argument is true, this enables and starts the first existing network
+        synchronization service. If the argument is false, then this disables and stops the known network
+        synchronization services. The way that the list of services is built is described in
+        <citerefentry><refentrytitle>systemd-timedated.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v195"/></listitem>
+      </varlistentry>
+
+    </variablelist>
+
+    <refsect2>
+      <title>systemd-timesyncd Commands</title>
+
+      <para>The following commands are specific to
+      <citerefentry><refentrytitle>systemd-timesyncd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+      </para>
+
+      <variablelist>
+        <varlistentry>
+          <term><command>timesync-status</command></term>
+
+          <listitem><para>Show current status of
+          <citerefentry><refentrytitle>systemd-timesyncd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+          If <option>--monitor</option> is specified, then this will monitor the status updates.</para>
+
+          <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><command>show-timesync</command></term>
+
+          <listitem><para>Show the same information as <option>timesync-status</option>, but in machine readable form.
+          This command is intended to be used whenever computer-parsable output is required.
+          Use <option>timesync-status</option> if you are looking for formatted human-readable output.</para>
+          <para>By default, empty properties are suppressed. Use <option>--all</option> to show those too.
+          To select specific properties to show, use <option>--property=</option>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><command>ntp-servers <replaceable>INTERFACE</replaceable> <replaceable>SERVER</replaceable>…</command></term>
+
+          <listitem><para>Set the interface specific NTP servers. This command can be used only when the
+          interface is managed by <command>systemd-networkd</command>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v243"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><command>revert <replaceable>INTERFACE</replaceable></command></term>
+
+          <listitem><para>Revert the interface specific NTP servers. This command can be used only when
+          the interface is managed by <command>systemd-networkd</command>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v243"/></listitem>
+        </varlistentry>
+      </variablelist>
+
+    </refsect2>
+
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>The following options are understood:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><option>--no-ask-password</option></term>
+
+        <listitem><para>Do not query the user for authentication for
+        privileged operations.</para>
+
+        <xi:include href="version-info.xml" xpointer="v195"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--adjust-system-clock</option></term>
+
+        <listitem><para>If <command>set-local-rtc</command> is invoked
+        and this option is passed, the system clock is synchronized
+        from the RTC again, taking the new setting into account.
+        Otherwise, the RTC is synchronized from the system
+        clock.</para>
+
+        <xi:include href="version-info.xml" xpointer="v195"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--monitor</option></term>
+
+        <listitem><para>If <command>timesync-status</command> is invoked and this option is passed, then
+        <command>timedatectl</command> monitors the status of
+        <citerefentry><refentrytitle>systemd-timesyncd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        and updates the outputs. Use <keycombo><keycap>Ctrl</keycap><keycap>C</keycap></keycombo> to terminate the
+        monitoring.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-a</option></term>
+        <term><option>--all</option></term>
+
+        <listitem><para>When showing properties of
+        <citerefentry><refentrytitle>systemd-timesyncd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+        show all properties regardless of whether they are set or not.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-p</option></term>
+        <term><option>--property=</option></term>
+
+        <listitem><para>When showing properties of
+        <citerefentry><refentrytitle>systemd-timesyncd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+        limit display to certain properties as specified as argument. If not specified, all set properties are shown.
+        The argument should be a property name, such as <literal>ServerName</literal>. If specified more than once,
+        all properties with the specified names are shown.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--value</option></term>
+
+        <listitem>
+          <para>When printing properties with <command>show-timesync</command>, only print the value, and skip the
+          property name and <literal>=</literal>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v239"/></listitem>
+      </varlistentry>
+
+      <xi:include href="user-system-options.xml" xpointer="host" />
+      <xi:include href="user-system-options.xml" xpointer="machine" />
+
+      <xi:include href="standard-options.xml" xpointer="help" />
+      <xi:include href="standard-options.xml" xpointer="version" />
+      <xi:include href="standard-options.xml" xpointer="no-pager" />
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Exit status</title>
+
+    <para>On success, 0 is returned, a non-zero failure code otherwise.</para>
+  </refsect1>
+
+  <xi:include href="common-variables.xml" />
+
+  <refsect1>
+    <title>Examples</title>
+    <para>Show current settings:
+    <programlisting>$ timedatectl
+               Local time: Thu 2017-09-21 16:08:56 CEST
+           Universal time: Thu 2017-09-21 14:08:56 UTC
+                 RTC time: Thu 2017-09-21 14:08:56
+                Time zone: Europe/Warsaw (CEST, +0200)
+System clock synchronized: yes
+              NTP service: active
+          RTC in local TZ: no</programlisting>
+    </para>
+
+    <para>Enable network time synchronization:
+    <programlisting>$ timedatectl set-ntp true
+==== AUTHENTICATING FOR org.freedesktop.timedate1.set-ntp ===
+Authentication is required to control whether network time synchronization shall be enabled.
+Authenticating as: user
+Password: ********
+==== AUTHENTICATION COMPLETE ===</programlisting>
+
+    <programlisting>$ systemctl status systemd-timesyncd.service
+● systemd-timesyncd.service - Network Time Synchronization
+   Loaded: loaded (/usr/lib/systemd/system/systemd-timesyncd.service; enabled)
+   Active: active (running) since Mo 2015-03-30 14:20:38 CEST; 5s ago
+     Docs: man:systemd-timesyncd.service(8)
+ Main PID: 595 (systemd-timesyn)
+   Status: "Using Time Server 216.239.38.15:123 (time4.google.com)."
+   CGroup: /system.slice/systemd-timesyncd.service
+           └─595 /usr/lib/systemd/systemd-timesyncd
+…</programlisting>
+    </para>
+
+    <para>Show current status of
+    <citerefentry><refentrytitle>systemd-timesyncd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>:
+    <programlisting>$ timedatectl timesync-status
+       Server: 216.239.38.15 (time4.google.com)
+Poll interval: 1min 4s (min: 32s; max 34min 8s)
+         Leap: normal
+      Version: 4
+      Stratum: 1
+    Reference: GPS
+    Precision: 1us (-20)
+Root distance: 335us (max: 5s)
+       Offset: +316us
+        Delay: 349us
+       Jitter: 0
+ Packet count: 1
+    Frequency: -8.802ppm</programlisting>
+    </para>
+
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>hwclock</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>date</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>localtime</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-timedated.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-timesyncd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-firstboot</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/timesyncd.conf.xml b/man/timesyncd.conf.xml
new file mode 100644
index 0000000..e804f5f
--- /dev/null
+++ b/man/timesyncd.conf.xml
@@ -0,0 +1,142 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="timesyncd.conf" conditional='ENABLE_TIMESYNCD'
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+  <refentryinfo>
+    <title>timesyncd.conf</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>timesyncd.conf</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>timesyncd.conf</refname>
+    <refname>timesyncd.conf.d</refname>
+    <refpurpose>Network Time Synchronization configuration files</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>/etc/systemd/timesyncd.conf</filename></para>
+    <para><filename>/etc/systemd/timesyncd.conf.d/*.conf</filename></para>
+    <para><filename>/run/systemd/timesyncd.conf.d/*.conf</filename></para>
+    <para><filename>/usr/lib/systemd/timesyncd.conf.d/*.conf</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>These configuration files control NTP network time synchronization. See
+    <citerefentry><refentrytitle>systemd.syntax</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+    for a general description of the syntax.</para>
+  </refsect1>
+
+  <xi:include href="standard-conf.xml" xpointer="main-conf" />
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>The following settings are configured in the [Time] section:</para>
+
+    <variablelist class='network-directives'>
+
+      <varlistentry>
+        <term><varname>NTP=</varname></term>
+        <listitem><para>A space-separated list of NTP server host names or IP addresses. During runtime this
+        list is combined with any per-interface NTP servers acquired from
+        <citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+        <command>systemd-timesyncd</command> will contact all configured system or per-interface servers in
+        turn, until one responds. When the empty string is assigned, the list of NTP servers is reset, and
+        all prior assignments will have no effect. This setting defaults to an empty list.</para>
+
+        <xi:include href="version-info.xml" xpointer="v216"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>FallbackNTP=</varname></term>
+        <listitem><para>A space-separated list of NTP server host names or IP addresses to be used as the
+        fallback NTP servers. Any per-interface NTP servers obtained from
+        <citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        take precedence over this setting, as do any servers set via <varname>NTP=</varname> above. This
+        setting is hence only relevant if no other NTP server information is known. When the empty string is
+        assigned, the list of NTP servers is reset, and all prior assignments will have no effect. If this
+        option is not given, a compiled-in list of NTP servers is used.</para>
+
+        <xi:include href="version-info.xml" xpointer="v216"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>RootDistanceMaxSec=</varname></term>
+        <listitem><para>Maximum acceptable root distance, i.e. the maximum estimated time required for a
+        packet to travel to the server we are connected to from the server with the reference clock. If
+        the current server does not satisfy this limit, <command>systemd-timesyncd</command> will switch
+        to a different server.</para>
+
+        <para>Takes a time span value. The default unit is seconds, but other units may be specified, see
+        <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+        Defaults to 5 seconds.</para>
+
+        <xi:include href="version-info.xml" xpointer="v236"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>PollIntervalMinSec=</varname></term>
+        <term><varname>PollIntervalMaxSec=</varname></term>
+        <listitem><para>The minimum and maximum poll intervals for NTP messages. Polling starts at the
+        minimum poll interval, and is adjusted within the specified limits in response to received packets.
+        </para>
+
+        <para>Each setting takes a time span value. The default unit is seconds, but other units may be
+        specified, see
+        <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+        <varname>PollIntervalMinSec=</varname> defaults to 32 seconds and must not be smaller than
+        16 seconds. <varname>PollIntervalMaxSec=</varname> defaults to 34 min 8 s (2048 seconds) and must be
+        larger than <varname>PollIntervalMinSec=</varname>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v236"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>ConnectionRetrySec=</varname></term>
+        <listitem><para>Specifies the minimum delay before subsequent attempts to contact a new NTP server
+        are made.</para>
+
+        <para>Takes a time span value. The default unit is seconds, but other units may be specified, see
+        <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+        Defaults to 30 seconds and must not be smaller than 1 second.</para>
+
+        <xi:include href="version-info.xml" xpointer="v248"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>SaveIntervalSec=</varname></term>
+        <listitem><para>The interval at which the current time is periodically saved to disk, in the absence
+        of any recent synchronisation from an NTP server. This is especially useful for offline systems
+        with no local RTC, as it will guarantee that the system clock remains roughly monotonic across
+        reboots.</para>
+
+        <para>Takes a time interval value. The default unit is seconds, but other units may be specified, see
+        <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+        Defaults to 60 seconds.</para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+      <title>See Also</title>
+      <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-timesyncd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+      </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/tmpfiles.d.xml b/man/tmpfiles.d.xml
new file mode 100644
index 0000000..971b7e6
--- /dev/null
+++ b/man/tmpfiles.d.xml
@@ -0,0 +1,910 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!--
+  SPDX-License-Identifier: LGPL-2.1-or-later
+
+  Copyright © 2010 Brandon Philips
+-->
+<refentry id="tmpfiles.d"
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>tmpfiles.d</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>tmpfiles.d</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>tmpfiles.d</refname>
+    <refpurpose>Configuration for creation, deletion and cleaning of
+    volatile and temporary files</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><literallayout><filename>/etc/tmpfiles.d/*.conf</filename>
+<filename>/run/tmpfiles.d/*.conf</filename>
+<filename>/usr/lib/tmpfiles.d/*.conf</filename>
+    </literallayout></para>
+
+    <para><literallayout><filename>~/.config/user-tmpfiles.d/*.conf</filename>
+<filename>$XDG_RUNTIME_DIR/user-tmpfiles.d/*.conf</filename>
+<filename>~/.local/share/user-tmpfiles.d/*.conf</filename>
+<filename index='false'>…</filename>
+<filename>/usr/share/user-tmpfiles.d/*.conf</filename>
+    </literallayout></para>
+
+    <programlisting>#Type Path                                     Mode User Group Age         Argument
+f     /file/to/create                          mode user group -           content
+f+    /file/to/create-or-truncate              mode user group -           content
+w     /file/to/write-to                        -    -    -     -           content
+w+    /file/to/append-to                       -    -    -     -           content
+d     /directory/to/create-and-clean-up        mode user group cleanup-age -
+D     /directory/to/create-and-remove          mode user group cleanup-age -
+e     /directory/to/clean-up                   mode user group cleanup-age -
+v     /subvolume-or-directory/to/create        mode user group cleanup-age -
+q     /subvolume-or-directory/to/create        mode user group cleanup-age -
+Q     /subvolume-or-directory/to/create        mode user group cleanup-age -
+p     /fifo/to/create                          mode user group -           -
+p+    /fifo/to/[re]create                      mode user group -           -
+L     /symlink/to/create                       -    -    -     -           symlink/target/path
+L+    /symlink/to/[re]create                   -    -    -     -           symlink/target/path
+c     /dev/char-device-to-create               mode user group -           major:minor
+c+    /dev/char-device-to-[re]create           mode user group -           major:minor
+b     /dev/block-device-to-create              mode user group -           major:minor
+b+    /dev/block-device-to-[re]create          mode user group -           major:minor
+C     /target/to/create                        -    -    -     cleanup-age /source/to/copy
+C+    /target/to/create                        -    -    -     cleanup-age /source/to/copy
+x     /path-or-glob/to/ignore/recursively      -    -    -     cleanup-age -
+X     /path-or-glob/to/ignore                  -    -    -     cleanup-age -
+r     /path-or-glob/to/remove                  -    -    -     -           -
+R     /path-or-glob/to/remove/recursively      -    -    -     -           -
+z     /path-or-glob/to/adjust/mode             mode user group -           -
+Z     /path-or-glob/to/adjust/mode/recursively mode user group -           -
+t     /path-or-glob/to/set/xattrs              -    -    -     -           xattrs
+T     /path-or-glob/to/set/xattrs/recursively  -    -    -     -           xattrs
+h     /path-or-glob/to/set/attrs               -    -    -     -           file attrs
+H     /path-or-glob/to/set/attrs/recursively   -    -    -     -           file attrs
+a     /path-or-glob/to/set/acls                -    -    -     -           POSIX ACLs
+a+    /path-or-glob/to/append/acls             -    -    -     -           POSIX ACLs
+A     /path-or-glob/to/set/acls/recursively    -    -    -     -           POSIX ACLs
+A+    /path-or-glob/to/append/acls/recursively -    -    -     -           POSIX ACLs
+
+</programlisting>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><filename>tmpfiles.d</filename> configuration files provide a generic mechanism to define the
+    <emphasis>creation</emphasis> of regular files, directories, pipes, and device nodes, adjustments to
+    their <emphasis>access mode, ownership, attributes, quota assignments, and contents</emphasis>, and
+    finally their time-based <emphasis>removal</emphasis>. It is mostly commonly used for volatile and
+    temporary files and directories (such as those located under <filename>/run/</filename>,
+    <filename>/tmp/</filename>, <filename>/var/tmp/</filename>, the API file systems such as
+    <filename>/sys/</filename> or <filename>/proc/</filename>, as well as some other directories below
+    <filename>/var/</filename>).</para>
+
+    <para><citerefentry><refentrytitle>systemd-tmpfiles</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    uses this configuration to create volatile files and directories during boot and to do periodic cleanup
+    afterwards. See
+    <citerefentry><refentrytitle>systemd-tmpfiles</refentrytitle><manvolnum>8</manvolnum></citerefentry> for
+    the description of <filename>systemd-tmpfiles-setup.service</filename>,
+    <filename>systemd-tmpfiles-clean.service</filename>, and associated units.</para>
+
+    <para>System daemons frequently require private runtime directories below <filename>/run/</filename> to
+    store communication sockets and similar. For these, it is better to use
+    <varname>RuntimeDirectory=</varname> in their unit files (see
+    <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
+    details), if the flexibility provided by <filename>tmpfiles.d</filename> is not required. The advantages
+    are that the configuration required by the unit is centralized in one place, and that the lifetime of the
+    directory is tied to the lifetime of the service itself. Similarly, <varname>StateDirectory=</varname>,
+    <varname>CacheDirectory=</varname>, <varname>LogsDirectory=</varname>, and
+    <varname>ConfigurationDirectory=</varname> should be used to create directories under
+    <filename>/var/lib/</filename>, <filename>/var/cache/</filename>, <filename>/var/log/</filename>, and
+    <filename>/etc/</filename>. <filename>tmpfiles.d</filename> should be used for files whose lifetime is
+    independent of any service or requires more complicated configuration.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Configuration Directories and Precedence</title>
+
+    <para>Each configuration file shall be named in the style of
+    <filename><replaceable>package</replaceable>.conf</filename> or
+    <filename><replaceable>package</replaceable>-<replaceable>part</replaceable>.conf</filename>.
+    The second variant should be used when it is desirable to make it
+    easy to override just this part of configuration.</para>
+
+    <para>Files in <filename>/etc/tmpfiles.d</filename> override files with the same name in
+    <filename>/usr/lib/tmpfiles.d</filename> and <filename>/run/tmpfiles.d</filename>. Files in
+    <filename>/run/tmpfiles.d</filename> override files with the same name in
+    <filename>/usr/lib/tmpfiles.d</filename>. Packages should install their configuration files in
+    <filename>/usr/lib/tmpfiles.d</filename>. Files in <filename>/etc/tmpfiles.d</filename> are reserved for
+    the local administrator, who may use this logic to override the configuration files installed by vendor
+    packages. All configuration files are sorted by their filename in lexicographic order, regardless of
+    which of the directories they reside in. If multiple files specify the same path, the entry in the file
+    with the lexicographically earliest name will be applied (note that lines suppressed due to the
+    <literal>!</literal> are filtered before application, meaning that if an early line carries the
+    exclamation mark and is suppressed because of that, a later line matching in path will be applied).  All
+    other conflicting entries will be logged as errors. When two lines are prefix path and suffix path of
+    each other, then the prefix line is always created first, the suffix later (and if removal applies to the
+    line, the order is reversed: the suffix is removed first, the prefix later). Lines that take globs are
+    applied after those accepting no globs. If multiple operations shall be applied on the same file (such as
+    ACL, xattr, file attribute adjustments), these are always done in the same fixed order. Except for those
+    cases, the files/directories are processed in the order they are listed.</para>
+
+    <para>If the administrator wants to disable a configuration file
+    supplied by the vendor, the recommended way is to place a symlink
+    to <filename>/dev/null</filename> in
+    <filename>/etc/tmpfiles.d/</filename> bearing the same filename.
+    </para>
+  </refsect1>
+
+  <refsect1>
+    <title>Configuration File Format</title>
+
+    <para>The configuration format is one line per path, containing type, path, mode, ownership, age, and
+    argument fields. The lines are separated by newlines, the fields by whitespace:</para>
+
+    <programlisting>#Type Path        Mode User Group Age Argument…
+d     /run/user   0755 root root  10d -
+L     /tmp/foobar -    -    -     -   /dev/null</programlisting>
+
+    <para>Fields may contain C-style escapes. With the exception of the seventh field (the "argument") all
+    fields may be enclosed in quotes. Note that any whitespace found in the line after the beginning of the
+    argument field will be considered part of the argument field. To begin the argument field with a
+    whitespace character, use C-style escapes (e.g. <literal>\x20</literal>).</para>
+
+    <refsect2>
+      <title>Type</title>
+
+      <para>The type consists of a single letter and optionally one or more modifier characters: a plus sign
+      (<literal>+</literal>), exclamation mark (<literal>!</literal>), minus sign (<literal>-</literal>),
+      equals sign (<literal>=</literal>), tilde character (<literal>~</literal>) and/or caret
+      (<literal>^</literal>).</para>
+
+      <para>The following line types are understood:</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><varname>f</varname></term>
+          <term><varname>f+</varname></term>
+          <listitem><para><varname>f</varname> will create a file if it does not exist yet. If the argument
+          parameter is given and the file did not exist yet, it will be written to the file.
+          <varname>f+</varname> will create or truncate the file. If the argument parameter is given, it will
+          be written to the file. Does not follow symlinks.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>w</varname></term>
+          <term><varname>w+</varname></term>
+          <listitem><para>Write the argument parameter to a file, if the file exists.
+          If suffixed with <varname>+</varname>, the line will be appended to the file.
+          If your configuration writes multiple lines to the same file, use <varname>w+</varname>.
+          Lines of this type accept shell-style globs in place of normal path names.
+          The argument parameter will be written without a trailing newline.
+          C-style backslash escapes are interpreted. Follows symlinks.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>d</varname></term>
+          <listitem><para>Create a directory. The mode and ownership will be adjusted if specified. Contents
+          of this directory are subject to time-based cleanup if the age argument is specified.
+          </para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>D</varname></term>
+          <listitem><para>Similar to <varname>d</varname>, but in addition the contents of the directory will
+          be removed when <option>--remove</option> is used.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>e</varname></term>
+          <listitem><para>Adjust the mode and ownership of existing directories and remove their contents
+          based on age. Lines of this type accept shell-style globs in place of normal path names. Contents
+          of the directories are subject to time-based cleanup if the age argument is specified. If the age
+          argument is <literal>0</literal>, contents will be unconditionally deleted every time
+          <citerefentry><refentrytitle>systemd-tmpfiles</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+          <option>--clean</option> is run.</para>
+
+          <para>For this entry to be useful, at least one of the mode, user, group, or age arguments must be
+          specified, since otherwise this entry has no effect. As an exception, an entry with no effect may
+          be useful when combined with <varname>!</varname>, see the examples.</para>
+
+          <xi:include href="version-info.xml" xpointer="v230"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>v</varname></term>
+          <listitem><para>Create a subvolume if the path does not exist yet, the file system supports
+          subvolumes (btrfs), and the system itself is installed into a subvolume (specifically: the root
+          directory <filename>/</filename> is itself a subvolume). Otherwise, create a normal directory, in
+          the same way as <varname>d</varname>.</para>
+
+          <para>A subvolume created with this line type is not assigned to any higher-level quota group. For
+          that, use <varname>q</varname> or <varname>Q</varname>, which allow creating simple quota group
+          hierarchies, see below.</para>
+
+          <xi:include href="version-info.xml" xpointer="v219"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>q</varname></term>
+          <listitem><para>Create a subvolume or directory the same as <varname>v</varname>, but assign the
+          subvolume to the same higher-level quota groups as the parent. This ensures that higher-level
+          limits and accounting applied to the parent subvolume also include the specified subvolume. On
+          non-btrfs file systems, this line type is identical to <varname>d</varname>.</para>
+
+          <para>If the subvolume already exists, no change to the quota hierarchy is made, regardless of whether the
+          subvolume is already attached to a quota group or not. Also see <varname>Q</varname> below. See
+          <citerefentry project='url'><refentrytitle url='https://btrfs.readthedocs.io/en/latest/btrfs-qgroup.html'>btrfs-qgroup</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+          for details about the btrfs quota group concept.</para>
+
+          <xi:include href="version-info.xml" xpointer="v228"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>Q</varname></term>
+          <listitem><para>Create the subvolume or directory the same as <varname>v</varname>, but assign the
+          new subvolume to a new leaf quota group. Instead of copying the higher-level quota group
+          assignments from the parent as is done with <varname>q</varname>, the lowest quota group of the
+          parent subvolume is determined that is not the leaf quota group. Then, an "intermediary" quota
+          group is inserted that is one level below this level, and shares the same ID part as the specified
+          subvolume. If no higher-level quota group exists for the parent subvolume, a new quota group at
+          level 255 sharing the same ID as the specified subvolume is inserted instead. This new intermediary
+          quota group is then assigned to the parent subvolume's higher-level quota groups, and the specified
+          subvolume's leaf quota group is assigned to it.</para>
+
+          <para>Effectively, this has a similar effect as <varname>q</varname>, however introduces a new higher-level
+          quota group for the specified subvolume that may be used to enforce limits and accounting to the specified
+          subvolume and children subvolume created within it. Thus, by creating subvolumes only via
+          <varname>q</varname> and <varname>Q</varname>, a concept of "subtree quotas" is implemented. Each subvolume
+          for which <varname>Q</varname> is set will get a "subtree" quota group created, and all child subvolumes
+          created within it will be assigned to it. Each subvolume for which <varname>q</varname> is set will not get
+          such a "subtree" quota group, but it is ensured that they are added to the same "subtree" quota group as
+          their immediate parents.</para>
+
+          <para>It is recommended to use <varname>Q</varname> for subvolumes that typically contain further subvolumes,
+          and where it is desirable to have accounting and quota limits on all child subvolumes together. Examples for
+          <varname>Q</varname> are typically <filename>/home/</filename> or <filename>/var/lib/machines/</filename>. In
+          contrast, <varname>q</varname> should be used for subvolumes that either usually do not include further
+          subvolumes or where no accounting and quota limits are needed that apply to all child subvolumes
+          together. Examples for <varname>q</varname> are typically <filename>/var/</filename> or
+          <filename>/var/tmp/</filename>. </para>
+
+          <para>As with <varname>q</varname>, <varname>Q</varname> has no effect on the quota group hierarchy if the
+          subvolume already exists, regardless of whether the subvolume already belong to a quota group or not.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v228"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>p</varname></term>
+          <term><varname>p+</varname></term>
+          <listitem><para>Create a named pipe (FIFO) if it does not
+          exist yet. If suffixed with <varname>+</varname> and a file
+          already exists where the pipe is to be created, it will be
+          removed and be replaced by the pipe.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>L</varname></term>
+          <term><varname>L+</varname></term>
+          <listitem><para>Create a symlink if it does not exist
+          yet. If suffixed with <varname>+</varname> and a file or
+          directory already exists where the symlink is to be created,
+          it will be removed and be replaced by the symlink. If the
+          argument is omitted, symlinks to files with the same name
+          residing in the directory
+          <filename>/usr/share/factory/</filename> are created. Note
+          that permissions and ownership on symlinks are ignored.
+          </para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>c</varname></term>
+          <term><varname>c+</varname></term>
+          <listitem><para>Create a character device node if it does
+          not exist yet. If suffixed with <varname>+</varname> and a
+          file already exists where the device node is to be created,
+          it will be removed and be replaced by the device node. It is
+          recommended to suffix this entry with an exclamation mark to
+          only create static device nodes at boot, as udev will not
+          manage static device nodes that are created at runtime.
+          </para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>b</varname></term>
+          <term><varname>b+</varname></term>
+          <listitem><para>Create a block device node if it does not
+          exist yet. If suffixed with <varname>+</varname> and a file
+          already exists where the device node is to be created, it
+          will be removed and be replaced by the device node. It is
+          recommended to suffix this entry with an exclamation mark to
+          only create static device nodes at boot, as udev will not
+          manage static device nodes that are created at runtime.
+          </para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>C</varname></term>
+          <term><varname>C+</varname></term>
+          <listitem><para>Recursively copy a file or directory, if the destination files or directories do
+          not exist yet or the destination directory is empty. Note that this command will not descend into
+          subdirectories if the destination directory already exists and is not empty, unless the action is
+          suffixed with <varname>+</varname>. Instead, the entire copy operation is skipped. If the argument
+          is omitted, files from the source directory <filename>/usr/share/factory/</filename> with the same
+          name are copied. Does not follow symlinks. Contents of the directories are subject to time-based
+          cleanup if the age argument is specified.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v214"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>x</varname></term>
+          <listitem><para>Ignore a path during cleaning. Use this type
+          to exclude paths from clean-up as controlled with the Age
+          parameter. Note that lines of this type do not influence the
+          effect of <varname>r</varname> or <varname>R</varname>
+          lines. Lines of this type accept shell-style globs in place
+          of normal path names.  </para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>X</varname></term>
+          <listitem><para>Ignore a path during cleaning. Use this type
+          to exclude paths from clean-up as controlled with the Age
+          parameter. Unlike <varname>x</varname>, this parameter will
+          not exclude the content if path is a directory, but only
+          directory itself. Note that lines of this type do not
+          influence the effect of <varname>r</varname> or
+          <varname>R</varname> lines. Lines of this type accept
+          shell-style globs in place of normal path names.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v198"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>r</varname></term>
+          <listitem><para>Remove a file or directory if it exists.
+          This may not be used to remove non-empty directories, use
+          <varname>R</varname> for that.  Lines of this type accept
+          shell-style globs in place of normal path
+          names. Does not follow symlinks.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>R</varname></term>
+          <listitem><para>Recursively remove a path and all its
+          subdirectories (if it is a directory). Lines of this type
+          accept shell-style globs in place of normal path
+          names. Does not follow symlinks.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>z</varname></term>
+          <listitem><para>Adjust the access mode, user and group ownership, and restore the SELinux security
+          context of a file or directory, if it exists. Lines of this type accept shell-style globs in place
+          of normal path names. Does not follow symlinks.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>Z</varname></term>
+          <listitem><para>Recursively set the access mode, user and group ownership, and restore the SELinux
+          security context of a file or directory if it exists, as well as of its subdirectories and the
+          files contained therein (if applicable). Lines of this type accept shell-style globs in place of
+          normal path names. Does not follow symlinks.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>t</varname></term>
+          <listitem><para>Set extended attributes, see <citerefentry
+          project='man-pages'><refentrytitle>attr</refentrytitle>
+          <manvolnum>5</manvolnum></citerefentry> for details. The argument field should take one or more
+          assignment expressions in the form
+          <replaceable>namespace</replaceable>.<replaceable>attribute</replaceable>=<replaceable>value</replaceable>,
+          for examples see below. Lines of this type accept shell-style globs in place of normal path
+          names. This can be useful for setting SMACK labels. Does not follow symlinks.</para>
+
+          <para>Please note that extended attributes settable with this line type are a different concept
+          from the Linux file attributes settable with <varname>h</varname>/<varname>H</varname>, see
+          below.</para>
+
+          <xi:include href="version-info.xml" xpointer="v218"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>T</varname></term>
+          <listitem><para>Same as <varname>t</varname>, but operates recursively.</para>
+
+          <xi:include href="version-info.xml" xpointer="v219"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>h</varname></term>
+          <listitem><para>Set Linux file/directory attributes. Lines of this type accept shell-style globs in
+          place of normal path names.</para>
+
+          <para>The format of the argument field is <varname>[+-=][aAcCdDeijPsStTu]</varname>. The prefix
+          <varname>+</varname> (the default one) causes the attributes to be added; <varname>-</varname>
+          causes the attributes to be removed; <varname>=</varname> causes the attributes to be set exactly
+          as the following letters. The letters <literal>aAcCdDeijPsStTu</literal> select the new attributes
+          for the files, see <citerefentry project='man-pages'><refentrytitle>chattr</refentrytitle>
+          <manvolnum>1</manvolnum></citerefentry> for further information.
+          </para>
+
+          <para>Passing only <varname>=</varname> as argument resets all the file attributes listed above. It
+          has to be pointed out that the <varname>=</varname> prefix limits itself to the attributes
+          corresponding to the letters listed here. All other attributes will be left untouched. Does not
+          follow symlinks.</para>
+
+          <para>Please note that the Linux file attributes settable with this line type are a different
+          concept from the extended attributes settable with <varname>t</varname>/<varname>T</varname>,
+          see above.</para></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>H</varname></term>
+          <listitem><para>Sames as <varname>h</varname>, but operates recursively.</para>
+
+          <xi:include href="version-info.xml" xpointer="v220"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>a</varname></term>
+          <term><varname>a+</varname></term>
+          <listitem><para>Set POSIX ACLs (access control lists), see
+          <citerefentry project='man-pages'><refentrytitle>acl</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+          Additionally, if 'X' is used, the execute bit is set only if the file is a directory or already has
+          execute permission for some user, as mentioned in
+          <citerefentry project='man-pages'><refentrytitle>setfacl</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
+          If suffixed with <varname>+</varname>, the specified entries will be added to the existing set.
+          <citerefentry><refentrytitle>systemd-tmpfiles</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+          will automatically add the required base entries for user and group based on the access mode of the
+          file, unless base entries already exist or are explicitly specified. The mask will be added if not
+          specified explicitly or already present. Lines of this type accept shell-style globs in place of
+          normal path names. This can be useful for allowing additional access to certain files. Does not
+          follow symlinks.</para>
+
+          <xi:include href="version-info.xml" xpointer="v219"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>A</varname></term>
+          <term><varname>A+</varname></term>
+          <listitem><para>Same as <varname>a</varname> and
+          <varname>a+</varname>, but recursive. Does not follow
+          symlinks.</para>
+
+          <xi:include href="version-info.xml" xpointer="v219"/></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+
+    <refsect2>
+      <title>Type Modifiers</title>
+
+      <para>If the exclamation mark (<literal>!</literal>) is used, this line is only safe to execute during
+      boot, and can break a running system. Lines without the exclamation mark are presumed to be safe to
+      execute at any time, e.g. on package upgrades.
+      <citerefentry><refentrytitle>systemd-tmpfiles</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+      will take lines with an exclamation mark only into consideration, if the <option>--boot</option> option
+      is given.</para>
+
+      <para>For example:
+      <programlisting># Make sure these are created by default so that nobody else can
+d /tmp/.X11-unix 1777 root root 10d
+
+# Unlink the X11 lock files
+r! /tmp/.X[0-9]*-lock</programlisting>
+      The second line in contrast to the first one would break a
+      running system, and will only be executed with
+      <option>--boot</option>.</para>
+
+      <para>If the minus sign (<literal>-</literal>) is used, this line failing to run successfully during
+      create (and only create) will not cause the execution of <command>systemd-tmpfiles</command> to return
+      an error.</para>
+
+      <para>For example:
+      <programlisting># Modify sysfs but don't fail if we are in a container with a read-only /proc
+w- /proc/sys/vm/swappiness - - - - 10</programlisting></para>
+
+      <para>If the equals sign (<literal>=</literal>) is used, the file types of existing objects in the specified path
+      are checked, and removed if they do not match. This includes any implicitly created parent directories (which can
+      be either directories or directory symlinks). For example, if there is a FIFO in place of one of the parent path
+      components it will be replaced with a directory.</para>
+
+      <para>If the tilde character (<literal>~</literal>) is used, the argument (i.e. 6th) column is <ulink
+      url="https://www.rfc-editor.org/rfc/rfc4648.html">Base64 decoded</ulink> before use. This modifier is
+      only supported on line types that can write file contents, i.e. <varname>f</varname>,
+      <varname>f+</varname>, <varname>w</varname>, <varname>+</varname>. This is useful for writing arbitrary
+      binary data (including newlines and NUL bytes) to files. Note that if this switch is used, the argument
+      is not subject to specifier expansion, neither before nor after Base64 decoding.</para>
+
+      <para>If the caret character (<literal>^</literal>) is used, the argument (i.e. 6th) column takes a
+      service credential name to read the argument data from. See <ulink
+      url="https://systemd.io/CREDENTIALS">System and Service Credentials</ulink> for details about the
+      credentials concept. This modifier is only supported on line types that can write file contents,
+      i.e. <varname>f</varname>, <varname>f+</varname>, <varname>w</varname>, <varname>w+</varname>. This is
+      useful for writing arbitrary files with contents sourced from elsewhere, including from VM or container
+      managers further up. If the specified credential is not set for the <command>systemd-tmpfiles</command>
+      service, the line is silently skipped. If <literal>^</literal> and <literal>~</literal> are combined
+      Base64 decoding is applied to the credential contents.</para>
+
+      <para>Note that for all line types that result in creation of any kind of file node
+      (i.e. <varname>f</varname>/<varname>F</varname>,
+      <varname>d</varname>/<varname>D</varname>/<varname>v</varname>/<varname>q</varname>/<varname>Q</varname>,
+      <varname>p</varname>, <varname>L</varname>, <varname>c</varname>/<varname>b</varname> and <varname>C</varname>)
+      leading directories are implicitly created if needed, owned by root with an access mode of 0755. In order to
+      create them with different modes or ownership make sure to add appropriate <varname>d</varname> lines.</para>
+    </refsect2>
+
+    <refsect2>
+      <title>Path</title>
+
+      <para>The file system path specification supports simple
+      specifier expansion, see below. The path (after expansion) must be
+      absolute.</para>
+    </refsect2>
+
+    <refsect2>
+      <title>Mode</title>
+
+      <para>The file access mode to use when creating this file or directory. If omitted or when set to
+      <literal>-</literal>, the default is used: 0755 for directories, 0644 for all other file objects. For
+      <varname>z</varname>, <varname>Z</varname> lines, if omitted or when set to <literal>-</literal>, the
+      file access mode will not be modified. This parameter is ignored for <varname>x</varname>,
+      <varname>r</varname>, <varname>R</varname>, <varname>L</varname>, <varname>t</varname>, and
+      <varname>a</varname> lines.</para>
+
+      <para>Optionally, if prefixed with <literal>~</literal>, the access mode is masked based on the already
+      set access bits for existing file or directories: if the existing file has all executable bits unset,
+      all executable bits are removed from the new access mode, too. Similarly, if all read bits are removed
+      from the old access mode, they will be removed from the new access mode too, and if all write bits are
+      removed, they will be removed from the new access mode too. In addition, the sticky/SUID/SGID bit is
+      removed unless applied to a directory. This functionality is particularly useful in conjunction with
+      <varname>Z</varname>.</para>
+
+      <para>By default the access mode of listed inodes is set to the specified mode regardless if it is
+      created anew, or already existed. Optionally, if prefixed with <literal>:</literal>, the configured
+      access mode is only applied when creating new inodes, and if the inode the line refers to
+      already exists, its access mode is left in place unmodified.</para>
+    </refsect2>
+
+    <refsect2>
+      <title>User, Group</title>
+
+      <para>The user and group to use for this file or directory. This may either be a numeric ID or a
+      user/group name. If omitted or when set to <literal>-</literal>, the user and group of the user who
+      invokes
+      <citerefentry><refentrytitle>systemd-tmpfiles</refentrytitle><manvolnum>8</manvolnum></citerefentry> is
+      used. For <varname>z</varname> and <varname>Z</varname> lines, when omitted or when set to
+      <literal>-</literal>, the file ownership will not be modified. These parameters are ignored for
+      <varname>x</varname>, <varname>r</varname>, <varname>R</varname>, <varname>L</varname>,
+      <varname>t</varname>, and <varname>a</varname> lines.</para>
+
+      <para>This field should generally only reference system users/groups, i.e. users/groups that are
+      guaranteed to be resolvable during early boot. If this field references users/groups that only become
+      resolveable during later boot (i.e. after NIS, LDAP or a similar networked directory service become
+      available), execution of the operations declared by the line will likely fail. Also see <ulink
+      url="https://systemd.io/UIDS-GIDS/#notes-on-resolvability-of-user-and-group-names">Notes on
+      Resolvability of User and Group Names</ulink> for more information on requirements on system user/group
+      definitions.</para>
+
+      <para>By default the ownership of listed inodes is set to the specified user/group regardless if it is
+      created anew, or already existed. Optionally, if prefixed with <literal>:</literal>, the configured
+      user/group information is only applied when creating new inodes, and if the inode the line refers to
+      already exists, its user/group is left in place unmodified.</para>
+    </refsect2>
+
+    <refsect2>
+      <title>Age</title>
+
+      <para>The date field, when set, is used to decide what files to
+      delete when cleaning. If a file or directory is older than the
+      current time minus the age field, it is deleted. The field
+      format is a series of integers each followed by one of the
+      following suffixes for the respective time units:
+      <constant>s</constant>,
+      <constant>m</constant> or <constant>min</constant>,
+      <constant>h</constant>,
+      <constant>d</constant>,
+      <constant>w</constant>,
+      <constant>ms</constant>, and
+      <constant>us</constant>,
+      meaning seconds, minutes, hours, days, weeks,
+      milliseconds, and microseconds, respectively. Full names of the time units can
+      be used too.
+      </para>
+
+      <para>If multiple integers and units are specified, the time
+      values are summed. If an integer is given without a unit,
+      <constant>s</constant> is assumed.
+      </para>
+
+      <para>When the age is set to zero, the files are cleaned
+      unconditionally.</para>
+
+      <para>The age field only applies to lines starting with
+      <varname>d</varname>, <varname>D</varname>, <varname>e</varname>,
+      <varname>v</varname>, <varname>q</varname>,
+      <varname>Q</varname>, <varname>C</varname>, <varname>x</varname>
+      and <varname>X</varname>. If omitted or set to
+      <literal>-</literal>, no automatic clean-up is done.</para>
+
+      <para>If the age field starts with a tilde character <literal>~</literal>, clean-up is only applied to
+      files and directories one level inside the directory specified, but not the files and directories
+      immediately inside it.</para>
+
+      <para>The age of a file system entry is determined from its last
+      modification timestamp (mtime), its last access timestamp (atime),
+      and (except for directories) its last status change timestamp
+      (ctime). By default, any of these three (or two) values will
+      prevent cleanup if it is more recent than the current time minus
+      the age field. To restrict the deletion based on particular type
+      of file timestamps, the age-by argument can be used.</para>
+
+      <para>The age-by argument overrides the timestamp types to be used for the age check. It can be
+      specified by prefixing the age argument with a sequence of characters to specify the timestamp types
+      and a colon (<literal>:</literal>):
+      <literal><replaceable>age-by</replaceable>...:<replaceable>cleanup-age</replaceable></literal>.  The
+      argument can consist of <constant>a</constant> (<constant>A</constant> for directories),
+      <constant>b</constant> (<constant>B</constant> for directories), <constant>c</constant>
+      (<constant>C</constant> for directories), or <constant>m</constant> (<constant>M</constant> for
+      directories). Those respectively indicate access, creation, last status change, and last modification
+      time of a file system entry. The lower-case letter signifies that the given timestamp type should be
+      considered for files, while the upper-case letter signifies that the given timestamp type should be
+      considered for directories. See <citerefentry
+      project='man-pages'><refentrytitle>statx</refentrytitle><manvolnum>2</manvolnum></citerefentry> file
+      timestamp fields for more details about timestamp types.</para>
+
+      <para>If not specified, the age-by field defaults to <constant>abcmABM</constant>, i.e. by default all
+      file timestamps are taken into consideration, with the exception of the last status change timestamp
+      (ctime) for directories. This is because the aging logic itself will alter the ctime whenever it
+      deletes a file inside it. To ensure that running the aging logic does not feed back into the next
+      iteration of itself, ctime for directories is ignored by default.</para>
+
+      <para>For example:<programlisting>
+# Files created and modified, and directories accessed more than
+# an hour ago in "/tmp/foo/bar", are subject to time-based cleanup.
+d /tmp/foo/bar - - - bmA:1h -</programlisting></para>
+
+      <para>Note that while the aging algorithm is run an exclusive BSD file lock (see <citerefentry
+      project='man-pages'><refentrytitle>flock</refentrytitle><manvolnum>2</manvolnum></citerefentry>) is
+      taken on each directory/file the algorithm decides to remove. If the aging algorithm finds a lock
+      (shared or exclusive) is already taken on some directory/file, it (and everything below it) is skipped.
+      Applications may use this to temporarily exclude certain directory subtrees from the aging algorithm:
+      the applications can take a BSD file lock themselves, and as long as they keep it aging of the
+      directory/file and everything below it is disabled.</para>
+
+      <para>This behavior can be used to ensure guaranteed cleanup of files or directories whose lifetime
+      should be aligned with the process that created them by having that process create them in a location
+      monitored by <command>systemd-tmpfiles</command> with an age of <literal>0</literal>, and having the
+      process immediately lock the directory or file before using it. Because the BSD lock is process
+      specific, the file is guaranteed to be unlocked as soon as the process exits, meaning that even if the
+      process crashes, those files and directories will be unlocked and cleaned up by
+      <command>systemd-tmpfiles</command>.</para>
+    </refsect2>
+
+    <refsect2>
+      <title>Argument</title>
+
+      <para>For <varname>L</varname> lines determines the destination path of the symlink. For <varname>c</varname> and
+      <varname>b</varname>, determines the major/minor of the device node, with major and minor formatted as integers,
+      separated by <literal>:</literal>, e.g.  <literal>1:3</literal>. For <varname>f</varname>, <varname>F</varname>,
+      and <varname>w</varname>, the argument may be used to specify a short string that is written to the file,
+      suffixed by a newline. For <varname>C</varname>, specifies the source file or directory. For <varname>t</varname>
+      and <varname>T</varname>, determines extended attributes to be set. For <varname>a</varname> and
+      <varname>A</varname>, determines ACL attributes to be set. For <varname>h</varname> and <varname>H</varname>,
+      determines the file attributes to set. Ignored for all other lines.</para>
+
+      <para>This field can contain specifiers, see below.</para>
+    </refsect2>
+  </refsect1>
+
+  <refsect1>
+    <title>Specifiers</title>
+
+    <para>Specifiers can be used in the "path" and "argument" fields.
+    An unknown or unresolvable specifier is treated as invalid configuration.
+    The following expansions are understood:</para>
+      <table class='specifiers'>
+        <title>Specifiers available</title>
+        <tgroup cols='3' align='left' colsep='1' rowsep='1'>
+          <colspec colname="spec" />
+          <colspec colname="mean" />
+          <colspec colname="detail" />
+          <thead>
+            <row>
+              <entry>Specifier</entry>
+              <entry>Meaning</entry>
+              <entry>Details</entry>
+            </row>
+          </thead>
+          <tbody>
+            <xi:include href="standard-specifiers.xml" xpointer="a"/>
+            <xi:include href="standard-specifiers.xml" xpointer="A"/>
+            <xi:include href="standard-specifiers.xml" xpointer="b"/>
+            <xi:include href="standard-specifiers.xml" xpointer="B"/>
+            <row>
+              <entry><literal>%C</literal></entry>
+              <entry>System or user cache directory</entry>
+              <entry>In <option>--user</option> mode, this is the same as <varname>$XDG_CACHE_HOME</varname>, and <filename>/var/cache</filename> otherwise.</entry>
+            </row>
+            <row>
+              <entry><literal>%g</literal></entry>
+              <entry>User group</entry>
+              <entry>This is the name of the group running the command. In case of the system instance this resolves to <literal>root</literal>.</entry>
+            </row>
+            <row>
+              <entry><literal>%G</literal></entry>
+              <entry>User GID</entry>
+              <entry>This is the numeric GID of the group running the command. In case of the system instance this resolves to <constant>0</constant>.</entry>
+            </row>
+            <row>
+              <entry><literal>%h</literal></entry>
+              <entry>User home directory</entry>
+              <entry>This is the home directory of the user running the command. In case of the system instance this resolves to <literal>/root</literal>.</entry>
+            </row>
+            <xi:include href="standard-specifiers.xml" xpointer="H"/>
+            <xi:include href="standard-specifiers.xml" xpointer="l"/>
+            <row>
+              <entry><literal>%L</literal></entry>
+              <entry>System or user log directory</entry>
+              <entry>In <option>--user</option> mode, this is the same as <varname>$XDG_STATE_HOME</varname> with <filename index="false">/log</filename> appended, and <filename>/var/log</filename> otherwise.</entry>
+            </row>
+            <xi:include href="standard-specifiers.xml" xpointer="m"/>
+            <xi:include href="standard-specifiers.xml" xpointer="M"/>
+            <xi:include href="standard-specifiers.xml" xpointer="o"/>
+            <row>
+              <entry><literal>%S</literal></entry>
+              <entry>System or user state directory</entry>
+              <entry>In <option>--user</option> mode, this is the same as <varname>$XDG_STATE_HOME</varname>, and <filename>/var/lib</filename> otherwise.</entry>
+            </row>
+            <row>
+              <entry><literal>%t</literal></entry>
+              <entry>System or user runtime directory</entry>
+              <entry>In <option>--user</option> mode, this is the same <varname>$XDG_RUNTIME_DIR</varname>, and <filename>/run/</filename> otherwise.</entry>
+            </row>
+            <xi:include href="standard-specifiers.xml" xpointer="T"/>
+            <row>
+              <entry><literal>%u</literal></entry>
+              <entry>User name</entry>
+              <entry>This is the name of the user running the command. In case of the system instance this resolves to <literal>root</literal>.</entry>
+            </row>
+            <row>
+              <entry><literal>%U</literal></entry>
+              <entry>User UID</entry>
+              <entry>This is the numeric UID of the user running the command. In case of the system instance this resolves to <constant>0</constant>.</entry>
+            </row>
+            <xi:include href="standard-specifiers.xml" xpointer="v"/>
+            <xi:include href="standard-specifiers.xml" xpointer="V"/>
+            <xi:include href="standard-specifiers.xml" xpointer="w"/>
+            <xi:include href="standard-specifiers.xml" xpointer="W"/>
+            <xi:include href="standard-specifiers.xml" xpointer="percent"/>
+          </tbody>
+        </tgroup>
+      </table>
+  </refsect1>
+
+  <refsect1>
+    <title>Examples</title>
+    <example>
+      <title>Create directories with specific mode and ownership</title>
+      <para>
+      <citerefentry project='die-net'><refentrytitle>screen</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      needs two directories created at boot with specific modes and ownership:</para>
+
+      <programlisting># /usr/lib/tmpfiles.d/screen.conf
+d /run/screens  1777 root screen 10d
+d /run/uscreens 0755 root screen 10d12h
+</programlisting>
+
+      <para>Contents of <filename>/run/screens</filename> and /run/uscreens will
+      be cleaned up after 10 and 10½ days, respectively.</para>
+    </example>
+
+    <example>
+      <title>Create a directory with a SMACK attribute</title>
+      <programlisting>D /run/cups - - - -
+t /run/cups - - - - security.SMACK64=printing user.attr-with-spaces="foo bar"
+      </programlisting>
+
+      <para>The directory will be owned by root and have default mode. Its contents are
+      not subject to time-based cleanup, but will be obliterated when
+      <command>systemd-tmpfiles --remove</command> runs.</para>
+    </example>
+
+    <example>
+      <title>Create a directory and prevent its contents from cleanup</title>
+      <para>
+      <citerefentry project='die-net'><refentrytitle>abrt</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      needs a directory created at boot with specific mode and ownership and its content
+      should be preserved from the automatic cleanup applied to the contents of
+      <filename>/var/tmp</filename>:</para>
+
+      <programlisting># /usr/lib/tmpfiles.d/tmp.conf
+d /var/tmp 1777 root root 30d
+</programlisting>
+
+      <programlisting># /usr/lib/tmpfiles.d/abrt.conf
+d /var/tmp/abrt 0755 abrt abrt -
+</programlisting>
+    </example>
+
+    <example>
+      <title>Apply clean up during boot and based on time</title>
+
+      <programlisting># /usr/lib/tmpfiles.d/dnf.conf
+r! /var/cache/dnf/*/*/download_lock.pid
+r! /var/cache/dnf/*/*/metadata_lock.pid
+r! /var/lib/dnf/rpmdb_lock.pid
+e  /var/cache/dnf/ - - - 30d
+</programlisting>
+
+     <para>The lock files will be removed during boot. Any files and directories in
+     <filename>/var/cache/dnf/</filename> will be removed after they have not been
+     accessed in 30 days.</para>
+    </example>
+
+    <example>
+      <title>Empty the contents of a cache directory on boot</title>
+
+      <programlisting># /usr/lib/tmpfiles.d/krb5rcache.conf
+e! /var/cache/krb5rcache - - - 0
+</programlisting>
+
+      <para>Any files and subdirectories in <filename>/var/cache/krb5rcache/</filename>
+      will be removed on boot. The directory will not be created.
+      </para>
+    </example>
+
+    <example>
+      <title>Provision SSH public key access for root user via Credentials in QEMU</title>
+
+      <programlisting>-smbios type=11,value=io.systemd.credential.binary:tmpfiles.extra=$(echo "f~ /root/.ssh/authorized_keys 700 root root - $(ssh-add -L | base64 -w 0)" | base64 -w 0)
+</programlisting>
+
+      <para>By passing this line to QEMU, the public key of the current user will be encoded in base64, added
+      to a tmpfiles.d line that tells <command>systemd-tmpfiles</command> to decode it into
+      <filename>/root/.ssh/authorized_keys</filename>, encode that line itself in base64 and pass it as a
+      Credential that will be picked up by systemd from SMBIOS on boot.
+      </para>
+    </example>
+  </refsect1>
+
+  <refsect1>
+    <title><filename>/run/</filename> and <filename>/var/run/</filename></title>
+    <para><filename>/var/run/</filename> is a deprecated symlink to <filename>/run/</filename>, and
+    applications should use the latter. <command>systemd-tmpfiles</command> will warn if
+    <filename>/var/run/</filename> is used.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-tmpfiles</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-delta</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>attr</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>getfattr</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>setfattr</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>setfacl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>getfacl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>chattr</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry project='url'><refentrytitle url='https://btrfs.readthedocs.io/en/latest/btrfs-subvolume.html'>btrfs-subvolume</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry project='url'><refentrytitle url='https://btrfs.readthedocs.io/en/latest/btrfs-qgroup.html'>btrfs-qgroup</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/tpm2-crypttab.sh b/man/tpm2-crypttab.sh
new file mode 100644
index 0000000..2be3499
--- /dev/null
+++ b/man/tpm2-crypttab.sh
@@ -0,0 +1,41 @@
+# SPDX-License-Identifier: MIT-0
+
+# Enroll the TPM2 security chip in the LUKS2 volume, and bind it to PCR 7
+# only. Replace /dev/sdXn by the partition to use (e.g. /dev/sda1).
+sudo systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=7 /dev/sdXn
+
+# Test: Let's run systemd-cryptsetup to test if this worked.
+sudo systemd-cryptsetup attach mytest /dev/sdXn - tpm2-device=auto
+
+# If that worked, let's now add the same line persistently to /etc/crypttab,
+# for the future. We don't want to use the (unstable) /dev/sdX name, so let's
+# figure out a stable link:
+udevadm info -q -r symlink /dev/sdXn
+
+# Now add the line using the by-uuid symlink to /etc/crypttab:
+sudo bash -c 'echo "mytest /dev/disk/by-uuid/... - tpm2-device=auto" >>/etc/crypttab'
+
+# And now let's check that automatic unlocking works:
+sudo systemd-cryptsetup detach mytest
+sudo systemctl daemon-reload
+sudo systemctl start cryptsetup.target
+systemctl is-active systemd-cryptsetup@mytest.service
+
+# Once we have the device which will be unlocked automatically, we can use it.
+# Usually we would create a file system and add it to /etc/fstab:
+sudo mkfs.ext4 /dev/mapper/mytest
+# This prints a 'Filesystem UUID', which we can use as a stable name:
+sudo bash -c 'echo "/dev/disk/by-uuid/... /var/mytest ext4 defaults,x-systemd.mkdir 0 2" >>/etc/fstab'
+# And now let's check that the mounting works:
+sudo systemctl daemon-reload
+sudo systemctl start /var/mytest
+systemctl status /var/mytest
+
+# Depending on your distribution and encryption setup, you may need to manually
+# regenerate your initramfs to be able to use a TPM2 security chip to unlock
+# the partition during early boot.
+# More information at https://unix.stackexchange.com/a/705809.
+# On Fedora based systems:
+sudo dracut --force
+# On Debian based systems:
+sudo update-initramfs -u
diff --git a/man/udev.conf.xml b/man/udev.conf.xml
new file mode 100644
index 0000000..bfdba7b
--- /dev/null
+++ b/man/udev.conf.xml
@@ -0,0 +1,140 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="udev.conf"
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>udev.conf</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>udev.conf</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>udev.conf</refname>
+    <refpurpose>Configuration for device event managing daemon</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>/etc/udev/udev.conf</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd-udevd</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+      expects its main configuration file at
+      <filename>/etc/udev/udev.conf</filename>. It consists of a set
+      of variables allowing the user to override default udev
+      values. All empty lines or lines beginning with '#' are
+      ignored. The following variables can be set:
+    </para>
+
+    <variablelist class='config-directives'>
+      <varlistentry>
+        <term><varname>udev_log=</varname></term>
+
+        <listitem>
+          <para>The log level. Valid values are the numerical
+          syslog priorities or their textual representations:
+          <option>err</option>, <option>info</option> and
+          <option>debug</option>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v216"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>children_max=</varname></term>
+
+        <listitem>
+          <para>An integer. The maximum number of events executed in parallel. When unspecified or 0 is
+          specified, the maximum is determined based on the system resources.</para>
+
+          <para>This is the same as the <option>--children-max=</option> option.</para>
+
+          <xi:include href="version-info.xml" xpointer="v240"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>exec_delay=</varname></term>
+
+        <listitem>
+          <para>An integer. Delay the execution of each <varname>RUN{<replaceable>program</replaceable>}</varname>
+          parameter by the given number of seconds. This option
+          might be useful when debugging system crashes during
+          coldplug caused by loading non-working kernel
+          modules.</para>
+
+          <para>This is the same as the <option>--exec-delay=</option> option.</para>
+
+          <xi:include href="version-info.xml" xpointer="v240"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>event_timeout=</varname></term>
+
+        <listitem>
+          <para>An integer. The number of seconds to wait for events to finish. After
+          this time, the event will be terminated. The default is 180 seconds.</para>
+
+          <para>This is the same as the <option>--event-timeout=</option> option.</para>
+
+          <xi:include href="version-info.xml" xpointer="v240"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>resolve_names=</varname></term>
+
+        <listitem>
+          <para>Specifies when systemd-udevd should resolve names of users and groups.  When set to
+          <option>early</option> (the default), names will be resolved when the rules are parsed.
+          When set to <option>late</option>, names will be resolved for every event.  When set to
+          <option>never</option>, names will never be resolved and all devices will be owned by
+          root.</para>
+
+          <para>This is the same as the <option>--resolve-names=</option> option.</para>
+
+          <xi:include href="version-info.xml" xpointer="v240"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>timeout_signal=</varname></term>
+
+        <listitem>
+          <para>Specifies a signal that <filename>systemd-udevd</filename> will send on worker
+          timeouts. Note that both workers and spawned processes will be killed using this
+          signal. Defaults to <option>SIGKILL</option>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v246"/>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+
+    <para>
+      In addition, <filename>systemd-udevd</filename> can be configured
+      by command line options and the kernel command line (see
+      <citerefentry><refentrytitle>systemd-udevd</refentrytitle><manvolnum>8</manvolnum></citerefentry>).
+    </para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd-udevd</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>udev</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>udevadm</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+</refentry>
diff --git a/man/udev.xml b/man/udev.xml
new file mode 100644
index 0000000..15cac8d
--- /dev/null
+++ b/man/udev.xml
@@ -0,0 +1,900 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+
+<!--
+  SPDX-License-Identifier: LGPL-2.1-or-later
+  Copyright © 2014 Jason St. John
+-->
+
+<refentry id="udev" xmlns:xi="http://www.w3.org/2001/XInclude">
+  <refentryinfo>
+    <title>udev</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>udev</refentrytitle>
+    <manvolnum>7</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>udev</refname>
+    <refpurpose>Dynamic device management</refpurpose>
+  </refnamediv>
+
+  <refsect1>
+    <title>Description</title>
+    <para>udev supplies the system software with device events, manages permissions
+    of device nodes and may create additional symlinks in the <filename>/dev/</filename>
+    directory, or renames network interfaces. The kernel usually just assigns unpredictable
+    device names based on the order of discovery. Meaningful symlinks or network device
+    names provide a way to reliably identify devices based on their properties or
+    current configuration.</para>
+
+    <para>The udev daemon, <citerefentry><refentrytitle>systemd-udevd.service</refentrytitle>
+    <manvolnum>8</manvolnum></citerefentry>, receives device uevents directly from
+    the kernel whenever a device is added or removed from the system, or it changes its
+    state. When udev receives a device event, it matches its configured set of rules
+    against various device attributes to identify the device. Rules that match may
+    provide additional device information to be stored in the udev database or
+    to be used to create meaningful symlink names.</para>
+
+    <para>All device information udev processes is stored in the udev database and
+    sent out to possible event subscribers. Access to all stored data and the event
+    sources is provided by the library libudev.</para>
+  </refsect1>
+
+  <refsect1>
+      <title>Rules Files</title>
+      <para>The udev rules are read from the files located in the system rules directories
+      <filename>/usr/lib/udev/rules.d</filename> and <filename>/usr/local/lib/udev/rules.d</filename>, the
+      volatile runtime directory <filename>/run/udev/rules.d</filename> and the local administration
+      directory <filename>/etc/udev/rules.d</filename>.  All rules files are collectively sorted and
+      processed in lexical order, regardless of the directories in which they live. However, files with
+      identical filenames replace each other. Files in <filename>/etc/</filename> have the highest priority,
+      files in <filename>/run/</filename> take precedence over files with the same name under
+      <filename>/usr/</filename>. This can be used to override a system-supplied rules file with a local
+      file if needed; a symlink in <filename>/etc/</filename> with the same name as a rules file in
+      <filename>/usr/lib/</filename>, pointing to <filename>/dev/null</filename>, disables the rules file
+      entirely. Rule files must have the extension <filename>.rules</filename>; other extensions are
+      ignored.</para>
+
+      <para>Every line in the rules file contains at least one key-value pair.
+      Except for empty lines or lines beginning with <literal>#</literal>, which are ignored.
+      There are two kinds of keys: match and assignment.
+      If all match keys match against their values, the rule gets applied and the
+      assignment keys get the specified values assigned.</para>
+
+      <para>A matching rule may rename a network interface, add symlinks
+      pointing to the device node, or run a specified program as part of
+      the event handling.</para>
+
+      <para>A rule consists of a comma-separated list of one or more key-operator-value expressions.
+      Each expression has a distinct effect, depending on the key and operator used.</para>
+
+      <refsect2>
+        <title>Operators</title>
+        <variablelist>
+          <varlistentry>
+            <term><literal>==</literal></term>
+            <listitem>
+              <para>Compare for equality. (The specified key has the specified value.)</para>
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><literal>!=</literal></term>
+            <listitem>
+              <para>Compare for inequality. (The specified key doesn't have the specified value, or the
+              specified key is not present at all.)
+              </para>
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><literal>=</literal></term>
+            <listitem>
+              <para>Assign a value to a key. Keys that represent a list are reset
+              and only this single value is assigned.</para>
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><literal>+=</literal></term>
+            <listitem>
+              <para>Add the value to a key that holds a list of entries.</para>
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><literal>-=</literal></term>
+            <listitem>
+              <para>Remove the value from a key that holds a list of entries.</para>
+
+            <xi:include href="version-info.xml" xpointer="v217"/>
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><literal>:=</literal></term>
+            <listitem>
+              <para>Assign a value to a key finally; disallow any later changes.</para>
+
+            <xi:include href="version-info.xml" xpointer="v247"/>
+            </listitem>
+          </varlistentry>
+        </variablelist>
+      </refsect2>
+
+      <refsect2>
+        <title>Values</title>
+          <para>Values are written as double quoted strings, such as ("string").
+          To include a quotation mark (") in the value, precede it by a backslash (\").
+          Any other occurrences of a backslash followed by a character are not unescaped.
+          That is, "\t\n" is treated as four characters:
+          backslash, lowercase t, backslash, lowercase n.</para>
+
+          <para>The string can be prefixed with a lowercase e (e"string\n") to mark the string as
+          C-style escaped, see
+          <ulink url="https://en.wikipedia.org/wiki/Escape_sequences_in_C#Table_of_escape_sequences">Escape sequences in C</ulink>.
+          For example, e"string\n" is parsed as 7 characters: 6 lowercase letters and a newline.
+          This can be useful for writing special characters when a kernel driver requires them.</para>
+
+          <para>Please note that <constant>NUL</constant> is not allowed in either string variant.</para>
+      </refsect2>
+
+      <refsect2>
+        <title>Keys</title>
+        <para>The following key names can be used to match against device properties.
+        Some of the keys also match against properties of the parent devices in sysfs,
+        not only the device that has generated the event. If multiple keys that match
+        a parent device are specified in a single rule, all these keys must match at
+        one and the same parent device.</para>
+        <variablelist class='udev-directives'>
+          <varlistentry>
+            <term><varname>ACTION</varname></term>
+            <listitem>
+              <para>Match the name of the event action.</para>
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><varname>DEVPATH</varname></term>
+            <listitem>
+              <para>Match the devpath of the event device.</para>
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><varname>KERNEL</varname></term>
+            <listitem>
+              <para>Match the name of the event device.</para>
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><varname>KERNELS</varname></term>
+            <listitem>
+              <para>Search the devpath upwards for a matching device name.</para>
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><varname>NAME</varname></term>
+            <listitem>
+              <para>Match the name of a network interface. It can be used once the
+              NAME key has been set in one of the preceding rules.</para>
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><varname>SYMLINK</varname></term>
+            <listitem>
+              <para>Match the name of a symlink targeting the node. It can be used once a SYMLINK key has
+              been set in one of the preceding rules. There may be multiple symlinks; only one needs to
+              match. If the operator is <literal>!=</literal>, the token returns true only if there is no
+              symlink matched.</para>
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><varname>SUBSYSTEM</varname></term>
+            <listitem>
+              <para>Match the subsystem of the event device.</para>
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><varname>SUBSYSTEMS</varname></term>
+            <listitem>
+              <para>Search the devpath upwards for a matching device subsystem name.</para>
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><varname>DRIVER</varname></term>
+            <listitem>
+              <para>Match the driver name of the event device. Only set this key for devices
+              which are bound to a driver at the time the event is generated.</para>
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><varname>DRIVERS</varname></term>
+            <listitem>
+              <para>Search the devpath upwards for a matching device driver name.</para>
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><varname>ATTR{<replaceable>filename</replaceable>}</varname></term>
+            <listitem>
+              <para>Match sysfs attribute value of the event device.</para>
+
+              <para>Trailing whitespace in the attribute values is ignored unless the specified match value
+              itself contains trailing whitespace.</para>
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><varname>ATTRS{<replaceable>filename</replaceable>}</varname></term>
+            <listitem>
+              <para>Search the devpath upwards for a device with matching sysfs attribute values. If
+              multiple <varname>ATTRS</varname> matches are specified, all of them must match on the same
+              device.</para>
+
+              <para>Trailing whitespace in the attribute values is ignored unless the specified match value
+              itself contains trailing whitespace.</para>
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><varname>SYSCTL{<replaceable>kernel parameter</replaceable>}</varname></term>
+            <listitem>
+              <para>Match a kernel parameter value.</para>
+
+            <xi:include href="version-info.xml" xpointer="v240"/>
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><varname>ENV{<replaceable>key</replaceable>}</varname></term>
+            <listitem>
+              <para>Match against a device property value.</para>
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><varname>CONST{<replaceable>key</replaceable>}</varname></term>
+            <listitem>
+              <para>Match against a system-wide constant. Supported keys are:</para>
+              <variablelist>
+                <varlistentry>
+                  <term><literal>arch</literal></term>
+                  <listitem>
+                    <para>System's architecture. See <option>ConditionArchitecture=</option> in
+                    <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+                    for possible values.</para>
+
+                  <xi:include href="version-info.xml" xpointer="v244"/>
+                  </listitem>
+                </varlistentry>
+                <varlistentry>
+                  <term><literal>virt</literal></term>
+                  <listitem>
+                    <para>System's virtualization environment. See
+                    <citerefentry><refentrytitle>systemd-detect-virt</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+                    for possible values.</para>
+
+                    <xi:include href="version-info.xml" xpointer="v244"/>
+                  </listitem>
+                </varlistentry>
+                <varlistentry>
+                  <term><literal>cvm</literal></term>
+                  <listitem>
+                    <para>System's confidential virtualization technology. See
+                    <citerefentry><refentrytitle>systemd-detect-virt</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+                    for possible values.</para>
+
+                    <xi:include href="version-info.xml" xpointer="v254"/>
+                  </listitem>
+                </varlistentry>
+              </variablelist>
+              <para>Unknown keys will never match.</para>
+
+              <xi:include href="version-info.xml" xpointer="v244"/>
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><varname>TAG</varname></term>
+            <listitem>
+              <para>Match against one of device tags. It can be used once a TAG key has been set in one of
+              the preceding rules. There may be multiple tags; only one needs to match. If the operator is
+              <literal>!=</literal>, the token returns true only if there is no tag matched.</para>
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><varname>TAGS</varname></term>
+            <listitem>
+              <para>Search the devpath upwards for a device with matching tag. If the operator is
+              <literal>!=</literal>, the token returns true only if there is no tag matched.</para>
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><varname>TEST{<replaceable>octal mode mask</replaceable>}</varname></term>
+            <listitem>
+              <para>Test the existence of a file. An octal mode mask can be specified
+              if needed.</para>
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><varname>PROGRAM</varname></term>
+            <listitem>
+              <para>Execute a program to determine whether there is a match; the key is true if the program
+              returns successfully. The device properties are made available to the executed program in the
+              environment. The program's standard output is available in the <varname>RESULT</varname>
+              key.</para>
+
+              <para>This can only be used for very short-running foreground tasks. For details, see
+              <varname>RUN</varname>.</para>
+
+              <para>Note that multiple <varname>PROGRAM</varname> keys may be specified in one rule, and
+              <literal>=</literal>, <literal>:=</literal>, and <literal>+=</literal> have the same effect as
+              <literal>==</literal>.</para>
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><varname>RESULT</varname></term>
+            <listitem>
+              <para>Match the returned string of the last <varname>PROGRAM</varname> call.
+              This key can be used in the same or in any later rule after a
+              <varname>PROGRAM</varname> call.</para>
+            </listitem>
+          </varlistentry>
+        </variablelist>
+
+        <para>Most of the fields support shell glob pattern matching and
+        alternate patterns. The following special characters are supported:</para>
+        <variablelist>
+          <varlistentry>
+            <term><literal>*</literal></term>
+            <listitem>
+              <para>Matches zero or more characters.</para>
+            </listitem>
+          </varlistentry>
+          <varlistentry>
+            <term><literal>?</literal></term>
+            <listitem>
+              <para>Matches any single character.</para>
+            </listitem>
+          </varlistentry>
+          <varlistentry>
+            <term><literal>[]</literal></term>
+            <listitem>
+              <para>Matches any single character specified within the brackets. For
+              example, the pattern string <literal>tty[SR]</literal>
+              would match either <literal>ttyS</literal> or <literal>ttyR</literal>.
+              Ranges are also supported via the <literal>-</literal> character.
+              For example, to match on the range of all digits, the pattern
+              <literal>[0-9]</literal> could be used. If the first character
+              following the <literal>[</literal> is a <literal>!</literal>,
+              any characters not enclosed are matched.</para>
+            </listitem>
+          </varlistentry>
+          <varlistentry>
+            <term><literal>|</literal></term>
+            <listitem>
+              <para>Separates alternative patterns. For example, the pattern string
+              <literal>abc|x*</literal> would match either <literal>abc</literal>
+              or <literal>x*</literal>.</para>
+
+              <xi:include href="version-info.xml" xpointer="v217"/>
+            </listitem>
+          </varlistentry>
+        </variablelist>
+
+        <para>The following keys can get values assigned:</para>
+        <variablelist class='udev-directives'>
+          <varlistentry>
+            <term><varname>NAME</varname></term>
+            <listitem>
+              <para>The name to use for a network interface. See
+              <citerefentry><refentrytitle>systemd.link</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+              for a higher-level mechanism for setting the interface name.
+              The name of a device node cannot be changed by udev, only additional
+              symlinks can be created.</para>
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><varname>SYMLINK</varname></term>
+            <listitem>
+              <para>The name of a symlink targeting the node. Every matching rule adds
+              this value to the list of symlinks to be created.</para>
+              <para>The set of characters to name a symlink is limited. Allowed
+              characters are <literal>0-9A-Za-z#+-.:=@_/</literal>, valid UTF-8 character
+              sequences, and <literal>\x00</literal> hex encoding. All other
+              characters are replaced by a <literal>_</literal> character.</para>
+              <para>Multiple symlinks may be specified by separating the names by the
+              space character. In case multiple devices claim the same name, the link
+              always points to the device with the highest link_priority. If the current
+              device goes away, the links are re-evaluated and the device with the
+              next highest link_priority becomes the owner of the link. If no
+              link_priority is specified, the order of the devices (and which one of
+              them owns the link) is undefined.</para>
+              <para>Symlink names must never conflict with the kernel's default device
+              node names, as that would result in unpredictable behavior.
+              </para>
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><varname>OWNER</varname>, <varname>GROUP</varname>, <varname>MODE</varname></term>
+            <listitem>
+              <para>The permissions for the device node. Every specified value overrides
+              the compiled-in default value.</para>
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><varname>SECLABEL{<replaceable>module</replaceable>}</varname></term>
+            <listitem>
+              <para>Applies the specified Linux Security Module label to the device node.</para>
+
+            <xi:include href="version-info.xml" xpointer="v209"/>
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><varname>ATTR{<replaceable>key</replaceable>}</varname></term>
+            <listitem>
+              <para>The value that should be written to a sysfs attribute of the
+              event device.</para>
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><varname>SYSCTL{<replaceable>kernel parameter</replaceable>}</varname></term>
+            <listitem>
+              <para>The value that should be written to kernel parameter.</para>
+
+            <xi:include href="version-info.xml" xpointer="v220"/>
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><varname>ENV{<replaceable>key</replaceable>}</varname></term>
+            <listitem>
+              <para>Set a device property value. Property names with a leading <literal>.</literal>
+              are neither stored in the database nor exported to events or
+              external tools (run by, for example, the <varname>PROGRAM</varname>
+              match key).</para>
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><varname>TAG</varname></term>
+            <listitem>
+              <para>Attach a tag to a device. This is used to filter events for users
+              of libudev's monitor functionality, or to enumerate a group of tagged
+              devices. The implementation can only work efficiently if only a few
+              tags are attached to a device. It is only meant to be used in
+              contexts with specific device filter requirements, and not as a
+              general-purpose flag. Excessive use might result in inefficient event
+              handling.</para>
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><varname>RUN{<replaceable>type</replaceable>}</varname></term>
+            <listitem>
+              <para>Specify a program to be executed after processing of all the rules for the event. With
+              <literal>+=</literal>, this invocation is added to the list, and with <literal>=</literal> or
+              <literal>:=</literal>, it replaces any previous contents of the list. Please note that both
+              <literal>program</literal> and <literal>builtin</literal> types described below share a common
+              list, so clearing the list with <literal>:=</literal> and <literal>=</literal> affects both
+              types.</para>
+
+              <para><replaceable>type</replaceable> may be:</para>
+              <variablelist>
+                <varlistentry>
+                  <term><literal>program</literal></term>
+                  <listitem>
+                    <para>Execute an external program specified as the assigned
+                    value. If no absolute path is given, the program is expected
+                    to live in <filename>/usr/lib/udev</filename>; otherwise, the
+                    absolute path must be specified.</para>
+                    <para>This is the default if no <replaceable>type</replaceable>
+                    is specified.</para>
+                  </listitem>
+                </varlistentry>
+                <varlistentry>
+                  <term><literal>builtin</literal></term>
+                  <listitem>
+                    <para>As <varname>program</varname>, but use one of the
+                    built-in programs rather than an external one.</para>
+
+                  <xi:include href="version-info.xml" xpointer="v199"/>
+                  </listitem>
+                </varlistentry>
+              </variablelist>
+
+              <para>The program name and following arguments are separated by spaces. Single quotes can be
+              used to specify arguments with spaces.</para>
+
+              <para>This can only be used for very short-running foreground tasks. Running an event process for
+              a long period of time may block all further events for this or a dependent device.</para>
+
+              <para>Note that running programs that access the network or mount/unmount filesystems is not
+              allowed inside of udev rules, due to the default sandbox that is enforced on
+              <filename>systemd-udevd.service</filename>.</para>
+
+              <para>Starting daemons or other long-running processes is not allowed; the forked processes,
+              detached or not, will be unconditionally killed after the event handling has finished. In order
+              to activate long-running processes from udev rules, provide a service unit and pull it in from a
+              udev device using the <varname>SYSTEMD_WANTS</varname> device property. See
+              <citerefentry><refentrytitle>systemd.device</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+              for details.</para>
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><varname>LABEL</varname></term>
+            <listitem>
+              <para>A named label to which a <varname>GOTO</varname> may jump.</para>
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><varname>GOTO</varname></term>
+            <listitem>
+              <para>Jumps to the next <varname>LABEL</varname> with a matching name.</para>
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><varname>IMPORT{<replaceable>type</replaceable>}</varname></term>
+            <listitem>
+              <para>Import a set of variables as device properties, depending on
+              <replaceable>type</replaceable>:</para>
+
+              <variablelist>
+                <varlistentry>
+                  <term><literal>program</literal></term>
+                  <listitem>
+                    <para>Execute an external program specified as the assigned
+                    value and, if it returns successfully,
+                    import its output, which must be in environment key
+                    format. Path specification, command/argument separation,
+                    and quoting work like in <varname>RUN</varname>.</para>
+
+                    <xi:include href="version-info.xml" xpointer="v199"/>
+                  </listitem>
+                </varlistentry>
+                <varlistentry>
+                  <term><literal>builtin</literal></term>
+                  <listitem>
+                    <para>Similar to <literal>program</literal>, but use one of the
+                    built-in programs rather than an external one.</para>
+
+                  <xi:include href="version-info.xml" xpointer="v199"/>
+                  </listitem>
+                </varlistentry>
+              <varlistentry>
+                  <term><literal>file</literal></term>
+                  <listitem>
+                    <para>Import a text file specified as the assigned value, the content
+                    of which must be in environment key format.</para>
+                  </listitem>
+                </varlistentry>
+                <varlistentry>
+                  <term><literal>db</literal></term>
+                  <listitem>
+                    <para>Import a single property specified as the assigned value from the
+                    current device database. This works only if the database is already populated
+                    by an earlier event.</para>
+                  </listitem>
+                </varlistentry>
+                <varlistentry>
+                  <term><literal>cmdline</literal></term>
+                  <listitem>
+                    <para>Import a single property from the kernel command line. For simple flags
+                    the value of the property is set to <literal>1</literal>.</para>
+                  </listitem>
+                </varlistentry>
+                <varlistentry>
+                  <term><literal>parent</literal></term>
+                  <listitem>
+                    <para>Import the stored keys from the parent device by reading
+                    the database entry of the parent device. The value assigned to
+                    <option>IMPORT{parent}</option> is used as a filter of key names
+                    to import (with the same shell glob pattern matching used for
+                    comparisons).</para>
+                  </listitem>
+                </varlistentry>
+              </variablelist>
+
+              <para>This can only be used for very short-running foreground tasks. For details see
+              <option>RUN</option>.</para>
+
+              <para>Note that multiple <varname>IMPORT{}</varname> keys may be specified in one rule, and
+              <literal>=</literal>, <literal>:=</literal>, and <literal>+=</literal> have the same effect as
+              <literal>==</literal>. The key is true if the import is successful, unless <literal>!=</literal>
+              is used as the operator which causes the key to be true if the import failed.</para>
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><varname>OPTIONS</varname></term>
+            <listitem>
+              <para>Rule and device options:</para>
+              <variablelist class='udev-directives'>
+                <varlistentry>
+                  <term><option>link_priority=<replaceable>value</replaceable></option></term>
+                  <listitem>
+                    <para>Specify the priority of the created symlinks. Devices with higher
+                    priorities overwrite existing symlinks of other devices. The default is 0.</para>
+                  </listitem>
+                </varlistentry>
+                <varlistentry>
+                  <term><option>string_escape=<replaceable>none|replace</replaceable></option></term>
+                  <listitem>
+                    <para>When <literal>replace</literal>, possibly unsafe characters in strings
+                    assigned to <varname>NAME</varname>, <varname>SYMLINK</varname>, and
+                    <varname>ENV{<replaceable>key</replaceable>}</varname> are replaced. When
+                    <literal>none</literal>, no replacement is performed. When unset, the replacement
+                    is performed for <varname>NAME</varname>, <varname>SYMLINK</varname>, but not for
+                    <varname>ENV{<replaceable>key</replaceable>}</varname>. Defaults to unset.</para>
+                  </listitem>
+                </varlistentry>
+                <varlistentry>
+                  <term><option>static_node=</option></term>
+                  <listitem>
+                    <para>Apply the permissions specified in this rule to the
+                    static device node with the specified name. Also, for every
+                    tag specified in this rule, create a symlink
+                    in the directory
+                    <filename>/run/udev/static_node-tags/<replaceable>tag</replaceable></filename>
+                    pointing at the static device node with the specified name.
+                    Static device node creation is performed by systemd-tmpfiles
+                    before systemd-udevd is started. The static nodes might not
+                    have a corresponding kernel device; they are used to trigger
+                    automatic kernel module loading when they are accessed.</para>
+                  </listitem>
+                </varlistentry>
+                <varlistentry>
+                  <term><option>watch</option></term>
+                  <listitem>
+                    <para>Watch the device node with inotify; when the node is
+                    closed after being opened for writing, a change uevent is
+                    synthesized.</para>
+                  </listitem>
+                </varlistentry>
+                <varlistentry>
+                  <term><option>nowatch</option></term>
+                  <listitem>
+                    <para>Disable the watching of a device node with inotify.</para>
+                  </listitem>
+                </varlistentry>
+                <varlistentry>
+                  <term><option>db_persist</option></term>
+                  <listitem>
+                    <para>Set the flag (sticky bit) on the udev database entry of the event device. Device
+                    properties are then kept in the database even when <command>udevadm info
+                    --cleanup-db</command> is called.  This option can be useful in certain cases
+                    (e.g. Device Mapper devices) for persisting device state on the transition from
+                    initrd.</para>
+
+                    <xi:include href="version-info.xml" xpointer="v241"/>
+                  </listitem>
+                </varlistentry>
+                <varlistentry>
+                  <term><option>log_level=<replaceable>level</replaceable></option></term>
+                  <listitem>
+                    <para>Takes a log level name like <literal>debug</literal> or
+                    <literal>info</literal>, or a special value <literal>reset</literal>. When a log
+                    level name is specified, the maximum log level is changed to that level. When
+                    <literal>reset</literal> is set, then the previously specified log level is
+                    revoked. Defaults to the log level of the main process of
+                    <command>systemd-udevd</command>.</para>
+                    <para>This may be useful when debugging events for certain devices. Note that the
+                    log level is applied when the line including this rule is processed. So, for
+                    debugging, it is recommended that this is specified at earlier place, e.g., the
+                    first line of <filename>00-debug.rules</filename>.</para>
+                    <para>Example for debugging uevent processing for network interfaces:
+                    <programlisting># /etc/udev/rules.d/00-debug-net.rules
+SUBSYSTEM=="net", OPTIONS="log_level=debug"</programlisting></para>
+
+                    <xi:include href="version-info.xml" xpointer="v248"/>
+                  </listitem>
+                </varlistentry>
+              </variablelist>
+            </listitem>
+          </varlistentry>
+        </variablelist>
+
+        <para>The <varname>ENV</varname>, <varname>GROUP</varname>,
+        <varname>MODE</varname>, <varname>NAME</varname>,
+        <varname>OWNER</varname>, <varname>PROGRAM</varname>,
+        <varname>RUN</varname>, <varname>SECLABEL</varname>, and
+        <varname>SYMLINK</varname> fields support simple string substitutions.
+        The <varname>RUN</varname> substitutions are performed after all rules
+        have been processed, right before the program is executed, allowing for
+        the use of device properties set by earlier matching rules. For all
+        other fields, substitutions are performed while the individual rule is
+        being processed. The available substitutions are:</para>
+        <variablelist class='udev-directives'>
+          <varlistentry>
+            <term><option>$kernel</option>, <option>%k</option></term>
+            <listitem>
+              <para>The kernel name for this device.</para>
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><option>$number</option>, <option>%n</option></term>
+            <listitem>
+              <para>The kernel number for this device. For example, <literal>sda3</literal> has kernel number
+              3.</para>
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><option>$devpath</option>, <option>%p</option></term>
+            <listitem>
+              <para>The devpath of the device.</para>
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><option>$id</option>, <option>%b</option></term>
+            <listitem>
+              <para>The name of the device matched while searching the devpath
+                upwards for <option>SUBSYSTEMS</option>, <option>KERNELS</option>,
+                <option>DRIVERS</option>, and <option>ATTRS</option>.
+              </para>
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><option>$driver</option></term>
+            <listitem>
+              <para>The driver name of the device matched while searching the
+                devpath upwards for <option>SUBSYSTEMS</option>,
+                <option>KERNELS</option>, <option>DRIVERS</option>, and
+                <option>ATTRS</option>.
+              </para>
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><option>$attr{<replaceable>file</replaceable>}</option>, <option>%s{<replaceable>file</replaceable>}</option></term>
+            <listitem>
+              <para>The value of a sysfs attribute found at the device where
+                all keys of the rule have matched. If the matching device does not
+                have such an attribute, and a previous <option>KERNELS</option>,
+                <option>SUBSYSTEMS</option>, <option>DRIVERS</option>, or
+                <option>ATTRS</option> test selected a parent device, then the
+                attribute from that parent device is used.
+              </para>
+              <para>If the attribute is a symlink, the last element of the
+                symlink target is returned as the value.
+              </para>
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><option>$env{<replaceable>key</replaceable>}</option>, <option>%E{<replaceable>key</replaceable>}</option></term>
+            <listitem>
+              <para>A device property value.</para>
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><option>$major</option>, <option>%M</option></term>
+            <listitem>
+              <para>The kernel major number for the device.</para>
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><option>$minor</option>, <option>%m</option></term>
+            <listitem>
+              <para>The kernel minor number for the device.</para>
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><option>$result</option>, <option>%c</option></term>
+            <listitem>
+              <para>The string returned by the external program requested with
+              <varname>PROGRAM</varname>.
+              A single part of the string, separated by a space character, may be selected
+              by specifying the part number as an attribute: <literal>%c{N}</literal>.
+              If the number is followed by the <literal>+</literal> character, this part plus all remaining parts
+              of the result string are substituted: <literal>%c{N+}</literal>.</para>
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><option>$parent</option>, <option>%P</option></term>
+            <listitem>
+              <para>The node name of the parent device.</para>
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><option>$name</option></term>
+            <listitem>
+              <para>The current name of the device. If not changed by a rule, it is the
+              name of the kernel device.</para>
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><option>$links</option></term>
+            <listitem>
+              <para>A space-separated list of the current symlinks. The value is
+              only set during a remove event or if an earlier rule assigned a value.</para>
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><option>$root</option>, <option>%r</option></term>
+            <listitem>
+              <para>The udev_root value.</para>
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><option>$sys</option>, <option>%S</option></term>
+            <listitem>
+              <para>The sysfs mount point.</para>
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><option>$devnode</option>, <option>%N</option></term>
+            <listitem>
+              <para>The name of the device node.</para>
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><option>%%</option></term>
+            <listitem>
+            <para>The <literal>%</literal> character itself.</para>
+            </listitem>
+          </varlistentry>
+
+          <varlistentry>
+            <term><option>$$</option></term>
+            <listitem>
+            <para>The <literal>$</literal> character itself.</para>
+            </listitem>
+          </varlistentry>
+        </variablelist>
+      </refsect2>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry>
+        <refentrytitle>systemd-udevd.service</refentrytitle><manvolnum>8</manvolnum>
+      </citerefentry>,
+      <citerefentry>
+        <refentrytitle>udevadm</refentrytitle><manvolnum>8</manvolnum>
+      </citerefentry>,
+      <citerefentry>
+        <refentrytitle>systemd.link</refentrytitle><manvolnum>5</manvolnum>
+      </citerefentry>
+    </para>
+  </refsect1>
+</refentry>
diff --git a/man/udev_device_get_syspath.xml b/man/udev_device_get_syspath.xml
new file mode 100644
index 0000000..f6d89c3
--- /dev/null
+++ b/man/udev_device_get_syspath.xml
@@ -0,0 +1,198 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [
+<!ENTITY % entities SYSTEM "custom-entities.ent" >
+%entities;
+]>
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="udev_device_get_syspath"
+  xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>udev_device_get_syspath</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>udev_device_get_syspath</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>udev_device_get_syspath</refname>
+    <refname>udev_device_get_sysname</refname>
+    <refname>udev_device_get_sysnum</refname>
+    <refname>udev_device_get_devpath</refname>
+    <refname>udev_device_get_devnode</refname>
+    <refname>udev_device_get_devnum</refname>
+    <refname>udev_device_get_devtype</refname>
+    <refname>udev_device_get_subsystem</refname>
+    <refname>udev_device_get_driver</refname>
+    <refname>udev_device_get_udev</refname>
+    <refname>udev_device_get_parent</refname>
+    <refname>udev_device_get_parent_with_subsystem_devtype</refname>
+    <refname>udev_device_get_is_initialized</refname>
+    <refname>udev_device_get_action</refname>
+
+    <refpurpose>Query device properties</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;libudev.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>const char *<function>udev_device_get_syspath</function></funcdef>
+        <paramdef>struct udev_device *<parameter>udev_device</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>const char *<function>udev_device_get_sysname</function></funcdef>
+        <paramdef>struct udev_device *<parameter>udev_device</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>const char *<function>udev_device_get_sysnum</function></funcdef>
+        <paramdef>struct udev_device *<parameter>udev_device</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>const char *<function>udev_device_get_devpath</function></funcdef>
+        <paramdef>struct udev_device *<parameter>udev_device</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>const char *<function>udev_device_get_devnode</function></funcdef>
+        <paramdef>struct udev_device *<parameter>udev_device</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>dev_t <function>udev_device_get_devnum</function></funcdef>
+        <paramdef>struct udev_device *<parameter>udev_device</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>const char *<function>udev_device_get_devtype</function></funcdef>
+        <paramdef>struct udev_device *<parameter>udev_device</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>const char *<function>udev_device_get_subsystem</function></funcdef>
+        <paramdef>struct udev_device *<parameter>udev_device</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>const char *<function>udev_device_get_driver</function></funcdef>
+        <paramdef>struct udev_device *<parameter>udev_device</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>struct udev *<function>udev_device_get_udev</function></funcdef>
+        <paramdef>struct udev_device *<parameter>udev_device</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>struct udev_device *<function>udev_device_get_parent</function></funcdef>
+        <paramdef>struct udev_device *<parameter>udev_device</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>struct udev_device *<function>udev_device_get_parent_with_subsystem_devtype</function></funcdef>
+        <paramdef>struct udev_device *<parameter>udev_device</parameter></paramdef>
+        <paramdef>const char *<parameter>subsystem</parameter></paramdef>
+        <paramdef>const char *<parameter>devtype</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>udev_device_get_is_initialized</function></funcdef>
+        <paramdef>struct udev_device *<parameter>udev_device</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>const char *<function>udev_device_get_action</function></funcdef>
+        <paramdef>struct udev_device *<parameter>udev_device</parameter></paramdef>
+      </funcprototype>
+
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <!--<refsect1>
+    <title>Description</title>
+
+    <para>XXX: Add documentation.</para>
+  </refsect1>-->
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, <function>udev_device_get_syspath()</function>,
+    <function>udev_device_get_sysname()</function>,
+    <function>udev_device_get_sysnum()</function>,
+    <function>udev_device_get_devpath()</function>,
+    <function>udev_device_get_devnode()</function>,
+    <function>udev_device_get_devtype()</function>,
+    <function>udev_device_get_subsystem()</function>,
+    <function>udev_device_get_driver()</function> and
+    <function>udev_device_get_action()</function> return a pointer
+    to a constant string that describes the requested property. The
+    lifetime of this string is bound to the device it was requested
+    on. On failure, each function may return
+    <constant>NULL</constant>.</para>
+
+    <para>On success, <function>udev_device_get_devnum()</function>
+    returns the device type of the passed device. On failure, a
+    device type with minor and major number set to
+    <constant>0</constant> is returned.</para>
+
+    <para><function>udev_device_get_udev()</function> always returns
+    a valid pointer to the udev context that this device belongs
+    to.</para>
+
+    <para>On success, <function>udev_device_get_parent()</function>
+    and
+    <function>udev_device_get_parent_with_subsystem_devtype()</function>
+    return a pointer to the parent device. No additional reference
+    to this device is acquired, but the child device owns a reference
+    to such a parent device. On failure, <constant>NULL</constant>
+    is returned.</para>
+
+    <para>On success, <function>udev_device_get_is_initialized()</function> returns either <constant>1</constant> or
+    <constant>0</constant>, depending on whether the passed device has already been initialized by udev or not. On
+    failure, a negative error code is returned. Note that devices for which no udev rules are defined are never
+    reported initialized.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>History</title>
+    <para><function>udev_device_get_syspath()</function>,
+    <function>udev_device_get_sysname()</function>,
+    <function>udev_device_get_sysnum()</function>,
+    <function>udev_device_get_devpath()</function>,
+    <function>udev_device_get_devnode()</function>,
+    <function>udev_device_get_devnum()</function>,
+    <function>udev_device_get_devtype()</function>,
+    <function>udev_device_get_subsystem()</function>,
+    <function>udev_device_get_driver()</function>,
+    <function>udev_device_get_udev()</function>,
+    <function>udev_device_get_parent()</function>,
+    <function>udev_device_get_parent_with_subsystem_devtype()</function>,
+    <function>udev_device_get_is_initialized()</function>, and
+    <function>udev_device_get_action()</function> were added in version 221.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>udev_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>udev_device_new_from_syspath</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>udev_device_has_tag</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>udev_enumerate_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>udev_monitor_new_from_netlink</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>udev_list_entry</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/udev_device_has_tag.xml b/man/udev_device_has_tag.xml
new file mode 100644
index 0000000..f66c3ed
--- /dev/null
+++ b/man/udev_device_has_tag.xml
@@ -0,0 +1,184 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [
+<!ENTITY % entities SYSTEM "custom-entities.ent" >
+%entities;
+]>
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="udev_device_has_tag"
+  xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>udev_device_has_tag</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>udev_device_has_tag</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>udev_device_has_tag</refname>
+    <refname>udev_device_has_current_tag</refname>
+    <refname>udev_device_get_devlinks_list_entry</refname>
+    <refname>udev_device_get_properties_list_entry</refname>
+    <refname>udev_device_get_tags_list_entry</refname>
+    <refname>udev_device_get_current_tags_list_entry</refname>
+    <refname>udev_device_get_sysattr_list_entry</refname>
+    <refname>udev_device_get_property_value</refname>
+    <refname>udev_device_get_sysattr_value</refname>
+    <refname>udev_device_set_sysattr_value</refname>
+
+    <refpurpose>Retrieve or set device attributes</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;libudev.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>udev_device_has_tag</function></funcdef>
+        <paramdef>struct udev_device *<parameter>udev_device</parameter></paramdef>
+        <paramdef>const char *<parameter>tag</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>udev_device_has_current_tag</function></funcdef>
+        <paramdef>struct udev_device *<parameter>udev_device</parameter></paramdef>
+        <paramdef>const char *<parameter>tag</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>struct udev_list_entry *<function>udev_device_get_devlinks_list_entry</function></funcdef>
+        <paramdef>struct udev_device *<parameter>udev_device</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>struct udev_list_entry *<function>udev_device_get_properties_list_entry</function></funcdef>
+        <paramdef>struct udev_device *<parameter>udev_device</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>struct udev_list_entry *<function>udev_device_get_tags_list_entry</function></funcdef>
+        <paramdef>struct udev_device *<parameter>udev_device</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>struct udev_list_entry *<function>udev_device_get_current_tags_list_entry</function></funcdef>
+        <paramdef>struct udev_device *<parameter>udev_device</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>struct udev_list_entry *<function>udev_device_get_sysattr_list_entry</function></funcdef>
+        <paramdef>struct udev_device *<parameter>udev_device</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>const char *<function>udev_device_get_property_value</function></funcdef>
+        <paramdef>struct udev_device *<parameter>udev_device</parameter></paramdef>
+        <paramdef>const char *<parameter>key</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>const char *<function>udev_device_get_sysattr_value</function></funcdef>
+        <paramdef>struct udev_device *<parameter>udev_device</parameter></paramdef>
+        <paramdef>const char *<parameter>sysattr</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>udev_device_set_sysattr_value</function></funcdef>
+        <paramdef>struct udev_device *<parameter>udev_device</parameter></paramdef>
+        <paramdef>const char *<parameter>sysattr</parameter></paramdef>
+        <paramdef>const char *<parameter>value</parameter></paramdef>
+      </funcprototype>
+
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>udev_device_has_tag()</function> returns a valuer larger than zero if the specified
+    device object has the indicated tag assigned to it, and zero otherwise. See
+    <citerefentry><refentrytitle>udev</refentrytitle><manvolnum>7</manvolnum></citerefentry> for details on
+    the tags concept. <function>udev_device_has_current_tag()</function> executes a similar check, however
+    only determines whether the indicated tag was set as result of the most recent event seen for the
+    device. Tags are "sticky", i.e. once set for a device they remain on the device until the device is
+    unplugged, even if the rules run for later events of the same device do not set them anymore. Any tag for
+    which <function>udev_device_has_current_tag()</function> returns true will hence also return true when
+    passed to <function>udev_device_has_tag()</function>, but the opposite might not be true, in case a tag is
+    no longer configured by the rules applied to the most recent device even.</para>
+
+    <para><function>udev_device_get_tags_list_entry()</function> returns a
+    <structname>udev_list_entry</structname> object, encapsulating a list of tags set for the specified
+    device. Similar, <function>udev_device_get_current_tags_list_entry()</function> returns a list of tags
+    set for the specified device as effect of the most recent device event seen (see above for details on the
+    difference).</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, <function>udev_device_has_tag()</function> and
+    <function>udev_device_has_current_tag()</function> return positive or <constant>0</constant>, depending
+    on whether the device has the given tag or not.  On failure, a negative error code is returned.</para>
+
+    <para>On success, <function>udev_device_get_devlinks_list_entry()</function>,
+    <function>udev_device_get_properties_list_entry()</function>,
+    <function>udev_device_get_tags_list_entry()</function>,
+    <function>udev_device_get_current_tags_list_entry()</function> and
+    <function>udev_device_get_sysattr_list_entry()</function> return a pointer to the first entry of the
+    retrieved list. If that list is empty, or if an error occurred, <constant>NULL</constant> is
+    returned.</para>
+
+    <para>On success,
+    <function>udev_device_get_property_value()</function> and
+    <function>udev_device_get_sysattr_value()</function> return a
+    pointer to a constant string of the requested value. On error,
+    <constant>NULL</constant> is returned. Attributes that may
+    contain <constant>NUL</constant> bytes should not be retrieved
+    with <function>udev_device_get_sysattr_value()</function>;
+    instead, read them directly from the files within the device's
+    <property>syspath</property>.</para>
+
+    <para>On success,
+    <function>udev_device_set_sysattr_value()</function> returns
+    an integer greater than, or equal to, <constant>0</constant>.
+    On failure, a negative error code is returned. Values that
+    contain <constant>NUL</constant> bytes should not be set with
+    this function; instead, write them directly to the files within
+    the device's <property>syspath</property>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>History</title>
+    <para><function>udev_device_get_devlinks_list_entry()</function>,
+    <function>udev_device_get_properties_list_entry()</function>,
+    <function>udev_device_get_tags_list_entry()</function>,
+    <function>udev_device_get_sysattr_list_entry()</function>,
+    <function>udev_device_get_property_value()</function>,
+    <function>udev_device_has_tag()</function>,
+    <function>udev_device_get_sysattr_value()</function>, and
+    <function>udev_device_set_sysattr_value()</function> were added in version 221.</para>
+    <para><function>udev_device_has_current_tag()</function> and
+    <function>udev_device_get_current_tags_list_entry()</function> were added in version 247.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>udev</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>udev_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>udev_device_new_from_syspath</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>udev_device_get_syspath</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>udev_enumerate_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>udev_monitor_new_from_netlink</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>udev_list_entry</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/udev_device_new_from_syspath.xml b/man/udev_device_new_from_syspath.xml
new file mode 100644
index 0000000..a9bd51c
--- /dev/null
+++ b/man/udev_device_new_from_syspath.xml
@@ -0,0 +1,198 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [
+<!ENTITY % entities SYSTEM "custom-entities.ent" >
+%entities;
+]>
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="udev_device_new_from_syspath"
+  xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>udev_device_new_from_syspath</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>udev_device_new_from_syspath</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>udev_device_new_from_syspath</refname>
+    <refname>udev_device_new_from_devnum</refname>
+    <refname>udev_device_new_from_subsystem_sysname</refname>
+    <refname>udev_device_new_from_device_id</refname>
+    <refname>udev_device_new_from_environment</refname>
+    <refname>udev_device_ref</refname>
+    <refname>udev_device_unref</refname>
+
+    <refpurpose>Create, acquire and release a udev device object</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;libudev.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>struct udev_device *<function>udev_device_new_from_syspath</function></funcdef>
+        <paramdef>struct udev *<parameter>udev</parameter></paramdef>
+        <paramdef>const char *<parameter>syspath</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>struct udev_device *<function>udev_device_new_from_devnum</function></funcdef>
+        <paramdef>struct udev *<parameter>udev</parameter></paramdef>
+        <paramdef>char <parameter>type</parameter></paramdef>
+        <paramdef>dev_t <parameter>devnum</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>struct udev_device *<function>udev_device_new_from_subsystem_sysname</function></funcdef>
+        <paramdef>struct udev *<parameter>udev</parameter></paramdef>
+        <paramdef>const char *<parameter>subsystem</parameter></paramdef>
+        <paramdef>const char *<parameter>sysname</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>struct udev_device *<function>udev_device_new_from_device_id</function></funcdef>
+        <paramdef>struct udev *<parameter>udev</parameter></paramdef>
+        <paramdef>const char *<parameter>id</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>struct udev_device *<function>udev_device_new_from_environment</function></funcdef>
+        <paramdef>struct udev *<parameter>udev</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>struct udev_device *<function>udev_device_ref</function></funcdef>
+        <paramdef>struct udev_device *<parameter>udev_device</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>struct udev_device *<function>udev_device_unref</function></funcdef>
+        <paramdef>struct udev_device *<parameter>udev_device</parameter></paramdef>
+      </funcprototype>
+
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>udev_device_new_from_syspath()</function>,
+    <function>udev_device_new_from_devnum()</function>,
+    <function>udev_device_new_from_subsystem_sysname()</function>,
+    <function>udev_device_new_from_device_id()</function>, and
+    <function>udev_device_new_from_environment()</function>
+    allocate a new udev device object and returns a pointer to it. This
+    object is opaque and must not be accessed by the caller via different
+    means than functions provided by libudev. Initially, the reference count
+    of the device is 1. You can acquire further references, and drop
+    gained references via <function>udev_device_ref()</function> and
+    <function>udev_device_unref()</function>. Once the reference count hits 0,
+    the device object is destroyed and freed.</para>
+
+    <para><function>udev_device_new_from_syspath()</function>,
+    <function>udev_device_new_from_devnum()</function>,
+    <function>udev_device_new_from_subsystem_sysname()</function>, and
+    <function>udev_device_new_from_device_id()</function>
+    create the device object based on information found in
+    <filename>/sys/</filename>, annotated with properties from the udev-internal
+    device database. A syspath is any subdirectory of <filename>/sys/</filename>,
+    with the restriction that a subdirectory of <filename>/sys/devices</filename>
+    (or a symlink to one) represents a real device and as such must contain
+    a <filename>uevent</filename> file. <function>udev_device_new_from_devnum()</function>
+    takes a device type, which can be <constant>b</constant> for block devices or
+    <constant>c</constant> for character devices, as well as a devnum (see
+    <citerefentry project='man-pages'><refentrytitle>makedev</refentrytitle><manvolnum>3</manvolnum></citerefentry>).
+    <function>udev_device_new_from_subsystem_sysname()</function> looks up devices based
+    on the provided subsystem and sysname
+    (see <citerefentry><refentrytitle>udev_device_get_subsystem</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+    and
+    <citerefentry><refentrytitle>udev_device_get_sysname</refentrytitle><manvolnum>3</manvolnum></citerefentry>)
+    and <function>udev_device_new_from_device_id()</function> looks up devices based on the provided
+    device ID, which is a special string in one of the following four forms:
+    <table>
+      <title>Device ID strings</title>
+
+      <tgroup cols='2'>
+        <colspec colname='example' />
+        <colspec colname='explanation' />
+        <thead><row>
+          <entry>Example</entry>
+          <entry>Explanation</entry>
+        </row></thead>
+        <tbody>
+          <row><entry><varname>b8:2</varname></entry>
+          <entry>block device major:minor</entry></row>
+
+          <row><entry><varname>c128:1</varname></entry>
+          <entry>char device major:minor</entry></row>
+
+          <row><entry><varname>n3</varname></entry>
+          <entry>network device ifindex</entry></row>
+
+          <row><entry><varname>+sound:card29</varname></entry>
+          <entry>kernel driver core subsystem:device name</entry></row>
+        </tbody>
+      </tgroup>
+    </table>
+    </para>
+
+    <para><function>udev_device_new_from_environment()</function>
+    creates a device from the current environment (see
+    <citerefentry project='man-pages'><refentrytitle>environ</refentrytitle><manvolnum>7</manvolnum></citerefentry>).
+    Each key-value pair is interpreted in the same way as if it was
+    received in an uevent (see
+    <citerefentry><refentrytitle>udev_monitor_receive_device</refentrytitle><manvolnum>3</manvolnum></citerefentry>).
+    The keys <constant>DEVPATH</constant>, <constant>SUBSYSTEM</constant>,
+    <constant>ACTION</constant>, and <constant>SEQNUM</constant> are mandatory.</para>
+
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, <function>udev_device_new_from_syspath()</function>,
+    <function>udev_device_new_from_devnum()</function>,
+    <function>udev_device_new_from_subsystem_sysname()</function>,
+    <function>udev_device_new_from_device_id()</function> and
+    <function>udev_device_new_from_environment()</function> return a
+    pointer to the allocated udev device. On failure,
+    <constant>NULL</constant> is returned,
+    and <varname>errno</varname> is set appropriately.
+    <function>udev_device_ref()</function> returns the argument
+    that it was passed, unmodified.
+    <function>udev_device_unref()</function> always returns
+    <constant>NULL</constant>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>History</title>
+    <para><function>udev_device_new_from_syspath()</function>,
+    <function>udev_device_new_from_devnum()</function>,
+    <function>udev_device_new_from_subsystem_sysname()</function>,
+    <function>udev_device_new_from_device_id()</function>,
+    <function>udev_device_new_from_environment()</function>,
+    <function>udev_device_ref()</function>, and
+    <function>udev_device_unref()</function> were added in version 221.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>udev_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>udev_device_get_syspath</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>udev_device_has_tag</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>udev_enumerate_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>udev_monitor_new_from_netlink</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>udev_list_entry</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/udev_enumerate_add_match_subsystem.xml b/man/udev_enumerate_add_match_subsystem.xml
new file mode 100644
index 0000000..079138b
--- /dev/null
+++ b/man/udev_enumerate_add_match_subsystem.xml
@@ -0,0 +1,149 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [
+<!ENTITY % entities SYSTEM "custom-entities.ent" >
+%entities;
+]>
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="udev_enumerate_add_match_subsystem"
+  xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>udev_enumerate_add_match_subsystem</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>udev_enumerate_add_match_subsystem</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>udev_enumerate_add_match_subsystem</refname>
+    <refname>udev_enumerate_add_nomatch_subsystem</refname>
+    <refname>udev_enumerate_add_match_sysattr</refname>
+    <refname>udev_enumerate_add_nomatch_sysattr</refname>
+    <refname>udev_enumerate_add_match_property</refname>
+    <refname>udev_enumerate_add_match_sysname</refname>
+    <refname>udev_enumerate_add_match_tag</refname>
+    <refname>udev_enumerate_add_match_parent</refname>
+    <refname>udev_enumerate_add_match_is_initialized</refname>
+
+    <refpurpose>Modify filters</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;libudev.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>udev_enumerate_add_match_subsystem</function></funcdef>
+        <paramdef>struct udev_enumerate *<parameter>udev_enumerate</parameter></paramdef>
+        <paramdef>const char *<parameter>subsystem</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>udev_enumerate_add_nomatch_subsystem</function></funcdef>
+        <paramdef>struct udev_enumerate *<parameter>udev_enumerate</parameter></paramdef>
+        <paramdef>const char *<parameter>subsystem</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>udev_enumerate_add_match_sysattr</function></funcdef>
+        <paramdef>struct udev_enumerate *<parameter>udev_enumerate</parameter></paramdef>
+        <paramdef>const char *<parameter>sysattr</parameter></paramdef>
+        <paramdef>const char *<parameter>value</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>udev_enumerate_add_nomatch_sysattr</function></funcdef>
+        <paramdef>struct udev_enumerate *<parameter>udev_enumerate</parameter></paramdef>
+        <paramdef>const char *<parameter>sysattr</parameter></paramdef>
+        <paramdef>const char *<parameter>value</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>udev_enumerate_add_match_property</function></funcdef>
+        <paramdef>struct udev_enumerate *<parameter>udev_enumerate</parameter></paramdef>
+        <paramdef>const char *<parameter>property</parameter></paramdef>
+        <paramdef>const char *<parameter>value</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>udev_enumerate_add_match_sysname</function></funcdef>
+        <paramdef>struct udev_enumerate *<parameter>udev_enumerate</parameter></paramdef>
+        <paramdef>const char *<parameter>sysname</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>udev_enumerate_add_match_tag</function></funcdef>
+        <paramdef>struct udev_enumerate *<parameter>udev_enumerate</parameter></paramdef>
+        <paramdef>const char *<parameter>tag</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>udev_enumerate_add_match_parent</function></funcdef>
+        <paramdef>struct udev_enumerate *<parameter>udev_enumerate</parameter></paramdef>
+        <paramdef>struct udev_device *<parameter>parent</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>udev_enumerate_add_match_is_initialized</function></funcdef>
+        <paramdef>struct udev_enumerate *<parameter>udev_enumerate</parameter></paramdef>
+      </funcprototype>
+
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <!--<refsect1>
+    <title>Description</title>
+
+    <para>XXX: Add short description.</para>
+  </refsect1>-->
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success,
+    <function>udev_enumerate_add_match_subsystem()</function>,
+    <function>udev_enumerate_add_nomatch_subsystem()</function>,
+    <function>udev_enumerate_add_match_sysattr()</function>,
+    <function>udev_enumerate_add_nomatch_sysattr()</function>,
+    <function>udev_enumerate_add_match_property()</function>,
+    <function>udev_enumerate_add_match_sysname()</function>,
+    <function>udev_enumerate_add_match_tag()</function>,
+    <function>udev_enumerate_add_match_parent()</function> and
+    <function>udev_enumerate_add_match_is_initialized()</function>
+    return an integer greater than, or equal to,
+    <constant>0</constant>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>History</title>
+    <para><function>udev_enumerate_add_match_subsystem()</function>,
+    <function>udev_enumerate_add_nomatch_subsystem()</function>,
+    <function>udev_enumerate_add_match_sysattr()</function>,
+    <function>udev_enumerate_add_nomatch_sysattr()</function>,
+    <function>udev_enumerate_add_match_property()</function>,
+    <function>udev_enumerate_add_match_sysname()</function>,
+    <function>udev_enumerate_add_match_tag()</function>,
+    <function>udev_enumerate_add_match_parent()</function>, and
+    <function>udev_enumerate_add_match_is_initialized()</function> were added in version 221.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>udev_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>udev_device_new_from_syspath</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>udev_enumerate_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>udev_enumerate_scan_devices</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>udev_monitor_new_from_netlink</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>udev_list_entry</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/udev_enumerate_new.xml b/man/udev_enumerate_new.xml
new file mode 100644
index 0000000..0429cd0
--- /dev/null
+++ b/man/udev_enumerate_new.xml
@@ -0,0 +1,91 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [
+<!ENTITY % entities SYSTEM "custom-entities.ent" >
+%entities;
+]>
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="udev_enumerate_new"
+  xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>udev_enumerate_new</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>udev_enumerate_new</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>udev_enumerate_new</refname>
+    <refname>udev_enumerate_ref</refname>
+    <refname>udev_enumerate_unref</refname>
+
+    <refpurpose>Create, acquire and release a udev enumerate object</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;libudev.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>struct udev_enumerate *<function>udev_enumerate_new</function></funcdef>
+        <paramdef>struct udev *<parameter>udev</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>struct udev_enumerate *<function>udev_enumerate_ref</function></funcdef>
+        <paramdef>struct udev_enumerate *<parameter>udev_enumerate</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>struct udev_enumerate *<function>udev_enumerate_unref</function></funcdef>
+        <paramdef>struct udev_enumerate *<parameter>udev_enumerate</parameter></paramdef>
+      </funcprototype>
+
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <!--<refsect1>
+    <title>Description</title>
+
+    <para>XXX: Add short description.</para>
+  </refsect1>-->
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, <function>udev_enumerate_new()</function> returns a
+    pointer to the allocated enumeration object. On failure,
+    <constant>NULL</constant> is returned.
+    <function>udev_enumerate_ref()</function> returns the argument
+    that it was passed, unmodified.
+    <function>udev_enumerate_unref()</function> always returns
+    <constant>NULL</constant>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>History</title>
+    <para><function>udev_enumerate_new()</function>,
+    <function>udev_enumerate_ref()</function>, and
+    <function>udev_enumerate_unref()</function> were added in version 221.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>udev_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>udev_device_new_from_syspath</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>udev_enumerate_add_match_subsystem</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>udev_enumerate_scan_devices</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>udev_monitor_new_from_netlink</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>udev_list_entry</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/udev_enumerate_scan_devices.xml b/man/udev_enumerate_scan_devices.xml
new file mode 100644
index 0000000..8b1b40b
--- /dev/null
+++ b/man/udev_enumerate_scan_devices.xml
@@ -0,0 +1,115 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [
+<!ENTITY % entities SYSTEM "custom-entities.ent" >
+%entities;
+]>
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="udev_enumerate_scan_devices"
+  xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>udev_enumerate_scan_devices</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>udev_enumerate_scan_devices</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>udev_enumerate_scan_devices</refname>
+    <refname>udev_enumerate_scan_subsystems</refname>
+    <refname>udev_enumerate_get_list_entry</refname>
+    <refname>udev_enumerate_add_syspath</refname>
+    <refname>udev_enumerate_get_udev</refname>
+
+    <refpurpose>Query or modify a udev enumerate object</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;libudev.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>udev_enumerate_scan_devices</function></funcdef>
+        <paramdef>struct udev_enumerate *<parameter>udev_enumerate</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>udev_enumerate_scan_subsystems</function></funcdef>
+        <paramdef>struct udev_enumerate *<parameter>udev_enumerate</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>struct udev_list_entry *<function>udev_enumerate_get_list_entry</function></funcdef>
+        <paramdef>struct udev_enumerate *<parameter>udev_enumerate</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>udev_enumerate_add_syspath</function></funcdef>
+        <paramdef>struct udev_enumerate *<parameter>udev_enumerate</parameter></paramdef>
+        <paramdef>const char *<parameter>syspath</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>struct udev *<function>udev_enumerate_get_udev</function></funcdef>
+        <paramdef>struct udev_enumerate *<parameter>udev_enumerate</parameter></paramdef>
+      </funcprototype>
+
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <!--<refsect1>
+    <title>Description</title>
+
+    <para>XXX: Add short description.</para>
+  </refsect1>-->
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success,
+    <function>udev_enumerate_scan_devices()</function>,
+    <function>udev_enumerate_scan_subsystems()</function> and
+    <function>udev_enumerate_add_syspath()</function>
+    return an integer greater than, or equal to,
+    <constant>0</constant>.</para>
+
+    <para>On success,
+    <function>udev_enumerate_get_list_entry()</function>
+    returns a pointer to the first entry in the list of found
+    devices. If the list is empty, or on failure,
+    <constant>NULL</constant> is returned.</para>
+
+    <para><function>udev_enumerate_get_udev()</function> always
+    returns a pointer to the udev context that this enumerated
+    object is associated with.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>History</title>
+    <para><function>udev_enumerate_scan_devices()</function>,
+    <function>udev_enumerate_scan_subsystems()</function>,
+    <function>udev_enumerate_get_list_entry()</function>,
+    <function>udev_enumerate_add_syspath()</function>, and
+    <function>udev_enumerate_get_udev()</function> were added in version 221.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>udev_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>udev_device_new_from_syspath</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>udev_enumerate_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>udev_enumerate_add_match_subsystem</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>udev_monitor_new_from_netlink</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>udev_list_entry</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/udev_list_entry.xml b/man/udev_list_entry.xml
new file mode 100644
index 0000000..de09498
--- /dev/null
+++ b/man/udev_list_entry.xml
@@ -0,0 +1,104 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [
+<!ENTITY % entities SYSTEM "custom-entities.ent" >
+%entities;
+]>
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="udev_list_entry"
+  xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>udev_list_entry</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>udev_list_entry</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>udev_list_entry</refname>
+    <refname>udev_list_entry_get_next</refname>
+    <refname>udev_list_entry_get_by_name</refname>
+    <refname>udev_list_entry_get_name</refname>
+    <refname>udev_list_entry_get_value</refname>
+
+    <refpurpose>Iterate and access udev lists</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;libudev.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>struct udev_list_entry *<function>udev_list_entry_get_next</function></funcdef>
+        <paramdef>struct udev_list_entry *<parameter>list_entry</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>struct udev_list_entry *<function>udev_list_entry_get_by_name</function></funcdef>
+        <paramdef>struct udev_list_entry *<parameter>list_entry</parameter></paramdef>
+        <paramdef>const char *<parameter>name</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>const char *<function>udev_list_entry_get_name</function></funcdef>
+        <paramdef>struct udev_list_entry *<parameter>list_entry</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>const char *<function>udev_list_entry_get_value</function></funcdef>
+        <paramdef>struct udev_list_entry *<parameter>list_entry</parameter></paramdef>
+      </funcprototype>
+
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <!--<refsect1>
+    <title>Description</title>
+
+    <para>XXX: Add short description.</para>
+  </refsect1>-->
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success,
+    <function>udev_list_entry_get_next()</function> and
+    <function>udev_list_entry_get_by_name()</function> return
+    a pointer to the requested list entry. If no such entry can
+    be found, or on failure, <constant>NULL</constant> is
+    returned.</para>
+
+    <para>On success,
+    <function>udev_list_entry_get_name()</function> and
+    <function>udev_list_entry_get_value()</function> return a
+    pointer to a constant string representing the requested value.
+    The string is bound to the lifetime of the list entry itself.
+    On failure, <constant>NULL</constant> is returned.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>History</title>
+    <para><function>udev_list_entry_get_next()</function>,
+    <function>udev_list_entry_get_by_name()</function>,
+    <function>udev_list_entry_get_name()</function>, and
+    <function>udev_list_entry_get_value()</function> were added in version 221.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>udev_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>udev_device_new_from_syspath</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>udev_enumerate_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>udev_monitor_new_from_netlink</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/udev_monitor_filter_update.xml b/man/udev_monitor_filter_update.xml
new file mode 100644
index 0000000..8f01670
--- /dev/null
+++ b/man/udev_monitor_filter_update.xml
@@ -0,0 +1,103 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [
+<!ENTITY % entities SYSTEM "custom-entities.ent" >
+%entities;
+]>
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="udev_monitor_filter_update"
+  xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>udev_monitor_filter_update</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>udev_monitor_filter_update</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>udev_monitor_filter_update</refname>
+    <refname>udev_monitor_filter_remove</refname>
+    <refname>udev_monitor_filter_add_match_subsystem_devtype</refname>
+    <refname>udev_monitor_filter_add_match_tag</refname>
+
+    <refpurpose>Modify filters</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;libudev.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>int <function>udev_monitor_filter_update</function></funcdef>
+        <paramdef>struct udev_monitor *<parameter>udev_monitor</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>udev_monitor_filter_remove</function></funcdef>
+        <paramdef>struct udev_monitor *<parameter>udev_monitor</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>udev_monitor_filter_add_match_subsystem_devtype</function></funcdef>
+        <paramdef>struct udev_monitor *<parameter>udev_monitor</parameter></paramdef>
+        <paramdef>const char *<parameter>subsystem</parameter></paramdef>
+        <paramdef>const char *<parameter>devtype</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>udev_monitor_filter_add_match_tag</function></funcdef>
+        <paramdef>struct udev_monitor *<parameter>udev_monitor</parameter></paramdef>
+        <paramdef>const char *<parameter>tag</parameter></paramdef>
+      </funcprototype>
+
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <!--<refsect1>
+    <title>Description</title>
+
+    <para>XXX: Add short description.</para>
+  </refsect1>-->
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success,
+    <function>udev_monitor_filter_update()</function>,
+    <function>udev_monitor_filter_remove()</function>,
+    <function>udev_monitor_filter_add_match_subsystem_devtype()</function>
+    and
+    <function>udev_monitor_filter_add_match_tag()</function>
+    return an integer greater than, or equal to,
+    <constant>0</constant>. On failure, a negative error code is
+    returned.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>History</title>
+    <para><function>udev_monitor_filter_update()</function>,
+    <function>udev_monitor_filter_remove()</function>,
+    <function>udev_monitor_filter_add_match_subsystem_devtype()</function>, and
+    <function>udev_monitor_filter_add_match_tag()</function> were added in version 221.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>udev_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>udev_device_new_from_syspath</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>udev_enumerate_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>udev_monitor_new_from_netlink</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>udev_monitor_receive_device</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>udev_list_entry</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/udev_monitor_new_from_netlink.xml b/man/udev_monitor_new_from_netlink.xml
new file mode 100644
index 0000000..8084f2c
--- /dev/null
+++ b/man/udev_monitor_new_from_netlink.xml
@@ -0,0 +1,93 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [
+<!ENTITY % entities SYSTEM "custom-entities.ent" >
+%entities;
+]>
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="udev_monitor_new_from_netlink"
+  xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>udev_monitor_new_from_netlink</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>udev_monitor_new_from_netlink</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>udev_monitor_new_from_netlink</refname>
+    <refname>udev_monitor_ref</refname>
+    <refname>udev_monitor_unref</refname>
+
+    <refpurpose>Create, acquire and release a udev monitor object</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;libudev.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>struct udev_monitor *<function>udev_monitor_new_from_netlink</function></funcdef>
+        <paramdef>struct udev *<parameter>udev</parameter></paramdef>
+        <paramdef>const char *<parameter>name</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>struct udev_monitor *<function>udev_monitor_ref</function></funcdef>
+        <paramdef>struct udev_monitor *<parameter>udev_monitor</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>struct udev_monitor *<function>udev_monitor_unref</function></funcdef>
+        <paramdef>struct udev_monitor *<parameter>udev_monitor</parameter></paramdef>
+      </funcprototype>
+
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <!--<refsect1>
+    <title>Description</title>
+
+    <para>XXX: Add short description.</para>
+  </refsect1>-->
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success,
+    <function>udev_monitor_new_from_netlink()</function> returns a
+    pointer to the allocated udev monitor. On failure,
+    <constant>NULL</constant> is returned.
+    <function>udev_monitor_ref()</function> returns the argument
+    that it was passed, unmodified.
+    <function>udev_monitor_unref()</function> always returns
+    <constant>NULL</constant>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>History</title>
+    <para><function>udev_monitor_new_from_netlink()</function>,
+    <function>udev_monitor_ref()</function>, and
+    <function>udev_monitor_unref()</function> were added in version 221.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>udev_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>udev_device_new_from_syspath</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>udev_enumerate_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>udev_monitor_filter_update</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>udev_monitor_receive_device</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>udev_list_entry</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/udev_monitor_receive_device.xml b/man/udev_monitor_receive_device.xml
new file mode 100644
index 0000000..f2a8dc3
--- /dev/null
+++ b/man/udev_monitor_receive_device.xml
@@ -0,0 +1,119 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [
+<!ENTITY % entities SYSTEM "custom-entities.ent" >
+%entities;
+]>
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="udev_monitor_receive_device"
+  xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>udev_monitor_receive_device</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>udev_monitor_receive_device</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>udev_monitor_receive_device</refname>
+    <refname>udev_monitor_enable_receiving</refname>
+    <refname>udev_monitor_set_receive_buffer_size</refname>
+    <refname>udev_monitor_get_fd</refname>
+    <refname>udev_monitor_get_udev</refname>
+
+    <refpurpose>Query and modify device monitor</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;libudev.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>struct udev_device *<function>udev_monitor_receive_device</function></funcdef>
+        <paramdef>struct udev_monitor *<parameter>udev_monitor</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>udev_monitor_enable_receiving</function></funcdef>
+        <paramdef>struct udev_monitor *<parameter>udev_monitor</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>udev_monitor_set_receive_buffer_size</function></funcdef>
+        <paramdef>struct udev_monitor *<parameter>udev_monitor</parameter></paramdef>
+        <paramdef>int <parameter>size</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>int <function>udev_monitor_get_fd</function></funcdef>
+        <paramdef>struct udev_monitor *<parameter>udev_monitor</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>struct udev *<function>udev_monitor_get_udev</function></funcdef>
+        <paramdef>struct udev_monitor *<parameter>udev_monitor</parameter></paramdef>
+      </funcprototype>
+
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <!--<refsect1>
+    <title>Description</title>
+
+    <para>XXX: Add short description.</para>
+  </refsect1>-->
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success,
+    <function>udev_monitor_receive_device()</function> returns a
+    pointer to a newly referenced device that was received via the
+    monitor. The caller is responsible to drop this reference when
+    done. On failure, <constant>NULL</constant> is returned.</para>
+
+    <para>On success,
+    <function>udev_monitor_enable_receiving()</function> and
+    <function>udev_monitor_set_receive_buffer_size()</function>
+    return an integer greater than, or equal to,
+    <constant>0</constant>. On failure, a negative error code is
+    returned.</para>
+
+    <para>On success, <function>udev_monitor_get_fd()</function>
+    returns the file descriptor used by this monitor. On failure,
+    a negative error code is returned.</para>
+
+    <para><function>udev_monitor_get_udev()</function> always returns
+    a pointer to the udev context that this monitor is associated
+    with.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>History</title>
+    <para><function>udev_monitor_receive_device()</function>,
+    <function>udev_monitor_enable_receiving()</function>,
+    <function>udev_monitor_set_receive_buffer_size()</function>,
+    <function>udev_monitor_get_fd()</function>, and
+    <function>udev_monitor_get_udev()</function> were added in version 221.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>udev_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>udev_device_new_from_syspath</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>udev_enumerate_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>udev_monitor_new_from_netlink</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>udev_monitor_filter_update</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>udev_list_entry</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/udev_new.xml b/man/udev_new.xml
new file mode 100644
index 0000000..cf360f6
--- /dev/null
+++ b/man/udev_new.xml
@@ -0,0 +1,90 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [
+<!ENTITY % entities SYSTEM "custom-entities.ent" >
+%entities;
+]>
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="udev_new"
+  xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>udev_new</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>udev_new</refentrytitle>
+    <manvolnum>3</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>udev_new</refname>
+    <refname>udev_ref</refname>
+    <refname>udev_unref</refname>
+
+    <refpurpose>Create, acquire and release a udev context object</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcsynopsisinfo>#include &lt;libudev.h&gt;</funcsynopsisinfo>
+
+      <funcprototype>
+        <funcdef>struct udev *<function>udev_new</function></funcdef>
+        <paramdef><parameter>void</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>struct udev *<function>udev_ref</function></funcdef>
+        <paramdef>struct udev *<parameter>udev</parameter></paramdef>
+      </funcprototype>
+
+      <funcprototype>
+        <funcdef>struct udev *<function>udev_unref</function></funcdef>
+        <paramdef>struct udev *<parameter>udev</parameter></paramdef>
+      </funcprototype>
+
+    </funcsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><function>udev_new()</function> allocates a new udev context
+    object and returns a pointer to it. This object is opaque and must
+    not be accessed by the caller via different means than functions
+    provided by libudev. Initially, the reference count of the context
+    is 1. You can acquire further references, and drop gained references
+    via <function>udev_ref()</function> and
+    <function>udev_unref()</function>. Once the reference count hits 0,
+    the context object is destroyed and freed.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Return Value</title>
+
+    <para>On success, <function>udev_new()</function> returns a pointer
+    to the allocated udev context. On failure, <constant>NULL</constant>
+    is returned. <function>udev_ref()</function> returns the argument
+    that it was passed, unmodified. <function>udev_unref()</function>
+    always returns <constant>NULL</constant>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>History</title>
+    <para><function>udev_new()</function>,
+    <function>udev_ref()</function>, and
+    <function>udev_unref()</function> were added in version 221.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/udevadm.xml b/man/udevadm.xml
new file mode 100644
index 0000000..76c54c3
--- /dev/null
+++ b/man/udevadm.xml
@@ -0,0 +1,1121 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="udevadm"
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>udevadm</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>udevadm</refentrytitle>
+    <manvolnum>8</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>udevadm</refname><refpurpose>udev management tool</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <cmdsynopsis>
+      <command>udevadm</command>
+        <arg><option>--debug</option></arg>
+        <arg><option>--version</option></arg>
+        <arg><option>--help</option></arg>
+    </cmdsynopsis>
+    <cmdsynopsis>
+      <command>udevadm info <optional>options</optional> <optional>devpath</optional></command>
+    </cmdsynopsis>
+    <cmdsynopsis>
+      <command>udevadm trigger <optional>options</optional> <optional>devpath</optional></command>
+    </cmdsynopsis>
+    <cmdsynopsis>
+      <command>udevadm settle <optional>options</optional></command>
+    </cmdsynopsis>
+    <cmdsynopsis>
+      <command>udevadm control <replaceable>option</replaceable></command>
+    </cmdsynopsis>
+    <cmdsynopsis>
+      <command>udevadm monitor <optional>options</optional></command>
+    </cmdsynopsis>
+    <cmdsynopsis>
+      <command>udevadm test <optional>options</optional> <replaceable>devpath</replaceable></command>
+    </cmdsynopsis>
+    <cmdsynopsis>
+      <command>udevadm test-builtin <optional>options</optional> <replaceable>command</replaceable> <replaceable>devpath</replaceable></command>
+    </cmdsynopsis>
+    <cmdsynopsis>
+      <command>udevadm verify</command>
+      <arg choice="opt" rep="repeat">options</arg>
+      <arg choice="opt" rep="repeat"><replaceable>file</replaceable></arg>
+    </cmdsynopsis>
+    <cmdsynopsis>
+      <command>udevadm wait <optional>options</optional> <replaceable>device|syspath</replaceable></command>
+    </cmdsynopsis>
+    <cmdsynopsis>
+      <command>udevadm lock <optional>options</optional> <replaceable>command</replaceable></command>
+    </cmdsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1><title>Description</title>
+    <para><command>udevadm</command> expects a command and command
+    specific options.  It controls the runtime behavior of
+    <command>systemd-udevd</command>, requests kernel events, manages
+    the event queue, and provides simple debugging mechanisms.</para>
+  </refsect1>
+
+  <refsect1><title>Options</title>
+    <variablelist>
+      <varlistentry>
+        <term><option>-d</option></term>
+        <term><option>--debug</option></term>
+        <listitem>
+          <para>Print debug messages to standard error. This option is implied in <command>udevadm test</command> and
+          <command>udevadm test-builtin</command> commands.</para>
+        </listitem>
+      </varlistentry>
+
+      <xi:include href="standard-options.xml" xpointer="help" />
+    </variablelist>
+
+    <refsect2><title>udevadm info
+      <arg choice="opt"><replaceable>options</replaceable></arg>
+      <arg choice="opt" rep="repeat"><replaceable>devpath</replaceable>|<replaceable>file</replaceable>|<replaceable>unit</replaceable></arg>
+    </title>
+
+      <para>Query the udev database for device information.</para>
+
+      <para>Positional arguments should be used to specify one or more devices. Each one may be a device name
+      (in which case it must start with <filename>/dev/</filename>), a sys path (in which case it must start
+      with <filename>/sys/</filename>), or a systemd device unit name (in which case it must end with
+      <literal>.device</literal>, see
+      <citerefentry><refentrytitle>systemd.device</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
+      </para>
+
+      <variablelist>
+        <varlistentry>
+          <term><option>-q</option></term>
+          <term><option>--query=<replaceable>TYPE</replaceable></option></term>
+          <listitem>
+            <para>Query the database for the specified type of device data.
+            Valid <replaceable>TYPE</replaceable>s are:
+            <constant>name</constant>, <constant>symlink</constant>,
+            <constant>path</constant>, <constant>property</constant>,
+            <constant>all</constant>.</para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><option>--property=<replaceable>NAME</replaceable></option></term>
+          <listitem>
+            <para>When showing device properties using the <option>--query=property</option>
+            option, limit display to properties specified in the argument. The argument should
+            be a comma-separated list of property names. If not specified, all known properties
+            are shown.</para>
+
+          <xi:include href="version-info.xml" xpointer="v250"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><option>--value</option></term>
+          <listitem>
+            <para>When showing device properties using the <option>--query=property</option>
+            option, print only their values, and skip the property name and <literal>=</literal>.</para>
+            <para>Cannot be used together with <option>-x/--export</option> or
+            <option>-P/--export-prefix</option>.</para>
+
+            <xi:include href="version-info.xml" xpointer="v250"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><option>-p</option></term>
+          <term><option>--path=<replaceable>DEVPATH</replaceable></option></term>
+          <listitem>
+            <para>The <filename>/sys/</filename> path of the device to query, e.g.
+            <filename><optional>/sys/</optional>/class/block/sda</filename>. This option is an alternative to
+            the positional argument with a <filename>/sys/</filename> prefix. <command>udevadm info
+            --path=/class/block/sda</command> is equivalent to <command>udevadm info
+            /sys/class/block/sda</command>.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><option>-n</option></term>
+          <term><option>--name=<replaceable>FILE</replaceable></option></term>
+          <listitem>
+            <para>The name of the device node or a symlink to query,
+            e.g. <filename><optional>/dev/</optional>/sda</filename>. This option is an alternative to the
+            positional argument with a <filename>/dev/</filename> prefix. <command>udevadm info
+            --name=sda</command> is equivalent to <command>udevadm info /dev/sda</command>.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><option>-r</option></term>
+          <term><option>--root</option></term>
+          <listitem>
+            <para>Print absolute paths in <command>name</command> or <command>symlink</command>
+            query.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><option>-a</option></term>
+          <term><option>--attribute-walk</option></term>
+          <listitem>
+            <para>Print all sysfs properties of the specified device that can be used
+            in udev rules to match the specified device. It prints all devices
+            along the chain, up to the root of sysfs that can be used in udev rules.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><option>-t</option></term>
+          <term><option>--tree</option></term>
+          <listitem>
+            <para>Display a sysfs tree. This recursively iterates through the sysfs hierarchy and displays it
+            in a tree structure. If a path is specified only the subtree below and its parent directories are
+            shown. This will show both device and subsystem items.</para>
+
+            <xi:include href="version-info.xml" xpointer="v251"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><option>-x</option></term>
+          <term><option>--export</option></term>
+          <listitem>
+            <para>Print output as key/value pairs. Values are enclosed in single quotes.
+            This takes effects only when <option>--query=property</option> or
+            <option>--device-id-of-file=<replaceable>FILE</replaceable></option> is specified.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><option>-P</option></term>
+          <term><option>--export-prefix=<replaceable>NAME</replaceable></option></term>
+          <listitem>
+            <para>Add a prefix to the key name of exported values.
+            This implies <option>--export</option>.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><option>-d</option></term>
+          <term><option>--device-id-of-file=<replaceable>FILE</replaceable></option></term>
+          <listitem>
+            <para>Print major/minor numbers of the underlying device, where the file lives on.
+            If this is specified, all positional arguments are ignored.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><option>-e</option></term>
+          <term><option>--export-db</option></term>
+          <listitem>
+            <para>Export the content of the udev database.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><option>-c</option></term>
+          <term><option>--cleanup-db</option></term>
+          <listitem>
+            <para>Cleanup the udev database.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><option>-w<optional>SECONDS</optional></option></term>
+          <term><option>--wait-for-initialization<optional>=SECONDS</optional></option></term>
+          <listitem>
+            <para>Wait for device to be initialized. If argument <replaceable>SECONDS</replaceable>
+            is not specified, the default is to wait forever.</para>
+
+          <xi:include href="version-info.xml" xpointer="v243"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><option>--subsystem-match<optional>=SUBSYSTEM</optional></option></term>
+          <term><option>--subsystem-nomatch<optional>=SUBSYSTEM</optional></option></term>
+          <listitem>
+            <para>When used with <option>--export-db</option>, only show devices of or not of the given
+            subsystem respectively.</para>
+
+          <xi:include href="version-info.xml" xpointer="v255"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><option>--attr-match<optional>=FILE[=VALUE]</optional></option></term>
+          <term><option>--attr-nomatch<optional>=FILE[=VALUE]</optional></option></term>
+          <listitem>
+            <para>When used with <option>--export-db</option>, only show devices matching or not matching the
+            given attribute respectively.</para>
+
+          <xi:include href="version-info.xml" xpointer="v255"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><option>--property-match<optional>=KEY=VALUE</optional></option></term>
+          <listitem>
+            <para>When used with <option>--export-db</option>, only show devices matching the given property
+            and value.</para>
+
+          <xi:include href="version-info.xml" xpointer="v255"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><option>--tag-match<optional>=TAG</optional></option></term>
+          <listitem>
+            <para>When used with <option>--export-db</option>, only show devices with the given tag.</para>
+
+          <xi:include href="version-info.xml" xpointer="v255"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><option>--sysname-match<optional>=NAME</optional></option></term>
+          <listitem>
+            <para>When used with <option>--export-db</option>, only show devices with the given
+            <literal>/sys</literal> path.</para>
+
+          <xi:include href="version-info.xml" xpointer="v255"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><option>--name-match<optional>=NAME</optional></option></term>
+          <listitem>
+            <para>When used with <option>--export-db</option>, only show devices with the given name in
+            <literal>/dev</literal>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v255"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><option>--parent-match<optional>=NAME</optional></option></term>
+          <listitem>
+            <para>When used with <option>--export-db</option>, only show devices with the given parent
+            device.</para>
+
+          <xi:include href="version-info.xml" xpointer="v255"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><option>--initialized-match</option></term>
+          <term><option>--initialized-nomatch</option></term>
+          <listitem>
+            <para>When used with <option>--export-db</option>, only show devices that are initialized or not
+            initialized respectively.</para>
+
+          <xi:include href="version-info.xml" xpointer="v255"/>
+          </listitem>
+        </varlistentry>
+
+        <xi:include href="standard-options.xml" xpointer="json" />
+        <xi:include href="standard-options.xml" xpointer="help" />
+        <xi:include href="standard-options.xml" xpointer="no-pager" />
+      </variablelist>
+
+      <para>The generated output shows the current device database entry in a terse format. Each line shown
+      is prefixed with one of the following characters:</para>
+
+      <table>
+        <title><command>udevadm info</command> output prefixes</title>
+        <tgroup cols='2' align='left' colsep='1' rowsep='1'>
+          <colspec colname="prefix" />
+          <colspec colname="meaning" />
+          <thead>
+            <row>
+              <entry>Prefix</entry>
+              <entry>Meaning</entry>
+            </row>
+          </thead>
+          <tbody>
+            <row>
+              <entry><literal>P:</literal></entry>
+              <entry>Device path in <filename>/sys/</filename></entry>
+            </row>
+            <row>
+              <entry><literal>M:</literal></entry>
+              <entry>Device name in <filename>/sys/</filename> (i.e. the last component of <literal>P:</literal>)</entry>
+            </row>
+            <row>
+              <entry><literal>R:</literal></entry>
+              <entry>Device number in <filename>/sys/</filename> (i.e. the numeric suffix of the last component of <literal>P:</literal>)</entry>
+            </row>
+            <row>
+              <entry><literal>U:</literal></entry>
+              <entry>Kernel subsystem</entry>
+            </row>
+            <row>
+              <entry><literal>T:</literal></entry>
+              <entry>Kernel device type within subsystem</entry>
+            </row>
+            <row>
+              <entry><literal>D:</literal></entry>
+              <entry>Kernel device node major/minor</entry>
+            </row>
+            <row>
+              <entry><literal>I:</literal></entry>
+              <entry>Network interface index</entry>
+            </row>
+            <row>
+              <entry><literal>N:</literal></entry>
+              <entry>Kernel device node name</entry>
+            </row>
+            <row>
+              <entry><literal>L:</literal></entry>
+              <entry>Device node symlink priority</entry>
+            </row>
+            <row>
+              <entry><literal>S:</literal></entry>
+              <entry>Device node symlink</entry>
+            </row>
+            <row>
+              <entry><literal>Q:</literal></entry>
+              <entry>Block device sequence number (DISKSEQ)</entry>
+            </row>
+            <row>
+              <entry><literal>V:</literal></entry>
+              <entry>Attached driver</entry>
+            </row>
+            <row>
+              <entry><literal>E:</literal></entry>
+              <entry>Device property</entry>
+            </row>
+          </tbody>
+        </tgroup>
+      </table>
+    </refsect2>
+
+    <refsect2><title>udevadm trigger
+      <arg choice="opt"><replaceable>options</replaceable></arg>
+      <arg choice="opt"><replaceable>devpath</replaceable>|<replaceable>file</replaceable>|<replaceable>unit</replaceable></arg>
+      </title>
+      <para>Request device events from the kernel. Primarily used to replay events at system coldplug time.</para>
+
+      <para>Takes device specifications as positional arguments. See the description of <command>info</command>
+      above.</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><option>-v</option></term>
+          <term><option>--verbose</option></term>
+          <listitem>
+            <para>Print the list of devices which will be triggered.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><option>-n</option></term>
+          <term><option>--dry-run</option></term>
+          <listitem>
+            <para>Do not actually trigger the event.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><option>-q</option></term>
+          <term><option>--quiet</option></term>
+          <listitem>
+            <para>Suppress error logging in triggering events.</para>
+
+          <xi:include href="version-info.xml" xpointer="v248"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><option>-t</option></term>
+          <term><option>--type=<replaceable>TYPE</replaceable></option></term>
+          <listitem>
+            <para>Trigger a specific type of devices. Valid types are <literal>all</literal>,
+            <literal>devices</literal>, and <literal>subsystems</literal>. The default value is
+            <literal>devices</literal>.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><option>-c</option></term>
+          <term><option>--action=<replaceable>ACTION</replaceable></option></term>
+          <listitem>
+            <para>Type of event to be triggered. Possible actions are <literal>add</literal>,
+            <literal>remove</literal>, <literal>change</literal>, <literal>move</literal>,
+            <literal>online</literal>, <literal>offline</literal>, <literal>bind</literal>,
+            and <literal>unbind</literal>. Also, the special value <literal>help</literal> can be used
+            to list the possible actions. The default value is <literal>change</literal>.
+            </para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><option>--prioritized-subsystem=<replaceable>SUBSYSTEM<optional>,<replaceable>SUBSYSTEM</replaceable>…</optional></replaceable></option></term>
+          <listitem>
+            <para>Takes a comma separated list of subsystems. When triggering events for devices, the
+            devices from the specified subsystems and their parents are triggered first. For example,
+            if <option>--prioritized-subsystem=block,net</option>, then firstly all block devices and
+            their parents are triggered, in the next all network devices and their parents are
+            triggered, and lastly the other devices are triggered. This option can be specified
+            multiple times, and in that case the lists of the subsystems will be merged. That is,
+            <option>--prioritized-subsystem=block --prioritized-subsystem=net</option> is equivalent to
+            <option>--prioritized-subsystem=block,net</option>.</para>
+
+            <xi:include href="version-info.xml" xpointer="v251"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><option>-s</option></term>
+          <term><option>--subsystem-match=<replaceable>SUBSYSTEM</replaceable></option></term>
+          <listitem>
+            <para>Trigger events for devices which belong to a
+            matching subsystem. This option supports shell style pattern matching.
+            When this option is specified more than once, then each matching result is ORed, that is,
+            all the devices in each subsystem are triggered.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><option>-S</option></term>
+          <term><option>--subsystem-nomatch=<replaceable>SUBSYSTEM</replaceable></option></term>
+          <listitem>
+            <para>Do not trigger events for devices which belong to a matching subsystem. This option
+            supports shell style pattern matching. When this option is specified more than once,
+            then each matching result is ANDed, that is, devices which do not match all specified
+            subsystems are triggered.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><option>-a</option></term>
+          <term><option>--attr-match=<replaceable>ATTRIBUTE</replaceable>=<replaceable>VALUE</replaceable></option></term>
+          <listitem>
+            <para>Trigger events for devices with a matching sysfs attribute. If a value is specified along
+            with the attribute name, the content of the attribute is matched against the given value using
+            shell style pattern matching. If no value is specified, the existence of the sysfs attribute is
+            checked. When this option is specified multiple times, then each matching result is ANDed,
+            that is, only devices which have all specified attributes are triggered.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><option>-A</option></term>
+          <term><option>--attr-nomatch=<replaceable>ATTRIBUTE</replaceable>=<replaceable>VALUE</replaceable></option></term>
+          <listitem>
+            <para>Do not trigger events for devices with a matching sysfs attribute. If a value is specified
+            along with the attribute name, the content of the attribute is matched against the given value
+            using shell style pattern matching. If no value is specified, the existence of the sysfs attribute
+            is checked. When this option is specified multiple times, then each matching result is ANDed,
+            that is, only devices which have none of the specified attributes are triggered.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><option>-p</option></term>
+          <term><option>--property-match=<replaceable>PROPERTY</replaceable>=<replaceable>VALUE</replaceable></option></term>
+          <listitem>
+            <para>Trigger events for devices with a matching property value. This option supports shell style
+            pattern matching. When this option is specified more than once, then each matching result is ORed,
+            that is, devices which have one of the specified properties are triggered.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><option>-g</option></term>
+          <term><option>--tag-match=<replaceable>TAG</replaceable></option></term>
+          <listitem>
+            <para>Trigger events for devices with a matching tag. When this option is specified multiple times,
+            then each matching result is ANDed, that is, devices which have all specified tags are triggered.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><option>-y</option></term>
+          <term><option>--sysname-match=<replaceable>NAME</replaceable></option></term>
+          <listitem>
+            <para>Trigger events for devices for which the last component (i.e. the filename) of the
+            <filename>/sys/</filename> path matches the specified <replaceable>PATH</replaceable>. This option
+            supports shell style pattern matching. When this option is specified more than once, then each
+            matching result is ORed, that is, all devices which have any of the specified
+            <replaceable>NAME</replaceable> are triggered.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><option>--name-match=<replaceable>NAME</replaceable></option></term>
+          <listitem>
+            <para>Trigger events for devices with a matching device path. When this option is specified more than once,
+            then each matching result is ORed, that is, all specified devices are triggered.</para>
+
+            <xi:include href="version-info.xml" xpointer="v218"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><option>-b</option></term>
+          <term><option>--parent-match=<replaceable>SYSPATH</replaceable></option></term>
+          <listitem>
+            <para>Trigger events for all children of a given device. When this option is specified more than once,
+            then each matching result is ORed, that is, all children of each specified device are triggered.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><option>--initialized-match</option></term>
+          <term><option>--initialized-nomatch</option></term>
+          <listitem>
+            <para>When <option>--initialized-match</option> is specified, trigger events for devices
+            that are already initialized by <command>systemd-udevd</command>, and skip devices that
+            are not initialized yet.</para>
+            <para>When <option>--initialized-nomatch</option> is specified, trigger events for devices
+            that are not initialized by <command>systemd-udevd</command> yet, and skip devices that
+            are already initialized.</para>
+            <para>Typically, it is essential that applications which intend to use such a match, make
+            sure a suitable udev rule is installed that sets at least one property on devices that
+            shall be matched. See also Initialized Devices section below for more details.</para>
+            <para>WARNING: <option>--initialized-nomatch</option> can potentially save a significant
+            amount of time compared to re-triggering all devices in the system and e.g. can be used to
+            optimize boot time. However, this is not safe to be used in a boot sequence in general.
+            Especially, when udev rules for a device depend on its parent devices (e.g.
+            <literal>ATTRS</literal> or <literal>IMPORT{parent}</literal> keys, see
+            <citerefentry><refentrytitle>udev</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+            for more details), the final state of the device becomes easily unstable with this option.
+            </para>
+
+            <xi:include href="version-info.xml" xpointer="v251"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><option>-w</option></term>
+          <term><option>--settle</option></term>
+          <listitem>
+            <para>Apart from triggering events, also waits for those events to
+            finish. Note that this is different from calling <command>udevadm
+            settle</command>. <command>udevadm settle</command> waits for all
+            events to finish. This option only waits for events triggered by
+            the same command to finish.</para>
+
+            <xi:include href="version-info.xml" xpointer="v238"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><option>--uuid</option></term>
+          <listitem>
+            <para>Trigger the synthetic device events, and associate a randomized UUID with each. These UUIDs
+            are printed to standard output, one line for each event. These UUIDs are included in the uevent
+            environment block (in the <literal>SYNTH_UUID=</literal> property) and may be used to track
+            delivery of the generated events.</para>
+
+            <xi:include href="version-info.xml" xpointer="v249"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><option>--wait-daemon[=<replaceable>SECONDS</replaceable>]</option></term>
+          <listitem>
+            <para>Before triggering uevents, wait for systemd-udevd daemon to be initialized.
+            Optionally takes timeout value. Default timeout is 5 seconds. This is equivalent to invoking
+            <command>udevadm control --ping</command> before <command>udevadm trigger</command>.</para>
+
+            <xi:include href="version-info.xml" xpointer="v241"/>
+          </listitem>
+        </varlistentry>
+
+        <xi:include href="standard-options.xml" xpointer="help" />
+      </variablelist>
+
+      <para>In addition, optional positional arguments can be used
+      to specify device names or sys paths. They must start with
+      <filename>/dev/</filename> or <filename>/sys/</filename>
+      respectively.</para>
+    </refsect2>
+
+    <refsect2><title>udevadm settle
+      <arg choice="opt"><replaceable>options</replaceable></arg>
+    </title>
+      <para>Watches the udev event queue, and exits if all current events are handled.</para>
+      <variablelist>
+        <varlistentry>
+          <term><option>-t</option></term>
+          <term><option>--timeout=<replaceable>SECONDS</replaceable></option></term>
+          <listitem>
+            <para>Maximum number of seconds to wait for the event
+            queue to become empty. The default value is 120 seconds. A
+            value of 0 will check if the queue is empty and always
+            return immediately. A non-zero value will return an exit
+            code of 0 if queue became empty before timeout was reached,
+            non-zero otherwise.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><option>-E</option></term>
+          <term><option>--exit-if-exists=<replaceable>FILE</replaceable></option></term>
+          <listitem>
+            <para>Stop waiting if file exists.</para>
+          </listitem>
+        </varlistentry>
+
+        <xi:include href="standard-options.xml" xpointer="help" />
+      </variablelist>
+
+      <para>See
+      <citerefentry><refentrytitle>systemd-udev-settle.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+      for more information.</para>
+    </refsect2>
+
+    <refsect2><title>udevadm control <replaceable>option</replaceable></title>
+      <para>Modify the internal state of the running udev daemon.</para>
+      <variablelist>
+        <varlistentry>
+          <term><option>-e</option></term>
+          <term><option>--exit</option></term>
+          <listitem>
+            <para>Signal and wait for systemd-udevd to exit. No option except for
+            <option>--timeout</option> can be specified after this option.
+            Note that <filename>systemd-udevd.service</filename> contains
+            <option>Restart=always</option> and so as a result, this option restarts systemd-udevd.
+            If you want to stop <filename>systemd-udevd.service</filename>, please use the following:
+            <programlisting>systemctl stop systemd-udevd-control.socket systemd-udevd-kernel.socket systemd-udevd.service</programlisting>
+            </para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><option>-l</option></term>
+          <term><option>--log-level=<replaceable>value</replaceable></option></term>
+          <listitem>
+            <para>Set the internal log level of
+            <filename>systemd-udevd</filename>. Valid values are the
+            numerical syslog priorities or their textual
+            representations: <option>emerg</option>,
+            <option>alert</option>, <option>crit</option>,
+            <option>err</option>, <option>warning</option>,
+            <option>notice</option>, <option>info</option>, and
+            <option>debug</option>.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><option>-s</option></term>
+          <term><option>--stop-exec-queue</option></term>
+          <listitem>
+            <para>Signal systemd-udevd to stop executing new events. Incoming events
+            will be queued.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><option>-S</option></term>
+          <term><option>--start-exec-queue</option></term>
+          <listitem>
+            <para>Signal systemd-udevd to enable the execution of events.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><option>-R</option></term>
+          <term><option>--reload</option></term>
+          <listitem>
+            <para>Signal systemd-udevd to reload the rules files and other databases like the kernel
+            module index. Reloading rules and databases does not apply any changes to already
+            existing devices; the new configuration will only be applied to new events.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><option>-p</option></term>
+          <term><option>--property=<replaceable>KEY</replaceable>=<replaceable>value</replaceable></option></term>
+          <listitem>
+            <para>Set a global property for all events.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><option>-m</option></term>
+          <term><option>--children-max=</option><replaceable>value</replaceable></term>
+          <listitem>
+            <para>Set the maximum number of events, systemd-udevd will handle at the same time. When 0 is
+            specified, then the maximum is determined based on the system resources.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><option>--ping</option></term>
+          <listitem>
+            <para>Send a ping message to systemd-udevd and wait for the reply. This may be useful to check that
+            systemd-udevd daemon is running.</para>
+
+            <xi:include href="version-info.xml" xpointer="v241"/>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><option>-t</option></term>
+          <term><option>--timeout=</option><replaceable>seconds</replaceable></term>
+          <listitem>
+            <para>The maximum number of seconds to wait for a reply from systemd-udevd.</para>
+          </listitem>
+        </varlistentry>
+
+        <xi:include href="standard-options.xml" xpointer="help" />
+      </variablelist>
+    </refsect2>
+
+    <refsect2><title>udevadm monitor
+      <arg choice="opt"><replaceable>options</replaceable></arg>
+    </title>
+      <para>Listens to the kernel uevents and events sent out by a udev rule
+      and prints the devpath of the event to the console. It can be used to analyze the
+      event timing, by comparing the timestamps of the kernel uevent and the udev event.
+      </para>
+      <variablelist>
+        <varlistentry>
+          <term><option>-k</option></term>
+          <term><option>--kernel</option></term>
+          <listitem>
+            <para>Print the kernel uevents.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><option>-u</option></term>
+          <term><option>--udev</option></term>
+          <listitem>
+            <para>Print the udev event after the rule processing.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><option>-p</option></term>
+          <term><option>--property</option></term>
+          <listitem>
+            <para>Also print the properties of the event.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><option>-s</option></term>
+          <term><option>--subsystem-match=<replaceable>string[/string]</replaceable></option></term>
+          <listitem>
+            <para>Filter kernel uevents and udev events by subsystem[/devtype]. Only events with a matching subsystem value will pass.
+            When this option is specified more than once, then each matching result is ORed, that is, all devices in the specified
+            subsystems are monitored.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><option>-t</option></term>
+          <term><option>--tag-match=<replaceable>string</replaceable></option></term>
+          <listitem>
+            <para>Filter udev events by tag. Only udev events with a given tag attached will pass.
+            When this option is specified more than once, then each matching result is ORed, that is, devices which have one of the
+            specified tags are monitored.</para>
+          </listitem>
+        </varlistentry>
+
+        <xi:include href="standard-options.xml" xpointer="help" />
+      </variablelist>
+    </refsect2>
+
+    <refsect2><title>udevadm test
+      <arg choice="opt"><replaceable>options</replaceable></arg>
+      <arg choice="opt"><replaceable>devpath</replaceable>|<replaceable>file</replaceable>|<replaceable>unit</replaceable></arg>
+    </title>
+      <para>Simulate a udev event run for the given device, and print debug output.</para>
+      <variablelist>
+        <varlistentry>
+          <term><option>-a</option></term>
+          <term><option>--action=<replaceable>ACTION</replaceable></option></term>
+          <listitem>
+            <para>Type of event to be simulated. Possible actions are <literal>add</literal>,
+            <literal>remove</literal>, <literal>change</literal>, <literal>move</literal>,
+            <literal>online</literal>, <literal>offline</literal>, <literal>bind</literal>,
+            and <literal>unbind</literal>. Also, the special value <literal>help</literal> can be used
+            to list the possible actions. The default value is <literal>add</literal>.</para>
+          </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term><option>-N</option></term>
+          <term><option>--resolve-names=<constant>early</constant>|<constant>late</constant>|<constant>never</constant></option></term>
+          <listitem>
+            <para>Specify when udevadm should resolve names of users
+            and groups.  When set to <constant>early</constant> (the
+            default), names will be resolved when the rules are
+            parsed. When set to <constant>late</constant>, names will
+            be resolved for every event. When set to
+            <constant>never</constant>, names will never be resolved
+            and all devices will be owned by root.</para>
+
+            <xi:include href="version-info.xml" xpointer="v209"/>
+          </listitem>
+        </varlistentry>
+
+        <xi:include href="standard-options.xml" xpointer="help" />
+      </variablelist>
+    </refsect2>
+
+    <refsect2><title>udevadm test-builtin
+      <arg choice="opt"><replaceable>options</replaceable></arg>
+      <arg><replaceable>command</replaceable></arg>
+      <arg choice="opt"><replaceable>devpath</replaceable>|<replaceable>file</replaceable>|<replaceable>unit</replaceable></arg>
+    </title>
+      <para>Run a built-in command <replaceable>COMMAND</replaceable>
+      for device <replaceable>DEVPATH</replaceable>, and print debug
+      output.</para>
+      <variablelist>
+        <varlistentry>
+          <term><option>-a</option></term>
+          <term><option>--action=<replaceable>ACTION</replaceable></option></term>
+          <listitem>
+            <para>Type of event to be simulated. Possible actions are <literal>add</literal>,
+            <literal>remove</literal>, <literal>change</literal>, <literal>move</literal>,
+            <literal>online</literal>, <literal>offline</literal>, <literal>bind</literal>,
+            and <literal>unbind</literal>. Also, the special value <literal>help</literal> can be used
+            to list the possible actions. The default value is <literal>add</literal>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v250"/>
+          </listitem>
+        </varlistentry>
+
+        <xi:include href="standard-options.xml" xpointer="help" />
+        <xi:include href="standard-options.xml" xpointer="version" />
+      </variablelist>
+    </refsect2>
+
+    <refsect2>
+      <title>udevadm verify
+      <arg choice="opt"><replaceable>options</replaceable></arg>
+      <arg choice="opt" rep="repeat"><replaceable>file</replaceable></arg>
+      …
+      </title>
+
+      <para>Verify syntactic, semantic, and stylistic correctness of udev rules files.</para>
+
+      <para>Positional arguments could be used to specify one or more files to check.
+      If no files are specified, the udev rules are read from the files located in
+      the same udev/rules.d directories that are processed by the udev daemon.</para>
+
+      <para>The exit status is <constant>0</constant> if all specified udev
+      rules files are syntactically, semantically, and stylistically correct,
+      and a non-zero error code otherwise.</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><option>-N</option></term>
+          <term><option>--resolve-names=<constant>early</constant>|<constant>never</constant></option></term>
+          <listitem>
+            <para>Specify when udevadm should resolve names of users
+            and groups.  When set to <constant>early</constant> (the
+            default), names will be resolved when the rules are
+            parsed. When set to <constant>never</constant>, names will
+            never be resolved.</para>
+
+            <xi:include href="version-info.xml" xpointer="v254"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><option>--root=<replaceable>PATH</replaceable></option></term>
+          <listitem>
+            <para>When looking for udev rules files located in udev/rules.d directories,
+            operate on files underneath the specified root path <replaceable>PATH</replaceable>.</para>
+
+            <xi:include href="version-info.xml" xpointer="v254"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><option>--no-summary</option></term>
+          <listitem>
+            <para>Do not show summary.</para>
+
+          <xi:include href="version-info.xml" xpointer="v254"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><option>--no-style</option></term>
+          <listitem>
+            <para>Ignore style issues. When specified, even if style issues are found in udev rules files,
+            the exit status is <constant>0</constant> if no syntactic or semantic errors are found.</para>
+
+            <xi:include href="version-info.xml" xpointer="v254"/>
+          </listitem>
+        </varlistentry>
+
+        <xi:include href="standard-options.xml" xpointer="help" />
+      </variablelist>
+    </refsect2>
+
+    <refsect2>
+      <title>udevadm wait
+      <arg choice="opt"><replaceable>options</replaceable></arg>
+      <arg choice="opt"><replaceable>device|syspath</replaceable></arg>
+      …
+      </title>
+
+      <para>Wait for devices or device symlinks being created and initialized by
+      <command>systemd-udevd</command>. Each device path must start with
+      <literal>/dev/</literal> or <literal>/sys/</literal>, e.g. <literal>/dev/sda</literal>,
+      <literal>/dev/disk/by-path/pci-0000:3c:00.0-nvme-1-part1</literal>,
+      <literal>/sys/devices/pci0000:00/0000:00:1f.6/net/eth0</literal>, or
+      <literal>/sys/class/net/eth0</literal>. This can take multiple devices. This may be useful for
+      waiting for devices being processed by <command>systemd-udevd</command> after e.g. partitioning
+      or formatting the devices.</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><option>-t</option></term>
+          <term><option>--timeout=<replaceable>SECONDS</replaceable></option></term>
+          <listitem>
+            <para>Maximum number of seconds to wait for the specified devices or device symlinks being
+            created, initialized, or removed. The default value is <literal>infinity</literal>.</para>
+
+            <xi:include href="version-info.xml" xpointer="v251"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><option>--initialized=<replaceable>BOOL</replaceable></option></term>
+          <listitem>
+            <para>Check if <command>systemd-udevd</command> initialized devices. Defaults to true. When
+            false, the command only checks if the specified devices exist. Set false to this setting if
+            there is no udev rules for the specified devices, as the devices will never be considered
+            as initialized in that case. See Initialized Devices section below for more details.</para>
+
+          <xi:include href="version-info.xml" xpointer="v251"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><option>--removed</option></term>
+          <listitem>
+            <para>When specified, the command wait for devices being removed instead of created or
+            initialized. If this is specified, <option>--initialized=</option> will be ignored.</para>
+
+            <xi:include href="version-info.xml" xpointer="v251"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><option>--settle</option></term>
+          <listitem>
+            <para>When specified, also watches the udev event queue, and wait for all queued events
+            being processed by <command>systemd-udevd</command>.</para>
+
+            <xi:include href="version-info.xml" xpointer="v251"/>
+          </listitem>
+        </varlistentry>
+
+        <xi:include href="standard-options.xml" xpointer="help" />
+      </variablelist>
+    </refsect2>
+
+    <refsect2>
+      <title>udevadm lock
+      <arg choice="opt"><replaceable>options</replaceable></arg>
+      <arg choice="opt"><replaceable>command</replaceable></arg>
+      …
+      </title>
+
+      <para><command>udevadm lock</command> takes an (advisory) exclusive lock on a block device (or all
+      specified devices), as per <ulink url="https://systemd.io/BLOCK_DEVICE_LOCKING">Locking Block Device
+      Access</ulink> and invokes a program with the locks taken. When the invoked program exits the locks
+      are automatically released and its return value is propagated as exit code of <command>udevadm
+      lock</command>.</para>
+
+      <para>This tool is in particular useful to ensure that
+      <citerefentry><refentrytitle>systemd-udevd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+      does not probe a block device while changes are made to it, for example partitions created or file
+      systems formatted. Note that many tools that interface with block devices natively support taking
+      relevant locks, see for example
+      <citerefentry project='man-pages'><refentrytitle>sfdisk</refentrytitle><manvolnum>8</manvolnum></citerefentry>'s
+      <option>--lock</option> switch.</para>
+
+      <para>The command expects at least one block device specified via <option>--device=</option> or
+      <option>--backing=</option>, and a command line to execute as arguments.</para>
+
+      <variablelist>
+        <varlistentry>
+          <term><option>--device=<replaceable>DEVICE</replaceable></option></term>
+          <term><option>-d <replaceable>DEVICE</replaceable></option></term>
+
+          <listitem><para>Takes a path to a device node of the device to lock. This switch may be used
+          multiple times (and in combination with <option>--backing=</option>) in order to lock multiple
+          devices. If a partition block device node is specified the containing "whole" block device is
+          automatically determined and used for the lock, as per the specification. If multiple devices are
+          specified, they are deduplicated, sorted by the major/minor of their device nodes and then locked
+          in order.</para>
+
+          <para>This switch must be used at least once, to specify at least one device to
+          lock. (Alternatively, use <option>--backing=</option>, see below.)</para>
+
+          <xi:include href="version-info.xml" xpointer="v251"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><option>--backing=<replaceable>PATH</replaceable></option></term>
+          <term><option>-b <replaceable>PATH</replaceable></option></term>
+
+          <listitem><para>If a path to a device node is specified, identical to
+          <option>--device=</option>. However, this switch alternatively accepts a path to a regular file or
+          directory, in which case the block device of the file system the file/directory resides on is
+          automatically determined and used as if it was specified with
+          <option>--device=</option>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v251"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><option>--timeout=<replaceable>SECS</replaceable></option></term>
+          <term><option>-t <replaceable>SECS</replaceable></option></term>
+
+          <listitem><para>Specifies how long to wait at most until all locks can be taken. Takes a value in
+          seconds, or in the usual supported time units, see
+          <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry>. If
+          specified as zero the lock is attempted and if not successful the invocation will immediately
+          fail. If passed as <literal>infinity</literal> (the default) the invocation will wait indefinitely
+          until the lock can be acquired. If the lock cannot be taken in the specified time the specified
+          command will not be executed and the invocation will fail.</para>
+
+          <xi:include href="version-info.xml" xpointer="v251"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><option>--print</option></term>
+          <term><option>-p</option></term>
+
+          <listitem><para>Instead of locking the specified devices and executing a command, just print the
+          device paths that would be locked, and execute no command. This command is useful to determine
+          the "whole" block device in case a partition block device is specified. The devices will be sorted
+          by their device node major number as primary ordering key and the minor number as secondary
+          ordering key (i.e. they are shown in the order they'd be locked). Note that the number of lines
+          printed here can be less than the number of <option>--device=</option> and
+          <option>--backing=</option> switches specified in case these resolve to the same "whole"
+          devices.</para>
+
+          <xi:include href="version-info.xml" xpointer="v251"/></listitem>
+        </varlistentry>
+
+        <xi:include href="standard-options.xml" xpointer="help" />
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <refsect1>
+    <title>Initialized Devices</title>
+
+    <para>Initialized devices are those for which at least one udev rule already completed execution
+    – for any action but <literal>remove</literal> — that set a property or other device setting (and
+    thus has an entry in the udev device database). Devices are no longer considered initialized if a
+    <literal>remove</literal> action is seen for them (which removes their entry in the udev device
+    database). Note that devices that have no udev rules are never considered initialized, but might
+    still be announced via the sd-device API (or similar).</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Example</title>
+
+    <example>
+      <title>Format a File System</title>
+
+      <para>Take a lock on the backing block device while creating a file system, to ensure that
+      <command>systemd-udevd</command> doesn't probe or announce the new superblock before it is
+      comprehensively written:</para>
+
+      <programlisting># udevadm lock --device=/dev/sda1 mkfs.ext4 /dev/sda1</programlisting>
+    </example>
+
+    <example>
+      <title>Format a RAID File System</title>
+
+      <para>Similar, but take locks on multiple devices at once:</para>
+
+      <programlisting># udevadm lock --device=/dev/sda1 --device=/dev/sdb1 mkfs.btrfs /dev/sda1 /dev/sdb1</programlisting>
+    </example>
+
+    <example>
+      <title>Copy in a File System</title>
+
+      <para>Take a lock on the backing block device while copying in a prepared file system image, to ensure
+      that <command>systemd-udevd</command> doesn't probe or announce the new superblock before it is fully
+      written:</para>
+
+      <programlisting># udevadm lock -d /dev/sda1 dd if=fs.raw of=/dev/sda1</programlisting>
+    </example>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para><citerefentry>
+        <refentrytitle>udev</refentrytitle><manvolnum>7</manvolnum>
+    </citerefentry>,
+    <citerefentry>
+        <refentrytitle>systemd-udevd.service</refentrytitle><manvolnum>8</manvolnum>
+    </citerefentry></para>
+  </refsect1>
+</refentry>
diff --git a/man/uki.conf.example b/man/uki.conf.example
new file mode 100644
index 0000000..84a9f77
--- /dev/null
+++ b/man/uki.conf.example
@@ -0,0 +1,14 @@
+[UKI]
+SecureBootPrivateKey=/etc/kernel/secure-boot.key.pem
+SecureBootCertificate=/etc/kernel/secure-boot.cert.pem
+
+[PCRSignature:initrd]
+Phases=enter-initrd
+PCRPrivateKey=/etc/kernel/pcr-initrd.key.pem
+PCRPublicKey=/etc/kernel/pcr-initrd.pub.pem
+
+[PCRSignature:system]
+Phases=enter-initrd:leave-initrd enter-initrd:leave-initrd:sysinit
+       enter-initrd:leave-initrd:sysinit:ready
+PCRPrivateKey=/etc/kernel/pcr-system.key.pem
+PCRPublicKey=/etc/kernel/pcr-system.pub.pem
diff --git a/man/ukify.xml b/man/ukify.xml
new file mode 100644
index 0000000..9b7e209
--- /dev/null
+++ b/man/ukify.xml
@@ -0,0 +1,686 @@
+<?xml version="1.0"?>
+<!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+<refentry id="ukify" xmlns:xi="http://www.w3.org/2001/XInclude" conditional='ENABLE_UKIFY'>
+
+  <refentryinfo>
+    <title>ukify</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>ukify</refentrytitle>
+    <manvolnum>1</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>ukify</refname>
+    <refpurpose>Combine components into a signed Unified Kernel Image for UEFI systems</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <cmdsynopsis>
+      <command>ukify</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="plain">build</arg>
+    </cmdsynopsis>
+
+    <cmdsynopsis>
+      <command>ukify</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="plain">genkey</arg>
+    </cmdsynopsis>
+
+    <cmdsynopsis>
+      <command>ukify</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="plain">inspect</arg>
+      <arg choice="plain" rep="repeat">FILE</arg>
+    </cmdsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>ukify</command> is a tool whose primary purpose is to combine components (usually a
+    kernel, an initrd, and a UEFI boot stub) to create a
+    <ulink url="https://uapi-group.org/specifications/specs/unified_kernel_image/">Unified Kernel Image (UKI)</ulink>
+    — a PE binary that can be executed by the firmware to start the embedded linux kernel.
+    See <citerefentry><refentrytitle>systemd-stub</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+    for details about the stub.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Commands</title>
+
+    <para>The following commands are understood:</para>
+
+    <refsect2>
+      <title><command>build</command></title>
+
+      <para>This command creates a Unified Kernel Image. The two primary options that should be specified for
+      the <command>build</command> verb are <varname>Linux=</varname>/<option>--linux=</option>, and
+      <varname>Initrd=</varname>/<option>--initrd=</option>. <varname>Initrd=</varname> accepts multiple
+      whitespace-separated paths and <option>--initrd=</option> can be specified multiple times.</para>
+
+      <para>Additional sections will be inserted into the UKI, either automatically or only if a specific
+      option is provided. See the discussions of
+      <varname>Cmdline=</varname>/<option>--cmdline=</option>,
+      <varname>OSRelease=</varname>/<option>--os-release=</option>,
+      <varname>DeviceTree=</varname>/<option>--devicetree=</option>,
+      <varname>Splash=</varname>/<option>--splash=</option>,
+      <varname>PCRPKey=</varname>/<option>--pcrpkey=</option>,
+      <varname>Uname=</varname>/<option>--uname=</option>,
+      <varname>SBAT=</varname>/<option>--sbat=</option>,
+      and <option>--section=</option>
+      below.</para>
+
+      <para><command>ukify</command> can also be used to assemble a PE binary that is not executable but
+      contains auxiliary data, for example additional kernel command line entries.</para>
+
+      <para>If PCR signing keys are provided via the
+      <varname>PCRPrivateKey=</varname>/<option>--pcr-private-key=</option> and
+      <varname>PCRPublicKey=</varname>/<option>--pcr-public-key=</option> options, PCR values that will be seen
+      after booting with the given kernel, initrd, and other sections, will be calculated, signed, and embedded
+      in the UKI.
+      <citerefentry><refentrytitle>systemd-measure</refentrytitle><manvolnum>1</manvolnum></citerefentry> is
+      used to perform this calculation and signing.</para>
+
+      <para>The calculation of PCR values is done for specific boot phase paths. Those can be specified with
+      the <varname>Phases=</varname>/<option>--phases=</option> option. If not specified, the default provided
+      by <command>systemd-measure</command> is used. It is also possible to specify the
+      <varname>PCRPrivateKey=</varname>/<option>--pcr-private-key=</option>,
+      <varname>PCRPublicKey=</varname>/<option>--pcr-public-key=</option>, and
+      <varname>Phases=</varname>/<option>--phases=</option> arguments more than once. Signatures will then be
+      performed with each of the specified keys. On the command line, when both <option>--phases=</option> and
+      <option>--pcr-private-key=</option> are used, they must be specified the same number of times, and then
+      the n-th boot phase path set will be signed by the n-th key. This can be used to build different trust
+      policies for different phases of the boot. In the config file, <varname>PCRPrivateKey=</varname>,
+      <varname>PCRPublicKey=</varname>, and <varname>Phases=</varname> are grouped into separate sections,
+      describing separate boot phases.</para>
+
+      <para>If a SecureBoot signing key is provided via the
+      <varname>SecureBootPrivateKey=</varname>/<option>--secureboot-private-key=</option> option, the resulting
+      PE binary will be signed as a whole, allowing the resulting UKI to be trusted by SecureBoot. Also see the
+      discussion of automatic enrollment in
+      <citerefentry><refentrytitle>systemd-boot</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
+      </para>
+
+      <para>If the stub and/or the kernel contain <literal>.sbat</literal> sections they will be merged in
+      the UKI so that revocation updates affecting either are considered when the UKI is loaded by Shim. For
+      more information on SBAT see
+      <ulink url="https://github.com/rhboot/shim/blob/main/SBAT.md">Shim documentation</ulink>.
+      </para>
+    </refsect2>
+
+    <refsect2>
+      <title><command>genkey</command></title>
+
+      <para>This command creates the keys for PCR signing and the key and certificate used for SecureBoot
+      signing. The same configuration options that determine what keys and in which paths will be needed for
+      signing when <command>build</command> is used, here determine which keys will be created. See the
+      discussion of <varname>PCRPrivateKey=</varname>/<option>--pcr-private-key=</option>,
+      <varname>PCRPublicKey=</varname>/<option>--pcr-public-key=</option>, and
+      <varname>SecureBootPrivateKey=</varname>/<option>--secureboot-private-key=</option> below.</para>
+
+      <para>The output files must not exist.</para>
+    </refsect2>
+
+    <refsect2>
+      <title><command>inspect</command></title>
+
+      <para>Display information about the sections in a given binary or binaries.
+      If <option>--all</option> is given, all sections are shown.
+      Otherwise, if <option>--section=</option> option is specified at least once, only those sections are shown.
+      Otherwise, well-known sections that are typically included in an UKI are shown.
+      For each section, its name, size, and sha256-digest is printed.
+      For text sections, the contents are printed.</para>
+
+      <para>Also see the description of <option>-j</option>/<option>--json=</option> and
+      <option>--section=</option>.</para>
+    </refsect2>
+  </refsect1>
+
+  <refsect1>
+    <title>Configuration settings</title>
+
+    <para>Settings can appear in configuration files (the syntax with <varname
+    index='false'>SomeSetting=<replaceable>value</replaceable></varname>) and on the command line (the syntax
+    with <option index='false'>--some-setting=<replaceable>value</replaceable></option>). For some command
+    line parameters, a single-letter shortcut is also allowed. In the configuration files, the setting must
+    be in the appropriate section, so the descriptions are grouped by section below. When the same setting
+    appears in the configuration file and on the command line, generally the command line setting has higher
+    priority and overwrites the config file setting completely. If some setting behaves differently, this is
+    described below.</para>
+
+    <para>If no config file is provided via the option <option>--config=<replaceable>PATH</replaceable></option>,
+    <command>ukify</command> will try to look for a default configuration file in the following paths in this
+    order: <filename>/run/systemd/ukify.conf</filename>, <filename>/etc/systemd/ukify.conf</filename>,
+    <filename>/usr/local/lib/systemd/ukify.conf</filename>, and <filename>/usr/lib/systemd/ukify.conf</filename>,
+    and then load the first one found. <command>ukify</command> will proceed normally if no configuration file
+    is specified and no default one is found.</para>
+
+    <para>The <replaceable>LINUX</replaceable> and <replaceable>INITRD</replaceable> positional arguments, or
+    the equivalent <varname>Linux=</varname> and <varname>Initrd=</varname> settings, are optional. If more
+    than one initrd is specified, they will all be combined into a single PE section. This is useful to, for
+    example, prepend microcode before the actual initrd.</para>
+
+    <para>The following options and settings are understood:</para>
+
+    <refsect2>
+      <title>Command line-only options</title>
+
+      <variablelist>
+        <varlistentry>
+          <term><option>--config=<replaceable>PATH</replaceable></option></term>
+
+          <listitem><para>Load configuration from the given config file. In general, settings specified in
+          the config file have lower precedence than the settings specified via options. In cases where the
+          command line option does not fully override the config file setting are explicitly mentioned in the
+          descriptions of individual options.</para>
+
+          <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><option>--measure</option></term>
+          <term><option>--no-measure</option></term>
+
+          <listitem><para>Enable or disable a call to
+          <citerefentry><refentrytitle>systemd-measure</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+          to print pre-calculated PCR values. Defaults to false.</para>
+
+          <xi:include href="version-info.xml" xpointer="v253"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><option>--section=<replaceable>NAME</replaceable>:<replaceable>TEXT</replaceable>|<replaceable>@PATH</replaceable></option></term>
+          <term><option>--section=<replaceable>NAME</replaceable>:<arg choice="plain">text|binary</arg><optional>@<replaceable>PATH</replaceable></optional></option></term>
+
+          <listitem><para>For all verbs except <command>inspect</command>, the first syntax is used.
+          Specify an arbitrary additional section <literal><replaceable>NAME</replaceable></literal>.
+          The argument may be a literal string, or <literal>@</literal> followed by a path name.
+          This option may be specified more than once. Any sections specified in this fashion will be
+          inserted (in order) before the <literal>.linux</literal> section which is always last.</para>
+
+          <para>For the <command>inspect</command> verb, the second syntax is used.
+          The section <replaceable>NAME</replaceable> will be inspected (if found).
+          If the second argument is <literal>text</literal>, the contents will be printed.
+          If the third argument is given, the contents will be saved to file <replaceable>PATH</replaceable>.
+          </para>
+
+          <para>Note that the name is used as-is, and if the section name should start with a dot, it must be
+          included in <replaceable>NAME</replaceable>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v253"/>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><option>--tools=<replaceable>DIRS</replaceable></option></term>
+
+          <listitem><para>Specify one or more directories with helper tools. <command>ukify</command> will
+          look for helper tools in those directories first, and if not found, try to load them from
+          <varname>$PATH</varname> in the usual fashion.</para>
+
+          <xi:include href="version-info.xml" xpointer="v253"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><option>--output=<replaceable>FILENAME</replaceable></option></term>
+
+          <listitem><para>The output filename. If not specified, the name of the
+          <replaceable>LINUX</replaceable> argument, with the suffix <literal>.unsigned.efi</literal> or
+          <literal>.signed.efi</literal> will be used, depending on whether signing for SecureBoot was
+          performed.</para>
+
+          <xi:include href="version-info.xml" xpointer="v253"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><option>--summary</option></term>
+
+          <listitem><para>Print a summary of loaded config and exit. This is useful to check how the options
+          from the configuration file and the command line are combined.</para>
+
+          <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><option>--all</option></term>
+
+          <listitem><para>Print all sections (with <command>inspect</command> verb).</para>
+
+          <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><option>--json</option></term>
+
+          <listitem><para>Generate JSON output (with <command>inspect</command> verb).</para>
+
+          <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+        </varlistentry>
+
+        <xi:include href="standard-options.xml" xpointer="help" />
+        <xi:include href="standard-options.xml" xpointer="version" />
+      </variablelist>
+    </refsect2>
+
+    <refsect2>
+      <title>[UKI] section</title>
+
+      <variablelist>
+        <varlistentry>
+          <term><varname>Linux=<replaceable>LINUX</replaceable></varname></term>
+          <term><option>--linux=<replaceable>LINUX</replaceable></option></term>
+
+          <listitem><para>A path to the kernel binary.</para>
+
+          <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>Initrd=<replaceable>INITRD</replaceable>...</varname></term>
+          <term><option>--initrd=<replaceable>LINUX</replaceable></option></term>
+
+          <listitem><para>Zero or more initrd paths. In the configuration file, items are separated by
+          whitespace. The initrds are combined in the order of specification, with the initrds specified in
+          the config file first.</para>
+
+          <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>Cmdline=<replaceable>TEXT</replaceable>|<replaceable>@PATH</replaceable></varname></term>
+          <term><option>--cmdline=<replaceable>TEXT</replaceable>|<replaceable>@PATH</replaceable></option></term>
+
+          <listitem><para>The kernel command line (the <literal>.cmdline</literal> section). The argument may
+          be a literal string, or <literal>@</literal> followed by a path name. If not specified, no command
+          line will be embedded.</para>
+
+          <xi:include href="version-info.xml" xpointer="v253"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>OSRelease=<replaceable>TEXT</replaceable>|<replaceable>@PATH</replaceable></varname></term>
+          <term><option>--os-release=<replaceable>TEXT</replaceable>|<replaceable>@PATH</replaceable></option></term>
+
+          <listitem><para>The os-release description (the <literal>.osrel</literal> section). The argument
+          may be a literal string, or <literal>@</literal> followed by a path name. If not specified, the
+          <citerefentry><refentrytitle>os-release</refentrytitle><manvolnum>5</manvolnum></citerefentry> file
+          will be picked up from the host system.</para>
+
+          <xi:include href="version-info.xml" xpointer="v253"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>DeviceTree=<replaceable>PATH</replaceable></varname></term>
+          <term><option>--devicetree=<replaceable>PATH</replaceable></option></term>
+
+          <listitem><para>The devicetree description (the <literal>.dtb</literal> section). The argument is a
+          path to a compiled binary DeviceTree file. If not specified, the section will not be present.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v253"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>Splash=<replaceable>PATH</replaceable></varname></term>
+          <term><option>--splash=<replaceable>PATH</replaceable></option></term>
+
+          <listitem><para>A picture to display during boot (the <literal>.splash</literal> section). The
+          argument is a path to a BMP file. If not specified, the section will not be present.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v253"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>PCRPKey=<replaceable>PATH</replaceable></varname></term>
+          <term><option>--pcrpkey=<replaceable>PATH</replaceable></option></term>
+
+          <listitem><para>A path to a public key to embed in the <literal>.pcrpkey</literal> section. If not
+          specified, and there's exactly one
+          <varname>PCRPublicKey=</varname>/<option>--pcr-public-key=</option> argument, that key will be used.
+          Otherwise, the section will not be present.</para>
+
+          <xi:include href="version-info.xml" xpointer="v253"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>Uname=<replaceable>VERSION</replaceable></varname></term>
+          <term><option>--uname=<replaceable>VERSION</replaceable></option></term>
+
+          <listitem><para>Specify the kernel version (as in <command>uname -r</command>, the
+          <literal>.uname</literal> section). If not specified, an attempt will be made to extract the
+          version string from the kernel image. It is recommended to pass this explicitly if known, because
+          the extraction is based on heuristics and not very reliable. If not specified and extraction fails,
+          the section will not be present.</para>
+
+          <xi:include href="version-info.xml" xpointer="v253"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>PCRBanks=<replaceable>PATH</replaceable></varname></term>
+          <term><option>--pcr-banks=<replaceable>PATH</replaceable></option></term>
+
+          <listitem><para>A comma or space-separated list of PCR banks to sign a policy for. If not present,
+          all known banks will be used (<literal>sha1</literal>, <literal>sha256</literal>,
+          <literal>sha384</literal>, <literal>sha512</literal>), which will fail if not supported by the
+          system.</para>
+
+          <xi:include href="version-info.xml" xpointer="v253"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>SecureBootSigningTool=<replaceable>SIGNER</replaceable></varname></term>
+          <term><option>--signtool=<replaceable>SIGNER</replaceable></option></term>
+
+          <listitem><para>Whether to use <literal>sbsign</literal> or <literal>pesign</literal>.
+          Depending on this choice, different parameters are required in order to sign an image.
+          Defaults to <literal>sbsign</literal>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>SecureBootPrivateKey=<replaceable>SB_KEY</replaceable></varname></term>
+          <term><option>--secureboot-private-key=<replaceable>SB_KEY</replaceable></option></term>
+
+          <listitem><para>A path to a private key to use for signing of the resulting binary. If the
+          <varname>SigningEngine=</varname>/<option>--signing-engine=</option> option is used, this may also be
+          an engine-specific designation. This option is required by
+          <varname>SecureBootSigningTool=sbsign</varname>/<option>--signtool=sbsign</option>. </para>
+
+          <xi:include href="version-info.xml" xpointer="v253"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>SecureBootCertificate=<replaceable>SB_CERT</replaceable></varname></term>
+          <term><option>--secureboot-certificate=<replaceable>SB_CERT</replaceable></option></term>
+
+          <listitem><para>A path to a certificate to use for signing of the resulting binary. If the
+          <varname>SigningEngine=</varname>/<option>--signing-engine=</option> option is used, this may also
+          be an engine-specific designation. This option is required by
+          <varname>SecureBootSigningTool=sbsign</varname>/<option>--signtool=sbsign</option>. </para>
+
+          <xi:include href="version-info.xml" xpointer="v253"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>SecureBootCertificateDir=<replaceable>SB_PATH</replaceable></varname></term>
+          <term><option>--secureboot-certificate-dir=<replaceable>SB_PATH</replaceable></option></term>
+
+          <listitem><para>A path to a nss certificate database directory to use for signing of the resulting binary.
+          Takes effect when <varname>SecureBootSigningTool=pesign</varname>/<option>--signtool=pesign</option> is used.
+          Defaults to <filename>/etc/pki/pesign</filename>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>SecureBootCertificateName=<replaceable>SB_CERTNAME</replaceable></varname></term>
+          <term><option>--secureboot-certificate-name=<replaceable>SB_CERTNAME</replaceable></option></term>
+
+          <listitem><para>The name of the nss certificate database entry to use for signing of the resulting binary.
+          This option is required by <varname>SecureBootSigningTool=pesign</varname>/<option>--signtool=pesign</option>.</para>
+
+          <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>SecureBootCertificateValidity=<replaceable>DAYS</replaceable></varname></term>
+          <term><option>--secureboot-certificate-validity=<replaceable>DAYS</replaceable></option></term>
+
+          <listitem><para>Period of validity (in days) for a certificate created by
+          <command>genkey</command>. Defaults to 3650, i.e. 10 years.</para>
+
+          <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>SigningEngine=<replaceable>ENGINE</replaceable></varname></term>
+          <term><option>--signing-engine=<replaceable>ENGINE</replaceable></option></term>
+
+          <listitem><para>An "engine" for signing of the resulting binary. This option is currently passed
+          verbatim to the <option>--engine=</option> option of
+          <citerefentry project='archlinux'><refentrytitle>sbsign</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v253"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>SignKernel=<replaceable>BOOL</replaceable></varname></term>
+          <term><option>--sign-kernel</option></term>
+          <term><option>--no-sign-kernel</option></term>
+
+          <listitem><para>Override the detection of whether to sign the Linux binary itself before it is
+          embedded in the combined image. If not specified, it will be signed if a SecureBoot signing key is
+          provided via the
+          <varname>SecureBootPrivateKey=</varname>/<option>--secureboot-private-key=</option> option and the
+          binary has not already been signed. If
+          <varname>SignKernel=</varname>/<option>--sign-kernel</option> is true, and the binary has already
+          been signed, the signature will be appended anyway.</para>
+
+          <xi:include href="version-info.xml" xpointer="v253"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>SBAT=<replaceable>TEXT</replaceable>|<replaceable>@PATH</replaceable></varname></term>
+          <term><option>--sbat=<replaceable>TEXT</replaceable>|<replaceable>@PATH</replaceable></option></term>
+
+          <listitem><para>SBAT metadata associated with the UKI or addon. SBAT policies are useful to revoke
+          whole groups of UKIs or addons with a single, static policy update that does not take space in
+          DBX/MOKX. If not specified manually, a default metadata entry consisting of
+          <literal>uki,1,UKI,uki,1,https://www.freedesktop.org/software/systemd/man/systemd-stub.html</literal>
+          will be used, to ensure it is always possible to revoke UKIs and addons. For more information on
+          SBAT see <ulink url="https://github.com/rhboot/shim/blob/main/SBAT.md">Shim documentation</ulink>.
+          </para>
+
+          <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+
+    <refsect2>
+      <title>[PCRSignature:<replaceable>NAME</replaceable>] section</title>
+
+      <para>In the config file, those options are grouped by section. On the command line, they
+      must be specified in the same order. The sections specified in both sources are combined.
+      </para>
+
+      <variablelist>
+        <varlistentry>
+          <term><varname>PCRPrivateKey=<replaceable>PATH</replaceable></varname></term>
+          <term><option>--pcr-private-key=<replaceable>PATH</replaceable></option></term>
+
+          <listitem><para>A private key to use for signing PCR policies. On the command line, this option may
+          be specified more than once, in which case multiple signatures will be made.</para>
+
+          <xi:include href="version-info.xml" xpointer="v253"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>PCRPublicKey=<replaceable>PATH</replaceable></varname></term>
+          <term><option>--pcr-public-key=<replaceable>PATH</replaceable></option></term>
+
+          <listitem><para>A public key to use for signing PCR policies.</para>
+
+          <para>On the command line, this option may be specified more than once, similarly to the
+          <option>--pcr-private-key=</option> option. If not present, the public keys will be extracted from
+          the private keys. On the command line, if present, this option must be specified the same number of
+          times as the <option>--pcr-private-key=</option> option.</para>
+
+          <xi:include href="version-info.xml" xpointer="v253"/></listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><varname>Phases=<replaceable>LIST</replaceable></varname></term>
+          <term><option>--phases=<replaceable>LIST</replaceable></option></term>
+
+          <listitem><para>A comma or space-separated list of colon-separated phase paths to sign a policy
+          for. Each set of boot phase paths will be signed with the corresponding private key. If not
+          present, the default of
+          <citerefentry><refentrytitle>systemd-measure</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+          will be used.</para>
+
+          <para>On the command line, when this argument is present, it must appear the same number of times as
+          the <option>--pcr-private-key=</option> option. </para>
+
+          <xi:include href="version-info.xml" xpointer="v253"/></listitem>
+        </varlistentry>
+      </variablelist>
+    </refsect2>
+  </refsect1>
+
+  <refsect1>
+    <title>Examples</title>
+
+    <example>
+      <title>Minimal invocation</title>
+
+      <programlisting>$ ukify build \
+      --linux=/lib/modules/6.0.9-300.fc37.x86_64/vmlinuz \
+      --initrd=/some/path/initramfs-6.0.9-300.fc37.x86_64.img \
+      --cmdline='quiet rw'
+      </programlisting>
+
+      <para>This creates an unsigned UKI <filename>./vmlinuz.unsigned.efi</filename>.</para>
+    </example>
+
+    <example>
+      <title>All the bells and whistles</title>
+
+      <programlisting>$ ukify build \
+      --linux=/lib/modules/6.0.9-300.fc37.x86_64/vmlinuz \
+      --initrd=early_cpio \
+      --initrd=/some/path/initramfs-6.0.9-300.fc37.x86_64.img \
+      --sbat='sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
+      uki.author.myimage,1,UKI for System,uki.author.myimage,1,https://www.freedesktop.org/software/systemd/man/systemd-stub.html' \
+      --pcr-private-key=pcr-private-initrd-key.pem \
+      --pcr-public-key=pcr-public-initrd-key.pem \
+      --phases='enter-initrd' \
+      --pcr-private-key=pcr-private-system-key.pem \
+      --pcr-public-key=pcr-public-system-key.pem \
+      --phases='enter-initrd:leave-initrd enter-initrd:leave-initrd:sysinit \
+                enter-initrd:leave-initrd:sysinit:ready' \
+      --pcr-banks=sha384,sha512 \
+      --secureboot-private-key=sb.key \
+      --secureboot-certificate=sb.cert \
+      --sign-kernel \
+      --cmdline='quiet rw rhgb'
+      </programlisting>
+
+      <para>This creates a signed UKI <filename index='false'>./vmlinuz.signed.efi</filename>.
+      The initrd section contains two concatenated parts, <filename index='false'>early_cpio</filename>
+      and <filename index='false'>initramfs-6.0.9-300.fc37.x86_64.img</filename>.
+      The policy embedded in the <literal>.pcrsig</literal> section will be signed for the initrd (the
+      <constant>enter-initrd</constant> phase) with the key
+      <filename index='false'>pcr-private-initrd-key.pem</filename>, and for the main system (phases
+      <constant>leave-initrd</constant>, <constant>sysinit</constant>, <constant>ready</constant>) with the
+      key <filename index='false'>pcr-private-system-key.pem</filename>. The Linux binary and the resulting
+      combined image will be signed with the SecureBoot key <filename index='false'>sb.key</filename>.</para>
+    </example>
+
+    <example>
+      <title>All the bells and whistles, via a config file</title>
+
+      <para>This is the same as the previous example, but this time the configuration is stored in a
+      file:</para>
+
+      <programlisting>$ cat ukify.conf
+[UKI]
+Initrd=early_cpio
+Cmdline=quiet rw rhgb
+
+SecureBootPrivateKey=sb.key
+SecureBootCertificate=sb.cert
+SignKernel=yes
+PCRBanks=sha384,sha512
+
+[PCRSignature:initrd]
+PCRPrivateKey=pcr-private-initrd-key.pem
+PCRPublicKey=pcr-public-initrd-key.pem
+Phases=enter-initrd
+
+[PCRSignature:system]
+PCRPrivateKey=pcr-private-system-key.pem
+PCRPublicKey=pcr-public-system-key.pem
+Phases=enter-initrd:leave-initrd
+       enter-initrd:leave-initrd:sysinit
+       enter-initrd:leave-initrd:sysinit:ready
+
+$ ukify -c ukify.conf build \
+        --linux=/lib/modules/6.0.9-300.fc37.x86_64/vmlinuz \
+        --initrd=/some/path/initramfs-6.0.9-300.fc37.x86_64.img
+      </programlisting>
+
+      <para>One "initrd" (<filename index='false'>early_cpio</filename>) is specified in the config file, and
+      the other initrd (<filename index='false'>initramfs-6.0.9-300.fc37.x86_64.img</filename>) is specified
+      on the command line. This may be useful for example when the first initrd contains microcode for the CPU
+      and does not need to be updated when the kernel version changes, unlike the actual initrd.</para>
+    </example>
+
+    <example>
+      <title>Kernel command line auxiliary PE</title>
+
+      <programlisting>ukify build \
+      --secureboot-private-key=sb.key \
+      --secureboot-certificate=sb.cert \
+      --cmdline='debug' \
+      --sbat='sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
+      uki.addon.author,1,UKI Addon for System,uki.addon.author,1,https://www.freedesktop.org/software/systemd/man/systemd-stub.html'
+      --output=debug.cmdline
+      </programlisting>
+
+      <para>This creates a signed PE binary that contains the additional kernel command line parameter
+      <literal>debug</literal> with SBAT metadata referring to the owner of the addon.</para>
+    </example>
+
+    <example>
+      <title>Decide signing policy and create certificate and keys</title>
+
+      <para>First, let's create an config file that specifies what signatures shall be made:</para>
+
+      <programlisting># cat >/etc/kernel/uki.conf &lt;&lt;EOF
+<xi:include href="uki.conf.example" parse="text" />EOF</programlisting>
+
+      <para>Next, we can generate the certificate and keys:</para>
+      <programlisting># ukify genkey --config=/etc/kernel/uki.conf
+Writing SecureBoot private key to /etc/kernel/secure-boot.key.pem
+Writing SecureBoot certificate to /etc/kernel/secure-boot.cert.pem
+Writing private key for PCR signing to /etc/kernel/pcr-initrd.key.pem
+Writing public key for PCR signing to /etc/kernel/pcr-initrd.pub.pem
+Writing private key for PCR signing to /etc/kernel/pcr-system.key.pem
+Writing public key for PCR signing to /etc/kernel/pcr-system.pub.pem
+</programlisting>
+
+      <para>(Both operations need to be done as root to allow write access
+      to <filename>/etc/kernel/</filename>.)</para>
+
+      <para>Subsequent invocations using the config file
+      (<command>ukify build --config=/etc/kernel/uki.conf</command>)
+      will use this certificate and key files. Note that the
+      <citerefentry><refentrytitle>kernel-install</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+      plugin <filename>60-ukify.install</filename> uses <filename>/etc/kernel/uki.conf</filename>
+      by default, so after this file has been created, installations of kernels that create a UKI on the
+      local machine using <command>kernel-install</command> will perform signing using this config.</para>
+    </example>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-stub</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-boot</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-measure</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-pcrphase.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+     </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/user-system-options.xml b/man/user-system-options.xml
new file mode 100644
index 0000000..f3bafae
--- /dev/null
+++ b/man/user-system-options.xml
@@ -0,0 +1,58 @@
+<?xml version="1.0"?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<variablelist>
+  <varlistentry id='user'>
+    <term><option>--user</option></term>
+
+    <listitem id='user-text'>
+      <para>Talk to the service manager of the calling user,
+      rather than the service manager of the system.</para>
+    </listitem>
+  </varlistentry>
+
+  <varlistentry id='system'>
+    <term><option>--system</option></term>
+
+    <listitem id='system-text'>
+      <para>Talk to the service manager of the system. This is the
+      implied default.</para>
+    </listitem>
+  </varlistentry>
+
+  <varlistentry id='host'>
+    <term><option>-H</option></term>
+    <term><option>--host=</option></term>
+
+    <listitem id='host-text'>
+      <para>Execute the operation remotely. Specify a hostname, or a
+      username and hostname separated by <literal>@</literal>, to
+      connect to. The hostname may optionally be suffixed by a
+      port ssh is listening on, separated by <literal>:</literal>, and then a
+      container name, separated by <literal>/</literal>, which
+      connects directly to a specific container on the specified
+      host. This will use SSH to talk to the remote machine manager
+      instance. Container names may be enumerated with
+      <command>machinectl -H
+      <replaceable>HOST</replaceable></command>. Put IPv6 addresses in brackets.</para>
+    </listitem>
+  </varlistentry>
+
+  <varlistentry id='machine'>
+    <term><option>-M</option></term>
+    <term><option>--machine=</option></term>
+
+    <listitem id='machine-text'>
+      <para>Execute operation on a local container. Specify a container name to connect to, optionally
+      prefixed by a user name to connect as and a separating <literal>@</literal> character. If the special
+      string <literal>.host</literal> is used in place of the container name, a connection to the local
+      system is made (which is useful to connect to a specific user's user bus: <literal>--user
+      --machine=lennart@.host</literal>). If the <literal>@</literal> syntax is not used, the connection is
+      made as root user. If the <literal>@</literal> syntax is used either the left hand side or the right hand
+      side may be omitted (but not both) in which case the local user name and <literal>.host</literal> are
+      implied.</para>
+    </listitem>
+  </varlistentry>
+</variablelist>
diff --git a/man/user@.service.xml b/man/user@.service.xml
new file mode 100644
index 0000000..0cf7f02
--- /dev/null
+++ b/man/user@.service.xml
@@ -0,0 +1,194 @@
+<?xml version="1.0"?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="user@.service">
+  <refentryinfo>
+    <title>user@.service</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>user@.service</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>user@.service</refname>
+    <refname>user-runtime-dir@.service</refname>
+    <refname>systemd-user-runtime-dir</refname>
+    <refpurpose>System units to start the user manager</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>user@<replaceable>UID</replaceable>.service</filename></para>
+    <para><filename>user-runtime-dir@<replaceable>UID</replaceable>.service</filename></para>
+    <para><filename>/usr/lib/systemd/systemd-user-runtime-dir</filename></para>
+    <para><filename>user-<replaceable>UID</replaceable>.slice</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>The <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    system manager (PID 1) starts user manager instances as
+    <filename>user@<replaceable>UID</replaceable>.service</filename>, with the user's numerical UID used as
+    the instance identifier. These instances use the same executable as the system manager, but running in a
+    mode where it starts a different set of units. Each <command>systemd --user</command> instance manages a
+    hierarchy of units specific to that user. See
+    <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> for a
+    discussion of units and
+    <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry> for a
+    list of units that form the basis of the unit hierarchies of system and user units.</para>
+
+    <para><filename>user@<replaceable>UID</replaceable>.service</filename> is accompanied by the
+    system unit <filename>user-runtime-dir@<replaceable>UID</replaceable>.service</filename>, which
+    creates the user's runtime directory
+    <filename>/run/user/<replaceable>UID</replaceable></filename>, and then removes it when this
+    unit is stopped. <filename>user-runtime-dir@<replaceable>UID</replaceable>.service</filename>
+    executes the <filename>systemd-user-runtime-dir</filename> binary to do the actual work.</para>
+
+    <para>User processes may be started by the <filename>user@.service</filename> instance, in which
+    case they will be part of that unit in the system hierarchy. They may also be started elsewhere,
+    for example by
+    <citerefentry project='die-net'><refentrytitle>sshd</refentrytitle><manvolnum>8</manvolnum></citerefentry> or a
+    display manager like <command>gdm</command>, in which case they form a .scope unit (see
+    <citerefentry><refentrytitle>systemd.scope</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
+    Both <filename>user@<replaceable>UID</replaceable>.service</filename> and the scope units are
+    collected under the <filename>user-<replaceable>UID</replaceable>.slice</filename>.</para>
+
+    <para>Individual <filename>user-<replaceable>UID</replaceable>.slice</filename> slices are
+    collected under <filename>user.slice</filename>, see
+    <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
+    </para>
+  </refsect1>
+
+  <refsect1>
+    <title>Controlling resources for logged-in users</title>
+
+    <para>Options that control resources available to logged-in users can be configured at a few
+    different levels. As described in the previous section, <filename>user.slice</filename> contains
+    processes of all users, so any resource limits on that slice apply to all users together. The
+    usual way to configure them would be through drop-ins, e.g. <filename
+    index="false">/etc/systemd/system/user.slice.d/resources.conf</filename>.
+    </para>
+
+    <para>The processes of a single user are collected under
+    <filename>user-<replaceable>UID</replaceable>.slice</filename>. Resource limits for that user
+    can be configured through drop-ins for that unit, e.g. <filename
+    index="false">/etc/systemd/system/user-1000.slice.d/resources.conf</filename>. If the limits
+    should apply to all users instead, they may be configured through drop-ins for the truncated
+    unit name, <filename>user-.slice</filename>. For example, configuration in <filename
+    index="false">/etc/systemd/system/user-.slice.d/resources.conf</filename> is included in all
+    <filename>user-<replaceable>UID</replaceable>.slice</filename> units, see
+    <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for a discussion of the drop-in mechanism.</para>
+
+    <para>When a user logs in and a .scope unit is created for the session (see previous section),
+    the creation of the scope may be managed through
+    <citerefentry><refentrytitle>pam_systemd</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+    This PAM module communicates with
+    <citerefentry><refentrytitle>systemd-logind</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    to create the session scope and provide access to hardware resources. Resource limits for the
+    scope may be configured through the PAM module configuration, see
+    <citerefentry><refentrytitle>pam_systemd</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+    Configuring them through the normal unit configuration is also possible, but since
+    the name of the slice unit is generally unpredictable, this is less useful.</para>
+
+    <para>In general any resources that apply to units may be set for
+    <filename>user@<replaceable>UID</replaceable>.service</filename> and the slice
+    units discussed above, see
+    <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+    for an overview.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Examples</title>
+    <example>
+      <title>Hierarchy of control groups with two logged in users</title>
+
+      <programlisting>$ systemd-cgls
+Control group /:
+-.slice
+├─user.slice
+│ ├─user-1000.slice
+│ │ ├─user@1000.service
+│ │ │ ├─pulseaudio.service
+│ │ │ │ └─2386 /usr/bin/pulseaudio --daemonize=no
+│ │ │ └─gnome-terminal-server.service
+│ │ │   └─init.scope
+│ │ │     ├─ 4127 /usr/libexec/gnome-terminal-server
+│ │ │     └─ 4198 zsh
+│ │ …
+│ │ └─session-4.scope
+│ │   ├─ 1264 gdm-session-worker [pam/gdm-password]
+│ │   ├─ 2339 /usr/bin/gnome-shell
+│ │   …
+│ │ ├─session-19.scope
+│ │   ├─6497 sshd: zbyszek [priv]
+│ │   ├─6502 sshd: zbyszek@pts/6
+│ │   ├─6509 -zsh
+│ │   └─6602 systemd-cgls --no-pager
+│ …
+│ └─user-1001.slice
+│   ├─session-20.scope
+│   │ ├─6675 sshd: guest [priv]
+│   │ ├─6708 sshd: guest@pts/6
+│   │ └─6717 -bash
+│   └─user@1001.service
+│     ├─init.scope
+│     │ ├─6680 /usr/lib/systemd/systemd --user
+│     │ └─6688 (sd-pam)
+│     └─sleep.service
+│       └─6706 /usr/bin/sleep 30
+…</programlisting>
+      <para>User with UID 1000 is logged in using <command>gdm</command> (<filename
+      index="false">session-4.scope</filename>) and
+      <citerefentry project='die-net'><refentrytitle>ssh</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+      (<filename index="false">session-19.scope</filename>), and also has a user manager instance
+      running (<filename index="false">user@1000.service</filename>).  User with UID 1001 is logged
+      in using <command>ssh</command> (<filename index="false">session-20.scope</filename>) and
+      also has a user manager instance running (<filename
+      index="false">user@1001.service</filename>).  Those are all (leaf) system units, and form
+      part of the slice hierarchy, with <filename index="false">user-1000.slice</filename> and
+      <filename index="false">user-1001.slice</filename> below <filename
+      index="false">user.slice</filename>.  User units are visible below the
+      <filename>user@.service</filename> instances (<filename
+      index="false">pulseaudio.service</filename>, <filename
+      index="false">gnome-terminal-server.service</filename>, <filename
+      index="false">init.scope</filename>, <filename index="false">sleep.service</filename>).
+      </para>
+    </example>
+
+    <example>
+      <title>Default user resource limits</title>
+
+      <programlisting>$ systemctl cat user-1000.slice
+# /usr/lib/systemd/system/user-.slice.d/10-defaults.conf
+# …
+[Unit]
+Description=User Slice of UID %j
+After=systemd-user-sessions.service
+
+[Slice]
+TasksMax=33%</programlisting>
+     <para>The <filename>user-<replaceable>UID</replaceable>.slice</filename> units by default don't
+     have a unit file. The resource limits are set through a drop-in, which can be easily replaced
+     or extended following standard drop-in mechanisms discussed in the first section.</para>
+    </example>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>pam</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+</refentry>
diff --git a/man/userdbctl.xml b/man/userdbctl.xml
new file mode 100644
index 0000000..c3b1a10
--- /dev/null
+++ b/man/userdbctl.xml
@@ -0,0 +1,390 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="userdbctl" conditional='ENABLE_USERDB'
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>userdbctl</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>userdbctl</refentrytitle>
+    <manvolnum>1</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>userdbctl</refname>
+    <refpurpose>Inspect users, groups and group memberships</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <cmdsynopsis>
+      <command>userdbctl</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="req">COMMAND</arg>
+      <arg choice="opt" rep="repeat">NAME</arg>
+    </cmdsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>userdbctl</command> may be used to inspect user and groups (as well as group memberships)
+    of the system. This client utility inquires user/group information provided by various system services,
+    both operating on JSON user/group records (as defined by the <ulink
+    url="https://systemd.io/USER_RECORD">JSON User Records</ulink> and <ulink
+    url="https://systemd.io/GROUP_RECORD">JSON Group Records</ulink> definitions), and classic UNIX NSS/glibc
+    user and group records. This tool is primarily a client to the <ulink
+    url="https://systemd.io/USER_GROUP_API">User/Group Record Lookup API via Varlink</ulink>, and may also
+    pick up drop-in JSON user and group records from <filename>/etc/userdb/</filename>,
+    <filename>/run/userdb/</filename>, <filename>/run/host/userdb/</filename>,
+    <filename>/usr/lib/userdb/</filename>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>The following options are understood:</para>
+
+    <variablelist>
+
+      <varlistentry>
+        <term><option>--output=</option><replaceable>MODE</replaceable></term>
+
+        <listitem><para>Choose the output mode, takes one of <literal>classic</literal>,
+        <literal>friendly</literal>, <literal>table</literal>, <literal>json</literal>. If
+        <literal>classic</literal>, an output very close to the format of <filename>/etc/passwd</filename> or
+        <filename>/etc/group</filename> is generated. If <literal>friendly</literal> a more comprehensive and
+        user friendly, human readable output is generated; if <literal>table</literal> a minimal, tabular
+        output is generated; if <literal>json</literal> a JSON formatted output is generated. Defaults to
+        <literal>friendly</literal> if a user/group is specified on the command line,
+        <literal>table</literal> otherwise.</para>
+
+        <para>Note that most output formats do not show all available information. In particular,
+        <literal>classic</literal> and <literal>table</literal> show only the most important fields. Various
+        modes also do not show password hashes. Use <literal>json</literal> to view all fields, including
+        any authentication fields.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--json=</option><replaceable>FORMAT</replaceable></term>
+
+        <listitem><para>Selects JSON output mode (like <option>--output=json</option>) and selects the
+        precise display mode. Takes one of <literal>pretty</literal> or <literal>short</literal>. If
+        <literal>pretty</literal>, human-friendly whitespace and newlines are inserted in the output to make
+        the JSON data more readable. If <literal>short</literal>, all superfluous whitespace is
+        suppressed.</para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--service=</option><replaceable>SERVICE</replaceable><optional>:<replaceable>SERVICE…</replaceable></optional></term>
+        <term><option>-s</option> <replaceable>SERVICE</replaceable>:<replaceable>SERVICE…</replaceable></term>
+
+        <listitem><para>Controls which services to query for users/groups. Takes a list of one or more
+        service names, separated by <literal>:</literal>. See below for a list of well-known service
+        names. If not specified all available services are queried at once.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--with-nss=</option><replaceable>BOOL</replaceable></term>
+
+        <listitem><para>Controls whether to include classic glibc/NSS user/group lookups in the output. If
+        <option>--with-nss=no</option> is used any attempts to resolve or enumerate users/groups provided
+        only via glibc NSS is suppressed. If <option>--with-nss=yes</option> is specified such users/groups
+        are included in the output (which is the default).</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--with-varlink=</option><replaceable>BOOL</replaceable></term>
+
+        <listitem><para>Controls whether to include Varlink user/group lookups in the output, i.e. those done
+        via the <ulink url="https://systemd.io/USER_GROUP_API">User/Group Record Lookup API via
+        Varlink</ulink>. If <option>--with-varlink=no</option> is used any attempts to resolve or enumerate
+        users/groups provided only via Varlink are suppressed. If <option>--with-varlink=yes</option> is
+        specified such users/groups are included in the output (which is the default).</para>
+
+        <xi:include href="version-info.xml" xpointer="v249"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--with-dropin=</option><replaceable>BOOL</replaceable></term>
+
+        <listitem><para>Controls whether to include user/group lookups in the output that are defined using
+        drop-in files in <filename>/etc/userdb/</filename>, <filename>/run/userdb/</filename>,
+        <filename>/run/host/userdb/</filename>, <filename>/usr/lib/userdb/</filename>. If
+        <option>--with-dropin=no</option> is used these records are suppressed. If
+        <option>--with-dropin=yes</option> is specified such users/groups are included in the output (which
+        is the default).</para>
+
+        <xi:include href="version-info.xml" xpointer="v249"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--synthesize=</option><replaceable>BOOL</replaceable></term>
+
+        <listitem><para>Controls whether to synthesize records for the root and nobody users/groups if they
+        aren't defined otherwise. By default (or <literal>yes</literal>) such records are implicitly
+        synthesized if otherwise missing since they have special significance to the OS. When
+        <literal>no</literal> this synthesizing is turned off.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-N</option></term>
+
+        <listitem><para>This option is short for <option>--with-nss=no</option>
+        <option>--synthesize=no</option>. Use this option to show only records that are natively defined as
+        JSON user or group records, with all NSS/glibc compatibility and all implicit synthesis turned
+        off.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--multiplexer=</option><replaceable>BOOL</replaceable></term>
+
+        <listitem><para>Controls whether to do lookups via the multiplexer service (if specified as true, the
+        default) or do lookups in the client (if specified as false). Using the multiplexer service is
+        typically preferable, since it runs in a locked down sandbox.</para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--chain</option></term>
+
+        <listitem><para>When used with the <command>ssh-authorized-keys</command> command, this will allow
+        passing an additional command line after the user name that is chain executed after the lookup
+        completed. This allows chaining multiple tools that show SSH authorized keys.</para>
+
+        <xi:include href="version-info.xml" xpointer="v250"/></listitem>
+      </varlistentry>
+
+      <xi:include href="standard-options.xml" xpointer="no-pager" />
+      <xi:include href="standard-options.xml" xpointer="no-legend" />
+      <xi:include href="standard-options.xml" xpointer="help" />
+      <xi:include href="standard-options.xml" xpointer="version" />
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Commands</title>
+
+    <para>The following commands are understood:</para>
+
+    <variablelist>
+
+      <varlistentry>
+        <term><command>user</command> <optional><replaceable>USER</replaceable>…</optional></term>
+
+        <listitem><para>List all known users records or show details of one or more specified user
+        records. Use <option>--output=</option> to tweak output mode.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>group</command> <optional><replaceable>GROUP</replaceable>…</optional></term>
+
+        <listitem><para>List all known group records or show details of one or more specified group
+        records. Use <option>--output=</option> to tweak output mode.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>users-in-group</command> <optional><replaceable>GROUP</replaceable>…</optional></term>
+
+        <listitem><para>List users that are members of the specified groups. If no groups are specified list
+        all user/group memberships defined. Use <option>--output=</option> to tweak output
+        mode.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>groups-of-user</command> <optional><replaceable>USER</replaceable>…</optional></term>
+
+        <listitem><para>List groups that the specified users are members of. If no users are specified list
+        all user/group memberships defined (in this case <command>groups-of-user</command> and
+        <command>users-in-group</command> are equivalent). Use <option>--output=</option> to tweak output
+        mode.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>services</command></term>
+
+        <listitem><para>List all services currently providing user/group definitions to the system. See below
+        for a list of well-known services providing user information.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>ssh-authorized-keys</command></term>
+
+        <listitem><para>Show SSH authorized keys for this account. This command is intended to be used to
+        allow the SSH daemon to pick up authorized keys from user records, see below.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Well-Known Services</title>
+
+    <para>The <command>userdbctl services</command> command will list all currently running services that
+    provide user or group definitions to the system. The following well-known services are shown among
+    this list:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><constant>io.systemd.DynamicUser</constant></term>
+
+        <listitem><para>This service is provided by the system service manager itself (i.e. PID 1) and
+        makes all users (and their groups) synthesized through the <varname>DynamicUser=</varname> setting in
+        service unit files available to the system (see
+        <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
+        details about this setting).</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><constant>io.systemd.Home</constant></term>
+
+        <listitem><para>This service is provided by
+        <citerefentry><refentrytitle>systemd-homed.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        and makes all users (and their groups) belonging to home directories managed by that service
+        available to the system.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><constant>io.systemd.Machine</constant></term>
+
+        <listitem><para>This service is provided by
+        <citerefentry><refentrytitle>systemd-machined.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        and synthesizes records for all users/groups used by a container that employs user
+        namespacing.</para>
+
+        <xi:include href="version-info.xml" xpointer="v246"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><constant>io.systemd.Multiplexer</constant></term>
+
+        <listitem><para>This service is provided by
+        <citerefentry><refentrytitle>systemd-userdbd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        and multiplexes user/group look-ups to all other running lookup services. This is the primary entry point
+        for user/group record clients, as it simplifies client side implementation substantially since they
+        can ask a single service for lookups instead of asking all running services in parallel.
+        <command>userdbctl</command> uses this service preferably, too, unless <option>--with-nss=</option>
+        or <option>--service=</option> are used, in which case finer control over the services to talk to is
+        required.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><constant>io.systemd.NameServiceSwitch</constant></term>
+
+        <listitem><para>This service is (also) provided by
+        <citerefentry><refentrytitle>systemd-userdbd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        and converts classic NSS/glibc user and group records to JSON user/group records, providing full
+        backwards compatibility. Use <option>--with-nss=no</option> to disable this compatibility, see
+        above. Note that compatibility is actually provided in both directions:
+        <citerefentry><refentrytitle>nss-systemd</refentrytitle><manvolnum>8</manvolnum></citerefentry> will
+        automatically synthesize classic NSS/glibc user/group records from all JSON user/group records
+        provided to the system, thus using both APIs is mostly equivalent and provides access to the same
+        data, however the NSS/glibc APIs necessarily expose a more reduced set of fields
+        only.</para>
+
+        <xi:include href="version-info.xml" xpointer="v245"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><constant>io.systemd.DropIn</constant></term>
+
+        <listitem><para>This service is (also) provided by
+        <citerefentry><refentrytitle>systemd-userdbd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+        and picks up JSON user/group records from <filename>/etc/userdb/</filename>,
+        <filename>/run/userdb/</filename>, <filename>/run/host/userdb/</filename>,
+        <filename>/usr/lib/userdb/</filename>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v249"/></listitem>
+      </varlistentry>
+
+    </variablelist>
+
+    <para>Note that <command>userdbctl</command> has internal support for NSS-based lookups too. This means
+    that if neither <constant>io.systemd.Multiplexer</constant> nor
+    <constant>io.systemd.NameServiceSwitch</constant> are running look-ups into the basic user/group
+    databases will still work.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Integration with SSH</title>
+
+    <para>The <command>userdbctl</command> tool may be used to make the list of SSH authorized keys possibly
+    contained in a user record available to the SSH daemon for authentication. For that configure the
+    following in <citerefentry
+    project='die-net'><refentrytitle>sshd_config</refentrytitle><manvolnum>5</manvolnum></citerefentry>:</para>
+
+    <programlisting>…
+AuthorizedKeysCommand /usr/bin/userdbctl ssh-authorized-keys %u
+AuthorizedKeysCommandUser root
+…</programlisting>
+
+    <para>Sometimes it's useful to allow chain invocation of another program to list SSH authorized keys. By
+    using the <option>--chain</option> such a tool may be chain executed by <command>userdbctl
+    ssh-authorized-keys</command> once a lookup completes (regardless if an SSH key was found or
+    not). Example:</para>
+
+    <programlisting>…
+AuthorizedKeysCommand /usr/bin/userdbctl ssh-authorized-keys %u --chain /usr/bin/othertool %u
+AuthorizedKeysCommandUser root
+…</programlisting>
+
+    <para>The above will first query the userdb database for SSH keys, and then chain execute
+    <command>/usr/bin/othertool</command> to also be queried.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Exit status</title>
+
+    <para>On success, 0 is returned, a non-zero failure code otherwise.</para>
+  </refsect1>
+
+  <xi:include href="common-variables.xml" />
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-userdbd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-homed.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>nss-systemd</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>getent</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/varlinkctl.xml b/man/varlinkctl.xml
new file mode 100644
index 0000000..7dec54c
--- /dev/null
+++ b/man/varlinkctl.xml
@@ -0,0 +1,315 @@
+<?xml version='1.0'?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="varlinkctl"
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>varlinkctl</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>varlinkctl</refentrytitle>
+    <manvolnum>1</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>varlinkctl</refname>
+    <refpurpose>Introspect with and invoke Varlink services</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <cmdsynopsis>
+      <command>varlinkctl</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="plain">info</arg>
+      <arg choice="plain"><replaceable>ADDRESS</replaceable></arg>
+    </cmdsynopsis>
+
+    <cmdsynopsis>
+      <command>varlinkctl</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="plain">list-interfaces</arg>
+      <arg choice="plain"><replaceable>ADDRESS</replaceable></arg>
+    </cmdsynopsis>
+
+    <cmdsynopsis>
+      <command>varlinkctl</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="plain">introspect</arg>
+      <arg choice="plain"><replaceable>ADDRESS</replaceable></arg>
+      <arg choice="plain"><replaceable>INTERFACE</replaceable></arg>
+    </cmdsynopsis>
+
+    <cmdsynopsis>
+      <command>varlinkctl</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="plain">call</arg>
+      <arg choice="plain"><replaceable>ADDRESS</replaceable></arg>
+      <arg choice="plain"><replaceable>METHOD</replaceable></arg>
+      <arg choice="opt"><replaceable>PARAMETERS</replaceable></arg>
+    </cmdsynopsis>
+
+    <cmdsynopsis>
+      <command>varlinkctl</command>
+      <arg choice="opt" rep="repeat">OPTIONS</arg>
+      <arg choice="plain">validate-idl</arg>
+      <arg choice="opt"><replaceable>FILE</replaceable></arg>
+    </cmdsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para><command>varlinkctl</command> may be used to introspect and invoke <ulink
+    url="https://varlink.org/">Varlink</ulink> services.</para>
+
+    <para>Services are referenced by one of the following:</para>
+
+    <itemizedlist>
+      <listitem><para>A Varlink service reference starting with the <literal>unix:</literal> string, followed
+      by an absolute <constant>AF_UNIX</constant> path, or by <literal>@</literal> and an arbitrary string
+      (the latter for referencing sockets in the abstract namespace).</para></listitem>
+
+      <listitem><para>A Varlink service reference starting with the <literal>exec:</literal> string, followed
+      by an absolute path of a binary to execute.</para></listitem>
+    </itemizedlist>
+
+    <para>For convenience these two simpler (redundant) service address syntaxes are also supported:</para>
+
+    <itemizedlist>
+      <listitem><para>A file system path to an <constant>AF_UNIX</constant> socket, either absolute
+      (i.e. begins with <literal>/</literal>) or relative (in which case it must begin with
+      <literal>./</literal>).</para></listitem>
+
+      <listitem><para>A file system path to an executable, either absolute or relative (as above, must begin
+      with <literal>/</literal>, resp. <literal>./</literal>).</para></listitem>
+    </itemizedlist>
+  </refsect1>
+
+  <refsect1>
+    <title>Commands</title>
+
+    <para>The following commands are understood:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><command>info</command> <replaceable>ADDRESS</replaceable></term>
+
+        <listitem><para>Show brief information about the specified service, including vendor name and list of
+        implemented interfaces. Expects a service address in the formats described above.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>list-interfaces</command> <replaceable>ADDRESS</replaceable></term>
+
+        <listitem><para>Show list of interfaces implemented by the specified service. Expects a service
+        address in the formats described above.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>introspect</command> <replaceable>ADDRESS</replaceable> <replaceable>INTERFACE</replaceable></term>
+
+        <listitem><para>Show interface definition of the specified interface provided by the specified
+        service. Expects a service address in the formats described above and a Varlink interface
+        name.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>call</command> <replaceable>ADDRESS</replaceable> <replaceable>METHOD</replaceable> [<replaceable>ARGUMENTS</replaceable>]</term>
+
+        <listitem><para>Call the specified method of the specified service. Expects a service address in the
+        format described above, a fully qualified Varlink method name, and a JSON arguments object. If the
+        arguments object is not specified, it is read from STDIN instead. To pass an empty list of
+        parameters, specify the empty object <literal>{}</literal>.</para>
+
+        <para>The reply parameters are written as JSON object to STDOUT.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>validate-idl</command> [<replaceable>FILE</replaceable>]</term>
+
+        <listitem><para>Reads a Varlink interface definition file, parses and validates it, then outputs it
+        with syntax highlighting. This checks for syntax and internal consistency of the interface. Expects a
+        file name to read the interface definition from. If omitted reads the interface definition from
+        STDIN.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><command>help</command></term>
+
+        <listitem><para>Show command syntax help.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>The following options are understood:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term><option>--more</option></term>
+
+        <listitem><para>When used with <command>call</command>: expect multiple method replies. If this flag is
+        set the method call is sent with the <constant>more</constant> flag set, which tells the service to
+        generate multiple replies, if needed. The command remains running until the service sends a reply
+        message that indicates it is the last in the series. This flag should be set only for method calls
+        that support this mechanism.</para>
+
+        <para>If this mode is enabled output is automatically switched to JSON-SEQ mode, so that individual
+        reply objects can be easily discerned.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--oneway</option></term>
+
+        <listitem><para>When used with <command>call</command>: do not expect a method reply. If this flag
+        is set the method call is sent with the <constant>oneway</constant> flag set (the command exits
+        immediately after), which tells the service not to generate a reply.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>--json=</option><replaceable>MODE</replaceable></term>
+
+        <listitem>
+          <para>Selects the JSON output formatting, one of <literal>pretty</literal> (for nicely indented,
+          colorized output) or <literal>short</literal> (for terse output with minimal whitespace and no
+          newlines), defaults to <literal>short</literal>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>-j</option></term>
+
+        <listitem>
+          <para>Equivalent to <option>--json=pretty</option> when invoked interactively from a terminal. Otherwise
+          equivalent to <option>--json=short</option>, in particular when the output is piped to some other
+          program.</para>
+
+        <xi:include href="version-info.xml" xpointer="v255"/>
+        </listitem>
+      </varlistentry>
+
+      <xi:include href="standard-options.xml" xpointer="no-pager" />
+      <xi:include href="standard-options.xml" xpointer="help" />
+      <xi:include href="standard-options.xml" xpointer="version" />
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Examples</title>
+
+    <example>
+      <title>Investigating a Service</title>
+
+      <para>The following three commands inspect the <literal>io.systemd.Resolve</literal> service
+      implemented by
+      <citerefentry><refentrytitle>systemd-resolved.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      listing general service information and implemented interfaces, and then displaying the interface
+      definition of its primary interface:</para>
+
+      <programlisting>$ varlinkctl info /run/systemd/resolve/io.systemd.Resolve
+    Vendor: The systemd Project
+   Product: systemd (systemd-resolved)
+   Version: 254 (254-1522-g4790521^)
+       URL: https://systemd.io/
+Interfaces: io.systemd
+            io.systemd.Resolve
+            org.varlink.service
+$ varlinkctl list-interfaces /run/systemd/resolve/io.systemd.Resolve
+io.systemd
+io.systemd.Resolve
+org.varlink.service
+$ varlinkctl introspect /run/systemd/resolve/io.systemd.Resolve io.systemd.Resolve
+interface io.systemd.Resolve
+type ResolvedAddress(
+        ifindex: ?int,
+        …</programlisting>
+
+    <para>(Interface definition has been truncated in the example above, in the interest of brevity.)</para>
+    </example>
+
+    <example>
+      <title>Invoking a Method</title>
+
+      <para>The following command resolves a hostname via <citerefentry><refentrytitle>systemd-resolved.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>'s <function>ResolveHostname</function>  method call.</para>
+
+      <programlisting>$ varlinkctl call /run/systemd/resolve/io.systemd.Resolve io.systemd.Resolve.ResolveHostname '{"name":"systemd.io","family":2}' -j
+{
+        "addresses" : [
+                {
+                        "ifindex" : 2,
+                        "family" : 2,
+                        "address" : [
+                                185,
+                                199,
+                                111,
+                                153
+                        ]
+                }
+        ],
+        "name" : "systemd.io",
+        "flags" : 1048577
+}</programlisting>
+    </example>
+
+    <example>
+      <title>Investigating a Service Executable</title>
+
+      <para>The following command inspects the <filename>/usr/lib/systemd/systemd-pcrextend</filename>
+      executable and the IPC APIs it provides. It then invokes a method on it:</para>
+
+      <programlisting># varlinkctl info /usr/lib/systemd/systemd-pcrextend
+    Vendor: The systemd Project
+   Product: systemd (systemd-pcrextend)
+   Version: 254 (254-1536-g97734fb)
+       URL: https://systemd.io/
+Interfaces: io.systemd
+            io.systemd.PCRExtend
+            org.varlink.service
+# varlinkctl introspect /usr/lib/systemd/systemd-pcrextend io.systemd.PCRExtend
+interface io.systemd.PCRExtend
+
+method Extend(
+        pcr: int,
+        text: ?string,
+        data: ?string
+) -> ()
+# varlinkctl call /usr/lib/systemd/systemd-pcrextend io.systemd.PCRExtend.Extend '{"pcr":15,"text":"foobar"}'
+{}</programlisting>
+    </example>
+
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+
+    <para>
+      <citerefentry><refentrytitle>busctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <ulink url="https://varlink.org/">Varlink</ulink>
+    </para>
+  </refsect1>
+</refentry>
diff --git a/man/vconsole.conf.xml b/man/vconsole.conf.xml
new file mode 100644
index 0000000..48001d3
--- /dev/null
+++ b/man/vconsole.conf.xml
@@ -0,0 +1,153 @@
+<?xml version='1.0'?> <!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [
+<!ENTITY % entities SYSTEM "custom-entities.ent" >
+%entities;
+]>
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refentry id="vconsole.conf" conditional='ENABLE_VCONSOLE'
+          xmlns:xi="http://www.w3.org/2001/XInclude">
+  <refentryinfo>
+    <title>vconsole.conf</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>vconsole.conf</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>vconsole.conf</refname>
+    <refpurpose>Configuration file for the virtual console</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>/etc/vconsole.conf</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>The <filename>/etc/vconsole.conf</filename> file configures
+    the virtual console, i.e. keyboard mapping and console font. It is
+    applied at boot by udev using <filename>90-vconsole.rules</filename> file.
+    You can safely mask this file if you want to avoid this kind of initialization.
+    </para>
+
+    <para>The format of <filename>vconsole.conf</filename> is a newline-separated list of environment-like
+    shell-compatible variable assignments, ignoring comments and empty lines. It is possible to source the
+    configuration from shell scripts, however, beyond mere variable assignments no shell features are
+    supported, allowing applications to read the file without implementing a shell compatible execution
+    engine. See
+    <citerefentry><refentrytitle>os-release</refentrytitle><manvolnum>5</manvolnum></citerefentry> for a
+    detailed description of the format.</para>
+
+    <para>Note that the kernel command line options
+    <varname>vconsole.keymap=</varname>,
+    <varname>vconsole.keymap_toggle=</varname>,
+    <varname>vconsole.font=</varname>,
+    <varname>vconsole.font_map=</varname>,
+    <varname>vconsole.font_unimap=</varname> may be used
+    to override the console settings at boot.</para>
+
+    <para>Depending on the operating system other configuration files
+    might be checked for configuration of the virtual console as well,
+    however only as fallback.</para>
+
+    <para><filename>/etc/vconsole.conf</filename> is usually created and updated
+    using
+    <citerefentry><refentrytitle>systemd-localed.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
+    <citerefentry><refentrytitle>localectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+    may be used to instruct <command>systemd-localed.service</command> to
+    query or update configuration.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Options</title>
+
+    <para>The following options are understood:</para>
+
+    <variablelist class='environment-variables'>
+
+      <varlistentry>
+        <term><varname>KEYMAP=</varname></term>
+        <term><varname>KEYMAP_TOGGLE=</varname></term>
+
+        <listitem><para>Configures the key mapping table for the keyboard.  <varname>KEYMAP=</varname>
+        defaults to <literal>&DEFAULT_KEYMAP;</literal> if not set. Specially, if <literal>@kernel</literal>
+        is specified, no keymap will be loaded, i.e. the kernel's default keymap is used.  The
+        <varname>KEYMAP_TOGGLE=</varname> can be used to configure a second toggle keymap and is by default
+        unset.</para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><varname>FONT=</varname></term>
+        <term><varname>FONT_MAP=</varname></term>
+        <term><varname>FONT_UNIMAP=</varname></term>
+
+        <listitem><para>Configures the console font, the console map
+        and the unicode font map.</para></listitem>
+      </varlistentry>
+
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Kernel Command Line</title>
+
+    <para>A few configuration parameters from <filename>vconsole.conf</filename> may be overridden
+    on the kernel command line:</para>
+
+    <variablelist class='kernel-commandline-options'>
+      <varlistentry>
+        <term><varname>vconsole.keymap=</varname></term>
+        <term><varname>vconsole.keymap_toggle=</varname></term>
+
+        <listitem><para>Overrides <varname>KEYMAP=</varname> and <varname>KEYMAP_TOGGLE=</varname>.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v232"/></listitem>
+      </varlistentry>
+      <varlistentry>
+
+        <term><varname>vconsole.font=</varname></term>
+        <term><varname>vconsole.font_map=</varname></term>
+        <term><varname>vconsole.font_unimap=</varname></term>
+
+        <listitem><para>Overrides <varname>FONT=</varname>, <varname>FONT_MAP=</varname>, and
+        <varname>FONT_UNIMAP=</varname>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v232"/></listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>Example</title>
+
+    <example>
+      <title>German keyboard and console</title>
+
+      <para><filename>/etc/vconsole.conf</filename>:</para>
+
+      <programlisting>KEYMAP=de-latin1
+FONT=eurlatgr</programlisting>
+    </example>
+
+  </refsect1>
+
+  <refsect1>
+      <title>See Also</title>
+      <para>
+        <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd-vconsole-setup.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+        <citerefentry project='mankier'><refentrytitle>loadkeys</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+        <citerefentry project='die-net'><refentrytitle>setfont</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+        <citerefentry project='man-pages'><refentrytitle>locale.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        <citerefentry><refentrytitle>systemd-localed.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+      </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/veritytab.xml b/man/veritytab.xml
new file mode 100644
index 0000000..bc9aa58
--- /dev/null
+++ b/man/veritytab.xml
@@ -0,0 +1,325 @@
+<?xml version="1.0"?>
+<!--*-nxml-*-->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!--
+  SPDX-License-Identifier: LGPL-2.1-or-later
+
+This is based on crypttab(5).
+
+-->
+<refentry id="veritytab" conditional='HAVE_LIBCRYPTSETUP' xmlns:xi="http://www.w3.org/2001/XInclude">
+
+  <refentryinfo>
+    <title>veritytab</title>
+    <productname>systemd</productname>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle>veritytab</refentrytitle>
+    <manvolnum>5</manvolnum>
+  </refmeta>
+
+  <refnamediv>
+    <refname>veritytab</refname>
+    <refpurpose>Configuration for verity block devices</refpurpose>
+  </refnamediv>
+
+  <refsynopsisdiv>
+    <para><filename>/etc/veritytab</filename></para>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>Description</title>
+
+    <para>The <filename>/etc/veritytab</filename> file describes
+    verity protected block devices that are set up during
+    system boot.</para>
+
+    <para>Empty lines and lines starting with the <literal>#</literal>
+    character are ignored. Each of the remaining lines describes one
+    verity protected block device. Fields are delimited by
+    white space.</para>
+
+    <para>Each line is in the form<programlisting><replaceable>volume-name</replaceable> <replaceable>data-device</replaceable> <replaceable>hash-device</replaceable> <replaceable>roothash</replaceable> <replaceable>options</replaceable></programlisting>
+    The first four fields are mandatory, the remaining one is optional.</para>
+
+    <para>The first field contains the name of the resulting verity volume; its block device is set up
+    below <filename>/dev/mapper/</filename>.</para>
+
+    <para>The second field contains a path to the underlying block data device, or a specification of a block device via
+    <literal>UUID=</literal> followed by the UUID.</para>
+
+    <para>The third field contains a path to the underlying block hash device, or a specification of a block device via
+    <literal>UUID=</literal> followed by the UUID.</para>
+
+    <para>The fourth field is the <literal>roothash</literal> in hexadecimal.</para>
+
+    <para>The fifth field, if present, is a comma-delimited list of options. The following options are
+    recognized:</para>
+
+    <variablelist class='fstab-options'>
+
+      <varlistentry>
+        <term><option>superblock=<replaceable>BOOL</replaceable></option></term>
+
+        <listitem><para>Use dm-verity with or without permanent on-disk superblock.</para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>format=<replaceable>NUMBER</replaceable></option></term>
+
+        <listitem><para>Specifies the hash version type. Format type 0 is original Chrome OS version. Format type 1 is
+        modern version.</para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>data-block-size=<replaceable>BYTES</replaceable></option></term>
+
+        <listitem><para>Used block size for the data device. (Note kernel supports only page-size as maximum
+        here; Multiples of 512 bytes.) </para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>hash-block-size=<replaceable>BYTES</replaceable></option></term>
+
+        <listitem><para>Used block size for the hash device. (Note kernel supports only page-size as maximum
+        here; Multiples of 512 bytes.)</para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>data-blocks=<replaceable>BLOCKS</replaceable></option></term>
+
+        <listitem><para>Number of blocks of data device used in verification. If not specified, the whole device is
+        used.</para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>hash-offset=<replaceable>BYTES</replaceable></option></term>
+
+        <listitem><para>Offset of hash area/superblock on <literal>hash-device</literal>. (Multiples of 512 bytes.)
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>salt=<replaceable>HEX</replaceable></option></term>
+
+        <listitem><para>Salt used for format or verification. Format is a hexadecimal string; 256 bytes long maximum;
+        <literal>-</literal>is the special value for empty.</para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>uuid=<replaceable>UUID</replaceable></option></term>
+
+        <listitem><para>Use the provided UUID for format command instead of generating new one. The UUID must be
+        provided in standard UUID format, e.g. 12345678-1234-1234-1234-123456789abc.</para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+        <listitem><para></para></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>ignore-corruption</option></term>
+        <term><option>restart-on-corruption</option></term>
+        <term><option>panic-on-corruption</option></term>
+
+        <listitem><para>Defines what to do if a data verity problem is detected (data corruption). Without these
+        options kernel fails the IO operation with I/O error. With <literal>--ignore-corruption</literal> option the
+        corruption is only logged. With <literal>--restart-on-corruption</literal> or
+        <literal>--panic-on-corruption</literal> the kernel is restarted (panicked) immediately.
+
+        (You have to provide way how to avoid restart loops.)</para>
+
+        <xi:include href="version-info.xml" xpointer="v248"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>ignore-zero-blocks</option></term>
+
+        <listitem><para>Instruct kernel to not verify blocks that are expected to contain zeroes and always directly
+        return zeroes instead.
+
+        WARNING: Use this option only in very specific cases. This option is available since Linux kernel version 4.5.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v248"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>check-at-most-once</option></term>
+
+        <listitem><para>Instruct kernel to verify blocks only the first time they are read from the data device, rather
+        than every time.
+
+        WARNING: It provides a reduced level of security because only offline tampering of the data device's content
+        will be detected, not online tampering. This option is available since Linux kernel version 4.17.
+        </para>
+
+        <xi:include href="version-info.xml" xpointer="v248"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>hash=<replaceable>HASH</replaceable></option></term>
+
+        <listitem><para>Hash algorithm for dm-verity. This should be the name of the algorithm, like "sha1". For default
+        see <command>veritysetup --help</command>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>fec-device=<replaceable>PATH</replaceable></option></term>
+
+        <listitem><para>Use forward error correction (FEC) to recover from corruption if hash verification fails. Use
+        encoding data from the specified device. The fec device argument can be block device or file image. For format,
+        if fec device path doesn't exist, it will be created as file. Note: block sizes for data and hash devices must
+        match. Also, if the verity data_device is encrypted the fec_device should be too.</para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>fec-offset=<replaceable>BYTES</replaceable></option></term>
+
+        <listitem><para>This is the offset, in bytes, from the start of the FEC device to the beginning of the encoding
+        data. (Aligned on 512 bytes.)</para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>fec-roots=<replaceable>NUM</replaceable></option></term>
+
+        <listitem><para>Number of generator roots. This equals to the number of parity bytes in the encoding data. In
+        RS(M, N) encoding, the number of roots is M-N. M is 255 and M-N is between 2 and 24 (including).</para>
+
+        <xi:include href="version-info.xml" xpointer="v254"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>root-hash-signature=<replaceable>PATH</replaceable>|base64:<replaceable>HEX</replaceable></option></term>
+
+        <listitem><para>A base64 string encoding the root hash signature prefixed by <literal>base64:</literal> or a
+        path to roothash signature file used to verify the root hash (in kernel). This feature requires Linux kernel
+        version 5.4 or more recent.</para>
+
+        <xi:include href="version-info.xml" xpointer="v248"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>_netdev</option></term>
+
+        <listitem><para>Marks this veritysetup device as requiring network. It will be
+        started after the network is available, similarly to
+        <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        units marked with <option>_netdev</option>. The service unit to set up this device
+        will be ordered between <filename>remote-fs-pre.target</filename> and
+        <filename>remote-veritysetup.target</filename>, instead of
+        <filename>veritysetup-pre.target</filename> and
+        <filename>veritysetup.target</filename>.</para>
+
+        <para>Hint: if this device is used for a mount point that is specified in
+        <citerefentry project='man-pages'><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+        the <option>_netdev</option> option should also be used for the mount
+        point. Otherwise, a dependency loop might be created where the mount point
+        will be pulled in by <filename>local-fs.target</filename>, while the
+        service to configure the network is usually only started <emphasis>after</emphasis>
+        the local file system has been mounted.</para>
+
+        <xi:include href="version-info.xml" xpointer="v248"/>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>noauto</option></term>
+
+        <listitem><para>This device will not be added to <filename>veritysetup.target</filename>.
+        This means that it will not be automatically enabled on boot, unless something else pulls
+        it in. In particular, if the device is used for a mount point, it'll be enabled
+        automatically during boot, unless the mount point itself is also disabled with
+        <option>noauto</option>.</para>
+
+        <xi:include href="version-info.xml" xpointer="v248"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>nofail</option></term>
+
+        <listitem><para>This device will not be a hard dependency of
+        <filename>veritysetup.target</filename>. It'll still be pulled in and started, but the system
+        will not wait for the device to show up and be enabled, and boot will not fail if this is
+        unsuccessful. Note that other units that depend on the enabled device may still fail. In
+        particular, if the device is used for a mount point, the mount point itself also needs to
+        have the <option>nofail</option> option, or the boot will fail if the device is not enabled
+        successfully.</para>
+
+        <xi:include href="version-info.xml" xpointer="v248"/></listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term><option>x-initrd.attach</option></term>
+
+        <listitem><para>Setup this verity protected block device in the initrd, similarly to
+        <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+        units marked with <option>x-initrd.mount</option>.</para>
+
+        <para>Although it's not necessary to mark the mount entry for the root file system with
+        <option>x-initrd.mount</option>, <option>x-initrd.attach</option> is still recommended with
+        the verity protected block device containing the root file system as otherwise systemd
+        will attempt to detach the device during the regular system shutdown while it's still in
+        use. With this option the device will still be detached but later after the root file
+        system is unmounted.</para>
+
+        <para>All other verity protected block devices that contain file systems mounted in the initrd should
+        use this option.</para>
+
+        <xi:include href="version-info.xml" xpointer="v248"/>
+        </listitem>
+      </varlistentry>
+
+    </variablelist>
+
+    <para>At early boot and when the system manager configuration is
+    reloaded, this file is translated into native systemd units by
+    <citerefentry><refentrytitle>systemd-veritysetup-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
+  </refsect1>
+
+  <refsect1>
+    <title>Examples</title>
+    <example>
+      <title>/etc/veritytab example</title>
+      <para>Set up two verity protected block devices. One using device blocks, another using files.</para>
+
+      <programlisting>usr  PARTUUID=783e45ae-7aa3-484a-beef-a80ff9c19cbb PARTUUID=21dc1dfe-4c33-8b48-98a9-918a22eb3e37 36e3f740ad502e2c25e2a23d9c7c17bf0fdad2300b7580842d4b7ec1fb0fa263 auto
+data /etc/data /etc/hash a5ee4b42f70ae1f46a08a7c92c2e0a20672ad2f514792730f5d49d7606ab8fdf auto
+</programlisting>
+    </example>
+  </refsect1>
+
+  <refsect1>
+    <title>See Also</title>
+    <para>
+      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-veritysetup@.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-veritysetup-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry project='man-pages'><refentrytitle>fstab</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+      <citerefentry project='die-net'><refentrytitle>veritysetup</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+    </para>
+  </refsect1>
+
+</refentry>
diff --git a/man/version-info.xml b/man/version-info.xml
new file mode 100644
index 0000000..5dabf9d
--- /dev/null
+++ b/man/version-info.xml
@@ -0,0 +1,81 @@
+<?xml version="1.0"?>
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
+  "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+
+<refsect1>
+  <para id="v183">Added in version 183.</para>
+  <para id="v184">Added in version 184.</para>
+  <para id="v185">Added in version 185.</para>
+  <para id="v186">Added in version 186.</para>
+  <para id="v187">Added in version 187.</para>
+  <para id="v188">Added in version 188.</para>
+  <para id="v189">Added in version 189.</para>
+  <para id="v190">Added in version 190.</para>
+  <para id="v191">Added in version 191.</para>
+  <para id="v192">Added in version 192.</para>
+  <para id="v193">Added in version 193.</para>
+  <para id="v194">Added in version 194.</para>
+  <para id="v195">Added in version 195.</para>
+  <para id="v196">Added in version 196.</para>
+  <para id="v197">Added in version 197.</para>
+  <para id="v198">Added in version 198.</para>
+  <para id="v199">Added in version 199.</para>
+  <para id="v200">Added in version 200.</para>
+  <para id="v201">Added in version 201.</para>
+  <para id="v202">Added in version 202.</para>
+  <para id="v203">Added in version 203.</para>
+  <para id="v204">Added in version 204.</para>
+  <para id="v205">Added in version 205.</para>
+  <para id="v206">Added in version 206.</para>
+  <para id="v207">Added in version 207.</para>
+  <para id="v208">Added in version 208.</para>
+  <para id="v209">Added in version 209.</para>
+  <para id="v210">Added in version 210.</para>
+  <para id="v211">Added in version 211.</para>
+  <para id="v212">Added in version 212.</para>
+  <para id="v213">Added in version 213.</para>
+  <para id="v214">Added in version 214.</para>
+  <para id="v215">Added in version 215.</para>
+  <para id="v216">Added in version 216.</para>
+  <para id="v217">Added in version 217.</para>
+  <para id="v218">Added in version 218.</para>
+  <para id="v219">Added in version 219.</para>
+  <para id="v220">Added in version 220.</para>
+  <para id="v221">Added in version 221.</para>
+  <para id="v222">Added in version 222.</para>
+  <para id="v223">Added in version 223.</para>
+  <para id="v224">Added in version 224.</para>
+  <para id="v225">Added in version 225.</para>
+  <para id="v226">Added in version 226.</para>
+  <para id="v227">Added in version 227.</para>
+  <para id="v228">Added in version 228.</para>
+  <para id="v229">Added in version 229.</para>
+  <para id="v230">Added in version 230.</para>
+  <para id="v231">Added in version 231.</para>
+  <para id="v232">Added in version 232.</para>
+  <para id="v233">Added in version 233.</para>
+  <para id="v234">Added in version 234.</para>
+  <para id="v235">Added in version 235.</para>
+  <para id="v236">Added in version 236.</para>
+  <para id="v237">Added in version 237.</para>
+  <para id="v238">Added in version 238.</para>
+  <para id="v239">Added in version 239.</para>
+  <para id="v240">Added in version 240.</para>
+  <para id="v241">Added in version 241.</para>
+  <para id="v242">Added in version 242.</para>
+  <para id="v243">Added in version 243.</para>
+  <para id="v244">Added in version 244.</para>
+  <para id="v245">Added in version 245.</para>
+  <para id="v246">Added in version 246.</para>
+  <para id="v247">Added in version 247.</para>
+  <para id="v248">Added in version 248.</para>
+  <para id="v249">Added in version 249.</para>
+  <para id="v250">Added in version 250.</para>
+  <para id="v251">Added in version 251.</para>
+  <para id="v252">Added in version 252.</para>
+  <para id="v253">Added in version 253.</para>
+  <para id="v254">Added in version 254.</para>
+  <para id="v255">Added in version 255.</para>
+  <para id="v256">Added in version 256.</para>
+</refsect1>
diff --git a/man/vtable-example.c b/man/vtable-example.c
new file mode 100644
index 0000000..e3346a8
--- /dev/null
+++ b/man/vtable-example.c
@@ -0,0 +1,112 @@
+/* SPDX-License-Identifier: MIT-0 */
+
+#include <errno.h>
+#include <stdbool.h>
+#include <stddef.h>
+#include <stdlib.h>
+#include <stdio.h>
+#include <systemd/sd-bus.h>
+
+#define _cleanup_(f) __attribute__((cleanup(f)))
+
+#define check(x) ({                             \
+  int r = (x);                                  \
+  errno = r < 0 ? -r : 0;                       \
+  printf(#x ": %m\n");                          \
+  if (r < 0)                                    \
+    return EXIT_FAILURE;                        \
+  })
+
+typedef struct object {
+  char *name;
+  uint32_t number;
+} object;
+
+static int method(sd_bus_message *m, void *userdata, sd_bus_error *error) {
+  printf("Got called with userdata=%p\n", userdata);
+
+  if (sd_bus_message_is_method_call(m,
+                                    "org.freedesktop.systemd.VtableExample",
+                                    "Method4"))
+    return 1;
+
+  const char *string;
+  check(sd_bus_message_read(m, "s", &string));
+  check(sd_bus_reply_method_return(m, "s", string));
+
+  return 1;
+}
+
+static const sd_bus_vtable vtable[] = {
+        SD_BUS_VTABLE_START(0),
+        SD_BUS_METHOD(
+            "Method1", "s", "s", method, 0),
+        SD_BUS_METHOD_WITH_NAMES_OFFSET(
+            "Method2",
+            "so", SD_BUS_PARAM(string) SD_BUS_PARAM(path),
+            "s", SD_BUS_PARAM(returnstring),
+            method, offsetof(object, number),
+            SD_BUS_VTABLE_DEPRECATED),
+        SD_BUS_METHOD_WITH_ARGS_OFFSET(
+            "Method3",
+            SD_BUS_ARGS("s", string, "o", path),
+            SD_BUS_RESULT("s", returnstring),
+            method, offsetof(object, number),
+            SD_BUS_VTABLE_UNPRIVILEGED),
+        SD_BUS_METHOD_WITH_ARGS(
+            "Method4",
+            SD_BUS_NO_ARGS,
+            SD_BUS_NO_RESULT,
+            method,
+            SD_BUS_VTABLE_UNPRIVILEGED),
+        SD_BUS_SIGNAL(
+            "Signal1",
+            "so",
+            0),
+        SD_BUS_SIGNAL_WITH_NAMES(
+            "Signal2",
+            "so", SD_BUS_PARAM(string) SD_BUS_PARAM(path),
+            0),
+        SD_BUS_SIGNAL_WITH_ARGS(
+            "Signal3",
+            SD_BUS_ARGS("s", string, "o", path),
+            0),
+        SD_BUS_WRITABLE_PROPERTY(
+            "AutomaticStringProperty", "s", NULL, NULL,
+            offsetof(object, name),
+            SD_BUS_VTABLE_PROPERTY_EMITS_CHANGE),
+        SD_BUS_WRITABLE_PROPERTY(
+            "AutomaticIntegerProperty", "u", NULL, NULL,
+            offsetof(object, number),
+            SD_BUS_VTABLE_PROPERTY_EMITS_INVALIDATION),
+        SD_BUS_VTABLE_END
+};
+
+int main(int argc, char **argv) {
+  _cleanup_(sd_bus_flush_close_unrefp) sd_bus *bus = NULL;
+
+  sd_bus_default(&bus);
+
+  object object = { .number = 666 };
+  check((object.name = strdup("name")) != NULL);
+
+  check(sd_bus_add_object_vtable(bus, NULL,
+                                 "/org/freedesktop/systemd/VtableExample",
+                                 "org.freedesktop.systemd.VtableExample",
+                                 vtable,
+                                 &object));
+
+  check(sd_bus_request_name(bus,
+                            "org.freedesktop.systemd.VtableExample",
+                            0));
+
+  for (;;) {
+    check(sd_bus_wait(bus, UINT64_MAX));
+    check(sd_bus_process(bus, NULL));
+  }
+
+  check(sd_bus_release_name(bus, "org.freedesktop.systemd.VtableExample"));
+  free(object.name);
+
+  return 0;
+}
diff --git a/man/vtable-example.xml b/man/vtable-example.xml
new file mode 100644
index 0000000..a195777
--- /dev/null
+++ b/man/vtable-example.xml
@@ -0,0 +1,55 @@
+<!DOCTYPE node PUBLIC "-//freedesktop//DTD D-BUS Object Introspection 1.0//EN"
+"https://www.freedesktop.org/standards/dbus/1.0/introspect.dtd">
+<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
+<node>
+ <interface name="org.freedesktop.DBus.Peer">
+  <method name="Ping"/>
+  <method name="GetMachineId">
+   <arg type="s" name="machine_uuid" direction="out"/>
+  </method>
+ </interface>
+ <interface name="org.freedesktop.DBus.Introspectable">
+  <method name="Introspect">
+   <arg name="xml_data" type="s" direction="out"/>
+  </method>
+ </interface>
+ <interface name="org.freedesktop.DBus.Properties">
+  <method name="Get">
+   <arg name="interface_name" direction="in" type="s"/>
+   <arg name="property_name" direction="in" type="s"/>
+   <arg name="value" direction="out" type="v"/>
+  </method>
+  <method name="GetAll">
+   <arg name="interface_name" direction="in" type="s"/>
+   <arg name="props" direction="out" type="a{sv}"/>
+  </method>
+  <method name="Set">
+   <arg name="interface_name" direction="in" type="s"/>
+   <arg name="property_name" direction="in" type="s"/>
+   <arg name="value" direction="in" type="v"/>
+  </method>
+  <signal name="PropertiesChanged">
+   <arg type="s" name="interface_name"/>
+   <arg type="a{sv}" name="changed_properties"/>
+   <arg type="as" name="invalidated_properties"/>
+  </signal>
+ </interface>
+ <interface name="org.freedesktop.systemd.VtableExample">
+  <method name="Method1">
+   <arg type="s" direction="in"/>
+   <arg type="s" direction="out"/>
+  </method>
+  <method name="Method2">
+   <arg type="s" name="string" direction="in"/>
+   <arg type="o" name="path" direction="in"/>
+   <arg type="s" name="returnstring" direction="out"/>
+   <annotation name="org.freedesktop.DBus.Deprecated" value="true"/>
+  </method>
+  <property name="AutomaticStringProperty" type="s" access="readwrite">
+  </property>
+  <property name="AutomaticIntegerProperty" type="u" access="readwrite">
+   <annotation name="org.freedesktop.DBus.Property.EmitsChangedSignal" value="invalidates"/>
+  </property>
+ </interface>
+</node>
+
diff --git a/man/yubikey-crypttab.sh b/man/yubikey-crypttab.sh
new file mode 100644
index 0000000..a66a88f
--- /dev/null
+++ b/man/yubikey-crypttab.sh
@@ -0,0 +1,41 @@
+# SPDX-License-Identifier: MIT-0
+
+# Destroy any old key on the Yubikey (careful!)
+ykman piv reset
+
+# Generate a new private/public key pair on the device, store the public key in
+# 'pubkey.pem'.
+ykman piv generate-key -a RSA2048 9d pubkey.pem
+
+# Create a self-signed certificate from this public key, and store it on the
+# device. The "subject" should be an arbitrary user-chosen string to identify
+# the token with.
+ykman piv generate-certificate --subject "Knobelei" 9d pubkey.pem
+
+# We don't need the public key anymore, let's remove it. Since it is not
+# security sensitive we just do a regular "rm" here.
+rm pubkey.pem
+
+# Enroll the freshly initialized security token in the LUKS2 volume. Replace
+# /dev/sdXn by the partition to use (e.g. /dev/sda1).
+sudo systemd-cryptenroll --pkcs11-token-uri=auto /dev/sdXn
+
+# Test: Let's run systemd-cryptsetup to test if this all worked.
+sudo systemd-cryptsetup attach mytest /dev/sdXn - pkcs11-uri=auto
+
+# If that worked, let's now add the same line persistently to /etc/crypttab,
+# for the future. We don't want to use the (unstable) /dev/sdX name, so let's
+# figure out a stable link:
+udevadm info -q -r symlink /dev/sdXn
+
+# Now add the line using the by-uuid symlink to /etc/crypttab:
+sudo bash -c 'echo "mytest /dev/disk/by-uuid/... - pkcs11-uri=auto" >>/etc/crypttab'
+
+# Depending on your distribution and encryption setup, you may need to manually
+# regenerate your initramfs to be able to use a Yubikey / PKCS#11 token to
+# unlock the partition during early boot.
+# More information at https://unix.stackexchange.com/a/705809.
+# On Fedora based systems:
+sudo dracut --force
+# On Debian based systems:
+sudo update-initramfs -u