sonewconn: pcb [...]: Listen queue overflow to human-readable form
Hi. Sometimes on one of my servers I got dmesg full of sonewconn: pcb 0xf80373aec000: Listen queue overflow: 49 already in queue awaiting acceptance (6 occurrences) sonewconn: pcb 0xf80373aec000: Listen queue overflow: 49 already in queue awaiting acceptance (2 occurrences) sonewconn: pcb 0xf80373aec000: Listen queue overflow: 49 already in queue awaiting acceptance (1 occurrences) sonewconn: pcb 0xf80373aec000: Listen queue overflow: 49 already in queue awaiting acceptance (15 occurrences) sonewconn: pcb 0xf80373aec000: Listen queue overflow: 49 already in queue awaiting acceptance (12 occurrences) sonewconn: pcb 0xf80373aec000: Listen queue overflow: 49 already in queue awaiting acceptance (10 occurrences) sonewconn: pcb 0xf80373aec000: Listen queue overflow: 49 already in queue awaiting acceptance (16 occurrences) sonewconn: pcb 0xf80373aec000: Listen queue overflow: 49 already in queue awaiting acceptance (16 occurrences) sonewconn: pcb 0xf80373aec000: Listen queue overflow: 49 already in queue awaiting acceptance (22 occurrences) sonewconn: pcb 0xf80373aec000: Listen queue overflow: 49 already in queue awaiting acceptance (6 occurrences) sonewconn: pcb 0xf80373aec000: Listen queue overflow: 49 already in queue awaiting acceptance (6 occurrences) sonewconn: pcb 0xf80373aec000: Listen queue overflow: 49 already in queue awaiting acceptance (1 occurrences) sonewconn: pcb 0xf80373aec000: Listen queue overflow: 49 already in queue awaiting acceptance (9 occurrences) sonewconn: pcb 0xf80373aec000: Listen queue overflow: 49 already in queue awaiting acceptance (5 occurrences) sonewconn: pcb 0xf80373aec000: Listen queue overflow: 49 already in queue awaiting acceptance (18 occurrences) sonewconn: pcb 0xf80373aec000: Listen queue overflow: 49 already in queue awaiting acceptance (4 occurrences) but at the time of investigation the socket is already closed and lsof cannot show me the owner. I wonder if the kernel can itself decode this output and write it in the human-readable form ? Thanks. Eugene. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: sonewconn: pcb [...]: Listen queue overflow to human-readable form
On 15.12.2016 19:23, Eugene M. Zheganin wrote: > but at the time of investigation the socket is already closed and lsof > cannot show me the owner. I wonder if the kernel can itself decode this > output and write it in the human-readable form ? Until that's not implemented, you can monitor "netstat -Lan" output and continuously save it for later analisys and/or draw graphs. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: CVE-2016-7434 NTP
Xin LI wrote: We plan to issue an EN to update the base system ntp to 4.2.8p9. The high impact issue is Windows only by the way. I don't think I'm even impacted - but $security team are going nuts about getting patched on all systems :/ Michelle ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: sonewconn: pcb [...]: Listen queue overflow to human-readable form
2016-12-15 14:28, Eugene Grosbein написав: On 15.12.2016 19:23, Eugene M. Zheganin wrote: but at the time of investigation the socket is already closed and lsof cannot show me the owner. I wonder if the kernel can itself decode this output and write it in the human-readable form ? Until that's not implemented, you can monitor "netstat -Lan" output and continuously save it for later analisys and/or draw graphs. netstat -LanA -f inet ? ___ freebsd-...@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" -- Regards! ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: sonewconn: pcb [...]: Listen queue overflow to human-readable form
On Thu, Dec 15, 2016 at 05:27:02PM +0200, Artem Viklenko wrote: > 2016-12-15 14:28, Eugene Grosbein ??: > > On 15.12.2016 19:23, Eugene M. Zheganin wrote: > > > >> but at the time of investigation the socket is already closed and lsof > >> cannot show me the owner. I wonder if the kernel can itself decode > >> this > >> output and write it in the human-readable form ? > > > > Until that's not implemented, you can monitor "netstat -Lan" output and > > continuously save it for later analisys and/or draw graphs. > > > > netstat -LanA -f inet ? That's only IPv4 sockets (or sockets that are listening on both families at the same time). If you are dual stack with IPv6, you'd probably also need to capture netstat -LanA -f inet6 Regards, Gary ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Vestibular SENAI 2017/1 - Oportunidade de 50% de desconto no 1º semestre para ex-aluno SENAI
___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: sonewconn: pcb [...]: Listen queue overflow to human-readable form
2016-12-15 18:05, Gary Palmer написав: On Thu, Dec 15, 2016 at 05:27:02PM +0200, Artem Viklenko wrote: 2016-12-15 14:28, Eugene Grosbein ??: > On 15.12.2016 19:23, Eugene M. Zheganin wrote: > >> but at the time of investigation the socket is already closed and lsof >> cannot show me the owner. I wonder if the kernel can itself decode >> this >> output and write it in the human-readable form ? > > Until that's not implemented, you can monitor "netstat -Lan" output and > continuously save it for later analisys and/or draw graphs. > netstat -LanA -f inet ? That's only IPv4 sockets (or sockets that are listening on both families at the same time). If you are dual stack with IPv6, you'd probably also need to capture netstat -LanA -f inet6 Sure, the point was that -A flag showes tcb addresses. :) Regards, Gary -- Regards! ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: sonewconn: pcb [...]: Listen queue overflow to human-readable form
On 12/15/16 at 05:23P, Eugene M. Zheganin wrote: > Hi. > > Sometimes on one of my servers I got dmesg full of > > sonewconn: pcb 0xf80373aec000: Listen queue overflow: 49 already in > queue awaiting acceptance (6 occurrences) [skip] > > but at the time of investigation the socket is already closed and lsof > cannot show me the owner. I wonder if the kernel can itself decode this > output and write it in the human-readable form ? I have this not-quite-correct patch that may help you. (If you follow the discussion there, you'd know why its not complete.) https://lists.freebsd.org/pipermail/freebsd-net/2014-March/038074.html Cheers, Hiren pgps4v8nv8jEZ.pgp Description: PGP signature
Re: broken source upgrade 9.3-STABLE to 10.3-STABLE
On Wed, 14 Dec 2016 08:27:13 +0100, Eugene Grosbein wrote: Hi! I've got legacy FreeBSD server running 8.4-STABLE and I'm trying to upgrade it. Source upgrade for 8.4 to 9.3-STABLE r310015 went flawlessly. After reboot, I checked out stable/10 r310043 sources and ran buildworld again. It fails: ===> lib/clang/libllvmanalysis (all) c++ -O2 -pipe -I/usr/src/lib/clang/libllvmanalysis/../../../contrib/llvm/include -I/usr/src/lib/clang/libllvmanalysis/../../../contrib/llvm/tools/clang/include -I/usr/src/lib/clang/libllvmanalysis/../../../contrib/llvm/lib/Analysis -I. -I/usr/src/lib/clang/libllvmanalysis/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNDEBUG -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd10.3\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd10.3\" -DDEFAULT_SYSROOT=\"/usr/obj/usr/src/tmp\" -I/usr/obj/usr/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /usr/src/lib/clang/libllvmanalysis/../../../contrib/llvm/lib/Analysis/LazyValueInfo.cpp -o LazyValueInfo.o /usr/src/lib/clang/libllvmanalysis/../../../contrib/llvm/lib/Analysis/LazyValueInfo.cpp: In member function 'llvm::Constant* llvm::LazyValueInfo::getConstant(llvm::Value*, llvm::BasicBlock*)': /usr/src/lib/clang/libllvmanalysis/../../../contrib/llvm/lib/Analysis/LazyValueInfo.cpp:1054: error: 'nullptr' was not declared in this scope *** Error code 1 Does it mean that FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 is unable to build more recent clang version? Check /usr/src/UPDATING: 20141231: Clang, llvm and lldb have been upgraded to 3.5.0 release. As of this release, a prerequisite for building clang, llvm and lldb is a C++11 capable compiler and C++11 standard library. This means that to be able to successfully build the cross-tools stage of buildworld, with clang as the bootstrap compiler, your system compiler or cross compiler should either be clang 3.3 or later, or gcc 4.8 or later, and your system C++ library should be libc++, or libdstdc++ from gcc 4.8 or later. On any standard FreeBSD 10.x or 11.x installation, where clang and libc++ are on by default (that is, on x86 or arm), this should work out of the box. On 9.x installations where clang is enabled by default, e.g. on x86 and powerpc, libc++ will not be enabled by default, so libc++ should be built (with clang) and installed first. If both clang and libc++ are missing, build clang first, then use it to build libc++. On 8.x and earlier installations, upgrade to 9.x first, and then follow the instructions for 9.x above. Regards, Ronald. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
