]> git.ipfire.org Git - thirdparty/haproxy.git/commit
BUG/MEDIUM: wdt/clock: properly handle early task hangs
authorAurelien DARRAGON <adarragon@haproxy.com>
Thu, 10 Nov 2022 10:47:47 +0000 (11:47 +0100)
committerWilly Tarreau <w@1wt.eu>
Mon, 14 Nov 2022 18:14:53 +0000 (19:14 +0100)
commit16d6c0cb0935f94859f56ff015743d6c3e77cb60
treeada523be3d9bfa0549d1fc2154e5d1678f72ea20
parentaa1909edf7a9e841bb6adf63235eb80a236d85f1
BUG/MEDIUM: wdt/clock: properly handle early task hangs

In ae053b30 - BUG/MEDIUM: wdt: don't trigger the watchdog when p is unitialized:
wdt is not triggering until prev_cpu_time
is initialized to prevent unexpected process
termination.

Unfortunately this is not enough, some tasks could start
immediately after process startup, and in such cases
prev_cpu_time could be uninitialized, because
prev_cpu_time is set after the polling loop while
process_runnable_tasks() is executed before the polling loop.

It happens to be the case with lua tasks registered using
register_task function from lua script.

Those tasks are registered in early init stage of haproxy and
they are scheduled to run before the first polling loop,
leading to prev_cpu_time being uninitialized (equals 0)
on the thread when the task is first executed.

Because of this, if such tasks get stuck right away
(e.g: blocking IO) the watchdog won't behave as expected
and the thread will remain stuck indefinitely.
(polling loop for the thread won't run at all as
the thread is already stuck)

To solve this, we're now making sure that prev_cpu_time is first
set before any tasks are processed on the thread.
This is done by setting initial prev_cpu_time value directly
in clock_init_thread_date()

Thanks to Abhijeet Rastogi for reporting this unexpected behavior.

It could be backported in every stable versions.
(everywhere ae053b30 is, because both are related)
src/clock.c