Re: Replication failed 3.0.5 -> 3.0.13, now 3.0.13->3.0.13

2020-04-22 Thread Olaf Frączyk
Yes, Michael was right - it works properly now. (I hope ;). OK. I'll put it in the DAEMON section - this way I have only one point where all stuff related to imap is started. Thank you for explanation. Regards, Olaf On 2020-04-22 02:36, ellie timoney wrote: I think Michael's got this

Re: Replication failed 3.0.5 -> 3.0.13, now 3.0.13->3.0.13

2020-04-22 Thread Olaf Frączyk
On 2020-04-21 20:40, Michael Menge wrote: Quoting Olaf Frączyk : Yes, at the beginning I was also thinking if initial sync is necessary, but there was nothing in docs about it, something started replicating and I simply assumed it does initial resync. I'll try it this evening. :) Since

Re: Replication failed 3.0.5 -> 3.0.13, now 3.0.13->3.0.13

2020-04-21 Thread ellie timoney
I think Michael's got this pretty much covered -- you need to disable the rolling replication for now, and then use sync_client -u (or if you're brave, sync_client -A) to get an initial sync of everything. These two options work entire-user-at-a-time, so they should detect and fix the problems

Re: Replication failed 3.0.5 -> 3.0.13, now 3.0.13->3.0.13

2020-04-21 Thread Michael Menge
Quoting Olaf Frączyk : Yes, at the beginning I was also thinking if initial sync is necessary, but there was nothing in docs about it, something started replicating and I simply assumed it does initial resync. I'll try it this evening. :) Since you use replication - are sieve scripts

Re: Replication failed 3.0.5 -> 3.0.13, now 3.0.13->3.0.13

2020-04-21 Thread Olaf Frączyk
On 2020-04-21 16:00, Michael Menge wrote: Hi, Quoting Olaf Frączyk : I managed to get strace on both sides, however it doesn't make me wiser - there is nothing obvious for me. Additionally I see that replication works more or less for new messages, but older are not processed. I have

Re: Replication failed 3.0.5 -> 3.0.13, now 3.0.13->3.0.13

2020-04-21 Thread Michael Menge
Hi, Quoting Olaf Frączyk : I managed to get strace on both sides, however it doesn't make me wiser - there is nothing obvious for me. Additionally I see that replication works more or less for new messages, but older are not processed. I have several subfolders in my mailbox, some of

Re: Replication failed 3.0.5 -> 3.0.13, now 3.0.13->3.0.13

2020-04-21 Thread Olaf Frączyk
I managed to get strace on both sides, however it doesn't make me wiser - there is nothing obvious for me. Additionally I see that replication works more or less for new messages, but older are not processed. I have several subfolders in my mailbox, some of them unreplicated. If I change

Re: Replication failed 3.0.5 -> 3.0.13, now 3.0.13->3.0.13

2020-04-21 Thread Michael Menge
Quoting Olaf Frączyk : Thank you for the telemetry hint :) I don't use the syncserver - the replication is done via IMAP port on the replica side. I have no idea how to have strace spawned by cyrus master process. When I attach later to imapd using strace -p I'm afraid some info already

Re: Replication failed 3.0.5 -> 3.0.13, now 3.0.13->3.0.13

2020-04-21 Thread Olaf Frączyk
Thank you for the telemetry hint :) I don't use the syncserver - the replication is done via IMAP port on the replica side. I have no idea how to have strace spawned by cyrus master process. When I attach later to imapd using strace -p I'm afraid some info already will be lost. The

Re: Replication failed 3.0.5 -> 3.0.13, now 3.0.13->3.0.13

2020-04-21 Thread Michael Menge
Hi, Quoting Olaf Frączyk : The current situation is: 1. Replica: stopped and started the replica no activity on replica - iotop and top show nothing the only messages on replica is incoming connection from master 2. Master: when I run sync_client -r I still get: Apr 21 12:38:36 ifs

Re: Replication failed 3.0.5 -> 3.0.13, now 3.0.13->3.0.13

2020-04-21 Thread Olaf Frączyk
The current situation is: 1. Replica: stopped and started the replica no activity on replica - iotop and top show nothing the only messages on replica is incoming connection from master 2. Master: when I run sync_client -r I still get: Apr 21 12:38:36 ifs sync_client[29518]: Reprocessing

Re: Replication failed 3.0.5 -> 3.0.13, now 3.0.13->3.0.13

2020-04-21 Thread Olaf Frączyk
I also found out that when I see on master: Apr 21 11:12:38 ifs sync_client[27996]: IOERROR: zero length response to MAILBOXES (idle for too long) Apr 21 11:12:38 ifs sync_client[27996]: IOERROR: zero length response to RESTART (idle for too long) Apr 21 11:12:38 ifs sync_client[27996]: Error

Re: Replication failed 3.0.5 -> 3.0.13, now 3.0.13->3.0.13

2020-04-21 Thread Olaf Frączyk
Hi, When I run sync_client -r on the master I see the following on the replica: Apr 21 10:56:15 skink1 imap[5775]: mailbox: longlock navi.pl!user.olaf for 1.7 seconds Apr 21 10:56:20 skink1 imap[5775]: mailbox: longlock navi.pl!user.piotr for 2.0 seconds Apr 21 10:56:23 skink1 imap[5775]:

Re: Replication failed 3.0.5 -> 3.0.13, now 3.0.13->3.0.13

2020-04-21 Thread Michael Menge
Hi Olaf Quoting Olaf Frączyk : Hi, I upgraded to 3.0.13 but it didn't help. This time it copied about 18GB in the logs I still see: 1 - inefficient replication 2 - IOERROR: zero length response to MAILBOXES (idle for too long) IOERROR: zero length response to RESTART (idle for too long)

Re: Replication failed 3.0.5 -> 3.0.13, now 3.0.13->3.0.13

2020-04-20 Thread Olaf Frączyk
Hi, I upgraded to 3.0.13 but it didn't help. This time it copied about 18GB in the logs I still see: 1 - inefficient replication 2 - IOERROR: zero length response to MAILBOXES (idle for too long) IOERROR: zero length response to RESTART (idle for too long) Error in do_sync(): bailing out!