[Dovecot] assertion failed -0.99 -> 1.0-stable
Hello Timo,
I've upgraded from dovecot-0.99 to dovecot-1.0-stable (the 2005-05-09 version) on FreeBSD 5.4 and encountered the following problems (problem #4 (assertion failed) made me downgrade back to dovecot-0.99...) :
- mbox sync: UID inserted in the middle of mailbox /var/mail/gopauld (5230 > 4407)
--> OK, that's documented on the Wiki, not a real problem
- imap(cxxx): mkdir_parents(/opt/dovecot/c/cxxx/.imap/INBOX) failed: Permission denied
--> I can't understand why since /opt/dovecot/c is rwxrwxrwt and belongs to root:wheel
dovecot: IMAP(xxxx): UIDs broken with partial sync in mbox file /yyyy/zzzz/xxxx/Mail/Drafts
dovecot: IMAP(xxxx): file istream-raw-mbox.c: line 383 (istream_raw_mbox_get_body_size): assertion failed: +(rstream->body_offset != (uoff_t)-1)
--> That one occured each time a user connected with Eudora (on OS-X) moved messages from INBOX to some of her IMAP mailboxes.
Since it was in real life, I hadn't time to get a gdb backtrace.
Notes :
. that user had restarted her client (Eudora).
. my messages moves from one IMAP mbox to another did work.
. the assertion failed occured with the version of 2005-06-04 as well (which I tried since the ChangLog mentionned some similar problems).
Any clues ?
-- Thomas Hummel | Institut Pasteur <hummel@pasteur.fr> | Pôle informatique - systèmes et réseau
On Wed, 2005-06-08 at 14:46 +0200, Thomas Hummel wrote:
Was cxxx created then? Anyway one of the mkdir() calls which tried to create that path failed with that error..
Well, shouldn't happen but not a real problem unless it happens constantly.
Probably means the mbox has CR+LF linefeeds? 1.0-stables don't handle them well yet. IMAP clients can't create CR+LF linefeeds, so they must have come somewhere else.
--> That one occured each time a user connected with Eudora (on OS-X) moved messages from INBOX to some of her IMAP mailboxes.
I'm not sure if copying preserves CR+LFs.. I don't think it should. Maybe it just triggered the problem in INBOX when some messages were deleted.
On Wed, Jun 08, 2005 at 01:19:31PM +0000, Timo Sirainen wrote:
On Wed, 2005-06-08 at 14:46 +0200, Thomas Hummel wrote:
I don't think so. This is strange since other users index directories were created normally.
What is that partial sync about ?
You're right : that INBOX do have CR+LF linefeeds. I don't know where they come from.
What can I do then ? Is there a way to work this around ? Besides, do you mean that I wouldn't have had this problem with a 1.0-tests ?
One other problem I forgot to mention :
when I switched back (because of that assertion failed problem) from 1.0-stable down to 0.99, my maillog file (I had chosen to log through syslog) was flooded with such messages :
-- dovecot-auth: BUG: login gave a PID of existing connection dovecot-auth: Login process 15 disconnected
--> I cannot understand how this can happen, since, I
. shot down -stable . installed 0.99 instead . started 0.99
Thus clients faced a closed TCP connection.
-- Thomas Hummel | Institut Pasteur <hummel@pasteur.fr> | Pôle informatique - systèmes et réseau
On Thu, Jun 09, 2005 at 12:02:39PM +0200, Thomas Hummel wrote:
Why provide the 'mail_save_crlf' option then ? Granted it's there for performance sake, but can I conclude from what you're saying that it should not be triggered to 'yes' (which is not my case by the way) in 1.0-stables ?
-- Thomas Hummel | Institut Pasteur <hummel@pasteur.fr> | Pôle informatique - systèmes et réseau
On Thu, 2005-06-09 at 12:17 +0200, Thomas Hummel wrote:
I think mail_save_crlf with mbox writes CRs only to message's body, not headers. The problem is only with parsing headers correctly (or maybe it's only CR after From-line.. well, maybe I should look into it and try to fix it finally).
On Thu, 2005-06-09 at 12:02 +0200, Thomas Hummel wrote:
It means Dovecot thought it knew exactly what was in mbox file, so when it had to do some changes to mbox (eg. flag changes or expunges) it jumped right to the beginning of the mail that needed modification. But one of those mails contained X-UID header that was broken or contained an unexpected value. It shouldn't really happen unless some other program goes and modifies the X-UIDs..
Remove them: cat mbox|tr -d '\r' > mbox2;mv mbox2 mbox
Besides, do you mean that I wouldn't have had this problem with a 1.0-tests ?
It's a problem with 1.0-tests too.
Sounds like some 1.0-stable's login-process was left running..
participants (2)
-
Thomas Hummel
-
Timo Sirainen