picnoir
/
Systemd
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

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
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

33
man/systemd.unit.xml
View File

@ -831,25 +831,28 @@
<term><varname>StartLimitBurst=<replaceable>burst</replaceable></varname></term> <term><varname>StartLimitBurst=<replaceable>burst</replaceable></varname></term>
<listitem><para>Configure unit start rate limiting. Units which are started more than <listitem><para>Configure unit start rate limiting. Units which are started more than
<replaceable>burst</replaceable> times within an <replaceable>interval</replaceable> time interval <replaceable>burst</replaceable> times within an <replaceable>interval</replaceable> time interval are not
are not permitted to start any more. Use <varname>StartLimitIntervalSec=</varname> to configure the permitted to start any more. Use <varname>StartLimitIntervalSec=</varname> to configure the checking interval
checking interval (defaults to <varname>DefaultStartLimitIntervalSec=</varname> in manager configuration file, (defaults to <varname>DefaultStartLimitIntervalSec=</varname> in manager configuration file, set it to 0 to
set it to 0 to disable any kind of rate limiting). Use <varname>StartLimitBurst=</varname> to configure how many disable any kind of rate limiting). Use <varname>StartLimitBurst=</varname> to configure how many starts per
starts per interval are allowed (defaults to <varname>DefaultStartLimitBurst=</varname> in manager interval are allowed (defaults to <varname>DefaultStartLimitBurst=</varname> in manager configuration
configuration file). These configuration options are particularly useful in conjunction with the service file). These configuration options are particularly useful in conjunction with the service setting
setting <varname>Restart=</varname> (see <varname>Restart=</varname> (see
<citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>); however, <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 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 <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 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. manually at a later point, after the <replaceable>interval</replaceable> has passed. From this point on, the
From this point on, the restart logic is activated again. Note that restart logic is activated again. Note that <command>systemctl reset-failed</command> will cause the restart
<command>systemctl reset-failed</command> will cause the restart rate counter for a service to be flushed, rate counter for a service to be flushed, which is useful if the administrator wants to manually start a unit
which is useful if the administrator wants to manually start a unit and the start limit interferes with and the start limit interferes with that. Note that this rate-limiting is enforced after any unit condition
that. Note that this rate-limiting is enforced after any unit condition checks are executed, and hence unit checks are executed, and hence unit activations with failing conditions do not count towards this rate
activations with failing conditions do not count towards this rate limit. This setting does not apply to limit. This setting does not apply to slice, target, device, and scope units, since they are unit types whose
slice, target, device, and scope units, since they are unit types whose activation may either never fail, or activation may either never fail, or may succeed only a single time.</para>
may succeed only a single time.</para></listitem>
<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>
<varlistentry> <varlistentry>