* Previously, in HAProxy 2.6 deployments on OpenShift, shutting down HAproxy could result in a race condition. The main thread `(tid=0)` would wait for other threads to complete, but some threads would enter an infinite loop, consuming 100% CPU. With this release, the variable controlling the loop's termination is now properly reset, preventing non-main threads from looping indefinitely. This ensures that the thread's poll loop can terminate correctly. (link: https://issues.redhat.com/browse/OCPBUGS-33883 [* OCPBUGS-33883 *]) ______________ Previous Behaviour: In HAProxy 2.6 deployments on OpenShift, shutting down haproxy could result in a race condition. The main thread (tid=0) would wait for other threads to complete, but some threads would enter an infinite loop, consuming 100% CPU. This loop involved continuous syscalls such as epoll_wait and clock_gettime. Fixed Behaviour: The issue has been addressed in the upstream issue https://github.com/haproxy/haproxy/issues/2537 and we carry the fix in the following RPM version: haproxy-2.6.13-3.rhaos4.15.el8. The fix ensures that the thread's poll loop can terminate correctly. The variable controlling the loop's termination is now properly reset, preventing non-main threads from looping indefinitely. This change ensures that the "stopping" part of the run_poll_loop() function is reached, allowing all threads to exit cleanly during shutdown, except for the main thread (tid=0), which handles signals.