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
- sessions will appear hung until the user logs in on another virtual terminal (regardless if via
+ 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
appears hung, keypresses can still be queued into it, and the existing screen contents be read
<listitem><para>Takes a boolean parameter; used in conjunction with <command>query</command>. If true
(the default), lookups use the local DNS resource record cache. If false, lookups are routed to the
- network instead, regardless if already available in the local cache.</para>
+ network instead, regardless of whether already available in the local cache.</para>
<xi:include href="version-info.xml" xpointer="v248"/></listitem>
</varlistentry>
<para><function>sd_bus_track_count()</function> returns the number of names currently being tracked by the
specified bus peer tracking object. Note that this function always returns the actual number of names tracked, and
hence if <function>sd_bus_track_add_name()</function> has been invoked multiple times for the same name it is only
- counted as one, regardless if recursive mode is used or not.</para>
+ counted as one, regardless of whether recursive mode is used or not.</para>
<para><function>sd_bus_track_count_name()</function> returns the current per-name counter for the specified
name. If non-recursive mode is used this returns either 1 or 0, depending on whether the specified name has been
<para><function>sd_event_source_get_child_pidfd()</function> retrieves the file descriptor referencing
the watched process ("pidfd") if this functionality is available. On kernels that support the concept the
- event loop will make use of pidfds to watch child processes, regardless if the individual event sources
+ event loop will make use of pidfds to watch child processes, regardless of whether the individual event sources
are allocated via <function>sd_event_add_child()</function> or
<function>sd_event_add_child_pidfd()</function>. If the latter call was used to allocate the event
source, this function returns the file descriptor used for allocation. On kernels that do not support the
all mount units that mount and failed are kept in memory until the user explicitly resets their failure state with
<command>systemctl reset-failed</command> or an equivalent command. On the other hand, units that stopped
successfully are unloaded immediately. If this option is turned on the "garbage collection" of units is more
- aggressive, and unloads units regardless if they exited successfully or failed. This option is a shortcut for
+ aggressive, and unloads units regardless of whether they exited successfully or failed. This option is a shortcut for
<command>--property=CollectMode=inactive-or-failed</command>, see the explanation for
<varname>CollectMode=</varname> in
<citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> for further
<para>Note that if one of the volatile modes is chosen, its effect is limited to the root file system
(or <filename>/var/</filename> in case of <option>state</option>), and any other mounts placed in the
- hierarchy are unaffected — regardless if they are established automatically (e.g. the EFI system
+ hierarchy are unaffected — regardless of whether they are established automatically (e.g. the EFI system
partition that might be mounted to <filename>/efi/</filename> or <filename>/boot/</filename>) or
explicitly (e.g. through an additional command line option such as <option>--bind=</option>, see
below). This means, even if <option>--volatile=overlay</option> is used changes to
all units that ran and failed are kept in memory until the user explicitly resets their failure state with
<command>systemctl reset-failed</command> or an equivalent command. On the other hand, units that ran
successfully are unloaded immediately. If this option is turned on the "garbage collection" of units is more
- aggressive, and unloads units regardless if they exited successfully or failed. This option is a shortcut for
+ aggressive, and unloads units regardless of whether they exited successfully or failed. This option is a shortcut for
<command>--property=CollectMode=inactive-or-failed</command>, see the explanation for
<varname>CollectMode=</varname> in
<citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> for further
<listitem><para>Similar to <varname>LoaderDevicePartUUID</varname> and
<varname>StubImageIdentifier</varname>, but indicates the location of the unified kernel image EFI
- binary rather than the location of the boot loader binary, regardless if booted via a boot loader
+ binary rather than the location of the boot loader binary, regardless of whether booted via a boot loader
or not.</para>
<xi:include href="version-info.xml" xpointer="v257"/></listitem>
component over the immutable OS image without doing a full OS rebuild or modifying the nominally
immutable image. (e.g. "install" a locally built package with <command>DESTDIR=/var/lib/extensions/mytest
make install && systemd-sysext refresh</command>, making it available in
- <filename>/usr/</filename> as if it was installed in the OS image itself.) This case works regardless if
- the underlying host <filename>/usr/</filename> is managed as immutable disk image or is a traditional
+ <filename>/usr/</filename> as if it was installed in the OS image itself.) This case works regardless of
+ whether the underlying host <filename>/usr/</filename> is managed as immutable disk image or is a traditional
package manager controlled (i.e. writable) tree.</para>
<para>With <command>systemd-confext</command> one can perform runtime reconfiguration of OS services.
process capability isolation.</para>
<para>If this mode is enabled, all unit processes are run without privileges in the host user
- namespace (regardless if the unit's own user/group is <literal>root</literal> or not). Specifically
+ namespace (regardless of whether the unit's own user/group is <literal>root</literal> or not). Specifically
this means that the process will have zero process capabilities on the host's user namespace, but
full capabilities within the service's user namespace. Settings such as
<varname>CapabilityBoundingSet=</varname> will affect only the latter, and there's no way to acquire
user-defined string identifying the namespace. If not used the processes of the service are run in
the default journal namespace, i.e. their log stream is collected and processed by
<filename>systemd-journald.service</filename>. If this option is used any log data generated by
- processes of this unit (regardless if via the <function>syslog()</function>, journal native logging
+ processes of this unit (regardless of whether via the <function>syslog()</function>, journal native logging
or stdout/stderr logging) is collected and processed by an instance of the
<filename>systemd-journald@.service</filename> template unit, which manages the specified
namespace. The log data is stored in a data store independent from the default log namespace's data
included in the image, regardless whether the configured image policy would allow access to it or
not. Similar,
<citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry> is not
- going to make use of any discovered swap device, regardless if the policy would allow that or not.</para>
+ going to make use of any discovered swap device, regardless of whether the policy would allow that or not.</para>
<para>Use the <command>image-policy</command> command of the
<citerefentry><refentrytitle>systemd-analyze</refentrytitle><manvolnum>1</manvolnum></citerefentry> tool
<citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>).
</para>
- <para>Note that the start timeout is also applied to service reloads, regardless if implemented
+ <para>Note that the start timeout is also applied to service reloads, regardless of whether implemented
through <varname>ExecReload=</varname> or via the reload logic enabled via <varname>Type=notify-reload</varname>.
If the reload does not complete within the configured time, the reload will be considered failed and
the service will continue running with the old configuration. This will not affect the running service,
milestone indicating if and when SSH access into the system is available. It should only become
active when an SSH port is bound for remote clients (i.e. if SSH is used as a local privilege
escalation mechanism, it should <emphasis>not</emphasis> involve this target unit), regardless of
- the protocol choices, i.e. regardless if IPv4, IPv6 or <constant>AF_VSOCK</constant> is
+ the protocol choices, i.e. regardless of whether IPv4, IPv6 or <constant>AF_VSOCK</constant> is
used.</para>
<xi:include href="version-info.xml" xpointer="v256"/>
</listitem>
removed unless applied to a directory. This functionality is particularly useful in conjunction with
<varname>Z</varname>.</para>
- <para>By default the access mode of listed inodes is set to the specified mode regardless if it is
+ <para>By default the access mode of listed inodes is set to the specified mode regardless of whether it is
created anew, or already existed. Optionally, if prefixed with <literal>:</literal>, the configured
access mode is only applied when creating new inodes, and if the inode the line refers to
already exists, its access mode is left in place unmodified.</para>
Resolvability of User and Group Names</ulink> for more information on requirements on system user/group
definitions.</para>
- <para>By default the ownership of listed inodes is set to the specified user/group regardless if it is
+ <para>By default the ownership of listed inodes is set to the specified user/group regardless of whether it is
created anew, or already existed. Optionally, if prefixed with <literal>:</literal>, the configured
user/group information is only applied when creating new inodes, and if the inode the line refers to
already exists, its user/group is left in place unmodified.</para>
<para>Sometimes it's 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 if an SSH key was found or
+ ssh-authorized-keys</command> once a lookup completes (regardless of whether an SSH key was found or
not). Example:</para>
<programlisting>…
<para>If this mode is enabled output is automatically switched to JSON-SEQ mode, so that individual
reply objects can be easily discerned.</para>
- <para>This switch has no effect on the method call timeout applied by default: regardless if
- <option>--more</option> is specified or not, the default timeout will be 45s. Use
+ <para>This switch has no effect on the method call timeout applied by default: regardless of
+ whether <option>--more</option> is specified or not, the default timeout will be 45s. Use
<option>--timeout=</option> (see below) to change or disable the timeout. When invoking a method
call that continuously returns updates it is typically desirable to disable the timeout with
<option>--timeout=infinity</option>. On the other hand, when invoking a <option>--more</option>
projects / thirdparty / systemd.git / commitdiff
