From: Wesley Craig (no email)
Date: Tue Aug 29 2006 - 11:01:59 EDT
On 29 Aug 2006, at 04:11, Paul Dekkers wrote:
> I haven't tried this; but does it hurt defining sync_server, imapd and
> friends processes in the replicas cyrus.conf and by that have it
> identical as the master?
If you tell the replica where mupdate is, sync_server behaves
incorrectly. I'd also avoid running imapd on a replica, unless I
could guarantee that users couldn't get to it.
> (I'm still thinking of nice ways to control (/automatically
> restart) the
> sync_client; It doesn't write out a pid, daemon (on FreeBSD) doesn't
> create the right pidfile for the thing, so things like monit or the
> restartwrapper fail to control the thing... It doesn't stay in
> foreground while in rolling mode... Maybe just have check_procs from
> Nagios look at the process-string (or any other thing that looks in
> /proc or ps). What do others do? Wesley's suggestion for having a
> seperate init-script in the same runlevel still looks 'manual' to me,
> and/or that's not the part that generates an alert.
We run the attached script periodically.
> Maybe I'd write a patch for staying in foreground and/or writing out a
> pidfile ;-))
We've toyed with the idea of making it stay in the foreground, so we
could run it from init. In the current implementation, tho, when it
exits it needs operator intervention, so automatic restart is no use
-- it will just exit again. The real solution is to make the code
more resilient.
And on a separate track, we need an overarching strategy for high
availability.
:wes
---- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
|
|
|