Displaying 20 results from an estimated 10000 matches similar to: "2.3.1 Replication is throwing scary errors"
2018 May 06
0
2.3.1 Replication is throwing scary errors
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
2018 May 06
1
2.3.1 Replication is throwing scary errors
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
2018 May 06
0
2.3.1 Replication is throwing scary errors
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
2018 Apr 03
3
2.3.1 Replication is throwing scary errors
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
2018 May 06
2
2.3.1 Replication is throwing scary errors
Hi Andy,
Funny you say that - I've been testing this very problem for some time
today to narrow down the commits where I think the problem started
occurring.
So far I have been able to roll forward to commit from git:
74ef8506dcb946acc42722683e49fdcb964eed19
>> "doveadm: Unref header search context after use" . So far I have
been running on that code for a few hours
2018 Apr 02
1
2.3.1 Replication is throwing scary errors
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
2018 May 06
3
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
2018 Jun 01
0
2.3.1 Replication is throwing scary errors
On 1/06/2018 2:47 AM, Michael Grimm wrote:
> 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
2018 May 31
2
2.3.1 Replication is throwing scary errors
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
2018 May 31
0
2.3.1 Replication is throwing scary errors
> 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
2018 Jun 07
1
2.3.1 Replication is throwing scary errors
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))
>>
2018 Jun 07
0
2.3.1 Replication is throwing scary errors
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"
>
2018 Jun 07
0
2.3.1 Replication is throwing scary errors
> 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
2018 Jun 07
4
2.3.1 Replication is throwing scary errors
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
2018 Jun 06
7
2.3.1 Replication is throwing scary errors
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>
2018 May 30
0
2.3.1 Replication is throwing scary errors
Hi,
Checking in - this is still an issue with 2.3-master as of today
(2.3.devel (3a6537d59)).
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
good (not perfect but good enough):
d9a1a7cbec19f4c6a47add47688351f8c3a0e372 (from Feb 19, 2018)
whereas this commit:
2018 May 06
2
2.3.1 Replication is throwing scary errors
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
2018 May 31
2
2.3.1 Replication is throwing scary errors
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
2018 Jun 07
0
2.3.1 Replication is throwing scary errors
Am 2018-06-07 08:48, schrieb Remko Lodder:
> On Thu, Jun 07, 2018 at 08:04:49AM +0200, Michael Grimm wrote:
>> Conclusion: After 12 hours of running a patched FBSD port I do get
>> those
>> error messages but replictaion seems to work now. But, I still have
>> the
>> feeling that there might something else going wrong.
>
> I agree with that. Are you using
2018 Jun 13
1
2.3.1 Replication is throwing scary errors
Hey all,
almost 48h ago I upgraded both my instances to 2.3.1 again to see if
the new patches would fix the replication issues for me.
So far, the result is: great.
I haven't been able to provoke any kind of I/O stall or persisting
queued/failed resync requests in my replication setup.
Newly added users are replicated instantly upon the first received
mails and the home directory gets