docs: fix typos and grammar in various documents

docs/CATALOG.md

@@ -57,7 +57,7 @@ The text format of the .catalog files is as follows:
   For each message ID (in combination with a locale) only a single entry may be defined.
   Every entry consists of:
     * A separator line beginning with `-- `, followed by a hexadecimal message ID formatted as lower case ASCII string.
-    Optionally, the message ID may be suffixed by a space and a locale identifier, such as `de` or `fr\_FR`, if i10n is required.
+    Optionally, the message ID may be suffixed by a space and a locale identifier, such as `de` or `fr_FR`, if l10n is required.
     * A series of entry headers, in RFC822-style but not supporting continuation lines.
     Some header fields may appear more than once per entry.
     The following header fields are currently known (but additional fields may be added later):

docs/CONTROL_GROUP_INTERFACE.md

@@ -203,9 +203,9 @@ To create and start a transient (scope, service or slice) unit in the cgroup tre
 
 The properties array of `StartTransientUnit()` may take many of the settings that may also be configured in unit files. Not all parameters are currently accepted though, but we plan to cover more properties with future release. Currently you may set the `Description`, `Slice` and all dependency types of units, as well as `RemainAfterExit`, `ExecStart` for service units, `TimeoutStopUSec` and `PIDs` for scope units, and `CPUAccounting`, `CPUShares`, `BlockIOAccounting`, `BlockIOWeight`, `BlockIOReadBandwidth`, `BlockIOWriteBandwidth`, `BlockIODeviceWeight`, `MemoryAccounting`, `MemoryLimit`, `DevicePolicy`, `DeviceAllow` for services/scopes/slices. These fields map directly to their counterparts in unit files and as normal D-Bus object properties. The exception here is the `PIDs` field of scope units which is used for construction of the scope only and specifies the initial PIDs to add to the scope object.
 
-To alter resource control properties at runtime use the `SetUnitProperty()` call on the `Manager` object or `SetProperty()` on the individual Unit objects. This also takes an array of properties to set, in the same format as `StartTransientUnit()` takes. Note again that this is not a dictionary, and allows properties to be set multiple times with a single invocation. THis is useful for array properties: if a property is assigned the empty array it will be reset to the empty array itself, however if it is assigned a non-empty array then this array is appended to the previous array. This mimics behaviour of array settings in unit files. Note that most settings may only be set during creation of units with `StartTransientUnit()`, and may not be altered later on. The exception here are the resource control settings, more specifically `CPUAccounting`, `CPUShares`, `BlockIOAccounting`, `BlockIOWeight`, `BlockIOReadBandwidth`, `BlockIOWriteBandwidth`, `BlockIODeviceWeight`, `MemoryAccounting`, `MemoryLimit`, `DevicePolicy`, `DeviceAllow` for services/scopes/slices. Note that the standard D-Bus `org.freedesktop.DBus.Properties.Set()` call is currently not supported by any of the unit objects to set these properties, but might eventually (note however, that it is substantially less useful as it only allows setting a single property at a time, resulting in races).
+To alter resource control properties at runtime use the `SetUnitProperties()` call on the `Manager` object or `SetProperties()` on the individual Unit objects. This also takes an array of properties to set, in the same format as `StartTransientUnit()` takes. Note again that this is not a dictionary, and allows properties to be set multiple times with a single invocation. This is useful for array properties: if a property is assigned the empty array it will be reset to the empty array itself, however if it is assigned a non-empty array then this array is appended to the previous array. This mimics behaviour of array settings in unit files. Note that most settings may only be set during creation of units with `StartTransientUnit()`, and may not be altered later on. The exception here are the resource control settings, more specifically `CPUAccounting`, `CPUShares`, `BlockIOAccounting`, `BlockIOWeight`, `BlockIOReadBandwidth`, `BlockIOWriteBandwidth`, `BlockIODeviceWeight`, `MemoryAccounting`, `MemoryLimit`, `DevicePolicy`, `DeviceAllow` for services/scopes/slices. Note that the standard D-Bus `org.freedesktop.DBus.Properties.Set()` call is currently not supported by any of the unit objects to set these properties, but might eventually (note however, that it is substantially less useful as it only allows setting a single property at a time, resulting in races).
 
