Re: sticky session with cookie
~. for strictness -- Ionel GARDAIS Tech'Advantage CIO - IT Team manager De: "Ionel GARDAIS" À: "haproxy" Envoyé: Vendredi 24 Janvier 2020 19:24:45 Objet: sticky session with cookie Hi list, I'm sorry if this question has already been asked but I don't see any answer to it. The backend servers already set a cookie which value identifies it (.) Can haproxy archieve stickiness based on the value ? Currently, I'm using cookie AUTH_SESSION_ID prefix server srv1 192.168.1.1 cookie s1 server srv2 192.168.1.2 cookie s2 but ending with .. is redundant if I can make haproxy use Thanks, Ionel -- 232 avenue Napoleon BONAPARTE 92500 RUEIL MALMAISON Capital EUR 219 300,00 - RCS Nanterre B 408 832 301 - TVA FR 09 408 832 301
sticky session with cookie
Hi list, I'm sorry if this question has already been asked but I don't see any answer to it. The backend servers already set a cookie which value identifies it (.) Can haproxy archieve stickiness based on the value ? Currently, I'm using cookie AUTH_SESSION_ID prefix server srv1 192.168.1.1 cookie s1 server srv2 192.168.1.2 cookie s2 but ending with .. is redundant if I can make haproxy use Thanks, Ionel -- 232 avenue Napoleon BONAPARTE 92500 RUEIL MALMAISON Capital EUR 219 300,00 - RCS Nanterre B 408 832 301 - TVA FR 09 408 832 301
Re: arm64 builds?
Hi, FWIW, when I build for armhf (RaspberryPi 3b with Raspbian buster), I have to add -latomic to the LD_FLAGS. Ionel - Mail original - De: "Willy Tarreau" À: " ???" Cc: "haproxy" Envoyé: Lundi 4 Novembre 2019 13:48:57 Objet: Re: arm64 builds? Hi Ilya, On Mon, Nov 04, 2019 at 12:18:49AM +0500, ??? wrote: > hello, > > should we switch some builds to arm64? > > https://blog.travis-ci.com/2019-10-07-multi-cpu-architecture-support Ah that's interesting! I frequently build for arm/arm64 but I agree it would be nice to have this done more frequently. The two main points I'm seeing are : - unsigned chars, which occasionally trigger a warning somewhere - non-x86 build, which can occasionally trigger a build error if we accidently rely on an arch-specific function In fact I would even suggest that we build for arm instead of arm64 so that we switch to 32 bits at the same time and have an opportunity to detect long vs int vs uint64t vs pointer vs size_t issues (typically places where printf uses "%lu" without a cast for uint64_t). Thanks, Willy -- 232 avenue Napoleon BONAPARTE 92500 RUEIL MALMAISON Capital EUR 219 300,00 - RCS Nanterre B 408 832 301 - TVA FR 09 408 832 301
Re: Segfaults with 1.9.6
Hi Olivier,
As far as I can remember, 1.9 had a series of segfaults involving H2 and HTX,
patched from release to release.
[ http://www.haproxy.org/bugs/bugs-1.9.6.html |
http://www.haproxy.org/bugs/bugs-1.9.6.html ]
As a rule of thumb, I can only suggest you try with the latest 1.9 release
(that is 1.9.12 as of today) and see if segfaults happen again.
--
Ionel GARDAIS
Tech'Advantage CIO - IT Team manager
De: "Olivier D"
À: "haproxy"
Envoyé: Vendredi 25 Octobre 2019 14:48:20
Objet: Segfaults with 1.9.6
Hello,
I know I'm reporting an issue with an old version, but I got 2 segfaults in
48h.
As I only got 3 segfaults with HAProxy in +10 years, I just wanted to make sure
these bugs have been caught and are now fixed.
haproxy -vv output:
HA-Proxy version 1.9.6 2019/03/29 - [ https://haproxy.org/ |
https://haproxy.org/ ]
Build options :
TARGET = linux2628
CPU = generic
CC = gcc
CFLAGS = -O2 -g -fno-strict-aliasing -Wdeclaration-after-statement -fwrapv
-Wno-format-truncation -Wno-unused-label -Wno-sign-compare
-Wno-unused-parameter -Wno-old-style-declaration -Wno-ignored-qualifiers
-Wno-clobbered -Wno-missing-field-initializers -Wno-implicit-fallthrough
-Wno-stringop-overflow -Wtype-limits -Wshift-negative-value -Wshift-overflow=2
-Wduplicated-cond -Wnull-dereference
OPTIONS = USE_ZLIB=1 USE_OPENSSL=1 USE_LUA=1 USE_STATIC_PCRE=1
Default settings :
maxconn = 2000, bufsize = 16384, maxrewrite = 1024, maxpollevents = 200
Built with OpenSSL version : OpenSSL 1.1.1b 26 Feb 2019
Running on OpenSSL version : OpenSSL 1.1.1b 26 Feb 2019
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports : TLSv1.0 TLSv1.1 TLSv1.2 TLSv1.3
Built with Lua version : Lua 5.3.5
Built with transparent proxy support using: IP_TRANSPARENT IPV6_TRANSPARENT
IP_FREEBIND
Built with zlib version : 1.2.11
Running on zlib version : 1.2.11
Compression algorithms supported : identity("identity"), deflate("deflate"),
raw-deflate("deflate"), gzip("gzip")
Built with PCRE version : 8.41 2017-07-05
Running on PCRE version : 8.41 2017-07-05
PCRE library supports JIT : no (USE_PCRE_JIT not set)
Encrypted password support via crypt(3): yes
Built with multi-threading support.
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)
h2 : mode=HTX side=FE|BE
h2 : mode=HTTP side=FE
: mode=HTX side=FE|BE
: mode=TCP|HTTP side=FE|BE
Available filters :
[SPOE] spoe
[COMP] compression
[CACHE] cache
[TRACE] trace
### First segfault : ###
Program terminated with signal 11, Segmentation fault.
#0 0x004cba32 in h2_process_mux (h2c=0x9b4b300) at src/mux_h2.c:2588
(gdb) bt full
#0 0x004cba32 in h2_process_mux (h2c=0x9b4b300) at src/mux_h2.c:2588
h2s = 0x98edf50
#1 h2_send (h2c=h2c@entry=0x9b4b300) at src/mux_h2.c:2716
flags =
conn = 0x9aef030
done = 0
sent = 0
#2 0x004d3918 in h2_io_cb (t=, ctx=0x9b4b300,
status=) at src/mux_h2.c:2778
h2c = 0x9b4b300
ret = 0
#3 0x00584456 in process_runnable_tasks () at src/task.c:437
t = 0x9e15170
state =
ctx =
process =
t =
max_processed = 194
#4 0x00503fd4 in run_poll_loop () at src/haproxy.c:2642
next =
exp =
#5 run_thread_poll_loop (data=data@entry=0x19a32b0) at src/haproxy.c:2707
ptif =
ptdf =
start_lock = 0
#6 0x004648d8 in main (argc=, argv=0x7ffccfb0cba8) at
src/haproxy.c:3343
tids = 0x19a32b0
threads = 0x19a2750
i =
old_sig = {__val = {68097, 0, 64, 206158430210, 532575944795, 472446402679, 0,
139791683256608, 24, 11381472, 335544638, 11392704, 26776016, 139791680031404,
0, 26699504}}
blocked_sig = {__val = {1844674406710583, 18446744073709551615 }}
err =
retry =
limit = {rlim_cur = 801167, rlim_max = 801167}
errmsg =
"\000\000\000\000\000\000\000\000\220Ap\312#\177\000\000\000\357\200\000\000\000\000\000(\357\200\000\000\000\000\000\231\353\200\000\000\000\000\000\000\000\000\000\002",
'\000' "\350,
Dp\312#\177\000\000p\311\260\317\374\177\000\000\035\000\000\000\000\000\000\000\210\311\260\317\374\177\000\000
\326\230\001\001\000\000\000\000v\000"
pidfd =
### Second segfault ###
Program terminated with signal 11, Segmentation fault.
#0 0x005808b5 in __pendconn_unlink (p=p@entry=0x7fff694b0730) at
src/queue.c:138
(gdb) bt full
#0 0x005808b5 in __pendconn_unlink (p=p@entry=0x7fff694b0730) at
src/queue.c:138
No locals.
#1 0x00581507 in pendconn_redistribute (s=s@entry=0x6b01cd0) at
src/queue.c:413
p = 0x7fff694b0730
node = 0xb781a88
#2 0x004ee2b2 in srv_update_status (s=s@entry=0x6b01cd0) at
src/server.c:4805
next_admin =
check = 0x6b02170
xferred =
px = 0x6a357e0
prev_srv_count = 2
srv_was_stopping =
log_level =
tmptrash =
Re: Issue with HTX
Hi Christopher, First : good news : I was not able to reproduce the issue with 2.1-dev2-e0f48a-88 and HTX enable. I guess e0f8dc576f62ace9ad1055ca068ab5d4f3a952aa was the culprit. To answer your questions and for others on the list : - The issue arose with H1 (H2 not enable) - It's the client who complained about a malformed payload thus it was unable to unmarshall datas into a valid object (it was the result of an API call). The message from the client is a short error message like "expecting [0-9a-fA-F] but got 0x4f" (note that 0x4f is not a constant and would vary from run to run) - To my understanding, the payload is chunk-encoded. -- Ionel GARDAIS Tech'Advantage CIO - IT Team manager - Mail original - De: "Christopher Faulet" À: "Ionel GARDAIS" , "Willy Tarreau" Cc: "haproxy" Envoyé: Mardi 15 Octobre 2019 10:20:50 Objet: Re: Issue with HTX Le 12/10/2019 à 14:23, GARDAIS Ionel a écrit : > I might have been too enthusiast. > haproxy is set as a TLS-endpoint thus the traces from the client-side are > encrypted. > The trace of the server side is plain text but as this is the client which > complains about a malformed packet, client-side should be compared to > server-side. > > Instead of a tcpdump, I should run full debug on haproxy. > Could you tell me how to do this for HTX ? > > Also, as I was looking at the traces, note that protobuf is involved in the > client-server exchange. > It might change how debug and traces are collected. > Hi, The data corruption happens for H1 or H2 connections (or both) ? On the client side or the server side ? If it is related to H1 connections, is the payload chunk-encoded or not ? If yes, I pushed a fix yesterday that may help. If so, give the last 2.1 snapshot a try. Then, which kind of data corruption did you observe and how did you observe it ? Finally, could you share your configuration please ? Thanks, -- Christopher Faulet -- 232 avenue Napoleon BONAPARTE 92500 RUEIL MALMAISON Capital EUR 219 300,00 - RCS Nanterre B 408 832 301 - TVA FR 09 408 832 301
Re: Issue with HTX
I might have been too enthusiast. haproxy is set as a TLS-endpoint thus the traces from the client-side are encrypted. The trace of the server side is plain text but as this is the client which complains about a malformed packet, client-side should be compared to server-side. Instead of a tcpdump, I should run full debug on haproxy. Could you tell me how to do this for HTX ? Also, as I was looking at the traces, note that protobuf is involved in the client-server exchange. It might change how debug and traces are collected. -- Ionel GARDAIS Tech'Advantage CIO - IT Team manager - Mail original - De: "Willy Tarreau" À: "Ionel GARDAIS" Cc: "haproxy" Envoyé: Samedi 12 Octobre 2019 06:20:40 Objet: Re: Issue with HTX Hi Ionel, On Fri, Oct 11, 2019 at 10:49:19PM +0200, GARDAIS Ionel wrote: > Hi Willy, > > Got 2 tcpdump but I really don't know where to start searching. > One is with HTX on the other HTX disabled. Perfect! > May I send them to you ? Yes please. However I won't have time to look at them before ~Tuesday. Thanks! Willy -- 232 avenue Napoleon BONAPARTE 92500 RUEIL MALMAISON Capital EUR 219 300,00 - RCS Nanterre B 408 832 301 - TVA FR 09 408 832 301
Re: Issue with HTX
Hi Willy, Got 2 tcpdump but I really don't know where to start searching. One is with HTX on the other HTX disabled. May I send them to you ? -- Ionel GARDAIS Tech'Advantage CIO - IT Team manager -- 232 avenue Napoleon BONAPARTE 92500 RUEIL MALMAISON Capital EUR 219 300,00 - RCS Nanterre B 408 832 301 - TVA FR 09 408 832 301
Re: Issue with HTX
> Not for now, this requires the trace filters which are only planned but > not yet available. Thus you'll have debugging enabled on the whole process > at once. Can your reproduce this outside production ? No. But I can run tcpdump filtered on the backend's server IP and provide you with a timestamp of when the client triggers the error because of malformed datas. Ionel -- 232 avenue Napoleon BONAPARTE 92500 RUEIL MALMAISON Capital EUR 219 300,00 - RCS Nanterre B 408 832 301 - TVA FR 09 408 832 301
Re: Issue with HTX
Was using 2.0.7. Had the same issue with 2.1-dev2 It happens with the same tool but does not seem to be triggered every time. Is it possible to enable H1+H2 debug traces on a specific backend ? -- Ionel GARDAIS Tech'Advantage CIO - IT Team manager - Mail original - De: "Willy Tarreau" À: "Ionel GARDAIS" Cc: "haproxy" Envoyé: Mercredi 9 Octobre 2019 04:27:42 Objet: Re: Issue with HTX Hi Ionel, On Tue, Oct 08, 2019 at 03:33:16PM +0200, GARDAIS Ionel wrote: > Hi, > > I'm facing a data corruption that seems related to HTX. > Simply adding 'no option http-use-htx' solve the issue. > > What kind of traces do you need to help diagnose the issue and how to collect > it ? Ideally a network capture before and after haproxy will help. Are you sure you're running on an up-to-date version ? Christopher addressed one such issue recently in H2. If you're able to reproduce this at will, it may be useful to run on latest 2.1-dev, where we can help you enable H1+H2 debug traces. Thanks, Willy -- 232 avenue Napoleon BONAPARTE 92500 RUEIL MALMAISON Capital EUR 219 300,00 - RCS Nanterre B 408 832 301 - TVA FR 09 408 832 301
Issue with HTX
Hi, I'm facing a data corruption that seems related to HTX. Simply adding 'no option http-use-htx' solve the issue. What kind of traces do you need to help diagnose the issue and how to collect it ? Thanks, Ionel -- 232 avenue Napoleon BONAPARTE 92500 RUEIL MALMAISON Capital EUR 219 300,00 - RCS Nanterre B 408 832 301 - TVA FR 09 408 832 301
Re: Issue with checks after 2.0.6
Done : https://github.com/haproxy/haproxy/issues/278 -- Ionel GARDAIS Tech'Advantage CIO - IT Team manager - Mail original - De: "Lukas Tribus" À: "Ionel GARDAIS" , "Willy Tarreau" Cc: "haproxy" Envoyé: Lundi 16 Septembre 2019 11:20:00 Objet: Re: Issue with checks after 2.0.6 Hello! On Mon, Sep 16, 2019 at 8:50 AM GARDAIS Ionel wrote: > > Hi Lukas, > > Same with nbthread 1. > > I gave my first try to git bisect and it looks like the offending commit is : > > ab160a47acde9dc9c341b328c8716a721a389ab4 is the first bad commit > commit ab160a47acde9dc9c341b328c8716a721a389ab4 > Author: Willy Tarreau > Date: Thu Sep 5 17:38:40 2019 +0200 > > BUG/MINOR: checks: do not uselessly poll for reads before the connection > is up Thanks for this, could you file a github issue with those informations: https://github.com/haproxy/haproxy/issues/new/choose Lukas -- 232 avenue Napoleon BONAPARTE 92500 RUEIL MALMAISON Capital EUR 219 300,00 - RCS Nanterre B 408 832 301 - TVA FR 09 408 832 301
Re: Issue with checks after 2.0.6
Hi Lukas, Same with nbthread 1. I gave my first try to git bisect and it looks like the offending commit is : ab160a47acde9dc9c341b328c8716a721a389ab4 is the first bad commit commit ab160a47acde9dc9c341b328c8716a721a389ab4 Author: Willy Tarreau Date: Thu Sep 5 17:38:40 2019 +0200 BUG/MINOR: checks: do not uselessly poll for reads before the connection is up It's pointless to start to perform a recv() call on a connection that is not yet established. The only purpose used to be to subscribe but that causes many extra syscalls when we know we can do it later. This patch only attempts a read if the connection is established or if there is no write planed, since we want to be certain to be called. And in wake_srv_chk() we continue to attempt to read if the reader was not subscribed, so as to perform the first read attempt. In case a first result is provided, __event_srv_chk_r() will not do anything anyway so this is totally harmless in this case. This fix requires that commit "BUG/MINOR: checks: make __event_chk_srv_r() report success before closing" is applied before, otherwise it will break some checks (notably SSL) by doing them again after the connection is shut down. This completes the fixes on the checks described in issue #253 by roughly cutting the number of syscalls in half. It must be backported to 2.0. (cherry picked from commit c5940392255e5a5a7eb0d27be62e155f1aec26c6) Signed-off-by: Christopher Faulet :04 04 4cd93f8ab452b7092e56620c4a9f7672a3f9cd85 cc618d82eea0b8e421274410c61dc579a68cf7ce M src -- Ionel GARDAIS Tech'Advantage CIO - IT Team manager - Mail original - De: "Lukas Tribus" À: "Ionel GARDAIS" , "haproxy" Envoyé: Dimanche 15 Septembre 2019 20:37:09 Objet: Re: Issue with checks after 2.0.6 Hello, On Sat, Sep 14, 2019 at 4:58 PM GARDAIS Ionel wrote: > > What was the previous release that worked for you? 2.0.5 or something older? > > 2.0.5 worked well from the checks point of vue. Ok, so this is a regression in 2.0.6. Please try whether limiting the threads to 1 (global section: nbthread 1) changes something for you. Also I suggest you file a bug on github: https://github.com/haproxy/haproxy/issues/new/choose Lukas -- 232 avenue Napoleon BONAPARTE 92500 RUEIL MALMAISON Capital EUR 219 300,00 - RCS Nanterre B 408 832 301 - TVA FR 09 408 832 301
Re: Issue with checks after 2.0.6
Same.
I had to disable HTX because I had issues with some corrupted payloads.
I'll give a new try to HTX as 2.0.6 corrects issues with TLS.
--
Ionel GARDAIS
Tech'Advantage CIO - IT Team manager
- Mail original -
De: "Aleksandar Lazic"
À: "Ionel GARDAIS"
Cc: "haproxy"
Envoyé: Samedi 14 Septembre 2019 14:16:30
Objet: Re: Issue with checks after 2.0.6
When you enable htx do you have the same problems?
Comment in `no option http-use-htx`
Regards Aleks
Sat Sep 14 14:12:30 GMT+02:00 2019 GARDAIS Ionel
:
> Also, haproxy and servers are on the same subnet : no filtering nor routing
> between them.
> Ping as no troubles, servers are not overloaded by other connections.
>
> --
> Ionel GARDAIS
> Tech'Advantage CIO - IT Team manager
>
> - Mail original -
> De: "Ionel GARDAIS"
> À: "Aleksandar Lazic"
> Cc: "haproxy"
> Envoyé: Samedi 14 Septembre 2019 14:07:42
> Objet: Re: Issue with checks after 2.0.6
>
> Sure.
> Note : as soon as I remove the check from the server line then 'systemctl
> reload haproxy', access is OK.
>
> # haproxy -vv
> HA-Proxy version 2.0.6-1~bpo9+1 2019/09/14 - https://haproxy.org/
> Build options :
> TARGET = linux-glibc
> CPU = generic
> CC = gcc
> CFLAGS = -O2 -g -O2 -fdebug-prefix-map=/build/haproxy-2.0.6=.
> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
> -D_FORTIFY_SOURCE=2 -fno-strict-aliasing -Wdeclaration-after-statement
> -fwrapv -Wno-unused-label -Wno-sign-compare -Wno-unused-parameter
> -Wno-old-style-declaration -Wno-ignored-qualifiers -Wno-clobbered
> -Wno-missing-field-initializers -Wtype-limits -Wshift-negative-value
> -Wshift-overflow=2 -Wduplicated-cond -Wnull-dereference
> OPTIONS = USE_PCRE2=1 USE_PCRE2_JIT=1 USE_REGPARM=1 USE_OPENSSL=1 USE_LUA=1
> USE_ZLIB=1 USE_SYSTEMD=1
>
> Feature list : +EPOLL -KQUEUE -MY_EPOLL -MY_SPLICE +NETFILTER -PCRE -PCRE_JIT
> +PCRE2 +PCRE2_JIT +POLL -PRIVATE_CACHE +THREAD -PTHREAD_PSHARED +REGPARM
> -STATIC_PCRE -STATIC_PCRE2 +TPROXY +LINUX_TPROXY +LINUX_SPLICE +LIBCRYPT
> +CRYPT_H -VSYSCALL +GETADDRINFO +OPENSSL +LUA +FUTEX +ACCEPT4 -MY_ACCEPT4
> +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=2).
> Built with OpenSSL version : OpenSSL 1.1.0k 28 May 2019
> Running on OpenSSL version : OpenSSL 1.1.0k 28 May 2019
> 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.3
> Built with network namespace support.
> Built with transparent proxy support using: IP_TRANSPARENT IPV6_TRANSPARENT
> IP_FREEBIND
> 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 PCRE2 version : 10.22 2016-07-29
> PCRE2 library supports JIT : yes
> Encrypted password support via crypt(3): yes
> 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)
> h2 : mode=HTXside=FE|BE mux=H2
> h2 : mode=HTTP side=FEmux=H2
> : mode=HTXside=FE|BE mux=H1
> : mode=TCP|HTTP side=FE|BE mux=PASS
>
> Available services :
> prometheus-exporter
>
> Available filters :
> [SPOE] spoe
> [COMP] compression
> [CACHE] cache
> [TRACE] trace
>
>
>
>
>
>
> # cat /etc/haproxy/haproxy.cfg
> global
> log /dev/loglocal0 info
> log /dev/loglocal1 notice
> chroot /var/lib/haproxy
> stats socket /run/haproxy/admin.sock mode 660 level admin expose-fd
> listeners
> stats timeout 30s
> user haproxy
> group haproxy
> daemon
>
> # Default SSL material locations
> ca-base /etc/ssl/certs
> crt-base /etc/ssl/private
>
> # Default ciphers to use on SSL-enabled listening sockets.
> # For more information, see ciphers(1SSL). This list is from:
> # https://hynek.me/articles/hardening-your-web-servers-
Re: Issue with checks after 2.0.6
-2019-chain.crt #capture request header Host len 50 #capture response header Location len 50 #capture request header User-Agent len 50 http-request set-header X-Forwarded-Proto https http-request set-header X-Forwarded-Port 443 http-request set-header X-Forwarded-Host %[ssl_fc_sni] http-response set-header Strict-Transport-Security max-age=31536000;\ includeSubDomains acl secured_cookie res.hdr(Set-Cookie),lower -m sub secure rspirep ^(Set-Cookie:.*) \1;\ Secure unless secured_cookie acl host-tools hdr(host) tools.example.com acl to-etap path_beg /etap use_backend bck-etap if host-tools to-etap backend bck-etap server etap 192.168.1.69:8080 check >From haproxy.log : Sep 14 13:57:35 haproxy-1 haproxy[9978]: Server bck-etap/etap is DOWN, reason: Layer4 timeout, check duration: 2001ms. 0 active and 0 backup servers left. 0 sessions active, 0 dequeued, 0 remaining in queue. Sep 14 13:57:35 haproxy-1 haproxy[9976]: [WARNING] 256/135735 (9978) : Server bck-etap/etap is DOWN, reason: Layer4 timeout, check duration: 2001ms. 0 active and 0 backup servers left. 0 sessions active, 0 dequeued, 0 remaining in queue. Sep 14 13:57:35 haproxy-1 haproxy[9978]: Server bck-etap/etap is DOWN, reason: Layer4 timeout, check duration: 2001ms. 0 active and 0 backup servers left. 0 sessions active, 0 dequeued, 0 remaining in queue. Sep 14 13:57:35 haproxy-1 haproxy[9978]: backend bck-etap has no server available! Sep 14 13:57:35 haproxy-1 haproxy[9978]: backend bck-etap has no server available! Sep 14 13:57:35 haproxy-1 haproxy[9976]: [ALERT] 256/135735 (9978) : backend 'bck-etap' has no server available! Sep 14 13:58:16 haproxy-1 haproxy[9978]: 172.17.10.1:51523 [14/Sep/2019:13:58:16.024] ssl~ bck-etap/ 0/-1/-1/-1/0 503 213 - - SC-- 16/15/0/0/0 0/0 "GET /etap/ HTTP/1.1" ^C -- Ionel GARDAIS Tech'Advantage CIO - IT Team manager - Mail original - De: "Aleksandar Lazic" À: "Ionel GARDAIS" , "haproxy" Envoyé: Samedi 14 Septembre 2019 13:12:49 Objet: Re: Issue with checks after 2.0.6 Hi. Am 14.09.2019 um 13:08 schrieb GARDAIS Ionel: > Hi, > > I've just upgraded to 2.0.6 and all server checks went erratic. > I had to disable checks for the servers to be reachable. > > The observed behavior was a flip-flap (but mostly down) of server availability > with L4TOUT when the server was considered unresponsive. Please can you share some more informations like some configs and log lines. > Ionel Best regards Aleks -- 232 avenue Napoleon BONAPARTE 92500 RUEIL MALMAISON Capital EUR 219 300,00 - RCS Nanterre B 408 832 301 - TVA FR 09 408 832 301 -- 232 avenue Napoleon BONAPARTE 92500 RUEIL MALMAISON Capital EUR 219 300,00 - RCS Nanterre B 408 832 301 - TVA FR 09 408 832 301
Re: Issue with checks after 2.0.6
_cookie res.hdr(Set-Cookie),lower -m sub secure rspirep ^(Set-Cookie:.*) \1;\ Secure unless secured_cookie acl host-tools hdr(host) tools.example.com acl to-etap path_beg /etap use_backend bck-etap if host-tools to-etap backend bck-etap server etap 192.168.1.69:8080 check >From haproxy.log : Sep 14 13:57:35 haproxy-1 haproxy[9978]: Server bck-etap/etap is DOWN, reason: Layer4 timeout, check duration: 2001ms. 0 active and 0 backup servers left. 0 sessions active, 0 dequeued, 0 remaining in queue. Sep 14 13:57:35 haproxy-1 haproxy[9976]: [WARNING] 256/135735 (9978) : Server bck-etap/etap is DOWN, reason: Layer4 timeout, check duration: 2001ms. 0 active and 0 backup servers left. 0 sessions active, 0 dequeued, 0 remaining in queue. Sep 14 13:57:35 haproxy-1 haproxy[9978]: Server bck-etap/etap is DOWN, reason: Layer4 timeout, check duration: 2001ms. 0 active and 0 backup servers left. 0 sessions active, 0 dequeued, 0 remaining in queue. Sep 14 13:57:35 haproxy-1 haproxy[9978]: backend bck-etap has no server available! Sep 14 13:57:35 haproxy-1 haproxy[9978]: backend bck-etap has no server available! Sep 14 13:57:35 haproxy-1 haproxy[9976]: [ALERT] 256/135735 (9978) : backend 'bck-etap' has no server available! Sep 14 13:58:16 haproxy-1 haproxy[9978]: 172.17.10.1:51523 [14/Sep/2019:13:58:16.024] ssl~ bck-etap/ 0/-1/-1/-1/0 503 213 - - SC-- 16/15/0/0/0 0/0 "GET /etap/ HTTP/1.1" ^C -- Ionel GARDAIS Tech'Advantage CIO - IT Team manager - Mail original - De: "Aleksandar Lazic" À: "Ionel GARDAIS" , "haproxy" Envoyé: Samedi 14 Septembre 2019 13:12:49 Objet: Re: Issue with checks after 2.0.6 Hi. Am 14.09.2019 um 13:08 schrieb GARDAIS Ionel: > Hi, > > I've just upgraded to 2.0.6 and all server checks went erratic. > I had to disable checks for the servers to be reachable. > > The observed behavior was a flip-flap (but mostly down) of server availability > with L4TOUT when the server was considered unresponsive. Please can you share some more informations like some configs and log lines. > Ionel Best regards Aleks -- 232 avenue Napoleon BONAPARTE 92500 RUEIL MALMAISON Capital EUR 219 300,00 - RCS Nanterre B 408 832 301 - TVA FR 09 408 832 301
Re: Coverity scan findings
it depends on how haproxy is built (number of flags) BQ_BEGIN we use most of available options when testing on coverity [ https://github.com/haproxy/haproxy/blob/master/.travis.yml#L8 | https://github.com/haproxy/haproxy/blob/master/.travis.yml#L8 ] can you share build command ? we may also set up sonar in travis-ci schedules. (personally, I find sonar too much noisy, but I agree, it finds bugs sometimes) BQ_END I'm using $ make -j4 TARGET=linux-glibc USE_LIBCRYPT=1 USE_OPENSSL=1 USE_ZLIB=1 USE_NS= The shortest command from the travis file is $ make -j4 TARGET=linux-glibc USE_ZLIB=1 USE_PCRE=1 USE_OPENSSL=1 USE_WURFL=1 WURFL_INC=contrib/wurfl WURFL_LIB=contrib/wurfl USE_DEVICEATLAS=1 DEVICEATLAS_SRC=contrib/deviceatlas USE_NS= I'm using CentOS 6 to build. As Willy says, it generates lots of false-positive because static analysis of pointer-work is hard, especially in C. Most of C smart moves are interpreted as wrong behavior. -- 232 avenue Napoleon BONAPARTE 92500 RUEIL MALMAISON Capital EUR 219 300,00 - RCS Nanterre B 408 832 301 - TVA FR 09 408 832 301
Re: Coverity scan findings
> On Tue, Sep 10, 2019 at 08:29:38PM +0500, ??? wrote: > > those findings are mostly mess (maybe, except few real bugs). > > I do not mind sharing those findings with community, Willy ? > > we need more manpower here. > > Oh no problem! I'm not the one asking to hide bugs, the more eyeballs > on bug reports, the faster these ones will be sorted out! Also if one > fears that this could help a black hat guy find a vulnerability and > exploit it, mind you that these people already spend time scanning the > same code (with and without tools) and spot bugs in advance without > relying on our public reports anyway. Please note that Sonarqube is scanning haproxy code too. Results are available at https://sonarcloud.io/dashboard?id=haproxy Some results are false positive but some are worth looking at. -- 232 avenue Napoleon BONAPARTE 92500 RUEIL MALMAISON Capital EUR 219 300,00 - RCS Nanterre B 408 832 301 - TVA FR 09 408 832 301
Re: HA-Proxy version 1.8.13 2018/07/30.
Hi Leonardo, What are you trying to achieve ? What is your current setup ? -- Ionel GARDAIS Tech'Advantage CIO - IT Team manager De: "BISSOLI Leonardo" À: "haproxy" Envoyé: Vendredi 30 Août 2019 17:05:57 Objet: HA-Proxy version 1.8.13 2018/07/30. Hi All. My name is Leonardo Bissoli and we’re working in a project that use HAProxy. We can successfully deploy 2 Load Balance Servers with 2 Web Servers the only issue that we’re facing is when we reboot the Load Balance Server (the page couldn’t be reached anymore) but there is no error in the HAProxy. Do you have any cue where I can start do search? I’ve tried forums, manual etc but we couldn’t find yet the reason that stop to work after the reboot. If we reboot the Web Servers there is no issue, all back to work as usual. The problem is only when we reboot the LB Servers. Using curl is working as well curl [ http://localhost:7025/helloworld/hi.jsp | http://localhost:7025/helloworld/hi.jsp ] JSP Test Hello, World. This is from Web Server 02 Fri Aug 30 14:57:52 UTC 2019 curl [ http://localhost:7025/helloworld/hi.jsp | http://localhost:7025/helloworld/hi.jsp ] JSP Test Hello, World. This is from Web Server 01 Fri Aug 30 14:57:57 UTC 2019 Thank you. Best Regards, Leonardo Bissoli QUMAS SW Dev & Cloud Office: +353 2 1491 5106 [ mailto:leonardo.biss...@3ds.com | leonardo.biss...@3ds.com ] [ http://www.3ds.com/ENOVIA | 3DS.COM/ENOVIA ] Dassault Systemes Limited | Phoenix House | Monahan Rd | Cork | Ireland This email and any attachments are intended solely for the use of the individual or entity to whom it is addressed and may be confidential and/or privileged. If you are not one of the named recipients or have received this email in error, (i) you should not read, disclose, or copy it, (ii) please notify sender of your receipt by reply email and delete this email and all attachments, (iii) Dassault Systèmes does not accept or assume any liability or responsibility for any use of or reliance on this email. Please be informed that your personal data are processed according to our data privacy policy as described on our website. Should you have any questions related to personal data protection, please contact 3DS Data Protection Officer at [ mailto:3ds.compliance-priv...@3ds.com | 3ds.compliance-priv...@3ds.com ] For other languages, go to https://www.3ds.com/terms/email-disclaimer -- 232 avenue Napoleon BONAPARTE 92500 RUEIL MALMAISON Capital EUR 219 300,00 - RCS Nanterre B 408 832 301 - TVA FR 09 408 832 301
Debugging protobuf and HTX
Hi list, We ran into an issue with haproxy 2.0.1 in front of SonarQube. With HTX enabled, despite no errors being displayed either in haproxy nor SonarQube, some but not all analysis failed. >From SonarQube, debug shows protobuf requests >(/sonarqube/api/rules/list.protobuf) failing and fallbacking to default, or >complete failure if no default available. When switching back to 'no option http-use-htx', protobuf requests' answers did not had the same size and no more issues with SonarQube. How could I specifically debug protobuf handling with HTX enabled ? Thanks, Ionel -- 232 avenue Napoleon BONAPARTE 92500 RUEIL MALMAISON Capital EUR 219 300,00 - RCS Nanterre B 408 832 301 - TVA FR 09 408 832 301
