damien chambe - EGS
2007-Jun-21 22:28 UTC
[Dovecot] Server 1.0.1 migration: Maildir : UID inserted in the middle of mailbox
Hello all, Since a migration from dovecot 1.rc16 to Dovecot 1.0.1 + new server, every day I have a lot of errors like this : Jun 21 17:42:34 dovecot1 deliver(damien.chambe at egs-gestion.fr): msgid=<467A9B3E.5070605 at egs-gestion.fr>: saved mail to INBOX Jun 21 17:42:34 dovecot1 postfix/pipe[10242]: 92DD11FA8B: to=<damien.chambe at egs-gestion.fr>, relay=dovecot, delay=0, status=sent (egs-gestion.fr) Jun 21 17:42:34 dovecot1 postfix/qmgr[2724]: 92DD11FA8B: removed Jun 21 17:42:37 dovecot1 dovecot: IMAP(damien.chambe at egs-gestion.fr): Maildir /mnt/baie/hula/dovecot/maildir/damien.chambe sync: UID inserted in the middle of mailbox (374 > 1, file 1182330228.P30307Q0M224874.dovecot1:2,ST) Jun 21 17:42:37 dovecot1 dovecot: IMAP(damien.chambe at egs-gestion.fr): Disconnected: Mailbox is in inconsistent state, please relogin. Jun 21 17:51:41 dovecot1 dovecot: imap-login: Login: user=<damien.chambe at egs-gestion.fr>, method=PLAIN, rip=10.6.1.104, lip=10.5.3.38 Jun 21 17:51:41 dovecot1 dovecot: IMAP(damien.chambe at egs-gestion.fr): Corrupted index cache file /opt/dovecot/indexes/damien.chambe/.INBOX/dovecot.index.cache: indexid changed After this error, all UID are regenerated. And, when the user logs in, all headers are sent back to the client (IMAP / thunderbird 1.5.x or 2.0.0.4). No email are lost or duplicated, but it cause a huge traffic on our DSL lines, and user are complaining... There's also other errors related to UID: Jun 21 16:11:01 dovecot1 deliver(pr at egs-gestion.fr): rename(/mnt/baie/hula/dovecot/maildir/pr/dovecot-uidlist.lock, /mnt/baie/hula/dovecot/maildir/pr/dovecot-uidlist) failed: No such file or directory Jun 21 16:11:01 dovecot1 deliver(pr at egs-gestion.fr): file_dotlock_replace(/mnt/baie/hula/dovecot/maildir/pr/dovecot-uidlist) failed: No such file or directory Jun 21 16:11:02 dovecot1 deliver(pr at egs-gestion.fr): /mnt/baie/hula/dovecot/maildir/pr/dovecot-uidlist: next_uid was lowered (374 -> 373) Jun 21 16:11:02 dovecot1 deliver(pr at egs-gestion.fr): msgid=<467A85CB.50009 at fica.fr>: saved mail to INBOX Jun 21 16:11:02 dovecot1 dovecot: IMAP(pr at egs-gestion.fr): rename(/mnt/baie/hula/dovecot/maildir/pr/dovecot-uidlist.lock, /mnt/baie/hula/dovecot/maildir/pr/dovecot-uidlist) failed: No such file or directory Here's the context: Our Dovecot server had to be changed due to a hardware problem I was forced to use SUSE SLES 10 for the new one, instead of SLES 9 on the old server. X86-32 I've kept the same configuration files for postfix, dovecot. We use dovecot deliver. Old postfix version was 2.1.1, now I have 2.2.9 During the migration, I've changed dovecot 1.rc16 to dovecot 1.0.0 When I saw this error, I upgraded to dovecot 1.0.1, but same problem (I use suse rpm packages ) I have 400 mailbox, all Maildir. The problem happens 50 times a day, so not on every mail received. I store mails on NFS, and index on local disk. There's only one dovecot server, so no multiple access. I've tried to remove all index files, and remove dovecot-uidlist, all is correctly re-created, but the problem remains. Could it be an NFS locking problem ? Since only mail are stored on maildir + NFS, and index on local disk, so I didn't set lock_method or nmap_disable Could it be related to this: see email from from Doug Concil : [Dovecot] NFS lock contention for dovecot-uidlist on may 17 , 2007 ? dovecot -n # 1.0.1: /etc/dovecot/dovecot.conf protocols: imap pop3 ssl_disable: yes disable_plaintext_auth: no login_dir: /var/run/dovecot/login login_executable(default): /usr/lib/dovecot/imap-login login_executable(imap): /usr/lib/dovecot/imap-login login_executable(pop3): /usr/lib/dovecot/pop3-login login_user: dovecotlogin login_process_per_connection: no login_processes_count: 5 max_mail_processes: 2048 first_valid_uid: 120 first_valid_gid: 12 default_mail_env: maildir:/mnt/baie/hula/dovecot/maildir/%n:INDEX=/opt/dovecot/indexes/%n mail_location: maildir:/mnt/baie/hula/dovecot/maildir/%n:INDEX=/opt/dovecot/indexes/%n mail_executable(default): /usr/lib/dovecot/imap mail_executable(imap): /usr/lib/dovecot/imap mail_executable(pop3): /usr/lib/dovecot/pop3 mail_plugins(default): quota imap_quota mail_plugins(imap): quota imap_quota mail_plugins(pop3): mail_plugin_dir(default): /usr/lib/dovecot/modules/imap mail_plugin_dir(imap): /usr/lib/dovecot/modules/imap mail_plugin_dir(pop3): /usr/lib/dovecot/modules/pop3 pop3_uidl_format(default): pop3_uidl_format(imap): pop3_uidl_format(pop3): %08Xu%08Xv auth default: verbose: yes passdb: driver: ldap args: /etc/dovecot/dovecot-ldap.conf userdb: driver: ldap args: /etc/dovecot/dovecot-ldap.conf socket: type: listen master: path: /var/run/dovecot/auth-master mode: 384 user: dovecot group: mail plugin: quota: maildir:storage=1500000:messages=40000 Thanks, -- Cordialement, Damien Chambe EGS 42 bld jules janin - BP 240 - 42006 Saint Etienne Cedex 1 Tel : 04 77 49 48 16 Fax : 04 77 49 48 45 Site institutionnel : http://www.groupe-laurent.com Site catalogue : http://ecat.groupe-laurent.com
Timo Sirainen
2007-Jun-25 16:55 UTC
[Dovecot] Server 1.0.1 migration: Maildir : UID inserted in the middle of mailbox
On Fri, 2007-06-22 at 00:28 +0200, damien chambe - EGS wrote:> Our Dovecot server had to be changed due to a hardware problem > I was forced to use SUSE SLES 10 for the new one, instead of SLES 9 on > the old server.The kernel matters a lot with NFS. Some kernels are more broken than others. Attribute cache also matters. http://wiki.dovecot.org/NFS> I store mails on NFS, and index on local disk. There's only one > dovecot > server, so no multiple access.So deliver is also run on the same server? If all of it is done on the same server, then pretty much the only thing you can change is the kernel or somehow try to work around its bugs. I can think of only this fix on Dovecot's side: http://dovecot.org/list/dovecot/2006-December/018145.html Hmm. Actually I just realized another reason that could cause these: Are the clocks on the NFS server and on your Dovecot machine synchronized? They must be less than 1 second apart at all times or you'll begin to see problems. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://dovecot.org/pipermail/dovecot/attachments/20070625/13a5b1cd/attachment-0002.bin>
damien chambe - EGS
2007-Jun-27 10:42 UTC
[Dovecot] Server 1.0.1 migration: Maildir : UID inserted in the middle of mailbox [resolved]
Timo Sirainen a ?crit :> On Fri, 2007-06-22 at 00:28 +0200, damien chambe - EGS wrote: > > >> Our Dovecot server had to be changed due to a hardware problem >> I was forced to use SUSE SLES 10 for the new one, instead of SLES 9 on >> the old server. >> > > The kernel matters a lot with NFS. Some kernels are more broken than > others. Attribute cache also matters. http://wiki.dovecot.org/NFS > > >> I store mails on NFS, and index on local disk. There's only one >> dovecot >> server, so no multiple access. >> > > So deliver is also run on the same server? If all of it is done on the > same server, then pretty much the only thing you can change is the > kernel or somehow try to work around its bugs. I can think of only this > fix on Dovecot's side: > > http://dovecot.org/list/dovecot/2006-December/018145.html > > Hmm. Actually I just realized another reason that could cause these: Are > the clocks on the NFS server and on your Dovecot machine synchronized? > They must be less than 1 second apart at all times or you'll begin to > see problems. > >I've tried to update kernel (SUSE SLES 10 is 2.6.16) but no change. But synchronizing NFS server and dovecot server with NTP did the trick. SUSE SLES9 NFS was more tolerant than SLES 10 with time sync... No more uid messages yesterday ! Thank you for your quick answer -- Cordialement, Damien Chambe EGS - Groupe Laurent 42 bld jules janin - BP 240 - 42006 Saint Etienne Cedex 1 Tel : 04 77 49 48 16 Fax : 04 77 49 48 45 Site institutionnel : http://www.groupe-laurent.com Site catalogue : http://ecat.groupe-laurent.com