morgan/systemd
1
0
Fork 0
mirror of https://github.com/morgan9e/systemd synced 2026-04-15 08:56:15 +09:00
Code Issues Packages Projects Releases Wiki Activity

Man page fixes (#37645)

Browse Source
This commit is contained in:
Luca Boccassi
2025-05-28 19:15:46 +01:00
committed by GitHub
parent 46bcfe651f b082968d19
commit 7a232071d0
34 changed files with 242 additions and 194 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
man/busctl.xml
View File

@@ -149,7 +149,7 @@
<listitem><para>Wait for a signal. Takes an object path, interface name, and signal name. To suppress
output of the returned data, use the <option>--quiet</option> option. The service name may be
omitted, in which case busctl will match signals from any sender.</para>
omitted, in which case <command>busctl</command> will match signals from any sender.</para>
<xi:include href="version-info.xml" xpointer="v257"/></listitem>
</varlistentry>

3
man/coredump.conf.xml
View File

@@ -113,7 +113,8 @@
<term><varname>EnterNamespace=</varname></term>
<listitem><para>For processes belonging to a PID namespace, controls whether
<command>systemd-coredump</command> shall attempt to process core dumps on the host, using debug
<citerefentry><refentrytitle>systemd-coredump</refentrytitle><manvolnum>8</manvolnum></citerefentry>
shall attempt to process core dumps on the host, using debug
information from the file system hierarchy (i.e. the mount namespace) of the process that
crashed. Access to the process' file system hierarchy might be necessary to generate a fully
symbolized backtrace. If set to <literal>yes</literal>, <command>systemd-coredump</command> will

12
man/custom-html.xsl
View File

@@ -66,6 +66,18 @@
</a>
</xsl:template>
<xsl:template match="citerefentry[@project='openssl']">
<a>
<xsl:attribute name="href">
<xsl:text>https://docs.openssl.org/master/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='archlinux']">
<a>
<xsl:attribute name="href">

14
man/networkctl.xml
View File

@@ -422,7 +422,8 @@ s - Service VLAN, m - Two-port MAC Relay (TPMR)
was created, so changing [VLAN] <varname>Id=</varname> will not take effect if the matching VLAN
interface already exists. To apply such settings, the interfaces need to be removed manually before
reload. Also note that even if a <filename>.netdev</filename> file is removed,
<command>systemd-networkd</command> does not remove the existing netdev corresponding to the file.
<citerefentry><refentrytitle>systemd-networkd</refentrytitle><manvolnum>8</manvolnum></citerefentry>
does not remove the existing netdev corresponding to the file.
</para>
<para>If a new, modified, or removed <filename>.network</filename> file is found, then all
@@ -449,9 +450,9 @@ s - Service VLAN, m - Two-port MAC Relay (TPMR)
<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-networkd</refentrytitle><manvolnum>8</manvolnum></citerefentry>
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
@@ -520,8 +521,9 @@ s - Service VLAN, m - Two-port MAC Relay (TPMR)
<replaceable>BOOL</replaceable>
</term>
<listitem>
<para>Notify <filename>systemd-networkd.service</filename> that the persistent storage for the
service is ready. This is called by
<para>Notify
<citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
that the persistent storage for the service is ready. This is called by
<filename>systemd-networkd-persistent-storage.service</filename>. Usually, this command should not
be called manually by users or administrators.</para>

2
man/os-release.xml
View File

@@ -343,7 +343,7 @@
<listitem><para><literal>lts</literal> is for long term support releases of the system, suitable
for production use and supported for an extended period of time. Generally, LTS releases
continue to receive support even if newer major releases of the distribution are available.
Examples include Ubuntu 24.04, Debian 12 Bookworm and RHEL 9.4.</para></listitem>
Examples include Ubuntu 24.04, Debian 12 Bookworm, and RHEL 9.4.</para></listitem>
<listitem><para><literal>development</literal> is for unstable versions of the system,
unsuitable for production use, such as alpha, beta, or rolling unstable releases. Examples

24
man/pam_systemd.xml
View File

@@ -113,7 +113,7 @@
</row>
<row>
<entry><constant>user-early</constant></entry>
<entry>Similar to <literal>user</literal> but sessions of this class are not ordered after <citerefentry><refentrytitle>systemd-user-sessions.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, i.e. may be started before regular sessions are allowed to be established. This session class is the default for sessions of the root user that would otherwise qualify for the <constant>user</constant> class, see above. (Added in v256.)</entry>
<entry>Similar to <constant>user</constant> but sessions of this class are not ordered after <citerefentry><refentrytitle>systemd-user-sessions.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, i.e. may be started before regular sessions are allowed to be established. This session class is the default for sessions of the root user that would otherwise qualify for the <constant>user</constant> class, see above. (Added in v256.)</entry>
</row>
<row>
<entry><constant>user-light</constant></entry>
@@ -125,15 +125,15 @@
</row>
<row>
<entry><constant>user-incomplete</constant></entry>
<entry>Similar to <literal>user</literal> but for sessions which are not fully set up yet, i.e. have no home directory mounted or similar. This is used by <citerefentry><refentrytitle>systemd-homed.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> to allow users to log in via <citerefentry project='man-pages'><refentrytitle>ssh</refentrytitle><manvolnum>1</manvolnum></citerefentry> before their home directory is mounted, delaying the mount until the user provided the unlock password. Sessions of this class are upgraded to the regular <constant>user</constant> class once the home directory is activated.</entry>
<entry>Similar to <constant>user</constant> but for sessions which are not fully set up yet, i.e. have no home directory mounted or similar. This is used by <citerefentry><refentrytitle>systemd-homed.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> to allow users to log in via <citerefentry project='man-pages'><refentrytitle>ssh</refentrytitle><manvolnum>1</manvolnum></citerefentry> before their home directory is mounted, delaying the mount until the user provided the unlock password. Sessions of this class are upgraded to the regular <constant>user</constant> class once the home directory is activated.</entry>
</row>
<row>
<entry><constant>greeter</constant></entry>
<entry>Similar to <literal>user</literal> but for sessions that are spawned by a display manager ephemerally and which prompt the user for login credentials.</entry>
<entry>Similar to <constant>user</constant> but for sessions that are spawned by a display manager ephemerally and which prompt the user for login credentials.</entry>
</row>
<row>
<entry><constant>lock-screen</constant></entry>
<entry>Similar to <literal>user</literal> but for sessions that are spawned by a display manager ephemerally and which show a lock screen that can be used to unlock locked user accounts or sessions.</entry>
<entry>Similar to <constant>user</constant> but for sessions that are spawned by a display manager ephemerally and which show a lock screen that can be used to unlock locked user accounts or sessions.</entry>
</row>
<row>
<entry><constant>background</constant></entry>
@@ -166,9 +166,9 @@
<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>, <literal>mir</literal>, or
<literal>web</literal>. See
environment variable (see below) takes precedence. One of <constant>unspecified</constant>,
<constant>tty</constant>, <constant>x11</constant>, <constant>wayland</constant>, <constant>mir</constant>, or
<constant>web</constant>. See
<citerefentry><refentrytitle>sd_session_get_type</refentrytitle><manvolnum>3</manvolnum></citerefentry> for
details about the session type.</para>
@@ -181,7 +181,7 @@
<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
<constant>GNOME</constant>, or <constant>KDE</constant>. 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
@@ -229,16 +229,16 @@
<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
<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>
seat or if it is invoked for the systemd user service <filename>user@.service</filename>. Otherwise,
defaults to the empty set.</para>
<xi:include href="version-info.xml" xpointer="v254"/></listitem>
</varlistentry>

39
man/repart.d.xml
View File

@@ -516,7 +516,7 @@
<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, it exclude any files
instead of excluding the path on the host from being copied into the partition, it excludes any files
and directories from being copied into the given path in the partition.</para>
<para>When
@@ -612,10 +612,10 @@
<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>
<citerefentry project="url"><refentrytitle url="https://btrfs.readthedocs.io/en/latest/btrfs.html">btrfs</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
<para>Note that this option is only supported in combination with <option>--offline=yes</option>
since btrfs-progs 6.11 or newer.</para>
since <filename>btrfs-progs</filename> 6.11 or newer.</para>
<xi:include href="version-info.xml" xpointer="v255"/></listitem>
</varlistentry>
@@ -632,7 +632,7 @@
</para>
<para>Note that this option is only supported in combination with <option>--offline=yes</option>
since btrfs-progs 6.11 or newer.</para>
since <filename>btrfs-progs</filename> 6.11 or newer.</para>
<xi:include href="version-info.xml" xpointer="v256"/></listitem>
</varlistentry>
@@ -868,7 +868,9 @@
<para>Note that this setting is only taken into account when the filesystem configured with
<varname>Format=</varname> supports compression (
<citerefentry project="url"><refentrytitle url="https://btrfs.readthedocs.io/en/latest/btrfs.html">btrfs</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
squashfs, erofs). Here's an incomplete list of compression algorithms supported by the filesystems
squashfs,
<citerefentry project='man-pages'><refentrytitle>erofs</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
Here's an incomplete list of compression algorithms supported by the filesystems
known to <command>systemd-repart</command>:</para>
<table>
@@ -954,29 +956,30 @@
target for some other supplement definition. A target cannot have more than one supplement partition
associated with it.</para>
<para>For example, distributions can use this to implement <varname>$BOOT</varname> as defined in
the <ulink url="https://uapi-group.org/specifications/specs/boot_loader_specification/">Boot Loader
<para>For example, distributions can use this to implement <varname>$BOOT</varname> as defined in the
<ulink url="https://uapi-group.org/specifications/specs/boot_loader_specification/">Boot Loader
Specification</ulink>. Distributions may prefer to use the ESP as <varname>$BOOT</varname> whenever
possible, but to adhere to the spec XBOOTLDR must sometimes be used instead. So, they should create
two definitions: the first defining an ESP big enough to hold just the bootloader, and a second for
the XBOOTLDR that's sufficiently large to hold kernels and configured as a supplement for the ESP.
Whenever possible, <command>systemd-repart</command> will try to merge the two definitions to create
one large ESP, but if that's not allowable due to the existing conditions on disk a small ESP and a
large XBOOTLDR will be created instead.</para>
Whenever possible,
<citerefentry><refentrytitle>systemd-repart</refentrytitle><manvolnum>8</manvolnum></citerefentry>
will try to merge the two definitions to create one large ESP, but if that's not allowable due to the
existing conditions on disk a small ESP and a large XBOOTLDR will be created instead.</para>
<para>As another example, distributions can also use this to seamlessly share a single
<filename>/home</filename> partition in a multi-boot scenario, while preferring to keep
<filename>/home</filename> on the root partition by default. Having a <filename>/home</filename>
partition separated from the root partition entails some extra complexity: someone has to decide how
to split the space between the two partitions. On the other hand, it allows a user to share their
home area between multiple installed OSs (i.e. via <citerefentry><refentrytitle>systemd-homed.service
</refentrytitle><manvolnum>8</manvolnum></citerefentry>). Distributions should create two definitions:
the first for a root partition that takes up some relatively small percentage of the disk, and the
second as a supplement for the first to create a <filename>/home</filename> partition that takes up
all the remaining free space. On first boot, if <command>systemd-repart</command> finds an existing
<filename>/home</filename> partition on disk, it'll un-merge the definitions and create just a small
root partition. Otherwise, the definitions will be merged and a single large root partition will be
created.</para>
home area between multiple installed OSs (i.e. via
<citerefentry><refentrytitle>systemd-homed.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>).
Distributions should create two definitions: the first for a root partition that takes up some
relatively small percentage of the disk, and the second as a supplement for the first to create a
<filename>/home</filename> partition that takes up all the remaining free space. On first boot, if
<command>systemd-repart</command> finds an existing <filename>/home</filename> partition on disk,
it'll un-merge the definitions and create just a small root partition. Otherwise, the definitions
will be merged and a single large root partition will be created.</para>
<xi:include href="version-info.xml" xpointer="v257"/></listitem>
</varlistentry>

12
man/systemctl.xml
View File

@@ -2298,11 +2298,13 @@ Jan 12 10:46:45 example.com bluetoothd[8900]: gatt-time-server: Input/output err
<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 means logind will perform the
check and respect active inhibitor locks, but systemctl will only do a client-side check for
interactive invocations (i.e. from a TTY), so that a more friendly and informative error can be
returned to users. <literal>no</literal> disables both the systemctl and logind checks.</para>
locks. It takes one of <literal>auto</literal>, <literal>yes</literal>, and <literal>no</literal>.
Defaults to <literal>auto</literal>, which means logind will perform the check and respect active
inhibitor locks, but <command>systemctl</command> will only do a client-side check for interactive
invocations (i.e. from a TTY), so that a more friendly and informative error can be returned to
users. <literal>no</literal> disables the checks both in <command>systemctl</command> and
<citerefentry><refentrytitle>systemd-logind</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
</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

21
man/systemd-analyze.xml
View File

@@ -1732,17 +1732,20 @@ LEGEND: M → sys_vendor (LENOVO) ┄ F → product_family (ThinkPad X1 Carbon G
<refsect1>
<title>Exit status</title>
<para>For most commands, 0 is returned on success, and a non-zero failure code otherwise.</para>
<para>For most verbs, <constant>0</constant> 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>
<para>For the verb <command>compare-versions</command>, in the two-argument form,
<constant>12</constant>, <constant>0</constant>, or <constant>11</constant> are returned if the second
version string is respectively larger than, equal to, or smaller than the first. In the three-argument
form, <constant>0</constant> or <constant>1</constant> are returned when the condition is respectively
true or false.</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
<para>For the verb <command>has-tpm2</command>, <constant>0</constant> is returned if a TPM2 device is
discovered, supported, and used by firmware, driver, and userspace (i.e. <command>systemd</command>).
Otherwise, the OR combination of the value <constant>1</constant> (in case firmware support is missing),
<constant>2</constant> (in case driver support is missing), and <constant>4</constant> (in case userspace
support is missing). If no TPM2 support is available at all, value <constant>7</constant> is hence
returned.</para>
</refsect1>

7
man/systemd-boot.xml
View File

@@ -430,9 +430,10 @@
<term><varname>LoaderDevicePartUUID</varname></term>
<listitem><para>Contains the partition UUID of the partition the boot loader has been started from on
the current boot (usually a EFI System Partition). Set by the boot loader. (Note that
<command>systemd-stub</command> will set this too, if not set yet, to support systems that directly
boot into a unified kernel image, bypassing any boot loader.)
the current boot (usually an EFI System Partition). Set by the boot loader. (Note that
<citerefentry><refentrytitle>systemd-stub</refentrytitle><manvolnum>7</manvolnum></citerefentry> will
set this too, if not set yet, to support systems that boot directly into a unified kernel image,
bypassing any 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>

2
man/systemd-cryptsetup.xml
View File

@@ -49,7 +49,7 @@
<refsect1>
<title>Description</title>
<para><filename>systemd-cryptsetup</filename> is used to set up (with <command>attach</command>) and tear
<para><command>systemd-cryptsetup</command> 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 called manually.
The positional arguments <parameter>VOLUME</parameter>, <parameter>SOURCE-DEVICE</parameter>,

7
man/systemd-fsck@.service.xml
View File

@@ -64,10 +64,11 @@
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
<citerefentry project='man-pages'><refentrytitle>fsck</refentrytitle><manvolnum>8</manvolnum></citerefentry>
returns either the "System should reboot"
or the "Filesystem errors left uncorrected" condition. For filesystems
listed in <filename>/etc/fstab</filename> without <literal>nofail</literal>
or <literal>noauto</literal> options, <literal>local-fs.target</literal>
or <literal>noauto</literal> options, <filename>local-fs.target</filename>
will then activate <filename>emergency.target</filename>.</para>
</refsect1>

7
man/systemd-gpt-auto-generator.xml
View File

@@ -159,12 +159,7 @@
<entry><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 root partition 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>.
This can be generated using <citerefentry><refentrytitle>systemd-id128</refentrytitle><manvolnum>1</manvolnum></citerefentry>.</entry>
<entry>The first partition with this type UUID on the same disk as the root partition 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>. This can be generated using <citerefentry><refentrytitle>systemd-id128</refentrytitle><manvolnum>1</manvolnum></citerefentry>.</entry>
</row>
<row>
<entry><constant>SD_GPT_TMP</constant></entry>

10
man/systemd-import-generator.xml
View File

@@ -81,10 +81,11 @@
<term>verify=</term>
<listitem><para>Controls whether to cryptographically validate the download before installing it
in place. Takes one of <literal>no</literal>, <literal>checksum</literal> or
<literal>signature</literal> (the latter being the default if not specified). For details see the
in place. Takes one of <literal>no</literal>, <literal>checksum</literal>, or
<literal>signature</literal> (the default if not specified). For details see the
<option>--verify=</option> of
<citerefentry><refentrytitle>importctl</refentrytitle><manvolnum>1</manvolnum></citerefentry></para>
<citerefentry><refentrytitle>importctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
</para>
<xi:include href="version-info.xml" xpointer="v257"/></listitem>
</varlistentry>
@@ -111,7 +112,8 @@
<term>raw</term>
<listitem><para>Controls the type of resource to download, i.e. a (possibly compressed) tarball
that needs to be unpacked into a file system tree, or (possibly compressed) raw disk image (DDI).</para>
that needs to be unpacked into a file system tree, or (possibly compressed) raw disk image (DDI).
</para>
<para>Specification of exactly one of these options is mandatory.</para>

10
man/systemd-network-generator.service.xml
View File

@@ -143,15 +143,17 @@
<filename>50-foobar.link</filename>.</para>
<para>Note that the resulting files are created world-readable, it is hence recommended to not include
secrets in these credentials, but supply them via separate credentials directly to
<filename>systemd-networkd.service</filename>.</para>
secrets in these credentials, but to supply them via separate credentials directly to
<citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
</para>
<xi:include href="version-info.xml" xpointer="v256"/></listitem>
</varlistentry>
</variablelist>
<para>Note that by default the <filename>systemd-network-generator.service</filename> unit file is set up
to inherit the these credentials from the service manager.</para>
<para>Note that by default the
<citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
service is set up to inherit the these credentials from the service manager.</para>
</refsect1>
<refsect1>

7
man/systemd-pcrphase.service.xml
View File

@@ -73,7 +73,8 @@
<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>
<citerefentry><refentrytitle>systemd-pcrphase-sysinit.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
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
@@ -85,7 +86,9 @@
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.)
(This extension happens when the
<citerefentry><refentrytitle>systemd-pcrphase-sysinit.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
service is started.)
</para></listitem>
<listitem><para><literal>shutdown</literal> — when the system shutdown begins. It acts as barrier

6
man/systemd-poweroff.service.xml
View File

@@ -54,9 +54,9 @@
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
<command>systemd-shutdown</command> will run all executables in
<filename>/usr/lib/systemd/system-shutdown/</filename>. Those executables are called with one argument:
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. (A safety
timeout of 90s is applied however.) Note that these executables are run <emphasis>after</emphasis> all

2
man/systemd-repart.xml
View File

@@ -19,7 +19,7 @@
<refnamediv>
<refname>systemd-repart</refname>
<refname>systemd-repart.service</refname>
<refpurpose>Automatically grow and add partitions, and generate disk images (DDIs).</refpurpose>
<refpurpose>Automatically grow and add partitions, and generate disk images (DDIs)</refpurpose>
</refnamediv>
<refsynopsisdiv>

22
man/systemd-resolved.service.xml
View File

@@ -240,8 +240,8 @@
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,
configure the link as the default route 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, make it not the default route.</para>
it. Finally, in order to avoid a specific link receiving any DNS traffic not matching any of its
configured routing domains, do not make it a default route.</para>
<para>See
<citerefentry><refentrytitle>org.freedesktop.resolve1</refentrytitle><manvolnum>5</manvolnum></citerefentry>
@@ -320,15 +320,15 @@ search foobar.com barbar.com
<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>
end of the list which is when the query fails. The resolver in <command>systemd-resolved</command>
however maintains state, and will continuously talk to the same server for all queries in a particular
lookup scope until some form of error is seen at which point it will switch to the next server, and
then stay 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 takes time.
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>

8
man/systemd-sbsign.xml
View File

@@ -73,12 +73,12 @@
<term><option>--certificate-source=<replaceable>TYPE</replaceable>[:<replaceable>NAME</replaceable>]</option></term>
<listitem><para>Set the Secure Boot private key and certificate for use with the
<command>sign</command>. The <option>--certificate=</option> option takes a path to a PEM encoded
X.509 certificate or a URI that's passed to the OpenSSL provider configured with
<option>--certificate-source</option>. The <option>--certificate-source</option> takes one of
<command>sign</command> verb. The <option>--certificate=</option> option takes a path to a
PEM-encoded X.509 certificate or a URI that's passed to the OpenSSL provider configured with
<option>--certificate-source</option>. The <option>--certificate-source</option> option takes one of
<literal>file</literal> or <literal>provider</literal>, with the latter being followed by a specific
provider identifier, separated with a colon, e.g. <literal>provider:pkcs11</literal>. The
<option>--private-key=</option> option can take a path or a URI that will be passed to the OpenSSL
<option>--private-key=</option> option takes a path or a URI that will be passed to the OpenSSL
engine or provider, as specified by <option>--private-key-source=</option> as a
<literal>type:name</literal> tuple, such as <literal>engine:pkcs11</literal>. The specified OpenSSL
signing engine or provider will be used to sign the PE binary.</para>

4
man/systemd-soft-reboot.service.xml
View File

@@ -170,8 +170,8 @@ DefaultDependencies=no</programlisting>
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>
executed directly. Instead, trigger system shutdown with a command such as <command>systemctl
soft-reboot</command>.</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

38
man/systemd-stub.xml
View File

@@ -140,11 +140,12 @@
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 11 of these 12 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
corresponding EFI configuration table. <command>systemd-stub</command> will ask the firmware via the
<literal>EFI_DT_FIXUP_PROTOCOL</literal> for hardware specific fixups to the DeviceTree.</para>
<para>The contents of 11 of these 12 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. If an UKI contains multiple profiles, only
the PE sections of the selected profile (and those of the base profile, except if overridden) are
measured.</para>
@@ -287,19 +288,20 @@
<literal>rd.systemd.unit=storagetm.target</literal>.</para>
<para>A single UKI may support multiple profiles by means of the special <literal>.profile</literal> PE
section. This section acts as separator between the PE sections of the individual
profiles. <literal>.profile</literal> PE sections hence may appear multiple times in a single UKI, and
the other PE sections listed above may appear multiple times too, if <literal>.profile</literal> are
used, but only once before the first <literal>.profile</literal> section, once between each subsequent
pair, and once after the last appearance of <literal>.profile</literal>. The sections listed before the
first <literal>.profile</literal> are considered the "base" profile of the UKI. Each
<literal>.profile</literal> section then introduces a new profile, which are numbered starting from
zero. The PE sections following each <literal>.profile</literal> are specific to that profile. When
booting into a specific profile the base section's profiles are used in combination with the specific
profile's sections: if the same section is defined in both, the per-profile section overrides the base
profile's version, otherwise the per-profile sections is used together with the base profile
sections.</para> <para>A UKI that contains no <literal>.profile</literal> is consider equivalent to one
that just contains a single <literal>.profile</literal>, as having only a single profile @0.</para>
section. This section acts as separator between the PE sections of the individual profiles.
<literal>.profile</literal> PE sections hence may appear multiple times in a single UKI, and the other PE
sections listed above may appear multiple times too, if <literal>.profile</literal> are used, but only
once before the first <literal>.profile</literal> section, once between each subsequent pair, and once
after the last appearance of <literal>.profile</literal>. The sections listed before the first
<literal>.profile</literal> are considered the "base" profile of the UKI. Each
<literal>.profile</literal> section then introduces a new profile, which are numbered starting from zero.
The PE sections following each <literal>.profile</literal> are specific to that profile. When booting
into a specific profile, the base section's profiles are used in combination with the specific profile's
sections: if the same section is defined in both, the per-profile section overrides the base profile's
version, otherwise the base profile sections are used.</para>
<para>A UKI that contains no <literal>.profile</literal> is consider equivalent to one that just contains
a single <literal>.profile</literal>, as having only a single profile <literal>@0</literal>.</para>
<para>Here's a simple example for a multi-profile UKI's sections, inspired by the setup suggested above:</para>

30
man/systemd-timesyncd.service.xml
View File

@@ -30,16 +30,16 @@
<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
<para><filename>systemd-timesyncd.service</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 <filename>systemd-timesyncd.service</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.service</filename>.</para>
<para>The NTP servers contacted are determined from the global settings in
<citerefentry><refentrytitle>timesyncd.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>, the
@@ -56,8 +56,8 @@
<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
<para>Initialization of <filename>systemd-timesyncd.service</filename> 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
@@ -67,13 +67,13 @@
<filename>time-sync.target</filename> until synchronization to an accurate reference clock is
reached.</para>
<para><filename>systemd</filename> and <filename>systemd-timesyncd</filename> advance the system clock to
<para><command>systemd</command> and <command>systemd-timesyncd</command> advance the system clock to
the "epoch" (the lowest date above which the system clock time is assumed to be set correctly). See
"System clock epoch" section in
<citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> for details.
<filename>systemd</filename> will set the clock when initializing, but
<command>systemd</command> will set the clock when initializing, but
<filename>/var/lib/systemd/timesync/clock</filename> might not yet be available at that point.
<filename>systemd-timesyncd</filename> will advance the clock when it is started and notices that the
<command>systemd-timesyncd</command> will advance the clock when it is started and notices that the
system clock is before the modification time of <filename>/var/lib/systemd/timesync/clock</filename>.
</para>
</refsect1>
@@ -104,8 +104,8 @@
<listitem>
<para>A file that is touched on each successful synchronization to assist
<filename>systemd-time-wait-sync</filename> and other applications in detecting synchronization to
an accurate reference clock.</para>
<citerefentry><refentrytitle>systemd-time-wait-sync.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
service and other applications in detecting synchronization to an accurate reference clock.</para>
<xi:include href="version-info.xml" xpointer="v239"/>
</listitem>

2
man/systemd.exec.xml
View File

@@ -3793,7 +3793,7 @@ StandardInputData=V2XigLJyZSBubyBzdHJhbmdlcnMgdG8gbG92ZQpZb3Uga25vdyB0aGUgcnVsZX
<literal>my.renamed.xxx</literal> to the service.</para>
<para>If <varname>ImportCredential=</varname> is specified multiple times and multiple credentials
end up with the same name after renaming, the first one is kept and later ones are dropped.</para>.
end up with the same name after renaming, the first one is kept and later ones are dropped.</para>
<para>When multiple credentials of the same name are found, credentials found by
<varname>LoadCredential=</varname> and <varname>LoadCredentialEncrypted=</varname> take priority over

32
man/systemd.journal-fields.xml
View File

@@ -127,8 +127,8 @@
<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>
or log level are expected to do so properly formatted, i.e. as integers formatted
as decimals.</para>
</listitem>
</varlistentry>
@@ -206,11 +206,10 @@
<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>
<para>The process number, user number, and group number of the process the journal entry originates
from formatted as decimals. 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>
@@ -273,17 +272,17 @@
<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. The timestamp is in the <constant>CLOCK_REALTIME</constant>
clock in microseconds, formatted as decimal strings.</para>
<para>The earliest trusted timestamp of the message, if any is known that is different from the
reception time of the journal. The timestamp is the <constant>CLOCK_REALTIME</constant> time in
microseconds, formatted as a decimal.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><varname>_SOURCE_BOOTTIME_TIMESTAMP=</varname></term>
<listitem>
<para>The earliest trusted timestamp of the message in <constant>CLOCK_BOOTTIME</constant> clock.
For details, refer to <varname>_SOURCE_REALTIME_TIMESTAMP=</varname>.</para>
<para>The earliest trusted timestamp of the message in the <constant>CLOCK_BOOTTIME</constant>
time, in the same format as <varname>_SOURCE_REALTIME_TIMESTAMP=</varname>.</para>
<xi:include href="version-info.xml" xpointer="v257"/>
</listitem>
@@ -301,8 +300,7 @@
<varlistentry>
<term><varname>_MACHINE_ID=</varname></term>
<listitem>
<para>The machine ID of the originating host, as available
in
<para>The machine ID of the originating host, as described in
<citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
</listitem>
</varlistentry>
@@ -322,7 +320,7 @@
<varlistentry>
<term><varname>_HOSTNAME=</varname></term>
<listitem>
<para>The name of the originating host.</para>
<para>The hostname of the originating host.</para>
</listitem>
</varlistentry>
@@ -646,7 +644,7 @@
<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
the epoch UTC, formatted as a decimal. This has
different properties from
<literal>_SOURCE_REALTIME_TIMESTAMP=</literal>, as it is
usually a bit later but more likely to be monotonic.
@@ -660,7 +658,7 @@
<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
formatted as a decimal. To be useful as an address
for the entry, this should be combined with the boot ID in
<literal>_BOOT_ID=</literal>.
</para>

3
man/systemd.link.xml
View File

@@ -396,7 +396,8 @@
<para>This setting is useful to configure the <literal>ID_NET_MANAGED_BY=</literal> property which
declares which network management service shall manage the interface, which is respected by
<command>systemd-networkd</command> and others. Use
<citerefentry><refentrytitle>systemd-networkd</refentrytitle><manvolnum>8</manvolnum></citerefentry>
and others. Use
<programlisting>Property=ID_NET_MANAGED_BY=io.systemd.Network</programlisting>
to declare explicitly that <command>systemd-networkd</command> shall manage the interface, or set
the property to something else to declare explicitly it shall not do so. See

19
man/systemd.net-naming-scheme.xml
View File

@@ -94,7 +94,8 @@
</tgroup>
</table>
<para>The udev <command>net_id</command> builtin exports the following udev device properties:</para>
<para>The <citerefentry><refentrytitle>udev</refentrytitle><manvolnum>7</manvolnum></citerefentry>
<command>net_id</command> builtin exports the following device properties:</para>
<variablelist>
<varlistentry>
@@ -451,9 +452,10 @@
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>
<para>The <citerefentry><refentrytitle>udev</refentrytitle><manvolnum>7</manvolnum></citerefentry>
rule <varname>NAME=</varname> replaces <literal>:</literal>, <literal>/</literal>, and
<literal>%</literal> with an underscore (<literal>_</literal>), and refuses strings which contain
only digits.</para>
<xi:include href="version-info.xml" xpointer="v249"/>
</listitem>
@@ -559,10 +561,11 @@
<refsect1>
<title>Limiting the use of specific sysfs attributes</title>
<para>When creating names for network cards, some naming schemes use data from sysfs populated
by the kernel. This means that although a specific naming scheme in udev is picked,
the network card's name can still change when a new kernel version adds a new sysfs attribute.
For example if kernel starts setting the <constant>phys_port_name</constant>, udev will append the
<para>When creating names for network cards, some naming schemes use data from sysfs populated by the
kernel. This means that although a specific naming scheme in
<citerefentry><refentrytitle>udev</refentrytitle><manvolnum>7</manvolnum></citerefentry> is picked, the
network card's name can still change when a new kernel version adds a new sysfs attribute. For example,
if kernel starts setting the <constant>phys_port_name</constant>, <command>udev</command> will append the
"<constant>n</constant><replaceable>phys_port_name</replaceable>" suffix to the device name.</para>
<variablelist>

2
man/systemd.netdev.xml
View File

@@ -1112,7 +1112,7 @@ Ports=eth2</programlisting>
<varlistentry>
<term><varname>MinSourcePort=</varname></term>
<listitem>
<para>Specifies the lowest value of the UDP tunnel source UDP port (in range 1…65535).
<para>Specifies the lowest value of the UDP tunnel source port (in range 1…65535).
Defaults to unset.</para>
<xi:include href="version-info.xml" xpointer="v257"/>

30
man/systemd.network.xml
View File

@@ -89,10 +89,11 @@
<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>
used to exclude specific network interfaces from
<citerefentry><refentrytitle>systemd-networkd</refentrytitle><manvolnum>8</manvolnum></citerefentry>'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
@@ -1035,14 +1036,15 @@ DuplicateAddressDetection=none</programlisting></para>
<filename>/proc/sys/net/ipv4/conf/<replaceable>INTERFACE</replaceable>/force_igmp_version</filename>.
Takes one of <literal>no</literal>,
<literal>v1</literal>, <literal>v2</literal>, or <literal>v3</literal>.
When <literal>no</literal>, no enforcement of an IGMP version will be applied, IGMPv1/v2 fallback are allowed, will back to
IGMPv3 mode again if all IGMPv1/v2 Querier Present timer expire.
When <literal>v1</literal>, use of IGMP version 1 will be enforced, and IGMPv1 report will be replied even if IGMPv2/v3
When <literal>no</literal>, no enforcement of an IGMP version is applied. IGMPv1/v2 fallbacks are allowed, and
<command>systemd-networkd</command> will return to
IGMPv3 mode after all IGMPv1/v2 Querier Present timers have expired.
When <literal>v1</literal>, use of IGMP version 1 is enforced. An IGMPv1 report will be returned even if IGMPv2/v3
queries are received.
When <literal>v2</literal>, use of IGMP version 2 will be enforced, and IGMPv2 report will be replied if an IGMPv2/v3 query
is received, but fallback to IGMPv1 if an IGMPv1 query is received.
When <literal>v3</literal>, use of IGMP version 3 will be enforced, and the same reaction will be done as <literal>no</literal>.
Defaults to unset, and the sysctl value will be unchanged.
When <literal>v2</literal>, use of IGMP version 2 is enforced. An IGMPv2 report will be returned if an IGMPv2/v3 query
is received. <command>systemd-networkd</command> will fall back to IGMPv1 if an IGMPv1 query is received.
When <literal>v3</literal>, use of IGMP version 3 is enforced, and the response is the same as with <literal>no</literal>.
Defaults to unset — the sysctl is not set.
</para>
<xi:include href="version-info.xml" xpointer="v257"/>
@@ -1801,8 +1803,8 @@ NFTSet=prefix:netdev:filter:eth_ipv4_prefix</programlisting>
<varlistentry>
<term><varname>GoTo=</varname></term>
<listitem>
<para>Specifies the target priority used by <literal>goto</literal> type of rule. Takes an integer
in the range 1…4294967295. This must be larger than the priority of this rule specified in
<para>Specifies the target priority used by the <literal>goto</literal> type of rule. Takes an
integer in the range 1…4294967295. This must be larger than the priority of the rule specified in
<varname>Priority=</varname>. When specified, <varname>Type=goto</varname> is implied. This is
mandatory when <varname>Type=goto</varname>.</para>
@@ -2972,7 +2974,7 @@ NFTSet=prefix:netdev:filter:eth_ipv4_prefix</programlisting>
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 might not work when
<varname>RapidCommit=</varname> is enabled. See also <varname>RapidCommit=</varname> in the above.
<varname>RapidCommit=</varname> is enabled. See also <varname>RapidCommit=</varname> above.
</para>
<xi:include href="version-info.xml" xpointer="v246"/>

4
man/systemd.timer.xml
View File

@@ -299,7 +299,7 @@
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
<para>This setting has an effect only if <varname>RandomizedDelaySec=</varname> is not 0. Defaults to
<option>false</option>.</para>
<xi:include href="version-info.xml" xpointer="v247"/></listitem>
@@ -318,7 +318,7 @@
time, and since the interval is shorter than the service runtime, that elapse will be in the past,
causing it to immediately trigger once done.</para>
<para>This setting has no effect if a realtime timer has not been specified with
<para>This setting has an effect only if a realtime timer has been specified with
<varname>OnCalendar=</varname>. Defaults to <option>false</option>.</para>
<xi:include href="version-info.xml" xpointer="v257"/></listitem>

10
man/sysupdate.d.xml
View File

@@ -58,7 +58,8 @@
combined, synchronized operation, so that only a combined update of all three together constitutes a
complete update.
We'll call such a collection of transfers a target.
<command>systemd-sysupdate</command> always operates on a single target.</para>
<citerefentry><refentrytitle>systemd-sysupdate</refentrytitle><manvolnum>8</manvolnum></citerefentry>
always operates on a single target.</para>
<para>Transfers may be grouped together into sets that can be individually enabled or disabled by the
system administrator, called "Optional Features":
@@ -522,7 +523,9 @@
XML file. This may be used by software centers (such as GNOME Software or KDE Discover) to present
rich metadata about the resources being updated. This includes display names, changelogs, icons,
and more. The specified catalog must include <ulink url="https://systemd.io/APPSTREAM_BUNDLE">special metadata</ulink>
to be correctly associated with <command>systemd-sysupdate</command> by the software centers.</para>
to be correctly associated with
<citerefentry><refentrytitle>systemd-sysupdate</refentrytitle><manvolnum>8</manvolnum></citerefentry>
by the software centers.</para>
<para>This setting supports specifier expansion. See below for details on supported
specifiers.</para>
@@ -688,7 +691,8 @@
<para>If set to <constant>explicit</constant>, the specified <varname>Path=</varname> will be
resolved relative to the directory specified with <option>--transfer-source=</option> when invoking
<command>systemd-sysupdate</command>.</para>
<citerefentry><refentrytitle>systemd-sysupdate</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
</para>
<para>The values <constant>esp</constant>, <constant>xbootldr</constant>, and
<constant>boot</constant> are only supported when <varname>Type=</varname> is set to

8
man/sysupdate.features.xml
View File

@@ -43,7 +43,9 @@
downloading updates, when vacuuming, and in all other situations.
In effect, transfers belonging to a feature will always be updated in lock-step with the rest of their
target.
This is the primary difference an Optional Feature and a <command>systemd-sysupdate</command> component.
This is the primary difference an Optional Feature and a
<citerefentry><refentrytitle>systemd-sysupdate</refentrytitle><manvolnum>8</manvolnum></citerefentry>
component.
When a feature is disabled, its transfers will not be considered when checking for and downloading updates,
but <command>systemd-sysupdate</command> will still consider them while vacuuming and in other situations
where it needs to determine ownership over previously downloaded system resources.
@@ -54,8 +56,8 @@
defined below.
Transfers can declare that they belong to a feature via the <varname>Features=</varname> setting.
Feature definitions support drop-in files, which are most commonly used to override the
<varname>Enabled=</varname> setting).
They can also be masked out to hide the availability of the feature entirely.</para>
<varname>Enabled=</varname> setting.
They can also be masked to hide the availability of the feature entirely.</para>
<para>Each <filename>*.feature</filename> file contains one section: [Feature].</para>
</refsect1>

12
man/tmpfiles.d.xml
View File

@@ -508,8 +508,9 @@ r! /tmp/.X[0-9]*-lock</programlisting>
<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>
create (and only create) will not cause the execution of
<citerefentry><refentrytitle>systemd-tmpfiles</refentrytitle><manvolnum>8</manvolnum></citerefentry>
to return an error.</para>
<para>For example:
<programlisting># Modify sysfs but do not fail if we are in a container with a read-only /proc
@@ -877,9 +878,10 @@ e! /var/cache/krb5rcache - - - 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.
to a tmpfiles.d line that tells
<citerefentry><refentrytitle>systemd-tmpfiles</refentrytitle><manvolnum>8</manvolnum></citerefentry> 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>

25
man/ukify.xml
View File

@@ -107,9 +107,10 @@
describing separate boot phases. If one of
<varname>SigningEngine=</varname>/<option>--signing-engine=</option> or
<varname>SigningProvider=</varname>/<option>--signing-provider=</option> is specified, then the private
key arguments will be passed verbatim to OpenSSL as URIs, and the public key arguments will be loaded
as X.509 certificates, so that signing can be performed with an OpenSSL engine or provider
respectively.</para>
key arguments will be passed verbatim to
<citerefentry project='openssl'><refentrytitle>openssl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
as URIs, and the public key arguments will be loaded as X.509 certificates, so that signing can be
performed with an OpenSSL engine or provider respectively.</para>
<para>If a SecureBoot signing key is provided via the
<varname>SecureBootPrivateKey=</varname>/<option>--secureboot-private-key=</option> option, the resulting
@@ -582,7 +583,9 @@
<term><varname>SigningEngine=<replaceable>ENGINE</replaceable></varname></term>
<term><option>--signing-engine=<replaceable>ENGINE</replaceable></option></term>
<listitem><para>An OpenSSL engine to be used for signing the resulting binary and PCR measurements.
<listitem><para>An OpenSSL engine to be used for signing the resulting binary and PCR measurements,
see
<citerefentry project='openssl'><refentrytitle>openssl-engine</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
</para>
<xi:include href="version-info.xml" xpointer="v253"/></listitem>
@@ -593,8 +596,10 @@
<term><option>--signing-provider=<replaceable>PROVIDER</replaceable></option></term>
<listitem><para>An OpenSSL provider to be used for signing the resulting binary and PCR
measurements. This option can only be used when using <command>systemd-sbsign</command> as the
signing tool.</para>
measurements, see
<citerefentry project='openssl'><refentrytitle>provider</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
This option can only be used when <command>systemd-sbsign</command> is used as the signing
tool.</para>
<xi:include href="version-info.xml" xpointer="v257"/></listitem>
</varlistentry>
@@ -604,8 +609,10 @@
<term><option>--certificate-provider=<replaceable>PROVIDER</replaceable></option></term>
<listitem><para>An OpenSSL provider to be used for loading the certificate used to sign the
resulting binary and PCR measurements. This option can only be used when using
<command>systemd-sbsign</command> as the signing tool.</para>
resulting binary and PCR measurements, see
<citerefentry project='openssl'><refentrytitle>provider</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
This option can only be used when <command>systemd-sbsign</command> is used as the signing
tool.</para>
<xi:include href="version-info.xml" xpointer="v257"/></listitem>
</varlistentry>
@@ -844,7 +851,7 @@ Writing public key for PCR signing to /etc/systemd/tpm2-pcr-public-key-system.pe
<programlisting>$ ukify build \
--profile='TITLE=Boot into Storage Target Mode
ID=storagetm' \
--cmdline='quiet rw rd.systemd.unit=stroage-target-mode.target' \
--cmdline='quiet rw rd.systemd.unit=storage-target-mode.target' \
--output=profile1.efi
</programlisting>