[Dovecot] Index corruption causes child process to die

Bill Cole dovecot-20061108 at billmail.scconsult.com
Sat Nov 11 03:10:44 UTC 2006


At 1:19 PM -0500 11/10/06, bofh list wrote:
>I am seeing the following errors with vanilla RC13 (two servers, 
>nfs, mmap_disable=yes, lock_method=fnctl, Maildir).  These only 
>manifested after the upgrade to 1.0RC13
>
>
>
>server1:
>dovecot: Nov 09 15:44:08 Error: IMAP(user1): file ioloop.c: line 22 
>(io_add): assertion failed: (fd >= 0)
>dovecot: Nov 09 15:44:08 Error: child 2920 (imap) killed with signal 6
>dovecot: Nov 09 16:09:47 Error: IMAP(user2): file ioloop.c: line 22 
>(io_add): assertion failed: (fd >= 0)

Data point: I am seeing the same thing (ioloop.c line 22 assertion 
failure) with a very different system: MacOS X 10.4.8, 
mmap_disable=no (default), single machine, Maildir at ~/Maildir on 
the same internal disk as everything else, lock_method=fcntl.

Because this is a small informal test system I also have a little 
more info that may be relevant. Since rc7 (my first rc version) I 
have seen occasional incidents where a single account (the same one 
involved in my assertion failures today) gets one subdirectory locked 
with one or more temp.$PID.<random> files in it and a message in tmp, 
This account has multiple clients almost constantly logged in, one 
Eudora/Mac, one Outlook 2003/XP, one Versamail 3.5/PalmOS. Only 
Eudora moves anything anywhere, Outlook sits mostly idle, Versamail 
is scanning the Inbox every 15 minutes and sync's everything 
irregularly every few hours. Most mail arriving for this account is 
automatically moved to one of 3 IMAP folders, and about half of the 
rest is automatically stashed locally by the client and trashed on 
the server. In all cases, the jammed IMAP directory In all 4 cases of 
the hang, a simple stop and restart of Dovecot and all clients has 
failed to solve the hang, and the solutions have come from either 
full system reboots or cleaning out both the dovecot index files and 
the file in the tmp folder of the Maildir subdirectory that was hung. 
I believe this is connected because twice today around  the same 
times as the assertion failures in the logs, I had clients time out 
while trying to synch IMAP folders, which had me suspecting the same 
sort of failure, only to work on another connection within 10 minutes.


-- 
Bill Cole                                  
bill at scconsult.com



More information about the dovecot mailing list