# too many CLOSE_WAIT (not TIME_WAIT) with courier-imap

## hexa

Hi,

on one of my server clusters where i'm running courier-imap with pop3 enabled i get, from time to time, really hight number of CLOSE_WAIT connection states. More than 4 per user. System seems not to be under any load and nothing would be noticed until maximum connection's per IP or for whole system is reached. Then it takes a couple of minutes for those processes to close, which reduces number of connections to pop3 and imap, so service starts working again normally.

Netstat looks like this per single IP. There can be even more connections.

#netstat -apl | grep IP2

...

tcp        1      0 mail.server:pop3 IP2:4898 CLOSE_WAIT  15072/bash          

tcp        1      0 mail.server:pop3 IP2:4902 CLOSE_WAIT  15604/bash          

tcp        1      0 mail.server:pop3 IP2:4879 CLOSE_WAIT  14752/bash          

tcp        0      0 mail.server:pop3 IP2:4982 ESTABLISHED 15921/bash          

tcp        1      0 mail.server:pop3 IP2:4900 CLOSE_WAIT  15353/bash          

tcp        0      0 mail.server:smtp IP2:4981 TIME_WAIT   -            

...

(BTW netstat always shows /bash as process name and it's normal behavior.)

Each connection has corresponding pop3 process, which is idling. Allso, i can't kill any of the processes, no matter what signal i use.

Any1 has any ideas where to look for problems? Courier-imap is latest marked stable. Most of the time there are 0 connections in CLOSE_WAIT. Seems like the problem is on the network, but CLOSE_WAIT state means that my imap/pop3 server is the only one still hogging the connection. The other site is gone already.

My current workaround was to increase number of allowed connections.

----------

## hexa

Any1?  :Smile: 

----------

## gentoo_ram

Yeah, CLOSE_WAIT probably means the application isn't closing the sockets like it's supposed to.  Sounds like a bug to me.  I guess you could try other options.  I use dovecot for my IMAP serving needs.

----------

