<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>
<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
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
<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
<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>
<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
<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
<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>
</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>
<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>
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>
<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
<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>
<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>,
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>
<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>
<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>
<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>
<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>
<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
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
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
<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>
<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>
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
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>
<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>
<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
<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
<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>
<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>
<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
<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
</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>
<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>
<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"/>
<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
<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>
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"/>
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":
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>
<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
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.
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>
<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
</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>
projects / thirdparty / systemd.git / commitdiff
