From owner-freebsd-questions@FreeBSD.ORG Sun Sep 14 19:32:28 2014 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2EEFF605 for ; Sun, 14 Sep 2014 19:32:28 +0000 (UTC) Received: from mail.tivas.info (85.234.217.139.static.edpnet.net [85.234.217.139]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8BDE8D32 for ; Sun, 14 Sep 2014 19:32:26 +0000 (UTC) Received: from localhost.localdomain ([192.168.3.104]) by mail.tivas.info (8.14.4/8.14.4) with ESMTP id s8EJRaHU015226 for ; Sun, 14 Sep 2014 21:27:36 +0200 (CEST) (envelope-from bram@diomedia.be) Message-ID: <5415EC27.40708@diomedia.be> Date: Sun, 14 Sep 2014 21:27:35 +0200 From: Bram Van Steenlandt User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: freebsd-questions@freebsd.org Subject: Listen queue guestion Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Sep 2014 19:32:28 -0000 Hi, I'm porting an plc automation system to freebsd and while doing so I got errors like these: sonewconn: pcb 0xfffff8000cecc870: Listen queue overflow: 76 already in queue awaiting acceptance With the help of netstat I've found the problem, 2 programs communicate with ipc file like sockets and the "client" was connecting too fast (it was connecting and disconnecting in a small for loop). Still, on linux this worked and there will be cases where I may bump in to this limit again (a lot of different programs communicate with one master program over ipc). I've found kern.ipc.somaxconn but this seems to be only for TCP connections. Is there a sysctl or kernel parameter that allows me to set this queue a bit larger ? Thx Bram