doc: update punctuation
Resolve spotted issues related to missing or extraneous commas, dashes.
This commit is contained in:
Jan Engelhardt
Zbigniew Jędrzejewski-Szmek
parent
48b5804a48
commit
73e231abde
|
|
@ -521,16 +521,16 @@
|
|||
unit names found in the journal is
|
||||
compared with the specified pattern
|
||||
and all that match are used. For each
|
||||
unit name a match is added for
|
||||
unit name, a match is added for
|
||||
messages from the unit
|
||||
(<literal>_SYSTEMD_UNIT=<replaceable>UNIT</replaceable></literal>)
|
||||
(<literal>_SYSTEMD_UNIT=<replaceable>UNIT</replaceable></literal>),
|
||||
along with additional matches for
|
||||
messages from systemd and messages
|
||||
about coredumps for the specified
|
||||
unit.</para>
|
||||
|
||||
<para>This parameter can be specified
|
||||
multiple times. </para></listitem>
|
||||
multiple times.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
|
|
|
|||
|
|
@ -307,7 +307,7 @@ along with systemd; If not, see <http://www.gnu.org/licenses/>.
|
|||
<parameter>e</parameter>. If the strings in
|
||||
<parameter>e</parameter> were set using
|
||||
<function>sd_bus_set_error_const</function>, they will be shared.
|
||||
Otherwie they wil be copied.</para>
|
||||
Otherwie, they wil be copied.</para>
|
||||
|
||||
<para><function>sd_bus_error_is_set</function> will return
|
||||
<constant>true</constant> if <parameter>e</parameter> is
|
||||
|
|
|
|||
|
|
@ -75,7 +75,7 @@ along with systemd; If not, see <http://www.gnu.org/licenses/>.
|
|||
<title>Description</title>
|
||||
|
||||
<para><function>sd_bus_new()</function> creates a new bus
|
||||
object. This object is reference counted, and will be destroyed
|
||||
object. This object is reference-counted, and will be destroyed
|
||||
when all references are gone. Initially, the caller of this
|
||||
function owns the sole reference.</para>
|
||||
|
||||
|
|
|
|||
|
|
@ -591,7 +591,7 @@ kobject-uevent 1 systemd-udevd-kernel.socket systemd-udevd.service
|
|||
failed state usually are not loaded, and would not be
|
||||
matched by any pattern. In addition, in case of
|
||||
instantiated units, systemd is often unaware of the
|
||||
instance name until the instance has been started. Therefore
|
||||
instance name until the instance has been started. Therefore,
|
||||
using glob patterns with <command>start</command>
|
||||
has limited usefulness.</para>
|
||||
</listitem>
|
||||
|
|
@ -1199,9 +1199,9 @@ kobject-uevent 1 systemd-udevd-kernel.socket systemd-udevd.service
|
|||
<listitem>
|
||||
<para>Import all, one or more environment variables set on
|
||||
the client into the systemd manager environment block. If
|
||||
no arguments are passed the entire environment block is
|
||||
imported. Otherwise a list of one or more environment
|
||||
variable names should be passed, whose client side values
|
||||
no arguments are passed, the entire environment block is
|
||||
imported. Otherwise, a list of one or more environment
|
||||
variable names should be passed, whose client-side values
|
||||
are then imported into the manager's environment
|
||||
block.</para>
|
||||
</listitem>
|
||||
|
|
@ -1432,7 +1432,7 @@ kobject-uevent 1 systemd-udevd-kernel.socket systemd-udevd.service
|
|||
<programlisting># systemctl status dev-sda.device
|
||||
# systemctl status home.mount</programlisting>
|
||||
In the second case, shell-style globs will be matched against
|
||||
currently loaded units, and literal unit names, with or without
|
||||
currently loaded units; literal unit names, with or without
|
||||
a suffix, will be treated as in the first case. This means that
|
||||
literal unit names always refer to exactly one unit, but globs
|
||||
may match zero units and this is not considered an error.</para>
|
||||
|
|
|
|||
|
|
@ -189,7 +189,7 @@
|
|||
<para>Even though the two examples have very similar
|
||||
effects the first is preferable since only one process
|
||||
is running at a time, and both stdout and stderr are
|
||||
captured while in the second example only stdout is
|
||||
captured while in the second example, only stdout is
|
||||
captured.</para>
|
||||
</refsect1>
|
||||
|
||||
|
|
|
|||
|
|
@ -118,7 +118,7 @@
|
|||
<varlistentry>
|
||||
<term><varname>Id</varname></term>
|
||||
<listitem>
|
||||
<para>The VLAN ID to use. An integer in the range 0-4094.
|
||||
<para>The VLAN ID to use. An integer in the range 0–4094.
|
||||
This option is compulsory.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
|
@ -192,7 +192,7 @@
|
|||
<varlistentry>
|
||||
<term><varname>DHCP</varname></term>
|
||||
<listitem>
|
||||
<para>A boolean. When true enables basic DHCPv4 support.</para>
|
||||
<para>A boolean. When true, enables basic DHCPv4 support.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
|
|
@ -283,28 +283,28 @@
|
|||
<varlistentry>
|
||||
<term><varname>UseDNS</varname></term>
|
||||
<listitem>
|
||||
<para>When true (the default) the DNS servers received from the DHCP server will
|
||||
be used, and take precedence over any statically configured ones.</para>
|
||||
<para>When true (the default), the DNS servers received from the DHCP server will
|
||||
be used and take precedence over any statically configured ones.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><varname>UseMTU</varname></term>
|
||||
<listitem>
|
||||
<para>When true the interface maximum transmission unit from the DHCP server will
|
||||
<para>When true, the interface maximum transmission unit from the DHCP server will
|
||||
be used on the current link. Defaults to false.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><varname>UseHostname</varname></term>
|
||||
<listitem>
|
||||
<para>When true (the default) the hostname received from the DHCP server
|
||||
<para>When true (the default), the hostname received from the DHCP server
|
||||
will be used as the transient hostname.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><varname>CriticalConnection</varname></term>
|
||||
<listitem>
|
||||
<para>When true the connection will never be torn down even if the DHCP lease
|
||||
<para>When true, the connection will never be torn down even if the DHCP lease
|
||||
expires. This is contrary to the DHCP specification, but may be the best choice
|
||||
if, say, the root filesystem relies on this connection. Defaults to false.</para>
|
||||
</listitem>
|
||||
|
|
|
|||
|
|
@ -272,7 +272,7 @@
|
|||
<option>--network-interface=</option>
|
||||
and configured with
|
||||
<option>--network-veth</option>. If
|
||||
this option is specified the
|
||||
this option is specified, the
|
||||
CAP_NET_ADMIN capability will be added
|
||||
to the set of capabilities the
|
||||
container retains. The latter may be
|
||||
|
|
@ -289,7 +289,7 @@
|
|||
specified interface from the calling
|
||||
namespace and place it in the
|
||||
container. When the container
|
||||
terminates it is moved back to the
|
||||
terminates, it is moved back to the
|
||||
host namespace. Note that
|
||||
<option>--network-interface=</option>
|
||||
implies
|
||||
|
|
@ -378,7 +378,7 @@
|
|||
is retained if
|
||||
<option>--private-network</option> is
|
||||
specified. If the special value
|
||||
<literal>all</literal> is passed all
|
||||
<literal>all</literal> is passed, all
|
||||
capabilities are
|
||||
retained.</para></listitem>
|
||||
</varlistentry>
|
||||
|
|
@ -524,7 +524,7 @@
|
|||
and shown by tools such as
|
||||
<citerefentry><refentrytitle>ps</refentrytitle><manvolnum>1</manvolnum></citerefentry>. If
|
||||
the container does not run an init
|
||||
system it is recommended to set this
|
||||
system, it is recommended to set this
|
||||
option to <literal>no</literal>. Note
|
||||
that <option>--share-system</option>
|
||||
implies
|
||||
|
|
|
|||
|
|
@ -222,15 +222,15 @@
|
|||
used as an effective way to disable
|
||||
invocation of non-native binaries
|
||||
system-wide, for example to prohibit
|
||||
execution of 32bit x86 binaries on
|
||||
64bit x86-64 systems. This option
|
||||
operates system wide, and acts
|
||||
execution of 32-bit x86 binaries on
|
||||
64-bit x86-64 systems. This option
|
||||
operates system-wide, and acts
|
||||
similar to the
|
||||
<varname>SystemCallArchitectures=</varname>
|
||||
setting of unit files, see
|
||||
<citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
|
||||
for details. This setting defaults to
|
||||
the empty list in which case no
|
||||
the empty list, in which case no
|
||||
filtering of system calls based on
|
||||
architecture is applied. Known
|
||||
architecture identifiers are
|
||||
|
|
@ -249,7 +249,7 @@
|
|||
execution of any non-native
|
||||
binaries. When a binary executes a
|
||||
system call of an architecture that is
|
||||
not listed in this setting it will be
|
||||
not listed in this setting, it will be
|
||||
immediately terminated with the SIGSYS
|
||||
signal.</para></listitem>
|
||||
</varlistentry>
|
||||
|
|
@ -285,7 +285,7 @@
|
|||
<term><varname>DefaultRestartSec=</varname></term>
|
||||
|
||||
<listitem><para>Configures the default
|
||||
time-outs for starting and stopping of
|
||||
timeouts for starting and stopping of
|
||||
units, as well as the default time to
|
||||
sleep between automatic restarts of
|
||||
units, as configured per-unit in
|
||||
|
|
|
|||
|
|
@ -93,10 +93,10 @@
|
|||
<term><option>--resolve-names=</option></term>
|
||||
<listitem>
|
||||
<para>Specify when systemd-udevd should resolve names of users and groups.
|
||||
When set to <option>early</option> (the default) names will be
|
||||
When set to <option>early</option> (the default), names will be
|
||||
resolved when the rules are parsed. When set to
|
||||
<option>late</option> names will be resolved for every event.
|
||||
When set to <option>never</option> names will never be resolved
|
||||
<option>late</option>, names will be resolved for every event.
|
||||
When set to <option>never</option>, names will never be resolved
|
||||
and all devices will be owned by root.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
|
|
|||
|
|
@ -1033,7 +1033,7 @@
|
|||
|
||||
<para>If you specify both types of
|
||||
this option (i.e. whitelisting and
|
||||
blacklisting) the first encountered
|
||||
blacklisting), the first encountered
|
||||
will take precedence and will dictate
|
||||
the default action (termination or
|
||||
approval of a system call). Then the
|
||||
|
|
@ -1044,7 +1044,7 @@
|
|||
default action (e.g. You have started
|
||||
with a whitelisting of
|
||||
<function>read</function> and
|
||||
<function>write</function> and right
|
||||
<function>write</function>, and right
|
||||
after it add a blacklisting of
|
||||
<function>write</function>, then
|
||||
<function>write</function> will be
|
||||
|
|
@ -1075,7 +1075,7 @@
|
|||
<literal>EACCES</literal> or
|
||||
<literal>EUCLEAN</literal>. When this
|
||||
setting is not used, or when the empty
|
||||
string is assigned the process will be
|
||||
string is assigned, the process will be
|
||||
terminated immediately when the filter
|
||||
is triggered.</para></listitem>
|
||||
</varlistentry>
|
||||
|
|
@ -1099,8 +1099,8 @@
|
|||
unit. This is an effective way to
|
||||
disable compatibility with non-native
|
||||
architectures for processes, for
|
||||
example to prohibit execution of 32bit
|
||||
x86 binaries on 64bit x86-64
|
||||
example to prohibit execution of 32-bit
|
||||
x86 binaries on 64-bit x86-64
|
||||
systems. The special
|
||||
<literal>native</literal> identifier
|
||||
implicitly maps to the native
|
||||
|
|
@ -1110,7 +1110,7 @@
|
|||
that setting this option to a
|
||||
non-empty list implies that
|
||||
<literal>native</literal> is included
|
||||
too. By default this option is set to
|
||||
too. By default, this option is set to
|
||||
the empty list, i.e. no architecture
|
||||
system call filtering is applied. Note
|
||||
that configuring a system call filter
|
||||
|
|
|
|||
|
|
@ -109,7 +109,7 @@
|
|||
<varname>ExecStop=</varname>). If set
|
||||
to <option>process</option>, only the
|
||||
main process itself is killed. If set
|
||||
to <option>mixed</option> the
|
||||
to <option>mixed</option>, the
|
||||
<constant>SIGTERM</constant> signal
|
||||
(see below) is sent to the main
|
||||
process while the subsequent
|
||||
|
|
@ -118,7 +118,7 @@
|
|||
processes of the unit's control
|
||||
group. If set to
|
||||
<option>none</option>, no process is
|
||||
killed. In this case only the stop
|
||||
killed. In this case, only the stop
|
||||
command will be executed on unit stop,
|
||||
but no process be killed
|
||||
otherwise. Processes remaining alive
|
||||
|
|
|
|||
|
|
@ -748,29 +748,29 @@ ExecStart=/bin/echo $ONE $TWO ${TWO}</programlisting>
|
|||
definitions can either be numeric exit
|
||||
codes or termination signal names,
|
||||
separated by spaces. For example:
|
||||
<programlisting>SuccessExitStatus=1 2 8 <constant>SIGKILL</constant></programlisting>
|
||||
ensures that exit codes 1, 2, 8 and
|
||||
the termination signal
|
||||
<constant>SIGKILL</constant> are
|
||||
considered clean service terminations.
|
||||
</para>
|
||||
<programlisting>SuccessExitStatus=1 2 8 <constant>SIGKILL</constant></programlisting>
|
||||
ensures that exit codes 1, 2, 8 and
|
||||
the termination signal
|
||||
<constant>SIGKILL</constant> are
|
||||
considered clean service terminations.
|
||||
</para>
|
||||
|
||||
<para>Note that if a process has a
|
||||
signal handler installed and exits by
|
||||
calling
|
||||
<citerefentry><refentrytitle>_exit</refentrytitle><manvolnum>2</manvolnum></citerefentry>
|
||||
in response to a signal, the
|
||||
information about the signal is lost.
|
||||
Programs should instead perform cleanup and kill themselves with the same signal instead. See
|
||||
<ulink url="http://www.cons.org/cracauer/sigint.html">Proper handling of SIGINT/SIGQUIT — How to be a proper program</ulink>.</para>
|
||||
<para>Note that if a process has a
|
||||
signal handler installed and exits by
|
||||
calling
|
||||
<citerefentry><refentrytitle>_exit</refentrytitle><manvolnum>2</manvolnum></citerefentry>
|
||||
in response to a signal, the
|
||||
information about the signal is lost.
|
||||
Programs should instead perform cleanup and kill themselves with the same signal instead. See
|
||||
<ulink url="http://www.cons.org/cracauer/sigint.html">Proper handling of SIGINT/SIGQUIT — How to be a proper program</ulink>.</para>
|
||||
|
||||
<para>This option may appear more than once
|
||||
in which case the list of successful
|
||||
exit statuses is merged. If the empty
|
||||
string is assigned to this option, the
|
||||
list is reset, all prior assignments
|
||||
of this option will have no
|
||||
effect.</para></listitem>
|
||||
<para>This option may appear more than once,
|
||||
in which case the list of successful
|
||||
exit statuses is merged. If the empty
|
||||
string is assigned to this option, the
|
||||
list is reset, all prior assignments
|
||||
of this option will have no
|
||||
effect.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
|
|
|
|||
|
|
@ -84,7 +84,7 @@
|
|||
which configure resource control settings for the
|
||||
processes of the socket.</para>
|
||||
|
||||
<para>For each socket file a matching service file
|
||||
<para>For each socket file, a matching service file
|
||||
must exist, describing the service to start on
|
||||
incoming traffic on the socket (see
|
||||
<citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>
|
||||
|
|
@ -254,7 +254,7 @@
|
|||
before the interface it is configured
|
||||
on is up and running, and even
|
||||
regardless of whether it will be up and
|
||||
running at any point. To deal with this
|
||||
running at any point. To deal with this,
|
||||
it is recommended to set the
|
||||
<varname>FreeBind=</varname> option
|
||||
described below.</para></listitem>
|
||||
|
|
@ -720,7 +720,7 @@
|
|||
<varname>Accept=no</varname>. It
|
||||
defaults to the service that bears the
|
||||
same name as the socket (with the
|
||||
suffix replaced). In most cases it
|
||||
suffix replaced). In most cases, it
|
||||
should not be necessary to use this
|
||||
option.</para></listitem>
|
||||
</varlistentry>
|
||||
|
|
|
|||
|
|
@ -820,7 +820,7 @@
|
|||
services. These targets are generally not part of the
|
||||
initial boot transaction, unless they are explicitly
|
||||
pulled in by one of the implementing services. Note
|
||||
specifically, that these <emphasis>passive</emphasis>
|
||||
specifically that these <emphasis>passive</emphasis>
|
||||
target units are generally not pulled in by the
|
||||
consumer of a service, but by the provider of the
|
||||
service. This means: a consuming service should order
|
||||
|
|
|
|||
|
|
@ -214,7 +214,7 @@
|
|||
later. Within this time window, the
|
||||
expiry time will be placed at a
|
||||
host-specific, randomized but stable
|
||||
position, that is synchronized between
|
||||
position that is synchronized between
|
||||
all local timer units. This is done in
|
||||
order to distribute the wake-up time
|
||||
in networked installations, as well as
|
||||
|
|
|
|||
|
|
@ -393,7 +393,7 @@
|
|||
and ordering dependencies are placed between two
|
||||
units. Also note that the majority of dependencies are
|
||||
implicitly created and maintained by systemd. In most
|
||||
cases it should be unnecessary to declare additional
|
||||
cases, it should be unnecessary to declare additional
|
||||
dependencies manually, however it is possible to do
|
||||
this.</para>
|
||||
|
||||
|
|
|
|||
|
|
@ -33,7 +33,7 @@ KERNEL=="sd*[!0-9]|sr*", ENV{ID_SERIAL}!="?*", SUBSYSTEMS=="scsi", ATTRS{type}==
|
|||
|
||||
# Run ata_id on non-removable USB Mass Storage (SATA/PATA disks in enclosures)
|
||||
KERNEL=="sd*[!0-9]|sr*", ENV{ID_SERIAL}!="?*", ATTR{removable}=="0", SUBSYSTEMS=="usb", IMPORT{program}="ata_id --export $devnode"
|
||||
# Otherwise fall back to using usb_id for USB devices
|
||||
# Otherwise, fall back to using usb_id for USB devices
|
||||
KERNEL=="sd*[!0-9]|sr*", ENV{ID_SERIAL}!="?*", SUBSYSTEMS=="usb", IMPORT{builtin}="usb_id"
|
||||
|
||||
# scsi devices
|
||||
|
|
|
|||
|
|
@ -285,7 +285,7 @@ int main(int argc, char *argv[]) {
|
|||
* their probing at boot-time might happen in any order. This
|
||||
* means the validity checking of the device then is not
|
||||
* reliable, since it might not see other devices conflicting
|
||||
* with a specific backlight. To deal with this we will
|
||||
* with a specific backlight. To deal with this, we will
|
||||
* actively delete backlight state files at shutdown (where
|
||||
* device probing should be complete), so that the validity
|
||||
* check at boot time doesn't have to be reliable. */
|
||||
|
|
|
|||
|
|
@ -629,7 +629,7 @@ int unit_realize_cgroup(Unit *u) {
|
|||
* unit, we need to first create all parents, but there's more
|
||||
* actually: for the weight-based controllers we also need to
|
||||
* make sure that all our siblings (i.e. units that are in the
|
||||
* same slice as we are) have cgroups, too. Otherwise things
|
||||
* same slice as we are) have cgroups, too. Otherwise, things
|
||||
* would become very uneven as each of their processes would
|
||||
* get as much resources as all our group together. This call
|
||||
* will synchronously create the parent cgroups, but will
|
||||
|
|
|
|||
|
|
@ -727,7 +727,7 @@ static int add_matches(sd_journal *j, char **args) {
|
|||
t = strappend("_COMM=", comm);
|
||||
|
||||
/* Append _EXE only if the interpreter is not a link.
|
||||
Otherwise it might be outdated often. */
|
||||
Otherwise, it might be outdated often. */
|
||||
if (lstat(interpreter, &st) == 0 &&
|
||||
!S_ISLNK(st.st_mode)) {
|
||||
t2 = strappend("_EXE=", interpreter);
|
||||
|
|
|
|||
|
|
@ -464,7 +464,7 @@ static int compare_entry_order(JournalFile *af, Object *_ao,
|
|||
|
||||
if (sd_id128_equal(ao->entry.boot_id, bo->entry.boot_id)) {
|
||||
|
||||
/* If the boot id matches compare monotonic time */
|
||||
/* If the boot id matches, compare monotonic time */
|
||||
a = le64toh(ao->entry.monotonic);
|
||||
b = le64toh(bo->entry.monotonic);
|
||||
|
||||
|
|
@ -474,7 +474,7 @@ static int compare_entry_order(JournalFile *af, Object *_ao,
|
|||
return 1;
|
||||
}
|
||||
|
||||
/* Otherwise compare UTC time */
|
||||
/* Otherwise, compare UTC time */
|
||||
a = le64toh(ao->entry.realtime);
|
||||
b = le64toh(bo->entry.realtime);
|
||||
|
||||
|
|
|
|||
|
|
@ -299,8 +299,8 @@ static int bus_message_setup_kmsg(sd_bus *b, sd_bus_message *m) {
|
|||
continue;
|
||||
}
|
||||
|
||||
/* Otherwise let's send a vector to the actual data,
|
||||
* for that we need to map it first. */
|
||||
/* Otherwise, let's send a vector to the actual data.
|
||||
* For that, we need to map it first. */
|
||||
r = bus_body_part_map(part);
|
||||
if (r < 0)
|
||||
goto fail;
|
||||
|
|
|
|||
|
|
@ -1041,7 +1041,7 @@ int cg_mangle_path(const char *path, char **result) {
|
|||
assert(path);
|
||||
assert(result);
|
||||
|
||||
/* First check if it already is a filesystem path */
|
||||
/* First, check if it already is a filesystem path */
|
||||
if (path_startswith(path, "/sys/fs/cgroup")) {
|
||||
|
||||
t = strdup(path);
|
||||
|
|
@ -1053,7 +1053,7 @@ int cg_mangle_path(const char *path, char **result) {
|
|||
return 0;
|
||||
}
|
||||
|
||||
/* Otherwise treat it as cg spec */
|
||||
/* Otherwise, treat it as cg spec */
|
||||
r = cg_split_spec(path, &c, &p);
|
||||
if (r < 0)
|
||||
return r;
|
||||
|
|
|
|||
|
|
@ -219,9 +219,9 @@ static int dev_if_packed_info(struct udev_device *dev, char *ifs_str, size_t len
|
|||
* A unique USB identification is generated like this:
|
||||
*
|
||||
* 1.) Get the USB device type from InterfaceClass and InterfaceSubClass
|
||||
* 2.) If the device type is 'Mass-Storage/SPC-2' or 'Mass-Storage/RBC'
|
||||
* 2.) If the device type is 'Mass-Storage/SPC-2' or 'Mass-Storage/RBC',
|
||||
* use the SCSI vendor and model as USB-Vendor and USB-model.
|
||||
* 3.) Otherwise use the USB manufacturer and product as
|
||||
* 3.) Otherwise, use the USB manufacturer and product as
|
||||
* USB-Vendor and USB-model. Any non-printable characters
|
||||
* in those strings will be skipped; a slash '/' will be converted
|
||||
* into a full stop '.'.
|
||||
|
|
|
|||
Loading…
Reference in New Issue