-The [`systemctl set-property`](https://www.freedesktop.org/software/systemd/man/latest/systemctl.html) command internally is little more than a wrapper around `SetUnitProperty()`. The [`systemd-run`](https://www.freedesktop.org/software/systemd/man/latest/systemd-run.html) tool is a wrapper around `StartTransientUnit()`. It may be used to either run a process as a transient service in the background, where it is invoked from PID 1, or alternatively as a scope unit in the foreground, where it is run from the `systemd-run` process itself.
+The [`systemctl set-property`](https://www.freedesktop.org/software/systemd/man/latest/systemctl.html) command internally is little more than a wrapper around `SetUnitProperties()`. The [`systemd-run`](https://www.freedesktop.org/software/systemd/man/latest/systemd-run.html) tool is a wrapper around `StartTransientUnit()`. It may be used to either run a process as a transient service in the background, where it is invoked from PID 1, or alternatively as a scope unit in the foreground, where it is run from the `systemd-run` process itself.
 
 ### Enumeration
 

docs/CREDENTIALS.md

@@ -503,7 +503,7 @@ systemd-nspawn -i test.raw  \
 ```
 
 This boots the specified disk image as `systemd-nspawn` container, and passes
-the root password `mysecret`and default locale `C.UTF-8` to use to it. This
+the root password `mysecret` and the default locale `C.UTF-8` to it. This
 data is then propagated by default to `systemd-sysusers.service` and
 `systemd-firstboot.service`, where it is applied. (Note that these services
 will only do so if these settings in `/etc/` are so far unset, i.e. they only

docs/FILE_DESCRIPTOR_STORE.md

@@ -9,7 +9,7 @@ SPDX-License-Identifier: LGPL-2.1-or-later
 
 *TL;DR: The systemd service manager may optionally maintain a set of file
 descriptors for each service. Those file descriptors are under control of the
-service. Storing file descriptors in the manager makes is easier to restart
+service. Storing file descriptors in the manager makes it easier to restart
 services without dropping connections or losing state.*
 
 Since its inception `systemd` has supported the *socket* *activation*

docs/HOME_DIRECTORY.md

@@ -133,7 +133,7 @@ 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 necessary to validate the home directory image *before* mounting it and establishing a minimal level of trust.
 Since the user record data is cryptographically signed and user records not signed with a recognized private
-key are not accepted, a minimal level of trust between the system and the homedirectory image is established.
+key are not accepted, a minimal level of trust between the system and the home directory image is established.
 
 Rationale for storing the home directory one level below to root directory of
 the contained file system:

docs/PORTABLE_SERVICES.md

@@ -332,7 +332,7 @@ services copied onto the host.
 
 ## Logging
 
-Several fields are autotmatically added to log messages generated by a portable
+Several fields are automatically added to log messages generated by a portable
 service (or about a portable service, e.g.: start/stop logs from systemd).
 The `PORTABLE=` field will refer to the name of the portable image where the unit
 was loaded from. In case extensions are used, additionally there will be a `PORTABLE_ROOT=` field, referring to the name of the image used as the base layer (i.e.: `RootImage=` or `RootDirectory=`), and one `PORTABLE_EXTENSION=` field for

docs/RANDOM_SEEDS.md

@@ -105,7 +105,7 @@ systemd itself requires random numbers as well, including for the following uses
   and thus the runtime context the service manager maintains can be neatly matched up with
   the log data a specific service invocation generated.
   systemd also initializes `/etc/machine-id` with a randomized UUID.
-  (systemd also makes use of the randomized "boot id" the kernel exposes in `/proc/sys/kernel/random boot_id`).
+  (systemd also makes use of the randomized "boot id" the kernel exposes in `/proc/sys/kernel/random/boot_id`).
   These UUIDs are exclusively Type 4 UUIDs, i.e. randomly generated ones.
 
 * systemd maintains various hash tables internally.

docs/RESOLVED-VPNS.md

@@ -98,13 +98,13 @@ interfaces are "merged": domains existing on one but not the other will "just
 work" and vice versa.
 
 And one more note: the domain routing logic implemented is a tiny bit more
-complex that what described above: if there two interfaces have search domains
+complex than what is described above: if two interfaces have search domains
-that are suffix of each other, and a name is looked up that matches both, the
+that are suffixes of each other, and a name is looked up that matches both, the
-interface with the longer match will win and get the lookup routed to is DNS
+interface with the longer match will win and get the lookup routed to its DNS
 servers. Only if the match has the same length, then both will be used in
 parallel. Example: one interface has `~foo.example.com` as routing domain, and
-another one `example.com` has search domain. A lookup for
+another one has `example.com` as search domain. A lookup for
-`waldo.foo.example.com` is the exclusively routed to the first interface's DNS
+`waldo.foo.example.com` is exclusively routed to the first interface's DNS
 server, since it matches by three suffix labels instead of just two. The fact
 that the matching length is taken into consideration for the routing decision
 is particularly relevant if you have one interface with the `~.` routing domain

docs/ROOTFS_DISCOVERY.md

@@ -362,7 +362,7 @@ typically requires enrolment of TLS server certificates in the system
 firmware, but provides transport integrity, authenticity and
 confidentiality. Acquiring the various resources via plain HTTP should
 generally be sufficient too, as the key resources acquired this way
-area generally authenticated before use via other mechanisms, see above.
+are generally authenticated before use via other mechanisms, see above.
 
 ## Building
 

docs/SYSTEMD_FILE_HIERARCHY_REQUIREMENTS.md

@@ -17,7 +17,7 @@ In systemd we leave much of the file system layout open to the operating system,
   All of them must be available before the host systemd is first executed.
 
 - `/var` does not have to be mounted when the host systemd is first invoked, however,
-  it must be configured so that it is mounted writable before local-fs.target is reached (for example, by simply listing it in` /etc/fstab`).
+  it must be configured so that it is mounted writable before local-fs.target is reached (for example, by simply listing it in `/etc/fstab`).
 
 - `/tmp` is recommended to be a tmpfs (default), but doesn't have to.
   If configured, it must be mounted before local-fs.target is reached (for example, by listing it in `/etc/fstab`).

docs/TPM2_PCR_MEASUREMENTS.md

@@ -402,5 +402,5 @@ about activated Verity images before they are activated.
 → **Measured hash** covers the string `verity:`, followed by the Verity device
 name, followed by `:`, followed by a hexadecimal formatted string indicating
 the root hash of the Verity image, followed by `:`, followed by a comma
-separatec list of PKCS#7 signature key's serial (formatted in hexadecimal), `/`, and
+separated list of PKCS#7 signature key's serial (formatted in hexadecimal), `/`, and
 key issuer (formatted in Base64).

docs/WRITING_RESOLVER_CLIENTS.md

@@ -20,7 +20,7 @@ _`systemd-resolved`_ provides a set of APIs on the bus for resolving DNS resourc
 
 Below you'll find examples for two of these calls, to show how to use them.
 Note that glibc offers similar (and more portable) calls in _getaddrinfo()_, _getnameinfo()_ and _res\_query()_.
-Of these _getaddrinfo()_ and _getnameinfo()_ are directed to the calls above via the _nss-resolve_ NSS module, but _req\_query()_ is not.
+Of these _getaddrinfo()_ and _getnameinfo()_ are directed to the calls above via the _nss-resolve_ NSS module, but _res\_query()_ is not.
 There are a number of reasons why it might be preferable to invoke `systemd-resolved`'s bus calls rather than the glibc APIs:
 
 1. Bus APIs are naturally asynchronous, which the glibc APIs generally are not.
@@ -88,7 +88,7 @@ int main(int argc, char*argv[]) {
                                AF_UNSPEC,                                /* Which address family to look for */
                                UINT64_C(0));                             /* Input flags parameter */
         if (r < 0) {
-               fprintf(stderr, "Failed to resolve hostnme: %s\n", error.message);
+                fprintf(stderr, "Failed to resolve hostname: %s\n", error.message);
                 sd_bus_error_free(&error);
                 goto finish;
         }