Date: Wed, 10 Jan 2018 13:43:56 +0100 From: Thomas Steen Rasmussen <thomas@gibfest.dk> To: freebsd-net@freebsd.org Subject: Help finding a pcb id Message-ID: <84c785a2-cf14-3921-797b-6e4157566f3b@gibfest.dk>
next in thread | raw e-mail | index | archive | help
Hello list, I have a jailhost with a busy TCP service which sometimes cannot keep up, triggering the usual "listen queue overflow" messages most of you will have seen at some point: kernel: sonewconn: pcb 0xfffff803f327a1d0: Listen queue overflow: 193 already in queue awaiting acceptance (1169 occurrences) kernel: sonewconn: pcb 0xfffff8031b131740: Listen queue overflow: 193 already in queue awaiting acceptance (1068 occurrences) These two pcb id's are repeating warnings: $ cat /var/log/messages | cut -w -f 8 | sort | uniq -c  142 0xfffff8031b131740:  483 0xfffff803f327a1d0: Through elimination I know which two listening TCP ports/services are causing the warnings. But I can't get the pcb id to match. Usually I would find the listening socket with netstat -Aan but the listening sockets causing these warnings have different pcb ids in the netstat output: fffff80319ff5000 tcp4      0     0 185.96.180.29.9091 *.*               LISTEN fffff80319e19410 tcp4      0     0 185.96.180.29.9090 *.*               LISTEN What am I missing? What is the correct way to match the pcb id from messages to a process/listening socket? Could this be because of these pf rdr rules? Does a pf rdr create a new pcb id which is "invisible" to netstat? rdr on $if inet proto tcp from any to $tor6v4 port 443 -> $tor6v4 port 9090 rdr on $if inet proto tcp from any to $tor6v4 port 80 -> $tor6v4 port 9091 On a more general note I am wondering is if it would be possible to log some more info from the socket around line 600 of sys/kern/uipc_socket.c? Local (and remote where relevant) address/port/or whatever relevant for the protocol, and perhaps also pid and jid? More info would make things a lot easier on busy jailhosts :) The cause of "listen queue overflow" messages can be almost impossible to find if the process/socket is short-lived. Thank you in advance for any input! Best regards, Thomas Steen Rasmussen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?84c785a2-cf14-3921-797b-6e4157566f3b>