From 8d2c98b76c505e199ba3abac632fa98aab9f7b20 Mon Sep 17 00:00:00 2001 From: Willy Tarreau Date: Fri, 1 May 2020 09:51:11 +0200 Subject: [PATCH] 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. --- src/listener.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/listener.c b/src/listener.c index ef7567e5e9..829dc99b74 100644 --- a/src/listener.c +++ b/src/listener.c @@ -1036,6 +1036,7 @@ void listener_accept(int fd) } #endif + ti->flags &= ~TI_FL_STUCK; // this thread is still running } /* end of for (max_accept--) */ end: