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 Carter
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 to
a
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
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 see
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 generate in
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 in
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 and -v
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 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 the
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
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's
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
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
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
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 give
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 of
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 -r
processes on the master tend to die after a while -- at which point no
more sync
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 -r
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., some
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 anyone
20 matches
Mail list logo
