First off, thank you to everyone who's chimed in with extremely helpful
suggestions in response to my previous message. Some of them have helped
performance, and others mysteriously haven't when I really thought they
would, but it's been very helpful for me in untying this knot. I've been
too busy with a cranky service to respond to everyone personally, but
please know it's appreciated.
I have two questions regarding the Murder architecture. The first is just
a general annoyance at the way master starts up the mupdate processes. In
order to get master to fire off anything, you have to set prefork=1.
However, the result of this is that you generate one mupdate, it reports as
unavailable to the master, and so the master fires off another one. These
two seem to fight with each other over connections to the mupdate master,
over locks to the mailboxes database, and over who gets to serve
connections. I don't think more than one is needed from what I can tell,
but you get two just out of the master architecture. Do I really need two,
and if not, is there some way to keep more than one from starting up?
(maxchild=1 does not do the trick for whatever reason. I'm still
deciphering code on this one.)
The second one is that the code for lmtpproxyd very explicitly connects to
the mupdate master rather than the local slave. I can't really figure out
why it would do this, but here are the two relevant snippets from lmtpd.c:
This is from service_init:
if (config_mupdate_server &&
(config_mupdate_config == IMAP_ENUM_MUPDATE_CONFIG_STANDARD) &&
!config_getstring(IMAPOPT_PROXYSERVERS)) {
/* proxy only -- talk directly to mupdate master */
r = mupdate_connect(config_mupdate_server, NULL, &mhandle, NULL);
if (r) {
syslog(LOG_ERR, "couldn't connect to MUPDATE server %s: %s",
config_mupdate_server, error_message(r));
fatal("error connecting with MUPDATE server", EC_TEMPFAIL);
}
}
and it appears that this runs every time a message delivery is attempted:
static int mlookup(const char *name, char **server, char **aclp, void *tid)
{
int r, type;
if (server) *server = NULL;
if (mhandle) {
/* proxy only, so check the mupdate master */
struct mupdate_mailboxdata *mailboxdata;
/* find what server we're sending this to */
r = mupdate_find(mhandle, name, &mailboxdata);
In short, it looks like, unlike proxyd and pop3proxyd, lmtpproxyd never
even bothers to check the local mailboxes database, and when it wants an
answer, feels the need to go directly to the mupdate master, rather than
querying the handy dandy local slave. Is this intentional? Why can't it
use the local cache?
Thanks much,
Michael Bacon
UNC Chapel Hill
----
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
