Murder confusion -- two mupdate slaves, lmtpproxyd's always connecting to master

[Michael Bacon]

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