mirror of
https://github.com/systemd/systemd.git
synced 2024-12-22 17:35:35 +03:00
man: typo fixes
A mix of fixes for typos and UK english
This commit is contained in:
parent
6612379adf
commit
2dd678171e
@ -261,7 +261,7 @@
|
||||
<listitem><para>Controls whether actions that <command>systemd-logind</command>
|
||||
takes when the power and sleep keys and the lid switch are triggered are subject
|
||||
to high-level inhibitor locks ("shutdown", "sleep", "idle"). Low level inhibitor
|
||||
locks ("handle-*-key"), are always honoured, irrespective of this setting.</para>
|
||||
locks ("handle-*-key"), are always honored, irrespective of this setting.</para>
|
||||
|
||||
<para>These settings take boolean arguments. If <literal>no</literal>, the
|
||||
inhibitor locks taken by applications are respected. If <literal>yes</literal>,
|
||||
|
@ -97,7 +97,7 @@
|
||||
iteration a single event source is dispatched. Each time an event
|
||||
source is dispatched the kernel is polled for new events, before
|
||||
the next event source is dispatched. The event loop is designed to
|
||||
honour priorities and provide fairness within each priority. It is
|
||||
honor priorities and provide fairness within each priority. It is
|
||||
not designed to provide optimal throughput, as this contradicts
|
||||
these goals due the limitations of the underlying <citerefentry
|
||||
project='man-pages'><refentrytitle>epoll</refentrytitle><manvolnum>7</manvolnum></citerefentry>
|
||||
|
@ -115,7 +115,7 @@
|
||||
reliable. However, it is guaranteed that if events are seen on
|
||||
multiple same-priority event sources at the same time, each one is
|
||||
not dispatched again until all others have been dispatched
|
||||
once. This behaviour guarantees that within each priority
|
||||
once. This behavior guarantees that within each priority
|
||||
particular event sources do not starve or dominate the event
|
||||
loop.</para>
|
||||
|
||||
|
@ -306,7 +306,7 @@
|
||||
<para><literal>ignore-requirements</literal> is similar to
|
||||
<literal>ignore-dependencies</literal>, but only causes the
|
||||
requirement dependencies to be ignored, the ordering
|
||||
dependencies will still be honoured.</para>
|
||||
dependencies will still be honored.</para>
|
||||
</listitem>
|
||||
|
||||
</varlistentry>
|
||||
@ -1006,7 +1006,7 @@ kobject-uevent 1 systemd-udevd-kernel.socket systemd-udevd.service
|
||||
desired, combine this command with the <option>--now</option> switch, or invoke <command>start</command>
|
||||
with appropriate arguments later. Note that in case of unit instance enablement (i.e. enablement of units of
|
||||
the form <filename>foo@bar.service</filename>), symlinks named the same as instances are created in the
|
||||
unit configuration diectory, however they point to the single template unit file they are instantiated
|
||||
unit configuration directory, however they point to the single template unit file they are instantiated
|
||||
from.</para>
|
||||
|
||||
<para>This command expects either valid unit names (in which case various unit file directories are
|
||||
|
@ -107,7 +107,7 @@
|
||||
<citerefentry><refentrytitle>systemd-sysctl</refentrytitle><manvolnum>8</manvolnum></citerefentry>.
|
||||
</para>
|
||||
|
||||
<para>The behaviour of <command>systemd-coredump</command> itself is configured through the configuration file
|
||||
<para>The behavior of <command>systemd-coredump</command> itself is configured through the configuration file
|
||||
<filename>/etc/systemd/coredump.conf</filename> and corresponding snippets
|
||||
<filename>/etc/systemd/coredump.conf.d/*.conf</filename>, see
|
||||
<citerefentry><refentrytitle>coredump.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>. A new
|
||||
|
@ -260,7 +260,7 @@
|
||||
<refsect1>
|
||||
<title>The udev Database</title>
|
||||
|
||||
<para>If <option>--discover</option> is used, <command>systemd-mount</command> honours a couple of additional udev
|
||||
<para>If <option>--discover</option> is used, <command>systemd-mount</command> honors a couple of additional udev
|
||||
properties of block devices:</para>
|
||||
|
||||
<variablelist class='udev-directives'>
|
||||
|
@ -405,7 +405,7 @@
|
||||
purposes (usually in the range beyond the host's UID/GID 65536). The parameter may be specified as follows:</para>
|
||||
|
||||
<orderedlist>
|
||||
<listitem><para>If one or two colon-separated numers are specified, user namespacing is turned on. The first
|
||||
<listitem><para>If one or two colon-separated numbers are specified, user namespacing is turned on. The first
|
||||
parameter specifies the first host UID/GID to assign to the container, the second parameter specifies the
|
||||
number of host UIDs/GIDs to assign to the container. If the second parameter is omitted, 65536 UIDs/GIDs are
|
||||
assigned.</para></listitem>
|
||||
@ -425,13 +425,13 @@
|
||||
range is automatically chosen. As first step, the file owner of the root directory of the container's
|
||||
directory tree is read, and it is checked that it is currently not used by the system otherwise (in
|
||||
particular, that no other container is using it). If this check is successful, the UID/GID range determined
|
||||
this way is used, similar to the behaviour if "yes" is specified. If the check is not successful (and thus
|
||||
this way is used, similar to the behavior if "yes" is specified. If the check is not successful (and thus
|
||||
the UID/GID range indicated in the root directory's file owner is already used elsewhere) a new – currently
|
||||
unused – UID/GID range of 65536 UIDs/GIDs is randomly chosen between the host UID/GIDs of 524288 and
|
||||
1878982656, always starting at a multiple of 65536. This setting implies
|
||||
<option>--private-users-chown</option> (see below), which has the effect that the files and directories in
|
||||
the container's directory tree will be owned by the appropriate users of the range picked. Using this option
|
||||
makes user namespace behaviour fully automatic. Note that the first invocation of a previously unused
|
||||
makes user namespace behavior fully automatic. Note that the first invocation of a previously unused
|
||||
container image might result in picking a new UID/GID range for it, and thus in the (possibly expensive) file
|
||||
ownership adjustment operation. However, subsequent invocations of the container will be cheap (unless of
|
||||
course the picked UID/GID range is assigned to a different use by then).</para></listitem>
|
||||
@ -440,7 +440,7 @@
|
||||
<para>It is recommended to assign at least 65536 UIDs/GIDs to each container, so that the usable UID/GID range in the
|
||||
container covers 16 bit. For best security, do not assign overlapping UID/GID ranges to multiple containers. It is
|
||||
hence a good idea to use the upper 16 bit of the host 32-bit UIDs/GIDs as container identifier, while the lower 16
|
||||
bit encode the container UID/GID used. This is in fact the behaviour enforced by the
|
||||
bit encode the container UID/GID used. This is in fact the behavior enforced by the
|
||||
<option>--private-users=pick</option> option.</para>
|
||||
|
||||
<para>When user namespaces are used, the GID range assigned to each container is always chosen identical to the
|
||||
@ -722,7 +722,7 @@
|
||||
and the subdirectory is symlinked into the host at the same
|
||||
location. <literal>try-host</literal> and
|
||||
<literal>try-guest</literal> do the same but do not fail if
|
||||
the host does not have persistent journalling enabled. If
|
||||
the host does not have persistent journaling enabled. If
|
||||
<literal>auto</literal> (the default), and the right
|
||||
subdirectory of <filename>/var/log/journal</filename> exists,
|
||||
it will be bind mounted into the container. If the
|
||||
|
@ -402,7 +402,7 @@ There is a screen on:
|
||||
when the user first logs in, and stays around as long as at least one
|
||||
login session is open. After the user logs out of the last session,
|
||||
<filename>user@.service</filename> and all services underneath it
|
||||
are terminated. This behaviour is the default, when "lingering" is
|
||||
are terminated. This behavior is the default, when "lingering" is
|
||||
not enabled for that user. Enabling lingering means that
|
||||
<filename>user@.service</filename> is started automatically during
|
||||
boot, even if the user is not logged in, and that the service is
|
||||
|
@ -109,7 +109,7 @@
|
||||
<term><varname>CtrlAltDelBurstAction=</varname></term>
|
||||
|
||||
<listitem><para>Defines what action will be performed
|
||||
if user presses Ctr-Alt-Delete more than 7 times in 2s.
|
||||
if user presses Ctrl-Alt-Delete more than 7 times in 2s.
|
||||
Can be set to <literal>reboot-force</literal>, <literal>poweroff-force</literal>
|
||||
or disabled with <literal>ignore</literal>. Defaults to
|
||||
<literal>reboot-force</literal>.
|
||||
|
@ -988,7 +988,7 @@
|
||||
the unit's own user and group to themselves and everything else to the <literal>nobody</literal> user and
|
||||
group. This is useful to securely detach the user and group databases used by the unit from the rest of the
|
||||
system, and thus to create an effective sandbox environment. All files, directories, processes, IPC objects and
|
||||
other resources owned by users/groups not equalling <literal>root</literal> or the unit's own will stay visible
|
||||
other resources owned by users/groups not equaling <literal>root</literal> or the unit's own will stay visible
|
||||
from within the unit but appear owned by the <literal>nobody</literal> user and group. If this mode is enabled,
|
||||
all unit processes are run without privileges in the host user namespace (regardless if the unit's own
|
||||
user/group is <literal>root</literal> or not). Specifically this means that the process will have zero process
|
||||
@ -1560,7 +1560,7 @@
|
||||
<varlistentry>
|
||||
<term><varname>$MAINPID</varname></term>
|
||||
|
||||
<listitem><para>The PID of the units main process if it is
|
||||
<listitem><para>The PID of the unit's main process if it is
|
||||
known. This is only set for control processes as invoked by
|
||||
<varname>ExecReload=</varname> and similar. </para></listitem>
|
||||
</varlistentry>
|
||||
|
@ -107,7 +107,7 @@
|
||||
<listitem>
|
||||
<para>A whitespace-separated list of shell-style globs matching
|
||||
the device name, as exposed by the udev property
|
||||
"INTERFACE". This can not be used to match on names that have
|
||||
"INTERFACE". This cannot be used to match on names that have
|
||||
already been changed from userspace. Caution is advised when matching on
|
||||
kernel-assigned names, as they are known to be unstable
|
||||
between reboots.</para>
|
||||
|
@ -535,7 +535,7 @@
|
||||
and the kernel will ignore initial ACK packets without any
|
||||
data. The argument specifies the approximate amount of time
|
||||
the kernel should wait for incoming data before falling back
|
||||
to the normal behavior of honouring empty ACK packets. This
|
||||
to the normal behavior of honoring empty ACK packets. This
|
||||
option is beneficial for protocols where the client sends the
|
||||
data first (e.g. HTTP, in contrast to SMTP), because the
|
||||
server process will not be woken up unnecessarily before it
|
||||
|
@ -195,7 +195,7 @@
|
||||
instantiated units, this logic will first look for the instance <literal>.d/</literal>
|
||||
subdirectory and read its <literal>.conf</literal> files, followed by the template
|
||||
<literal>.d/</literal> subdirectory and the <literal>.conf</literal> files there. Also note that
|
||||
settings from the <literal>[Install]</literal> section are not honoured in drop-in unit files,
|
||||
settings from the <literal>[Install]</literal> section are not honored in drop-in unit files,
|
||||
and have no effect.</para>
|
||||
|
||||
<para>In addition to <filename>/etc/systemd/system</filename>, the drop-in <literal>.d</literal>
|
||||
|
Loading…
Reference in New Issue
Block a user