On 2019-02-21 22:18, Sami Ketola via dovecot wrote:
On 21 Feb 2019, at 12.23, Hajo Locke via dovecot <dovecot@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.
Not directly affected by this issue since I'm not using mbox for any production system nor have I for many years. And it'd take a lot of effort to convince me to use mbox for anything someone would even dare to classify, even remotely, as "production". But if I understand OP's point of view correctly, he's not arguing necessarily for or against a specific mailbox format. Instead, he's flagging a regression and people will be very reluctant to upgrade or even adopt a certain feature in a new release of a product if regressions are seen as acceptable. Something that previously worked in an otherwise unchanged environment stopped working after an upgrade and this is a regression. Trying to convince people to move away from mbox is a very sensible approach, I'm all for it, but in cases like this not practical.
-- Adi Pircalabu