[Dovecot] Dovecot-1.1.15 panics
Dovecot-1.1.15 assert-fails frequently. Attached are some errors from
the logs, and a stack trace from the common panic. Hope you can fix
these soon. Thanks.
0 libSystem.B.dylib 0x00007fff8825e606 __kill + 10
1 libSystem.B.dylib 0x00007fff882e1c92 abort + 83
2 imap 0x0000000100069e1b
default_fatal_finish + 70
3 imap 0x0000000100069e69
i_syslog_fatal_handler + 0
4 imap 0x00000001000695c8 i_info + 0
5 imap 0x000000010001913f
maildir_uidlist_iter_next_rec + 210
6 imap 0x0000000100019177
maildir_uidlist_iter_next + 38
7 imap 0x0000000100018abb
maildir_sync_index + 2019
8 imap 0x0000000100017788
maildir_sync_context + 662
9 imap 0x000000010001797c
maildir_storage_sync_init + 104
10 imap 0x000000010000bbe3
imap_sync_init + 132
11 imap 0x000000010000be35
cmd_sync_delayed + 477
12 imap 0x0000000100006692
client_handle_input + 419
13 imap 0x000000010000676c
client_input + 148
14 imap 0x0000000100070e60
io_loop_handler_run + 272
15 imap 0x0000000100070225 io_loop_run
- 55 16 imap 0x000000010000d746 main + 1640 17 imap 0x0000000100000b84 start + 52
On Mon, 2009-06-29 at 16:17 -0500, Mike Abbott wrote:
Dovecot-1.1.15 assert-fails frequently. Attached are some errors from
the logs, and a stack trace from the common panic. Hope you can fix
these soon. Thanks.
Either there's a bit stranger bug, or the UIDs have reached 2^32-1 for that mailbox. Which one is it? I "fixed" the latter: http://hg.dovecot.org/dovecot-1.1/rev/07a377d58ccf
Either there's a bit stranger bug
It appears to be related to the readdir()-returns-EINVAL issue.
Fixing that stopped the assertion from failing.
There is still lots of "noise" in the log though. The attached perl
script just sends and retrieves mail over and over:
$ ./dere.pl --iterations 1000 --sendfor 3 --server mailhost.my.domain
--sender a@b.c --username user1 --password test
[...]
Pid 24307 iteration 74 at Wed Jul 8 08:17:38 2009
Sent 738 message(s)
INBOX contains 698 message(s)
Pid 24307 iteration 75 at Wed Jul 8 08:17:48 2009 Sent 626 message(s) INBOX contains 725 message(s)
When run against a Mac OS X server with dovecot-1.1.16 and dovecot's
deliver via postfix, there are lots of errors and warnings. See the
attached log. Are these normal?
Thanks.
On Wed, 2009-07-08 at 08:23 -0500, Mike Abbott wrote:
There is still lots of "noise" in the log though. The attached perl
script just sends and retrieves mail over and over: .. When run against a Mac OS X server with dovecot-1.1.16 and dovecot's
deliver via postfix, there are lots of errors and warnings. See the
attached log. Are these normal?
Nope. I've now managed to get this twice in last two days:
Fixed index file /Users/tss/Maildir/dovecot.index: log_file_seq 1 -> 22
Once with my Macbook/Leopard and the second time with Mac mini/Snow Leopard server. I've now added some debug code, but it takes forever to get that error even once, so it's kind of difficult.
Is that a normal HFS+ filesystem? Anything special done to it? With case-insensitive filenames? Have you tried my imaptest tool (http://imapwiki.org/ImapTest) to see if it gives errors?
BTW. Is there some really easy way to get those Net::IMAP::Simple etc. Perl packages installed? I'm now running the Perl script from a separate Linux machine over WLAN..
Is that a normal HFS+ filesystem?
Yup.
Anything special done to it?
Nope.
With case-insensitive filenames?
Yup.
Have you tried my imaptest tool (http://imapwiki.org/ImapTest) to
see if it gives errors?
I'll try that soon and let you know.
BTW. Is there some really easy way to get those Net::IMAP::Simple etc. Perl packages installed? I'm now running the Perl script from a
separate Linux machine over WLAN..
cpan(1)
On Mon, 2009-07-27 at 18:12 -0500, Mike Abbott wrote:
Have you tried my imaptest tool (http://imapwiki.org/ImapTest) to
see if it gives errors?I'll try that soon and let you know.
Looks like readdir() EINVALs come whenever there is more than one session accessing the mailbox and I couldn't get rid of them even when retrying it many times..
Also I can't get your perl script to break my Dovecot installation anymore at all.
This is the main reason it keeps breaking:
Terminal 1: while true; do touch foo.tmp; mv foo.tmp foo; done
Termanal 2: while true; do cat foo; done
foo always exists, because POSIX guarantees that rename is atomic. But terminal 2 keeps failing randomly:
cat: No such file or directory
So, apparently HFS+'s rename() isn't really atomic after all..
[...] mv foo.tmp foo [...]
[...]
So, apparently HFS+'s rename() isn't really atomic after all..
Are you sure OS X's mv(1) simply calls rename(2)? Maybe some magic in mv(1) for ._xxx resource forks or directory hardlinks?
On Aug 10, 2009, at 8:59 AM, Edgar Fuß wrote:
[...] mv foo.tmp foo [...]
[...]
So, apparently HFS+'s rename() isn't really atomic after all..
Are you sure OS X's mv(1) simply calls rename(2)? Maybe some magic
in mv(1) for ._xxx resource forks or directory hardlinks?
I also wrote a C program that used rename() to verify it. Anyway, I
heard it was also verified by Apple's HFS+ people.
participants (3)
-
Edgar Fuß
-
Mike Abbott
-
Timo Sirainen