Closes https://github.com/systemd/systemd/issues/29814.
<para><option>--vacuum-time=</option> removes archived journal files older than the specified
timespan. Accepts the usual <literal>s</literal> (default), <literal>m</literal>,
- <literal>h</literal>, <literal>days</literal>, <literal>months</literal>, <literal>weeks</literal>
+ <literal>h</literal>, <literal>days</literal>, <literal>weeks</literal>, <literal>months</literal>,
and <literal>years</literal> suffixes, see
<citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
details.</para>
<varlistentry>
<term><command>edit</command> <replaceable>NAME|FILE</replaceable></term>
- <listitem><para>Edit the settings file of the specified machines. For the format of the settings file, refer to <citerefentry
- project='man-pages'><refentrytitle>systemd.nspawn</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
- If an existing settings file of the given machine can't be found, <command>edit</command> automatically
- create a new settings file from scratch under <filename>/etc/</filename></para>
+ <listitem><para>Edit the settings file of the specified machines. For the format of the settings
+ file, refer to
+ <citerefentry project='man-pages'><refentrytitle>systemd.nspawn</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+ If an existing settings file of the given machine can't be found, <command>edit</command>
+ automatically create a new settings file from scratch under <filename>/etc/</filename>.
+ </para>
<xi:include href="version-info.xml" xpointer="v254"/></listitem>
</varlistentry>
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 <command>systemd-udevd</command>.
+ The same applies for <filename>.link</filename> files and
+ <citerefentry><refentrytitle>systemd-udevd</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
Note that the changed link settings are not automatically applied after reloading.
To achieve that, trigger uevents for the corresponding interface. Refer to
<citerefentry><refentrytitle>systemd.link</refentrytitle><manvolnum>5</manvolnum></citerefentry>
</varlistentry>
<varlistentry>
- <term><option>--drop-in=</option></term>
- <replaceable>NAME</replaceable>
+ <term><option>--drop-in=</option><replaceable>NAME</replaceable></term>
<listitem>
<para>When used with <command>edit</command>, edit the drop-in file <replaceable>NAME</replaceable>
<term><option>--no-reload</option></term>
<listitem>
- <para>When used with <command>edit</command>, <command>systemd-networkd</command>
- or <command>systemd-udevd</command> will not be reloaded after the editing finishes.</para>
+ <para>When used with <command>edit</command>,
+ <citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+ or
+ <citerefentry><refentrytitle>systemd-udevd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+ will not be reloaded after the editing finishes.</para>
<xi:include href="version-info.xml" xpointer="v254"/>
</listitem>
</varlistentry>
<varlistentry>
<term>StaleRetentionSec=<replaceable>SECONDS</replaceable></term>
- <listitem><para>Takes a duration value, which determines the length of time DNS resource records can be retained
- in the cache beyond their Time To Live (TTL). This allows these records to be returned as stale records.
- By default, this value is set to zero, meaning that DNS resource records are not stored in the cache after their TTL expires.</para>
-
- <para>This is useful when a DNS server failure occurs or becomes unreachable.
- In such cases, systemd-resolved continues to use the stale records to answer DNS queries, particularly when no valid response
- can be obtained from the upstream DNS servers. However, this doesn't apply to NXDOMAIN responses, as those are still perfectly valid responses.
- This feature enhances resilience against DNS infrastructure failures and outages.</para>
-
- <para>systemd-resolved always attempts to reach the upstream DNS servers first, before providing the client application with any stale data.
- If this feature is enabled, cache will not be flushed when changing servers.</para>
+ <listitem><para>Takes a duration value, which determines the length of time DNS resource records can
+ be retained in the cache beyond their Time To Live (TTL). This allows these records to be returned as
+ stale records. By default, this value is set to zero, meaning that DNS resource records are not
+ stored in the cache after their TTL expires.</para>
+
+ <para>This is useful when a DNS server failure occurs or becomes unreachable. In such cases,
+ <citerefentry><refentrytitle>systemd-resolved</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+ continues to use the stale records to answer DNS queries, particularly when no valid response can be
+ obtained from the upstream DNS servers. However, this doesn't apply to NXDOMAIN responses, as those
+ are still perfectly valid responses. This feature enhances resilience against DNS infrastructure
+ failures and outages.</para>
+
+ <para><command>systemd-resolved</command> always attempts to reach the upstream DNS servers first,
+ before providing the client application with any stale data. If this feature is enabled, cache will
+ not be flushed when changing servers.</para>
<xi:include href="version-info.xml" xpointer="v254"/>
</listitem>
</varlistentry>
<varlistentry>
- <term><option>--drop-in=</option></term>
+ <term><option>--drop-in=</option><replaceable>NAME</replaceable></term>
<listitem>
- <para>When used with <command>edit</command>, use the given drop-in file name instead of
- <filename>override.conf</filename>.</para>
+ <para>When used with <command>edit</command>, use <replaceable>NAME</replaceable> as the drop-in
+ file name instead of <filename>override.conf</filename>.</para>
<xi:include href="version-info.xml" xpointer="v253"/>
</listitem>
<citerefentry><refentrytitle>systemd.image-policy</refentrytitle><manvolnum>7</manvolnum></citerefentry>. The
policy is normalized and simplified. For each currently defined partition identifier (as per the <ulink
url="https://uapi-group.org/specifications/specs/discoverable_partitions_specification">Discoverable
- Partitions Specification</ulink> the effect of the image policy string is shown in tabular form.</para>
+ Partitions Specification</ulink>) the effect of the image policy string is shown in tabular form.</para>
<example>
<title>Example Output</title>
<refnamediv>
<refname>systemd-battery-check.service</refname>
<refname>systemd-battery-check</refname>
- <refpurpose>Check battery level whether there's enough charge, and power off if not.</refpurpose>
+ <refpurpose>Check battery level whether there's enough charge, and power off if not</refpurpose>
</refnamediv>
<refsynopsisdiv>
<refsect1>
<title>Description</title>
- <para>
- <filename>systemd-battery-check.service</filename> is used to check the battery level during the early
- boot stage to determine whether there's sufficient battery power to carry on with the booting process.
- </para>
- <para>
- <command>systemd-battery-check</command> returns success if the device is connected to an AC power
- source or if the battery charge is greater than 5%. It returns failure otherwise.
- </para>
+ <para>This service checks the presence of an external power supply and the battery level during the early
+ boot stage to determine whether there is sufficient power to carry on with the booting process.</para>
+
+ <para><command>systemd-battery-check</command> returns success if the device is connected to an AC power
+ source or if the battery charge is greater than 5%. It returns failure otherwise.</para>
</refsect1>
<refsect1>
<term><option>--force</option></term>
<listitem><para>Write configuration even if the relevant files already exist. Without this option,
- <filename>systemd-firstboot</filename> doesn't modify or replace existing files. Note that when
- configuring the root account, even with this option, <filename>systemd-firstboot</filename> only
+ <command>systemd-firstboot</command> doesn't modify or replace existing files. Note that when
+ configuring the root account, even with this option, <command>systemd-firstboot</command> only
modifies the entry of the <literal>root</literal> user, leaving other entries in
<filename>/etc/passwd</filename> and <filename>/etc/shadow</filename> intact.</para>
last check, number of mounts, unclean unmount, etc.</para>
<para><filename>systemd-fsck-root.service</filename> and <filename>systemd-fsck-usr.service</filename>
- will activate <filename>reboot.target</filename> if <filename>fsck</filename> returns the "System
- should reboot" condition, or <filename>emergency.target</filename> if <filename>fsck</filename>
+ will activate <filename>reboot.target</filename> if <command>fsck</command> returns the "System
+ should reboot" condition, or <filename>emergency.target</filename> if <command>fsck</command>
returns the "Filesystem errors left uncorrected" condition.</para>
<para><filename>systemd-fsck@.service</filename> will fail if
- <filename>fsck</filename> returns with either "System should reboot"
+ <command>fsck</command> returns with either "System should reboot"
or "Filesystem errors left uncorrected" conditions. For filesystems
listed in <filename>/etc/fstab</filename> without <literal>nofail</literal>
or <literal>noauto</literal> options, <literal>local-fs.target</literal>
<refsect1>
<title>Kernel Command Line</title>
- <para><filename>systemd-fsck</filename> understands these kernel
+ <para><command>systemd-fsck</command> understands these kernel
command line parameters:</para>
<variablelist class='kernel-commandline-options'>
<para><filename>systemd-hibernate-resume.service</filename> initiates the resume from hibernation.</para>
- <para><filename>systemd-hibernate-resume</filename> only supports the in-kernel hibernation
+ <para><command>systemd-hibernate-resume</command> only supports the in-kernel hibernation
implementation, see <ulink url="https://docs.kernel.org/power/swsusp.html">Swap suspend</ulink>.
Internally, it works by writing the major:minor of specified device node to
<filename>/sys/power/resume</filename>, along with the offset in memory pages
invoked. This option may be used multiple times to pass multiple file descriptors in a single
notification message.</para>
- <para>To use this functionality from a <command>bash</command> shell, use an expression like the following:</para>
+ <para>To use this functionality from a
+ <citerefentry project='man-pages'><refentrytitle>bash</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+ shell, use an expression like the following:</para>
<programlisting>systemd-notify --fd=4 --fd=5 4</some/file 5</some/other/file</programlisting>
<xi:include href="version-info.xml" xpointer="v254"/></listitem>
<example>
<title>Allowing access to the tty</title>
- <para>The following command invokes <citerefentry project='man-pages'><refentrytitle>bash</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+ <para>The following command invokes
+ <citerefentry project='man-pages'><refentrytitle>bash</refentrytitle><manvolnum>1</manvolnum></citerefentry>
as a service passing its standard input, output and error to the calling TTY.</para>
<programlisting># systemd-run -t --send-sighup bash</programlisting>
</programlisting>
<para>The first argument is expanded by the shell (double quotes), but the second one is not expanded
- by the shell (single quotes). <command>echo</command> is called with [<literal>/usr/bin/echo</literal>,
+ by the shell (single quotes).
+ <citerefentry project='man-pages'><refentrytitle>echo</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+ is called with [<literal>/usr/bin/echo</literal>,
<literal>[]</literal>, <literal>[${INVOCATION_ID}]</literal>] as the argument array, and then
- <command>systemd</command> generates <varname>${INVOCATION_ID}</varname> and substitutes it in the
- command-line. This substitution could not be done on the client side, because the target ID that will
- be set for the service isn't known before the call is made.</para>
+ <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+ generates <varname>${INVOCATION_ID}</varname> and substitutes it in the command-line. This substitution
+ could not be done on the client side, because the target ID that will be set for the service isn't
+ known before the call is made.</para>
</example>
<example>
<title>Variable expansion and output redirection using a shell</title>
- <para>Variable expansion by <command>systemd</command> can be disabled with
- <varname>--expand-environment=no</varname>.</para>
+ <para>Variable expansion by
+ <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+ can be disabled with <varname>--expand-environment=no</varname>.</para>
<para>Disabling variable expansion can be useful if the command to execute contains dollar characters
and escaping them would be inconvenient. For example, when a shell is used:</para>
/bin/bash 12345
</programlisting>
- <para>The last argument is passed verbatim to the <command>bash</command> shell which is started by the
- service unit. The shell expands <literal>$SHELL</literal> to the path of the shell, and
- <literal>$$</literal> to its process number, and then those strings are passed to the
+ <para>The last argument is passed verbatim to the
+ <citerefentry project='man-pages'><refentrytitle>bash</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+ shell which is started by the service unit. The shell expands <literal>$SHELL</literal> to the path of
+ the shell, and <literal>$$</literal> to its process number, and then those strings are passed to the
<command>echo</command> built-in and printed to standard output (which in this case is connected to the
calling terminal).</para>
</example>
an extension with the same name in a system folder with lower precedence.</para>
<para>A simple mechanism for version compatibility is enforced: a system extension image must carry a
- <filename>/usr/lib/extension-release.d/extension-release.<replaceable>$name</replaceable></filename>
+ <filename>/usr/lib/extension-release.d/extension-release.<replaceable>NAME</replaceable></filename>
file, which must match its image name, that is compared with the host <filename>os-release</filename>
file: the contained <varname>ID=</varname> fields have to match unless <literal>_any</literal> is set
for the extension. If the extension <varname>ID=</varname> is not <literal>_any</literal>, the
<filename>.raw</filename> suffix are considered disk image based confext images.</para>
<para>Again, just like sysext images, the confext images will contain a
- <filename>/etc/extension-release.d/extension-release.<replaceable>$name</replaceable></filename>
- file, which must match the image name (with the usual escape hatch of xattr), and again with content
- being one or more of <varname>ID=</varname>, <varname>VERSION_ID=</varname>, and
- <varname>CONFEXT_LEVEL</varname>. Confext images will then be checked and matched against the
- base OS layer.</para>
+ <filename>/etc/extension-release.d/extension-release.<replaceable>NAME</replaceable></filename>
+ file, which must match the image name (with the usual escape hatch of
+ the <varname>user.extension-release.strict</varname>
+ <citerefentry project='man-pages'><refentrytitle>xattr</refentrytitle><manvolnum>7</manvolnum></citerefentry>),
+ and again with content being one or more of <varname>ID=</varname>, <varname>VERSION_ID=</varname>, and
+ <varname>CONFEXT_LEVEL</varname>. Confext images will then be checked and matched against the base OS
+ layer.</para>
</refsect1>
<refsect1>
<title>Credentials</title>
<para><command>systemd-sysusers</command> supports the service credentials logic as implemented by
- <varname>ImportCredential=</varname><varname>LoadCredential=</varname>/<varname>SetCredential=</varname>
+ <varname>ImportCredential=</varname>/<varname>LoadCredential=</varname>/<varname>SetCredential=</varname>
(see <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>1</manvolnum></citerefentry> for
details). The following credentials are used when passed in:</para>
<title>Credentials</title>
<para><command>systemd-vconsole-setup</command> supports the service credentials logic as implemented by
- <varname>ImportCredential=</varname><varname>LoadCredential=</varname>/<varname>SetCredential=</varname>
+ <varname>ImportCredential=</varname>/<varname>LoadCredential=</varname>/<varname>SetCredential=</varname>
(see <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>1</manvolnum></citerefentry> for
details). The following credentials are used when passed in:</para>
<para>To make sure making ephemeral copies can be made efficiently, the root directory or root image
should be located on the same filesystem as <filename>/var/lib/systemd/ephemeral-trees/</filename>.
- When using <varname>RootEphemeral=</varname> with root directories, btrfs should be used as the
- filesystem and the root directory should ideally be a subvolume which <command>systemd</command> can
- snapshot to make the ephemeral copy. For root images, a filesystem with support for reflinks should
- be used to ensure an efficient ephemeral copy.</para>
+ When using <varname>RootEphemeral=</varname> with root directories,
+ <citerefentry project='url'><refentrytitle url='https://btrfs.wiki.kernel.org/index.php/Manpage/btrfs(5)'>btrfs</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+ should be used as the filesystem and the root directory should ideally be a subvolume which
+ <command>systemd</command> can snapshot to make the ephemeral copy. For root images, a filesystem
+ with support for reflinks should be used to ensure an efficient ephemeral copy.</para>
<xi:include href="system-only.xml" xpointer="singular"/>
<para>Note that this functionality might not be available, for example if KSM is disabled in the
kernel, or the kernel doesn't support controlling KSM at the process level through
- <function>prctl()</function>.</para>
+ <citerefentry><refentrytitle>prctl</refentrytitle><manvolnum>2</manvolnum></citerefentry>.</para>
<xi:include href="version-info.xml" xpointer="v254"/>
</listitem>
<varname>RateLimitBurst=</varname> configured in
<citerefentry><refentrytitle>journald.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
Note that this only applies to log messages that are processed by the logging subsystem, i.e. by
- <citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+ <citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
This means that if you connect a service's stderr directly to a file via
<varname>StandardOutput=file:…</varname> or a similar setting, the rate limiting will not be applied
to messages written that way (but it will be enforced for messages generated via
<varname>FileDescriptorStoreMax=</varname> is set to a non-zero value (see
<citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>
for details). Applications may check this environment variable before sending file descriptors to
- the service manager via <function>sd_pid_notify_with_fds()</function> (see
- <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry> for
- details).</para>
+ the service manager via
+ <citerefentry><refentrytitle>sd_pid_notify_with_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
+ </para>
<xi:include href="version-info.xml" xpointer="v254"/></listitem>
</varlistentry>
<listitem><para><option>verity</option> for partitions that shall exist and be used, with Verity
authentication. (Note: if a DDI image carries a data partition, along with a Verity partition and a
- signature partition for it, and only the <option>verity</option> flag is set – and
- <option>signed</option> is not –, then the image will be set up with Verity, but the signature data will
- not be used. Or in other words: any DDI with a set of partitions that qualify for
- <option>signature</option> also implicitly qualifies for <option>verity</option>, and in fact
+ signature partition for it, and only the <option>verity</option> flag is set (<option>signed</option>
+ is not), then the image will be set up with Verity, but the signature data will not be used. Or in
+ other words: any DDI with a set of partitions that qualify for <option>signature</option> also
+ implicitly qualifies for <option>verity</option>, and in fact also
<option>unprotected</option>).</para></listitem>
<listitem><para><option>signed</option> for partitions that shall exist and be used, with Verity
<para>Most systemd components that support operating with disk images support a
<option>--image-policy=</option> command line option to specify the image policy to use, and default to
- relatively open policies by default (typically the <literal>*</literal> policy, as described above),
- under the assumption that trust in disk images is established before the images are passed to the program
- in question.</para>
+ relatively open policies (typically the <literal>*</literal> policy, as described above), under the
+ assumption that trust in disk images is established before the images are passed to the program in
+ question.</para>
<para>For the host image itself
<citerefentry><refentrytitle>systemd-gpt-auto-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>
$ sudo udevadm trigger --verbose --settle --action add /sys/class/net/eth0</programlisting>
<para>You may also need to stop the service that manages the network interface, e.g.
- <filename>systemd-networkd.service</filename> or <filename>NetworkManager.service</filename> before
- the above operation, and then restart the service after that. For more details about
- <command>udevadm</command> command, see
+ <citerefentry><refentrytitle>systemd-networkd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+ or <filename>NetworkManager.service</filename> before the above operation, and then restart the service
+ after that. For more details about <command>udevadm</command> command, see
<citerefentry><refentrytitle>udevadm</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
</example>
property or none at all.</para>
<para>Some firmware and hypervisor implementations report unreasonably high numbers for the
- on-board index. To prevent the generation of bogus onbard interface names, index numbers greater
+ on-board index. To prevent the generation of bogus on-board interface names, index numbers greater
than 16381 (2¹⁴-1) were ignored. For s390 PCI devices index values up to 65535 (2¹⁶-1) are valid.
To account for that, the limit was increased to 65535.</para>
<term><varname>UseCaptivePortal=</varname></term>
<listitem>
<para>When true (the default), the captive portal advertised by the DHCP server will be recorded
- and made available to client programs and displayed in the networkctl status output per-link.</para>
+ and made available to client programs and displayed in the
+ <citerefentry><refentrytitle>networkctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+ status output per-link.</para>
<xi:include href="version-info.xml" xpointer="v254"/>
</listitem>
<term><varname>UseCaptivePortal=</varname></term>
<listitem>
<para>When true (the default), the captive portal advertised by the DHCPv6 server will be recorded
- and made available to client programs and displayed in the networkctl status output per-link.</para>
+ and made available to client programs and displayed in the
+ <citerefentry><refentrytitle>networkctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+ status output per-link.</para>
<xi:include href="version-info.xml" xpointer="v254"/>
</listitem>
<term><varname>UseCaptivePortal=</varname></term>
<listitem>
<para>When true (the default), the captive portal received in the Router Advertisement will be recorded
- and made available to client programs and displayed in the networkctl status output per-link.</para>
+ and made available to client programs and displayed in the
+ <citerefentry><refentrytitle>networkctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+ status output per-link.</para>
<xi:include href="version-info.xml" xpointer="v254"/>
</listitem>
<varlistentry>
<term><varname>UsePREF64=</varname></term>
<listitem>
- <para>When true, the IPv6 PREF64 (or NAT64) prefixes received in the Router Advertisement will be recorded
- and made available to client programs and displayed in the <command>networkctl</command> status output per-link.
- See <ulink url="https://tools.ietf.org/html/rfc8781">RFC 8781</ulink>. Defaults to false.</para>
+ <para>When true, the IPv6 PREF64 (or NAT64) prefixes received in the Router Advertisement will be
+ recorded and made available to client programs and displayed in the
+ <citerefentry><refentrytitle>networkctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+ status output per-link. See <ulink url="https://tools.ietf.org/html/rfc8781">RFC 8781</ulink>.
+ Defaults to false.</para>
<xi:include href="version-info.xml" xpointer="v255"/>
</listitem>
<listitem>
<para><varname>BPFProgram=</varname> allows attaching custom BPF programs to the cgroup of a
unit. (This generalizes the functionality exposed via <varname>IPEgressFilterPath=</varname> and
- and <varname>IPIngressFilterPath=</varname> for other hooks.) Cgroup-bpf hooks in the form of BPF
+ <varname>IPIngressFilterPath=</varname> for other hooks.) Cgroup-bpf hooks in the form of BPF
programs loaded to the BPF filesystem are attached with cgroup-bpf attach flags determined by the
unit. For details about attachment types and flags see <ulink
url="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/include/uapi/linux/bpf.h"><filename>bpf.h</filename></ulink>. Also
<replaceable>type</replaceable>:<replaceable>program-path</replaceable>.</para>
<para>The BPF program type is equivalent to the BPF attach type used in
- <command>bpftool</command>. It may be one of <constant>egress</constant>,
- <constant>ingress</constant>, <constant>sock_create</constant>, <constant>sock_ops</constant>,
- <constant>device</constant>, <constant>bind4</constant>, <constant>bind6</constant>,
- <constant>connect4</constant>, <constant>connect6</constant>, <constant>post_bind4</constant>,
- <constant>post_bind6</constant>, <constant>sendmsg4</constant>, <constant>sendmsg6</constant>,
- <constant>sysctl</constant>, <constant>recvmsg4</constant>, <constant>recvmsg6</constant>,
- <constant>getsockopt</constant>, <constant>setsockopt</constant>.</para>
+ <citerefentry project='mankier'><refentrytitle>bpftool</refentrytitle><manvolnum>8</manvolnum></citerefentry>
+ It may be one of
+ <constant>egress</constant>,
+ <constant>ingress</constant>,
+ <constant>sock_create</constant>,
+ <constant>sock_ops</constant>,
+ <constant>device</constant>,
+ <constant>bind4</constant>,
+ <constant>bind6</constant>,
+ <constant>connect4</constant>,
+ <constant>connect6</constant>,
+ <constant>post_bind4</constant>,
+ <constant>post_bind6</constant>,
+ <constant>sendmsg4</constant>,
+ <constant>sendmsg6</constant>,
+ <constant>sysctl</constant>,
+ <constant>recvmsg4</constant>,
+ <constant>recvmsg6</constant>,
+ <constant>getsockopt</constant>,
+ or <constant>setsockopt</constant>.
+ </para>
<para>The specified program path must be an absolute path referencing a BPF program inode in the
bpffs file system (which generally means it must begin with <filename>/sys/fs/bpf/</filename>). If
<varname>$MEMORY_PRESSURE_WATCH</varname> environment variable to the literal string
<filename>/dev/null</filename>. If <literal>on</literal> tells the service to watch for memory
pressure events. This enables memory accounting for the service, and ensures the
- <filename>memory.pressure</filename> cgroup attribute files is accessible for read and write to the
+ <filename>memory.pressure</filename> cgroup attribute file is accessible for reading and writing by the
service's user. It then sets the <varname>$MEMORY_PRESSURE_WATCH</varname> environment variable for
processes invoked by the unit to the file system path to this file. The threshold information
configured with <varname>MemoryPressureThresholdSec=</varname> is encoded in the
been forked off (i.e. immediately after <function>fork()</function>, and before various process
attributes have been configured and in particular before the new process has called
<function>execve()</function> to invoke the actual service binary). Typically,
- <varname>Type=</varname><option>exec</option> (see below) is the better choice, see below.</para>
+ <varname>Type=</varname><option>exec</option> is the better choice, see below.</para>
<para>It is expected that the process configured with <varname>ExecStart=</varname> is the main
process of the service. In this mode, if the process offers functionality to other processes on
socket provided by systemd. If <varname>NotifyAccess=</varname> is missing or set to
<option>none</option>, it will be forcibly set to <option>main</option>.</para>
- <para>If the service supports reloading, and uses the a signal to start the reload, using
+ <para>If the service supports reloading, and uses a signal to start the reload, using
<option>notify-reload</option> instead is recommended.</para></listitem>
<listitem><para>Behavior of <option>notify-reload</option> is similar to <option>notify</option>,
<constant>stop</constant> the event is logged but the unit is terminated cleanly by the service
manager. If set to <constant>kill</constant> and one of the unit's processes is killed by the OOM
killer the kernel is instructed to kill all remaining processes of the unit too, by setting the
- <filename>memory.oom.group</filename> attribute to <constant>1</constant>; also see <ulink
- url="https://docs.kernel.org/admin-guide/cgroup-v2.html">kernel documentation</ulink>.</para>
+ <filename>memory.oom.group</filename> attribute to <constant>1</constant>; also see kernel
+ page <ulink url="https://docs.kernel.org/admin-guide/cgroup-v2.html">Control Group v2</ulink>.
+ </para>
<para>Defaults to the setting <varname>DefaultOOMPolicy=</varname> in
<citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
queue that have not been accepted yet. This setting matters only for stream and sequential packet
sockets. See
<citerefentry><refentrytitle>listen</refentrytitle><manvolnum>2</manvolnum></citerefentry> for
- details. Note that this value is silently capped by the <literal>net.core.somaxconn</literal> sysctl,
- which typically defaults to 4096. By default this is set to 4294967295, so that the sysctl takes full
- effect.</para></listitem>
+ details. Defaults to 4294967295. Note that this value is silently capped by the
+ <literal>net.core.somaxconn</literal> sysctl, which typically defaults to 4096, so typically
+ the sysctl is the setting that actually matters.</para></listitem>
</varlistentry>
<varlistentry>
<term><varname>JoinsNamespaceOf=</varname></term>
<listitem><para>For units that start processes (such as service units), lists one or more other units
- whose network and/or temporary file namespace to join. If this is specified on a unit (say, a.service
- has <varname>JoinsNamespaceOf=b.service</varname>), then this the inverse dependency
- (<varname>JoinsNamespaceOf=a.service</varname> for b.service) is implied. This only applies to unit
- types which support the <varname>PrivateNetwork=</varname>, <varname>NetworkNamespacePath=</varname>,
- <varname>PrivateIPC=</varname>, <varname>IPCNamespacePath=</varname>, and
- <varname>PrivateTmp=</varname> directives (see
+ whose network and/or temporary file namespace to join. If this is specified on a unit (say,
+ <filename>a.service</filename> has <varname>JoinsNamespaceOf=b.service</varname>), then the inverse
+ dependency (<varname>JoinsNamespaceOf=a.service</varname> for b.service) is implied. This only
+ applies to unit types which support the <varname>PrivateNetwork=</varname>,
+ <varname>NetworkNamespacePath=</varname>, <varname>PrivateIPC=</varname>,
+ <varname>IPCNamespacePath=</varname>, and <varname>PrivateTmp=</varname> directives (see
<citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
details). If a unit that has this setting set is started, its processes will see the same
<filename>/tmp/</filename>, <filename>/var/tmp/</filename>, IPC namespace and network namespace as
<programlisting>-smbios type=11,value=io.systemd.credential.binary:tmpfiles.extra=$(echo "f~ /root/.ssh/authorized_keys 700 root root - $(ssh-add -L | base64 -w 0)" | base64 -w 0)
</programlisting>
- <para>By passing this line to QEMU, the public key of the current user will be encoded in
- base64, added to a tmpfiles.d line that tells systemd-tmpfiles 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>By passing this line to QEMU, the public key of the current user will be encoded in base64, added
+ to a tmpfiles.d line that tells <command>systemd-tmpfiles</command> to decode it into
+ <filename>/root/.ssh/authorized_keys</filename>, encode that line itself in base64 and pass it as a
+ Credential that will be picked up by systemd from SMBIOS on boot.
</para>
</example>
</refsect1>
<para>If the stub and/or the kernel contain <literal>.sbat</literal> sections they will be merged in
the UKI so that revocation updates affecting either are considered when the UKI is loaded by Shim. For
more information on SBAT see
- <ulink url="https://github.com/rhboot/shim/blob/main/SBAT.md">Shim's documentation.</ulink>
+ <ulink url="https://github.com/rhboot/shim/blob/main/SBAT.md">Shim documentation</ulink>.
</para>
</refsect2>
<term><option>--summary</option></term>
<listitem><para>Print a summary of loaded config and exit. This is useful to check how the options
- form the configuration file and the command line are combined.</para>
+ from the configuration file and the command line are combined.</para>
<xi:include href="version-info.xml" xpointer="v254"/></listitem>
</varlistentry>
DBX/MOKX. If not specified manually, a default metadata entry consisting of
<literal>uki,1,UKI,uki,1,https://www.freedesktop.org/software/systemd/man/systemd-stub.html</literal>
will be used, to ensure it is always possible to revoke UKIs and addons. For more information on
- SBAT see <ulink url="https://github.com/rhboot/shim/blob/main/SBAT.md">Shim's documentation.</ulink>
+ SBAT see <ulink url="https://github.com/rhboot/shim/blob/main/SBAT.md">Shim documentation</ulink>.
</para>
<xi:include href="version-info.xml" xpointer="v254"/></listitem>
<para>On the command line, this option may be specified more than once, similarly to the
<option>--pcr-private-key=</option> option. If not present, the public keys will be extracted from
- the private keys. On the command line, if present, the this option must be specified the same number
- of times as the <option>--pcr-private-key=</option> option.</para>
+ the private keys. On the command line, if present, this option must be specified the same number of
+ times as the <option>--pcr-private-key=</option> option.</para>
<xi:include href="version-info.xml" xpointer="v253"/></listitem>
</varlistentry>
<para>(Both operations need to be done as root to allow write access
to <filename>/etc/kernel/</filename>.)</para>
- <para>Subsequent invocations of using the config file
+ <para>Subsequent invocations using the config file
(<command>ukify build --config=/etc/kernel/uki.conf</command>)
will use this certificate and key files. Note that the
<citerefentry><refentrytitle>kernel-install</refentrytitle><manvolnum>8</manvolnum></citerefentry>
plugin <filename>60-ukify.install</filename> uses <filename>/etc/kernel/uki.conf</filename>
by default, so after this file has been created, installations of kernels that create a UKI on the
- local machine using <command>kernel-install</command> would perform signing using this config.</para>
+ local machine using <command>kernel-install</command> will perform signing using this config.</para>
</example>
</refsect1>
projects / thirdparty / systemd.git / commitdiff
