MINOR: Revert part of clarifying samples support per os commit
Commit 5c83e3a1563cd7face299bf08037e51f976eb5e3 made some adjustments to clarify which TCP_INFO information is supported by each respective OS. There was a comment like so.. Note that fc_rtt and fc_rttvar are supported on any OS that has TCP_INFO, not just linux/freebsd/netbsd, so we continue to expose them unconditionally. But the diff didn't do so in a consistent manner. diff --git a/src/tcp_sample.c b/src/tcp_sample.c index 300ce1c8d..925b93291 100644 --- a/src/tcp_sample.c +++ b/src/tcp_sample.c @@ -373,7 +373,6 @@ static inline int get_tcp_info(const struct arg *args, struct sample *smp, return 1; } -#if defined(__linux__) || defined(__FreeBSD__) || defined(__NetBSD__) || defined(__OpenBSD__) || defined(__APPLE__) /* get the mean rtt of a client connection */ static int smp_fetch_fc_rtt(const struct arg *args, struct sample *smp, const char *kw, void *private) @@ -387,9 +386,7 @@ smp_fetch_fc_rtt(const struct arg *args, struct sample *smp, const char *kw, voi return 1; } -#endif -#if defined(__linux__) || defined(__FreeBSD__) || defined(__NetBSD__) || defined(__OpenBSD__) || defined(__APPLE__) /* get the variance of the mean rtt of a client connection */ static int smp_fetch_fc_rttvar(const struct arg *args, struct sample *smp, const char *kw, void *private) @@ -403,8 +400,6 @@ smp_fetch_fc_rttvar(const struct arg *args, struct sample *smp, const char *kw, return 1; } -#endif - #if defined(__linux__) || defined(__FreeBSD__) || defined(__NetBSD__) || defined(__OpenBSD__) || defined(__APPLE__) /* get the unacked counter on a client connection */
Weird behavior with UNIX sockets
Hey, I've got a kinda strange problem with UNIX sockets. I first thought it's a Varnish issue but it may be actually be a HAProxy one. So I've this attached test config, a static error file and a test script (perl, no third party modules, just a few lines), which I'd like to share only off-list (just mail me / let me know) to prevent script-kiddies from abusing it. So we have those huge timeouts just for this test case. maxconn 500k. The test script will do 200k connections. It will open all 200k connections (verify via netstat/ss or something else) and waits for a /tmp/debug file to exist (just touch it if ready). If it exists, it will send GET / requests as fast as possible with all the connections. It was initially meant to test a connection to Varnish instead. So what happens is what is strange: Often: Some connections/requests will be answered with a 503 by HAProxy. HAProxy will log a "SC" on the backend connection: Aug 25 18:14:20 localhost haproxy[23512]: unix:1 [25/Aug/2022:18:14:20.051] li_udstest be_static_err/ 62/-1/-1/-1/62 503 97 - - SC-- 162032/1/0/0/0 0/0 "GET / HTTP/1.1" Sometimes: The mentioned 503's plus: Aug 25 18:14:19 localhost haproxy[23512]: Connect() failed for backend be_udstest: can't connect to destination unix socket, check backlog size on the server. Also sometimes: All 200's. Anything fine. I'd expect it to behave basically the same every time but that's a completely different behavior in all three cases. And actually I'd like it to only answer 200's :) The process limits are looking good so far: # grep 'open files' /proc/$(pgrep -n haproxy)/limits Max open files182 800 files On another test machine we even have a 30mio hard and 10mio soft limit. So those limits should be enough in any case, actually. This has been tested with 2.6.4, 2.6.3, 2.6.2. The same happens if be_udstest points to e.g. Varnish via UDS. Can you reproduce it? Any idea what may cause it? -- Regards, Christian Ruppertglobal maxconn 50 defaults maxconn 50 timeout client 15m timeout client-fin 15m timeout connect 15m timeout http-request 15m timeout queue 15m timeout http-keep-alive 15m timeout server 15m log 127.0.0.1 len 65535 local0 frontend fe_udstest mode http bind :61610 log global option httplog default_backend be_udstest backend be_udstest mode http server udstest unix@/run/udstest.sock listen li_udstest mode http option httplog bind unix@/run/udstest.sock mode 666 default_backend be_static_err backend be_static_err mode http errorfile 503 /etc/haproxy/static-err.txt HTTP/1.1 200 OK Cache-Control: no-cache Connection: close Content-Type: text/plain Test
Schedule a quick call
Hi, I hope I'm not bothering you. Could you please refer me to the person in charge of email marketing in your company and possibly interested in the most affordable email campaign tool - ReachEngine.io? Thanks for your time. Regards, Angela Christine| Pre-Sales Associate ReachEngine.io To Opt-Out, please reply unsubscribe in the subject line.
Re: Lua: processing expired on timeout when using core.msleep
Le 8/23/22 à 20:08, Bren a écrit : --- Original Message --- On Tuesday, August 23rd, 2022 at 4:26 AM, Christopher Faulet wrote: It could be good to share your config, at least the part calling your lua script. I think these are the only relevant bits: tcp-request inspect-delay 10s http-request lua.delay_request 15000 3 I'm delaying requests a random number of ms between 15000 and 3. But this error can be triggered when the inspect-delay for tcp rules evaluation is expires. Perhaps this is what is happening? You have an inspect delay for tcp-request rules but your script is called during http-request rules eval. So it is not related. Here I guess you have enable abortonclose option and a client abort is caught. In this case, the script execution is interrupted. Or a read error occurred on the client side. However, I must admit the warning is not accurate in this case... -- Christopher Faulet
