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

tree: wide "the the" and other trivial grammar fixes

Browse Source
This commit is contained in:
Zbigniew Jędrzejewski-Szmek 2020-06-30 15:24:57 +02:00
parent 838d39af93
commit 37b22b3b47
16 changed files with 19 additions and 19 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
docs/BOOT_LOADER_SPECIFICATION.md
View File

@ -47,7 +47,7 @@ functionality. Here's why we think that it is not enough for our uses:
* The various EFI implementations implement the boot order/boot item logic to different levels. Some firmware implementations do not offer a boot menu at all and instead unconditionally follow the EFI boot order, booting the first item that is working.
* If the firmware setup is used to reset all data usually all EFI boot entries are lost, making the system entirely unbootable, as the firmware setups generally do not offer a UI to define additional boot items. By placing the menu item information on disk, it is always available, regardless if the BIOS setup data is lost.
* Harddisk images should be moveable between machines and be bootable without requiring explicit EFI variables to be set. This also requires that the list of boot options is defined on disk, and not in EFI variables alone.
* Harddisk images should be movable between machines and be bootable without requiring explicit EFI variables to be set. This also requires that the list of boot options is defined on disk, and not in EFI variables alone.
* EFI is not universal yet (especially on non-x86 platforms), this specification is useful both for EFI and non-EFI boot loaders.
* Many EFI systems disable USB support during early boot to optimize boot times, thus making keyboard input unavailable in the EFI menu. It is thus useful if the OS UI has a standardized way to discover available boot options which can be booted to.

2
docs/HOME_DIRECTORY.md
View File

@ -125,7 +125,7 @@ medium. (Moreover it allows to embed additional partitions later on, for
example for allowing a multi-purpose USB stick that contains both a home
directory and a generic storage volume.)
Rationale for including the encrypted user record in the the LUKS2 header:
Rationale for including the encrypted user record in the LUKS2 header:
Linux kernel file system implementations are generally not robust towards
maliciously formatted file systems; there's a good chance that file system
images can be used as attack vectors, exploiting the kernel. Thus it is

2
docs/INITRD_INTERFACE.md
View File

