]> git.ipfire.org Git - thirdparty/systemd.git/commitdiff
man: document that start limiting of GC'ed units doesn't work (#7337)
authorLennart Poettering <lennart@poettering.net>
Fri, 17 Nov 2017 14:18:30 +0000 (15:18 +0100)
committerZbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
Fri, 17 Nov 2017 14:18:30 +0000 (15:18 +0100)
Fixes: #7139
man/systemd.unit.xml

index 72c66028f89417abc4ee144707026423098d729a..4f39505aed585c8362c1b3719ec7d52423013ce1 100644 (file)
         <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>