mirror of
https://git.haproxy.org/git/haproxy.git/
synced 2026-05-02 11:41:07 +02:00
64383e655b
In master-worker mode the master CLI proxy (mworker_proxy) has a hardcoded maxconn of 10. When a client connects to the master CLI socket and issues a command that gets forwarded to an unresponsive worker (e.g. one that is stuck or very slow), the connection hangs waiting for the worker's response. If the client then disconnects (timeout, Ctrl-C, etc.), the connection slot is never released because the client-side FIN is never acknowledged by the unresponsive worker. After 10 such leaked slots the master CLI socket becomes completely unreachable, returning "Resource temporarily unavailable" to any new connection attempt. In containerized deployments this means readiness probes start failing and the pod gets restarted. The fix adds a timeout server-fin of 1s to the mworker_proxy. When the client disconnects while waiting for a worker response, this timeout ensures the dangling backend connection is cleaned up after 1s, freeing the connection slot. This does not affect normal CLI operations since the timeout only starts after the client has already closed its side of the connection. A regression test is included that blocks the worker CLI thread using "debug dev delay" with nbthread 1, fills all 10 master CLI slots, waits for client-side timeouts, then verifies a new connection still succeeds. This fixes GH issue #3351. This should be backported to all stable branches. Co-authored-by: Martin Strenge <github@trixer.net> Co-authored-by: William Lallemand <wlallemand@haproxy.com>