On 2019-02-21 22:18, Sami Ketola via dovecot wrote:
On 21 Feb 2019, at 12.23, Hajo Locke via dovecot <[email protected]>
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
