Make scheduling loop detector less sensitive

It could be triggered by delayed name resolving as it adds multiple new
timeouts which can be called in the same dispatching if the DNS responses
are slower than initial delay and sampling separation.

Compare number of dispatched events also with current number of
timeouts.

diff --git a/sched.c b/sched.c
index 5ea93f68e4e5d9a793ac822d6b5a4deeaac13080..ae17783d6f82b207b2c64f316e4096f61bf151dc 100644 (file)
--- a/sched.c
+++ b/sched.c
@@ -466,11 +466,12 @@ dispatch_timeouts(struct timeval *now) {
     ++n_done;
 
     /* If more timeouts were handled than there were in the timer queue on
-       start, assume some code is scheduling timeouts with negative delays and
-       abort.  Make the actual limit higher in case the machine is temporarily
-       overloaded and dispatching the handlers takes more time than was delay
-       of a scheduled timeout. */
-    if (n_done > n_entries_on_start * 4) {
+       start and there are now, assume some code is scheduling timeouts with
+       negative delays and abort.  Make the actual limit higher in case the
+       machine is temporarily overloaded and dispatching the handlers takes
+       more time than was delay of a scheduled timeout. */
+    if (n_done > n_timer_queue_entries * 4 &&
+        n_done > n_entries_on_start * 4) {
       LOG_FATAL(LOGF_Scheduler, "Possible infinite loop in scheduling");
     }
   }