similar to: ManageSieve OOM with Huge Folders

An email came to several users but one user didn't receive it and we got 'Mail delivery failed' message. As I see from the log below, there were broken index file. Then dovecot repaired that index and we got the error: Panic: file mail-index-sync-update.c: line 1013 (mail_index_sync_map): assertion failed: (map->hdr.indexid == index->indexid || map->hdr.indexid == 0) It was

Op 08/05/2018 om 10:34 schreef Olaf Hopp: > Hi, > > I had an email with 58 recipients in the "To" and 13 in the "CC" > Delivering it from exim to dovecot lmtp panics (see below) > Panic: file smtp-address.c: line 533 (smtp_address_write): assertion > failed: (smtp_char_is_qpair(*p)) > > # 2.3.1 (c5a5c0c82): /etc/dovecot/dovecot.conf > # Pigeonhole

Hi again, we've been trying dovecot 2.2 in our setup and we see thousands of messages like these : Jul 4 12:29:47 pop01 dovecot: lmtp(2899): Debug: auth input: rigakis2 at otenet.gr home=/var/mail/folders/U/9/5/rigakis2 quota_rule=*:storage=50M uid=531846 gid=100 mail=mbox:~/:INBOX=/var/mail/U/9/5 /rigakis2:INDEX=/indexes/4/1/b/rigakis2 at otenet.gr Jul 4 12:29:47 pop01 dovecot:

Hi I was doing some migration from a 1.2 installation to a 2.1. While testing my new installation dovecot crashed at two test-cases constantly with with a "Panic: Trying to allocate 0 bytes" message. Both times it was because I was using a wrong group (or none) in my config. The output I got by dovecot was not that helpful. I only figured it out, that it has something to do with the

Hi, I had an email with 58 recipients in the "To" and 13 in the "CC" Delivering it from exim to dovecot lmtp panics (see below) Panic: file smtp-address.c: line 533 (smtp_address_write): assertion failed: (smtp_char_is_qpair(*p)) # 2.3.1 (c5a5c0c82): /etc/dovecot/dovecot.conf # Pigeonhole version 0.5.devel (61b47828) # OS: Linux 2.6.32-696.23.1.el6.x86_64 x86_64 CentOS

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nov 25 22:25:39 dancol dovecot: master: Error: service(imap): child 25115 killed with signal 6 (core dumps disabled) Nov 25 22:25:59 dancol dovecot: imap(dancol): Panic: file mail-search-build.c: line 59 (mail_search_build_key_int): assertion failed: (sarg->value.subargs != NULL) Nov 25 22:25:59 dancol dovecot: imap(dancol): Error: Raw backtrace:

December 28, 2017 12:43 PM, "Fabian A. Santiago" <fsantiago at garbage-juice.com> wrote: > December 28, 2017 12:14 PM, "Aki Tuomi" <aki.tuomi at dovecot.fi> wrote: > >>> On December 28, 2017 at 7:07 PM "Fabian A. Santiago" <fsantiago at garbage-juice.com> wrote: >>> >>> Hello, >>> >>> After

Hi Everybody, I'm using dovecot 2.1.14 from http://xi.rename-it.nl/debian/ with debian squeeze stable. In general, sieve works fine for me, but "addheader :last ..." from the editheader extension causes a crash when it processes a message. I was able to narrow this down a bit: It only happens if "addheader :last" is the first editheader command executed in a script.

On 01/11/2018 12:18 PM, Aki Tuomi wrote: > > On 11.01.2018 12:09, CP wrote: >> On 01/11/2018 11:49 AM, Aki Tuomi wrote: >>> On 11.01.2018 11:45, CP wrote: >>>> Hello list, >>>> >>>> I'm trying to setup sieve on a Debian 9 install with virtual users. >>>> Perhaps I'm getting old, but I can't figure out why managesieve

Yep On 10.08.2018 11:06, davide marchi wrote: > Thanks Aki for your quick response!! I'm sorry, so i have to compile > and install dovecot version 2.2.36 before compiling and install > pigeonhole 0.4.24? If so sorry for my noob approach > > Il giorno ven 10 ago 2018 alle ore 09:55 Aki Tuomi > <aki.tuomi at dovecot.fi <mailto:aki.tuomi at dovecot.fi>> ha scritto:

