Re: TCP mode and ultra short lived connection
Hi, Lukas! I didn’t attach dump of haproxy to backend servers packets because there were no such packets in this particular case. :( this haproxy installation is heavy loaded with traffic. So it could be the reason haproxy even didn’t start connecting to a backend in time. If I add some small delay to the client right after connection or after sending of data - everything works as expected. Clients differ, so TC could possibly be an only option. But maybe there is a better way. Вт, 9 февр. 2021 г. в 02:12, Lukas Tribus : > Hello, > > On Mon, 8 Feb 2021 at 18:14, Максим Куприянов > wrote: > > > > Hi! > > > > I faced a problem dealing with l4 (tcp mode) haproxy-based proxy over > Graphite's component receiving metrics from clients and clients who are > connecting just to send one or two Graphite-metrics and disconnecting right > after. > > > > It looks like this > > 1. Client connects to haproxy (SYN/SYN-ACK/ACK) > > 2. Client sends one line of metric > > 3. Haproxy acknowledges receiving this line (ACK to client) > > 4. Client disconnects (FIN, FIN-ACK) > > 5. Haproxy writes 1/-1/0/0 CC-termination state to log without even > trying to connect to a backend and send client's data to it. > > 6. Metric is lost :( > > > > If the client is slow enough between steps 1 and 2 or it sends a bunch > of metrics so haproxy has time to connect to a backend – everything works > like a charm. > > The issue though is the client disconnect. If we delay the client > disconnect, it could work. Try playing with tc by delaying the > incoming FIN packets for a few hundred milliseconds (make sure you > only apply this to this particular traffic, for example this > particular destination port). > > > Example. First column is a time delta in seconds between packets > > It would be useful to have both front and backend tcp connections in > the same output (and absolute time stamps - delta from the first > packet, not the previous). > > > You may also want to accelerate the server connect with options like: > > option tcp-smart-connect > > https://cbonte.github.io/haproxy-dconv/2.2/configuration.html#4-option%20tcp-smart-connect > > tfo (needs server support) > > https://cbonte.github.io/haproxy-dconv/2.2/configuration.html#tfo%20%28Server%20and%20default-server%20options%29 > > > > > How can I deal with these send-and-forget clients? > > In TCP mode, we need to propagate the close from one side to the > other, as we are not aware of the protocol. Not sure if it is possible > (or a good idea) to keep sending buffer contents to the backend server > when the client is already gone. "[no] option abortonclose" only > affects HTTP, according to the docs. > > Maybe Willy can confirm/deny this. > > > Lukas >
minconn, maxconn and fullconn (again, sigh!)
Dear Colleagues, The dynamic limit is probably one of the darker sides of Haproxy configuration. One of the best explanations I've found is https://www.mail-archive.com/haproxy@formilux.org/msg04782.html but still I'm missing some points. Consider the following configuration: frontend bar maxconn 1 default_backend foo backend foo server server1 server1: minconn 10 maxconn 100 weight 100 server server2 server2: minconn 10 maxconn 100 weight 100 This configuration will set the automatic implicit fullconn=1000 to the backend "foo", correct? "maxconn 100" is still a hard limit, correct? So, when there happen to be 500 connections to the backend "foo", 200 of them will be served by server1 and server2, what will happen to the other 300 connections? The same can be asked about the example from the Haproxy documentation with the explicit fullconn: backend dynamic fullconn 1 server srv1 dyn1:80 minconn 100 maxconn 1000 server srv2 dyn2:80 minconn 100 maxconn 1000 "maxconn 1000" is still a hard limit, correct? When 4000 connections come to this backend, srv1 and srv2 will serve 2000 of them (each reaching its hard limit at "maxconn=1000"), what will happen to the other 2000 ? -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/
Re: [PATCH v2 3/6] BUG/MEDIUM: server: re-align state file fields number
Hello Christopher,
On Mon, Feb 8, 2021 at 11:53 PM William Dauchy wrote:
> Since commit 3169471964fdc49963e63f68c1fd88686821a0c4 ("MINOR: Add
> server port field to server state file.") max_fields was not increased
> on version number 1. So this patch aims to fix it. This should be
> backported as far as v1.8, but the numbering should be adpated depending
> on the version: simply increase the field by 1.
this one is simply a mistake where I changed the subject line from
MEDIUM to MINOR. So ignore this one.
--
William
[PATCH v2 4/6] MEDIUM: server: add server-states version 2
Even if it is possibly too much work for the current usage, it makes
sure we don't break states file from v2.3 to v2.4; indeed, since v2.3,
we introduced two new fields, so we put them aside to guarantee we can
easily reload from a version 1.
The diff seems huge but there is no specific change apart from:
- introduce v2 where it is needed (parsing, update)
- move away from switch/case in update to be able to reuse code
- move srv lock to the whole function to make it easier
this patch confirm how painful it is to maintain this functionality.
Signed-off-by: William Dauchy
---
include/haproxy/server-t.h | 7 +-
src/server.c | 742 ++---
2 files changed, 367 insertions(+), 382 deletions(-)
diff --git a/include/haproxy/server-t.h b/include/haproxy/server-t.h
index af52b6a25..89d8ecc06 100644
--- a/include/haproxy/server-t.h
+++ b/include/haproxy/server-t.h
@@ -101,9 +101,9 @@ enum srv_initaddr {
} __attribute__((packed));
/* server-state-file version */
-#define SRV_STATE_FILE_VERSION 1
+#define SRV_STATE_FILE_VERSION 2
#define SRV_STATE_FILE_VERSION_MIN 1
-#define SRV_STATE_FILE_VERSION_MAX 1
+#define SRV_STATE_FILE_VERSION_MAX 2
#define SRV_STATE_FILE_FIELD_NAMES \
"be_id " \
"be_name "\
@@ -129,7 +129,8 @@ enum srv_initaddr {
"srv_check_port"
#define SRV_STATE_FILE_MAX_FIELDS 22
-#define SRV_STATE_FILE_NB_FIELDS_VERSION_1 22
+#define SRV_STATE_FILE_NB_FIELDS_VERSION_1 20
+#define SRV_STATE_FILE_NB_FIELDS_VERSION_2 22
#define SRV_STATE_LINE_MAXLEN 512
/* server flags -- 32 bits */
diff --git a/src/server.c b/src/server.c
index a865fb4dd..84b283567 100644
--- a/src/server.c
+++ b/src/server.c
@@ -2629,391 +2629,383 @@ static void srv_update_state(struct server *srv, int
version, char **params)
fqdn = NULL;
port_svc = port_check = 0;
msg = get_trash_chunk();
- switch (version) {
- case 1:
- /*
-* now we can proceed with server's state update:
-* srv_addr: params[0]
-* srv_op_state: params[1]
-* srv_admin_state: params[2]
-* srv_uweight: params[3]
-* srv_iweight: params[4]
-* srv_last_time_change: params[5]
-* srv_check_status: params[6]
-* srv_check_result: params[7]
-* srv_check_health: params[8]
-* srv_check_state: params[9]
-* srv_agent_state: params[10]
-* bk_f_forced_id: params[11]
-* srv_f_forced_id: params[12]
-* srv_fqdn: params[13]
-* srv_port: params[14]
-* srvrecord:params[15]
-* srv_use_ssl: params[16]
-* srv_check_port: params[17]
-*/
+ HA_SPIN_LOCK(SERVER_LOCK, >lock);
+
+ if (version >= 1) {
+ /* srv_addr: params[0]
+* srv_op_state: params[1]
+* srv_admin_state: params[2]
+* srv_uweight: params[3]
+* srv_iweight: params[4]
+* srv_last_time_change: params[5]
+* srv_check_status: params[6]
+* srv_check_result: params[7]
+* srv_check_health: params[8]
+* srv_check_state: params[9]
+* srv_agent_state: params[10]
+* bk_f_forced_id: params[11]
+* srv_f_forced_id: params[12]
+* srv_fqdn: params[13]
+* srv_port: params[14]
+* srvrecord:params[15]
+*/
- /* validating srv_op_state */
- p = NULL;
- errno = 0;
- srv_op_state = strtol(params[1], , 10);
- if ((p == params[1]) || errno == EINVAL || errno ==
ERANGE ||
- (srv_op_state != SRV_ST_STOPPED &&
-srv_op_state != SRV_ST_STARTING &&
-srv_op_state != SRV_ST_RUNNING &&
-srv_op_state != SRV_ST_STOPPING)) {
- chunk_appendf(msg, ", invalid srv_op_state
value '%s'", params[1]);
- }
+ /* validating srv_op_state */
+ p = NULL;
+ errno = 0;
+ srv_op_state = strtol(params[1], , 10);
+ if ((p == params[1]) || errno == EINVAL || errno == ERANGE ||
+
[PATCH v2 5/6] MEDIUM: server: support {check,agent}_addr, agent_port in server state
logical followup from cli commands addition, so that the state server
file stays compatible with the changes made at runtime; use previously
added helper to load server attributes.
also alloc a specific chunk to avoid mixing with other called functions
using it
Signed-off-by: William Dauchy
---
doc/management.txt| 5 ++-
include/haproxy/server-t.h| 9 ++--
.../checks/1be_40srv_odd_health_checks.vtc| 2 +-
.../checks/40be_2srv_odd_health_checks.vtc| 2 +-
reg-tests/checks/4be_1srv_health_checks.vtc | 6 +--
src/proxy.c | 41 +++
src/server.c | 40 +++---
7 files changed, 66 insertions(+), 39 deletions(-)
diff --git a/doc/management.txt b/doc/management.txt
index 423c614b2..60e25c7e1 100644
--- a/doc/management.txt
+++ b/doc/management.txt
@@ -2455,7 +2455,10 @@ show servers state []
srv_port:Server port.
srvrecord: DNS SRV record associated to this SRV.
srv_use_ssl: use ssl for server connections.
- srv_check_port: Server check port.
+ srv_check_port: Server health check port.
+ srv_check_addr: Server health check address.
+ srv_agent_addr: Server health agent address.
+ srv_agent_port: Server health agent port.
show sess
Dump all known sessions. Avoid doing this on slow connections as this can
diff --git a/include/haproxy/server-t.h b/include/haproxy/server-t.h
index 89d8ecc06..7f1356024 100644
--- a/include/haproxy/server-t.h
+++ b/include/haproxy/server-t.h
@@ -126,11 +126,14 @@ enum srv_initaddr {
"srv_port " \
"srvrecord " \
"srv_use_ssl "\
-"srv_check_port"
+"srv_check_port " \
+"srv_check_addr " \
+"srv_agent_addr " \
+"srv_agent_port"
-#define SRV_STATE_FILE_MAX_FIELDS 22
+#define SRV_STATE_FILE_MAX_FIELDS 25
#define SRV_STATE_FILE_NB_FIELDS_VERSION_1 20
-#define SRV_STATE_FILE_NB_FIELDS_VERSION_2 22
+#define SRV_STATE_FILE_NB_FIELDS_VERSION_2 25
#define SRV_STATE_LINE_MAXLEN 512
/* server flags -- 32 bits */
diff --git a/reg-tests/checks/1be_40srv_odd_health_checks.vtc
b/reg-tests/checks/1be_40srv_odd_health_checks.vtc
index f01205295..c279972aa 100644
--- a/reg-tests/checks/1be_40srv_odd_health_checks.vtc
+++ b/reg-tests/checks/1be_40srv_odd_health_checks.vtc
@@ -112,6 +112,6 @@ syslog S -wait
haproxy h1 -cli {
send "show servers state"
-expect ~ "# be_id be_name srv_id srv_name srv_addr srv_op_state
srv_admin_state srv_uweight srv_iweight srv_time_since_last_change
srv_check_status srv_check_result srv_check_health srv_check_state
srv_agent_state bk_f_forced_id srv_f_forced_id srv_fqdn srv_port srvrecord
srv_use_ssl srv_check_port\n2 be1 1 srv0 ${s0_addr} 2 0 1 1 [[:digit:]]+ 1 0 1
0 0 0 0 - ${s0_port} - 0 0\n2 be1 2 srv1 ${s1_addr} 2 0 1 1 [[:digit:]]+ 6
([[:digit:]]+ ){3}0 0 0 - ${s1_port} - 0 0\n2 be1 3 srv2 ${s2_addr} 2 0 1 1
[[:digit:]]+ 1 0 1 0 0 0 0 - ${s2_port} - 0 0\n2 be1 4 srv3 ${s3_addr} 2 0 1 1
[[:digit:]]+ 6 ([[:digit:]]+ ){3}0 0 0 - ${s3_port} - 0 0\n2 be1 5 srv4
${s4_addr} 2 0 1 1 [[:digit:]]+ 1 0 1 0 0 0 0 - ${s4_port} - 0 0\n2 be1 6 srv5
${s5_addr} 2 0 1 1 [[:digit:]]+ 6 ([[:digit:]]+ ){3}0 0 0 - ${s5_port} - 0 0\n2
be1 7 srv6 ${s6_addr} 2 0 1 1 [[:digit:]]+ 1 0 1 0 0 0 0 - ${s6_port} - 0 0\n2
be1 8 srv7 ${s7_addr} 2 0 1 1 [[:digit:]]+ 6 ([[:digit:]]+ ){3}0 0 0 -
${s7_port} - 0 0\n2 be1 9 srv8 ${s8_addr} 2 0 1 1 [[:digit:]]+ 1 0 1 0 0 0 0 -
${s8_port} - 0 0\n2 be1 10 srv9 ${s9_addr} 2 0 1 1 [[:digit:]]+ 6 ([[:digit:]]+
){3}0 0 0 - ${s9_port} - 0 0\n2 be1 11 srv10 ${s10_addr} 2 0 1 1 [[:digit:]]+ 1
0 1 0 0 0 0 - ${s10_port} - 0 0\n2 be1 12 srv11 ${s11_addr} 2 0 1 1
[[:digit:]]+ 6 ([[:digit:]]+ ){3}0 0 0 - ${s11_port} - 0 0\n2 be1 13 srv12
${s12_addr} 2 0 1 1 [[:digit:]]+ 1 0 1 0 0 0 0 - ${s12_port} - 0 0\n2 be1 14
srv13 ${s13_addr} 2 0 1 1 [[:digit:]]+ 6 ([[:digit:]]+ ){3}0 0 0 - ${s13_port}
- 0 0\n2 be1 15 srv14 ${s14_addr} 2 0 1 1 [[:digit:]]+ 1 0 1 0 0 0 0 -
${s14_port} - 0 0\n2 be1 16 srv15 ${s15_addr} 2 0 1 1 [[:digit:]]+ 6
([[:digit:]]+ ){3}0 0 0 - ${s15_port} - 0 0\n2 be1 17 srv16 ${s16_addr} 2 0 1 1
[[:digit:]]+ 1 0 1 0 0 0 0 - ${s16_port} - 0 0\n2 be1 18 srv17 ${s17_addr} 2 0
1 1 [[:digit:]]+ 6 ([[:digit:]]+ ){3}0 0 0 - ${s17_port} - 0 0\n2 be1 19 srv18
${s18_addr} 2 0 1 1 [[:digit:]]+ 1 0 1 0 0 0 0 - ${s18_port} - 0 0\n2 be1 20
srv19 ${s19_addr} 2 0 1 1 [[:digit:]]+ 6 ([[:digit:]]+ ){3}0 0 0 - ${s19_port}
- 0 0\n2 be1 21 srv20 ${s20_addr} 2 0 1 1 [[:digit:]]+ 1 0 1 0 0 0 0 -
${s20_port} - 0 0\n2 be1 22 srv21 ${s21_addr} 2 0 1 1 [[:digit:]]+ 6
([[:digit:]]+ ){3}0 0 0 - ${s21_port} - 0 0\n2 be1 23 srv22 ${s22_addr} 2 0 1 1
[[:digit:]]+ 1 0 1 0 0 0 0 - ${s22_port} - 0 0\n2 be1 24
[PATCH v2 6/6] CLEANUP: server: add missing space in server-state error output
a space was missing in the output to make it more readable.
Signed-off-by: William Dauchy
---
src/server.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/server.c b/src/server.c
index 6b360291d..673844dd7 100644
--- a/src/server.c
+++ b/src/server.c
@@ -3015,7 +3015,7 @@ static void srv_update_state(struct server *srv, int
version, char **params)
HA_SPIN_UNLOCK(SERVER_LOCK, >lock);
if (msg->data) {
chunk_appendf(msg, "\n");
- ha_warning("server-state application failed for server
'%s/%s'%s",
+ ha_warning("server-state application failed for server '%s/%s'
%s",
srv->proxy->id, srv->id, msg->area);
}
end:
--
2.30.0
[PATCH v2 3/6] BUG/MINOR: server: re-align state file fields number
Since commit 3169471964fdc49963e63f68c1fd88686821a0c4 ("MINOR: Add
server port field to server state file.") max_fields was not increased
on version number 1. So this patch aims to fix it. This should be
backported as far as v1.8, but the numbering should be adpated depending
on the version: simply increase the field by 1.
Signed-off-by: William Dauchy
---
include/haproxy/server-t.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/haproxy/server-t.h b/include/haproxy/server-t.h
index 32697a9c4..af52b6a25 100644
--- a/include/haproxy/server-t.h
+++ b/include/haproxy/server-t.h
@@ -129,7 +129,7 @@ enum srv_initaddr {
"srv_check_port"
#define SRV_STATE_FILE_MAX_FIELDS 22
-#define SRV_STATE_FILE_NB_FIELDS_VERSION_1 21
+#define SRV_STATE_FILE_NB_FIELDS_VERSION_1 22
#define SRV_STATE_LINE_MAXLEN 512
/* server flags -- 32 bits */
--
2.30.0
[PATCH v2 2/6] MEDIUM: cli: add agent-port command
this patch allows to set agent port at runtime. In order to align with
both `addr` and `check-addr` commands, also add the possibility to
optionnaly set port on `agent-addr` command. This led to a small
refactor in order to use the same function for both `agent-addr` and
`agent-port` commands.
Signed-off-by: William Dauchy
---
doc/management.txt | 6 +++-
src/server.c | 76 --
2 files changed, 72 insertions(+), 10 deletions(-)
diff --git a/doc/management.txt b/doc/management.txt
index bff770e4e..423c614b2 100644
--- a/doc/management.txt
+++ b/doc/management.txt
@@ -1828,10 +1828,14 @@ set server / agent [ up | down ]
switch a server's state regardless of some slow agent checks for example.
Note that the change is propagated to tracking servers if any.
-set server / agent-addr
+set server / agent-addr [port ]
Change addr for servers agent checks. Allows to migrate agent-checks to
another address at runtime. You can specify both IP and hostname, it will be
resolved.
+ Optionally, change the port agent.
+
+set server / agent-port
+ Change the port used for agent checks.
set server / agent-send
Change agent string sent to agent check target. Allows to update string while
diff --git a/src/server.c b/src/server.c
index 58347d215..a865fb4dd 100644
--- a/src/server.c
+++ b/src/server.c
@@ -56,6 +56,8 @@ static int srv_state_get_version(FILE *f);
static void srv_cleanup_connections(struct server *srv);
static const char *update_server_check_addr_port(struct server *s, const char
*addr,
const char *port);
+static const char *update_server_agent_addr_port(struct server *s, const char
*addr,
+const char *port);
/* List head of all known server keywords */
static struct srv_kw_list srv_keywords = {
@@ -3573,6 +3575,46 @@ int update_server_addr(struct server *s, void *ip, int
ip_sin_family, const char
return 0;
}
+/* update agent health check address and port
+ * addr can be ip4/ip6 or a hostname
+ * must be called with the server lock held.
+ */
+static const char *update_server_agent_addr_port(struct server *s, const char
*addr,
+const char *port)
+{
+ struct sockaddr_storage sk;
+ struct buffer *msg;
+ int new_port;
+
+ msg = get_trash_chunk();
+
+ if (!(s->agent.state & CHK_ST_ENABLED)) {
+ chunk_appendf(msg, "agent checks are not enabled on this
server.\n");
+ goto out;
+ }
+ if (addr) {
+ memset(, 0, sizeof(struct sockaddr_storage));
+ if (str2ip(addr, ) == NULL) {
+ chunk_appendf(msg, "invalid addr '%s'\n", addr);
+ goto out;
+ }
+ set_srv_agent_addr(s, );
+ }
+ if (port) {
+ if (strl2irc(port, strlen(port), _port) != 0) {
+ chunk_appendf(msg, "provided port is not an integer\n");
+ goto out;
+ }
+ if (new_port < 0 || new_port > 65535) {
+ chunk_appendf(msg, "provided port is invalid\n");
+ goto out;
+ }
+ set_srv_agent_port(s, new_port);
+ }
+out:
+ return msg->area;
+}
+
/* update server health check address and port
* addr must be ip4 or ip6, it won't be resolved
* must be called with the server lock held.
@@ -4432,15 +4474,31 @@ static int cli_parse_set_server(char **args, char
*payload, struct appctx *appct
cli_err(appctx, "'set server agent' expects 'up'
or 'down'.\n");
}
else if (strcmp(args[3], "agent-addr") == 0) {
- struct sockaddr_storage sk;
-
- memset(, 0, sizeof(sk));
- if (!(sv->agent.state & CHK_ST_ENABLED))
- cli_err(appctx, "agent checks are not enabled on this
server.\n");
- else if (str2ip(args[4], ))
- set_srv_agent_addr(sv, );
- else
- cli_err(appctx, "incorrect addr address given for
agent.\n");
+ char *addr = NULL;
+ char *port = NULL;
+ if (strlen(args[4]) == 0) {
+ cli_err(appctx, "set server / agent-addr requires"
+ " an address and optionally a port.\n");
+ goto out_unlock;
+ }
+ addr = args[4];
+ if (strcmp(args[5], "port") == 0)
+ port = args[6];
+ warning = update_server_agent_addr_port(sv, addr, port);
+ if (warning)
+ cli_msg(appctx, LOG_WARNING, warning);
+ }
+ else if (strcmp(args[3], "agent-port") == 0) {
+ char *port = NULL;
+ if
[PATCH v2 1/6] MEDIUM: cli: add check-addr command
this patch allows to set server health check address at runtime. In
order to align with `addr` command, also allow to set port optionnaly.
This led to a small refactor in order to use the same function for both
`check-addr` and `check-port` commands.
for `check-port`, we however don't permit the change anymore if checks
are not enabled on the server.
This command becomes more and more useful for people having a consul
like architecture:
- the backend server is located on a container with its own IP
- the health checks are done the consul instance located on the host
with the host IP
Signed-off-by: William Dauchy
---
doc/management.txt | 4 +++
src/server.c | 87 ++
2 files changed, 76 insertions(+), 15 deletions(-)
diff --git a/doc/management.txt b/doc/management.txt
index b74aba769..bff770e4e 100644
--- a/doc/management.txt
+++ b/doc/management.txt
@@ -1842,6 +1842,10 @@ set server / health [ up | stopping |
down ]
switch a server's state regardless of some slow health checks for example.
Note that the change is propagated to tracking servers if any.
+set server / check-addr [port ]
+ Change the IP address used for server health checks.
+ Optionally, change the port used for server health checks.
+
set server / check-port
Change the port used for health checking to
diff --git a/src/server.c b/src/server.c
index da2325e9a..58347d215 100644
--- a/src/server.c
+++ b/src/server.c
@@ -54,6 +54,8 @@ static int srv_set_fqdn(struct server *srv, const char *fqdn,
int dns_locked);
static void srv_state_parse_line(char *buf, const int version, char **params,
char **srv_params);
static int srv_state_get_version(FILE *f);
static void srv_cleanup_connections(struct server *srv);
+static const char *update_server_check_addr_port(struct server *s, const char
*addr,
+const char *port);
/* List head of all known server keywords */
static struct srv_kw_list srv_keywords = {
@@ -3571,6 +3573,51 @@ int update_server_addr(struct server *s, void *ip, int
ip_sin_family, const char
return 0;
}
+/* update server health check address and port
+ * addr must be ip4 or ip6, it won't be resolved
+ * must be called with the server lock held.
+ */
+static const char *update_server_check_addr_port(struct server *s, const char
*addr,
+const char *port)
+{
+ struct sockaddr_storage sk;
+ struct buffer *msg;
+ int new_port;
+
+ msg = get_trash_chunk();
+
+ if (!(s->check.state & CHK_ST_ENABLED)) {
+ chunk_appendf(msg, "health checks are not enabled on this
server.\n");
+ goto out;
+ }
+ if (addr) {
+ memset(, 0, sizeof(struct sockaddr_storage));
+ if (str2ip2(addr, , 0) == NULL) {
+ chunk_appendf(msg, "invalid addr '%s'\n", addr);
+ goto out;
+ }
+ s->check.addr = sk;
+ }
+ if (port) {
+ if (strl2irc(port, strlen(port), _port) != 0) {
+ chunk_appendf(msg, "provided port is not an integer\n");
+ goto out;
+ }
+ if (new_port < 0 || new_port > 65535) {
+ chunk_appendf(msg, "provided port is invalid\n");
+ goto out;
+ }
+ /* prevent the update of port to 0 if MAPPORTS are in use */
+ if ((s->flags & SRV_F_MAPPORTS) && new_port == 0) {
+ chunk_appendf(msg, "can't unset 'port' since MAPPORTS
is in use\n");
+ goto out;
+ }
+ s->check.port = new_port;
+ }
+out:
+ return msg->area;
+}
+
/*
* This function update a server's addr and port only for AF_INET and AF_INET6
families.
*
@@ -4403,23 +4450,32 @@ static int cli_parse_set_server(char **args, char
*payload, struct appctx *appct
cli_err(appctx, "cannot allocate memory for new
string.\n");
}
}
- else if (strcmp(args[3], "check-port") == 0) {
- int i = 0;
- if (strl2irc(args[4], strlen(args[4]), ) != 0) {
- cli_err(appctx, "'set server check-port' expects
an integer as argument.\n");
- goto out_unlock;
- }
- if ((i < 0) || (i > 65535)) {
- cli_err(appctx, "provided port is not valid.\n");
+ else if (strcmp(args[3], "check-addr") == 0) {
+ char *addr = NULL;
+ char *port = NULL;
+ if (strlen(args[4]) == 0) {
+ cli_err(appctx, "set server / check-addr requires"
+ " an address and optionally a port.\n");
goto out_unlock;
}
- /*
[PATCH v2 3/6] BUG/MEDIUM: server: re-align state file fields number
Since commit 3169471964fdc49963e63f68c1fd88686821a0c4 ("MINOR: Add
server port field to server state file.") max_fields was not increased
on version number 1. So this patch aims to fix it. This should be
backported as far as v1.8, but the numbering should be adpated depending
on the version: simply increase the field by 1.
Signed-off-by: William Dauchy
---
include/haproxy/server-t.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/haproxy/server-t.h b/include/haproxy/server-t.h
index 32697a9c4..af52b6a25 100644
--- a/include/haproxy/server-t.h
+++ b/include/haproxy/server-t.h
@@ -129,7 +129,7 @@ enum srv_initaddr {
"srv_check_port"
#define SRV_STATE_FILE_MAX_FIELDS 22
-#define SRV_STATE_FILE_NB_FIELDS_VERSION_1 21
+#define SRV_STATE_FILE_NB_FIELDS_VERSION_1 22
#define SRV_STATE_LINE_MAXLEN 512
/* server flags -- 32 bits */
--
2.30.0
[PATCH v2 0/6] cli commands for checks and agent
Hello Christopher,
Here is the v2 addressing the points raised yesterday.
The patch 4/6 clearly looks scary but I made sure to not change anything
crazy apart from adding support for a version 2. I will probably start
to dream about a server-state-file burning every night.
I hope this will be good enough, but otherwise, don't hesitate to put
more comments, I will come back with a v3.
William Dauchy (6):
MEDIUM: cli: add check-addr command
MEDIUM: cli: add agent-port command
BUG/MEDIUM: server: re-align state file fields number
MEDIUM: server: add server-states version 2
MEDIUM: server: support {check,agent}_addr, agent_port in server state
CLEANUP: server: add missing space in server-state error output
doc/management.txt| 15 +-
include/haproxy/server-t.h| 16 +-
.../checks/1be_40srv_odd_health_checks.vtc| 2 +-
.../checks/40be_2srv_odd_health_checks.vtc| 2 +-
reg-tests/checks/4be_1srv_health_checks.vtc | 6 +-
src/proxy.c | 41 +-
src/server.c | 929 ++
7 files changed, 573 insertions(+), 438 deletions(-)
--
2.30.0
Re: TCP mode and ultra short lived connection
Hello, On Mon, 8 Feb 2021 at 18:14, Максим Куприянов wrote: > > Hi! > > I faced a problem dealing with l4 (tcp mode) haproxy-based proxy over > Graphite's component receiving metrics from clients and clients who are > connecting just to send one or two Graphite-metrics and disconnecting right > after. > > It looks like this > 1. Client connects to haproxy (SYN/SYN-ACK/ACK) > 2. Client sends one line of metric > 3. Haproxy acknowledges receiving this line (ACK to client) > 4. Client disconnects (FIN, FIN-ACK) > 5. Haproxy writes 1/-1/0/0 CC-termination state to log without even trying to > connect to a backend and send client's data to it. > 6. Metric is lost :( > > If the client is slow enough between steps 1 and 2 or it sends a bunch of > metrics so haproxy has time to connect to a backend – everything works like a > charm. The issue though is the client disconnect. If we delay the client disconnect, it could work. Try playing with tc by delaying the incoming FIN packets for a few hundred milliseconds (make sure you only apply this to this particular traffic, for example this particular destination port). > Example. First column is a time delta in seconds between packets It would be useful to have both front and backend tcp connections in the same output (and absolute time stamps - delta from the first packet, not the previous). You may also want to accelerate the server connect with options like: option tcp-smart-connect https://cbonte.github.io/haproxy-dconv/2.2/configuration.html#4-option%20tcp-smart-connect tfo (needs server support) https://cbonte.github.io/haproxy-dconv/2.2/configuration.html#tfo%20%28Server%20and%20default-server%20options%29 > How can I deal with these send-and-forget clients? In TCP mode, we need to propagate the close from one side to the other, as we are not aware of the protocol. Not sure if it is possible (or a good idea) to keep sending buffer contents to the backend server when the client is already gone. "[no] option abortonclose" only affects HTTP, according to the docs. Maybe Willy can confirm/deny this. Lukas
Re: TCP mode and ultra short lived connection
I have to go to sleep :)
for unknown reason I thought that you are out ot ephemeral ports due to
rapid connection reopen (aka ephemeral ports exhaustion).
вт, 9 февр. 2021 г. в 01:04, Максим Куприянов :
> Илья, thanks for your answer!
>
> Sorry, but It seems to me I didn't make it clear: the problem is the data
> received from these fast clients never reaches backends. But it should be
> delivered in order to be saved.
>
> Maybe there is some way to delay acknowledging of the data received until
> some backend is selected and connected to session?
>
>
> пн, 8 февр. 2021 г. в 22:56, Илья Шипицин :
>
>> I think it is "4. Client disconnects (FIN, FIN-ACK)"
>> if client would send RST instead of FIN, port would have been released
>> immediately.
>>
>>
>> https://stackoverflow.com/questions/13049828/fin-vs-rst-in-tcp-connections
>>
>> RST is much better for short living connections.
>>
>> пн, 8 февр. 2021 г. в 22:17, Максим Куприянов > >:
>>
>>> Hi!
>>>
>>> I faced a problem dealing with l4 (tcp mode) haproxy-based proxy over
>>> Graphite's component receiving metrics from clients and clients who are
>>> connecting just to send one or two Graphite-metrics and disconnecting right
>>> after.
>>>
>>> It looks like this
>>> 1. Client connects to haproxy (SYN/SYN-ACK/ACK)
>>> 2. Client sends one line of metric
>>> 3. Haproxy acknowledges receiving this line (ACK to client)
>>> 4. Client disconnects (FIN, FIN-ACK)
>>> 5. Haproxy writes 1/-1/0/0 CC-termination state to log without even
>>> trying to connect to a backend and send client's data to it.
>>> 6. Metric is lost :(
>>>
>>> If the client is slow enough between steps 1 and 2 or it sends a bunch
>>> of metrics so haproxy has time to connect to a backend – everything works
>>> like a charm.
>>>
>>> How can I deal with these send-and-forget clients?
>>>
>>> Example. First column is a time delta in seconds between packets
>>> 0.00 client haproxy TCP 100 58664 → 2024 [SYN] Seq=0 Win=65535
>>> Len=0 MSS=1220 WS=64 TSval=904701415 TSecr=0 SACK_PERM=1
>>> 0.15 haproxy client TCP 96 2024 → 58664 [SYN, ACK] Seq=0 Ack=1
>>> Win=65535 Len=0 MSS=8840 SACK_PERM=1 TSval=276942420 TSecr=904701415 WS=2048
>>> 0.019105 client haproxy TCP 88 58664 → 2024 [ACK] Seq=1 Ack=1
>>> Win=131264 Len=0 TSval=904701434 TSecr=276942420
>>> 0.90 client haproxy TCP 151 58664 → 2024 [PSH, ACK] Seq=1 Ack=1
>>> Win=131264 Len=63 TSval=904701434 TSecr=276942420
>>> 0.12 haproxy client TCP 88 2024 → 58664 [ACK] Seq=1 Ack=64
>>> Win=65536 Len=0 TSval=276942439 TSecr=904701434
>>> 0.000150 client haproxy TCP 88 58664 → 2024 [FIN, ACK] Seq=64 Ack=1
>>> Win=131264 Len=0 TSval=904701434 TSecr=276942420
>>> 0.58 haproxy client TCP 88 2024 → 58664 [FIN, ACK] Seq=1 Ack=65
>>> Win=65536 Len=0 TSval=276942439 TSecr=904701434
>>>
>>> haproxy -vv
>>> HA-Proxy version 2.2.8-1 2021/01/28 - https://haproxy.org/
>>> Status: long-term supported branch - will stop receiving fixes around Q2
>>> 2025.
>>> Known bugs: http://www.haproxy.org/bugs/bugs-2.2.8.html
>>> Running on: Linux 4.19.91-22 #1 SMP Wed Dec 25 14:25:55 UTC 2019 x86_64
>>> Build options :
>>> TARGET = linux-glibc
>>> CPU = generic
>>> CC = gcc
>>> CFLAGS = -O2 -g -O2 -fPIE -fstack-protector-strong -Wformat
>>> -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wextra
>>> -Wdeclaration-after-statement -fwrapv -Wno-unused-label -Wno-sign-compare
>>> -Wno-unused-parameter -Wno-clobbered -Wno-missing-field-initializers
>>> -Wtype-limits
>>> OPTIONS = USE_PCRE2=1 USE_PCRE2_JIT=1 USE_GETADDRINFO=1 USE_OPENSSL=1
>>> USE_LUA=1 USE_ZLIB=1 USE_TFO=1 USE_SYSTEMD=1
>>> DEBUG =
>>>
>>> Feature list : +EPOLL -KQUEUE +NETFILTER -PCRE -PCRE_JIT +PCRE2
>>> +PCRE2_JIT +POLL -PRIVATE_CACHE +THREAD -PTHREAD_PSHARED +BACKTRACE
>>> -STATIC_PCRE -STATIC_PCRE2 +TPROXY +LINUX_TPROXY +LINUX_SPLICE +LIBCRYPT
>>> +CRYPT_H +GETADDRINFO +OPENSSL +LUA +FUTEX +ACCEPT4 -CLOSEFROM +ZLIB -SLZ
>>> +CPU_AFFINITY +TFO +NS +DL +RT -DEVICEATLAS -51DEGREES -WURFL +SYSTEMD
>>> -OBSOLETE_LINKER +PRCTL +THREAD_DUMP -EVPORTS
>>>
>>> Default settings :
>>> bufsize = 16384, maxrewrite = 1024, maxpollevents = 200
>>>
>>> Built with multi-threading support (MAX_THREADS=64, default=32).
>>> Built with OpenSSL version : OpenSSL 1.0.2g 1 Mar 2016
>>> Running on OpenSSL version : OpenSSL 1.0.2g 1 Mar 2016
>>> OpenSSL library supports TLS extensions : yes
>>> OpenSSL library supports SNI : yes
>>> OpenSSL library supports : TLSv1.0 TLSv1.1 TLSv1.2
>>> Built with Lua version : Lua 5.3.1
>>> Built with network namespace support.
>>> Built with zlib version : 1.2.8
>>> Running on zlib version : 1.2.8
>>> Compression algorithms supported : identity("identity"),
>>> deflate("deflate"), raw-deflate("deflate"), gzip("gzip")
>>> Built with transparent proxy support using: IP_TRANSPARENT
>>> IPV6_TRANSPARENT IP_FREEBIND
>>> Built with PCRE2 version : 10.21 2016-01-12
>>> PCRE2 library supports JIT : yes
>>> Encrypted password support via crypt(3):
Re: TCP mode and ultra short lived connection
Илья, thanks for your answer!
Sorry, but It seems to me I didn't make it clear: the problem is the data
received from these fast clients never reaches backends. But it should be
delivered in order to be saved.
Maybe there is some way to delay acknowledging of the data received until
some backend is selected and connected to session?
пн, 8 февр. 2021 г. в 22:56, Илья Шипицин :
> I think it is "4. Client disconnects (FIN, FIN-ACK)"
> if client would send RST instead of FIN, port would have been released
> immediately.
>
>
> https://stackoverflow.com/questions/13049828/fin-vs-rst-in-tcp-connections
>
> RST is much better for short living connections.
>
> пн, 8 февр. 2021 г. в 22:17, Максим Куприянов >:
>
>> Hi!
>>
>> I faced a problem dealing with l4 (tcp mode) haproxy-based proxy over
>> Graphite's component receiving metrics from clients and clients who are
>> connecting just to send one or two Graphite-metrics and disconnecting right
>> after.
>>
>> It looks like this
>> 1. Client connects to haproxy (SYN/SYN-ACK/ACK)
>> 2. Client sends one line of metric
>> 3. Haproxy acknowledges receiving this line (ACK to client)
>> 4. Client disconnects (FIN, FIN-ACK)
>> 5. Haproxy writes 1/-1/0/0 CC-termination state to log without even
>> trying to connect to a backend and send client's data to it.
>> 6. Metric is lost :(
>>
>> If the client is slow enough between steps 1 and 2 or it sends a bunch of
>> metrics so haproxy has time to connect to a backend – everything works like
>> a charm.
>>
>> How can I deal with these send-and-forget clients?
>>
>> Example. First column is a time delta in seconds between packets
>> 0.00 client haproxy TCP 100 58664 → 2024 [SYN] Seq=0 Win=65535 Len=0
>> MSS=1220 WS=64 TSval=904701415 TSecr=0 SACK_PERM=1
>> 0.15 haproxy client TCP 96 2024 → 58664 [SYN, ACK] Seq=0 Ack=1
>> Win=65535 Len=0 MSS=8840 SACK_PERM=1 TSval=276942420 TSecr=904701415 WS=2048
>> 0.019105 client haproxy TCP 88 58664 → 2024 [ACK] Seq=1 Ack=1 Win=131264
>> Len=0 TSval=904701434 TSecr=276942420
>> 0.90 client haproxy TCP 151 58664 → 2024 [PSH, ACK] Seq=1 Ack=1
>> Win=131264 Len=63 TSval=904701434 TSecr=276942420
>> 0.12 haproxy client TCP 88 2024 → 58664 [ACK] Seq=1 Ack=64 Win=65536
>> Len=0 TSval=276942439 TSecr=904701434
>> 0.000150 client haproxy TCP 88 58664 → 2024 [FIN, ACK] Seq=64 Ack=1
>> Win=131264 Len=0 TSval=904701434 TSecr=276942420
>> 0.58 haproxy client TCP 88 2024 → 58664 [FIN, ACK] Seq=1 Ack=65
>> Win=65536 Len=0 TSval=276942439 TSecr=904701434
>>
>> haproxy -vv
>> HA-Proxy version 2.2.8-1 2021/01/28 - https://haproxy.org/
>> Status: long-term supported branch - will stop receiving fixes around Q2
>> 2025.
>> Known bugs: http://www.haproxy.org/bugs/bugs-2.2.8.html
>> Running on: Linux 4.19.91-22 #1 SMP Wed Dec 25 14:25:55 UTC 2019 x86_64
>> Build options :
>> TARGET = linux-glibc
>> CPU = generic
>> CC = gcc
>> CFLAGS = -O2 -g -O2 -fPIE -fstack-protector-strong -Wformat
>> -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wextra
>> -Wdeclaration-after-statement -fwrapv -Wno-unused-label -Wno-sign-compare
>> -Wno-unused-parameter -Wno-clobbered -Wno-missing-field-initializers
>> -Wtype-limits
>> OPTIONS = USE_PCRE2=1 USE_PCRE2_JIT=1 USE_GETADDRINFO=1 USE_OPENSSL=1
>> USE_LUA=1 USE_ZLIB=1 USE_TFO=1 USE_SYSTEMD=1
>> DEBUG =
>>
>> Feature list : +EPOLL -KQUEUE +NETFILTER -PCRE -PCRE_JIT +PCRE2
>> +PCRE2_JIT +POLL -PRIVATE_CACHE +THREAD -PTHREAD_PSHARED +BACKTRACE
>> -STATIC_PCRE -STATIC_PCRE2 +TPROXY +LINUX_TPROXY +LINUX_SPLICE +LIBCRYPT
>> +CRYPT_H +GETADDRINFO +OPENSSL +LUA +FUTEX +ACCEPT4 -CLOSEFROM +ZLIB -SLZ
>> +CPU_AFFINITY +TFO +NS +DL +RT -DEVICEATLAS -51DEGREES -WURFL +SYSTEMD
>> -OBSOLETE_LINKER +PRCTL +THREAD_DUMP -EVPORTS
>>
>> Default settings :
>> bufsize = 16384, maxrewrite = 1024, maxpollevents = 200
>>
>> Built with multi-threading support (MAX_THREADS=64, default=32).
>> Built with OpenSSL version : OpenSSL 1.0.2g 1 Mar 2016
>> Running on OpenSSL version : OpenSSL 1.0.2g 1 Mar 2016
>> OpenSSL library supports TLS extensions : yes
>> OpenSSL library supports SNI : yes
>> OpenSSL library supports : TLSv1.0 TLSv1.1 TLSv1.2
>> Built with Lua version : Lua 5.3.1
>> Built with network namespace support.
>> Built with zlib version : 1.2.8
>> Running on zlib version : 1.2.8
>> Compression algorithms supported : identity("identity"),
>> deflate("deflate"), raw-deflate("deflate"), gzip("gzip")
>> Built with transparent proxy support using: IP_TRANSPARENT
>> IPV6_TRANSPARENT IP_FREEBIND
>> Built with PCRE2 version : 10.21 2016-01-12
>> PCRE2 library supports JIT : yes
>> Encrypted password support via crypt(3): yes
>> Built with gcc compiler version 5.4.0 20160609
>> Built with the Prometheus exporter as a service
>>
>> Available polling systems :
>> epoll : pref=300, test result OK
>>poll : pref=200, test result OK
>> select : pref=150, test result OK
>> Total: 3 (3 usable), will use epoll.
>>
>> Available
Re: TCP mode and ultra short lived connection
I think it is "4. Client disconnects (FIN, FIN-ACK)"
if client would send RST instead of FIN, port would have been released
immediately.
https://stackoverflow.com/questions/13049828/fin-vs-rst-in-tcp-connections
RST is much better for short living connections.
пн, 8 февр. 2021 г. в 22:17, Максим Куприянов :
> Hi!
>
> I faced a problem dealing with l4 (tcp mode) haproxy-based proxy over
> Graphite's component receiving metrics from clients and clients who are
> connecting just to send one or two Graphite-metrics and disconnecting right
> after.
>
> It looks like this
> 1. Client connects to haproxy (SYN/SYN-ACK/ACK)
> 2. Client sends one line of metric
> 3. Haproxy acknowledges receiving this line (ACK to client)
> 4. Client disconnects (FIN, FIN-ACK)
> 5. Haproxy writes 1/-1/0/0 CC-termination state to log without even trying
> to connect to a backend and send client's data to it.
> 6. Metric is lost :(
>
> If the client is slow enough between steps 1 and 2 or it sends a bunch of
> metrics so haproxy has time to connect to a backend – everything works like
> a charm.
>
> How can I deal with these send-and-forget clients?
>
> Example. First column is a time delta in seconds between packets
> 0.00 client haproxy TCP 100 58664 → 2024 [SYN] Seq=0 Win=65535 Len=0
> MSS=1220 WS=64 TSval=904701415 TSecr=0 SACK_PERM=1
> 0.15 haproxy client TCP 96 2024 → 58664 [SYN, ACK] Seq=0 Ack=1
> Win=65535 Len=0 MSS=8840 SACK_PERM=1 TSval=276942420 TSecr=904701415 WS=2048
> 0.019105 client haproxy TCP 88 58664 → 2024 [ACK] Seq=1 Ack=1 Win=131264
> Len=0 TSval=904701434 TSecr=276942420
> 0.90 client haproxy TCP 151 58664 → 2024 [PSH, ACK] Seq=1 Ack=1
> Win=131264 Len=63 TSval=904701434 TSecr=276942420
> 0.12 haproxy client TCP 88 2024 → 58664 [ACK] Seq=1 Ack=64 Win=65536
> Len=0 TSval=276942439 TSecr=904701434
> 0.000150 client haproxy TCP 88 58664 → 2024 [FIN, ACK] Seq=64 Ack=1
> Win=131264 Len=0 TSval=904701434 TSecr=276942420
> 0.58 haproxy client TCP 88 2024 → 58664 [FIN, ACK] Seq=1 Ack=65
> Win=65536 Len=0 TSval=276942439 TSecr=904701434
>
> haproxy -vv
> HA-Proxy version 2.2.8-1 2021/01/28 - https://haproxy.org/
> Status: long-term supported branch - will stop receiving fixes around Q2
> 2025.
> Known bugs: http://www.haproxy.org/bugs/bugs-2.2.8.html
> Running on: Linux 4.19.91-22 #1 SMP Wed Dec 25 14:25:55 UTC 2019 x86_64
> Build options :
> TARGET = linux-glibc
> CPU = generic
> CC = gcc
> CFLAGS = -O2 -g -O2 -fPIE -fstack-protector-strong -Wformat
> -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wextra
> -Wdeclaration-after-statement -fwrapv -Wno-unused-label -Wno-sign-compare
> -Wno-unused-parameter -Wno-clobbered -Wno-missing-field-initializers
> -Wtype-limits
> OPTIONS = USE_PCRE2=1 USE_PCRE2_JIT=1 USE_GETADDRINFO=1 USE_OPENSSL=1
> USE_LUA=1 USE_ZLIB=1 USE_TFO=1 USE_SYSTEMD=1
> DEBUG =
>
> Feature list : +EPOLL -KQUEUE +NETFILTER -PCRE -PCRE_JIT +PCRE2 +PCRE2_JIT
> +POLL -PRIVATE_CACHE +THREAD -PTHREAD_PSHARED +BACKTRACE -STATIC_PCRE
> -STATIC_PCRE2 +TPROXY +LINUX_TPROXY +LINUX_SPLICE +LIBCRYPT +CRYPT_H
> +GETADDRINFO +OPENSSL +LUA +FUTEX +ACCEPT4 -CLOSEFROM +ZLIB -SLZ
> +CPU_AFFINITY +TFO +NS +DL +RT -DEVICEATLAS -51DEGREES -WURFL +SYSTEMD
> -OBSOLETE_LINKER +PRCTL +THREAD_DUMP -EVPORTS
>
> Default settings :
> bufsize = 16384, maxrewrite = 1024, maxpollevents = 200
>
> Built with multi-threading support (MAX_THREADS=64, default=32).
> Built with OpenSSL version : OpenSSL 1.0.2g 1 Mar 2016
> Running on OpenSSL version : OpenSSL 1.0.2g 1 Mar 2016
> OpenSSL library supports TLS extensions : yes
> OpenSSL library supports SNI : yes
> OpenSSL library supports : TLSv1.0 TLSv1.1 TLSv1.2
> Built with Lua version : Lua 5.3.1
> Built with network namespace support.
> Built with zlib version : 1.2.8
> Running on zlib version : 1.2.8
> Compression algorithms supported : identity("identity"),
> deflate("deflate"), raw-deflate("deflate"), gzip("gzip")
> Built with transparent proxy support using: IP_TRANSPARENT
> IPV6_TRANSPARENT IP_FREEBIND
> Built with PCRE2 version : 10.21 2016-01-12
> PCRE2 library supports JIT : yes
> Encrypted password support via crypt(3): yes
> Built with gcc compiler version 5.4.0 20160609
> Built with the Prometheus exporter as a service
>
> Available polling systems :
> epoll : pref=300, test result OK
>poll : pref=200, test result OK
> select : pref=150, test result OK
> Total: 3 (3 usable), will use epoll.
>
> Available multiplexer protocols :
> (protocols marked as cannot be specified using 'proto' keyword)
> fcgi : mode=HTTP side=BEmux=FCGI
> : mode=HTTP side=FE|BE mux=H1
> h2 : mode=HTTP side=FE|BE mux=H2
> : mode=TCPside=FE|BE mux=PASS
>
> Available services : prometheus-exporter
> Available filters :
> [SPOE] spoe
> [COMP] compression
> [TRACE] trace
> [CACHE] cache
> [FCGI] fcgi-app
>
> --
> Best regards,
> Maksim
TCP mode and ultra short lived connection
Hi!
I faced a problem dealing with l4 (tcp mode) haproxy-based proxy over
Graphite's component receiving metrics from clients and clients who are
connecting just to send one or two Graphite-metrics and disconnecting right
after.
It looks like this
1. Client connects to haproxy (SYN/SYN-ACK/ACK)
2. Client sends one line of metric
3. Haproxy acknowledges receiving this line (ACK to client)
4. Client disconnects (FIN, FIN-ACK)
5. Haproxy writes 1/-1/0/0 CC-termination state to log without even trying
to connect to a backend and send client's data to it.
6. Metric is lost :(
If the client is slow enough between steps 1 and 2 or it sends a bunch of
metrics so haproxy has time to connect to a backend – everything works like
a charm.
How can I deal with these send-and-forget clients?
Example. First column is a time delta in seconds between packets
0.00 client haproxy TCP 100 58664 → 2024 [SYN] Seq=0 Win=65535 Len=0
MSS=1220 WS=64 TSval=904701415 TSecr=0 SACK_PERM=1
0.15 haproxy client TCP 96 2024 → 58664 [SYN, ACK] Seq=0 Ack=1
Win=65535 Len=0 MSS=8840 SACK_PERM=1 TSval=276942420 TSecr=904701415 WS=2048
0.019105 client haproxy TCP 88 58664 → 2024 [ACK] Seq=1 Ack=1 Win=131264
Len=0 TSval=904701434 TSecr=276942420
0.90 client haproxy TCP 151 58664 → 2024 [PSH, ACK] Seq=1 Ack=1
Win=131264 Len=63 TSval=904701434 TSecr=276942420
0.12 haproxy client TCP 88 2024 → 58664 [ACK] Seq=1 Ack=64 Win=65536
Len=0 TSval=276942439 TSecr=904701434
0.000150 client haproxy TCP 88 58664 → 2024 [FIN, ACK] Seq=64 Ack=1
Win=131264 Len=0 TSval=904701434 TSecr=276942420
0.58 haproxy client TCP 88 2024 → 58664 [FIN, ACK] Seq=1 Ack=65
Win=65536 Len=0 TSval=276942439 TSecr=904701434
haproxy -vv
HA-Proxy version 2.2.8-1 2021/01/28 - https://haproxy.org/
Status: long-term supported branch - will stop receiving fixes around Q2
2025.
Known bugs: http://www.haproxy.org/bugs/bugs-2.2.8.html
Running on: Linux 4.19.91-22 #1 SMP Wed Dec 25 14:25:55 UTC 2019 x86_64
Build options :
TARGET = linux-glibc
CPU = generic
CC = gcc
CFLAGS = -O2 -g -O2 -fPIE -fstack-protector-strong -Wformat
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wextra
-Wdeclaration-after-statement -fwrapv -Wno-unused-label -Wno-sign-compare
-Wno-unused-parameter -Wno-clobbered -Wno-missing-field-initializers
-Wtype-limits
OPTIONS = USE_PCRE2=1 USE_PCRE2_JIT=1 USE_GETADDRINFO=1 USE_OPENSSL=1
USE_LUA=1 USE_ZLIB=1 USE_TFO=1 USE_SYSTEMD=1
DEBUG =
Feature list : +EPOLL -KQUEUE +NETFILTER -PCRE -PCRE_JIT +PCRE2 +PCRE2_JIT
+POLL -PRIVATE_CACHE +THREAD -PTHREAD_PSHARED +BACKTRACE -STATIC_PCRE
-STATIC_PCRE2 +TPROXY +LINUX_TPROXY +LINUX_SPLICE +LIBCRYPT +CRYPT_H
+GETADDRINFO +OPENSSL +LUA +FUTEX +ACCEPT4 -CLOSEFROM +ZLIB -SLZ
+CPU_AFFINITY +TFO +NS +DL +RT -DEVICEATLAS -51DEGREES -WURFL +SYSTEMD
-OBSOLETE_LINKER +PRCTL +THREAD_DUMP -EVPORTS
Default settings :
bufsize = 16384, maxrewrite = 1024, maxpollevents = 200
Built with multi-threading support (MAX_THREADS=64, default=32).
Built with OpenSSL version : OpenSSL 1.0.2g 1 Mar 2016
Running on OpenSSL version : OpenSSL 1.0.2g 1 Mar 2016
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports : TLSv1.0 TLSv1.1 TLSv1.2
Built with Lua version : Lua 5.3.1
Built with network namespace support.
Built with zlib version : 1.2.8
Running on zlib version : 1.2.8
Compression algorithms supported : identity("identity"),
deflate("deflate"), raw-deflate("deflate"), gzip("gzip")
Built with transparent proxy support using: IP_TRANSPARENT IPV6_TRANSPARENT
IP_FREEBIND
Built with PCRE2 version : 10.21 2016-01-12
PCRE2 library supports JIT : yes
Encrypted password support via crypt(3): yes
Built with gcc compiler version 5.4.0 20160609
Built with the Prometheus exporter as a service
Available polling systems :
epoll : pref=300, test result OK
poll : pref=200, test result OK
select : pref=150, test result OK
Total: 3 (3 usable), will use epoll.
Available multiplexer protocols :
(protocols marked as cannot be specified using 'proto' keyword)
fcgi : mode=HTTP side=BEmux=FCGI
: mode=HTTP side=FE|BE mux=H1
h2 : mode=HTTP side=FE|BE mux=H2
: mode=TCPside=FE|BE mux=PASS
Available services : prometheus-exporter
Available filters :
[SPOE] spoe
[COMP] compression
[TRACE] trace
[CACHE] cache
[FCGI] fcgi-app
--
Best regards,
Maksim Kupriianov
Did my last email go through? (Monday)
Hi there, I don't think I've heard back from you yet - should I send those article ideas your way? Have a great start to the week! Best, David
RE: Should server crt be consider as crt-list and handled via the runtime API?
Hi William! On Mon, Feb 08 2021 15:49:02 +0100, William Lallemand wrote: > Thanks to Rémi development we already have the server crt update > available from the CLI in the 2.4 tree. Wow, this prove that I didn't follow that much what's currently happening... Awesome, thanks! > I'm not sure why you want this in the crt-list though, I think you meant > "show ssl cert"? The crt-list are only useful to manage multiple > certificates and SNIs on a bind line, in the case of a server line you > only need one certicate. Yes, that's most probably a misunderstanding on my side. As long as I get access to the " ssl cert" API in the end, that's perfectly OK. -- Pierre
Re: Should server crt be consider as crt-list and handled via the runtime API?
On Mon, Feb 08, 2021 at 02:31:18PM +, Pierre Cheynier wrote: > I'm trying to figure out what would be missing to consider server crt-s as > crt-lists (as in bind lines) so that they could be listed via "show ssl > crt-list" APIs and also managed (essentially renewed) this way. > > Exemple: > backend foo-using-client-auth > default-server check ssl crt /path/to/crt-list ca-file /path/to/my/ca.pem > server srv0 192.0.2.1:80 > > I'd like then to manage this using: > set ssl cert > > The use-case being the following: when integrating with service mesh > solutions such as consul-connect, you may want to reduce the disruption > occurring when certificates are renewed. > And in such kind of solution, they are renewed quite often (once every few > tens of hours). > In this case the memory space is already allocated etc. so I (naively?) think > it probably doesn't hurt too much. > > What is your point-of-view? > Hello Pierre, Thanks to Rémi development we already have the server crt update available from the CLI in the 2.4 tree. I'm not sure why you want this in the crt-list though, I think you meant "show ssl cert"? The crt-list are only useful to manage multiple certificates and SNIs on a bind line, in the case of a server line you only need one certicate. -- William Lallemand
Re: Issues with d13afbcce5e664f9cfe797eee8c527e5fa947f1b (haproxy-2.2) "mux-h1: Don't set CS_FL_EOI too early for protocol upgrade requests"
Le 08/02/2021 à 15:03, Christian Ruppert a écrit : On 2021-02-08 14:46, Christopher Faulet wrote: Le 08/02/2021 à 14:31, Christian Ruppert a écrit : Hi list, Christopher, we're having issues with the mentioned commit / patch: d13afbcce5e664f9cfe797eee8c527e5fa947f1b https://git.haproxy.org/?p=haproxy-2.2.git;a=commit;h=d13afbcce5e664f9cfe797eee8c527e5fa947f1b I can also reproduce it with 2.2.9 as well as 2.3.5. I don't have any useful details yet, just the our Jira fails to load. A curl against the site seams to work fine while browser requests (chrome / firefox) seem to timeout or at least some. See the attached log. The first 3 requests seem to be fine so far. Then, much later, there's a 504 between more 200s. I'm not sure yet why the other 200s there seem to wait / are logged after the actual timeout happens. According to chrome's F12 there are more requests still pending. Ignore the 503 there. That seems to be an unrelated problem, since this also happends with a working HAProxy. Much later, the site loaded, sometimes broken though. I'll try to prepare a config snipped if required. Is there anything know already? Thanks Christian, I'll take a look. Could you confirm or inform it happens only with requests with a "Connection: upgrade" header ? This frontend doesn't have H2 enabled explicit. I'm not really sure but it looks like some of those delayed requests don't have the upgrade header. It is not related to the H2. The mentioned commit is about HTTP/1.1 protocol upgrades, like WebsScket. But if some requests are delayed without any "connection: upgrade" header, it is a bit strange. If it is easily reproducible, it may be useful to enable the H1 mux traces. To enable it, just use the following commands on the CLI socket : echo "trace h1 sink buf0; trace h1 level developer; trace h1 verbosity complete; trace h1 start now" | socat - /path/to/cli-socket This will capture detailed info on the H1 mux internals. Then you can later check for captured events using "show events buf0". If you want to collect them as they are logged, and archive them, you can use the following command : (echo "show events buf0 -w -n" ; cat ) | socat - /path/to/cli-socket > file.log If you do so, please send me privately the generated log file. In the mean time, the config may help. Thanks, -- Christopher Faulet
Should server crt be consider as crt-list and handled via the runtime API?
I'm trying to figure out what would be missing to consider server crt-s as crt-lists (as in bind lines) so that they could be listed via "show ssl crt-list" APIs and also managed (essentially renewed) this way. Exemple: backend foo-using-client-auth default-server check ssl crt /path/to/crt-list ca-file /path/to/my/ca.pem server srv0 192.0.2.1:80 I'd like then to manage this using: set ssl cert The use-case being the following: when integrating with service mesh solutions such as consul-connect, you may want to reduce the disruption occurring when certificates are renewed. And in such kind of solution, they are renewed quite often (once every few tens of hours). In this case the memory space is already allocated etc. so I (naively?) think it probably doesn't hurt too much. What is your point-of-view? -- Pierre
Re: Issues with d13afbcce5e664f9cfe797eee8c527e5fa947f1b (haproxy-2.2) "mux-h1: Don't set CS_FL_EOI too early for protocol upgrade requests"
On 2021-02-08 14:46, Christopher Faulet wrote: Le 08/02/2021 à 14:31, Christian Ruppert a écrit : Hi list, Christopher, we're having issues with the mentioned commit / patch: d13afbcce5e664f9cfe797eee8c527e5fa947f1b https://git.haproxy.org/?p=haproxy-2.2.git;a=commit;h=d13afbcce5e664f9cfe797eee8c527e5fa947f1b I can also reproduce it with 2.2.9 as well as 2.3.5. I don't have any useful details yet, just the our Jira fails to load. A curl against the site seams to work fine while browser requests (chrome / firefox) seem to timeout or at least some. See the attached log. The first 3 requests seem to be fine so far. Then, much later, there's a 504 between more 200s. I'm not sure yet why the other 200s there seem to wait / are logged after the actual timeout happens. According to chrome's F12 there are more requests still pending. Ignore the 503 there. That seems to be an unrelated problem, since this also happends with a working HAProxy. Much later, the site loaded, sometimes broken though. I'll try to prepare a config snipped if required. Is there anything know already? Thanks Christian, I'll take a look. Could you confirm or inform it happens only with requests with a "Connection: upgrade" header ? This frontend doesn't have H2 enabled explicit. I'm not really sure but it looks like some of those delayed requests don't have the upgrade header. -- Regards, Christian Ruppert
Re: Issues with d13afbcce5e664f9cfe797eee8c527e5fa947f1b (haproxy-2.2) "mux-h1: Don't set CS_FL_EOI too early for protocol upgrade requests"
Le 08/02/2021 à 14:31, Christian Ruppert a écrit : Hi list, Christopher, we're having issues with the mentioned commit / patch: d13afbcce5e664f9cfe797eee8c527e5fa947f1b https://git.haproxy.org/?p=haproxy-2.2.git;a=commit;h=d13afbcce5e664f9cfe797eee8c527e5fa947f1b I can also reproduce it with 2.2.9 as well as 2.3.5. I don't have any useful details yet, just the our Jira fails to load. A curl against the site seams to work fine while browser requests (chrome / firefox) seem to timeout or at least some. See the attached log. The first 3 requests seem to be fine so far. Then, much later, there's a 504 between more 200s. I'm not sure yet why the other 200s there seem to wait / are logged after the actual timeout happens. According to chrome's F12 there are more requests still pending. Ignore the 503 there. That seems to be an unrelated problem, since this also happends with a working HAProxy. Much later, the site loaded, sometimes broken though. I'll try to prepare a config snipped if required. Is there anything know already? Thanks Christian, I'll take a look. Could you confirm or inform it happens only with requests with a "Connection: upgrade" header ? -- Christopher Faulet
Re: [PATCH] BUILD: ssl: guard SSL_CTX_set_msg_callback with SSL_CTRL_SET_MSG_CALLBACK macro
On Mon, Feb 08, 2021 at 05:17:32PM +0500, Илья Шипицин wrote: > usually I do such a stupid mistakes on friday. > I wonder about next friday :( > > new patch attached. > > Ilya > Don't worry it happens to me quite a lot :-) Applied, thanks. -- William Lallemand
Re: [PATCH 0/6] cli commands coherency
Hi Christopher, On Mon, Feb 8, 2021 at 12:21 PM Christopher Faulet wrote: > First, there is a test to be sure the agent-check is enabled before updating > the > agent address and/or port. Do you think it should also be done for the > health-check? Because, for now, it is possible to set an address on a disabled > (or even not configured) health-check. But it is not possible for an > agent-check. Given that it is not possible to enable/disable an agent-check or > an health-check from the CLI, I guess the warning for both makes sense. yes ok. > Then, there are some problems when the server-state file is loaded. The trash > chunk used by srv_update_state() is overwritten when > update_server_agent_addr_port() is called. It is not obvious, but the > get_trash_chunk() function returns cyclically one of two trash chunks. > srv_update_state() uses a trash chunk. When called, > update_server_check_addr_port() uses the other one. So, > update_server_agent_addr_port() re-uses the first trash chunk, the same than > srv_update_state(). A solution may be to allocate a dedicated chunk in > srv_update_state(), using alloc_trash_chunk(). ah ok, I thought it was ok as long as there was no reset, but I indeed overlooked the second chunk. I will fix that. > A more annoying problem happens when an old state file is loaded (prior these > changes). Last parameters are not defined, params[18] (check-addr), params[19] > (agent-addr) and params[20] (agent-port) are set to NULL. Thus, HAProxy > crashes > when the health-check address is compared to "-". In fact, this comes from the > SRV_STATE_FILE_NB_FIELDS_VERSION_1 macro. It should be set to 24. You added 3 > new fields but just incremented it by 1. Hum... No, there is also another > problem. In srv_state_parse_line(). SRV_STATE_FILE_NB_FIELDS_VERSION_1 must be > equal to SRV_STATE_FILE_MAX_FIELDS. Or better, it should really reflect the > argument number of the version 1, so 21. And it must be compared to srv_arg > instead of arg. It is a bug since the 1.8 (commit 316947196). ah true I overlooked SRV_STATE_FILE_NB_FIELDS_VERSION_1 meaning. let me fix that as well. > However, this means with these changes, a cold restart is required. In the > 2.4, > 5 new fields were added to the server-state file. Is it expected to perform a > cold restart when upgrading to the 2.4 from a prior major version ? If so, I'm > ok. But, it may be a good idea to change the state file version then to not > silently ignore the state file. Otherwise, I guess it is possible to make > these > 5 new fields optional, isn't it ? good idea. We never did it in the past, but that's probably a good thing to do. > William, I'm sorry if I'm not really clear but the subject is a bit foggy for > me > :) Do you feel confident to handle all the changes ? Thanks for the review. I will come back with a v2. -- William
Issues with d13afbcce5e664f9cfe797eee8c527e5fa947f1b (haproxy-2.2) "mux-h1: Don't set CS_FL_EOI too early for protocol upgrade requests"
Hi list, Christopher,
we're having issues with the mentioned commit / patch:
d13afbcce5e664f9cfe797eee8c527e5fa947f1b
https://git.haproxy.org/?p=haproxy-2.2.git;a=commit;h=d13afbcce5e664f9cfe797eee8c527e5fa947f1b
I can also reproduce it with 2.2.9 as well as 2.3.5. I don't have any
useful details yet, just the our Jira fails to load.
A curl against the site seams to work fine while browser requests
(chrome / firefox) seem to timeout or at least some.
See the attached log. The first 3 requests seem to be fine so far. Then,
much later, there's a 504 between more 200s.
I'm not sure yet why the other 200s there seem to wait / are logged
after the actual timeout happens. According to chrome's F12 there are
more requests still pending.
Ignore the 503 there. That seems to be an unrelated problem, since this
also happends with a working HAProxy.
Much later, the site loaded, sometimes broken though.
I'll try to prepare a config snipped if required.
Is there anything know already?
--
Regards,
Christian Ruppert1.2.3.4:48262 [08/Feb/2021:14:07:46.764] genfrontend_23510-somecorp_jira_prod~
genbackend_23540-somecorp_jira_prod/localhost 0/0/0/42/42 200 11980 - -
2/1/0/0/0 0/0 {jira.somecorp.com|Mozilla/5.0 (X11; Linux x86_64)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.146 Safari/537.36|||}
"GET /secure/Dashboard.jspa HTTP/1.1"
1.2.3.4:48274 [08/Feb/2021:14:07:47.012] genfrontend_23510-somecorp_jira_prod~
genbackend_23540-somecorp_jira_prod/localhost 0/0/0/8/8 200 732 - -
11/6/4/4/0 0/0 {jira.somecorp.com|Mozilla/5.0 (X11; Linux x86_64)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.146
Safari/537.36|https://jira.somecorp.com/secure/Dashboard.jspa||} "GET
/s/d41d8cd98f00b204e9800998ecf8427e-CDN/-98lwuj/813002/490f9a4ca6ac70d1532e1a0dd1cb197c/3.0.4/_/download/batch/com.atlassian.jira.jira-tzdetect-plugin:tzdetect-banner-component/com.atlassian.jira.jira-tzdetect-plugin:tzdetect-banner-component.css
HTTP/1.1"
1.2.3.4:48278 [08/Feb/2021:14:07:47.012] genfrontend_23510-somecorp_jira_prod~
genbackend_23540-somecorp_jira_prod/localhost 0/0/1/7/8 200 2594 - -
11/6/3/3/0 0/0 {jira.somecorp.com|Mozilla/5.0 (X11; Linux x86_64)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.146
Safari/537.36|https://jira.somecorp.com/secure/Dashboard.jspa||} "GET
/s/ff9c3ef8b3ac69e6c33e26ebff0feeac-CDN/-98lwuj/813002/490f9a4ca6ac70d1532e1a0dd1cb197c/14305ce2982b2bea8ec24ee5b182b6c7/_/download/contextbatch/css/jira.global.look-and-feel,-_super/batch.css
HTTP/1.1"
1.2.3.4:48278 [08/Feb/2021:14:07:47.042] genfrontend_23510-somecorp_jira_prod~
genbackend_23540-somecorp_jira_prod/localhost 0/0/0/24/24 200 3460 - -
12/6/5/5/0 0/0 {jira.somecorp.com|Mozilla/5.0 (X11; Linux x86_64)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.146
Safari/537.36|https://jira.somecorp.com/secure/Dashboard.jspa||} "GET
/s/00712794fa9ae1af7f4bae6d811706f6-CDN/-98lwuj/813002/490f9a4ca6ac70d1532e1a0dd1cb197c/3.0.4/_/download/batch/com.atlassian.jira.jira-tzdetect-plugin:tzdetect-banner-component/com.atlassian.jira.jira-tzdetect-plugin:tzdetect-banner-component.js?locale=de-DE
HTTP/1.1"
1.2.3.4:48274 [08/Feb/2021:14:07:47.036] genfrontend_23510-somecorp_jira_prod~
genbackend_23540-somecorp_jira_prod/localhost 0/0/0/-1/30 504 203 - - sH--
12/6/4/4/0 0/0 {jira.somecorp.com|Mozilla/5.0 (X11; Linux x86_64)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.146
Safari/537.36|https://jira.somecorp.com/secure/Dashboard.jspa||} "GET
/s/9a5257d0fa632d5edfa0967de8b1c7df-CDN/-98lwuj/813002/490f9a4ca6ac70d1532e1a0dd1cb197c/6aeee818fc5e706562782156532c027f/_/download/contextbatch/js/atl.global,-_super/batch.js?locale=de-DE
HTTP/1.1"
1.2.3.4:48276 [08/Feb/2021:14:07:47.012] genfrontend_23510-somecorp_jira_prod~
genbackend_23540-somecorp_jira_prod/localhost 0/0/1/13/300035 200 144662 - -
sD-- 11/6/3/3/0 0/0 {jira.somecorp.com|Mozilla/5.0 (X11; Linux x86_64)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.146
Safari/537.36|https://jira.somecorp.com/secure/Dashboard.jspa||} "GET
/s/fc667f1dddeeda81ff75f751da43391f-CDN/-98lwuj/813002/490f9a4ca6ac70d1532e1a0dd1cb197c/c2b5a025bbb84cbbb3ec1b499bc08403/_/download/contextbatch/css/atl.dashboard,jira.global,atl.general,jira.dashboard,-_super/batch.css?agile_global_admin_condition=true=true
HTTP/1.1"
1.2.3.4:48276 [08/Feb/2021:14:12:47.046] genfrontend_23510-somecorp_jira_prod~
genbackend_23540-somecorp_jira_prod/localhost 0/0/0/7/7 200 861 - -
11/6/3/3/0 0/0 {jira.somecorp.com|Mozilla/5.0 (X11; Linux x86_64)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.146
Safari/537.36|https://jira.somecorp.com/secure/Dashboard.jspa||} "GET
/s/d41d8cd98f00b204e9800998ecf8427e-CDN/-98lwuj/813002/490f9a4ca6ac70d1532e1a0dd1cb197c/3.0.4/_/download/batch/com.atlassian.jira.jira-tzdetect-plugin:tzdetect-lib/com.atlassian.jira.jira-tzdetect-plugin:tzdetect-lib.js
HTTP/1.1"
1.2.3.4:48274 [08/Feb/2021:14:12:47.058]
Re: [PATCH] BUILD: ssl: guard SSL_CTX_set_msg_callback with SSL_CTRL_SET_MSG_CALLBACK macro
usually I do such a stupid mistakes on friday. I wonder about next friday :( new patch attached. Ilya пн, 8 февр. 2021 г. в 17:08, William Lallemand : > On Mon, Feb 08, 2021 at 05:03:43PM +0500, Илья Шипицин wrote: > > I've added commit message. > > > > Ilya > > > > > From f39f9f69e29570fa43d7db5a0f08ee9395b98d50 Mon Sep 17 00:00:00 2001 > > From: Ilya Shipitsin > > Date: Sat, 23 Jan 2021 00:50:59 +0500 > > Subject: [PATCH] BUILD: ssl: guard SSL_CTX_set_msg_callback with > > SSL_CTRL_SET_MSG_CALLBACK macro > > > > --- > > src/ssl_sock.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/src/ssl_sock.c b/src/ssl_sock.c > > index 24a38e47d..2bda3d765 100644 > > --- a/src/ssl_sock.c > > +++ b/src/ssl_sock.c > > @@ -4224,7 +4224,7 @@ int ssl_sock_prepare_ctx(struct bind_conf > *bind_conf, struct ssl_bind_conf *ssl_ > > #endif /* OPENSSL_NO_DH */ > > > > SSL_CTX_set_info_callback(ctx, ssl_sock_infocbk); > > -#if HA_OPENSSL_VERSION_NUMBER >= 0x00907000L > > +#ifdef SSL_CTRL_SET_MSG_CALLBACK > > SSL_CTX_set_msg_callback(ctx, ssl_sock_msgcbk); > > #endif > > #ifdef HAVE_OPENSSL_KEYLOG > > -- > > 2.29.2 > > > > It looks like you sent the exact same patch by mistake. > > -- > William Lallemand > From 381ae2e9948d5d85f6926481c8816a0a7069a994 Mon Sep 17 00:00:00 2001 From: Ilya Shipitsin Date: Mon, 8 Feb 2021 16:55:06 +0500 Subject: [PATCH] BUILD: ssl: guard SSL_CTX_set_msg_callback with SSL_CTRL_SET_MSG_CALLBACK macro both SSL_CTX_set_msg_callback and SSL_CTRL_SET_MSG_CALLBACK defined since ea262260469e49149cb10b25a87dfd6ad3fbb4ba, we can safely switch to that guard instead of OpenSSL version --- src/ssl_sock.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/ssl_sock.c b/src/ssl_sock.c index 310578503..099e7f922 100644 --- a/src/ssl_sock.c +++ b/src/ssl_sock.c @@ -4411,7 +4411,7 @@ int ssl_sock_prepare_ctx(struct bind_conf *bind_conf, struct ssl_bind_conf *ssl_ #endif /* OPENSSL_NO_DH */ SSL_CTX_set_info_callback(ctx, ssl_sock_infocbk); -#if HA_OPENSSL_VERSION_NUMBER >= 0x00907000L +#ifdef SSL_CTRL_SET_MSG_CALLBACK SSL_CTX_set_msg_callback(ctx, ssl_sock_msgcbk); #endif #ifdef HAVE_OPENSSL_KEYLOG -- 2.29.2
Re: [PATCH] BUILD: ssl: guard SSL_CTX_set_msg_callback with SSL_CTRL_SET_MSG_CALLBACK macro
On Mon, Feb 08, 2021 at 05:03:43PM +0500, Илья Шипицин wrote: > I've added commit message. > > Ilya > > From f39f9f69e29570fa43d7db5a0f08ee9395b98d50 Mon Sep 17 00:00:00 2001 > From: Ilya Shipitsin > Date: Sat, 23 Jan 2021 00:50:59 +0500 > Subject: [PATCH] BUILD: ssl: guard SSL_CTX_set_msg_callback with > SSL_CTRL_SET_MSG_CALLBACK macro > > --- > src/ssl_sock.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/src/ssl_sock.c b/src/ssl_sock.c > index 24a38e47d..2bda3d765 100644 > --- a/src/ssl_sock.c > +++ b/src/ssl_sock.c > @@ -4224,7 +4224,7 @@ int ssl_sock_prepare_ctx(struct bind_conf *bind_conf, > struct ssl_bind_conf *ssl_ > #endif /* OPENSSL_NO_DH */ > > SSL_CTX_set_info_callback(ctx, ssl_sock_infocbk); > -#if HA_OPENSSL_VERSION_NUMBER >= 0x00907000L > +#ifdef SSL_CTRL_SET_MSG_CALLBACK > SSL_CTX_set_msg_callback(ctx, ssl_sock_msgcbk); > #endif > #ifdef HAVE_OPENSSL_KEYLOG > -- > 2.29.2 > It looks like you sent the exact same patch by mistake. -- William Lallemand
Re: [PATCH] BUILD: ssl: guard SSL_CTX_set_msg_callback with SSL_CTRL_SET_MSG_CALLBACK macro
I've added commit message. Ilya сб, 23 янв. 2021 г. в 21:46, William Lallemand : > Hello, > > On Sat, Jan 23, 2021 at 02:06:41AM +0500, Илья Шипицин wrote: > > Hello, > > > > another ssl guard patch > > > > Ilya > > > From f39f9f69e29570fa43d7db5a0f08ee9395b98d50 Mon Sep 17 00:00:00 2001 > > From: Ilya Shipitsin > > Date: Sat, 23 Jan 2021 00:50:59 +0500 > > Subject: [PATCH] BUILD: ssl: guard SSL_CTX_set_msg_callback with > > SSL_CTRL_SET_MSG_CALLBACK macro > > > > --- > > src/ssl_sock.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/src/ssl_sock.c b/src/ssl_sock.c > > index 24a38e47d..2bda3d765 100644 > > --- a/src/ssl_sock.c > > +++ b/src/ssl_sock.c > > @@ -4224,7 +4224,7 @@ int ssl_sock_prepare_ctx(struct bind_conf > *bind_conf, struct ssl_bind_conf *ssl_ > > #endif /* OPENSSL_NO_DH */ > > > > SSL_CTX_set_info_callback(ctx, ssl_sock_infocbk); > > -#if HA_OPENSSL_VERSION_NUMBER >= 0x00907000L > > +#ifdef SSL_CTRL_SET_MSG_CALLBACK > > SSL_CTX_set_msg_callback(ctx, ssl_sock_msgcbk); > > #endif > > #ifdef HAVE_OPENSSL_KEYLOG > > -- > > 2.29.2 > > > > Please add a commit message in your patches, patches with only a subject > line won't be taken. See this part of the contributing rules: > https://github.com/haproxy/haproxy/blob/master/CONTRIBUTING#L455 > > Thanks, > > -- > William Lallemand > From f39f9f69e29570fa43d7db5a0f08ee9395b98d50 Mon Sep 17 00:00:00 2001 From: Ilya Shipitsin Date: Sat, 23 Jan 2021 00:50:59 +0500 Subject: [PATCH] BUILD: ssl: guard SSL_CTX_set_msg_callback with SSL_CTRL_SET_MSG_CALLBACK macro --- src/ssl_sock.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/ssl_sock.c b/src/ssl_sock.c index 24a38e47d..2bda3d765 100644 --- a/src/ssl_sock.c +++ b/src/ssl_sock.c @@ -4224,7 +4224,7 @@ int ssl_sock_prepare_ctx(struct bind_conf *bind_conf, struct ssl_bind_conf *ssl_ #endif /* OPENSSL_NO_DH */ SSL_CTX_set_info_callback(ctx, ssl_sock_infocbk); -#if HA_OPENSSL_VERSION_NUMBER >= 0x00907000L +#ifdef SSL_CTRL_SET_MSG_CALLBACK SSL_CTX_set_msg_callback(ctx, ssl_sock_msgcbk); #endif #ifdef HAVE_OPENSSL_KEYLOG -- 2.29.2
Re: [PATCH 0/6] cli commands coherency
Le 06/02/2021 à 20:47, William Dauchy a écrit :
Hello,
This is a followup from last week cleaning regarding check and agent
check. This patch series brings some more coherency on the CLI side. I
also put some minor cleaning.
William Dauchy (6):
CLEANUP: check: fix some typo in comments
CLEANUP: tools: typo in `strl2irc` mention
MEDIUM: cli: add check-addr command
MEDIUM: cli: add agent-port command
MEDIUM: server: support {check,agent}_addr, agent_port in server state
CLEANUP: server: add missing space in server-state error output
doc/management.txt| 15 +-
include/haproxy/server-t.h| 9 +-
.../checks/1be_40srv_odd_health_checks.vtc| 2 +-
.../checks/40be_2srv_odd_health_checks.vtc| 2 +-
reg-tests/checks/4be_1srv_health_checks.vtc | 6 +-
src/check.c | 18 +-
src/proxy.c | 41 ++--
src/server.c | 192 ++
src/tools.c | 2 +-
9 files changed, 213 insertions(+), 74 deletions(-)
Thanks William ! I merged the first two patches. For the others, I've some
questions/comments.
First, there is a test to be sure the agent-check is enabled before updating the
agent address and/or port. Do you think it should also be done for the
health-check? Because, for now, it is possible to set an address on a disabled
(or even not configured) health-check. But it is not possible for an
agent-check. Given that it is not possible to enable/disable an agent-check or
an health-check from the CLI, I guess the warning for both makes sense.
Then, there are some problems when the server-state file is loaded. The trash
chunk used by srv_update_state() is overwritten when
update_server_agent_addr_port() is called. It is not obvious, but the
get_trash_chunk() function returns cyclically one of two trash chunks.
srv_update_state() uses a trash chunk. When called,
update_server_check_addr_port() uses the other one. So,
update_server_agent_addr_port() re-uses the first trash chunk, the same than
srv_update_state(). A solution may be to allocate a dedicated chunk in
srv_update_state(), using alloc_trash_chunk().
A more annoying problem happens when an old state file is loaded (prior these
changes). Last parameters are not defined, params[18] (check-addr), params[19]
(agent-addr) and params[20] (agent-port) are set to NULL. Thus, HAProxy crashes
when the health-check address is compared to "-". In fact, this comes from the
SRV_STATE_FILE_NB_FIELDS_VERSION_1 macro. It should be set to 24. You added 3
new fields but just incremented it by 1. Hum... No, there is also another
problem. In srv_state_parse_line(). SRV_STATE_FILE_NB_FIELDS_VERSION_1 must be
equal to SRV_STATE_FILE_MAX_FIELDS. Or better, it should really reflect the
argument number of the version 1, so 21. And it must be compared to srv_arg
instead of arg. It is a bug since the 1.8 (commit 316947196).
However, this means with these changes, a cold restart is required. In the 2.4,
5 new fields were added to the server-state file. Is it expected to perform a
cold restart when upgrading to the 2.4 from a prior major version ? If so, I'm
ok. But, it may be a good idea to change the state file version then to not
silently ignore the state file. Otherwise, I guess it is possible to make these
5 new fields optional, isn't it ?
William, I'm sorry if I'm not really clear but the subject is a bit foggy for me
:) Do you feel confident to handle all the changes ?
--
Christopher Faulet
Re: [PATCH 1/2] MINOR: contrib/prometheus-exporter: use stats desc when possible followup
Le 07/02/2021 à 20:42, William Dauchy a écrit :
Remove remaining descrition which are common to stats.c.
This patch is a followup of commit
82b2ce2f967d967139adb7afab064416fadad615 ("MINOR:
contrib/prometheus-exporter: use stats desc when possible"). I probably
messed up with one of my rebase because I'm pretty sure I removed them
at some point, but who knows what happened.
Signed-off-by: William Dauchy
---
.../prometheus-exporter/service-prometheus.c | 35 ---
1 file changed, 35 deletions(-)
diff --git a/contrib/prometheus-exporter/service-prometheus.c
b/contrib/prometheus-exporter/service-prometheus.c
index 126962f5e..769389735 100644
--- a/contrib/prometheus-exporter/service-prometheus.c
+++ b/contrib/prometheus-exporter/service-prometheus.c
@@ -284,42 +284,7 @@ const struct promex_metric
promex_st_metrics[ST_F_TOTAL_FIELDS] = {
/* Description of overriden stats fields */
const struct ist promex_st_metric_desc[ST_F_TOTAL_FIELDS] = {
- [ST_F_PXNAME] = IST("The proxy name."),
- [ST_F_SVNAME] = IST("The service name (FRONTEND for frontend,
BACKEND for backend, any name for server/listener)."),
- [ST_F_QCUR] = IST("Current number of queued requests."),
- [ST_F_QMAX] = IST("Maximum observed number of queued
requests."),
- [ST_F_SCUR] = IST("Current number of active sessions."),
- [ST_F_SMAX] = IST("Maximum observed number of active
sessions."),
- [ST_F_SLIM] = IST("Configured session limit."),
- [ST_F_STOT] = IST("Total number of sessions."),
- [ST_F_BIN]= IST("Current total of incoming bytes."),
- [ST_F_BOUT] = IST("Current total of outgoing bytes."),
- [ST_F_DREQ] = IST("Total number of denied requests."),
- [ST_F_DRESP] = IST("Total number of denied responses."),
- [ST_F_EREQ] = IST("Total number of request errors."),
- [ST_F_ECON] = IST("Total number of connection errors."),
- [ST_F_ERESP] = IST("Total number of response errors."),
- [ST_F_WRETR] = IST("Total number of retry warnings."),
- [ST_F_WREDIS] = IST("Total number of redispatch warnings."),
[ST_F_STATUS] = IST("Current status of the service, per state label
value."),
- [ST_F_WEIGHT] = IST("Service weight."),
- [ST_F_ACT]= IST("Current number of active servers."),
- [ST_F_BCK]= IST("Current number of backup servers."),
- [ST_F_CHKFAIL]= IST("Total number of failed check (Only counts
checks failed when the server is up)."),
- [ST_F_CHKDOWN]= IST("Total number of UP->DOWN transitions."),
- [ST_F_LASTCHG]= IST("Number of seconds since the last UP<->DOWN
transition."),
- [ST_F_DOWNTIME] = IST("Total downtime (in seconds) for the
service."),
- [ST_F_QLIMIT] = IST("Configured maxqueue for the server (0 meaning
no limit)."),
- [ST_F_PID]= IST("Process id (0 for first instance, 1 for second,
...)"),
- [ST_F_IID]= IST("Unique proxy id."),
- [ST_F_SID]= IST("Server id (unique inside a proxy)."),
- [ST_F_THROTTLE] = IST("Current throttle percentage for the server,
when slowstart is active, or no value if not in slowstart."),
- [ST_F_LBTOT] = IST("Total number of times a service was selected,
either for new sessions, or when redispatching."),
- [ST_F_TRACKED]= IST("Id of proxy/server if tracking is
enabled."),
- [ST_F_TYPE] = IST("Service type (0=frontend, 1=backend, 2=server,
3=socket/listener)."),
- [ST_F_RATE] = IST("Current number of sessions per second over last
elapsed second."),
- [ST_F_RATE_LIM] = IST("Configured limit on new sessions per
second."),
- [ST_F_RATE_MAX] = IST("Maximum observed number of sessions per
second."),
[ST_F_CHECK_STATUS] = IST("Status of last health check, per state label
value."),
[ST_F_CHECK_CODE] = IST("layer5-7 code, if available of the last health
check."),
[ST_F_CHECK_DURATION] = IST("Total duration of the latest server health
check, in seconds."),
Both merged, thanks William !
--
Christopher Faulet
Re: [PATCH] typo fixes
Le 06/02/2021 à 18:30, Илья Шипицин a écrit : Hello, another cleanup. Now merged. Thanks ! -- Christopher Faulet