@ -36,7 +36,7 @@ interfaces are currently used by dracut and the ArchLinux initrds.
optionally followed (in `argv[2]`, `argv[3]`, … systemd's original command
line options, for example `--log-level=` and similar.
* Storage daemons run from the initrd should follow the the guide on [systemd
* Storage daemons run from the initrd should follow the guide on [systemd
and Storage Daemons for the Root File
System](https://systemd.io/ROOT_STORAGE_DAEMONS) to survive properly from the
boot initrd all the way to the point where systemd jumps back into the initrd

8
docs/RANDOM_SEEDS.md
View File

@ -212,10 +212,10 @@ boot, in order to ensure the entropy pool is filled up quickly.
random-seed`](https://www.freedesktop.org/software/systemd/man/bootctl.html#random-seed))
a seed file with an initial seed is placed in a file `/loader/random-seed`
in the ESP. In addition, an identically sized randomized EFI variable called
the the 'system token' is set, which is written to the machine's firmware
NVRAM. During boot, when `systemd-boot` finds both the random seed file and
the system token they are combined and hashed with SHA256 (in counter mode,
to generate sufficient data), to generate a new random seed file to store in
the 'system token' is set, which is written to the machine's firmware NVRAM.
During boot, when `systemd-boot` finds both the random seed file and the
system token they are combined and hashed with SHA256 (in counter mode, to
generate sufficient data), to generate a new random seed file to store in
the ESP as well as a random seed to pass to the OS kernel. The new random
seed file for the ESP is then written to the ESP, ensuring this is completed
before the OS is invoked. Very early during initialization PID 1 will read

2
man/homectl.xml
View File

@ -401,7 +401,7 @@
<option>--password-change-min=</option> configures how much time has to pass after changing the
password of the user until the password may be changed again. If the user tries to change their
password before this time passes the attempt is refused. <option>--password-change-max=</option>
configures how much time has to pass after the the password is changed until the password expires and
configures how much time has to pass after the password is changed until the password expires and
needs to be changed again. After this time passes any attempts to log in may only proceed after the
password is changed. <option>--password-change-warn=</option> specifies how much earlier than then
the time configured with <option>--password-change-max=</option> the user is warned at login to

2
man/org.freedesktop.LogControl1.xml
View File

@ -83,7 +83,7 @@ node /org/freedesktop/LogControl1 {
<para><varname>LogTarget</varname> describes the log target (mechanism). It should be one of
<literal>console</literal> (log to the console or standard output),
<literal>kmsg</literal> (log to the kernel ring buffer),
<literal>journal</literal> (log the the journal natively, see
<literal>journal</literal> (log to the journal natively, see
<citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>),
<literal>syslog</literal> (log using the
<citerefentry project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry> call).

2
man/sd_hwdb_get.xml
View File

@ -64,7 +64,7 @@
<para><function>sd_hwdb_get()</function> queries the <parameter>hwdb</parameter> object created earlier
with <citerefentry><refentrytitle>sd_hwdb_new</refentrytitle><manvolnum>3</manvolnum></citerefentry> for
entries matching the specified string <parameter>modalias</parameter>, and returns the value
corresponding to the the key <parameter>key</parameter>. The value is returned as a
corresponding to the key <parameter>key</parameter>. The value is returned as a
<constant>NUL</constant>-terminated string in <parameter>value</parameter>. It must not be modified by
the caller and is valid as long as a reference to <parameter>hwdb</parameter> is kept. When multiple
patterns in the database match <parameter>modalias</parameter>, the one with the highest priority is

2
man/standard-conf.xml
View File

@ -13,7 +13,7 @@
<para>Configuration files are read from directories in <filename>/etc/</filename>,
<filename>/run/</filename>, <filename>/usr/local/lib/</filename>, and <filename>/usr/lib/</filename>, in
order of precedence, as listed in the SYNOPSIS section above. Files must have the the
order of precedence, as listed in the SYNOPSIS section above. Files must have the
<literal>.conf</literal> extension. Files in <filename>/etc/</filename> override files with the same name
in <filename>/run/</filename>, <filename>/usr/local/lib/</filename>, and
<filename>/usr/lib/</filename>. Files in <filename>/run/</filename> override files with the same name

2
man/systemd.service.xml
View File

@ -884,7 +884,7 @@
project='man-pages'><refentrytitle>signal</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
a list of signal names.</para>
<para>Note that this setting does not change the the mapping between numeric exit statuses and their
<para>Note that this setting does not change the mapping between numeric exit statuses and their
names, i.e. regardless how this setting is used 0 will still be mapped to <literal>SUCCESS</literal>
(and thus typically shown as <literal>0/SUCCESS</literal> in tool outputs) and 1 to
<literal>FAILURE</literal> (and thus typically shown as <literal>1/FAILURE</literal>), and so on. It

2
man/userdbctl.xml
View File

@ -218,7 +218,7 @@
<para>Note that <command>userdbctl</command> has internal support for NSS-based lookups too. This means
that if neither <constant>io.systemd.Multiplexer</constant> nor
<constant>io.systemd.NameSeviceSwitch</constant> are running look-ups into the the basic user/group
<constant>io.systemd.NameSeviceSwitch</constant> are running look-ups into the basic user/group
databases will still work.</para>
</refsect1>

2
src/core/bpf-firewall.c
View File

@ -544,7 +544,7 @@ int bpf_firewall_compile(Unit *u) {
"BPF_F_ALLOW_MULTI is not supported on this manager, not doing BPF firewall on slice units.");
/* Note that when we compile a new firewall we first flush out the access maps and the BPF programs themselves,
* but we reuse the the accounting maps. That way the firewall in effect always maps to the actual
* but we reuse the accounting maps. That way the firewall in effect always maps to the actual
* configuration, but we don't flush out the accounting unnecessarily */
u->ip_bpf_ingress = bpf_program_unref(u->ip_bpf_ingress);

2
src/core/execute.c
View File

@ -2855,7 +2855,7 @@ static int setup_keyring(
}
out:
/* Revert back uid & gid for the the last time, and exit */
/* Revert back uid & gid for the last time, and exit */
/* no extra logging, as only the first already reported error matters */
if (getuid() != saved_uid)
(void) setreuid(saved_uid, -1);

2
src/core/namespace.c
View File

@ -747,7 +747,7 @@ static int mount_private_dev(MountEntry *m) {
NULSTR_FOREACH(d, devnodes) {
r = clone_device_node(d, temporary_mount, &can_mknod);
/* ENXIO means the the *source* is not a device file, skip creation in that case */
/* ENXIO means the *source* is not a device file, skip creation in that case */
if (r < 0 && r != -ENXIO)
goto fail;
}

2
src/home/pam_systemd_home.c
View File

@ -499,7 +499,7 @@ static int acquire_home(
return r;
/* Implement our own retry loop here instead of relying on the PAM client's one. That's because it
* might happen that the the record we stored on the host does not match the encryption password of
* might happen that the record we stored on the host does not match the encryption password of
* the LUKS image in case the image was used in a different system where the password was
* changed. In that case it will happen that the LUKS password and the host password are
* different, and we handle that by collecting and passing multiple passwords in that case. Hence we

2
src/home/user-record-util.c
View File

@ -172,7 +172,7 @@ int user_record_reconcile(
* -REMCHG: identity records are not about the same user
* -ESTALE: embedded identity record is equally new or newer than supplied record
*
* Return the new record to use, which is either the the embedded record updated with the host
* Return the new record to use, which is either the embedded record updated with the host
* binding or the host record. In both cases the secret data is stripped. */
assert(host);

2
src/shared/varlink.c
View File

@ -387,7 +387,7 @@ DEFINE_TRIVIAL_REF_UNREF_FUNC(Varlink, varlink, varlink_destroy);
static int varlink_test_disconnect(Varlink *v) {
assert(v);
/* Tests whether we the the connection has been terminated. We are careful to not stop processing it
/* Tests whether we the connection has been terminated. We are careful to not stop processing it
* prematurely, since we want to handle half-open connections as well as possible and want to flush
* out and read data before we close down if we can. */