Fixes #18397.
<term>carrier</term>
<listitem>
<para>the link has a carrier, or for bond or bridge master, all bonding or bridge slave
- network interfaces are enslaved to the master.</para>
+ network interfaces are enslaved to the master</para>
</listitem>
</varlistentry>
<varlistentry>
<listitem><para>Takes one of <literal>disabled</literal>, <literal>loop</literal>,
<literal>all</literal>, <literal>crypto</literal>. If <literal>disabled</literal> the image is
- accessed with empty block discarding turned off. if <literal>loop</literal> discarding is enabled if
+ accessed with empty block discarding turned off. If <literal>loop</literal> discarding is enabled if
operating on a regular file. If <literal>crypt</literal> discarding is enabled even on encrypted file
systems. If <literal>all</literal> discarding is unconditionally enabled.</para></listitem>
</varlistentry>
<term><option>--root-hash-sig=</option></term>
<term><option>--verity-data=</option></term>
- <listitem><para>Configure various aspects of Verity data integrity for the OS
- image. <option>--root-hash=</option> expects a hex-encoding top-level Verity hash to use for setting
- up the Verity integrity protection. <option>--root-hash-sig=</option> expects the path to a file
- containing a PKCS#7 signature file for the hash. This signature is passed to the kernel during
- activation, which will match it against signature keys available in the kernel
- keyring. <option>--verity-data=</option> expects the path to a file with the Verity data to use for
- the OS image, in case it is stored in a detached file. It is recommended to embed the Verity data
- directly in the image, using the Verity mechanisms in the <ulink
- url="https://systemd.io/DISCOVERABLE_PARTITIONS">Discoverable Partitions Specification</ulink>.</para></listitem>
+ <listitem><para>Configure various aspects of Verity data integrity for the OS image. Option
+ <option>--root-hash=</option> specifies a hex-encoded top-level Verity hash to use for setting up the
+ Verity integrity protection. Option <option>--root-hash-sig=</option> specifies the path to a file
+ containing a PKCS#7 signature for the hash. This signature is passed to the kernel during activation,
+ which will match it against signature keys available in the kernel keyring. Option
+ <option>--verity-data=</option> specifies a path to a file with the Verity data to use for the OS
+ image, in case it is stored in a detached file. It is recommended to embed the Verity data directly
+ in the image, using the Verity mechanisms in the <ulink
+ url="https://systemd.io/DISCOVERABLE_PARTITIONS">Discoverable Partitions Specification</ulink>.
+ </para></listitem>
</varlistentry>
<xi:include href="standard-options.xml" xpointer="no-pager" />
<varlistentry>
<term><option>--copy</option></term>
- <listitem><para>Copy locale, keymap, time zone and root password from
- the host. This is equivalent to specifying
+ <listitem><para>Copy locale, keymap, time zone, root password and shell from the host. This is
+ equivalent to specifying
<option>--copy-locale</option>,
<option>--copy-keymap</option>,
<option>--copy-timezone</option>,
thus preserving the existing information contained in the pstore, and clearing
pstore storage for future error events.</para>
- <para>Linux provides a persistent storage file system, pstore, that can store
- error records when the kernel dies (or reboots or powers-off). These records in
- turn can be referenced to debug kernel problems (currently the kernel stuffs
- the tail of the dmesg, which also contains a stack backtrace, into pstore).</para>
+ <para>Linux provides a persistent storage file system, pstore, that can store error records when the
+ kernel dies (or reboots or powers-off). These records in turn can be referenced to debug kernel problems
+ (currently the kernel stores the tail of the kernel log, which also contains a stack backtrace, into
+ pstore).</para>
<para>The pstore file system supports a variety of backends that map onto persistent
storage, such as the ACPI ERST and UEFI variables. The pstore backends
pstore.</para>
<para>The pstore service is independent of the kdump service. In cloud environments
- specifically, host and guest filesystems are on remote filesystems (eg. iSCSI
+ specifically, host and guest filesystems are on remote filesystems (e.g. iSCSI
or NFS), thus kdump relies (implicitly and/or explicitly) upon proper operation
of networking software *and* hardware *and* infrastructure. Thus it may not be
possible to capture a kernel coredump to a file since writes over the network
debugging.</para>
<para>The <command>systemd-pstore</command> executable does the actual work. Upon starting,
- the <filename>pstore.conf</filename> file is read and the <filename>/sys/fs/pstore</filename>
+ the <filename>pstore.conf</filename> file is read and the <filename>/sys/fs/pstore/</filename>
directory contents are processed according to the options. Pstore files are written to the
- journal, and optionally saved into <filename>/var/lib/systemd/pstore</filename>.</para>
+ journal, and optionally saved into <filename>/var/lib/systemd/pstore/</filename>.</para>
</refsect1>
<refsect1>
</refsect2>
<refsect2>
- <title>Controlling kernel parameters</title>
+ <title>Kernel parameters</title>
<para> The kernel has two parameters,
<filename>/sys/module/kernel/parameters/crash_kexec_post_notifiers</filename> and
- <filename>/sys/module/printk/parameters/always_kmsg_dump</filename>,
- that control writes into pstore.
- The crash_kexec_post_notifiers parameter enables the kernel to write
- dmesg (including stack trace) into pstore upon a panic or crash, and
- printk.always_kmsg_dump parameter enables the kernel to write dmesg
- upon a normal shutdown (shutdown, reboot, halt). These kernel
- parameters are managed via the
+ <filename>/sys/module/printk/parameters/always_kmsg_dump</filename>, that control writes into pstore.
+ The first enables storing of the kernel log (including stack trace) into pstore upon a panic or crash,
+ and the second enables storing of the kernel log upon a normal shutdown (shutdown, reboot, halt). These
+ parameters can be managed via the
<citerefentry><refentrytitle>tmpfiles.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>
mechanism, specifically the file <filename>/usr/lib/tmpfiles/systemd-pstore.conf</filename>.
</para>
<para>This section provides a short summary of differences in the stub resolver implemented by
<citerefentry><refentrytitle>nss-resolve</refentrytitle><manvolnum>8</manvolnum></citerefentry> together
- with <command>systemd-resolved</command> and the tranditional stub resolver implemented in
+ with <command>systemd-resolved</command> and the traditional stub resolver implemented in
<citerefentry><refentrytitle>nss-dns</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
<itemizedlist>
<term><varname>ProcSubset=</varname></term>
<listitem><para>Takes one of <literal>all</literal> (the default) and <literal>pid</literal>. If
- the latter all files and directories not directly associated with process management and introspection
- are made invisible in the <filename>/proc/</filename> file system configured for the unit's
- processes. This controls the <literal>subset=</literal> mount option of the <literal>procfs</literal>
- instance for the unit. For further details see <ulink
+ <literal>pid</literal>, all files and directories not directly associated with process management and
+ introspection are made invisible in the <filename>/proc/</filename> file system configured for the
+ unit's processes. This controls the <literal>subset=</literal> mount option of the
+
<literal>procfs</literal> instance for the unit. For further details see <ulink
url="https://www.kernel.org/doc/html/latest/filesystems/proc.html#mount-options">The /proc
Filesystem</ulink>. Note that Linux exposes various kernel APIs via <filename>/proc/</filename>,
which are made unavailable with this setting. Since these APIs are used frequently this option is
executed processes and mounts private <filename>/tmp/</filename> and <filename>/var/tmp/</filename>
directories inside it that are not shared by processes outside of the namespace. This is useful to
secure access to temporary files of the process, but makes sharing between processes via
- <filename>/tmp/</filename> or <filename>/var/tmp/</filename> impossible. If this is enabled, all
- temporary files created by a service in these directories will be removed after the service is
- stopped. Defaults to false. It is possible to run two or more units within the same private
- <filename>/tmp/</filename> and <filename>/var/tmp/</filename> namespace by using the
- <varname>JoinsNamespaceOf=</varname> directive, see
- <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
- details. This setting is implied if <varname>DynamicUser=</varname> is set. For this setting the same
- restrictions regarding mount propagation and privileges apply as for
+ <filename>/tmp/</filename> or <filename>/var/tmp/</filename> impossible. If true, all temporary files
+ created by a service in these directories will be removed after the service is stopped. Defaults to
+ false. It is possible to run two or more units within the same private <filename>/tmp/</filename> and
+ <filename>/var/tmp/</filename> namespace by using the <varname>JoinsNamespaceOf=</varname> directive,
+ see <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+ for details. This setting is implied if <varname>DynamicUser=</varname> is set. For this setting the
+ same restrictions regarding mount propagation and privileges apply as for
<varname>ReadOnlyPaths=</varname> and related calls, see above. Enabling this setting has the side
effect of adding <varname>Requires=</varname> and <varname>After=</varname> dependencies on all mount
units necessary to access <filename>/tmp/</filename> and <filename>/var/tmp/</filename>. Moreover an
<varname>ExecStart=</varname> command line use <literal>${CREDENTIALS_DIRECTORY}/mycred</literal>,
e.g. <literal>ExecStart=cat ${CREDENTIALS_DIRECTORY}/mycred</literal>.</para>
- <para>Currently, an accumulated credential size limit of 1M bytes per unit is
- enforced.</para>
+ <para>Currently, an accumulated credential size limit of 1 MB per unit is enforced.</para>
<para>If referencing an <constant>AF_UNIX</constant> stream socket to connect to, the connection will
originate from an abstract namespace socket, that includes information about the unit and the
<title>History</title>
<para>The following "naming schemes" have been defined (which may be chosen at system boot-up time via
- the <varname>net.naming-scheme=</varname> kernel command line switch, see above:</para>
+ the <varname>net.naming-scheme=</varname> kernel command line switch, see above):</para>
<variablelist>
<varlistentry>
<varlistentry>
<term><constant>v247</constant></term>
- <listitem><para>If the PCI slot is associated with PCI bridge and that has multiple child network
- controllers then all of them might derive the same value of <varname>ID_NET_NAME_SLOT</varname>
- property. That could cause naming conflict if the property is selected as a device name. Now, we detect the
- situation, slot - bridge relation, and we don't produce the <varname>ID_NET_NAME_SLOT</varname> property to
- avoid possible naming conflict.</para></listitem>
+ <listitem><para>When a PCI slot is associated with a PCI bridge that has multiple child network
+ controllers, the same value of the <varname>ID_NET_NAME_SLOT</varname> property might be derived
+ for those controllers. This would cause a naming conflict if the property is selected as the device
+ name. Now, we detect this situation and don't produce the <varname>ID_NET_NAME_SLOT</varname>
+ property.</para></listitem>
</varlistentry>
</variablelist>
<varlistentry>
<term><varname>DNS=</varname></term>
<listitem>
- <para>A DNS server address, which must be in the format
- described in
+ <para>A DNS server address, which must be in the format described in
<citerefentry project='man-pages'><refentrytitle>inet_pton</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
This option may be specified more than once. Each address can optionally take a port number
separated with <literal>:</literal>, a network interface name or index separated with
When IPv6 address is specified with a port number, then the address must be in the square
brackets. That is, the acceptable full formats are
<literal>111.222.333.444:9953%ifname#example.com</literal> for IPv4 and
- <literal>[1111:2222::3333]:9953%ifname#example.com</literal> for IPv6. This setting can be
- specified multiple times. If an empty string is assigned, then the all previous assignments
- are cleared. This setting is read by
+ <literal>[1111:2222::3333]:9953%ifname#example.com</literal> for IPv6. If an empty string is
+ assigned, then the all previous assignments are cleared. This setting is read by
<citerefentry><refentrytitle>systemd-resolved.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><varname>PreferredLifetime=</varname></term>
<listitem>
- <para>Allows the default "preferred lifetime" of the address to be overridden.
- Only three settings are accepted: <literal>forever</literal> or <literal>infinity</literal>
- which is the default and means that the address never expires, and <literal>0</literal> which means
- that the address is considered immediately "expired" and will not be used,
- unless explicitly requested. A setting of PreferredLifetime=0 is useful for
- addresses which are added to be used only by a specific application,
- which is then configured to use them explicitly.</para>
+ <para>Allows the default "preferred lifetime" of the address to be overridden. Only three
+ settings are accepted: <literal>forever</literal>, <literal>infinity</literal>, which is the
+ default and means that the address never expires, and <literal>0</literal>, which means that the
+ address is considered immediately "expired" and will not be used, unless explicitly requested. A
+ setting of <option>PreferredLifetime=0</option> is useful for addresses which are added to be
+ used only by a specific application, which is then configured to use them explicitly.</para>
</listitem>
</varlistentry>
<varlistentry>
<varlistentry>
<term><varname>RequestOptions=</varname></term>
<listitem>
- <para>When configured, allows to set arbitrary request options in the DHCPv4 request options list and will be
- sent to the DHCPV4 server. A whitespace-separated list of integers in the range 1..254. Defaults to unset.</para>
+ <para>Sets request options to be sent to the server in the DHCPv4 request options list. A
+ whitespace-separated list of integers in the range 1..254. Defaults to unset.</para>
</listitem>
</varlistentry>
<term><varname>MUDURL=</varname></term>
<listitem>
<para>When configured, the specified Manufacturer Usage Description (MUD) URL will be sent to
- the DHCPV6 server. The syntax and semantics are the same as for <varname>MUDURL=</varname> in the
+ the DHCPv6 server. The syntax and semantics are the same as for <varname>MUDURL=</varname> in the
[DHCPv4] section described above.</para>
</listitem>
</varlistentry>
<term><varname>RequestOptions=</varname></term>
<listitem>
<para>When configured, allows to set arbitrary request options in the DHCPv6 request options list
- that will be sent to the DHCPV6 server. A whitespace-separated list of integers in the range
+ that will be sent to the DHCPv6 server. A whitespace-separated list of integers in the range
1..254. Defaults to unset.</para>
</listitem>
</varlistentry>
servers set. The "uplink" interface is determined by the default route of the system with the highest
priority. Note that this information is acquired at the time the lease is handed out, and does not
take uplink interfaces into account that acquire DNS server information at a later point. If no
- suitable uplinkg interface is found the DNS server data from <filename>/etc/resolv.conf</filename> is
+ suitable uplink interface is found the DNS server data from <filename>/etc/resolv.conf</filename> is
used. Also, note that the leases are not refreshed if the uplink network configuration changes. To
ensure clients regularly acquire the most current uplink DNS server information, it is thus advisable
to shorten the DHCP lease time via <varname>MaxLeaseTimeSec=</varname> described
<varlistentry>
<term><varname>PacketLimit=</varname></term>
<listitem>
- <para>Specifies the hard limit on the queue size in number of packets. When this limit is reached, incoming packets are
- dropped. An unsigned integer ranges 1 to 4294967294. Defaults to unset and kernel's default is used.</para>
+ <para>Specifies the hard limit on the queue size in number of packets. When this limit is reached,
+ incoming packets are dropped. An unsigned integer ranges 1 to 4294967294. Defaults to unset and
+ kernel's default is used.</para>
</listitem>
</varlistentry>
</variablelist>
<varlistentry>
<term><varname>PacketLimit=</varname></term>
<listitem>
- <para>Specifies the hard limit on the FIFO size in number of packets. The size limit (a buffer
- size) to prevent it from overflowing in case it is unable to dequeue packets as quickly as it
- receives them. When this limit is reached, incoming packets are dropped. An unsigned integer in the
- range 0–4294967294. Defaults to unset and kernel's default is used.</para>
+ <para>Specifies the hard limit on the number of packets in the FIFO queue. The size limit prevents
+ overflow in case the kernel is unable to dequeue packets as quickly as it receives them. When this
+ limit is reached, incoming packets are dropped. An unsigned integer in the range
+ 0–4294967294. Defaults to unset and kernel's default is used.</para>
</listitem>
</varlistentry>
</variablelist>
<varlistentry>
<term><varname>MaxPacketBytes=</varname></term>
<listitem>
- <para>Specifies the maximum packet size in bytes for the class. When suffixed with K, M, or G, the specified
- size is parsed as Kilobytes, Megabytes, or Gigabytes, respectively, to the base of 1024. When unset,
- the kernel default is used.</para>
+ <para>Specifies the maximum packet size in bytes for the class. When suffixed with K, M, or G, the
+ specified size is parsed as Kilobytes, Megabytes, or Gigabytes, respectively, to the base of
+ 1024. When unset, the kernel default is used.</para>
</listitem>
</varlistentry>
</variablelist>
<listitem>
<para>Overrides the default memory pressure limit set by
- <citerefentry><refentrytitle>oomd.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> for this unit
- (cgroup). Takes a percentage value between 0% and 100%, inclusive. This property is ignored unless
- <varname>ManagedOOMMemoryPressure=</varname><option>kill</option>. Defaults to 0%, which means use the
- default set by <citerefentry><refentrytitle>oomd.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
+ <citerefentry><refentrytitle>oomd.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
+ this unit (cgroup). Takes a percentage value between 0% and 100%, inclusive. This property is
+ ignored unless <varname>ManagedOOMMemoryPressure=</varname><option>kill</option>. Defaults to 0%,
+ which means to use the default set by
+ <citerefentry><refentrytitle>oomd.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
</para>
</listitem>
</varlistentry>
abnormally by a signal, or hit a timeout.</para>
<table>
- <title>Exit causes and the effect of the <varname>Restart=</varname> settings on them</title>
+ <title>Exit causes and the effect of the <varname>Restart=</varname> settings</title>
<tgroup cols='2'>
<colspec colname='path' />
<para>The XDG specification defines a way to autostart applications using XDG desktop files.
systemd ships
<citerefentry><refentrytitle>systemd-xdg-autostart-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>
- for the XDG desktop files in autostart directories.
- Desktop Environments can opt-in to use this service by adding a <varname>Wants=</varname>
- dependency on <literal>xdg-desktop-autostart.target</literal>.</para>
+ for the XDG desktop files in autostart directories. Desktop Environments can opt-in to use this
+ service by adding a <varname>Wants=</varname> dependency on
+ <filename>xdg-desktop-autostart.target</filename>.</para>
</listitem>
</varlistentry>
</variablelist>
projects / thirdparty / systemd.git / commitdiff
