On Mon, May 06, 2013 at 04:20:52PM +0200, Morten Stevens wrote:

...

May 4 21:15:17 volanges dovecot: imap(jdoe): Error: Corrupted index cache file /mail/indexes/jdoe/mail/.imap/Commandes/dovecot.index.cache: Broken physical size for mail UID 680

Does that ring a bell? I am tempted to downgrade to 2.1.13. Does it makes sense? Is it safe to do so?

This bug has been fixed with dovecot 2.1.14.

But I am running 2.2.0 ...

-- Emmanuel Dreyfus manu@netbsd.org

On Mon, May 06, 2013 at 01:52:55PM -0400, Oscar del Rio wrote:

Have you tried 2.2.1?

Will do, but since the problem cannot be reliabily reproduced, I have no way of knowing it is fixed. Is there anything in 2.2.1 changelog that hints it could be fixed?

-- Emmanuel Dreyfus manu@netbsd.org

On Wed, May 15, 2013 at 02:50:55PM +0300, Timo Sirainen wrote:

There are some locking code changes between v2.1 and v2.2, which I guess might be buggy. But I can't reproduce any corruption with stress testing. What's your doveconf -n output? Are you delivering mails via dovecot-lda or something external?

dovecot -n is below. dovecot takes care of delivery, through LMTP.

Additionnal thoughts on possible problems:

• one of the users was using mutt locally and accessed its mailbox directly without going through dovecot.
• I experimented dsync replication from another machine that was not accessible through POP/IMAP/SMTP, perhaps this is what caused chaos?

auth_mechanisms = plain login disable_plaintext_auth = no first_valid_uid = 400 mail_location = mbox:~/mail:INBOX=/var/mail/%u:INDEX=/mail/indexes/%u:SUBSCRIPTI ONS=../.mailboxlist mbox_very_dirty_syncs = yes passdb { args = max_requests=1 cache_key=%u dovecot driver = pam } passdb { args = /etc/dovecot-ldap.conf driver = ldap } plugin { autosubscribe = INBOX quota = fs:User quota quota_warning = storage=95%% quota-warning %u } quota_full_tempfail = yes service anvil { client_limit = 1639 } service auth { client_limit = 1736 user = root } service imap-login { chroot = login process_limit = 1024 } service imap { process_limit = 680 } service lmtp { process_min_avail = 5 unix_listener lmtp { group = smmsp mode = 0660 } } service pop3-login { chroot = login process_limit = 512 } service pop3 { process_limit = 680 } service quota-warning { executable = script /usr/local/sbin/morts unix_listener quota-warning { mode = 0666 } user = root } ssl_ca =

-- Emmanuel Dreyfus manu@netbsd.org

On Wed, May 15, 2013 at 09:36:54PM +0300, Timo Sirainen wrote:

...

• one of the users was using mutt locally and accessed its mailbox directly without going through dovecot. That shouldn't cause problems if locking was configured the same.

I never looked at it, but I assume they both use flock or fcntl since this is local storage. And it worked fine for a while, therefore there is no hint it could be wrong.

...

• I experimented dsync replication from another machine that was not accessible through POP/IMAP/SMTP, perhaps this is what caused chaos? That might cause trouble. I tested today and dsync was doing some strange things with mbox.

What is the advised setup? Here is the additionnal config I tried on the inacessible host:

mail_plugins = $mail_plugins notify replication service replicator { process_min_avail = 1 } dsync_remote_cmd = ssh -lroot %{host} doveadm dsync-server -u%u plugin { mail_replica = remote:root@server1.example.net } service aggregator { fifo_listener replication-notify-fifo { user = dovecot } unix_listener replication-notify { user = dovecot } } service replicator { unix_listener replicator-doveadm { mode = 0600 } } service replicator { unix_listener replicator-doveadm { mode = 0600 } } service doveadm { inet_listener { port = 12345 ssl = yes } } doveadm_port = 12345 ssl_client_ca_file = /etc/openssl/certs/tcs-chain.crt doveadm_proxy_port = 0

-- Emmanuel Dreyfus manu@netbsd.org

On Thu, May 16, 2013 at 06:37:45AM -0400, Charles Marcus wrote:

...

I never looked at it, but I assume they both use flock or fcntl

Can't help with your actual problem, but... What was it that 'assumption' is supposedly the mother of?

I don't buy that explanation: everything worked fine for years.

-- Emmanuel Dreyfus manu@netbsd.org

On 16.5.2013, at 4.01, Emmanuel Dreyfus manu@netbsd.org wrote:

...

...

• I experimented dsync replication from another machine that was not accessible through POP/IMAP/SMTP, perhaps this is what caused chaos? That might cause trouble. I tested today and dsync was doing some strange things with mbox.

What is the advised setup?

Not using mbox, at least with dsync, at least for now.