index problems after update
list+dovecot at gcore.biz
Thu Feb 21 16:05:33 EET 2019
For replicated servers I'm stuck with 184.108.40.206 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
All servers run CentOS 7 (RHEL 7) but use lmtp delivery with mdbox and sieve.
Maybe something in dovecot-lda has changed?
> 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:
>>> 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:
>>>>> 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.
>>> 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 220.127.116.11 to
>>> 18.104.22.168, but same behaviour. Also 22.214.171.124 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 126.96.36.199 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 188.8.131.52 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 184.108.40.206 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.
>> 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.
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dovecot