queue overflow message

circus78

Active Member

Thanks: 4
Messages: 182

#1
Hi,
I am using FreeBSD 11.1-RELEASE-p8 (amd64).
I manage a mail server with large number of users.
Basically it is a mail server with: postfix, dovecot, nginx, php-fpm.
Since few days, webmail becomes unresponsive, and I see this in dmesg output:

Code:
Limiting closed port RST response from 233 to 200 packets/sec
sonewconn: pcb 0xfffff802e2f6c3a0: Listen queue overflow: 151 already in queue awaiting acceptance (159 occurrences)
sonewconn: pcb 0xfffff802e2f6c3a0: Listen queue overflow: 151 already in queue awaiting acceptance (19 occurrences)
sonewconn: pcb 0xfffff802e2f6c3a0: Listen queue overflow: 151 already in queue awaiting acceptance (50 occurrences)
sonewconn: pcb 0xfffff802e2f6c3a0: Listen queue overflow: 151 already in queue awaiting acceptance (146 occurrences)
sonewconn: pcb 0xfffff802e2f6c3a0: Listen queue overflow: 151 already in queue awaiting acceptance (2 occurrences)
sonewconn: pcb 0xfffff802e2f6c3a0: Listen queue overflow: 151 already in queue awaiting acceptance (32 occurrences)
sonewconn: pcb 0xfffff802e2f6c3a0: Listen queue overflow: 151 already in queue awaiting acceptance (8 occurrences)
sonewconn: pcb 0xfffff802e2f6c3a0: Listen queue overflow: 151 already in queue awaiting acceptance (48 occurrences)
sonewconn: pcb 0xfffff802e2f6c3a0: Listen queue overflow: 151 already in queue awaiting acceptance (60 occurrences)
sonewconn: pcb 0xfffff802e2f6c3a0: Listen queue overflow: 151 already in queue awaiting acceptance (151 occurrences)
sonewconn: pcb 0xfffff802e2f6c3a0: Listen queue overflow: 151 already in queue awaiting acceptance (142 occurrences)
I tried to find further infos with:
Code:
# netstat -na |grep 0xfffff802e2f6c3a0
but I got no output.
How can I further investigate this?
Thank you very much!
 

SirDice

Administrator
Staff member
Administrator
Moderator

Thanks: 6,426
Messages: 27,742

#2
Your mail server appears to be too slow to accept new connections. This typically happens when things aren't working correctly or if you get flooded by massive amounts of connections.
 

VladiBG

Well-Known Member

Thanks: 109
Messages: 307

#3
Use netstat -Aan | grep fffff802e2f6c3a0 this will list all protocol control block (PCB) from there use sockstat -l to find the pid usualy this will lead you to the postfix socket public/pickup. Also check your postfix master.cf file and /var/log/maillog
 

herrbischoff

Active Member

Thanks: 70
Messages: 168

#4
Thanks for the hints in this thread. I ran into the same issue as the original poster and want to resolve this.

I managed to track the process down to Postfix inside of my mail server jail. However, I'm now rather confused about how to proceed. Could someone shine some light on as to why this queuing happens and what I can do to relieve the issue?
 

SirDice

Administrator
Staff member
Administrator
Moderator

Thanks: 6,426
Messages: 27,742

#5
Queuing happens if the receiving application cannot process the number of connections fast enough. So you either get too many connections or your application is too slow to handle them.
 

herrbischoff

Active Member

Thanks: 70
Messages: 168

#6
I figured that this might be the case. However, there appears to be something else going on. Because even with a stopped jail netstat -L outputs

Code:
unix  151/0/100                        public/pickup
Shouldn't a stopped application also close its socket, effectively flushing it?
 

herrbischoff

Active Member

Thanks: 70
Messages: 168

#8
Thanks for confirming VladiBG. I tracked the issue down to another jail that was running Postfix unbeknownst to me. Once I shut that down, the socket was indeed gone — and with it the queue overflow warning.

Do you possibly know of an elegant way to trace sockets to jail ids that doesn't involve multiple steps?
 
Top