Date: Tue, 12 Nov 2013 12:06:27 +0100 From: Kristof Provost <kristof@sigsegv.be> To: Kai Gallasch <k@free.de> Cc: Mike Jakubik <mike.jakubik@intertainservices.com>, stable@freebsd.org Subject: Re: sonewconn: pcb 0xfffffe00c7223498: Listen queue overflow Message-ID: <20131112110627.GO58987@vega.codepro.be> In-Reply-To: <13DA2D84-38CE-4E70-B7E8-1A6780B8B0A4@free.de> References: <798639e66426509cd53d1f2a1c1d58e0@intertainservices.com> <20131001024308.89D557AEDA0@rock.dv.isc.org> <13DA2D84-38CE-4E70-B7E8-1A6780B8B0A4@free.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2013-11-12 09:53:15 (+0100), Kai Gallasch <k@free.de> wrote: > I also have quite a lot of this "Listen queue overflow" in the kernel > messages on a 9.2-STABLE (r257053) and I tried to identify the > listening processes with filled up listen queue with netstat. I tried > both "netstat -nAa | grep $pcb" and "netstat -Lan" but found no match > with the pcb. > > Problem seems to be that there are server processes that dynamically > fork child processes that do the listening and are only active for a > short time. > > Now I wonder if there is a nifty solution for this besides running a > watchdog script every minute that scans the kernel.msg for "Listen > queue overflow" and does the trick to find out the pid/process/jid of > the connected process. > I've also seen this happen on my box. I'll test the following dtrace bit, to see if I get any useful feedback out of it. dtrace -n ::sonewconn:return'/args[1] == NULL/ { print("sonewconn returned NULL"); printf("user stack %s (%d)", execname, pid); ustack(); print("Kernel stack"); stack(); }' Regards, Kristof
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20131112110627.GO58987>