Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    sonewconn: pcb Listen queue overflow

    General pfSense Questions
    3
    5
    4.3k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • S
      sloppymike
      last edited by

      Hi,

      we see following error messages in the systems log

      sonewconn: pcb 0xfffff8014de53498: Listen queue overflow: 193 already in queue awaiting acceptance (107 occurrences)
      

      and tried to identify the process following https://blog.tyk.nu/blog/fun-with-freebsd-listen-queue-overflow/ but

       netstat -Aan | grep 8014de53498
      

      gives no result. Is there another way to trace the error?

      cheers,

      mike

      R 1 Reply Last reply Reply Quote 0
      • stephenw10S
        stephenw10 Netgate Administrator
        last edited by

        Usually that is the result of some package, are you running any packages?

        You might try have to try that very shortly after seeing the error. You could also try using the -L switch to see which queues are largest before you actually hit the limit.

        Steve

        1 Reply Last reply Reply Quote 0
        • S
          sloppymike
          last edited by sloppymike

          Yes we run

          haproxy
          openvpn
          pfBlockerNG 2.1.1_8
          zabbix-agent

          We see connection drops for webservices behind haproxy and while investigating we found these log entries. From my understanding i don't find the pcb id because the process does not exist anymore so it can not be haproxy as it has a long uptime, right?

          I found some issues regarding pfBlockerNG and as it seems to restart it might is the cause

          0_1544555942889_3b4c39d6-b75b-4ae5-af2e-ecf4e4b36777-image.png

          Furthermore i try to find out what kind of limit we hit. Sockets? Networkcard? and can pgBlocker be the reason for connection drops of haproxy services?

          Cheers,

          Mike

          1 Reply Last reply Reply Quote 0
          • stephenw10S
            stephenw10 Netgate Administrator
            last edited by

            It's probably connections coming in faster than HAProxy can service them. Once the queue values is exhausted it starts throwing that error.

            You can increase that value quite substantially without a problem but it may just delay the problem.

            Set a system tunable kern.ipc.soacceptqueue to something larger that the default 128. Try 512.

            See if that eliminates the error or simply delays it's appearance.

            Steve

            1 Reply Last reply Reply Quote 0
            • R
              Redy321 Banned @sloppymike
              last edited by

              This post is deleted!
              1 Reply Last reply Reply Quote 0
              • First post
                Last post
              Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.