Replication between versions 2.5.7 and 2.4.17?

Hi, We have a Cyrus-IMAP server, v2.4.17 - which we're about to do an "in place" upgrade (i.e. keep the data, re-install newer version of OS + Cyrus IMAP). In testing this seems to work out OK (once the new server is run up, database files etc. are 'in place' upgrade as they're found - or w

Re: Replication between versions 2.5.7 and 2.4.17?

--On 12 April 2016 11:00 -0400 Giles Malet wrote: The 2.4.17 server has a partner it replicates to. If we update the main server to 2.5.7 - is this still able to replicate to it's 2.4.17 partner? Although this doesn't really answer your question, we did the reverse, updating the replica and

2.5.7 -> 2.5.7 initial replication fails - failed to parse?

Hi, I have 2 * 2.5.7 servers. The first is setup to replicate to the other (which is currently empty). The 'master' has quite a bit of mail on it (~90Gb). As it's quite a lot - I brought up the replica, but left 'rolling' replication off. On the 'master' I then ran: /usr/local/cyrus/bin

Re: 2.5.7 -> 2.5.7 initial replication fails - failed to parse?

--On 20 April 2016 at 13:15:24 -0400 Giles Malet wrote: Can I safely remove all of '/sync./*' and start the replication again? - I had a bit of fun & games getting some 2.5.7 servers up (upgraded from 2.4), and ended up doing a few `reconstruct -rfGO' runs on them, and forcing replication

Re: 2.5.7 -> 2.5.7 initial replication fails - failed to parse?

--On 20 April 2016 13:15 -0400 Giles Malet wrote: I can't answer your other questions, but deleting those directories is fine. The only one(s) possible in use are those whose name matches the PID of a running sync_server process. Perhaps best then to shut cyrus down on the replica, delete every

Cyrus 2.5.7 idled not stopped when server shut down?

Hi, We're in the process of moving from Cyrus 2.4.17 to 2.5.7. So far this is going OK - but I've noticed when I stop the 2.5.7 server (this is on FreeBSD so 'service imapd stop') - it leaves behind idled? Should this be stopped by the imap server itself, or does it need stopping manually /

Cyrus 2.5.7 after upgrade "Skipping log file log.xxxxxxx"?

Hi, After moving our data from Cyrus 2.4.17 to 2.5.7 (and doing a 'reconstruct -V max etc.) when starting the server we see some log entries such as: Sep 14 09:26:58 host ctl_cyrusdb[20709]: DBERROR db5: BDB2532 Skipping log file /vol/host/imap/db/log.001829: historic log version 7 Sep 1

Re: Cyrus 2.5.7 idled not stopped when server shut down?

--On 16 September 2016 14:12 +1000 ellie timoney via Cyrus-devel wrote: The attached patch seems to resolve this for me. Karl, does it help in your case? It's against the current cyrus-imapd-2.5 from git, but should apply cleanly to the 2.5.7 sources as well. Thanks for the patch - it c

Safe to delete apparently stale / aged 'spool/sync.' directory?

Hi, We've upgraded a number of Cyrus servers through the years - we're currently running 2.5.x. The other day I noticed on a couple of servers we have: /vol/imap/spool/sync. This directory hasn't been touched in years - but has a number of sub-dirs (all numbers) - that all contain message

Re: Safe to delete apparently stale / aged 'spool/sync.' directory?

--On 22 November 2016 23:08 +1100 Bron Gondwana via Cyrus-devel wrote: Yes, it's definitely safe to delete wheneven the server is shut down. We remove it as part of the startup script at FastMail, just in case something crashed. Both sync_server and sync_client will create it if necessary

Occasional 'Protocol Errors' - Cyrus 2.4

Hi, I've noticed in my logs - very occasionally Cyrus isn't excepting messages... The front end MX host accepts the mail, passes it onto the back end IMAP server - but this logs: sm-mta[41247]: yyy: localhost: SMTP DATA-3 protocol error: 530 5.3.0 Fatal: 550-Mailbox unknown. Eit