On 12/16/16 at 11:20P, Andrey V. Elsukov wrote:
> On 15.12.2016 20:51, hiren panchasara wrote:
> > 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
On 15.12.2016 20:51, hiren panchasara wrote:
> 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 awai
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 0xfffff80373aec000: Listen queue overflow: 49 already in
> queue awaiting acceptance (6 occurrences)
[skip]
>
> but at the time of investigati
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
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 kern
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 tha
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 "netst
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
On Thu, Oct 29, 2015, at 16:46, Zara Kanaeva wrote:
> Hello Дмитрий,
>
> thank you very much for your message.
>
> First of all: I like FreeBSD (the installation logic, the good
> documentation etc.), this is why I use FreeBSD as Server OS. But in my
> case I must desagree your strong theoret
s:
1. Re: Stuck processes in unkillable (STOP) state, listen queue
overflow (Zara Kanaeva)
2. Re: Stuck processes in unkillable (STOP) state, listen queue
overflow (Nagy, Attila)
--
Message: 1
Date: Tue, 27 Oct 2015 14:4
t
>freebsd-stable-ow...@freebsd.org
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of freebsd-stable digest..."
>
>
>Today's Topics:
>
> 1. Re: Stuck processes in unkillable (STOP) state, listen queue
>
ame machine and FREEBSD 9.0 RELEASE
on it (I am not 100% sure, I have yet no possibility to test it).
Regards, Z. Kanaeva.
Zitat von "Nagy, Attila" :
Hi,
Recently I've started to see a lot of cases, where the log is full
with "listen queue overflow" messages and t
here the log is full
with "listen queue overflow" messages and the process behind the
network socket is unavailable.
When I open a TCP to it, it opens but nothing happens (for example I
get no SMTP banner from postfix, nor I get a log entry about the new
connection).
I've se
Hi,
Recently I've started to see a lot of cases, where the log is full with
"listen queue overflow" messages and the process behind the network
socket is unavailable.
When I open a TCP to it, it opens but nothing happens (for example I get
no SMTP banner from postfix, nor I
001ac76930: Listen queue overflow: 8 already in
> queue awaiting acceptance
> sonewconn: pcb 0xfe001ac76930: Listen queue overflow: 8 already in
> queue awaiting acceptance
> sonewconn: pcb 0xfe001ac76930: Listen queue overflow: 8 already in
> queue awaiting acceptance
> sonew
On 2013-09-30 10:43 PM, Mark Andrews wrote:
Use "netstat -nAa" to match the reported pcb (protocol control
block) to the IP address and port. Then use that to work out which
daemon is not keeping up.
Thanks Mark, duckduckgo has failed me :( I found this info with google
later, guess I'll ju
on this error message. Things appear to be working OK
> so far.
>
> Sep 30 22:08:56 illidan kernel: sonewconn: pcb 0xfffffe00c7223498:
> Listen queue overflow: 193 already in queue awaiting acceptance
> Sep 30 22:12:27 illidan kernel: sonewconn: pcb 0xfe00c7223498:
> List
0xfe00c7223498:
Listen queue overflow: 193 already in queue awaiting acceptance
Sep 30 22:12:27 illidan kernel: sonewconn: pcb 0xfe00c7223498:
Listen queue overflow: 193 already in queue awaiting acceptance
Thanks!
___
freebsd-stable@freebsd.org mailing
gt; sonewconn: pcb 0xfe001ac76930: Listen queue overflow: 8 already in
> queue awaiting acceptance
> sonewconn: pcb 0xfe001ac76930: Listen queue overflow: 8 already in
> queue awaiting acceptance
> sonewconn: pcb 0xfe001ac76930: Listen queue overflow: 8 already in
> queue awa
appened after r253035 ?
>>
>>
>> sonewconn: pcb 0xfe001ac76930: Listen queue overflow: 8 already in
>> queue awaiting acceptance
>
> This message tells you that your daemon listening on that protocol control
> block isn't keeping up with accepting new messages and
On 01.08.2013 16:47, Mike Tancsa wrote:
After upgrading from a RELENG9 kernel from June 18th to July 27th, I am
seeing this odd new message. Is this a new bug, or just a new
diagnostic message ? I am guessing it happened after r253035 ?
sonewconn: pcb 0xfe001ac76930: Listen queue overflow
After upgrading from a RELENG9 kernel from June 18th to July 27th, I am
seeing this odd new message. Is this a new bug, or just a new
diagnostic message ? I am guessing it happened after r253035 ?
sonewconn: pcb 0xfe001ac76930: Listen queue overflow: 8 already in
queue awaiting acceptance
22 matches
Mail list logo
