On Tue, Apr 15, 2003 at 12:38:11AM -0400, Mark E. Mallett wrote:
Tried this- still get at least three varieties of the "Corrupted index file" errors (very frequent as you can see by the timestamps):
Apr 14 23:48:03 mercury mem[11546]: pop3(user3): Corrupted index file /users/1d/user3/Maildir/.INBOX/.imap.index: Filename mismatch for UID 1366: 1050157920.28714.mercury.mv.net vs 1050168692.1692.mercury.mv.net
Humm. Well, have to keep looking more at that.
Plus very rapid signal 11s:
Apr 14 23:48:12 mercury dovecot: child 25983 (imap) killed with signal 11 Apr 14 23:48:12 mercury dovecot: child 25992 (imap) killed with signal 11 Apr 14 23:48:14 mercury dovecot: child 26034 (imap) killed with signal 11
Could these be the FETCH MIME crashes that Evolution caused? What clients do you mostly have anyway?
In fact it appears that all examples of "Corrupted index" are pop3 instances, and all examples of "signal 11" are imap..
Are you sure you rebuilt/reinstalled the pop3 binary? I haven't actually tried pop3 at all for a long time, but it shares all the backend code with imap.
I tried setting
mail_drop_priv_before_exec = yes
as you suggested, to generate a core dump, but if it's dumping core I can't find it anywhere. dovecot was started from /var/tmp and I have verified that the running dovecot and dovecot-auth processes have /var/tmp as a working directory.
Does everyone have write access to that directory then? It's the imap process that needs it.. Or maybe you have just disabled core dumping? Dovecot uses the ulimit -c that was active when dovecot was started.
I also continue to see sporadic "(imap) returned error 89" with this version and with 0.99.8.1
Without more specific error above it?