[Dovecot] A couple of dovecot issues I've noted recently...

[Dan Price]

On Sun 20 Jul 2008 at 06:05PM, Timo Sirainen wrote:
> On Wed, 2008-07-09 at 17:09 -0700, Dan Price wrote:
> 
> You don't have a separate mail directory, so users sometimes list their
> entire home directory which can contain a huge directory tree, causing
> out of memory?

I rely on users to set their mail directory in their IMAP
client appropriately-- this is because we have a historical mix
of users with ~/Mail, ~/mail, and in some weird cases other
dir names in their home directories where they store their mail.

I don't know why (it seems obvious now) but I hadn't worked out that
it was a recursive directory walk which might be causing this.  I can
now hunt down these users and help them.  Thanks!

> Also v1.1+ sets aside an "out of memory" buffer which is used when
> logging the "out of memory" error.

Thanks.  I've applied your patch and will roll it out as soon as
I can.

> What heap corruption?

Sorry, never mind.

> > A final problem, and this one affects me personally, is that
> > we see some errors like this:
> > 
> > dovecot: Jul 09 11:52:10 Error: IMAP(dp): FETCH for mailbox mail/tmp-inbox UID 92086 got too little data: 6054 vs 6057
...
>
> But as for why it happens in the first place, that's a bit difficult to
> guess. Is the difference always 3 bytes? Anything else than Dovecot
> modifying the mboxes?

Seems to be 3 in most cases.  Take a look; I've marked the ones which
aren't offset by 3:

$ grep 'got too little' * | awk '{print $6, $17, $19}' | sort | uniq -c
   6 IMAP(dp): 2490 2493 3
   1 IMAP(dp): 5193 5196 3
   3 IMAP(dp): 6054 6057 3
 678 IMAP(helen): 1499 1710 211  <--
  22 IMAP(mimi): 2573 2690 117   <--
 208 IMAP(rav): 5651 5654 3
  69 IMAP(rav): 7549 7552 3
  22 IMAP(will): 3032 3035 3
 397 IMAP(will): 3213 3216 3
   6 IMAP(will): 3861 3864 3
 106 IMAP(will): 444 447 3

My first step will be to blow away the dovecot index files for all
of these users.  Thanks so much for your help.

	-dp

-- 
Daniel Price - Solaris Kernel Engineering - dp at eng.sun.com - blogs.sun.com/dp