core: make the StartLimitXYZ= settings generic and apply to any kind of unit, not just services

This moves the StartLimitBurst=, StartLimitInterval=, StartLimitAction=, RebootArgument= from the [Service] section
into the [Unit] section of unit files, and thus support it in all unit types, not just in services.

This way we can enforce the start limit much earlier, in particular before testing the unit conditions, so that
repeated start-up failure due to failed conditions is also considered for the start limit logic.

For compatibility the four options may also be configured in the [Service] section still, but we only document them in
their new section [Unit].

This also renamed the socket unit failure code "service-failed-permanent" into "service-start-limit-hit" to express
more clearly what it is about, after all it's only triggered through the start limit being hit.

Finally, the code in busname_trigger_notify() and socket_trigger_notify() is altered to become more alike.

Fixes: #2467

1 files changed, 4 insertions, 78 deletions

diff --git a/man/systemd.service.xml b/man/systemd.service.xml
index 4cd36ac70e..2145e33d05 100644
--- a/man/systemd.service.xml
+++ b/man/systemd.service.xml
@@ -874,85 +874,11 @@
       </varlistentry>
 
       <varlistentry>
-        <term><varname>StartLimitInterval=</varname></term>
-        <term><varname>StartLimitBurst=</varname></term>
-
-        <listitem><para>Configure service start rate limiting. By
-        default, services which are started more than 5 times within
-        10 seconds are not permitted to start any more times until the
-        10 second interval ends. With these two options, this rate
-        limiting may be modified. Use
-        <varname>StartLimitInterval=</varname> to configure the
-        checking interval (defaults to
-        <varname>DefaultStartLimitInterval=</varname> in manager
-        configuration file, set 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
-        <varname>Restart=</varname>; 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, from which point on, the restart logic is again
-        activated. 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 service and the start limit interferes with
-        that.</para></listitem>
-      </varlistentry>
-
-      <varlistentry>
-        <term><varname>StartLimitAction=</varname></term>
-
-        <listitem><para>Configure the action to take if the rate limit
-        configured with <varname>StartLimitInterval=</varname> and
-        <varname>StartLimitBurst=</varname> is hit. Takes one of
-        <option>none</option>,
-        <option>reboot</option>,
-        <option>reboot-force</option>,
-        <option>reboot-immediate</option>,
-        <option>poweroff</option>,
-        <option>poweroff-force</option> or
-        <option>poweroff-immediate</option>. If
-        <option>none</option> is set, hitting the rate limit will
-        trigger no action besides that the start will not be
-        permitted. <option>reboot</option> causes a reboot following
-        the normal shutdown procedure (i.e. equivalent to
-        <command>systemctl reboot</command>).
-        <option>reboot-force</option> causes a forced reboot which
-        will terminate all processes forcibly but should cause no
-        dirty file systems on reboot (i.e. equivalent to
-        <command>systemctl reboot -f</command>) and
-        <option>reboot-immediate</option> causes immediate execution
-        of the
-        <citerefentry><refentrytitle>reboot</refentrytitle><manvolnum>2</manvolnum></citerefentry>
-        system call, which might result in data loss. Similarly,
-        <option>poweroff</option>, <option>poweroff-force</option>,
-        <option>poweroff-immediate</option> have the effect of
-        powering down the system with similar semantics. Defaults to
-        <option>none</option>.</para></listitem>
-      </varlistentry>
-
-      <varlistentry>
         <term><varname>FailureAction=</varname></term>
-        <listitem><para>Configure the action to take when the service
-        enters a failed state. Takes the same values as
-        <varname>StartLimitAction=</varname> and executes the same
-        actions. Defaults to <option>none</option>. </para></listitem>
-      </varlistentry>
-
-      <varlistentry>
-        <term><varname>RebootArgument=</varname></term>
-        <listitem><para>Configure the optional argument for the
-        <citerefentry><refentrytitle>reboot</refentrytitle><manvolnum>2</manvolnum></citerefentry>
-        system call if <varname>StartLimitAction=</varname> or
-        <varname>FailureAction=</varname> is a reboot action. This
-        works just like the optional argument to <command>systemctl
-        reboot</command> command.</para></listitem>
+        <listitem><para>Configure the action to take when the service enters a failed state. Takes the same values as
+        the unit setting <varname>StartLimitAction=</varname> and executes the same actions (see
+        <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>). Defaults to
+        <option>none</option>. </para></listitem>
       </varlistentry>
 
       <varlistentry>