building, dovecot-2.0, HEAD:10054:5cb162da8708 dovecot-2.0-sieve, 1051:1d194d46d6e6 both build fine. @, dovecot-2.0-managesieve, 159:2236331aa0a3 cd /usr/local/src/dovecot-2.0-managesieve/ ./configure \ --with-dovecot=/usr/local/src/dovecot-2.0 \ --with-dovecot-sieve=/usr/local/src/dovecot-2.0-sieve make fails @, ... gcc -DHAVE_CONFIG_H -I. -I../..

Hi i have a problem compiling as mantioned on object of this mail: i'm changing dovecot on my debian 6 from version 2.2.32 to 2.2.36 and pigeonhole from 0.4.20 to 0.4.24 this is output of dovecot -n for listing versions installed dovecot -n # 2.2.32 (dfbe293d4): /usr/local/etc/dovecot/dovecot.conf # Pigeonhole version 0.4.20 (7cd71ba) # OS: Linux 2.6.32-5-amd64 x86_64 Debian 6.0.10 i have

when .dovecot.sieve is a symlink (which it is in my case) a warning is written to the error log file, but it still works. Dec 12 10:02:33 managesieve(tester at domain.com): Warning: sieve-storage: Active sieve script symlink /srv/vmail/sieve/domain.com/tester/.dovecot.sieve is broken: invalid/unknown path to storage (points to ingo.sieve). root at

Can you provide us gdb bt full dump? gdb /usr/libexec/dovecot/replicator /path/to/core on some systems, it's /usr/lib/dovecot/replicator Aki On 21.03.2017 23:48, Daniel Miller wrote: > I have the following in my log: > > Mar 21 14:46:59 bubba dovecot: replicator: Panic: data stack: Out of > memory when allocating 1073741864 bytes > Mar 21 14:46:59 bubba dovecot: replicator:

sysctl kernel.core_pattern usually indicates where cores are placed. If it says 'core' you are probably not gonna find it. Aki On 22.03.2017 18:11, Daniel Miller wrote: > Where would I find the core file? I'm not finding anything obvious. > > The replicator path is /usr/local/libexec/dovecot/replicator > > Daniel > > On 3/22/2017 12:52 AM, Aki Tuomi wrote:

Am 12.02.2015 um 15:47 schrieb Martin ?tefany: > Hello, > > I've ran into problem with Dovecot and dsync replication. Everything > works perfectly, including replication of sieve scripts, except fact > that if user activates the 'managesieve' ruleset (I'm using currently > Roundcubemail) on "mail1" host, it wouldn't be activated on

Think I got it: #0 0x00007fddaf597c37 in __GI_raise (sig=sig at entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x00007fddaf59b028 in __GI_abort () at abort.c:89 #2 0x00007fddaf9c0c86 in default_fatal_finish (type=<optimized out>, status=status at entry=0) at failures.c:201 #3 0x00007fddaf9c0d6e in i_internal_fatal_handler (ctx=0x7fff7197d000, format=<optimized out>,

Sorry for the re-post - just want to make sure you saw this: #0 0x00007fddaf597c37 in __GI_raise (sig=sig at entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x00007fddaf59b028 in __GI_abort () at abort.c:89 #2 0x00007fddaf9c0c86 in default_fatal_finish (type=<optimized out>, status=status at entry=0) at failures.c:201 #3 0x00007fddaf9c0d6e in i_internal_fatal_handler

Where would I find the core file? I'm not finding anything obvious. The replicator path is /usr/local/libexec/dovecot/replicator Daniel On 3/22/2017 12:52 AM, Aki Tuomi wrote: > Can you provide us gdb bt full dump? > > gdb /usr/libexec/dovecot/replicator /path/to/core > > on some systems, it's /usr/lib/dovecot/replicator > > Aki > > On 21.03.2017 23:48,

I have the following in my log: Mar 21 14:46:59 bubba dovecot: replicator: Panic: data stack: Out of memory when allocating 1073741864 bytes Mar 21 14:46:59 bubba dovecot: replicator: Error: Raw backtrace: /usr/local/lib/dovecot/libdovecot.so.0(+0x97c90) [0x7f4638a7cc90] -> /usr/local/lib/dovecot/libdovecot.so.0(+0x97d6e) [0x7f4638a7cd6e] ->