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@eng.sun.com - blogs.sun.com/dp