BUG/MEDIUM: listener: mark the thread as not stuck inside the loop
We tried hard to make sure we report threads as not stuck at various
crucial places, but one of them is special, it's the listener_accept()
function. The reason it is special is because it will loop a certain
number of times (default: 64) accepting incoming connections, allocating
resources, dispatching them to other threads or running L4 rules on them,
and while all of this is supposed to be extremely fast, when the machine
slows down or runs low on memory, the expectedly small delays in malloc()
caused by contention with other threads can quickly accumulate and suddenly
become critical to the point of triggering the watchdog. Furthermore, it
is technically possible to trigger this by pure configuration by setting
a huge tune.maxaccept value, which should not be possible.
Given that each operation isn't related to the same task but to a different
one each time, it is appropriate to mark the thread as not stuck each time
it accepts new work that possibly gets dispatched to other threads which
execute it.
This looks like this could be a good reason for the issue reported in
issue #388.
This fix must be backported to 2.0.
(cherry picked from commit 8d2c98b76c505e199ba3abac632fa98aab9f7b20)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 1c997412c8bc166ddc986bf6e8af633a4640a212)
Signed-off-by: Willy Tarreau <w@1wt.eu>
diff --git a/src/listener.c b/src/listener.c
index 352c788..b68eb8c 100644
--- a/src/listener.c
+++ b/src/listener.c
@@ -1021,6 +1021,7 @@
}
#endif
+ ti->flags &= ~TI_FL_STUCK; // this thread is still running
} /* end of for (max_accept--) */
/* we've exhausted max_accept, so there is no need to poll again */