diff options
| author | Michal Koutný <mkoutny@suse.com> | 2017-02-17 17:47:20 +0100 |
|---|---|---|
| committer | Michal Koutný <mkoutny@suse.com> | 2017-04-25 18:00:29 +0200 |
| commit | a2df3ea4ae058693bc7bf203d144e8af3c9493d2 (patch) | |
| tree | e27f533ddbe214617cb5b144d2d4d778b67a3df6 /man | |
| parent | 9e49656037717b96c06b1f1507a41550bdb2c795 (diff) | |
| download | systemd-a2df3ea4ae058693bc7bf203d144e8af3c9493d2.tar.gz | |
job: add JobRunningTimeoutSec for JOB_RUNNING state
Unit.JobTimeoutSec starts when a job is enqueued in a transaction. The
introduced distinct Unit.JobRunningTimeoutSec starts only when the job starts
running (e.g. it groups all Exec* commands of a service or spans waiting for a
device period.)
Unit.JobRunningTimeoutSec is intended to be used by default instead of
Unit.JobTimeoutSec for device units where such behavior causes less confusion
(consider a job for a _netdev mount device, with this change the timeout will
start ticking only after the network is ready).
Diffstat (limited to 'man')
| -rw-r--r-- | man/systemd.unit.xml | 19 |
1 files changed, 11 insertions, 8 deletions
diff --git a/man/systemd.unit.xml b/man/systemd.unit.xml index 44841ac7dd..23f62542d0 100644 --- a/man/systemd.unit.xml +++ b/man/systemd.unit.xml @@ -718,17 +718,20 @@ <varlistentry> <term><varname>JobTimeoutSec=</varname></term> + <term><varname>JobRunningTimeoutSec=</varname></term> <term><varname>JobTimeoutAction=</varname></term> <term><varname>JobTimeoutRebootArgument=</varname></term> - <listitem><para>When a job for this unit is queued, a time-out may be configured. If this 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 disabled), - except for device units. NB: this timeout is independent from any unit-specific timeout (for example, the - timeout set with <varname>TimeoutStartSec=</varname> in service units) as the job timeout has no effect on the - unit itself, only on the job that might be pending for it. Or in other words: unit-specific timeouts are useful - to abort unit state changes, and revert them. The job timeout set with this option however is useful to abort - only the job waiting for the unit state to change.</para> + <listitem><para>When a job for this unit is queued, a time-out <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 + disabled), except for device units (<varname>JobRunningTimeoutSec=</varname> defaults to + <varname>DefaultTimeoutStartSec=</varname>). NB: this timeout is independent from any unit-specific timeout + (for example, the timeout set with <varname>TimeoutStartSec=</varname> in service units) as the job timeout has + no effect on the unit itself, only on the job that might be pending for it. Or in other words: unit-specific + timeouts are useful to abort unit state changes, and revert them. The job timeout set with this option however + is useful to abort only the job waiting for the unit state to change.</para> <para><varname>JobTimeoutAction=</varname> optionally configures an additional |