intermittent problems with kick_mupdate

Wesley Craig wes at umich.edu
Wed Jun 9 13:39:56 EDT 2010


On 04 Jun 2010, at 04:14, Gavin Gray wrote:
> It's not a unified murder, we have a number of frontends and a  
> dedicated mupdate master. As for kick_mupdate we see lots of those  
> errors say over the course of the night when the xfers are taking  
> place ,but perhaps only one instance of a xfer failing, which is  
> matched by exactly one of these entries in our logs:
>
> Jun  3 01:00:23 backend machine imap[2554]: [ID 130975  
> local6.error] connect(mupdate master machine) failed: Connection  
> refused
> Jun  3 01:00:23 backend machine imap[2554]: [ID 320383  
> local6.error] mupdate_connect failed: unknown error

> The logs then go on to say some operation couldn't happen because  
> of not being able to connect to the mupdate server, however the  
> error reported by the failed xfer process is always the "Could not  
> set remote acl on user" one.

The mupdate_connect failed is logged on the xfer target?  You should  
also get an error like:

	cannot connect to mupdate server for reservation on '%s'

... another totally bogus error message: it's clearly been copy &  
pasted from mboxlist_createmailbox(), where the term "reservation"  
might make some sense.

As far as your situation goes, tho, I'm inclined to believe the  
reported "Connection refused" error.  What's going on on the mupdate  
master during this xfer?  I suspect that it has indeed refused the  
connection!

> I don't really understand what kick_mupdate does or how it does it  
> from having a quick look at the code so I feel at a bit of a loss  
> there.

kick_mupdate() is an appropriate call in a unified murder or on a  
frontend machine.  It ought to not be called at all on a standard  
murder backend.  That it's getting called is a bug (or two -- some  
other failure probably caused it to be called in the first place).

> Is their any possibility that with lots of concurrent xfers going  
> on we could be hitting some limit on how many connections the  
> mupdate master process will accept?

There is a limit, for sure, but I don't think that would show up as  
"Connection refused".  I'm inclined to suspect that the mupdate  
master has exited or something.

> I'll look at the bug report you mentioned and think about  
> submitting one regarding the error logging,

I doubt my bug fix will help, given the "Connection refused"  
message.  However, I'd greatly appreciate you reporting the bad  
logging.  Please cc me on those (3?) reports and mark them as  
blockers so the next release won't suffer from the same poor errors!   
Thanks!

:wes


More information about the Info-cyrus mailing list