Hi list, I had a user report that their read message status was lost. I
recall having dealt with seen message db files in the past, but on my
current implementation (2.5 on FreeBSD 10.2), I'm not able to locate any
in or within my configdirectory, /var/spool/CyrusDB-Sieve/cyrusdb. I
have /var
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 me
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 successfully reconstructed, the backlog of replication has
completed successfully and is now caught up.
-Eric
On
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 "r
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 looking slightly further back in my
logfiles, before every instance
'm still unable to
get a successful reconstruct with "failed to read index header" for
every subfolder and "fatal error: Internal error: assertion failed:
imap/mailbox.c: 2847: record->size"
Any ideas on how to correct this so I can see if I can then get past the
r
ct
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 Cunningham wrote:
Hi list, I'm running cyrus replication
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 restarts
, the accept() fails with this error.
Which sounds to me like we want to treat ECONNABORTED similarly to
EAGAIN, not as a fatal OS error. I'll have a patch up for this shortly.
Cheers,
ellie
On Wed, Oct 26, 2016, at 09:27 AM, Eric Cunningham via Info-cyrus wrote:
Having repeatedly experien
t’s the case could you be hitting the the maximum number
of accepts??
Check the 11.11.1.2. kern.ipc.soacceptqueue section of the FreeBSD handbook
https://www.freebsd.org/doc/handbook/configtuning-kernel-limits.html
Given the load you described perhaps 128 is just not enough?
On Oct 24, 2016, at
=
Eric Cunningham
Information Services - http://whoi-it.whoi.edu
Woods Hole Oceanographic Institution - http://www.whoi.edu
Woods Hole, MA 02543-1541 phone: (508) 289-2224
fax: (508) 457-2174 e-mail: ecunning
Hi list, we're running cyrus imap 2.5.9 built from the FreeBSD 10-2
(release-p7) ports tree.
The cyrus master process is failing periodically (every 1-2 weeks) as
follows:
Oct 22 07:38:48 imap1 master[7767]: process type:SERVICE name:imaps
path:/usr/local/cyrus/bin/imapd age:305.215s pid:327
12 matches
Mail list logo
