On 21.2.2019 10.53, Hajo Locke via dovecot wrote:> Hello, > > Am 20.02.2019 um 10:39 schrieb Aki Tuomi via dovecot: >>> On 18 February 2019 09:28 Hajo Locke via dovecot >>> <dovecot at dovecot.org> wrote: >>> >>> >>> Hello, >>> ? ? it seems we need a dovecot developers opinion. May be we hit a >>> bug or cant help ourselves. >>> ? ? > Thanks for your answer. >> Core dump with backtrace would help, if possible to acquire. Please >> refer to https://dovecot.org/bugreport.html for information how to >> get a core dump. >> >> Aki >> > Unfortunately its hard to get a backtrace because dovecot is not > crashing. so it seems to be more a kind of logic problem in code and > no unexpected situation. > yesterday evening i had next incident. I upgraded from 2.2.33.2 to > 2.2.36.1, but same behaviour. Also 2.2.36.1 is tricked by the broken > index and delivers no new mails. it starts delivering if i delete > index files. At this point i cant tell if 2.2.36.1 also has same bug > and writes a damaged index, but very likely.? We dont know this > problems with 2.2.22, between 2.2.22 and 2.2.33.2 a change on > mbox-index code must happend which leads to this big problem. So imapd > cant do what he was created for. > > For next incident i prepared a 2.3.2.1 on base of Ubuntu 18.10 and > will try this. In my opinion this is a major problem and i expect a > lot of affected people with version > 2.2.22 and classic mbox-storage. > > Thanks, > HajoWe consider mbox + procmail setup somewhat edge case, and if the core dump does not point into something more generic, it will probably not get fixed. It is more likely to have this working if you use dovecot-lda/lmtp with sieve instead of procmail. Aki
Hello, Am 21.02.2019 um 10:51 schrieb Aki Tuomi via dovecot:> On 21.2.2019 10.53, Hajo Locke via dovecot wrote: >> Hello, >> >> Am 20.02.2019 um 10:39 schrieb Aki Tuomi via dovecot: >>>> On 18 February 2019 09:28 Hajo Locke via dovecot >>>> <dovecot at dovecot.org> wrote: >>>> >>>> >>>> Hello, >>>> ? ? it seems we need a dovecot developers opinion. May be we hit a >>>> bug or cant help ourselves. >>>> >> Thanks for your answer. >>> Core dump with backtrace would help, if possible to acquire. Please >>> refer to https://dovecot.org/bugreport.html for information how to >>> get a core dump. >>> >>> Aki >>> >> Unfortunately its hard to get a backtrace because dovecot is not >> crashing. so it seems to be more a kind of logic problem in code and >> no unexpected situation. >> yesterday evening i had next incident. I upgraded from 2.2.33.2 to >> 2.2.36.1, but same behaviour. Also 2.2.36.1 is tricked by the broken >> index and delivers no new mails. it starts delivering if i delete >> index files. At this point i cant tell if 2.2.36.1 also has same bug >> and writes a damaged index, but very likely.? We dont know this >> problems with 2.2.22, between 2.2.22 and 2.2.33.2 a change on >> mbox-index code must happend which leads to this big problem. So imapd >> cant do what he was created for. >> >> For next incident i prepared a 2.3.2.1 on base of Ubuntu 18.10 and >> will try this. In my opinion this is a major problem and i expect a >> lot of affected people with version > 2.2.22 and classic mbox-storage. >> >> Thanks, >> Hajo > We consider mbox + procmail setup somewhat edge case, and if the core > dump does not point into something more generic, it will probably not > get fixed. It is more likely to have this working if you use > dovecot-lda/lmtp with sieve instead of procmail. > > Aki > >I think mbox+procmail is a classic setup and wide used and good solution for many usecases. Same setup we use many years. We run ~2 mio mailboxes. our automated systems depends on this setup. creating mailboxes, managing mailboxes, creating automated filterrules, backupsystem to tell something of them. we can not switch our whole mailsetup to work around this bug. How to get a dump if dovecot not crashing but has wrong behaviour? I would like to help and provide useful info, but it depends on kind of problem. I think if a classic setup is not working in dovecot any more, this is a serious problem. Thanks, Hajo
> On 21 Feb 2019, at 12.23, Hajo Locke via dovecot <dovecot at dovecot.org> wrote: > I think mbox+procmail is a classic setup and wide used and good solution for many usecases. Same setup we use many years. > We run ~2 mio mailboxes. our automated systems depends on this setup. creating mailboxes, managing mailboxes, creating automated filterrules, backupsystem to tell something of them. we can not switch our whole mailsetup to work around this bug. > How to get a dump if dovecot not crashing but has wrong behaviour? I would like to help and provide useful info, but it depends on kind of problem. > I think if a classic setup is not working in dovecot any more, this is a serious problem.In you first email to this thread it says:> Feb 8 08:45:37 hostname dovecot[14882]: imap(myuser): Fatal: master: service(imap): child 14135 killed with signal 6 (core dumped)So imap is crashing and even dumping a core. Also I must disagree with your mbox+procmail statement. mbox has always been very unoptimised mailbox format and everyone should be emphasised not to use it. Also that combination has always had problems with indexing and file locking. I would not use it on high volume mailservers. Or even medium volume mailservers. Sami
El 21/02/2019 a las 10:51, Aki Tuomi via dovecot escribi?:> On 21.2.2019 10.53, Hajo Locke via dovecot wrote: >> Hello, >> >> Am 20.02.2019 um 10:39 schrieb Aki Tuomi via dovecot: >>>> On 18 February 2019 09:28 Hajo Locke via dovecot >>>> <dovecot at dovecot.org> wrote: >>>> >>>> >>>> Hello, >>>> ? ? it seems we need a dovecot developers opinion. May be we hit a >>>> bug or cant help ourselves. >>>> >> Thanks for your answer. >>> Core dump with backtrace would help, if possible to acquire. Please >>> refer to https://dovecot.org/bugreport.html for information how to >>> get a core dump. >>> >>> Aki >>> >> Unfortunately its hard to get a backtrace because dovecot is not >> crashing. so it seems to be more a kind of logic problem in code and >> no unexpected situation. >> yesterday evening i had next incident. I upgraded from 2.2.33.2 to >> 2.2.36.1, but same behaviour. Also 2.2.36.1 is tricked by the broken >> index and delivers no new mails. it starts delivering if i delete >> index files. At this point i cant tell if 2.2.36.1 also has same bug >> and writes a damaged index, but very likely.? We dont know this >> problems with 2.2.22, between 2.2.22 and 2.2.33.2 a change on >> mbox-index code must happend which leads to this big problem. So imapd >> cant do what he was created for. >> >> For next incident i prepared a 2.3.2.1 on base of Ubuntu 18.10 and >> will try this. In my opinion this is a major problem and i expect a >> lot of affected people with version > 2.2.22 and classic mbox-storage. >> >> Thanks, >> Hajo > We consider mbox + procmail setup somewhat edge case, and if the core > dump does not point into something more generic, it will probably not > get fixed. It is more likely to have this working if you use > dovecot-lda/lmtp with sieve instead of procmail. > > Aki >Hi Aki, In support of Hajo I've to say that a few days ago I posted a similar issue, and I use dovecot-lda+sieve. My environment has RHEL6 and 7 servers. When I last updated the servers RHEL6 servers mantained 2.2.10-1_14.el6.x86_64 version, while RHEL7 updated dovecot from 2.2.10-8.el7.x86_64 to 2.2.36-3.el7.x86_64. When the RHEL7 servers (used for sympa) processed a message for a user, its indexes were corrupted, and the user could't access his inbox through webmail, so I had to delete dovecot.* files from the user mail path to get it working again. My solution was to downgrade dovecot and dovecot-pigeonhole back to 2.2.10-8.el7.x86_64 Regards *Gonzalo * -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://dovecot.org/pipermail/dovecot/attachments/20190221/39591e88/attachment.html>
For replicated servers I'm stuck with 2.2.33.2 because of pop3/dsync problems, but on single servers I have no index problems after upgrading to dovecot-2.2.35-1.el7.centos.0.x86_64 or dovecot-2.2.36-3.el7.x86_64. All servers run CentOS 7 (RHEL 7) but use lmtp delivery with mdbox and sieve. Maybe something in dovecot-lda has changed? Best regards Gerald> Am 21.02.2019 um 14:12 schrieb Gonzalo Palacios Goicolea via dovecot <dovecot at dovecot.org>: > > El 21/02/2019 a las 10:51, Aki Tuomi via dovecot escribi?: >> On 21.2.2019 10.53, Hajo Locke via dovecot wrote: >>> Hello, >>> >>> Am 20.02.2019 um 10:39 schrieb Aki Tuomi via dovecot: >>>>> On 18 February 2019 09:28 Hajo Locke via dovecot >>>>> <dovecot at dovecot.org> <mailto:dovecot at dovecot.org> wrote: >>>>> >>>>> >>>>> Hello, >>>>> it seems we need a dovecot developers opinion. May be we hit a >>>>> bug or cant help ourselves. >>>>> >>> Thanks for your answer. >>>> Core dump with backtrace would help, if possible to acquire. Please >>>> refer to https://dovecot.org/bugreport.html <https://dovecot.org/bugreport.html> for information how to >>>> get a core dump. >>>> >>>> Aki >>>> >>> Unfortunately its hard to get a backtrace because dovecot is not >>> crashing. so it seems to be more a kind of logic problem in code and >>> no unexpected situation. >>> yesterday evening i had next incident. I upgraded from 2.2.33.2 to >>> 2.2.36.1, but same behaviour. Also 2.2.36.1 is tricked by the broken >>> index and delivers no new mails. it starts delivering if i delete >>> index files. At this point i cant tell if 2.2.36.1 also has same bug >>> and writes a damaged index, but very likely. We dont know this >>> problems with 2.2.22, between 2.2.22 and 2.2.33.2 a change on >>> mbox-index code must happend which leads to this big problem. So imapd >>> cant do what he was created for. >>> >>> For next incident i prepared a 2.3.2.1 on base of Ubuntu 18.10 and >>> will try this. In my opinion this is a major problem and i expect a >>> lot of affected people with version > 2.2.22 and classic mbox-storage. >>> >>> Thanks, >>> Hajo >> We consider mbox + procmail setup somewhat edge case, and if the core >> dump does not point into something more generic, it will probably not >> get fixed. It is more likely to have this working if you use >> dovecot-lda/lmtp with sieve instead of procmail. >> >> Aki >> > Hi Aki, > In support of Hajo I've to say that a few days ago I posted a similar issue, and I use dovecot-lda+sieve. My environment has RHEL6 and 7 servers. When I last updated the servers RHEL6 servers mantained 2.2.10-1_14.el6.x86_64 version, while RHEL7 updated dovecot from 2.2.10-8.el7.x86_64 to 2.2.36-3.el7.x86_64. When the RHEL7 servers (used for sympa) processed a message for a user, its indexes were corrupted, and the user could't access his inbox through webmail, so I had to delete dovecot.* files from the user mail path to get it working again. > My solution was to downgrade dovecot and dovecot-pigeonhole back to 2.2.10-8.el7.x86_64 > Regards > Gonzalo >-------------- next part -------------- An HTML attachment was scrubbed... URL: <https://dovecot.org/pipermail/dovecot/attachments/20190221/85296ca3/attachment-0001.html>