For written text, contractions are not normally used.
if __name__ == '__main__':
path = os.environ['PATH'] # This should be always set.
- # If it's not, we'll just crash, which is OK too.
+ # If it is not, we will just crash, which is OK too.
new = rearrange_bin_sbin(path)
if new != path:
print('PATH={}'.format(new))
remaining file systems, kill any remaining processes and release any other remaining resources, in a simple and
robust fashion, without taking any service or unit concept into account anymore. At that point, regular
applications and resources are generally terminated and released already, the second phase hence operates only as
- safety net for everything that couldn't be stopped or released for some reason during the primary, unit-based
+ safety net for everything that could not be stopped or released for some reason during the primary, unit-based
shutdown phase described above.</para>
</refsect1>
<citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>
units marked with <option>x-initrd.mount</option>.</para>
- <para>Although it's not necessary to mark the mount entry for the root file system with
+ <para>Although it is not necessary to mark the mount entry for the root file system with
<option>x-initrd.mount</option>, <option>x-initrd.attach</option> is still recommended with
the encrypted block device containing the root file system as otherwise systemd will
- attempt to detach the device during the regular system shutdown while it's still in
+ attempt to detach the device during the regular system shutdown while it is still in
use. With this option the device will still be detached but later after the root file
system is unmounted.</para>
<refsect1>
<title>Miscellaneous options and directives</title>
- <para>Other configuration elements which don't fit in any of the above groups.</para>
+ <para>Other configuration elements which do not fit in any of the above groups.</para>
<variablelist id='miscellaneous' />
</refsect1>
sudo systemd-cryptsetup attach mytest /dev/sdXn - fido2-device=auto
# If that worked, let's now add the same line persistently to /etc/crypttab,
-# for the future. We don't want to use the (unstable) /dev/sdX name, so let's
+# for the future. We do not want to use the (unstable) /dev/sdX name, so let's
# figure out a stable link:
udevadm info -q symlink -r /dev/sdXn
<listitem><para>If the boot partition <filename>/boot/</filename> is maintained separately from the
EFI System Partition (ESP), the latter is mounted here. Tools that need to operate on the EFI system
partition should look for it at this mount point first, and fall back to <filename>/boot/</filename>
- — if the former doesn't qualify (for example if it is not a mount point or does not have the correct
+ — if the former does not qualify (for example if it is not a mount point or does not have the correct
file system type <constant>MSDOS_SUPER_MAGIC</constant>).</para></listitem>
</varlistentry>
possible to mount them <option>noexec</option>, because various programs use those directories for
dynamically generated or optimized code, and with that flag those use cases would break. Using this
flag is OK on special-purpose installations or systems where all software that may be installed is
- known and doesn't require such functionality. See the discussion of
+ known and does not require such functionality. See the discussion of
<option>nosuid</option>/<option>nodev</option>/<option>noexec</option> in <citerefentry
project='man-pages'><refentrytitle>mount</refentrytitle><manvolnum>8</manvolnum></citerefentry> and
<constant>PROT_EXEC</constant> in <citerefentry
sessions of the user ended. The default is configured in
<citerefentry><refentrytitle>logind.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> (for
home directories of LUKS2 storage located on removable media this defaults to 0 though). A longer
- time makes sure quick, repetitive logins are more efficient as the user's service manager doesn't
+ time makes sure quick, repetitive logins are more efficient as the user's service manager does not
have to be started every time.</para>
<xi:include href="version-info.xml" xpointer="v245"/></listitem>
# Create a self-signed certificate from this public key, and store it on the device.
ykman piv generate-certificate --subject "Knobelei" 9d pubkey.pem
-# We don't need the public key on disk anymore
+# We do not need the public key on disk anymore
rm pubkey.pem
# Allow the security token to unlock the account of user 'lafcadio'.
<varlistentry>
<term><option>--no-hostname</option></term>
- <listitem><para>Don't show the hostname field of log messages originating from the local host. This
+ <listitem><para>Do not show the hostname field of log messages originating from the local host. This
switch has an effect only on the <option>short</option> family of output modes (see above).</para>
<para>Note: this option does not remove occurrences of the hostname from log entries themselves, so
where the console is often a slow, virtual serial port.
Since journald is implemented as a conventional single-process daemon, forwarding to a completely
hung console will block journald. This can have a cascading effect resulting in any services synchronously
- logging to the blocked journal also becoming blocked. Unless actively debugging/developing something, it's
+ logging to the blocked journal also becoming blocked. Unless actively debugging/developing something, it is
generally preferable to setup a <command>journalctl --follow</command> style service redirected to the
console, instead of ForwardToConsole=yes, for production use.</para>
</listitem>
<programlisting>dd if=/dev/urandom bs=512 count=1 status=none | base64 -w 0</programlisting>
- <para>Again: do not use this option outside of testing environments, it's a security risk elsewhere,
+ <para>Again: do not use this option outside of testing environments, it is a security risk elsewhere,
as secret key material derived from the entropy pool can possibly be reconstructed by unprivileged
programs.</para>
</variablelist>
<para><varname>$KERNEL_INSTALL_MACHINE_ID</varname> is set for the plugins to the desired machine-id to
- use. It's always a 128-bit ID. Normally it's read from <filename>/etc/machine-id</filename>, but it can
+ use. It's always a 128-bit ID. Normally it is read from <filename>/etc/machine-id</filename>, but it can
also be overridden via <varname>$MACHINE_ID</varname> (see below). If not specified via these methods,
a fallback value will generated by <command>kernel-install</command> and used only for a single
invocation.</para>
<para><varname>$KERNEL_INSTALL_LAYOUT=auto|bls|uki|other|...</varname> is set for the plugins to specify the
installation layout. Additional layout names may be defined by convention. If a plugin uses a special layout,
- it's encouraged to declare its own layout name and configure <varname>layout=</varname> in
+ it is encouraged to declare its own layout name and configure <varname>layout=</varname> in
<filename>install.conf</filename> upon initial installation. The following values are currently
understood:</para>
<listitem><para>Specifies a timeout in seconds, or a time span value after which
<filename>systemd-logind</filename> checks the idle state of all sessions. Every session that is idle
- for longer than the timeout will be stopped. Note that this option doesn't apply to
+ for longer than the timeout will be stopped. Note that this option does not apply to
<literal>greeter</literal> or <literal>lock-screen</literal> sessions. Defaults to
<literal>infinity</literal> (<filename>systemd-logind</filename> is not checking the idle state
of sessions). For details about the syntax of time spans, see
<listitem><para>Edit the settings file of the specified machines. For the format of the settings
file, refer to
<citerefentry project='man-pages'><refentrytitle>systemd.nspawn</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
- If an existing settings file of the given machine can't be found, <command>edit</command>
+ If an existing settings file of the given machine cannot be found, <command>edit</command>
automatically create a new settings file from scratch under
<filename>/etc/systemd/nspawn/</filename>.
</para>
<term>pending</term>
<listitem>
<para><citerefentry><refentrytitle>systemd-udevd</refentrytitle><manvolnum>8</manvolnum></citerefentry>
- is still processing the link, we don't yet know if we will manage it.</para>
+ is still processing the link, we do not yet know if we will manage it.</para>
<xi:include href="version-info.xml" xpointer="v240"/>
</listitem>
<term>initialized</term>
<listitem>
<para><citerefentry><refentrytitle>systemd-udevd</refentrytitle><manvolnum>8</manvolnum></citerefentry>
- has processed the link, but we don't yet know if we will manage it.</para>
+ has processed the link, but we do not yet know if we will manage it.</para>
<xi:include href="version-info.xml" xpointer="v251"/>
</listitem>
<citerefentry><refentrytitle>systemd-homed.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>, or <citerefentry><refentrytitle>systemd-machined.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
<para>This module also ensures that the root and nobody users and groups (i.e. the users/groups with the UIDs/GIDs
- 0 and 65534) remain resolvable at all times, even if they aren't listed in <filename>/etc/passwd</filename> or
+ 0 and 65534) remain resolvable at all times, even if they are not listed in <filename>/etc/passwd</filename> or
<filename>/etc/group</filename>, or if these files are missing.</para>
<para>This module preferably utilizes
operate like their matching counterparts on the <classname>org.freedesktop.home1.Manager</classname>
interface (see above). The main difference is that they are methods of the home directory objects, and
hence carry no additional user name parameter. Which of the two flavors of methods to call depends on
- the handles to the user known on the client side: if only the user name is known, it's preferable to use
+ the handles to the user known on the client side: if only the user name is known, it is preferable to use
the methods on the manager object since they operate with user names only. Clients can also easily operate
on their own home area by using the methods on the manager object with an empty string as the user name.
If the client has the home's object path already acquired in some way, however, it is preferable to operate
only works on devices that are attached to the seat of the given session. A process is not required to
have direct access to the device node. <filename>systemd-logind</filename> only requires you to be the
active session controller (see <function>TakeControl()</function>). Also note that any device can only
- be requested once. As long as you don't release it, further <function>TakeDevice()</function> calls
+ be requested once. As long as you do not release it, further <function>TakeDevice()</function> calls
will fail.</para>
<para><function>ReleaseDevice()</function> releases a device again (see
notification. <function>pause</function> means <filename>systemd-logind</filename> grants you a limited amount of time to pause the device. You must respond to this via
<function>PauseDeviceComplete()</function>. This synchronous pausing mechanism is used for
backwards-compatibility to VTs and <filename>systemd-logind</filename> is free to not make use of
- it. It is also free to send a forced <function>PauseDevice()</function> if you don't respond in a timely
+ it. It is also free to send a forced <function>PauseDevice()</function> if you do not respond in a timely
manner (or for any other reason). <function>gone</function> means the device was unplugged from the
system and you will no longer get any notifications about it. There is no need to call
<function>ReleaseDevice()</function>. You may call <function>TakeDevice()</function> again if a new
its dependencies, possibly replacing already queued jobs that conflict with it. If
<literal>fail</literal>, the method will start the unit and its dependencies, but will fail if this would
change an already queued job. If <literal>isolate</literal>, the method will start the unit in question
- and terminate all units that aren't dependencies of it. If <literal>ignore-dependencies</literal>, it
+ and terminate all units that are not dependencies of it. If <literal>ignore-dependencies</literal>, it
will start a unit but ignore all its dependencies. If <literal>ignore-requirements</literal>, it will
start a unit but only ignore the requirement dependencies. It is not recommended to make use of the
latter two options. On reply, if successful, this method returns the newly created job object
<function>TryRestartUnit()</function>, <function>ReloadOrRestartUnit()</function>, or
<function>ReloadOrTryRestartUnit()</function> may be used to restart and/or reload a unit. These methods take
similar arguments as <function>StartUnit()</function>. Reloading is done only if the unit is already
- running and fails otherwise. If a service is restarted that isn't running, it will be started unless
- the "Try" flavor is used in which case a service that isn't running is not affected by the restart. The
+ running and fails otherwise. If a service is restarted that is not running, it will be started unless
+ the "Try" flavor is used in which case a service that is not running is not affected by the restart. The
"ReloadOrRestart" flavors attempt a reload if the unit supports it and use a restart otherwise.</para>
<para><function>EnqueueMarkedJobs()</function> creates reload/restart jobs for units which have been
<literal>failed</literal>, <literal>dependency</literal>, or
<literal>skipped</literal>. <literal>done</literal> indicates successful execution of a
job. <literal>canceled</literal> indicates that a job has been canceled (via
- <function>CancelJob()</function> above) before it finished execution (this doesn't necessarily mean
+ <function>CancelJob()</function> above) before it finished execution (this does not necessarily mean
though that the job operation is actually cancelled too, see above). <literal>timeout</literal>
indicates that the job timeout was reached. <literal>failed</literal> indicates that the job
failed. <literal>dependency</literal> indicates that a job this job depended on failed and the job hence
was removed as well. <literal>skipped</literal> indicates that a job was skipped because
- it didn't apply to the unit's current state.</para>
+ it did not apply to the unit's current state.</para>
<para><function>StartupFinished()</function> is sent out when startup finishes. It carries six
microsecond timespan values, each indicating how much boot time has been spent in the firmware (if
reboot). <literal>masked</literal> indicates that the unit file is masked permanently.
<literal>masked-runtime</literal> indicates that it is masked in <filename>/run/</filename> temporarily
(until the next reboot). <literal>static</literal> indicates that the unit is statically enabled, i.e.
- always enabled and doesn't need to be enabled explicitly. <literal>invalid</literal> indicates that it
+ always enabled and does not need to be enabled explicitly. <literal>invalid</literal> indicates that it
could not be determined whether the unit file is enabled.</para>
<para><varname>InactiveExitTimestamp</varname>, <varname>InactiveExitTimestampMonotonic</varname>,
five fields are given: condition type (e.g. <varname>ConditionPathExists</varname>), whether the
condition is a trigger condition, whether the condition is reversed, the right hand side of the
condition (e.g. the path in case of <varname>ConditionPathExists</varname>), and the status. The status
- can be 0, in which case the condition hasn't been checked yet, a positive value, in which case the
+ can be 0, in which case the condition has not been checked yet, a positive value, in which case the
condition passed, or a negative value, in which case the condition is not met. Currently only 0, +1, and -1
are used, but additional values may be used in the future, retaining the meaning of
zero/positive/negative values.</para>
with runtime data.</para>
<para><varname>LimitCPU</varname> (and related properties) map more or less directly to the
- corresponding settings in the service unit files except that if they aren't set, their value is
+ corresponding settings in the service unit files except that if they are not set their value is
18446744073709551615 (i.e. -1).</para>
<para><varname>Capabilities</varname> contains the configured capabilities, as formatted with
<para><varname>Result</varname> encodes the execution result of the last run of the service. It is
useful to determine the reason a service failed if it is in the <literal>failed</literal> state (see
<varname>ActiveState</varname> above). The following values are currently known:
- <literal>success</literal> is set if the unit didn't fail. <literal>resources</literal> indicates that
+ <literal>success</literal> is set if the unit did not fail. <literal>resources</literal> indicates that
not enough resources were available to fork off and execute the service
processes. <literal>timeout</literal> indicates that a timeout occurred while executing a service
operation. <literal>exit-code</literal> indicates that a service process exited with an unclean exit
software center to correctly associate the catalogs with this target.</para>
<para><function>GetVersion()</function> returns the current version of this target, if any. The current
- version is the newest version that is installed. Note that this isn't necessarily the same thing as the
+ version is the newest version that is installed. Note that this is not necessarily the same thing as the
booted or currently-in-use version of the target. For example, on the host system the booted version
is the current version most of the time, but if an update is installed and pending a reboot it will
become the current version instead. You can query the booted version of the host system via
<para>In the <filename>extension-release.<replaceable>IMAGE</replaceable></filename> filename, the
<replaceable>IMAGE</replaceable> part must exactly match the file name of the containing image with the
- suffix removed. In case it is not possible to guarantee that an image file name is stable and doesn't
+ suffix removed. In case it is not possible to guarantee that an image file name is stable and does not
change between the build and the deployment phases, it is possible to relax this check: if exactly one
file whose name matches <literal><filename>extension-release.*</filename></literal> is present in this
directory, and the file is tagged with a <varname>user.extension-release.strict</varname>
user concurrently uses graphical login sessions that implement the required re-authentication
mechanism and console logins that do not, the home directory is not locked during suspend, due to the
logic explained above. That said, it is possible to set this field for TTY logins too, ignoring the
- fact that TTY logins actually don't support the re-authentication mechanism. In that case the TTY
+ fact that TTY logins actually do not support the re-authentication mechanism. In that case the TTY
sessions will appear hung until the user logs in on another virtual terminal (regardless of whether via
another TTY session or graphically) which will resume the home directory and unblock the original TTY
session. (Do note that lack of screen locking on TTY sessions means even though the TTY session
<listitem><para>Detaches an existing portable service image from the host, and immediately attaches it again.
This is useful in case the image was replaced. Running units are not stopped during the process. Partial matching,
to allow for different versions in the image name, is allowed: only the part before the first <literal>_</literal>
- character has to match. If the new image doesn't exist, the existing one will not be detached. The parameters
+ character has to match. If the new image does not exist, the existing one will not be detached. The parameters
follow the same syntax as the <command>attach</command> command.</para>
<para>If <option>--now</option> and/or <option>--enable</option> are passed, the portable services are
<varlistentry>
<term><option>--no-reload</option></term>
- <listitem><para>Don't reload the service manager after attaching or detaching a portable service
+ <listitem><para>Do not reload the service manager after attaching or detaching a portable service
image. Normally the service manager is reloaded to ensure it is aware of added or removed unit
files.</para>
<varlistentry>
<term><option>--no-block</option></term>
- <listitem><para>Don't block waiting for attach --now to complete.</para>
+ <listitem><para>Do not block waiting for attach --now to complete.</para>
<xi:include href="version-info.xml" xpointer="v245"/></listitem>
</varlistentry>
<term><option>-n</option></term>
<term><option>--no-sync</option></term>
- <listitem><para>Don't sync hard disks/storage media before power-off, reboot, or halt.
+ <listitem><para>Do not sync hard disks/storage media before power-off, reboot, or halt.
</para>
<xi:include href="version-info.xml" xpointer="v253"/></listitem>
<para>This option has no effect if the partition it is declared for already exists, i.e. existing
data is never overwritten. Note that the data is copied in before the partition table is updated,
i.e. before the partition actually is persistently created. This provides robustness: it is
- guaranteed that the partition either doesn't exist or exists fully populated; it is not possible that
+ guaranteed that the partition either does not exist or exists fully populated; it is not possible that
the partition exists but is not or only partially populated.</para>
<para>This option cannot be combined with <varname>Format=</varname> or
<para>The copy operation is executed before the file system is registered in the partition table,
thus ensuring that a file system populated this way only ever exists fully initialized.</para>
- <para>Note that <varname>CopyFiles=</varname> will skip copying files that aren't supported by the
+ <para>Note that <varname>CopyFiles=</varname> will skip copying files that are not supported by the
target filesystem (e.g symlinks, fifos, sockets and devices on vfat). When an unsupported file type
is encountered, <command>systemd-repart</command> will skip copying this file and write a log message
about it.</para>
<varlistentry>
<term><varname>CacheFromLocalhost=</varname></term>
<listitem><para>Takes a boolean as argument. If <literal>no</literal> (the default), and response cames from
- host-local IP address (such as 127.0.0.1 or ::1), the result wouldn't be cached in order to avoid
+ host-local IP address (such as 127.0.0.1 or ::1), the result would not be cached in order to avoid
potential duplicate local caching.</para>
<xi:include href="version-info.xml" xpointer="v248"/>
<para>This is useful when a DNS server failure occurs or becomes unreachable. In such cases,
<citerefentry><refentrytitle>systemd-resolved</refentrytitle><manvolnum>8</manvolnum></citerefentry>
continues to use the stale records to answer DNS queries, particularly when no valid response can be
- obtained from the upstream DNS servers. However, this doesn't apply to NXDOMAIN responses, as those
+ obtained from the upstream DNS servers. However, this does not apply to NXDOMAIN responses, as those
are still perfectly valid responses. This feature enhances resilience against DNS infrastructure
failures and outages.</para>
<para>The API's central data structure is <type>JsonVariant</type> which encapsulates a JSON object,
array, string, boolean, number or null value. These data structures are mostly considered immutable after
- construction (i.e. their contents won't change, but some meta-data might, such as reference counters).</para>
+ construction (i.e. their contents will not change, but some meta-data might, such as reference counters).</para>
<para>The APIs broadly fall into five categories:</para>
<constant>CLOCK_MONOTONIC</constant> and specified in microseconds. When converting this value in order
to pass it as third argument to <function>poll()</function> (which expects relative milliseconds), care
should be taken to convert to a relative time and use a division that rounds up to ensure the I/O polling
- operation doesn't sleep for shorter than necessary, which might result in unintended busy looping
+ operation does not sleep for shorter than necessary, which might result in unintended busy looping
(alternatively, use <citerefentry
project='man-pages'><refentrytitle>ppoll</refentrytitle><manvolnum>2</manvolnum></citerefentry> instead
of plain <function>poll()</function>, which understands timeouts with nano-second granularity).</para>
<para>Read a boolean value:</para>
<programlisting>sd_bus_message *m;
-int x; /* Do not use C99 'bool' type here, it's typically smaller
+int x; /* Do not use C99 "bool" type here, it is typically smaller
in memory and would cause memory corruption */
sd_bus_message_read(m, "b", &x);</programlisting>
corresponding request. <parameter>timeout_usec</parameter> specifies the maximum time in
microseconds to wait for a reply to arrive.</para>
- <para>Note that in most scenarios, it's not necessary to call this function directly.
+ <para>Note that in most scenarios, it is not necessary to call this function directly.
<citerefentry><refentrytitle>sd_bus_call</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
<citerefentry><refentrytitle>sd_bus_call_async</refentrytitle><manvolnum>3</manvolnum></citerefentry> and
<citerefentry><refentrytitle>sd_bus_send</refentrytitle><manvolnum>3</manvolnum></citerefentry>
sensitive data. This ensures that the message data is carefully removed from memory (specifically,
overwritten with zero bytes) when released. It is recommended to mark all incoming and outgoing messages
like this that contain security credentials and similar data that should be dealt with carefully. Note
- that it is not possible to unmark messages like this, it's a one way operation. If a message is already
+ that it is not possible to unmark messages like this, it is a one way operation. If a message is already
marked sensitive and then marked sensitive a second time the message remains marked so and no further
operation is executed.</para>
<function>sd_bus_message_get_member()</function> return the destination, path, interface, and
member fields from <parameter>message</parameter> header. The return value will be
<constant>NULL</constant> is <parameter>message</parameter> is <constant>NULL</constant> or the
- message is of a type that doesn't use those fields or the message doesn't have them set. See
+ message is of a type that does not use those fields or the message does not have them set. See
<citerefentry><refentrytitle>sd_bus_message_new_method_call</refentrytitle><manvolnum>3</manvolnum></citerefentry> and
<citerefentry><refentrytitle>sd_bus_message_set_destination</refentrytitle><manvolnum>3</manvolnum></citerefentry>
for more discussion of those values.</para>
<para>When a string is returned, it is a pointer to internal storage, and may not be modified or
freed. It is only valid as long as the <parameter>message</parameter> remains referenced and
- this field hasn't been changed by a different call.</para>
+ this field has not been changed by a different call.</para>
</refsect1>
<refsect1>
for a list of possible flags. First, this message checks if the requested credentials are attached to the
message itself. If not, but the message contains the pid of the sender and the caller specified the
<constant index='false'>SD_BUS_CREDS_AUGMENT</constant> flag, this function tries to figure out
- the missing credentials via other means (starting from the pid). If the pid isn't available but the
+ the missing credentials via other means (starting from the pid). If the PID is not available but the
message has a sender, this function calls
<citerefentry><refentrytitle>sd_bus_get_name_creds</refentrytitle><manvolnum>3</manvolnum></citerefentry>
to get the requested credentials. If the message has no sender (when a direct connection is used), this
<para><function>sd_bus_send()</function> queues the bus message object <parameter>m</parameter> for
transfer. If <parameter>bus</parameter> is <constant>NULL</constant>, the bus that
<parameter>m</parameter> is attached to is used. <parameter>bus</parameter> only needs to be set when the
- message is sent to a different bus than the one it's attached to, for example when forwarding messages.
+ message is sent to a different bus than the one it is attached to, for example when forwarding messages.
If the output parameter <parameter>cookie</parameter> is not <constant>NULL</constant>, it is set to the
message identifier. This value can later be used to match incoming replies to their corresponding
messages. If <parameter>cookie</parameter> is set to <constant>NULL</constant> and the message is not
- sealed, <function>sd_bus_send()</function> assumes the message <parameter>m</parameter> doesn't expect a
+ sealed, <function>sd_bus_send()</function> assumes the message <parameter>m</parameter> does not expect a
reply and adds the necessary headers to indicate this.</para>
<para>Note that in most scenarios, <function>sd_bus_send()</function> should not be called
<citerefentry><refentrytitle>sd_bus_call</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
<citerefentry><refentrytitle>sd_bus_add_match</refentrytitle><manvolnum>3</manvolnum></citerefentry> or
<citerefentry><refentrytitle>sd_bus_request_name</refentrytitle><manvolnum>3</manvolnum></citerefentry>),
- that is used on a connection with this feature enabled that hasn't been established yet, might block
+ that is used on a connection with this feature enabled that has not been established yet, might block
forever if the socket is never created. However, asynchronous remote operations (such as
<citerefentry><refentrytitle>sd_bus_send</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
<citerefentry><refentrytitle>sd_bus_call_async</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
<para>On success, <function>sd_bus_track_add_name()</function> and <function>sd_bus_track_add_sender()</function>
return 0 if the specified name has already been added to the bus peer tracking object before and positive if it
- hasn't. On failure, they return a negative errno-style error code.</para>
+ has not. On failure, they return a negative errno-style error code.</para>
<para><function>sd_bus_track_remove_name()</function> and <function>sd_bus_track_remove_sender()</function> return
positive if the specified name was previously tracked by the bus peer tracking object and has now been removed. In
read from or written to the file descriptor to reset the mask of events seen.</para>
<para>Setting the I/O event mask to watch for to 0 does not mean
- that the event source won't be triggered anymore, as
+ that the event source will not be triggered anymore, as
<constant>EPOLLHUP</constant> and <constant>EPOLLERR</constant>
may be triggered even with a zero event mask. To temporarily
disable an I/O event source use
<para>This event source typically fires on memory pressure stalls, i.e. when operational latency above a
configured threshold already has been seen. This should be taken into consideration when discussing
- whether later latency to re-aquire any released resources is acceptable: it's usually more important to
+ whether later latency to re-aquire any released resources is acceptable: it is usually more important to
think of the latencies that already happened than those coming up in future.</para>
<para>The <function>sd_event_source_set_memory_pressure_type()</function> and
state before it was turned on, for the two signals. By default the two signals are not handled by the
event loop, and Linux' default signal handling for them is in effect.</para>
- <para>It's customary for UNIX programs to exit on either of these two signals, hence it's typically a
+ <para>It is customary for UNIX programs to exit on either of these two signals, hence it is typically a
good idea to enable this functionality for the main event loop of a program.</para>
</refsect1>
return a negative errno-style error code. <function>sd_event_source_is_ratelimited()</function> returns
zero if rate limiting is currently not in effect and greater than zero if it is in effect; it returns a
negative errno-style error code on failure. <function>sd_event_source_leave_ratelimit()</function>
- returns zero if rate limiting wasn't in effect on the specified event source, and positive if it was and
+ returns zero if rate limiting was not in effect on the specified event source, and positive if it was and
rate limiting is now turned off again; it returns a negative errno-style error code on failure.</para>
<refsect2>
<term><constant>-ENOEXEC</constant></term>
<listitem><para><function>sd_event_source_get_ratelimit()</function> was called on an event source
- that doesn't have rate limiting configured.</para>
+ that does not have rate limiting configured.</para>
<xi:include href="version-info.xml" xpointer="v248"/></listitem>
</varlistentry>
<title>Notes</title>
<para>Function <function>sd_journal_get_catalog()</function> is thread-agnostic and only
- a single specific thread may operate on a given object during its entire lifetime. It's safe to allocate multiple
- independent objects and use each from a specific thread in parallel. However, it's not safe to allocate such an
- object in one thread, and operate or free it from any other, even if locking is used to ensure these threads don't
+ a single specific thread may operate on a given object during its entire lifetime. It is safe to allocate multiple
+ independent objects and use each from a specific thread in parallel. However, it is not safe to allocate such an
+ object in one thread, and operate or free it from any other, even if locking is used to ensure these threads do not
operate on it at the very same time.</para>
<para>Function <function>sd_journal_get_catalog_for_message_id()</function> is are thread-safe and may be called in
code. <function>sd_journal_enumerate_data()</function> and
<function>sd_journal_enumerate_available_data()</function> return a positive integer if the next field
has been read, 0 when no more fields remain, or a negative errno-style error code.
- <function>sd_journal_restart_data()</function> doesn't return anything.
+ <function>sd_journal_restart_data()</function> does not return anything.
<function>sd_journal_set_data_threshold()</function> and <function>sd_journal_get_threshold()</function>
return 0 on success or a negative errno-style error code.</para>
code. <function>sd_journal_enumerate_unique()</function> and
<function>sd_journal_query_available_unique()</function> return a positive integer if the next field data
has been read, 0 when no more fields remain, or a negative errno-style error code.
- <function>sd_journal_restart_unique()</function> doesn't return anything.</para>
+ <function>sd_journal_restart_unique()</function> does not return anything.</para>
<refsect2>
<title>Errors</title>
(i.e. <constant>SD_LISTEN_FDS_START</constant>), the remaining descriptors follow at 4, 5, 6, …, if
any.</para>
- <para>The file descriptors passed this way may be closed at will by the processes receiving them: it's up
+ <para>The file descriptors passed this way may be closed at will by the processes receiving them: it is up
to the processes themselves to close them after use or whether to leave them open until the process exits
(in which case the kernel closes them automatically). Note that the file descriptors received by daemons
are duplicates of the file descriptors the service manager originally allocated and bound and of which it
continuously keeps a copy (except if <varname>Accept=yes</varname> is used). This means any socket option
changes and other changes made to the sockets will be visible to the service manager too. Most
- importantly this means it's generally not a good idea to invoke <citerefentry
+ importantly this means it is generally not a good idea to invoke <citerefentry
project='man-pages'><refentrytitle>shutdown</refentrytitle><manvolnum>2</manvolnum></citerefentry> on
such sockets, since it will shut down communication on the file descriptor the service manager holds for
the same socket too. Also note that if a daemon is restarted (and its associated sockets are not) it will
<term>MAINPID=…</term>
<listitem><para>Change the main process ID (PID) of the service. This is especially useful in the case
- where the real main process isn't directly forked off by the service manager.
+ where the real main process is not directly forked off by the service manager.
Example: <literal>MAINPID=4711</literal>.</para>
<xi:include href="version-info.xml" xpointer="v233"/></listitem>
<listitem><para>Tells the service manager to extend the startup, runtime or shutdown service timeout
corresponding the current state. The value specified is a time in microseconds during which the
- service must send a new message. A service timeout will occur if the message isn't received, but only
+ service must send a new message. A service timeout will occur if the message is not received, but only
if the runtime of the current state is beyond the original maximum times of
<varname>TimeoutStartSec=</varname>, <varname>RuntimeMaxSec=</varname>, and
<varname>TimeoutStopSec=</varname>. See
<filename>/usr/lib/systemd/</filename>.
The vendor version of the file contains commented out entries showing the defaults as a guide to the
administrator. Local overrides can also be created by creating drop-ins, as described below. The main
- configuration file can also be edited for this purpose (or a copy in <filename>/etc/</filename> if it's
+ configuration file can also be edited for this purpose (or a copy in <filename>/etc/</filename> if it is
shipped under <filename>/usr/</filename>), however using drop-ins for local configuration is recommended
over modifications to the main configuration file.</para>
<filename>net.ipv4.conf.default.rp_filter</filename> first, so any interfaces which are added
<emphasis>later</emphasis> will get this value (this also covers any interfaces detected while we're
running). The glob matches any interfaces which were detected <emphasis>earlier</emphasis>. The glob
- will also match <filename>net.ipv4.conf.all.rp_filter</filename>, which we don't want to set at all, so
+ will also match <filename>net.ipv4.conf.all.rp_filter</filename>, which we do not want to set at all, so
it is explicitly excluded. And "hub0" is excluded from the glob because it has an explicit setting.
</para>
</example>
options are specified.</para>
<para>Note that this command does not show unit templates, but only instances of unit
- templates. Units templates that aren't instantiated are not runnable, and will thus never show up
+ templates. Units templates that are not instantiated are not runnable, and will thus never show up
in the output of this command. Specifically this means that <filename>foo@.service</filename>
will never be shown in this list — unless instantiated, e.g. as
<filename>foo@bar.service</filename>. Use <command>list-unit-files</command> (see below) for
on disk, which might not match the system manager's
understanding of these units if any unit files were
updated on disk and the <command>daemon-reload</command>
- command wasn't issued since.</para>
+ command was not issued since.</para>
<xi:include href="version-info.xml" xpointer="v209"/>
</listitem>
<filename>default.target</filename> is implied.</para>
<para>The units that are shown are additionally filtered by <option>--type=</option> and
- <option>--state=</option> if those options are specified. Note that we won't be able to
+ <option>--state=</option> if those options are specified. Note that we will not be able to
use a tree structure in this case, so <option>--plain</option> is implied.</para>
<para>By default, only target units are recursively
<para>Note that this command only lists units currently loaded into memory by the service manager. In
particular, this command is not suitable to get a comprehensive list at all reverse dependencies on a
- specific unit, as it won't list the dependencies declared by units currently not loaded.</para>
+ specific unit, as it will not list the dependencies declared by units currently not loaded.</para>
<xi:include href="version-info.xml" xpointer="v198"/>
</listitem>
<para>Stop and then start one or more units specified on the
command line if the units are running. This does nothing
if units are not running.</para>
- <!-- Note that we don't document condrestart here, as that is just compatibility support, and we generally
- don't document that. -->
+ <!-- Note that we do not document condrestart here, as that is just compatibility support, and we generally
+ do not document that. -->
</listitem>
</varlistentry>
<varlistentry>
<listitem>
<para>Reload one or more units if they support it. If not, stop and then start them instead. This does
nothing if the units are not running.</para>
- <!-- Note that we don't document force-reload here, as that is just compatibility support, and we generally
- don't document that. -->
+ <!-- Note that we do not document force-reload here, as that is just compatibility support, and we generally
+ do not document that. -->
<xi:include href="version-info.xml" xpointer="v229"/>
</listitem>
command line using cgroup freezer</para>
<para>Freezing the unit will cause all processes contained within the cgroup corresponding to the unit
- to be suspended. Being suspended means that unit's processes won't be scheduled to run on CPU until thawed.
+ to be suspended. Being suspended means that unit's processes will not be scheduled to run on CPU until thawed.
Note that this command is supported only on systems that use unified cgroup hierarchy. Unit is automatically
thawed just before we execute a job against the unit, e.g. before the unit is stopped.</para>
</row>
<row>
<entry><literal>not-found</literal></entry>
- <entry>The unit file doesn't exist.</entry>
+ <entry>The unit file does not exist.</entry>
<entry>4</entry>
</row>
</tbody>
specified). If a matching unit file already exists under these directories this operation will
hence fail. This means that the operation is primarily useful to mask units shipped by the vendor
(as those are shipped in <filename>/usr/lib/systemd/system/</filename> and not the aforementioned
- two directories), but typically doesn't work for units created locally (as those are typically
+ two directories), but typically does not work for units created locally (as those are typically
placed precisely in the two aforementioned directories). Similar restrictions apply for
<option>--user</option> mode, in which case the directories are below the user's home directory
however.</para>
<listitem>
<para>Shut down and reboot the system via <command>kexec</command>. This command will load a
- kexec kernel if one wasn't loaded yet or fail. A kernel may be loaded earlier by a separate step,
+ kexec kernel if one was not loaded yet or fail. A kernel may be loaded earlier by a separate step,
this is particularly useful if a custom initrd or additional kernel command line options are
desired. The <option>--force</option> can be used to continue without a kexec kernel, i.e. to
perform a normal reboot. The final reboot step is equivalent to
units currently in memory, and patterns which do not match anything
are silently skipped. For example:
<programlisting># systemctl stop "sshd@*.service"</programlisting>
- will stop all <filename>sshd@.service</filename> instances. Note that alias names of units, and units that aren't
+ will stop all <filename>sshd@.service</filename> instances. Note that alias names of units, and units that are not
in memory are not considered for glob expansion.
</para>
<term><option>--no-warn</option></term>
<listitem>
- <para>Don't generate the warnings shown by default in the following cases:
+ <para>Do not generate the warnings shown by default in the following cases:
<itemizedlist>
<listitem>
<para>when <command>systemctl</command> is invoked without procfs mounted on
</listitem>
<listitem>
<para>when using <command>enable</command> or <command>disable</command> on units without
- install information (i.e. don't have or have an empty [Install] section),</para>
+ install information (i.e. do not have or have an empty [Install] section),</para>
</listitem>
<listitem>
<para>when using <command>disable</command> combined with <option>--user</option> on units
<para>This command prints a list of all running units, ordered by the time they took to initialize.
This information may be used to optimize boot-up times. Note that the output might be misleading as the
initialization of one service might be slow simply because it waits for the initialization of another
- service to complete. Also note: <command>systemd-analyze blame</command> doesn't display results for
+ service to complete. Also note: <command>systemd-analyze blame</command> does not display results for
services with <varname>Type=simple</varname>, because systemd considers such services to be started
immediately, hence no measurement of the initialization delays can be done. Also note that this command
only shows the time units took for starting up, it does not show how long unit jobs spent in the
<para>Note that this plot is based on the most recent per-unit timing data of loaded units. This means
that if a unit gets started, then stopped and then started again the information shown will cover the
- most recent start cycle, not the first one. Thus it's recommended to consult this information only
- shortly after boot, so that this distinction doesn't matter. Moreover, units that are not referenced by
+ most recent start cycle, not the first one. Thus it is recommended to consult this information only
+ shortly after boot, so that this distinction does not matter. Moreover, units that are not referenced by
any other unit through a dependency might be unloaded by the service manager once they terminate (and
did not fail). Such units will not show up in the plot.</para>
</refsect2>
OS. It contains a file system path (relative to the EFI system partition) of the <ulink
url="https://uapi-group.org/specifications/specs/boot_loader_specification">Boot Loader Specification</ulink> compliant boot loader entry
file or unified kernel image file that was used to boot up the
- system. <command>systemd-bless-boot.service</command> removes the two 'tries done' and 'tries left' numeric boot
+ system. <command>systemd-bless-boot.service</command> removes the two "tries done" and "tries left" numeric boot
counters from the filename, which indicates to future invocations of the boot loader that the entry has completed
booting successfully at least once. (This service will hence rename the boot loader entry file or unified kernel
image file on the first successful boot.)</para>
<varlistentry>
<term><option>bad</option></term>
- <listitem><para>When called the 'tries left' counter in the boot loader entry file name or unified kernel image
- file name is set to zero, marking the boot loader entry or kernel image as "bad", so that the boot loader won't
+ <listitem><para>When called the "tries left" counter in the boot loader entry file name or unified kernel image
+ file name is set to zero, marking the boot loader entry or kernel image as "bad", so that the boot loader will not
consider it anymore on future boots (at least as long as there are other entries available that are not marked
"bad" yet). This command is normally not executed, but can be used to instantly put an end to the boot counting
logic if a problem is detected and persistently mark the boot entry as bad.</para>
the random seed stored in the ESP is refreshed on <emphasis>every</emphasis> reboot ensuring that
multiple subsequent boots will boot with different seeds. On the other hand, the system token is
generated randomly <emphasis>once</emphasis>, and then persistently stored in the system's EFI variable
- storage, ensuring the same disk image won't result in the same series of boot loader seed values if used
+ storage, ensuring the same disk image will not result in the same series of boot loader seed values if used
on multiple systems in parallel.</para>
<para>The <filename>systemd-boot-random-seed.service</filename> unit invokes the <command>bootctl
random-seed</command> command, which updates the random seed in the ESP, and initializes the system
- token if it's not initialized yet. The service is conditionalized so that it is run only when a boot
+ token if it is not initialized yet. The service is conditionalized so that it is run only when a boot
loader is used that implements the <ulink url="https://systemd.io/BOOT_LOADER_INTERFACE">Boot Loader
Interface</ulink>.</para> <para>For further details see
<citerefentry><refentrytitle>bootctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>, regarding
<orderedlist>
<listitem><para>If the 'tries left' counter of an entry is greater than zero the entry is considered to be in
- 'indeterminate' state. This means the entry has not completed booting successfully yet, but also hasn't been
+ 'indeterminate' state. This means the entry has not completed booting successfully yet, but also has not been
determined not to work.</para></listitem>
<listitem><para>If the 'tries left' counter of an entry is zero it is considered to be in 'bad' state. This means
<term><option>--continuous</option></term>
<listitem><para>When specified, <command>systemd-bsod</command> waits continuously for changes in the
- journal if it doesn't find any emergency messages on the initial attempt.</para>
+ journal if it does not find any emergency messages on the initial attempt.</para>
<xi:include href="version-info.xml" xpointer="v255"/></listitem>
</varlistentry>
<listitem><para>Generates a host encryption key for credentials, if one has not been generated
already. This ensures the <filename>/var/lib/systemd/credential.secret</filename> file is initialized
- with a random secret key if it doesn't exist yet. This secret key is used when encrypting/decrypting
+ with a random secret key if it does not exist yet. This secret key is used when encrypting/decrypting
credentials with <command>encrypt</command> or <command>decrypt</command>, and is only accessible to
the root user. Note that there's typically no need to invoke this command explicitly as it is
implicitly called when <command>encrypt</command> is invoked, and credential host key encryption
<term><option>--newline=</option></term>
<listitem><para>When specified with <command>cat</command> or <command>decrypt</command> controls
- whether to add a trailing newline character to the end of the output if it doesn't end in one,
+ whether to add a trailing newline character to the end of the output if it does not end in one,
anyway. Takes one of <literal>auto</literal>, <literal>yes</literal> or <literal>no</literal>. The
default mode of <literal>auto</literal> will suffix the output with a single newline character only
when writing credential data to a TTY.</para>
done.</para>
<para>Embedding the credential name in the encrypted credential is done in order to protect against
- reuse of credentials for purposes they weren't originally intended for, under the assumption the
+ reuse of credentials for purposes they were not originally intended for, under the assumption the
credential name is chosen carefully to encode its intended purpose.</para>
<xi:include href="version-info.xml" xpointer="v250"/></listitem>
<para>Note that currently when enrolling a new key of one of the five supported types listed above, it is
required to first provide a passphrase, a recovery key, a FIDO2 token, or a TPM2 key. It's currently not
supported to unlock a device with a PKCS#11 key in order to enroll a new PKCS#11 key. Thus, if in future
- key roll-over is desired it's generally recommended to ensure a passphrase, a recovery key, a FIDO2
+ key roll-over is desired it is generally recommended to ensure a passphrase, a recovery key, a FIDO2
token, or a TPM2 key is always enrolled.</para>
<para>Also note that support for enrolling multiple FIDO2 tokens is currently limited. When multiple FIDO2
is unsupported if <option>--unlock-fido2-device=</option> option is also specified. The special value
<literal>list</literal> may be used to enumerate all suitable FIDO2 tokens currently plugged in. Note
that many hardware security tokens that implement FIDO2 also implement the older PKCS#11
- standard. Typically FIDO2 is preferable, given it's simpler to use and more modern.</para>
+ standard. Typically FIDO2 is preferable, given it is simpler to use and more modern.</para>
<para>In order to unlock a LUKS2 volume with an enrolled FIDO2 security token, specify the
<option>fido2-device=</option> option in the respective <filename>/etc/crypttab</filename> line:</para>
<term><option>--force</option></term>
<listitem><para>Write configuration even if the relevant files already exist. Without this option,
- <command>systemd-firstboot</command> doesn't modify or replace existing files. Note that when
+ <command>systemd-firstboot</command> does not modify or replace existing files. Note that when
configuring the root account, even with this option, <command>systemd-firstboot</command> only
modifies the entry of the <literal>root</literal> user, leaving other entries in
<filename>/etc/passwd</filename> and <filename>/etc/shadow</filename> intact.</para>
<term><varname>systemd.firstboot=</varname></term>
<listitem><para>Takes a boolean argument, defaults to on. If off, <filename>systemd-firstboot.service</filename>
- won't interactively query the user for basic settings at first boot, even if those settings are not
+ will not interactively query the user for basic settings at first boot, even if those settings are not
initialized yet.</para>
<xi:include href="version-info.xml" xpointer="v233"/></listitem>
The result may optionally be signed cryptographically, to allow TPM2 policies that can only be unlocked
if a certain set of kernels is booted, for which such a PCR signature can be provided.</para>
- <para>It usually doesn't make sense to call this tool directly when constructing a UKI. Instead,
+ <para>It usually does not make sense to call this tool directly when constructing a UKI. Instead,
<citerefentry><refentrytitle>ukify</refentrytitle><manvolnum>1</manvolnum></citerefentry> should be used;
it will invoke <command>systemd-measure</command> and take care of embedding the resulting measurements
into the UKI.</para>
<literal>enter-initrd:leave-initrd:sysinit:ready</literal>, i.e. calculates expected PCR values for
the boot phase in the initrd, during early boot, during later boot, and during system runtime, but
excluding the phases before the initrd or when shutting down. This setting is honoured both by
- <command>calculate</command> and <command>sign</command>. When used with the latter it's particularly
+ <command>calculate</command> and <command>sign</command>. When used with the latter it is particularly
useful for generating PCR signatures that can only be used for unlocking resources during specific
parts of the boot process.</para>
<para>If two arguments are specified, the first indicates the mount source (the
<replaceable>WHAT</replaceable>) and the second indicates the path to mount it on (the
<replaceable>WHERE</replaceable>). In this mode no probing of the source is attempted, and a backing
- device node doesn't have to exist. However, if this mode is combined with <option>--discover</option>,
+ device node does not have to exist. However, if this mode is combined with <option>--discover</option>,
device node probing for additional metadata is enabled, and – much like in the single-argument case
discussed above – the specified device has to exist at the time of invocation of the command.</para>
credential <filename>network.link.50-foobar</filename> will be copied into a configuration file
<filename>50-foobar.link</filename>.</para>
- <para>Note that the resulting files are created world-readable, it's hence recommended to not include
+ <para>Note that the resulting files are created world-readable, it is hence recommended to not include
secrets in these credentials, but supply them via separate credentials directly to
<filename>systemd-networkd.service</filename>.</para>
<listitem><para>Make the container part of the specified slice, instead of the default
<filename>machine.slice</filename>. This applies only if the machine is run in its own scope unit, i.e. if
- <option>--keep-unit</option> isn't used.</para>
+ <option>--keep-unit</option> is not used.</para>
<xi:include href="version-info.xml" xpointer="v206"/>
</listitem>
<term><option>--property=</option></term>
<listitem><para>Set a unit property on the scope unit to register for the machine. This applies only if the
- machine is run in its own scope unit, i.e. if <option>--keep-unit</option> isn't used. Takes unit property
+ machine is run in its own scope unit, i.e. if <option>--keep-unit</option> is not used. Takes unit property
assignments in the same format as <command>systemctl set-property</command>. This is useful to set memory
limits and similar for the container.</para>
<para>Note that the user record propagated from the host into the container will contain the UNIX
password hash of the user, so that seamless logins in the container are possible. If the container is
- less trusted than the host it's hence important to use a strong UNIX password hash function
+ less trusted than the host it is hence important to use a strong UNIX password hash function
(e.g. yescrypt or similar, with the <literal>$y$</literal> hash prefix).</para>
<para>When binding a user from the host into the container checks are executed to ensure that the
<listitem><para>Takes a boolean. If this switch is not specified <option>--discard=yes</option> is
the implied default. Controls whether to issue the <constant>BLKDISCARD</constant> I/O control
- command on the space taken up by any added partitions or on the space in between them. Usually, it's
+ command on the space taken up by any added partitions or on the space in between them. Usually, it is
a good idea to issue this request since it tells the underlying hardware that the covered blocks
shall be considered empty, improving performance. If operating on a regular file instead of a block
device node, a sparse file is generated.</para>
<term><option>--exclude-partitions=<replaceable>PARTITIONS</replaceable></option></term>
<listitem><para>These options specify which partition types <command>systemd-repart</command> should
- operate on. If <option>--include-partitions=</option> is used, all partitions that aren't specified
+ operate on. If <option>--include-partitions=</option> is used, all partitions that are not specified
are excluded. If <option>--exclude-partitions=</option> is used, all partitions that are specified
are excluded. Both options take a comma separated list of GPT partition type UUIDs or identifiers
(see <varname>Type=</varname> in
<listitem><para>This option specifies for which partition types <command>systemd-repart</command>
should defer. All partitions that are deferred using this option are still taken into account when
- calculating the sizes and offsets of other partitions, but aren't actually written to the disk image.
+ calculating the sizes and offsets of other partitions, but are not actually written to the disk image.
The net effect of this option is that if you run <command>systemd-repart</command> again without this
option, the missing partitions will be added as if they had not been deferred the first time
<command>systemd-repart</command> was executed.</para>
DNS servers, unless the domain is specified explicitly as routing or search domain for the DNS server
and interface. This means that on networks where the <literal>.local</literal> domain is defined in a
site-specific DNS server, explicit search or routing domains need to be configured to make lookups work
- within this DNS domain. Note that these days, it's generally recommended to avoid defining
+ within this DNS domain. Note that these days, it is generally recommended to avoid defining
<literal>.local</literal> in a DNS server, as <ulink
url="https://tools.ietf.org/html/rfc6762">RFC6762</ulink> reserves this domain for exclusive
MulticastDNS use.</para></listitem>
<para>In case of single-label names, when search domains are defined, the same logic applies, except
that the name is first suffixed by each of the search domains in turn. Note that this search logic
- doesn't apply to any names with at least one dot. Also see the discussion about compatibility with
+ does not apply to any names with at least one dot. Also see the discussion about compatibility with
the traditional glibc resolver below.</para></listitem>
<listitem><para>If a query does not match any configured routing domain (either per-link or global), it
<para>This option will result in <command>systemd-run</command> synchronously waiting for
the transient service to terminate, similar to specifying <option>--wait</option>. If specified
- along with <option>--wait</option>, <command>systemd-run</command> won't exit when manually disconnecting
+ along with <option>--wait</option>, <command>systemd-run</command> will not exit when manually disconnecting
from the pseudo TTY device.</para>
<para>Note that
<literal><></literal>, <literal><${INVOCATION_ID}></literal>] as the argument array, and then
<citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>
generates <varname>${INVOCATION_ID}</varname> and substitutes it in the command-line. This substitution
- could not be done on the client side, because the target ID that will be set for the service isn't
+ could not be done on the client side, because the target ID that will be set for the service is not
known before the call is made.</para>
</example>
<para>Even though passing resources from one soft reboot cycle to the next is possible this way, we
strongly suggest to use this functionality sparingly only, as it creates a more fragile system as
resources from different versions of the OS and applications might be mixed with unforeseen
- consequences. In particular it's recommended to <emphasis>avoid</emphasis> allowing processes to survive
+ consequences. In particular it is recommended to <emphasis>avoid</emphasis> allowing processes to survive
the soft reboot operation, as this means code updates will necessarily be incomplete, and processes
typically pin various other resources (such as the file system they are backed by), thus increasing
memory usage (as two versions of the OS/application/file system might be kept in memory). Leaving
must be of type <constant>SOCK_STREAM</constant>. Similar, SSH connections to <literal>vsock/</literal>
followed by an <constant>AF_VSOCK</constant> CID will result in an SSH connection made to that
CID. <literal>vsock-mux/</literal> followed by an absolute <constant>AF_UNIX</constant> file system
- path to a socket is similar but for cloud-hypervisor/firecracker which don't allow
+ path to a socket is similar but for cloud-hypervisor/firecracker which do not allow
direct <constant>AF_VSOCK</constant> communication between the host and guests, and provide their own
multiplexer over <constant>AF_UNIX</constant> sockets. See
<ulink url="https://github.com/cloud-hypervisor/cloud-hypervisor/blob/main/docs/vsock.md">cloud-hypervisor VSOCK support</ulink>
multi-profile UKIs, see below.</para> <para>If UEFI SecureBoot is enabled and the
<literal>.cmdline</literal> section is present in the executed image, any attempts to override the kernel
command line by passing one as invocation parameters to the EFI binary are ignored. Thus, in order to
- allow overriding the kernel command line, either disable UEFI SecureBoot, or don't include a kernel
+ allow overriding the kernel command line, either disable UEFI SecureBoot, or do not include a kernel
command line PE section in the kernel image file. If a command line is accepted via EFI invocation
parameters to the EFI binary it is measured into TPM PCR 12 (if a TPM is present).</para> <para>If a
DeviceTree is embedded in the <literal>.dtb</literal> section, it replaces an existing DeviceTree in the
</table>
<para>The section list above would define three profiles. The first four sections make up the base
- profile. A <literal>.profile</literal> section then introduces profile @0. It doesn't override any
+ profile. A <literal>.profile</literal> section then introduces profile @0. It does not override any
sections (or add any) from the base section, hence it is immediately followed by another
<literal>.profile</literal> section that then introduces section @1. This profile overrides the kernel
command line. Finally, the last two sections define section @2, again overriding the command line. (Note
that in this example the first <literal>.cmdline</literal> could also moved behind the first
- <literal>.profile</literal> with equivalent effect. To keep things nicely extensible, it's probably a
+ <literal>.profile</literal> with equivalent effect. To keep things nicely extensible, it is probably a
good idea to keep the generic command line in the base section instead of profile 0, in case later added
profiles might want to reuse it.)</para>
</variablelist>
<para>Note that some of the variables above may also be set by the boot loader. The stub will only set
- them if they are
n't set already. Some of these variables are defined by the <ulink
+ them if they are
not set already. Some of these variables are defined by the <ulink
url="https://systemd.io/BOOT_LOADER_INTERFACE">Boot Loader Interface</ulink>.</para>
</refsect1>
<term><varname>NUMAMask=</varname></term>
<listitem><para>Configures the NUMA node mask that will be associated with the selected NUMA policy. Note that
- <option>default</option> and <option>local</option> NUMA policies don't require explicit NUMA node mask and
+ <option>default</option> and <option>local</option> NUMA policies do not require explicit NUMA node mask and
value of the option can be empty. Similarly to <varname>NUMAPolicy=</varname>, value can be overridden
by individual services in unit files, see
<citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
<varlistentry>
<term><option>--dry-run</option></term>
- <listitem><para>Process the configuration and figure out what entries would be created, but don't
+ <listitem><para>Process the configuration and figure out what entries would be created, but do not
actually write anything.</para>
<xi:include href="version-info.xml" xpointer="v250"/></listitem>
<varlistentry>
<term><option>--dry-run</option></term>
- <listitem><para>Process the configuration and print what operations would be performed, but don't
+ <listitem><para>Process the configuration and print what operations would be performed, but do not
actually change anything in the file system.</para>
<xi:include href="version-info.xml" xpointer="v256"/></listitem>
<para>The <option>systemd.tpm2_wait=</option> kernel command line option may be used to override
behaviour of the generator. It accepts a boolean value: if true then <filename>tpm2.target</filename>
will be added as synchronization point even if the firmware has not detected a TPM2 device. If false, the
- target will not be inserted even if firmware reported a device but the OS kernel doesn't expose a device
+ target will not be inserted even if firmware reported a device but the OS kernel does not expose a device
for it yet. The latter might be useful in environments where a suitable TPM2 driver for the available
hardware is not available.</para>
<para><filename>systemd-tpm2-setup.service</filename> and
<filename>systemd-tpm2-setup-early.service</filename> are services that generate the Storage Root Key
- (SRK) if it hasn't been generated yet, and stores it in the TPM.</para>
+ (SRK) if it has not been generated yet, and stores it in the TPM.</para>
<para>The services will store the public key of the SRK key pair in a PEM file in
<filename>/run/systemd/tpm2-srk-public-key.pem</filename> and
enforcing=0
</programlisting>
- <para>Note: this example also uses a kernel command line argument to ensure SELinux isn't started in
+ <para>Note: this example also uses a kernel command line argument to ensure SELinux is not started in
enforcing mode.</para>
</example>
<varname>SYSTEMD_READY=</varname> (see below) to configure when a udev device shall be considered active, and
thus when to trigger the dependencies.</para>
- <!-- Note that we don't document here that we actually apply unit_name_mangle() to all specified names, since
- that's kinda ugly, and people should instead specify correctly escaped names -->
+ <!-- Note that we do not document here that we actually apply unit_name_mangle() to all specified names, since
+ that is kind of ugly, and people should instead specify correctly escaped names -->
<para>The specified property value should be a space-separated list of valid unit names. If a unit template
name is specified (that is, a unit name containing an <literal>@</literal> character indicating a unit name to
</itemizedlist>
</refsect1>
- <!-- We don't have any default dependency here. -->
+ <!-- We do not have any default dependency here. -->
<refsect1>
<title>Paths</title>
cannot be used for services that need to access metainformation about other users' processes. This
option implies <varname>MountAPIVFS=</varname>.</para>
- <para>If the kernel doesn't support per-mount point <option>hidepid=</option> mount options this
+ <para>If the kernel does not support per-mount point <option>hidepid=</option> mount options this
setting remains without effect, and the unit's processes will be able to access and see other process
as if the option was not used.</para>
<varname>ProtectHome=read-only</varname> are implied, thus prohibiting the service to write to
arbitrary file system locations. In order to allow the service to write to certain directories, they
have to be allow-listed using <varname>ReadWritePaths=</varname>, but care must be taken so that
- UID/GID recycling doesn't create security issues involving files created by the service. Use
+ UID/GID recycling does not create security issues involving files created by the service. Use
<varname>RuntimeDirectory=</varname> (see below) in order to assign a writable runtime directory to a
service, owned by the dynamic user/group and removed automatically when the unit is terminated. Use
<varname>StateDirectory=</varname>, <varname>CacheDirectory=</varname> and
<listitem><para>Set the SELinux security context of the executed process. If set, this will override the
automated domain transition. However, the policy still needs to authorize the transition. This directive is
ignored if SELinux is disabled. If prefixed by <literal>-</literal>, failing to set the SELinux
- security context will be ignored, but it's still possible that the subsequent
- <function>execve()</function> may fail if the policy doesn't allow the transition for the
+ security context will be ignored, but it is still possible that the subsequent
+ <function>execve()</function> may fail if the policy does not allow the transition for the
non-overridden context. This does not affect commands prefixed with <literal>+</literal>. See
<citerefentry
project='die-net'><refentrytitle>setexeccon</refentrytitle><manvolnum>3</manvolnum></citerefentry>
<entry>LimitDATA=</entry>
<entry>ulimit -d</entry>
<entry>Bytes</entry>
- <entry>Don't use. This limits the allowed address range, not memory use! Defaults to unlimited and should not be lowered. To limit memory use, see <varname>MemoryMax=</varname> in <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</entry>
+ <entry>Do not use. This limits the allowed address range, not memory use! Defaults to unlimited and should not be lowered. To limit memory use, see <varname>MemoryMax=</varname> in <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</entry>
</row>
<row>
<entry>LimitSTACK=</entry>
<entry>LimitRSS=</entry>
<entry>ulimit -m</entry>
<entry>Bytes</entry>
- <entry>Don't use. No effect on Linux.</entry>
+ <entry>Do not use. No effect on Linux.</entry>
</row>
<row>
<entry>LimitNOFILE=</entry>
<entry>ulimit -n</entry>
<entry>Number of File Descriptors</entry>
- <entry>Don't use. Be careful when raising the soft limit above 1024, since <citerefentry project='man-pages'><refentrytitle>select</refentrytitle><manvolnum>2</manvolnum></citerefentry> cannot function with file descriptors above 1023 on Linux. Nowadays, the hard limit defaults to 524288, a very high value compared to historical defaults. Typically applications should increase their soft limit to the hard limit on their own, if they are OK with working with file descriptors above 1023, i.e. do not use <citerefentry project='man-pages'><refentrytitle>select</refentrytitle><manvolnum>2</manvolnum></citerefentry>. Note that file descriptors are nowadays accounted like any other form of memory, thus there should not be any need to lower the hard limit. Use <varname>MemoryMax=</varname> to control overall service memory use, including file descriptor memory.</entry>
+ <entry>Do not use. Be careful when raising the soft limit above 1024, since <citerefentry project='man-pages'><refentrytitle>select</refentrytitle><manvolnum>2</manvolnum></citerefentry> cannot function with file descriptors above 1023 on Linux. Nowadays, the hard limit defaults to 524288, a very high value compared to historical defaults. Typically applications should increase their soft limit to the hard limit on their own, if they are OK with working with file descriptors above 1023, i.e. do not use <citerefentry project='man-pages'><refentrytitle>select</refentrytitle><manvolnum>2</manvolnum></citerefentry>. Note that file descriptors are nowadays accounted like any other form of memory, thus there should not be any need to lower the hard limit. Use <varname>MemoryMax=</varname> to control overall service memory use, including file descriptor memory.</entry>
</row>
<row>
<entry>LimitAS=</entry>
<entry>ulimit -v</entry>
<entry>Bytes</entry>
- <entry>Don't use. This limits the allowed address range, not memory use! Defaults to unlimited and should not be lowered. To limit memory use, see <varname>MemoryMax=</varname> in <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</entry>
+ <entry>Do not use. This limits the allowed address range, not memory use! Defaults to unlimited and should not be lowered. To limit memory use, see <varname>MemoryMax=</varname> in <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</entry>
</row>
<row>
<entry>LimitNPROC=</entry>
<entry>ulimit -u</entry>
<entry>Number of Processes</entry>
- <entry>This limit is enforced based on the number of processes belonging to the user. Typically it's better to track processes per service, i.e. use <varname>TasksMax=</varname>, see <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</entry>
+ <entry>This limit is enforced based on the number of processes belonging to the user. Typically it is better to track processes per service, i.e. use <varname>TasksMax=</varname>, see <citerefentry><refentrytitle>systemd.resource-control</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</entry>
</row>
<row>
<entry>LimitMEMLOCK=</entry>
kernel documentation.</para>
<para>Note that this functionality might not be available, for example if KSM is disabled in the
- kernel, or the kernel doesn't support controlling KSM at the process level through
+ kernel, or the kernel does not support controlling KSM at the process level through
<citerefentry><refentrytitle>prctl</refentrytitle><manvolnum>2</manvolnum></citerefentry>.</para>
<xi:include href="version-info.xml" xpointer="v254"/>
<para>It is not recommended to use <option>private</option> mount propagation for units, as this means
temporary mounts (such as removable media) of the host will stay mounted and thus indefinitely busy in forked
- off processes, as unmount propagation events won't be received by the file system namespace of the unit.</para>
+ off processes, as unmount propagation events will not be received by the file system namespace of the unit.</para>
<para>Usually, it is best to leave this setting unmodified, and use higher level file system namespacing
options instead, in particular <varname>PrivateMounts=</varname>, see above.</para>
<para>The <option>file:<replaceable>path</replaceable></option> option may be used to connect a specific file
system object to standard output. The semantics are similar to the same option of
<varname>StandardInput=</varname>, see above. If <replaceable>path</replaceable> refers to a regular file
- on the filesystem, it is opened (created if it doesn't exist yet using privileges of the user executing the
+ on the filesystem, it is opened (created if it does not exist yet using privileges of the user executing the
systemd process) for writing at the beginning of the file, but without truncating it.
If standard input and output are directed to the same file path, it is opened only once — for reading as well
as writing — and duplicated. This is particularly useful when the specified path refers to an
<para>Filtering is based on the unit for which <varname>LogFilterPatterns=</varname> is defined, meaning log
messages coming from
<citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> about the
- unit are not taken into account. Filtered log messages won't be forwarded to traditional syslog daemons,
+ unit are not taken into account. Filtered log messages will not be forwarded to traditional syslog daemons,
the kernel log buffer (kmsg), the systemd console, or sent as wall messages to all logged-in
users.</para>
specific user or the system as a whole, and it is ensured that per-user service managers cannot
decrypt secrets intended for the system or for other users.</para>
- <para>The credential files/IPC sockets must be accessible to the service manager, but don't have to
+ <para>The credential files/IPC sockets must be accessible to the service manager, but do not have to
be directly accessible to the unit's processes: the credential data is read and copied into separate,
read-only copies for the unit that are accessible to appropriately privileged processes. This is
particularly useful in combination with <varname>DynamicUser=</varname> as this way privileged data
<varlistentry>
<term><varname>ImportCredential=</varname><replaceable>GLOB</replaceable></term>
- <listitem><para>Pass one or more credentials to the unit. Takes a credential name for which we'll
+ <listitem><para>Pass one or more credentials to the unit. Takes a credential name for which we will
attempt to find a credential that the service manager itself received under the specified name —
which may be used to propagate credentials from an invoking environment (e.g. a container manager
that invoked the service manager) into a service. If the credential name is a glob, all credentials
<row>
<entry>71</entry>
<entry><constant>EX_OSERR</constant></entry>
- <entry>System error (e.g., can't fork)</entry>
+ <entry>System error (e.g., cannot fork)</entry>
</row>
<row>
<entry>72</entry>
<row>
<entry>73</entry>
<entry><constant>EX_CANTCREAT</constant></entry>
- <entry>Can't create (user) output file</entry>
+ <entry>Cannot create (user) output file</entry>
</row>
<row>
<entry>74</entry>
<programlisting>root=encrypted+read-only-off:srv=encrypted+absent:swap=absent</programlisting>
<para>The following image policy string dictates a single root partition that may be encrypted, but
- doesn't have to be, and ignores swap partitions, and uses all other partitions if they are available, possibly with encryption.</para>
+ does not have to be, and ignores swap partitions, and uses all other partitions if they are available, possibly with encryption.</para>
<programlisting>root=unprotected+encrypted:swap=absent+unused:=unprotected+encrypted+absent</programlisting>
</refsect1>
<para>Interface names must have a minimum length of 1 character and a maximum length of 15
characters, and may contain any 7bit ASCII character, with the exception of control characters,
<literal>:</literal>, <literal>/</literal> and <literal>%</literal>. While <literal>.</literal> is
- an allowed character, it's recommended to avoid it when naming interfaces as various tools (such as
+ an allowed character, it is recommended to avoid it when naming interfaces as various tools (such as
<citerefentry><refentrytitle>resolvconf</refentrytitle><manvolnum>1</manvolnum></citerefentry>) use
it as separator character. Also, fully numeric interface names are not allowed (in order to avoid
ambiguity with interface specification by numeric indexes), nor are the special strings
link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
hub0: Device has name_assign_type=4
Using default interface naming scheme 'v240'.
-hub0: Policies didn't yield a name, using specified Name=hub0.
+hub0: Policies did not yield a name, using specified Name=hub0.
ID_NET_LINK_FILE=/etc/systemd/network/10-eth0.link
ID_NET_NAME=hub0
…</programlisting>
for details. This setting is optional.</para>
<para>If the type is <literal>overlay</literal>, and <literal>upperdir=</literal> or
- <literal>workdir=</literal> are specified as options and the directories don't exist, they will be created.
+ <literal>workdir=</literal> are specified as options and the directories do not exist, they will be created.
</para></listitem>
</varlistentry>
name and the bus number are ignored.</para>
<para>In some configurations a parent PCI bridge of a given network controller may be associated
- with a slot. In such case we don't generate this device property to avoid possible naming conflicts.</para>
+ with a slot. In such case we do not generate this device property to avoid possible naming conflicts.</para>
<xi:include href="version-info.xml" xpointer="v243"/>
</listitem>
<listitem><para>When a PCI slot is associated with a PCI bridge that has multiple child network
controllers, the same value of the <varname>ID_NET_NAME_SLOT</varname> property might be derived
for those controllers. This would cause a naming conflict if the property is selected as the device
- name. Now, we detect this situation and don't produce the <varname>ID_NET_NAME_SLOT</varname>
+ name. Now, we detect this situation and do not produce the <varname>ID_NET_NAME_SLOT</varname>
property.</para>
<xi:include href="version-info.xml" xpointer="v247"/></listitem>
<term><varname>UDPSourcePort=</varname></term>
<listitem>
<para>Specifies the UDP source port to be used for the tunnel. When UDP encapsulation is selected
- it's mandatory. Ignored when IP encapsulation is selected.</para>
+ it is mandatory. Ignored when IP encapsulation is selected.</para>
<xi:include href="version-info.xml" xpointer="v242"/>
</listitem>
<varlistentry>
<term><varname>UDPDestinationPort=</varname></term>
<listitem>
- <para>Specifies destination port. When UDP encapsulation is selected it's mandatory. Ignored when IP
+ <para>Specifies destination port. When UDP encapsulation is selected it is mandatory. Ignored when IP
encapsulation is selected.</para>
<xi:include href="version-info.xml" xpointer="v245"/>
I.e. for <filename>50-foobar.netdev</filename>, <literal>network.wireguard.private.50-foobar</literal>
is tried.</para>
- <para>Note that because this information is secret, it's strongly recommended to use an (encrypted)
+ <para>Note that because this information is secret, it is strongly recommended to use an (encrypted)
credential. Alternatively, you may want to set the permissions of the .netdev file to be owned
by <literal>root:systemd-network</literal> with a <literal>0640</literal> file mode.</para>
This option honors the <literal>@</literal> prefix in the same way as the <option>PrivateKey=</option>
setting of the <option>[WireGuard]</option> section.</para>
- <para>Note that because this information is secret, it's strongly recommended to use an (encrypted)
+ <para>Note that because this information is secret, it is strongly recommended to use an (encrypted)
credential. Alternatively, you may want to set the permissions of the .netdev file to be owned
by <literal>root:systemd-network</literal> with a <literal>0640</literal> file mode.</para>
<warning>
<para>Once labeling is enabled for network traffic, a lot of LSM access control points in
Linux networking stack go from dormant to active. Care should be taken to avoid getting into a
- situation where for example remote connectivity is broken, when the security policy hasn't been
+ situation where for example remote connectivity is broken, when the security policy has not been
updated to consider LSM per-packet access controls and no rules would allow any network
traffic. Also note that additional configuration with <citerefentry
project='man-pages'><refentrytitle>netlabelctl</refentrytitle><manvolnum>8</manvolnum></citerefentry>
</listitem>
<listitem>
- <para><literal>nowhere</literal> means the destination doesn't exist.</para>
+ <para><literal>nowhere</literal> means the destination does not exist.</para>
</listitem>
</itemizedlist>
<listitem>
<para>Configures the time, used in the Neighbor Unreachability Detection algorithm, for which
clients can assume a neighbor is reachable after having received a reachability confirmation. Takes
- a time span in the range 0…4294967295 ms. When 0, clients will handle it as if the value wasn't
+ a time span in the range 0…4294967295 ms. When 0, clients will handle it as if the value was not
specified. Defaults to 0.</para>
<xi:include href="version-info.xml" xpointer="v256"/>
indicate to the kernel that the fdb entry is in use. <literal>self</literal> means
the address is associated with the port drivers fdb. Usually hardware. <literal>master</literal>
means the address is associated with master devices fdb. <literal>router</literal> means
- the destination address is associated with a router. Note that it's valid if the referenced
+ the destination address is associated with a router. Note that it is valid if the referenced
device is a VXLAN type device and has route shortcircuit enabled. Defaults to <literal>self</literal>.</para>
<xi:include href="version-info.xml" xpointer="v243"/>
<para>Add the <literal>bond1</literal> interface to the VRF master interface
<literal>vrf1</literal>. This will redirect routes generated on this interface to be
within the routing table defined during VRF creation. For kernels before 4.8 traffic
- won't be redirected towards the VRFs routing table unless specific ip-rules are added.
+ will not be redirected towards the VRFs routing table unless specific ip-rules are added.
</para>
<programlisting># /etc/systemd/network/25-vrf.network
[Match]
<listitem>
<para>After a reboot, now that the <filename>/system-update</filename> and
- <filename>/etc/system-update</filename> symlink is gone, the generator won't redirect
+ <filename>/etc/system-update</filename> symlink is gone, the generator will not redirect
<filename>default.target</filename> anymore and the system now boots into the default
target again.</para>
</listitem>
<varname>MemoryAccounting=</varname>/<varname>TasksAccounting=</varname>/<varname>IOAccounting=</varname>
settings. Because of how the cgroup hierarchy works, controllers will be automatically enabled for all
parent units and for any sibling units starting with the lowest level at which a controller is enabled.
- Units for which a controller is enabled may be subject to resource control even if they don't have any
+ Units for which a controller is enabled may be subject to resource control even if they do not have any
explicit configuration.</para>
<para>Setting <varname>Delegate=</varname> enables any delegated controllers for that unit (see below).
</itemizedlist>
</refsect1>
- <!-- We don't have any default dependency here. -->
+ <!-- We do not have any default dependency here. -->
<refsect1>
<title>Options</title>
<para>Restrict processes to be executed on specific CPUs. Takes a list of CPU indices or ranges separated by either
whitespace or commas. CPU ranges are specified by the lower and upper CPU indices separated by a dash.</para>
- <para>Setting <varname>AllowedCPUs=</varname> or <varname>StartupAllowedCPUs=</varname> doesn't guarantee that all
+ <para>Setting <varname>AllowedCPUs=</varname> or <varname>StartupAllowedCPUs=</varname> does not guarantee that all
of the CPUs will be used by the processes as it may be limited by parent units. The effective configuration is
reported as <varname>EffectiveCPUs=</varname>.</para>
or ranges separated by either whitespace or commas. Memory NUMA nodes ranges are specified by the lower and upper
NUMA nodes indices separated by a dash.</para>
- <para>Setting <varname>AllowedMemoryNodes=</varname> or <varname>StartupAllowedMemoryNodes=</varname> doesn't
+ <para>Setting <varname>AllowedMemoryNodes=</varname> or <varname>StartupAllowedMemoryNodes=</varname> does not
guarantee that all of the memory NUMA nodes will be used by the processes as it may be limited by parent units.
The effective configuration is reported as <varname>EffectiveMemoryNodes=</varname>.</para>
<para>Not all of these controllers are available on all kernels however, and some are specific to
the unified hierarchy while others are specific to the legacy hierarchy. Also note that the kernel
- might support further controllers, which aren't covered here yet as delegation is either not
+ might support further controllers, which are not covered here yet, as delegation is either not
supported at all for them or not defined cleanly.</para>
<para>Note that because of the hierarchical nature of cgroup hierarchy, any controllers that are
ownership is passed to the unit's configured user/group) when a process is started in it.</para>
<para>This option is useful to avoid manually moving the invoked process into a subgroup after it
- has been started. Since no processes should live in inner nodes of the control group tree it's
+ has been started. Since no processes should live in inner nodes of the control group tree it is
almost always necessary to run the main ("supervising") process of a unit that has delegation
turned on in a subgroup.</para>
disabled otherwise. If set to <literal>skip</literal> the logic is neither enabled, nor disabled and
the two environment variables are not set.</para>
- <para>Note that services are free to use the two environment variables, but it's unproblematic if
+ <para>Note that services are free to use the two environment variables, but it is unproblematic if
they ignore them. Memory pressure handling must be implemented individually in each service, and
usually means different things for different software. For further details on memory pressure
handling see <ulink url="https://systemd.io/MEMORY_PRESSURE">Memory Pressure Handling in
proceed starting follow-up units, right after creating the main service process, and before
executing the service's binary. Note that this means <command>systemctl start</command> command
lines for <option>simple</option> services will report success even if the service's binary
- cannot be invoked successfully (for example because the selected <varname>User=</varname> doesn't
+ cannot be invoked successfully (for example because the selected <varname>User=</varname> does not
exist, or the service binary is missing).</para></listitem>
<listitem><para>The <option>exec</option> type is similar to <option>simple</option>, but the
<function>fork()</function> and <function>execve()</function> in the service process succeeded.)
Note that this means <command>systemctl start</command> command lines for <option>exec</option>
services will report failure when the service's binary cannot be invoked successfully (for
- example because the selected <varname>User=</varname> doesn't exist, or the service binary is
+ example because the selected <varname>User=</varname> does not exist, or the service binary is
missing). This type is implied if credentials are used (refer to <varname>LoadCredential=</varname>
in <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
for details).</para></listitem>
<para>It is recommended to use <varname>Type=</varname><option>exec</option> for long-running
services, as it ensures that process setup errors (e.g. errors such as a missing service
- executable, or missing user) are properly tracked. However, as this service type won't propagate
+ executable, or missing user) are properly tracked. However, as this service type will not propagate
the failures in the service's own startup code (as opposed to failures in the preparatory steps the
- service manager executes before <function>execve()</function>) and doesn't allow ordering of other
+ service manager executes before <function>execve()</function>) and does not allow ordering of other
units against completion of initialization of the service code itself (which for example is useful
if clients need to connect to the service through some form of IPC, and the IPC channel is only
established by the service itself — in contrast to doing this ahead of time through socket or bus
precisely schedule when to consider the service started up successfully and when to proceed with
follow-up units. The <option>notify</option>/<option>notify-reload</option> service types require
explicit support in the service codebase (as <function>sd_notify()</function> or an equivalent API
- needs to be invoked by the service at the appropriate time) — if it's not supported, then
+ needs to be invoked by the service at the appropriate time) — if it is not supported, then
<option>forking</option> is an alternative: it supports the traditional heavy-weight UNIX service
start-up protocol. Note that using any type other than <option>simple</option> possibly delays the
boot process, as the service manager needs to wait for at least some service initialization to
<para>Note that the commands specified in <varname>ExecStop=</varname> are only executed when the service
started successfully first. They are not invoked if the service was never started at all, or in case its
start-up failed, for example because any of the commands specified in <varname>ExecStart=</varname>,
- <varname>ExecStartPre=</varname> or <varname>ExecStartPost=</varname> failed (and weren't prefixed with
+ <varname>ExecStartPre=</varname> or <varname>ExecStartPost=</varname> failed (and were not prefixed with
<literal>-</literal>, see above) or timed out. Use <varname>ExecStopPost=</varname> to invoke commands when a
service failed to start up correctly and is shut down again. Also note that the stop operation is always
performed if the service started successfully, even if the processes in the service terminated on their
are skipped and the service will be terminated by <constant>SIGTERM</constant>. If no <varname>ExecStop=</varname>
commands are specified, the service gets the <constant>SIGTERM</constant> immediately. This default behavior
can be changed by the <varname>TimeoutStopFailureMode=</varname> option. Second, it configures the time
- to wait for the service itself to stop. If it doesn't terminate in the specified time, it will be forcibly terminated
+ to wait for the service itself to stop. If it does not terminate in the specified time, it will be forcibly terminated
by <constant>SIGKILL</constant> (see <varname>KillMode=</varname> in
<citerefentry><refentrytitle>systemd.kill</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
Takes a unit-less value in seconds, or a time span value such
<varname>ExecStopPost=</varname> is still invoked.
<varname>OnSuccess=</varname> and <varname>OnFailure=</varname> are skipped.</para>
- <para>This option is useful in cases where a dependency can fail temporarily but we don't
+ <para>This option is useful in cases where a dependency can fail temporarily but we do not
want these temporary failures to make the dependent units fail. Dependent units are not
notified of these temporary failures.</para>
See <citerefentry><refentrytitle>sd_listen_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry>
for more details on how to retrieve these file descriptors.</para>
- <para>This setting is useful to allow services to access files/sockets that they can't access themselves
+ <para>This setting is useful to allow services to access files/sockets that they cannot access themselves
(due to running in a separate mount namespace, not having privileges, ...).</para>
<para>This setting can be specified multiple times, in which case all the specified paths are opened and the file descriptors passed to the service.
<para>For <constant>AF_UNIX</constant> socket connections, the <varname>$REMOTE_ADDR</varname>
environment variable will contain either the remote socket's file system path starting with a slash
(<literal>/</literal>) or its address in the abstract namespace starting with an at symbol
- (<literal>@</literal>). If the socket is unnamed, <varname>$REMOTE_ADDR</varname> won't be set.</para>
+ (<literal>@</literal>). If the socket is unnamed, <varname>$REMOTE_ADDR</varname> will not be set.</para>
<para>It is recommended to set <varname>CollectMode=inactive-or-failed</varname> for service
instances activated via <varname>Accept=yes</varname>, to ensure that failed connection services are
<option>Accept=no</option>. If yes, the socket's buffers are cleared after the
triggered service exited. This causes any pending data to be
flushed and any pending incoming connections to be rejected. If no, the
- socket's buffers won't be cleared, permitting the service to handle any
+ socket's buffers will not be cleared, permitting the service to handle any
pending connections after restart, which is the usually expected behaviour.
Defaults to <option>no</option>.
</para>
<para>If the polling limit is hit polling is temporarily disabled on it until the specified time
window passes. The polling limit hence slows down connection attempts if hit, but unlike the trigger
- limit won't cause permanent failures. It's the recommended mechanism to deal with DoS attempts
+ limit will not cause permanent failures. It's the recommended mechanism to deal with DoS attempts
through packet flooding.</para>
<para>The polling limit is enforced per file descriptor to listen on, as opposed to the trigger limit
<term><varname>login.issue</varname></term>
<listitem>
<para>The data of this credential is written to
- <filename>/etc/issue.d/50-provision.conf</filename>, if the file doesn't exist yet.
+ <filename>/etc/issue.d/50-provision.conf</filename>, if the file does not exist yet.
<citerefentry project='man-pages'><refentrytitle>agetty</refentrytitle><manvolnum>8</manvolnum></citerefentry>
reads this file and shows its contents at the login prompt of terminal logins. See
<citerefentry project='man-pages'><refentrytitle>issue</refentrytitle><manvolnum>5</manvolnum></citerefentry>
<term><varname>login.motd</varname></term>
<listitem>
<para>The data of this credential is written to <filename>/etc/motd.d/50-provision.conf</filename>,
- if the file doesn't exist yet.
+ if the file does not exist yet.
<citerefentry project='man-pages'><refentrytitle>pam_motd</refentrytitle><manvolnum>8</manvolnum></citerefentry>
reads this file and shows its contents as "message of the day" during terminal logins. See
<citerefentry project='man-pages'><refentrytitle>motd</refentrytitle><manvolnum>5</manvolnum></citerefentry>
<term><varname>network.hosts</varname></term>
<listitem>
<para>The data of this credential is written to <filename>/etc/hosts</filename>, if the file
- doesn't exist yet. See
+ does not exist yet. See
<citerefentry project='man-pages'><refentrytitle>hosts</refentrytitle><manvolnum>5</manvolnum></citerefentry>
for details.</para>
of a credential <filename>network.link.50-foobar</filename> will be copied into a file
<filename>50-foobar.link</filename>.</para>
- <para>Note that the resulting files are created world-readable, it's hence recommended to not include
+ <para>Note that the resulting files are created world-readable, it is hence recommended to not include
secrets in these credentials, but supply them via separate credentials directly to
<filename>systemd-networkd.service</filename>, e.g. <varname>network.wireguard.*</varname>
as described below.</para>
<term><varname>ssh.authorized_keys.root</varname></term>
<listitem>
<para>The data of this credential is written to <filename>/root/.ssh/authorized_keys</filename>, if
- the file doesn't exist yet. This allows provisioning SSH access for the system's root user.</para>
+ the file does not exist yet. This allows provisioning SSH access for the system's root user.</para>
<para>Consumed by <filename>/usr/lib/tmpfiles.d/provision.conf</filename>, see
<citerefentry><refentrytitle>tmpfiles.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
After=emergency.target systemd-networkd.service
AllowIsolate=yes</programlisting>
- <para>When adding dependencies to other units, it's important to check if they set
+ <para>When adding dependencies to other units, it is important to check if they set
<varname>DefaultDependencies=</varname>. Service units, unless they set
<varname>DefaultDependencies=no</varname>, automatically get a dependency on
<filename>sysinit.target</filename>. In this case, both
<para>A timestamp can start with a field containing a weekday, which can be in an abbreviated
(<literal>Wed</literal>) or non-abbreviated (<literal>Wednesday</literal>) English language form (case
does not matter), regardless of the locale.
- However, if a weekday <emphasis>is</emphasis> specified and doesn't match the date, the timestamp is rejected.</para>
+ However, if a weekday <emphasis>is</emphasis> specified and does not match the date, the timestamp is rejected.</para>
<para>If the date is omitted, it defaults to today. If the time is omitted, it defaults to 00:00:00.
Fractional seconds can be specified down to 1µs precision. The seconds field can also be omitted, defaulting to 0.</para>
<para>It is important to distinguish "linked unit files" from "unit file aliases": any symlink where the
symlink <emphasis>target</emphasis> is within the unit load path becomes an alias: the source name and
the target file name must satisfy specific constraints listed above in the discussion of aliases, but the
- symlink target doesn't have to exist, and in fact the symlink target path is not used, except to check
+ symlink target does not have to exist, and in fact the symlink target path is not used, except to check
whether the target is within the unit load path. In contrast, a symlink which goes outside of the unit
load path signifies a linked unit file. The symlink is followed when loading the file, but the
destination name is otherwise unused (and may even not be a valid unit file name). For example, symlinks
<term><varname>Description=</varname></term>
<listitem><para>A short human readable title of the unit. This may be used by
<command>systemd</command> (and other UIs) as a user-visible label for the unit, so this string
- should identify the unit rather than describe it, despite the name. This string also shouldn't just
+ should identify the unit rather than describe it, despite the name. This string also should not just
repeat the unit name. <literal>Apache2 Web Server</literal> is a good example. Bad examples are
<literal>high-performance lightweight HTTP server</literal> (too generic) or
<literal>Apache2</literal> (meaningless for people who do not know Apache, duplicates the unit
<para>Note that this setting does not imply an ordering dependency, similarly to the
<varname>Wants=</varname> and <varname>Requires=</varname> dependencies described above. This means
that to ensure that the conflicting unit is stopped before the other unit is started, an
- <varname>After=</varname> or <varname>Before=</varname> dependency must be declared. It doesn't
+ <varname>After=</varname> or <varname>Before=</varname> dependency must be declared. It does not
matter which of the two ordering dependencies is used, because stop jobs are always ordered before
start jobs, see the discussion in <varname>Before=</varname>/<varname>After=</varname> below.</para>
start-up order is applied. I.e. if a unit is configured with <varname>After=</varname> on another
unit, the former is stopped before the latter if both are shut down. Given two units with any
ordering dependency between them, if one unit is shut down and the other is started up, the shutdown
- is ordered before the start-up. It doesn't matter if the ordering dependency is
- <varname>After=</varname> or <varname>Before=</varname>, in this case. It also doesn't matter which
+ is ordered before the start-up. It does not matter if the ordering dependency is
+ <varname>After=</varname> or <varname>Before=</varname>, in this case. It also does not matter which
of the two is shut down, as long as one is shut down and the other is started up; the shutdown is
ordered before the start-up in all cases. If two units have no ordering dependencies between them,
they are shut down or started up simultaneously, and no ordering takes place. It depends on the unit
unit was successfully activated, and the conditions and asserts are executed the precise moment the
unit would normally start and thus can validate system state after the units ordered before completed
initialization. Use condition expressions for skipping units that do not apply to the local system, for
- example because the kernel or runtime environment doesn't require their functionality.
+ example because the kernel or runtime environment does not require their functionality.
</para>
<para>If multiple conditions are specified, the unit will be executed if all of them apply (i.e. a
<row>
<entry><literal>%y</literal></entry>
<entry>The path to the fragment</entry>
- <entry>This is the path where the main part of the unit file is located. For linked unit files, the real path outside of the unit search directories is used. For units that don't have a fragment file, this specifier will raise an error.</entry>
+ <entry>This is the path where the main part of the unit file is located. For linked unit files, the real path outside of the unit search directories is used. For units that do not have a fragment file, this specifier will raise an error.</entry>
</row>
<row>
<entry><literal>%Y</literal></entry>
in the creation of a recursive dependency chain. systemd will try to detect
these recursive dependency chains where a template unit directly and
recursively depends on itself and will remove such dependencies
- automatically if it finds them. If systemd doesn't detect the recursive
+ automatically if it finds them. If systemd does not detect the recursive
dependency chain, we can break the chain ourselves by disabling the drop-in
for the template instance units via a symlink to
<filename index='false'>/dev/null</filename>:</para>
<title/>
<para id="strict">All functions listed here are thread-agnostic and only a single specific thread may operate on a
- given object during its entire lifetime. It's safe to allocate multiple independent objects and use each from a
- specific thread in parallel. However, it's not safe to allocate such an object in one thread, and operate or free it
- from any other, even if locking is used to ensure these threads don't operate on it at the very same time.</para>
+ given object during its entire lifetime. It is safe to allocate multiple independent objects and use each from a
+ specific thread in parallel. However, it is not safe to allocate such an object in one thread, and operate or free it
+ from any other, even if locking is used to ensure these threads do not operate on it at the very same time.</para>
<para id="safe">All functions listed here are thread-safe and may be called in parallel from multiple threads.</para>
an error.</para>
<para>For example:
- <programlisting># Modify sysfs but don't fail if we are in a container with a read-only /proc
+ <programlisting># Modify sysfs but do not fail if we are in a container with a read-only /proc
w- /proc/sys/vm/swappiness - - - - 10</programlisting></para>
<para>If the equals sign (<literal>=</literal>) is used, the file types of existing objects in the specified path
sudo systemd-cryptsetup attach mytest /dev/sdXn - tpm2-device=auto
# If that worked, let's now add the same line persistently to /etc/crypttab,
-# for the future. We don't want to use the (unstable) /dev/sdX name, so let's
+# for the future. We do not want to use the (unstable) /dev/sdX name, so let's
# figure out a stable link:
udevadm info -q symlink -r /dev/sdXn
<varlistentry>
<term><literal>!=</literal></term>
<listitem>
- <para>Compare for inequality. (The specified key doesn't have the specified value, or the
+ <para>Compare for inequality. (The specified key does not have the specified value, or the
specified key is not present at all.)
</para>
</listitem>
<term><option>--include-parents</option></term>
<listitem>
<para>Trigger parent devices of found devices even if the parents
- won't match the filter condition.
+ will not match the filter condition.
This is useful if we are interested to limit the coldplug activities to
some devices or subsystems.</para>
<title>Format a File System</title>
<para>Take a lock on the backing block device while creating a file system, to ensure that
- <command>systemd-udevd</command> doesn't probe or announce the new superblock before it is
+ <command>systemd-udevd</command> does not probe or announce the new superblock before it is
comprehensively written:</para>
<programlisting># udevadm lock --device=/dev/sda1 mkfs.ext4 /dev/sda1</programlisting>
<title>Copy in a File System</title>
<para>Take a lock on the backing block device while copying in a prepared file system image, to ensure
- that <command>systemd-udevd</command> doesn't probe or announce the new superblock before it is fully
+ that <command>systemd-udevd</command> does not probe or announce the new superblock before it is fully
written:</para>
<programlisting># udevadm lock -d /dev/sda1 dd if=fs.raw of=/dev/sda1</programlisting>
[Slice]
TasksMax=33%</programlisting>
- <para>The <filename>user-<replaceable>UID</replaceable>.slice</filename> units by default don't
+ <para>The <filename>user-<replaceable>UID</replaceable>.slice</filename> units by default do not
have a unit file. The resource limits are set through a drop-in, which can be easily replaced
or extended following standard drop-in mechanisms discussed in the first section.</para>
</example>
<term><option>--synthesize=<replaceable>BOOL</replaceable></option></term>
<listitem><para>Controls whether to synthesize records for the root and nobody users/groups if they
- aren't defined otherwise. By default (or <literal>yes</literal>) such records are implicitly
+ are not defined otherwise. By default (or <literal>yes</literal>) such records are implicitly
synthesized if otherwise missing since they have special significance to the OS. When
<literal>no</literal> this synthesizing is turned off.</para>
AuthorizedKeysCommandUser root
…</programlisting>
- <para>Sometimes it's useful to allow chain invocation of another program to list SSH authorized keys. By
+ <para>Sometimes it is useful to allow chain invocation of another program to list SSH authorized keys. By
using the <option>--chain</option> such a tool may be chain executed by <command>userdbctl
ssh-authorized-keys</command> once a lookup completes (regardless of whether an SSH key was found or
not). Example:</para>
<listitem><para>Use forward error correction (<acronym>FEC</acronym>) to recover from corruption if hash verification fails. Use
encoding data from the specified device. The fec device argument can be block device or file image.
- If fec device path doesn't exist, it will be created as file. Note: block sizes for data and hash devices must
+ If fec device path does not exist, it will be created as file. Note: block sizes for data and hash devices must
match. Also, if the verity data_device is encrypted the fec_device should be too.</para>
<xi:include href="version-info.xml" xpointer="v254"/></listitem>
<citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>
units marked with <option>x-initrd.mount</option>.</para>
- <para>Although it's not necessary to mark the mount entry for the root file system with
+ <para>Although it is not necessary to mark the mount entry for the root file system with
<option>x-initrd.mount</option>, <option>x-initrd.attach</option> is still recommended with
the verity protected block device containing the root file system as otherwise systemd
- will attempt to detach the device during the regular system shutdown while it's still in
+ will attempt to detach the device during the regular system shutdown while it is still in
use. With this option the device will still be detached but later after the root file
system is unmounted.</para>
# the token with.
ykman piv generate-certificate --subject "Knobelei" 9d pubkey.pem
-# We don't need the public key anymore, let's remove it. Since it is not
+# We do not need the public key anymore, let's remove it. Since it is not
# security sensitive we just do a regular "rm" here.
rm pubkey.pem
sudo systemd-cryptsetup attach mytest /dev/sdXn - pkcs11-uri=auto
# If that worked, let's now add the same line persistently to /etc/crypttab,
-# for the future. We don't want to use the (unstable) /dev/sdX name, so let's
+# for the future. We do not want to use the (unstable) /dev/sdX name, so let's
# figure out a stable link:
udevadm info -q symlink -r /dev/sdXn
projects / thirdparty / systemd.git / commitdiff
