# queue overflow message



## circus78 (Mar 26, 2018)

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:


```
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:

```
# netstat -na |grep 0xfffff802e2f6c3a0
```

but I got no output.
How can I further investigate this?
Thank you very much!


----------



## SirDice (Mar 26, 2018)

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 (Mar 26, 2018)

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 (Oct 12, 2018)

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 (Oct 12, 2018)

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 (Oct 12, 2018)

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


```
unix  151/0/100                        public/pickup
```

Shouldn't a stopped application also close its socket, effectively flushing it?


----------



## VladiBG (Oct 12, 2018)

Yes if you stop the application that open that socket it will close.

pickup(8)


----------



## herrbischoff (Oct 12, 2018)

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?


----------



## VladiBG (Oct 12, 2018)

I'm not using jails but you can try sockstat(1)

*-j* _jid_     Show only sockets belonging to    the specified jail ID.


----------

