similar to: 2.3.1 Replication is throwing scary errors

Ah yes. The hash I put below is wrong but the commit message I quoted was right. This is the last known working good commit, which was on Mar 6: https://github.com/dovecot/core/commit/ff5d02182573b1d4306c2a8c36605c98f217ef3b "doveadm: Unref header search context after use Fixes memory leak, found by valgrind" I've subsequently been able to determine that the bad commit was one of

Hi, > ------------------------------ > > Message: 2 > Date: Mon, 2 Apr 2018 22:06:07 +0200 > From: Michael Grimm <trashcan at ellael.org> > To: Dovecot Mailing List <dovecot at dovecot.org> > Subject: 2.3.1 Replication is throwing scary errors > Message-ID: <29998016-D62F-4348-93D1-613B13DA90DB at ellael.org> > Content-Type: text/plain; charset=utf-8

Hi all, New to the mailing lists but have joined up because of above */2.3.1 Replication is throwing scary errors /*Brief system configuration ??? MX1 - Main ??? ??? Freebsd 11.1-Release-p9 ??? ??? Hosted on a Vultr VM in Sydney AU ??? ??? MTA = Postfix 3.4-20180401 ??? ??? Dovecot = 2.3.1 ??? ??? File system = ufs ??? MX2 - Backup ??? ??? Freebsd 11.1-Release-p9 ??? ???? Running on

Hi [This is Dovecot 2.3.1 at FreeBSD STABLE-11.1 running in two jails at distinct servers.] I did upgrade from 2.2.35 to 2.3.1 today, and I do become pounded by error messages at server1 (and vice versa at server2) as follows: | Apr 2 17:12:18 <mail.err> server1.lan dovecot: doveadm: Error: dsync(server2.lan): I/O has stalled, \ no activity for 600 seconds (last sent=mail_change, last

Seems you got the hash wrong... You probably mean 4a1e2e8e85ad5d4ab43496a5f3cd6b7ff6ac5955, which fixes a memory leak, but does not release sync lock. Interesting if this commit fixes the issue. Looking at the sync code, where the lock is made / released, there is only one commit recently, which is 8077d714e11388a294f1583e706152396972acce and that one creates home directory if missing. Would

Hi Reuben, thank you for digging into this issue reported by some users, now. I wonder if there are users out there using master/master replication with 2.3.1 dovecot that do *NOT* observe the errors mentioned in this thread? Please report, please. And, pleas have a closer look for It would be interesting to know if these failures are seen by a subset of users, only. And please have a look

Hi, [Formatting is a bit rough, replying from a trimmed digest email] > Message: 1 > Date: Fri, 6 Apr 2018 15:04:35 +0200 > From: Michael Grimm <trashcan at ellael.org> > To: Dovecot Mailing List <dovecot at dovecot.org> > Subject: Re: 2.3.1 Replication is throwing scary errors > Message-ID: <E7E7A927-68F8-443F-BA59-E66CED8FE878 at ellael.org> >

Hi, I've been seeing errors logged for some time with replication processes, whereby replication sessions seem to be timing out periodically. This is with dovecot version 2.3.10.1 (a3d0e1171) and both are Gentoo x86_64. After some investigation I've determined that these timeouts are only ever occurring with tcps as the replication connection type. These errors never occur if

Should be fixed by https://github.com/dovecot/core/commit/a952e178943a5944255cb7c053d970f8e6d49336 <https://github.com/dovecot/core/commit/a952e178943a5944255cb7c053d970f8e6d49336> -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://dovecot.org/pipermail/dovecot/attachments/20180606/996cfe38/attachment.html>

Reuben Farrelly <reuben-dovecot at reub.net> wrote: > Checking in - this is still an issue with 2.3-master as of today (2.3.devel (3a6537d59)). That doesn't sound good, because I did hope that someone has been working on this issue ... > I haven't been able to narrow the problem down to a specific commit. The best I have been able to get to is that this commit is relatively

Am 2018-06-07 07:34, schrieb Remko Lodder: > On 7 Jun 2018, at 07:21, Reuben Farrelly <reuben-dovecot at reub.net> > wrote: >> Still not quite right for me. >> >> Jun 7 15:11:33 thunderstorm.reub.net dovecot: doveadm: Error: >> dsync(lightning.reub.net): I/O has stalled, no activity for 600 >> seconds (last sent=mail, last recv=mail (EOL)) >>

Still not quite right for me. Jun 7 15:11:33 thunderstorm.reub.net dovecot: doveadm: Error: dsync(lightning.reub.net): I/O has stalled, no activity for 600 seconds (last sent=mail, last recv=mail (EOL)) Jun 7 15:11:33 thunderstorm.reub.net dovecot: doveadm: Error: Timeout during state=sync_mails (send=mails recv=recv_last_common) I'm not sure if there is an underlying replication error

Hello, I have two mail servers and am also experiencing sporadic replication errors over tcps, similar to Reuben. Each server is running Dovecot 2.3.11.3 (502c39af9) on Debian 10.6. *Log entries from MX1* Nov 18 00:39:26 mx1 dovecot: dsync-local(user at example.com)<Ow3zAjWxtF+TDgAAPHKnuQ>: Error: dsync(mx2.example.com): I/O has stalled, no activity for 600 seconds (last sent=mailbox,

Hey all, I've been affected by these replication issues too and finally downgraded back to 2.2.35 since some newly created virtual domains/mailboxes weren't replicated *at all* due to the bug(s). My setup is more like a master-slave, where I only have a rather small virtual machine as the slave host, which is also only MX 20. The idea was to replicate all mails through dovecot and

On 31. May 2018, at 18:09, Remko Lodder <remko at FreeBSD.org> wrote: >> On 31 May 2018, at 17:52, Michael Grimm <trashcan at ellael.org> wrote: >> I would love to get some feedback from the developers regarding: >> >> #) are commercial customers of yours running 2.3 master-master replication without those issues reported in this thread? >> #) do you get

Daniel, On Sat, May 30, 2015 at 09:26:32AM -0300, Daniel van Ham Colchete wrote: > B, > I really like the idea of N-way replication. Pairs are ugly, they cost double! Even if you have 20 servers, when one goes down all that IO traffic goes to just one. > So, what I did here was a (kind of) DHT-based n-way replication, where the node for the second copy is independent of where

> On 7 Jun 2018, at 07:21, Reuben Farrelly <reuben-dovecot at reub.net> wrote: > > Still not quite right for me. > > Jun 7 15:11:33 thunderstorm.reub.net dovecot: doveadm: Error: dsync(lightning.reub.net): I/O has stalled, no activity for 600 seconds (last sent=mail, last recv=mail (EOL)) > Jun 7 15:11:33 thunderstorm.reub.net dovecot: doveadm: Error: Timeout during

Hi there: I'm doing a backup of some of my machines via rsync, and I have the next problem: ------------------ [Tue Feb 22 02:51:13 CET 2011] /usr/bin/rsync -az --delete --numeric-ids --relative --delete-excluded --rsh=/usr/bin/ssh root at server1:/var/spool/exim /data/backups/server1 [Tue Feb 22 02:51:28 CET 2011] /usr/bin/rsync -az --delete --numeric-ids --relative --delete-excluded

Aaaaand I forgot to CC the list, sorry for that, it's way too early in the morning :P On 07.06.18 - 07:39, Thore B?decker wrote: > What does the output of these two commands show after that error has > been logged? > > doveadm replicator status > > doveadm replicator dsync-status > > If there are *waiting failed* requests, that never make it "through" >

> On 31 May 2018, at 17:52, Michael Grimm <trashcan at ellael.org> wrote: > > Reuben Farrelly <reuben-dovecot at reub.net> wrote: > >> Checking in - this is still an issue with 2.3-master as of today (2.3.devel (3a6537d59)). > > That doesn't sound good, because I did hope that someone has been working on this issue ... > >> I haven't been