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) thesync_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
Attachment:
replnag
Description: Binary data
---- 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
