<varname>Restart=</varname> logic.</para>
<para>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 that point on, the
- restart logic is activated again. <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. Rate-limiting is enforced after any unit
- condition checks are executed, and hence unit activations with failing conditions do not count
- towards the rate limit.</para>
+ limit are not attempted to be restarted anymore; however, they may still be restarted manually or
+ from a timer or socket at a later point, after the <replaceable>interval</replaceable> has passed.
+ From that point on, the restart logic is activated again. <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. Rate-limiting is enforced
+ after any unit condition checks are executed, and hence unit activations with failing conditions do
+ not count towards the rate limit.</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