similar to: 2.3.1 Replication is throwing scary errors

Displaying 20 results from an estimated 1000 matches similar to: "2.3.1 Replication is throwing scary errors"

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 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 Apr 08
0
2.3.1 Replication is throwing scary errors
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> >
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
2020 Jun 13
2
Dovecot Replication Errors (only) when using tcps: as the mail_replica Protocol
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
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
2013 Nov 05
1
Problem migration from cyrus with imapc
Hi all, i have problem with namespace when i try to migrate from cyrus to dovecot with imapc. If i login to the old cyrus i get: telnet 192.168.8.164 143 Trying 192.168.8.164... Connected to 192.168.8.164. Escape character is '^]'. * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE STARTTLS AUTH=PLAIN AUTH=LOGIN AUTH=DIGEST-MD5 AUTH=CRAM-MD5] Dovecot ready. a
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 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 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 Feb 02
1
Dovecot 2.3.0, Panic: file mailbox-attribute.c: line 362 (mailbox_attribute_get_stream): assertion failed: (value_r->value != NULL || value_r->value_stream != NULL)
Hi at all, I have a RHEL7 server with Dovecot 2.3.0 (new installation). I've a problem when trying to dsync from a Dovecot 2.2.24 server. If I try to sync any user with a folder with ACL, dsycn crash with panic: Source server: dsync-local(USERNAME): Debug: sieve: file storage: sync: Synchronization active dovecot: dsync-local(USERNAME): Debug: acl vfile: reading file
2014 Jan 31
1
dsync Error: Mailbox INBOX: Save commit failed: Mailbox was deleted under us
Hi, I am doing a mass migration of users from Cyrus imap on a solaris server to dovecot 1:2.2.9-1ubuntu1 and am getting this weird issue with dsync if I try to do a "full" sync. Debug output below: dsync(user at example.com): Error: Mailbox INBOX: Save commit failed: Mailbox was deleted under us dsync(user at example.com): Debug: brain M: out box 'INBOX'
2020 Nov 18
0
Dovecot Replication Errors (only) when using tcps: as the mail_replica Protocol
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,
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 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 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: