BUG/MEDIUM: mux-h1: always use RST to kill idle connections in pools
When idle H1 connections cannot be stored into a server pool or are later
evicted, they're often seen closed with a FIN then an RST. The problem is
that this is sufficient to leave them in TIME_WAIT in the local sockets
table and port exhaustion may happen.
The reason is that in h1_release() we rely on h1_shutw_conn() which itself
decides whether to close in silent or normal mode only based on the
H1C_F_ST_SILENT_SHUT flag. This flag is only set by h1_shutw() based on
the requested mode. But when the connection is in the idle list, the mode
ought to always be silent.
What this patch does is to set the flag before trying to add to the idle
list, and remove it after removing from the idle list. This way if the
connection fails to be added or has to be killed, it's closed with an
RST.
This must be backported as far as 2.4. It's not sure whether older
versions need an equivalent.
(cherry picked from commit 4d1ff11f05691aa6820a985c31e72811cf9ef95d)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit bcf4113535c765bb5856a0724f4db7a61d9df757)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
(cherry picked from commit aebb5ec80bfb444a8bf3856a681059f411eb9b0b)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
diff --git a/src/mux_h1.c b/src/mux_h1.c
index ce76e6e..4c4cac5 100644
--- a/src/mux_h1.c
+++ b/src/mux_h1.c
@@ -3070,6 +3070,9 @@
struct conn_stream *cs = NULL;
struct h1s *h1s;
+ /* this connection is no more idle (if it was at all) */
+ h1c->flags &= ~H1C_F_ST_SILENT_SHUT;
+
TRACE_ENTER(H1_EV_STRM_NEW, conn);
if (h1c->flags & H1C_F_ST_ERROR) {
TRACE_ERROR("h1c on error", H1_EV_STRM_NEW|H1_EV_STRM_END|H1_EV_STRM_ERR, conn);
@@ -3154,6 +3157,11 @@
h1s_destroy(h1s);
if ((h1c->flags & (H1C_F_IS_BACK|H1C_F_ST_IDLE)) == (H1C_F_IS_BACK|H1C_F_ST_IDLE)) {
+ /* this connection may be killed at any moment, we want it to
+ * die "cleanly" (i.e. only an RST).
+ */
+ h1c->flags |= H1C_F_ST_SILENT_SHUT;
+
/* If there are any excess server data in the input buffer,
* release it and close the connection ASAP (some data may
* remain in the output buffer). This happens if a server sends