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>