similar to: Problem migration from cyrus with imapc

I've run into a problem with `doveadm backup` (2.2 rc2 and 20130226) I did not notice in 2.1.15 doveadm backup [-Dv] -R -u cyrtest1 at iai.uni-bonn.de -m INBOX imapc: => crashes (signal 6 with acl plugin configured, sig 11 without acl) If this is considered a bug (not just because of the crash but in the meaning of "my configuration should work") it would be great if it could be

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'

Trying to migrate a bunch of users with mbox format to maildir format. dsync creates some directories, but otherwise does nothing. (Complained about the lack of "/" as separator until I added that to config, now is silent when running dsync except with the -D flag) I have tried dumping all the dovecot that came with my OS and built the latest sources, hoping I'd at least get a

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

While migrating users from Cyrus IMAP v2.3.14 to Dovecot 2.2.12 (compiled from source) dsync aborts with a backtrace on some (maybe 15 out of 800) mail accounts: (same error happens wiht or without -f flag) dsync -D -v -o mail_fsync=never mirror -f -R -u user at domain imapc: <snip> dsync(user at domain.com): Debug: brain M: in state=sync_mails dsync(user at domain.com): Debug: brain M:

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, [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

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 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 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 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

Hi, I have 2 Dovecot servers (2.2.10) which are replicating each other. Replication works fine except for one user. [root at dovecot2 ~]# doveadm -D sync -u username dovecot1 doveadm(root): Debug: Loading modules from directory: /usr/lib64/dovecot doveadm(root): Debug: Module loaded: /usr/lib64/dovecot/lib15_notify_plugin.so doveadm(root): Debug: Module loaded:

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

Hi, Using dsync to backup my users' mailboxes (dovecot 2.2.10 on both sides), I sometimes encounter the following issue. Below is the output of: dsync -Dvf -u "user" -R backup ssh root at server.domain.tld dsync -u "user" doveadm(root): Debug: Loading modules from directory: /usr/local/lib/dovecot/doveadm doveadm(root): Debug: Skipping module doveadm_acl_plugin,

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

I'm running dovecots replicator successfully on 33 mailboxes. There is only one mailbox (the biggest one, 167000 mails) that is not replicating successfully. After 10 minutes the "source" starts logging these messages: dovecot: dsync-local(foo at example.com): Error: dsync(imap.netsend.nl): I/O has stalled, no activity for 600 seconds dovecot: dsync-local(foo at example.com):

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 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

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)) >>