[Dovecot] quick question

[Brandon Davidson]

Hi David,

> -----Original Message-----
> From: David Halik
> 
> It looks like we're still working towards a layer 7 solution anyway.
> Right now we have one of our student programmers hacking Perdition
with
> a new plugin for dynamic username caching, storage, and automatic fail
> over. If we get it working I can send you the basics if you're
interested.

I'd definitely be glad in taking a look at what you come up with! I'm
still leaning towards MySQL with quick local fallback, but I'm nowhere
near committed to anything.

On a side note, we've been running with the two latest maildir patches
in production for a few days now. The last few days we've been seeing a
lot of lock failures:

Feb 10 04:06:02 cc-popmap6p dovecot: imap-login: Login: user=<pellerin>,
method=PLAIN, rip=67.223.67.45, lip=128.223.142.39, TLS, mailpid=12881 
Feb 10 04:08:03 oh-popmap3p dovecot: imap-login: Login: user=<pellerin>,
method=PLAIN, rip=67.223.67.45, lip=128.223.142.39, TLS, mailpid=9569 
Feb 10 04:09:02 cc-popmap6p dovecot: imap: user=<pellerin>,
rip=67.223.67.45, pid=12881: Timeout while waiting for lock for
transaction log file /home6/pellerin/.imapidx/.INBOX/dovecot.index.log 
Feb 10 04:09:02 cc-popmap6p dovecot: imap: user=<pellerin>,
rip=67.223.67.45, pid=12881: Our dotlock file
/home6/pellerin/Maildir/dovecot-uidlist.lock was modified (1265803562 vs
1265803684), assuming it wa
Feb 10 04:09:02 cc-popmap6p dovecot: imap: user=<pellerin>,
rip=67.223.67.45, pid=12881: Connection closed bytes=31/772 
Feb 10 04:11:04 oh-popmap3p dovecot: imap: user=<pellerin>,
rip=67.223.67.45, pid=9569: Timeout while waiting for lock for
transaction log file /home6/pellerin/.imapidx/.INBOX/dovecot.index.log 
Feb 10 04:11:04 oh-popmap3p dovecot: imap: user=<pellerin>,
rip=67.223.67.45, pid=9569: Our dotlock file
/home6/pellerin/Maildir/dovecot-uidlist.lock was deleted (locked 180
secs ago, touched 180 secs ago) 
Feb 10 04:11:04 oh-popmap3p dovecot: imap: user=<pellerin>,
rip=67.223.67.45, pid=9569: Connection closed bytes=18/465

I'm not sure if this is just because it's trying more diligently to make
sure it's got the latest info, and is therefore hitting locks where it
didn't previously... but it's been hanging our clients and requiring
manual intervention to clear. We've been removing the lock file and
killing any active dovecot sessions, which seems to resolve things for a
while.

Just thought I'd see if this was happening to anyone else.

-Brad