Revert "core: check start limit on condition checks too"

This reverts commit 2de9b9793b91f492141f090dcc89445511e94bd4.

This check causes regressions, in particular our own units fail. Apparently, it
is enough for the unit to be referenced enough times:

$ journalctl -b -u systemd-ask-password-console.path
Aug 30 12:08:14 krowka systemd[1]: Condition check resulted in Dispatch Password Requests to Console Directory Watch being skipped.
Aug 30 12:08:33 krowka systemd[1]: Condition check resulted in Dispatch Password Requests to Console Directory Watch being skipped.
Aug 30 12:08:33 krowka systemd[1]: Condition check resulted in Dispatch Password Requests to Console Directory Watch being skipped.
Aug 30 12:08:33 krowka systemd[1]: Condition check resulted in Dispatch Password Requests to Console Directory Watch being skipped.
Aug 30 12:08:33 krowka systemd[1]: Condition check resulted in Dispatch Password Requests to Console Directory Watch being skipped.
Aug 30 12:08:33 krowka systemd[1]: systemd-ask-password-console.path: Start request repeated too quickly.
Aug 30 12:08:33 krowka systemd[1]: Failed to start Dispatch Password Requests to Console Directory Watch.

$ journalctl -b -u systemd-firstboot.service
-- Logs begin at Sun 2019-04-21 12:39:21 CEST, end at Fri 2019-08-30 12:23:06 CEST. --
Aug 30 12:08:33 krowka systemd[1]: Condition check resulted in First Boot Wizard being skipped.
Aug 30 12:08:33 krowka systemd[1]: Condition check resulted in First Boot Wizard being skipped.
Aug 30 12:08:33 krowka systemd[1]: Condition check resulted in First Boot Wizard being skipped.
Aug 30 12:08:33 krowka systemd[1]: Condition check resulted in First Boot Wizard being skipped.
Aug 30 12:08:33 krowka systemd[1]: systemd-firstboot.service: Start request repeated too quickly.
Aug 30 12:08:33 krowka systemd[1]: Failed to start First Boot Wizard.

And the same for other units.

Fixes #13434.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=935829

diff --git a/src/core/unit.c b/src/core/unit.c
index a2944cbc15c2661b1f64493eec1a62a67da62d33..64eb12733aa783960779f5c3700e519abf51d720 100644 (file)
--- a/src/core/unit.c
+++ b/src/core/unit.c
@@ -1751,7 +1751,6 @@ static bool unit_verify_deps(Unit *u) {
 int unit_start(Unit *u) {
         UnitActiveState state;
         Unit *following;
-        int r;
 
         assert(u);
 
@@ -1776,25 +1775,8 @@ int unit_start(Unit *u) {
          * still be useful to speed up activation in case there is some hold-off time, but we don't want to
          * recheck the condition in that case. */
         if (state != UNIT_ACTIVATING &&
-            !unit_test_condition(u)) {
-
-                /* Let's also check the start limit here. Normally, the start limit is only checked by the
-                 * .start() method of the unit type after it did some additional checks verifying everything
-                 * is in order (so that those other checks can propagate errors properly). However, if a
-                 * condition check doesn't hold we don't get that far but we should still ensure we are not
-                 * called in a tight loop without a rate limit check enforced, hence do the check here. Note
-                 * that ECOMM is generally not a reason for a job to fail, unlike most other errors here,
-                 * hence the chance is big that any triggering unit for us will trigger us again. Note this
-                 * condition check is a bit different from the condition check inside the per-unit .start()
-                 * function, as this one will not change the unit's state in any way (and we shouldn't here,
-                 * after all the condition failed). */
-
-                r = unit_test_start_limit(u);
-                if (r < 0)
-                        return r;
-
+            !unit_test_condition(u))
                 return log_unit_debug_errno(u, SYNTHETIC_ERRNO(ECOMM), "Starting requested but condition failed. Not starting unit.");
-        }
 
         /* If the asserts failed, fail the entire job */
         if (state != UNIT_ACTIVATING &&