similar to: Handling ENFILE

Hello there! I've migrated our courier-imap production imap/pop server to dovecot 1.0-beta few days ago. In general dovecot performs excellent, but i've encountered several "bugs" in dovecot log: --- snip --- dovecot.log.1.gz:Feb 24 16:05:21 elfstone dovecot: imap(user3 at domain.tld): Maildir /export/mail/domain.tld/user3 sync: UID inserted in the middle of mailbox (47681

I'm not sure how useful this is with optimization turned back on, but here it is anyway. This was just a one off that happened last night: Jan 27 20:49:05 gehenna17.rutgers.edu dovecot: IMAP(user): fscking index file /rci/nqu/rci/u2/user/dovecot/.INBOX/dovecot.index Jan 27 20:49:05 gehenna17.rutgers.edu dovecot: IMAP(user): Panic: file mail-transaction-log-view.c: line 108

Hello Timo, I can reproduce this issue even with mmap_disable and mmap_no_write set to yes, please see the following back trace: $ 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.

i recently helped a friend of mine migrate from imap-uw using mboxes to dovecot on top of Maildirs and came up against two issues. this is quite embarrassing as ive been claiming dovecot is Solid As A Rock(tm) and hasn't ever given me any issues. 1. if dovecot runs out of file descriptors it will loop forever trying to open new logging pipes. the code in question is at line 624 of

I'm seeing this periodically in my logs for a specific user (followed by a backtrace which I've deleted from this post): Panic: file dovecot-1.2.11/src/lib-index/mail-transaction-log-view.c: line 290 (mail_transaction_log_view_set): assertion failed: (min_file_seq != max_file_seq || max_file_seq != view->head->hdr.file_seq || max_file_offset != (uoff_t)-1 || min_file_offset <=

I'm running Dovecot version 1.2.11 and getting this assertion error on a user's mail: Panic: file /home/durket/dovecot-1.2.11/src/lib-index/mail-transaction-log-view.c: line 290 (mail_transaction_log_view_set): assertion failed: (min_file_seq != max_file_seq || max_file_seq != view->head->hdr.file_seq || max_file_offset != (uoff_t)-1 || min_file_offset <=

Hi all. Looking at previous weeks logs I discovered strange errors: "file mail-transaction-log-view.c: assertion failed" dovecot v 1.0.12 Server is hosting more than 500 virtual users. It is compleate dovecot error log; only my own mailbox is affected ...and imap folder affected is "dovecots mailing list" :) While "Corrupted transaction log file" as far as I know

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, After having moved to using Apple mail.app for offline imap reading (served by a dovecot 1.0-test59 server), I noticed the following in the logs: Feb 14 13:52:48 top dovecot: 3102(schmitta): file mail-transaction-log-view.c: line 86 (mail_transaction_log_view_set): assertion failed: (min_file_seq <= max_file_seq) Is this bad? Would

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 dovecot: Jan 18 10:48:39 Error: IMAP(bfg at noviforum.si): file mail-transaction-log-view.c: line 138 (mail_transaction_log_view_set): assertion failed: (min_file_seq != max_file_seq ~ || min_file_offset <= max_file_offset) dovecot: Jan 18 10:48:39 Error: child 18837 (imap) killed with signal 6 dovecot: Jan 18 10:48:52 Info: imap-login: Login:

GNU gdb 6.7.1-debian Copyright (C) 2007 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as

I setup new server with dovecot 2.1.12 and mboxes from backup (moboxes was used with dovecot 1.1.6). OS: FreeBSD 8.3-STABLE, amd64. All index files from dovecot 1.1.6 has been deleted. Some times dovecot processes aborted. E. g. Jan 25 03:01:52 ost dovecot: lda(user at example.ru): Panic: file mail-transaction-log-file.c: line 1694 (mail_transaction_log_file_map): assertion failed:

I've just updated from 1.0.14 to 1.1.1 (Maildirs). According to <URL:http://wiki.dovecot.org/Upgrading/1.1>, "dovecot-uidlist file is in a new format. The old format is automatically converted to new one." When I try to delete a message (which moves it to the IMAP Trash folder), I get the following looping sequence of errors until I cancel the delete operation in the mail

I see the following history in my log during message delivery: Mar 1 13:35:09 mailserver postfix/pickup[21464]: 5FAFC2A002: uid=0 from=<root> Mar 1 13:35:09 mailserver postfix/cleanup[21526]: 5FAFC2A002: message-id=<20090301213509.5FAFC2A002 at mailserver.amfeslan.local> Mar 1 13:35:09 mailserver postfix/qmgr[21429]: 5FAFC2A002: from=<root at mailserver.amfeslan.local>,

Hi all, I upgraded to dovecot 1.1.6 to be able to use NFS. Got a little issue: I can't move mail to another IMAP folder (so I can't delete to: moving to .trash does not work. Error message Oct 31 11:07:45 jozua-mailserver dovecot: IMAP(nicolette at kerknet.org): fdatasync_path(/var/mail/kerknet.org/nicolette/Maildir/.Trash/cur) failed: Invalid Argument I tried to use ll

http://dovecot.org/test/ Just mbox fixes since 1.0-test16. The logic is simpler and more correct now. Can anyone break it anymore? I actually tested it a while with Evolution and several mailboxes and it didn't break at least immediately. :) Now maybe a few more days and I dare trying this thing myself with my real mboxes (yes, I'm still using them). Dovecot mailing list archives could

Hello all! dovecot 1.1.6 Use lazy_expunge plugin call core on connect. Core: bt full #0 lazy_expunge_mail_expunge (_mail=0x2ac06e9b89e8) at lazy-expunge-plugin.c:103 lt = (struct lazy_expunge_transaction *) 0x2ac06e9b86e0 deststorage = <value optimized out> #1 0x000000000041cefc in imap_expunge (box=0x2ac06e988de8, next_search_arg=0x0) at imap-expunge.c:31 ctx =

We recently upgraded from Dovecot 1.2.4 to 1.2.6 (with the sieve patches of course). Everything has been running quite well since the upgrade. The occasional issue with assert-crashing when expunging has gone away. However, one of our users seems to have triggered a new issue. She's been the only one to see it, but whenever she logs in, her imap process segfaults immediately. It appears that

I've attached two backtraces, one from a segfault and another from an assertion error in imap. I've seen a couple of the same assertion and this is the only segfault. It looks like they could be related. They both have to do with indexing anyway... The code is from CVS as of May 30. The segfault happened while imap was doing searches for my pine filters. I've also noticed that in

On Sat, Aug 06, 2016 at 03:43:48AM +0000, Eric Wong wrote: > Eric Wong <e at 80x24.org> wrote: > > I'm trying to test a trivial patch to set FD_CLOEXEC on the > > flintlock lockfd when using F_OFD_SETLK > > Fwiw, this is the patch I was originally going to test. > (but now I see maybe my F_SETFD might only need to be > called on F_OFD_SETLK success)

Hello List, We just migrated from a PPC Xserve to an Intel Xserve. I used "rsync" to bring everyone's home directories over, and in the back of my mind wondered about how it would handle the binary index files... only one way to find out! :) Once I tried to login to IMAP, I got the following results: May 6 19:46:48 posh dovecot[1169]: IMAP(cabel): Rebuilding index file