similar to: 2.3.1 Replication is throwing scary errors

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

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
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 30
1
v2.2.36 release candidate released
https://dovecot.org/releases/2.2/rc/dovecot-2.2.36.rc1.tar.gz https://dovecot.org/releases/2.2/rc/dovecot-2.2.36.rc1.tar.gz.sig v2.2.36 is hopefully going to be the last v2.2.x release. Please test this RC well, so we'll have a good final release! v2.3.2 is still going to take a couple of months before it's ready. * login-proxy: If ssl_require_crl=no, allow revoked certificates.
2018 Apr 30
1
v2.2.36 release candidate released
https://dovecot.org/releases/2.2/rc/dovecot-2.2.36.rc1.tar.gz https://dovecot.org/releases/2.2/rc/dovecot-2.2.36.rc1.tar.gz.sig v2.2.36 is hopefully going to be the last v2.2.x release. Please test this RC well, so we'll have a good final release! v2.3.2 is still going to take a couple of months before it's ready. * login-proxy: If ssl_require_crl=no, allow revoked certificates.
2018 Mar 27
0
Duplicate mails on pop3 expunge with dsync replication on 2.2.35 (2.2.33.2 works)
Hello, consider the following setup with dovecot 2.2.35: smtp/587 (subject: test 1535) | | mx2a.example.com --> dsync/ssh --> mx2b.example.com | pop3 fetch/expunge (uid 23) | !! dsync (copy from INBOX -> uid 24) /| dsync
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
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
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
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 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
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 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
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)) >>
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'
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
2013 May 09
1
Crossrealm Kerberos problems
I am running dovecot 2.1.7 on Debian Squeeze 64 bit, config information at the end of the email. I am working on a Kerberos/GSSAPI based setup that requires cross-realm authentication. I have regular GSSAPI working, I can log in using pam_krb5 with password based logins or with the GSSAPI support when using a kerberos ticket in the default realm. However when I attempt to authenticate using
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