Debian and FreeBSD resolvconf tool.
* Support for suspend-then-hibernate has been added, i.e. a sleep mode
- where the system initially suspends, and after a time-out resumes and
+ where the system initially suspends, and after a timeout resumes and
hibernates again.
* networkd's ClientIdentifier= now accepts a new option "duid-only". If
/run/systemd/user directory that was already previously
supported, but is under the control of the user.
- * Job timeouts (i.e. time-outs on the time a job that is
+ * Job timeouts (i.e. timeouts on the time a job that is
queued stays in the run queue) can now optionally result in
immediate reboot or power-off actions (JobTimeoutAction= and
JobTimeoutRebootArgument=). This is useful on ".target"
ESP the boot loader was run from formatted as NUL-terminated UTF16 string, in
normal GUID syntax.
-* The EFI variable `LoaderConfigTimeout` contains the boot menu time-out
+* The EFI variable `LoaderConfigTimeout` contains the boot menu timeout
currently in use. It may be modified both by the boot loader and by the
host. The value should be formatted as numeric, NUL-terminated, decimal
string, in UTF-16. The time is specified in µs.
* Similarly, the EFI variable `LoaderConfigTimeoutOneShot` contains a boot menu
- time-out for a single following boot. It is set by the OS in order to request
+ timeout for a single following boot. It is set by the OS in order to request
display of the boot menu on the following boot. When set overrides
`LoaderConfigTimeout`. It is removed automatically after being read by the
boot loader, to ensure it only takes effect a single time. This value is
formatted the same way as `LoaderConfigTimeout`. If set to `0` the boot menu
- time-out is turned off, and the menu is shown indefinitely.
+ timeout is turned off, and the menu is shown indefinitely.
* The EFI variable `LoaderEntries` may contain a series of boot loader entry
identifiers, one after the other, each individually NUL terminated. This may
<varlistentry>
<term><varname>LoaderConfigTimeout</varname></term>
<term><varname>LoaderConfigTimeoutOneShot</varname></term>
- <listitem><para>The menu time-out in seconds. Read by the boot loader. <varname>LoaderConfigTimeout</varname>
+ <listitem><para>The menu timeout in seconds. Read by the boot loader. <varname>LoaderConfigTimeout</varname>
is maintained persistently, while <varname>LoaderConfigTimeoutOneShot</varname> is a one-time override which is
read once (in which case it takes precedence over <varname>LoaderConfigTimeout</varname>) and then
removed. <varname>LoaderConfigTimeout</varname> may be manipulated with the
the command line. If passed, additional metadata is read from the device to enhance the unit to create. For
example, a descriptive string for the transient units is generated from the file system label and device
model. Moreover if a removable block device (e.g. USB stick) is detected an automount unit instead of a regular
- mount unit is created, with a short idle time-out, in order to ensure the file-system is placed in a clean
+ mount unit is created, with a short idle timeout, in order to ensure the file-system is placed in a clean
state quickly after each access.</para></listitem>
</varlistentry>
actual execution of the service program is delayed until all active jobs are dispatched. This may be used
to avoid interleaving of output of shell services with the status output on the console. Note that this
type is useful only to improve console output, it is not useful as a general unit ordering tool, and the
- effect of this service type is subject to a 5s time-out, after which the service program is invoked
+ effect of this service type is subject to a 5s timeout, after which the service program is invoked
anyway.</para></listitem>
</itemizedlist>
<term><varname>JobTimeoutSec=</varname></term>
<term><varname>JobRunningTimeoutSec=</varname></term>
- <listitem><para>When a job for this unit is queued, a time-out <varname>JobTimeoutSec=</varname> may be
+ <listitem><para>When a job for this unit is queued, a timeout <varname>JobTimeoutSec=</varname> may be
configured. Similarly, <varname>JobRunningTimeoutSec=</varname> starts counting when the queued job is actually
started. If either time limit is reached, the job will be cancelled, the unit however will not change state or
even enter the <literal>failed</literal> mode. This value defaults to <literal>infinity</literal> (job timeouts
<term><varname>JobTimeoutRebootArgument=</varname></term>
<listitem><para><varname>JobTimeoutAction=</varname> optionally configures an additional action to take when
- the time-out is hit, see description of <varname>JobTimeoutSec=</varname> and
+ the timeout is hit, see description of <varname>JobTimeoutSec=</varname> and
<varname>JobRunningTimeoutSec=</varname> above. It takes the same values as
<varname>StartLimitAction=</varname>. Defaults to <option>none</option>.
<varname>JobTimeoutRebootArgument=</varname> configures an optional reboot string to pass to the
usec_t method_call_timeout;
};
-/* For method calls we time-out at 25s, like in the D-Bus reference implementation */
+/* For method calls we timeout at 25s, like in the D-Bus reference implementation */
#define BUS_DEFAULT_TIMEOUT ((usec_t) (25 * USEC_PER_SEC))
/* For the authentication phase we grant 90s, to provide extra room during boot, when RNGs and such are not filled up
if (r == 0)
break;
if (r == -ETIMEDOUT) {
- /* Let's catch time-outs here, so that we can run safely in a CI that has no reliable DNS. Note
+ /* Let's catch timeouts here, so that we can run safely in a CI that has no reliable DNS. Note
* that we invoke exit() directly here, as the stuck NSS call will not allow us to exit
* cleanly. */