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

Reply via email to