diff options
| author | Lennart Poettering <lennart@poettering.net> | 2016-05-02 13:01:26 +0200 |
|---|---|---|
| committer | Lennart Poettering <lennart@poettering.net> | 2016-05-02 13:08:00 +0200 |
| commit | 072993504e3e4206ae1019f5461a0372f7d82ddf (patch) | |
| tree | feaea95e2790ba6adb7903b2c646c8546b52cb10 /man | |
| parent | 82f8bae2113f52ac9849ca085aaaf26d8c9620aa (diff) | |
| download | systemd-072993504e3e4206ae1019f5461a0372f7d82ddf.tar.gz | |
core: move enforcement of the start limit into per-unit-type code again
Let's move the enforcement of the per-unit start limit from unit.c into the
type-specific files again. For unit types that know a concept of "result" codes
this allows us to hook up the start limit condition to it with an explicit
result code. Also, this makes sure that the state checks in clal like
service_start() may be done before the start limit is checked, as the start
limit really should be checked last, right before everything has been verified
to be in order.
The generic start limit logic is left in unit.c, but the invocation of it is
moved into the per-type files, in the various xyz_start() functions, so that
they may place the check at the right location.
Note that this change drops the enforcement entirely from device, slice, target
and scope units, since these unit types generally may not fail activation, or
may only be activated a single time. This is also documented now.
Note that restores the "start-limit-hit" result code that existed before
6bf0f408e4833152197fb38fb10a9989c89f3a59 already in the service code. However,
it's not introduced for all units that have a result code concept.
Fixes #3166.
Diffstat (limited to 'man')
| -rw-r--r-- | man/systemd.unit.xml | 4 |
1 files changed, 3 insertions, 1 deletions
diff --git a/man/systemd.unit.xml b/man/systemd.unit.xml index abd47bd237..90a1ec6b9c 100644 --- a/man/systemd.unit.xml +++ b/man/systemd.unit.xml @@ -770,7 +770,9 @@ <command>systemctl reset-failed</command> will cause the restart rate counter for a service to be flushed, which is useful if the administrator wants to manually start a unit and the start limit interferes with that. Note that this rate-limiting is enforced after any unit condition checks are executed, and hence unit - activations with failing conditions are not counted by this rate limiting.</para></listitem> + activations with failing conditions are not counted by this rate limiting. Slice, target, device and scope + units do not enforce this setting, as they are unit types whose activation may either never fail, or may + succeed only a single time.</para></listitem> </varlistentry> <varlistentry> |