Ok, my head is swimming after catching up, but I think this is what I've concluded...
I am using Fedora Core 5 and dovecot RPMs. The RPM that shipped with FC5 was:
dovecot-1.0-0.beta2.7
after observing the stale imap processed I upgraded this to:
1.0-0.beta8.2.fc5
Both of these are built with ioloop=poll.
I am still seeing the stale processes with beta8. Sounds like I need to build from source using ioloop=kqueue to maybe clear up this issue. Did I interpret this correctly? And should I stick with beta8 or move to rc2?
Thanks, Fran
Renaud Allard wrote:
Unfortunately, I had the problem on OpenBSD with dovecot 1.0rc2. Stale imap processes when _NOT_ using kqueue (using poll). Using kqueue solved the problem. Not sure if it's the same on FreeBSD, but it seems that using kqueue solves the stale processes problem both on OpenBSD and NetBSD. On linux, kqueue doesn't produce stale imap processes either.
I have had a number of reports that kqueue, specifically kqueue for the file change mechanism (--with-notify=kqueue), causes the hanging and disabling this allowed regular operation. kqueue for the I/O loop mechanism causes dovecot processes to crash under certain (unknown) conditions. If poll is causing problems then there are definitely some nasty bugs lurking in the code base. The problem with the file change mechanism and kqueue popped up somewhere between beta8 and rc2.
I use --with-ioloop=kqueue I had no problems with beta8, and noticed stale imap processes after upgrading to rc2. Someone suggested using --with-ioloop=kqueue and this indeed solved my problem. Note that while I have no more imap processes hanging, I noticed that sometimes thunderbird complains about being unable to copy mails in sent folder. This wasn't the case in beta8.
-- Fran Fabrizio Senior Systems Analyst Department of Computer and Information Sciences University of Alabama at Birmingham http://www.cis.uab.edu/ 205.934.0653