Expunging messages caused those "Corrupted index file" errors. That's fixed now. There's probably still some problems, at least this fix didn't fix any crashes..
test3 available from http://dovecot.procontrol.fi/test/
On Sat, Apr 12, 2003 at 06:04:32PM +0300, Timo Sirainen wrote:
Expunging messages caused those "Corrupted index file" errors. That's fixed now. There's probably still some problems, at least this fix didn't fix any crashes..
test3 available from http://dovecot.procontrol.fi/test/
Hi-
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
Apr 14 23:48:11 mercury mem[11880]: pop3(user4): Corrupted index file (in-memory index for /users/2a/user4/Maildir): Filename mismatch for UID 1: 1050378453.254 31.mercury.mv.net vs 1050378419.24825.mercury.mv.net
Apr 14 23:48:15 mercury mem[10327]: pop3(user1): Corrupted index file /users/8f/user1/Maildir/.INBOX/.imap.index: index.next_uid (118) > uidlist.next_uid (114)
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
Pretty much the same as with test2.
All occurances of this last mesasge say "(imap)" -- no "pop3".
However most accesses on this system are pop3, not imap.
In fact it appears that all examples of "Corrupted index" are pop3 instances, and all examples of "signal 11" are 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.
I also continue to see sporadic "(imap) returned error 89" with this version and with 0.99.8.1
-mm-
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?
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?
It could be. I'll try the test4 and see what it reports. I generally stage the installation through a test machine and my rather low-volume tests to that machine do not show these failures. So there probably is some difference between my tests and other user accesses.
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.
Very sure..
Another difference that occured to me: I built the recent -test versions with the libiconv library, and the previous ones without. This would seem (from my naive perspective) to also be a difference between pop3 and imap code paths.
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 started it from /var/tmp to help with the core dumping (because that is indeed a directory that everybody can write to). I didn't mention it but I did indeed look at the dovecot process limits (via "rlimit") to verify that it did not have a restricted coredump limit.
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?
Not that I have been able to find.. i.e. no correlation with the pid given.
mm
participants (2)
-
Mark E. Mallett
-
Timo Sirainen