man: document that start limiting of GC'ed units doesn't work (#7337)

Fixes: #7139
This commit is contained in:
Lennart Poettering 2017-11-17 15:18:30 +01:00 committed by Zbigniew Jędrzejewski-Szmek
parent a53dbb34ff
commit b94f4313e8
1 changed files with 18 additions and 15 deletions

View File

@ -831,25 +831,28 @@
<term><varname>StartLimitBurst=<replaceable>burst</replaceable></varname></term>
<listitem><para>Configure unit start rate limiting. Units which are started more than
<replaceable>burst</replaceable> times within an <replaceable>interval</replaceable> time interval
are not permitted to start any more. Use <varname>StartLimitIntervalSec=</varname> to configure the
checking interval (defaults to <varname>DefaultStartLimitIntervalSec=</varname> in manager configuration file,
set it to 0 to disable any kind of rate limiting). Use <varname>StartLimitBurst=</varname> to configure how many
starts per interval are allowed (defaults to <varname>DefaultStartLimitBurst=</varname> in manager
configuration file). These configuration options are particularly useful in conjunction with the service
setting <varname>Restart=</varname> (see
<replaceable>burst</replaceable> times within an <replaceable>interval</replaceable> time interval are not
permitted to start any more. Use <varname>StartLimitIntervalSec=</varname> to configure the checking interval
(defaults to <varname>DefaultStartLimitIntervalSec=</varname> in manager configuration file, set it to 0 to
disable any kind of rate limiting). Use <varname>StartLimitBurst=</varname> to configure how many starts per
interval are allowed (defaults to <varname>DefaultStartLimitBurst=</varname> in manager configuration
file). These configuration options are particularly useful in conjunction with the service setting
<varname>Restart=</varname> (see
<citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>); however,
they apply to all kinds of starts (including manual), not just those triggered by the
<varname>Restart=</varname> logic. Note that units which are configured for <varname>Restart=</varname> 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 <replaceable>interval</replaceable> has passed.
From this point on, the restart logic is activated again. Note that
<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 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.</para></listitem>
manually at a later point, after the <replaceable>interval</replaceable> has passed. From this point on, the
restart logic is activated again. Note that <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 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.</para>
<para>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.</para></listitem>
</varlistentry>
<varlistentry>