]> git.ipfire.org Git - thirdparty/haproxy.git/commit
BUG/MEDIUM: clock: also update the date offset on time jumps
authorWilly Tarreau <w@1wt.eu>
Wed, 4 Sep 2024 14:55:43 +0000 (16:55 +0200)
committerWilly Tarreau <w@1wt.eu>
Wed, 4 Sep 2024 14:55:43 +0000 (16:55 +0200)
commite8b1ad4c2b3985eb9e826fd279e419719a2c03ce
treea56ab68f6d06ce4f649b0cef790fd39d1f20a71d
parent531bf44a651df3b513fd9f091e46e702c1753254
BUG/MEDIUM: clock: also update the date offset on time jumps

In GH issue #2704, @swimlessbird and @xanoxes reported problems handling
time jumps. Indeed, since 2.7 with commit 4eaf85f5d9 ("MINOR: clock: do
not update the global date too often") we refrain from updating the global
offset in case it didn't change. But there's a catch: in case of a large
time jump, if the poller was interrupted, the local time remains the same
and we return immediately from there without updating the offset. It then
becomes incorrect regarding the "date" value, and upon subsequent call to
the poller, there's no way to detect a jump anymore so we apply the old,
incorrect offset and the date becomes wrong. Worse, going back to the
original time (then in the past), global_now_ns remains higher than the
local time and neither get updated anymore.

What is missing in practice is to immediately update the offset when
detecting a time jump. In an ideal world, the offset would be updated
upon every call, that's what was being done prior to commit above but
it's extremely CPU intensive on large systems. However we can perfectly
afford to update the offset every time we detect a time jump, as it's
not as common.

This needs to be backported as far as 2.8. Thanks to both participants
above for providing very helpful details.
src/clock.c