BUG/MEDIUM: peers: limit reconnect attempts of the old process on reload
When peers are configured and HAProxy is reloaded or restarted, a
synchronization is performed between the old process and the new one. To do
so, the old process connects on the new one. If the synchronization fails,
it retries. However, there is no delay and reconnect attempts are not
bounded. Thus, it may loop for a while, consuming all the CPU. Of course, it
is unexpected, but it is possible. For instance, if the local peer is
misconfigured, an infinite loop can be observed if the connection succeeds
but not the synchronization. This prevents the old process to exit, except
if "hard-stop-after" option is set.
To fix the bug, the reconnect is delayed. The local peer already has a
expiration date to delay the reconnects. But it was not used on stopping
mode. So we use it not. Thanks to the previous fix, the reconnect timeout is
shorter in this case (500ms against 5s on running mode). In addition, we
also use the peers resync expiration date to not infinitely retries. It is
accurate because the new process, on its side, use this timeout to switch
from a local resync to a remote resync.
This patch depends on "MINOR: peers: Use a dedicated reconnect timeout when
stopping the local peer". It fixes the issue #1799. It should be backported
as far as 2.0.
(cherry picked from commit 160fff665e326952ed35aea9be5ed93cefae9c2e)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 17356a29d821a331ea98ebb8526508639eb6705d)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit c47b045ad2b0e56bb23d8988410d7c8a57edf9a5)
Signed-off-by: Willy Tarreau <w@1wt.eu>
1 file changed