Re: BUG: Mailbox renaming algorithm got into a potentially infinite loop, aborting

2019-10-16 Thread Timo Sirainen via dovecot
On 25 Sep 2019, at 17.03, Alex Ha via dovecot mailto:dovecot@dovecot.org>> wrote:
> 
> Hi all!
> 
> I have two dovecot servers with dsync replication over tcp.
> Replication works fine except for one user.
> 
> # doveadm replicator status
> username  
>priority fast sync full sync success sync failed
> custo...@example.com 
> none 00:00:33  07:03:23  
> 03:22:31 y 
> 
> If i run dsync manually, i get the following error message:
> 
> dsync-local(custo...@example.com ): Debug: brain 
> M: -- Mailbox renamed, restart sync --
> dsync-local(custo...@example.com ): Error: BUG: 
> Mailbox renaming algorithm got into a potentially infinite loop, aborting
> dsync-local(custo...@example.com ): Error: 
> Mailbox INBOX.Foldername sync: mailbox_rename failed: Invalid mailbox name 
> 'Foldername-temp-1': Missing namespace prefix 'INBOX.'
> 
I've never fixed this because I haven't figured out how to reproduce it. If it 
happens with you all the time, could you try:

 - Get a copy of both replica sides, e.g. under /tmp/replica1 and /tmp/replica2
 - Make sure dsync still crashes with them, e.g. doveadm -o 
mail=maildir:/tmp/replica1 sync maildir:/tmp/replica2
 - Delete all mails and dovecot.index* files (but not dovecot.mailbox.log)
 - Make sure dsync still crashes
 - Send me the replicas - they should no longer contain anything sensitive

As for fixing, you could see if deleting dovecot.mailbox.log from both replicas 
happens to fix this.



Re: [ext] dovecot 2.3.7.2-1~bionic: Performance issues caused by excessive IO to ~/mdbox/mailboxes/INBOX/dbox-Mails/dovecot.index.tmp

2019-10-16 Thread Ralf Hildebrandt via dovecot
* Aki Tuomi via dovecot :

> 2.3.7 does not generate DH keys. It's been removed since 2.3.0

Yes, it was the only periodic process I could think/knew of.

> Is it possible for you to track and find out which process is causing the 
> peak?

Will try. Next hour :)

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | https://www.charite.de



Re: [ext] dovecot 2.3.7.2-1~bionic: Performance issues caused by excessive IO to ~/mdbox/mailboxes/INBOX/dbox-Mails/dovecot.index.tmp

2019-10-16 Thread Aki Tuomi via dovecot


> On 16/10/2019 13:31 Ralf Hildebrandt via dovecot  wrote:
> 
>  
> * Ralf Hildebrandt via dovecot :
> > * Timo Sirainen :
> > 
> > > > BTW: This post is a followup to my "2.3.7 slower than 2.3.6?" post from 
> > > > back in July.
> > > 
> > > Fixed by 
> > > https://github.com/dovecot/core/commit/5e9e09a041b318025fd52db2df25052b60d0fc98
> > >  and will be in the soon-to-be-released v2.3.8.
> > 
> > I stopped 2.3.7, copied over the index files from the ramdisk into
> > the physical "realm" and restarted with a fresh 2.3.8. It probably
> > takes a few days to be absolutely sure.
> 
> So, in general the performance issues are gone.
> 
> But... 
> 
> I'm seeing odd hourly spikes almost every hour, on the hour.
> You might say: Well yes, that's a cronjob sending lots of mails. But
> it isn't. There's not more or less mail coming in at that very moment.
> 
> I suspect something in dovecot running every hour (DH key regeneration?)
> 
> -- 
> Ralf Hildebrandt

2.3.7 does not generate DH keys. It's been removed since 2.3.0

Is it possible for you to track and find out which process is causing the peak?

Aki


Re: [ext] dovecot 2.3.7.2-1~bionic: Performance issues caused by excessive IO to ~/mdbox/mailboxes/INBOX/dbox-Mails/dovecot.index.tmp

2019-10-16 Thread Ralf Hildebrandt via dovecot
* Ralf Hildebrandt via dovecot :
> * Timo Sirainen :
> 
> > > BTW: This post is a followup to my "2.3.7 slower than 2.3.6?" post from 
> > > back in July.
> > 
> > Fixed by 
> > https://github.com/dovecot/core/commit/5e9e09a041b318025fd52db2df25052b60d0fc98
> >  and will be in the soon-to-be-released v2.3.8.
> 
> I stopped 2.3.7, copied over the index files from the ramdisk into
> the physical "realm" and restarted with a fresh 2.3.8. It probably
> takes a few days to be absolutely sure.

So, in general the performance issues are gone.

But... 

I'm seeing odd hourly spikes almost every hour, on the hour.
You might say: Well yes, that's a cronjob sending lots of mails. But
it isn't. There's not more or less mail coming in at that very moment.

I suspect something in dovecot running every hour (DH key regeneration?)

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | https://www.charite.de



Re: BUG: Mailbox renaming algorithm got into a potentially infinite loop, aborting

2019-10-16 Thread Aki Tuomi via dovecot
You could try fix this by manually renaming the problematic folder. This
is a bug though.

Aki

On 15.10.2019 17.29, Alex Ha via dovecot wrote:
> Hi all!
> I'm using Dovecot 2.2.36.4.
> Maybe someone can help, this bug makes the replication unusable for me.
>
> Thanks,
> Alex
>
>
> On Wed, Sep 25, 2019 at 5:03 PM Alex Ha  > wrote:
>
> Hi all!
>
> I have two dovecot servers with dsync replication over tcp.
> Replication works fine except for one user.
>
> # doveadm replicator status
> username  
>   
> priority fast sync full sync success sync failed
> custo...@example.com
>  
>   
> none 00:00:33  07:03:23  03:22:31 y
>
> If i run dsync manually, i get the following error message:
>
> dsync-local(custo...@example.com ):
> Debug: brain M: -- Mailbox renamed, restart sync --
> dsync-local(custo...@example.com ):
> Error: BUG: Mailbox renaming algorithm got into a potentially
> infinite loop, aborting
> dsync-local(custo...@example.com ):
> Error: Mailbox INBOX.Foldername sync: mailbox_rename failed:
> Invalid mailbox name 'Foldername-temp-1': Missing namespace prefix
> 'INBOX.'
>
> For more info see the attached sync_loop.log
>
> Thanks for your help,
>
> Alex
>