The only place tcp-request appears in my config is in relation to
rate-limiting, which we have set up to track but not enforce. Here are the
associated rules:
frontend main
[...]
acl rate_whitelist src 10.0.0.1
acl rate_whitelist src 10.0.1.1
acl rate_whitelist src 10.0.1.2
acl rate_whitelist src 10.0.1.3
acl rate_whitelist src 10.0.1.4
stick-table type ip size 200k expire 60s store gpc0
tcp-request connection track-sc0 src if ! rate_whitelist
#use_backend throttled if { sc0_get_gpc0 gt 0 }
backend www
[...]
stick-table type ip size 200k expire 1m store http_req_rate(30s)
acl abuse_req_rate sc1_http_req_rate gt 1000
acl mark_as_abuser sc0_inc_gpc0(main) gt 0
tcp-request content track-sc1 src
tcp-request content reject if abuse_req_rate mark_as_abuser
Here's a pastebin of the full config:
https://paste.ubuntu.com/p/nM6xq4Vp2z/
Thanks!
On Tue, Mar 17, 2020 at 1:24 AM Christopher Faulet <[email protected]>
wrote:
> Le 06/03/2020 à 18:53, Sean Reifschneider a écrit :
> > Here's what the stack traces look like, they all seem to be showing
> > "pattern_exec_match" and "epool_wait":
> >
> > PID: 14348 (haproxy)
> > UID: 0 (root)
> > GID: 0 (root)
> > Signal: 11 (SEGV)
> > Timestamp: Thu 2020-03-05 19:59:05 MST (14h ago)
> > Command Line: /usr/sbin/haproxy -Ws -f /etc/haproxy/haproxy.cfg -p
> > /run/haproxy.pid -S /run/haproxy-master.sock
> > Executable: /usr/sbin/haproxy
> > Control Group: /system.slice/haproxy.service
> > Unit: haproxy.service
> > Slice: system.slice
> > Boot ID: 847e3549533c4b9b970c6ec86776621d
> > Machine ID: 90c4e8de95634bd898f918ea24b07374
> > Hostname: fw1
> > Storage:
> >
> /var/lib/systemd/coredump/core.haproxy.0.847e3549533c4b9b970c6ec86776621d.14348.1583463545000000.lz4
> > Message: Process 14348 (haproxy) of user 0 dumped core.
> >
> > Stack trace of thread 14349:
> > #0 0x0000564a9deaed08 pattern_exec_match (haproxy)
> > #1 0x0000564a9dee8eda acl_exec_cond (haproxy)
> > #2 0x0000564a9ded9848 tcp_exec_l4_rules (haproxy)
> > #3 0x0000564a9decfe24 session_accept_fd (haproxy)
> > #4 0x0000564a9debab44 n/a (haproxy)
> > #5 0x0000564a9dedc88e process_runnable_tasks (haproxy)
> > #6 0x0000564a9de87dd2 n/a (haproxy)
> > #7 0x00007f0f0de6a6db start_thread (libpthread.so.0)
> > #8 0x00007f0f0c8de88f __clone (libc.so.6)
> >
> > Stack trace of thread 14348:
> > #0 0x00007f0f0c8debb7 epoll_wait (libc.so.6)
> > #1 0x0000564a9dda7cef n/a (haproxy)
> > #2 0x0000564a9de87dbf n/a (haproxy)
> > #3 0x0000564a9dda5a4e main (haproxy)
> > #4 0x00007f0f0c7deb97 __libc_start_main (libc.so.6)
> > #5 0x0000564a9dda672a _start (haproxy)
> >
> > I have a bunch of ACLs to select the backend based on the host header,
> like:
> >
> > acl sitedown_stg_acl hdr(host) -m reg -i ^sitedown.example.com
> > <http://sitedown.example.com>
> > use_backend sitedown_stg if sitedown_stg_acl
> >
> > I'm not seeing anything particularly weird about those, the most
> complicated is
> > probably:
> >
> > acl aerial_acl hdr(host) -m reg -i ^aerial[1-4].(dev|stg).
> example.com
> > <http://example.com>
> > use_backend aerial if aerial_acl
> >
> > Thoughts?
> >
>
> Hi,
>
> If the segfault happens during execution of L4 rules, it means the faulty
> acl is
> on a "tcp-request connection" rule, not on use_backend directive. Could
> you
> share this part of your configuration ?
>
> --
> Christopher Faulet
>
