Yes, file 148 is completely corrupted.
On 5/12/17 9:16 AM, Bron Gondwana wrote:
Just read the 148 file and see if there is corruption. I suspect that's the
cause.
Bron
On Fri, 12 May 2017, at 23:09, Eric Cunningham wrote:
I have snapshot backups of that account, that particular message
Just read the 148 file and see if there is corruption. I suspect that's the
cause.
Bron
On Fri, 12 May 2017, at 23:09, Eric Cunningham wrote:
> I have snapshot backups of that account, that particular message and the
> various cyrus db files. What can I provide for review?
>
>
> On 5/11/17
I have snapshot backups of that account, that particular message and the
various cyrus db files. What can I provide for review?
On 5/11/17 7:38 PM, Bron Gondwana wrote:
It looked like the '148.' file was corrupted in some way. I assume you've
deleted all the evidence now, so we can't see
It looked like the '148.' file was corrupted in some way. I assume you've
deleted all the evidence now, so we can't see how! Oh well :(
Bron.
On Fri, 12 May 2017, at 04:55, Eric Cunningham wrote:
> Just to close the loop on this, once the corrupted cdm-lit account on my
> copy server
Just to close the loop on this, once the corrupted cdm-lit account on my
copy server successfully reconstructed, the backlog of replication has
completed successfully and is now caught up.
-Eric
On 05/11/2017 02:20 PM, Eric Cunningham wrote:
-G didn't seem to help, but I tried a "reconstruct
-G didn't seem to help, but I tried a "reconstruct -f -r" command
without having previously deleted all occurrences of the cyrus.* files
and it was then successful.
On 05/11/2017 01:44 PM, Patrick Boutilier wrote:
Try a -G with reconstruct?
-G Force re-parsing of the underlying
Try a -G with reconstruct?
-G Force re-parsing of the underlying message (checks GUID
correctness). Reconstruct with -G should fix all possible individual
message issues, including corrupted data files.
On 05/11/2017 02:37 PM, Eric Cunningham wrote:
I have to walk this back. In
I have to walk this back. In looking slightly further back in my
logfiles, before every instance of a failure to sync some folder, I see
a common error reported prior to every "bailing out! Bad protocol" error
- "IOERROR: GUID mismatch /var/spool/cyrus/mail/c/user/cdm-lit/Sent/148."
May 11
Thanks Bron, but that doesn't seem to work for me, unless I'm missing
something.
I ran reconstructs for this account on both my master and copy hosts:
[cyrus@imap1 ~]$ reconstruct -f -r user.scramer
user.scramer
user.scramer.Archive
user.scramer.Archives
user.scramer.Archives.2004
...
Looks like you have a corrupted mailboxes database - if you run a reconstruct
at each end then it should be fine. Replication won't bail for an
actually-doesn't-exist mailbox, but it can't fix broken mailboxes, that's what
reconstruct is for.
Bron.
On Thu, 11 May 2017, at 01:01, Eric
Hi list, I'm running cyrus replication on cyrus 2.5.10. It seems
whenever a folder is encountered in log-run that doesn't exist on the
client and/or the server, the replication process logs "Error in
do_sync(): bailing out! Bad protocol". Sometimes, it dies completely,
other times it
11 matches
Mail list logo
