On 19 Oct 2009, at 17:37, Michael Bacon wrote: > --On October 19, 2009 2:13:03 PM -0700 Andrew Morgan <morgan@xxxxxxxx> > wrote: >> What is causing a (re)sync of the frontends? Normally this should >> only >> happen when you start Cyrus on a frontend, right? > > I am not entirely sure. I think what may be happening is that the > slave > mupdate requests get some kind of timeout, and end up > disconnecting. As > soon as they reconnect, they want to re-sync. I've upped the > "mupdate_retry_timeout" to 10 minutes, so most of the time, they'll > only > timeout once, then the next retry will be successful. This solved a > constant re-sync issue we had early on, but apparently hasn't > solved the > problem entirely. How are your frontend mupdate processes authenticating to your mupdate master? And what version of Kerberos are you using (anticipating the answer to your first question)? I suspect that you're getting a GSSAPI expired context. > The front-ends go into a sync cycle, > which ties up the MUPDATE server while they download the database > (which > can take up over two minutes). This causes a similar halt on > anything that > was responding to a mupdate "kick" on the clients, which appears to > stop up > a decent amount of inbound mail. lmtpd on your proxies is talking directly to the mupdate master? It's possible for lmtpd on your proxies to only check the local mailboxes.db. :wes ---- Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
