From 496712eddcd4356f63d3271023dd33c0a404dd06 Mon Sep 17 00:00:00 2001 From: Yu Watanabe Date: Wed, 16 Sep 2026 05:07:01 +0900 Subject: [PATCH] docs: fix typos and grammar in various documents --- docs/CATALOG.md | 2 +- docs/CONTROL_GROUP_INTERFACE.md | 4 ++-- docs/CREDENTIALS.md | 2 +- docs/FILE_DESCRIPTOR_STORE.md | 2 +- docs/HOME_DIRECTORY.md | 2 +- docs/PORTABLE_SERVICES.md | 2 +- docs/RANDOM_SEEDS.md | 2 +- docs/RESOLVED-VPNS.md | 10 +++++----- docs/ROOTFS_DISCOVERY.md | 2 +- docs/SYSTEMD_FILE_HIERARCHY_REQUIREMENTS.md | 2 +- docs/TPM2_PCR_MEASUREMENTS.md | 2 +- docs/WRITING_RESOLVER_CLIENTS.md | 4 ++-- 12 files changed, 18 insertions(+), 18 deletions(-) diff --git a/docs/CATALOG.md b/docs/CATALOG.md index 0b8b9c0462..fdd0245ada 100644 --- a/docs/CATALOG.md +++ b/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): diff --git a/docs/CONTROL_GROUP_INTERFACE.md b/docs/CONTROL_GROUP_INTERFACE.md index 3490c1a4b9..573e1a0e4d 100644 --- a/docs/CONTROL_GROUP_INTERFACE.md +++ b/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 diff --git a/docs/CREDENTIALS.md b/docs/CREDENTIALS.md index 5260db6b33..d2303f6771 100644 --- a/docs/CREDENTIALS.md +++ b/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 diff --git a/docs/FILE_DESCRIPTOR_STORE.md b/docs/FILE_DESCRIPTOR_STORE.md index 6e17445105..693562f31d 100644 --- a/docs/FILE_DESCRIPTOR_STORE.md +++ b/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* diff --git a/docs/HOME_DIRECTORY.md b/docs/HOME_DIRECTORY.md index 0ef39e9737..9d85441525 100644 --- a/docs/HOME_DIRECTORY.md +++ b/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: diff --git a/docs/PORTABLE_SERVICES.md b/docs/PORTABLE_SERVICES.md index 79b34ee870..74ae0cca08 100644 --- a/docs/PORTABLE_SERVICES.md +++ b/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 diff --git a/docs/RANDOM_SEEDS.md b/docs/RANDOM_SEEDS.md index 3dd135baf8..61245a0c27 100644 --- a/docs/RANDOM_SEEDS.md +++ b/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. diff --git a/docs/RESOLVED-VPNS.md b/docs/RESOLVED-VPNS.md index 6f013175e7..cfd4c76eb4 100644 --- a/docs/RESOLVED-VPNS.md +++ b/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 -that are suffix 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 +complex than what is described above: if two interfaces have search domains +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 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 -`waldo.foo.example.com` is the exclusively routed to the first interface's DNS +another one has `example.com` as search domain. A lookup for +`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 diff --git a/docs/ROOTFS_DISCOVERY.md b/docs/ROOTFS_DISCOVERY.md index c58f44abcb..c2770a600e 100644 --- a/docs/ROOTFS_DISCOVERY.md +++ b/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 diff --git a/docs/SYSTEMD_FILE_HIERARCHY_REQUIREMENTS.md b/docs/SYSTEMD_FILE_HIERARCHY_REQUIREMENTS.md index 81d6f437d7..8db932d146 100644 --- a/docs/SYSTEMD_FILE_HIERARCHY_REQUIREMENTS.md +++ b/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`). diff --git a/docs/TPM2_PCR_MEASUREMENTS.md b/docs/TPM2_PCR_MEASUREMENTS.md index b249db0e82..2b99b106fd 100644 --- a/docs/TPM2_PCR_MEASUREMENTS.md +++ b/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). diff --git a/docs/WRITING_RESOLVER_CLIENTS.md b/docs/WRITING_RESOLVER_CLIENTS.md index 93c51c5388..27363e1256 100644 --- a/docs/WRITING_RESOLVER_CLIENTS.md +++ b/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; }