Mike Brady wrote: >I am observing a problem where imapd occasionally does not close the TCP >session properly. This only seems to occur with 2.1.3. ><...original details at end...> > We are also seeing an odd problem with 2.1.3. It may or may not be related to Mike's issue. We are using the skiplist backend for mailboxes and seen state. We have disabled the TLS session cache. We are using Linux 2.4.18 with Ext3.
2 times in the last week our IMAP server has suddenly stopped accepting IMAP connections on port 143 on its ethernet interface. However, it continues to accept IMAP connections on port 993 (SSL) and the localhost interface. Our cyrus.conf lines are: ---- imap cmd="imapd" listen="www.fastmail.fm:imap" prefork=20 imaplocal cmd="imapd" listen="[127.0.0.1]:imap" prefork=25 imaps cmd="imapd -s" listen="www.fastmail.fm:imaps" prefork=2 ---- Restarting Cyrus clears the problem. There are no unusual messages in imapd.conf or log/messages. We have plenty of spare system file descriptors. Both times this has happened has been at the busiest time of the day. However we had plenty of IO and CPU capacity spare at the time. It looks to me like somehow that particular port on that interface got 'filled up'. I'm not a TCP guru so I don't know exactly what that might look like--is there some limit on concurrent connections or a queue of waiting connections? When the lockup occured, telneting to the port simply resulted in nothing at all--it just sat there waiting for 5 minutes... Could Mike's problem report of TCP connections not being closed correctly lead to this kind of lockup? ---- <The rest of Mike's message...> The details are as follows. My system is RedHat 7.2 with all appropriate errata except the kernel ones. The kernel is 2.4.18 compiled from tarball, but this issue also occurs with the Redhat 2.4.7-10 kernel. I am currently using Outlook 2000 on W2K Pro as my mail client (sorry :-). In addition I have compiled Postfix 1.1.4, Cyrus SASL 2.1.1 and Cyrus IMAP 2.1.3 from their respective tarballs. The server is lightly loaded. This is my home server, I am the only user and it is only doing my e-mail at the moment. For the most part mail works. That is, I can send and receive e-mail with no problems. The symptom of the problem is that Outlook gets stuck while retrieving messages (I can't remember the exact message on the status bar). By stuck I mean that the Outlook UI is still accepting input, but it doesn't do anything. The Outlook UI can be closed, but the Outlook processes does not die. The only way to get rid of it is to use Task Manager to kill it. On the server side netstat shows that the tcp session state is CLOSE_WAIT. I have a tcpdump capture which shows that Outlook (well the tcp stack underneath it) has sent a FIN packet and imapd has acked it, which is why it is in the CLOSE_WAIT state. So far so good. However, to complete the tcp session close imapd should next send a FIN which Outlook should then ack. imapd never sends the FIN. I have waited for hours. The only way to get rid of the imapd process is to kill it, at which point it does send a RST packet. However, by this stage W2K/Outlook is so out to lunch the RST does not do anything. The only way to recover is to kill the Outlook.exe process. I have not been able to determine a way to make this happen. It has occurred within seconds of opening Outlook, but sometimes it takes hours. My initial "figuring out Cyrus" install/testing was done with 2.1.2 and I did not see this behaviour. 2.1.3 came out while I was doing through my learning phase, so when I did my real install I use that. I went back to 2.1.2 on my live server about 24 hours ago and this problem has not occurred at all. It has been many years since I did any C coding so I haven't tried to look at the source to figure this out. If there is something specific that I can look at or there is any more information that I can send please let me know. Thanks Mike Brady Auckland New Zealand
