http://dovecot.org/test/ - vpopmail authentication fix - many mmap_disable=yes fixes and a few optimizations - pop3 hang fix - mbox fix for "last-uid lost" error (hopefully last one) - mbox fix for losing dirty flag, causing lost message flags mmap_disable=yes seems to be finally working pretty well. There should be no more cache file related errors with it enabled. I'm still seeing "UID inserted in the middle of mailbox" error a couple of times in hour (out of ~320000 logins/h), so mbox code is still not perfect but I'd think it's good enough for normal use :) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://dovecot.org/pipermail/dovecot/attachments/20050514/6f89ab89/attachment-0001.bin>
Hello Timo Sirainen <tss at iki.fi>, Saturday, May 14, 2005, 7:49:02 PM, you wrote: TS> http://dovecot.org/test/ Excuse me if I insist, but what about the detailed logging proposed by Andrey Panin? I found it very useful and, in some cases, fundamental, both for checking and for reporting purposes. Ciao, luigi -- Acting is an art which consists of keeping the audience from coughing.
(05.05.14 kl.20:49) Timo Sirainen skrev f?ljande till dovecot at dovecot.org:> http://dovecot.org/test/ > > - vpopmail authentication fix > - many mmap_disable=yes fixes and a few optimizations > - pop3 hang fixpop3 still hangs for me. Would it be possible to have some code that detected this condition and kickstarted the output (until all the bugs are found) ? Thanks, Jens> - mbox fix for "last-uid lost" error (hopefully last one) > - mbox fix for losing dirty flag, causing lost message flags > > mmap_disable=yes seems to be finally working pretty well. There should > be no more cache file related errors with it enabled. > > I'm still seeing "UID inserted in the middle of mailbox" error a couple > of times in hour (out of ~320000 logins/h), so mbox code is still not > perfect but I'd think it's good enough for normal use :) > >----------------------------------------------------------------------- 'This mail automatically becomes portable when carried.' ----------------------------------------------------------------------- Jens L??s Email: jens.laas at data.slu.se Department of Computer Services, SLU Phone: +46 18 67 35 15 Vindbrov?gen 1 P.O. Box 7079 S-750 07 Uppsala SWEDEN -----------------------------------------------------------------------
Tero Ripattila
2005-May-20 18:38 UTC
Corrupted transaction log file assertion failures (Was: Re: [Dovecot] 1.0-test70)
Hello Timo, Saturday, May 14, 2005, 8:49:02 PM, you [TS] wrote: TS> mmap_disable=yes seems to be finally working pretty well. There should TS> be no more cache file related errors with it enabled. I started to receive these corrupted transaction log file assertion failures, again: dovecot: May 18 16:48:07 Error: IMAP(tero at ripattila.com): Corrupted transaction log file /var/spool/postfix/virtual/ripattila.com/tero/.Mailing Lists.Mulberry.Discussion/dovecot.index.log: Append with UID 5001, but next_uid = 5002 dovecot: May 18 16:48:07 Error: IMAP(tero at ripattila.com): Corrupted transaction log file /var/spool/postfix/virtual/ripattila.com/tero/.Mailing Lists.Mulberry.Discussion/dovecot.index.log: Append with UID 5001, but next_uid = 5002 dovecot: May 18 16:48:07 Error: IMAP(tero at ripattila.com): utime(/var/spool/postfix/virtual/ripattila.com/tero/.Mailing Lists.Mulberry.Discussion/dovecot-uidlist.lock) failed: No such file or directory dovecot: May 18 16:48:07 Warning: IMAP(tero at ripattila.com): Our dotlock file /var/spool/postfix/virtual/ripattila.com/tero/.Mailing Lists.Mulberry.Discussion/dovecot-uidlist.lock was deleted dovecot: May 18 16:48:07 Error: IMAP(tero at ripattila.com): Corrupted transaction log file /var/spool/postfix/virtual/ripattila.com/tero/.Mailing Lists.Mulberry.Discussion/dovecot.index.log: Append with UID 5001, but next_uid = 5002 dovecot: May 18 16:48:07 Error: IMAP(tero at ripattila.com): Corrupted transaction log file /var/spool/postfix/virtual/ripattila.com/tero/.Mailing Lists.Mulberry.Discussion/dovecot.index.log: Append with UID 5001, but next_uid = 5002 dovecot: May 18 16:48:07 Error: IMAP(tero at ripattila.com): Corrupted transaction log file /var/spool/postfix/virtual/ripattila.com/tero/.Mailing Lists.Mulberry.Discussion/dovecot.index.log: Append with UID 5001, but next_uid = 5002 dovecot: May 18 16:48:07 Error: IMAP(tero at ripattila.com): Lost transaction log file /var/spool/postfix/virtual/ripattila.com/tero/.Mailing Lists.Mulberry.Discussion/dovecot.index.log seq 3 I've had two or three similar situations within last two-three days or so. I'm running an OpenBSD 3.6-based snapshot that's practically almost a 3.7-stable one. Thanks, Tero -- Tero Ripattila
Tero Ripattila
2005-May-22 12:32 UTC
Corrupted index cache file: Duplicated field in header: hdr.SUBJECT (Was: Re: [Dovecot] 1.0-test70)
Hi Timo, Saturday, May 14, 2005, 8:49:02 PM, you [TS] wrote: TS> mmap_disable=yes seems to be finally working pretty well. There should TS> be no more cache file related errors with it enabled. Now I get duplicate field in header -error messages, please see the following: dovecot: May 22 15:11:43 Error: IMAP(tero at ripattila.com): Corrupted index cache file /var/spool/postfix/virtual/ripattila.com/tero/dovecot.index.cache: Duplicated field in header: hdr.SUBJECT dovecot: May 22 15:11:43 Error: IMAP(tero at ripattila.com): Corrupted index cache file /var/spool/postfix/virtual/ripattila.com/tero/dovecot.index.cache: invalid field header size dovecot: May 22 15:11:43 Error: IMAP(tero at ripattila.com): Corrupted index cache file /var/spool/postfix/virtual/ripattila.com/tero/dovecot.index.cache: used_file_size too small dovecot: May 22 15:11:46 Error: IMAP(tero at ripattila.com): Corrupted index cache file /var/spool/postfix/virtual/ripattila.com/tero/dovecot.index.cache: Duplicated field in header: hdr.SUBJECT dovecot: May 22 15:11:46 Error: IMAP(tero at ripattila.com): Corrupted index cache file /var/spool/postfix/virtual/ripattila.com/tero/dovecot.index.cache: Duplicated field in header: hdr.SUBJECT dovecot: May 22 15:12:09 Error: IMAP(tero at ripattila.com): Corrupted index cache file /var/spool/postfix/virtual/ripattila.com/tero/dovecot.index.cache: Duplicated field in header: hdr.SUBJECT In general, this -test70 is far more unstable than any of the ten test builds I've been running before. Thanks, Tero -- Tero Ripattila
Tero Ripattila
2005-May-22 12:40 UTC
Problems moving messages (Was: Re: [Dovecot] 1.0-test70)
Hello Timo, Saturday, May 14, 2005, 8:49:02 PM, you [TS] wrote: TS> mmap_disable=yes seems to be finally working pretty well. There should TS> be no more cache file related errors with it enabled. In addition to these two problems I've told about on the list, there's yet another issue that bugs me. I've got a couple of IMAP folders that holds something like 20k messages each of them. When I try to move messages from one to another, both of my e-mail stable e-mail clients, Mulberry and The Bat!, gets stucked and I have to use task manager to kill 'em. When this happens, there's nothing in dovecot.log. And when I check the source and destination folders of this movement operation, there's zero messages copied to destination folder and zero expunged from the source folder. What kind of log would be useful to track this problem down? I can try to get some trace with Mulberry now. backtrace would be nice, but the imap process never dies. Thanks, Tero -- Tero Ripattila
Tero Ripattila
2005-May-22 16:44 UTC
Core dumps when opening an IMAP folder (Was: Re: [Dovecot] 1.0-test70)
Hei Timo,
Saturday, May 14, 2005, 8:49:02 PM, you [TS] wrote:
TS> mmap_disable=yes seems to be finally working pretty well. There should
TS> be no more cache file related errors with it enabled.
Dovecot started to do core dumps when I try to open some particular IMAP
folders, please see the following:
$ ls -l imap.core
-rw------- 1 5303 wheel 20448104 May 22 18:56 imap.core
$ gdb /usr/local/libexec/dovecot/imap /tmp/imap.core
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "i386-unknown-openbsd3.6"...
Core was generated by `imap'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libc.so.34.2...done.
Loaded symbols for /usr/lib/libc.so.34.2
Reading symbols from /usr/libexec/ld.so...done.
Loaded symbols for /usr/libexec/ld.so
#0 0x1c0518e9 in pool_alloconly_clear (pool=0x3c02fe10)
at mempool-alloconly.c:281
281 free(block);
(gdb) bt full
#0 0x1c0518e9 in pool_alloconly_clear (pool=0x3c02fe10)
at mempool-alloconly.c:281
avail_size = 1006829072
#1 0x1c051678 in pool_alloconly_destroy (apool=0x3c02fe10)
at mempool-alloconly.c:109
block = (void *) 0x0
#2 0x1c02b794 in index_header_lookup_deinit (_ctx=0x0)
at index-mail-headers.c:681
No locals.
#3 0x1c04106f in mailbox_header_lookup_deinit (ctx=0x0) at mail-storage.c:381
No locals.
#4 0x1c029ee4 in index_mail_get_special (_mail=0x3c02fa40, field=0)
at index-mail.c:617
data = (struct index_mail_data *) 0x3c02faa4
cache_fields = (struct mail_cache_field *) 0x3c01f500
str = (string_t *) 0x5f
ext_data = (const void *) 0x5f
#5 0x1c01c526 in maildir_mail_get_special (_mail=0x9, field=0)
at maildir-mail.c:167
mbox = (struct maildir_mailbox *) 0x1
flags = 1006828096
fname = 0x3c023088 ""
#6 0x1c040534 in mail_get_special (mail=0x0, field=MAIL_FETCH_IMAP_ENVELOPE)
at mail.c:113
No locals.
#7 0x1c01199c in fetch_envelope (ctx=0x3c023088, mail=0x3c02fa40, context=0x0)
at imap-fetch.c:411
envelope = 0x3c023088 ""
#8 0x1c011572 in imap_fetch (ctx=0x3c023088) at imap-fetch.c:264
handlers = (const struct imap_fetch_context_handler *) 0x3c0231a8
size = 6
ret = 1
#9 0x1c00d708 in cmd_fetch (cmd=0x3c020040) at cmd-fetch.c:165
client = (struct client *) 0x3c020000
ctx = (struct imap_fetch_context *) 0x3c023088
args = (struct imap_arg *) 0x3c021048
search_arg = (struct mail_search_arg *) 0x3c023050
messageset = 0x9 ""
ret = 0
#10 0x1c00fa7d in cmd_uid (cmd=0x3c020040) at cmd-uid.c:19
cmd_name = 0x3c0210f8 "FETCH"
#11 0x1c01023b in client_handle_input (cmd=0x3c020040) at client.c:334
client = (struct client *) 0x3c020000
#12 0x1c010369 in _client_input (context=0x3c020000) at client.c:383
client = (struct client *) 0x3c020000
cmd = (struct client_command_context *) 0x3c020040
#13 0x1c050a68 in io_loop_handler_run (ioloop=0x3c01d000) at ioloop-poll.c:184
data = (struct ioloop_handler_data *) 0x3c0110a0
pollfd = (struct pollfd *) 0x3c01e000
tv = {tv_sec = 0, tv_usec = 572544}
io = (struct io *) 0x3c0353c0
t_id = 2
msecs = 0
ret = 0
call = 1
#14 0x1c050505 in io_loop_run (ioloop=0x3c01d000) at ioloop.c:218
No locals.
#15 0x1c016d37 in main (argc=3, argv=0xcfbefd3c, envp=0xcfbefd4c) at main.c:228
No locals.
(gdb)
I'm currently trying to find out what's so special with these folders
that cannot be opened normally, but havent find anything in common
between them. They all contain something like 20-40k messages.
I have to seriously consider reverting back to -test69 now :-(
Thanks, Tero
--
Tero Ripattila