shaba/systemd
1
0
Fork 0
mirror of https://github.com/systemd/systemd.git synced 2024-12-22 17:35:35 +03:00
Code

man: various typos and other small issues

Browse Source 
Fixes #18397.
This commit is contained in:
Zbigniew Jędrzejewski-Szmek 2021-01-28 20:38:27 +01:00
parent d13f2617c9
commit 75909cc7e4
11 changed files with 78 additions and 83 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
man/networkctl.xml
View File

@ -104,7 +104,7 @@
<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>

21
man/systemd-dissect.xml
View File

@ -207,7 +207,7 @@
<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>
@ -217,15 +217,16 @@
<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" />

4
man/systemd-firstboot.xml
View File

@ -237,8 +237,8 @@
<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>,

27
man/systemd-pstore.service.xml
View File

@ -34,10 +34,10 @@
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
@ -48,7 +48,7 @@
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
@ -59,9 +59,9 @@
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>
@ -83,17 +83,14 @@
</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>

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

@ -223,7 +223,7 @@
<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>

26
man/systemd.exec.xml
View File

@ -338,10 +338,10 @@
<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
@ -1443,14 +1443,13 @@ BindReadOnlyPaths=/var/lib/systemd</programlisting>
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
@ -2762,8 +2761,7 @@ StandardInputData=SWNrIHNpdHplIGRhIHVuJyBlc3NlIEtsb3BzLAp1ZmYgZWVtYWwga2xvcHAncy
<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

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

@ -271,7 +271,7 @@
<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>
@ -362,11 +362,11 @@
<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>

50
man/systemd.network.xml
View File

@ -665,8 +665,7 @@ IPv6Token=prefixstable:2002:da8:1::</programlisting></para>
<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
@ -674,9 +673,8 @@ IPv6Token=prefixstable:2002:da8:1::</programlisting></para>
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>
@ -1074,13 +1072,12 @@ IPv6Token=prefixstable:2002:da8:1::</programlisting></para>
<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>
@ -1882,8 +1879,8 @@ IPv6Token=prefixstable:2002:da8:1::</programlisting></para>
<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>
@ -1965,7 +1962,7 @@ IPv6Token=prefixstable:2002:da8:1::</programlisting></para>
<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>
@ -1974,7 +1971,7 @@ IPv6Token=prefixstable:2002:da8:1::</programlisting></para>
<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>
@ -2306,7 +2303,7 @@ IPv6Token=prefixstable:2002:da8:1::</programlisting></para>
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
@ -3022,8 +3019,9 @@ IPv6Token=prefixstable:2002:da8:1::</programlisting></para>
<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>
@ -3101,10 +3099,10 @@ IPv6Token=prefixstable:2002:da8:1::</programlisting></para>
<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>
@ -3682,9 +3680,9 @@ IPv6Token=prefixstable:2002:da8:1::</programlisting></para>
<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>

9
man/systemd.resource-control.xml
View File

@ -905,10 +905,11 @@ DeviceAllow=/dev/loop-control
<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>

2
man/systemd.service.xml
View File

@ -780,7 +780,7 @@
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' />

6
man/systemd.special.xml
View File

@ -1281,9 +1281,9 @@
<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>