On Wed, Mar 27, 2024 at 02:26:47PM -0300, Ricardo Nabinger Sanchez wrote: > On Wed, 27 Mar 2024 11:06:39 -0300 > Felipe Wilhelms Damasio <felip...@taghos.com.br> wrote: > > > kernel: traps: haproxy[2057993] trap invalid opcode ip:5b3e26 > > sp:7fd7c002f100 error:0 in haproxy[42c000+1f7000] > > We managed to get a core file, and so created ticket #2508 > (https://github.com/haproxy/haproxy/issues/2508) with more details.
Thanks guys! So there seems to be an annoying bug. However I'm not sure how this is related to your "connection refused", except if you try to connect at the moment the process crashes and restarts, of course. I'm seeing that the bug here is stktable_requeue_exp() calling task_queue() with an invalid task expiration. I'm having a look now. I'll respond in the issue with what I can find, thanks for your report. Since you were speaking about FD count and maxconn at 900k, please let me take this opportunity for a few extra sanity checks. By default we assign up to about 50% of the FD to pipes (i.e. up to 25% pipes compared to connections), so if maxconn is 900k you can reach 1800 + 900 = 2700k FD. One thing to keep in mind is that /proc/sys/fs/nr_open sets a per-process hard limit and usually is set to 1M, and that /proc/sys/fs/file-max sets a system-wide limit and depends on the amount of RAM, so both may interact with such a large setting. We could for example imagine that at ~256k connections with as many pipes you're reaching around 1M FDs and that the connection from socat to the CLI socket cannot be accepted and is rejected. Since you recently updated your kernel, it might be worth checking if the default values are still in line with your usage. Cheers, Willy
