Hi!> Somehow Dovecot thinks that the mbox file changed under it..Yes. And it's probably right, but I wonder what could have changed it. I looked around inotify and it seems there is no way to let a file being watched and get program names/pids of processes accessing it.> These mbox corruptions are usually pretty difficult to reproduce (= impossible to fix without ability to reproduce). You could try if you can (reliably) reproduce it in some way, e.g.:I can reproduce them multiple times a day :-). But not on command, and probably not on another machine, I know...> 1. Create a test folder: doveadm mailbox create -u krakonos testbox > 2. Use some combination of: > * Save mail(s) to test folder: cat some-mails | doveadm save -u krakonos testbox > * Try to read mails from test folder: doveadm fetch -u krakonos text mailbox testbox > /dev/nullWell, that's something. doveadm-save doesn't have a manpage, and there is nothing about it on wiki. Is it something new? Also, it doesn't seem to work.> > The fetch should print similar errors to stderr in some way. I attempted to reproduce this way with your msg-error.mbox, but it worked ok. >Thinking about it, it might be that I'm fetching the message just as dovecot delivers another one. Is it possible that fcntl locking is just not working? I'm running a bit older kernel, if that could play a role in it. I'll try to enable dotlock even on read and see if the problem persists. -- S pozdravem Ladislav "Krakono?" L?ska http://www.krakonos.org/
> On October 20, 2016 at 8:03 PM Ladislav Laska <laska at kam.mff.cuni.cz> wrote: > > > Hi! > > > Somehow Dovecot thinks that the mbox file changed under it.. > > Yes. And it's probably right, but I wonder what could have changed it. I > looked around inotify and it seems there is no way to let a file being > watched and get program names/pids of processes accessing it. > > > These mbox corruptions are usually pretty difficult to reproduce (= impossible to fix without ability to reproduce). You could try if you can (reliably) reproduce it in some way, e.g.: > > I can reproduce them multiple times a day :-). But not on command, and > probably not on another machine, I know... > > > 1. Create a test folder: doveadm mailbox create -u krakonos testbox > > 2. Use some combination of: > > * Save mail(s) to test folder: cat some-mails | doveadm save -u krakonos testbox > > * Try to read mails from test folder: doveadm fetch -u krakonos text mailbox testbox > /dev/null > > Well, that's something. doveadm-save doesn't have a manpage, and there > is nothing about it on wiki. Is it something new? Also, it doesn't seem > to work. > > > > > The fetch should print similar errors to stderr in some way. I attempted to reproduce this way with your msg-error.mbox, but it worked ok. > > > > Thinking about it, it might be that I'm fetching the message just as > dovecot delivers another one. > > Is it possible that fcntl locking is just not working? I'm running a bit > older kernel, if that could play a role in it. I'll try to enable > dotlock even on read and see if the problem persists. > > -- > S pozdravem Ladislav "Krakono?" L?ska http://www.krakonos.org/You could try running lsof in hopes of catching it. Might be rather difficult though. Aki
Well, I tried.
for i in {1..50}; do echo x | mail -s test krakonos+test at krakonos.org;
done
and running lsof. Didn't catch a single lockfile. lsof runs about 1s, so
there is little chance of catching it. However, I was reading the mails
while they were being delivered, and didn't trigger the problem.
I'll let it happen once more, so I know it's still reproducible and add
dotfile locks even for read, and see if it helps.
Or is it possible to enable lock debugging, or perhaps run it completely
synchronized (I don't have a lot of traffic, so a little slowdown isn't
an issue).
On Thu, Oct 20, 2016 at 08:20:51PM +0300, Aki Tuomi
wrote:>
> > On October 20, 2016 at 8:03 PM Ladislav Laska <laska at
kam.mff.cuni.cz> wrote:
> >
> >
> > Hi!
> >
> > > Somehow Dovecot thinks that the mbox file changed under it..
> >
> > Yes. And it's probably right, but I wonder what could have changed
it. I
> > looked around inotify and it seems there is no way to let a file being
> > watched and get program names/pids of processes accessing it.
> >
> > > These mbox corruptions are usually pretty difficult to reproduce
(= impossible to fix without ability to reproduce). You could try if you can
(reliably) reproduce it in some way, e.g.:
> >
> > I can reproduce them multiple times a day :-). But not on command, and
> > probably not on another machine, I know...
> >
> > > 1. Create a test folder: doveadm mailbox create -u krakonos
testbox
> > > 2. Use some combination of:
> > > * Save mail(s) to test folder: cat some-mails | doveadm save -u
krakonos testbox
> > > * Try to read mails from test folder: doveadm fetch -u krakonos
text mailbox testbox > /dev/null
> >
> > Well, that's something. doveadm-save doesn't have a manpage,
and there
> > is nothing about it on wiki. Is it something new? Also, it doesn't
seem
> > to work.
> >
> > >
> > > The fetch should print similar errors to stderr in some way. I
attempted to reproduce this way with your msg-error.mbox, but it worked ok.
> > >
> >
> > Thinking about it, it might be that I'm fetching the message just
as
> > dovecot delivers another one.
> >
> > Is it possible that fcntl locking is just not working? I'm running
a bit
> > older kernel, if that could play a role in it. I'll try to enable
> > dotlock even on read and see if the problem persists.
> >
> > --
> > S pozdravem Ladislav "Krakono?" L?ska
http://www.krakonos.org/
>
> You could try running lsof in hopes of catching it. Might be rather
difficult though.
>
> Aki
--
S pozdravem Ladislav "Krakono?" L?ska
http://www.krakonos.org/