From b94f4313e87c7af005eabc40ab60aeb9709022de Mon Sep 17 00:00:00 2001 From: Lennart Poettering Date: Fri, 17 Nov 2017 15:18:30 +0100 Subject: [PATCH] man: document that start limiting of GC'ed units doesn't work (#7337) Fixes: #7139 --- man/systemd.unit.xml | 33 ++++++++++++++++++--------------- 1 file changed, 18 insertions(+), 15 deletions(-) diff --git a/man/systemd.unit.xml b/man/systemd.unit.xml index 72c66028f89..4f39505aed5 100644 --- a/man/systemd.unit.xml +++ b/man/systemd.unit.xml @@ -831,25 +831,28 @@ StartLimitBurst=burst Configure unit start rate limiting. Units which are started more than - burst times within an interval time interval - are not permitted to start any more. Use StartLimitIntervalSec= to configure the - checking interval (defaults to DefaultStartLimitIntervalSec= in manager configuration file, - set it to 0 to disable any kind of rate limiting). Use StartLimitBurst= to configure how many - starts per interval are allowed (defaults to DefaultStartLimitBurst= in manager - configuration file). These configuration options are particularly useful in conjunction with the service - setting Restart= (see + burst times within an interval time interval are not + permitted to start any more. Use StartLimitIntervalSec= to configure the checking interval + (defaults to DefaultStartLimitIntervalSec= in manager configuration file, set it to 0 to + disable any kind of rate limiting). Use StartLimitBurst= to configure how many starts per + interval are allowed (defaults to DefaultStartLimitBurst= in manager configuration + file). These configuration options are particularly useful in conjunction with the service setting + Restart= (see systemd.service5); however, they apply to all kinds of starts (including manual), not just those triggered by the Restart= logic. Note that units which are configured for Restart= and which reach the start limit are not attempted to be restarted anymore; however, they may still be restarted - manually at a later point, after the interval has passed. - From this point on, the restart logic is activated again. Note that - systemctl reset-failed 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 do not count towards this rate limit. This setting does not apply to - slice, target, device, and scope units, since they are unit types whose activation may either never fail, or - may succeed only a single time. + manually at a later point, after the interval has passed. From this point on, the + restart logic is activated again. Note that systemctl reset-failed 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 do not count towards this rate + limit. This setting does not apply to slice, target, device, and scope units, since they are unit types whose + activation may either never fail, or may succeed only a single time. + + When a unit is unloaded due to the garbage collection logic (see above) its rate limit counters are + flushed out too. This means that configuring start rate limiting for a unit that is not referenced continously + has no effect.