On Mon, 12 Nov 2007, Bron Gondwana wrote:
>> It seems to me that the replication code ought to be a bit more robust
>> than this when a replica goes down or loses network connectivity. Is
>> the 2.3.10 code any better than 2.3.9 in the way this kind of situation
>> is handled?
>
> I believe David
On Sat, Nov 10, 2007 at 07:09:53PM -0800, Rich Wales wrote:
> After about a week of having synchronization running perfectly in my
> 2.3.9 system, I finally got another bailout incident with sync_client
> on my master server.
>
> This happened just after I shut down my replica server (to move it t
After about a week of having synchronization running perfectly in my
2.3.9 system, I finally got another bailout incident with sync_client
on my master server.
This happened just after I shut down my replica server (to move it to
a different location). About two minutes after the replica went dow
On Sun, Nov 04, 2007 at 08:42:21PM -0800, Rich Wales wrote:
> Wesley Craig wrote:
>
> > But most sync_server errors that will cause sync_client to bail out
> > ought to cause sync_server to give a reasonably unique log message
> > for the failure.
>
> As I explained earlier this evening, I didn't
Wesley Craig wrote:
> But most sync_server errors that will cause sync_client to bail out
> ought to cause sync_server to give a reasonably unique log message
> for the failure.
As I explained earlier this evening, I didn't see ANYTHING AT ALL in
the replica server's logs that resembled any sort
On 04 Nov 2007, at 22:57, Rich Wales wrote:
> Should I be looking for similar syslog messages on my replica server
> too (and checking syslog.conf on that system if necessary)?
No, not similar. But most sync_server errors that will cause
sync_client to bail out ought to cause sync_server to giv
Wesley Craig wrote:
> If you're running with -r -l . . . , you should be getting messages
> like:APPEND user.mariein syslog at level INFO. If you're
> not seeing those, then you have syslog configured to filter them.
Thanks. It looks like that's what was happening. I modified my
syslog
The log files are pretty obvious in what they say, e.g., they just
list mailboxes or users to check. So I suspect they would reveal to
you which mailboxes are problematic. I sort of assume that you're
running sync_client with -l, otherwise it doesn't log much. If it's
run with -l, it sho
If you're running with -r -l (-v is for interactive use -- it causes
printf output), you should be getting messages like:
APPEND user.marie
in syslog at level INFO. If you're not seeing those, then you have
syslog configured to filter them. See the man page for syslog.conf.
:wes
O
Wesley Craig wrote:
> The log files are pretty obvious in what they say, e.g., they just
> list mailboxes or users to check. So I suspect they would reveal
> to you which mailboxes are problematic. I sort of assume that
> you're running sync_client with -l, otherwise it doesn't log much.
> If it
Wesley Craig wrote:
> No, sync_server doesn't take much in the way of command line options.
Hmmm. OK, thanks.
> If the problem appears to be reproducible, you can enable telemetry
> logging or examine the mailboxes that are causing problem.
I currently have absolutely no idea as to what is cau
On 04 Nov 2007, at 14:27, Rich Wales wrote:
> No, sorry, as best I can tell, there isn't anything non-routine in any
> of the log files on my replica server.
> Do I need to specify any command-line flags to sync_server?
No, sync_server doesn't take much in the way of command line
options. If th
Wesley Craig wrote:
> The replica sync_server will also log to syslog.
No, sorry, as best I can tell, there isn't anything non-routine in any
of the log files on my replica server.
Do I need to specify any command-line flags to sync_server?
--
Rich Wales === Palo Alto, CA, USA =
On 04 Nov 2007, at 13:11, Rich Wales wrote:
> Where would I find this log info? As I said earlier, the only info
> I've
> found so far are the "Error in do_sync(): bailing out!" notices in the
> /var/log/messages file. Are there some other log files saved
> somewhere
> else? I do have "-l" a
Wesley Craig wrote:
> Both sync_client and sync_server typically log problems. Those
> logs are probably immediately helpful. Further information would
> depend on the reason for the bail out.
Where would I find this log info? As I said earlier, the only info I've
found so far are the "Error i
On 03 Nov 2007, at 23:20, Rich Wales wrote:
> Wesley Craig wrote:
>> It usually dies for a reason, i.e., some discrepancy that either
>> sync_client or sync_server couldn't handle. The typical way to
>> handle it is to contact someone.
>
> What sort of debugging output am I going to need to genera
Wesley Craig wrote:
> It usually dies for a reason, i.e., some discrepancy that either
> sync_client or sync_server couldn't handle. The typical way to
> handle it is to contact someone.
What sort of debugging output am I going to need to generate in order
for anyone to have a chance of tracking
Ken Murchison wrote:
> sync_client in 2.3.10 should be much more resilient.
That's good to know. However, I'm reluctant to upgrade quite yet,
given that 2.3.10 has only been out for a week and (judging from the
"Cyrus IMAPd 2.3.10 Released" thread") seems to have a few problems.
Can you (or any
On 31 Oct 2007, at 22:42, Rich Wales wrote:
> Can you (or anyone else) suggest anything I can do in the meantime
> (while I'm still running 2.3.9) to ensure that a sync_client stays
> running on my master server, or to start a new one as needed if it
> dies?
It usually dies for a reason, i.e., som
sync_client in 2.3.10 should be much more resilient.
Rich Wales wrote:
> I'm running 2.3.9 on a FreeBSD 6.2 system.
>
> Recently, I installed 2.3.9 on an Ubuntu 7.10 system and set it up as
> a replica of my original server.
>
> Everything seems to be running well, except that the "sync_client
20 matches
Mail list logo
