intermittent problems with kick_mupdate

[Gavin Gray]

Yes, all that you're saying makes sense in terms of what we're experiencing,

Quoting Wesley Craig <wes at umich.edu>:

> On 03 Jun 2010, at 09:24, Gavin Gray wrote:
>> imap[29289]: [ID 886451 local6.error] Could not trigger remote push to
>> mupdate serverduring move of user...
>
> During the xfer, the local backend sets some information in the mupdate
> master WRT the new mailbox location.  However, this information may be
> a bit of a guess.  The MUPDATEPUSH instructs the remote backend to set
> whatever the correct information is in the mupdate master.  Stupidly,
> the above log doesn't report what the problem was, and neither does the
> remote backend.  That should be fixed (can you open a bug report?).
> However, the error is not fatal.

This error does not interrupt xfers and cause them to fail.


>> imap[22505]: [ID 772019 local6.error] Could not set remote acl on user....
>
> This error is fatal.  In fact, you ought to not execute the following
> MUPDATEPUSH, because not being able to set the ACL is not permissible.
> Perhaps you're seeing this problem:
>
> 	https://bugzilla.andrew.cmu.edu/show_bug.cgi?id=3218
>
> Of course, the logging again fails to tell us *why* we aren't able to
> set the remote ACL (another good opportunity to report a bug).

This error does cause xfers to halt and fail. Although we can easily  
restart them and they pick up from where they left off and complete  
successfully.

>> The error on the new backend receiving the error is:
>> kick_mupdate: can't connect to target: No such file or directory
>
>
> Is this a unified murder?  Skimming imapd.c, I see a mix of calls to
> kick_mupdate(), some protected by checks for the type of murder, some
> not.  Perhaps that's the problem.  In any case, kick_mupdate() is void,
> so errors relating to it are probably cascades from some other failed
> step in the process.

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.

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.

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?

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

many thanks,

Gavin Gray



-- 
Gavin Gray
Edinburgh University Information Services
Rm 2013 JCMB
Kings Buildings
Edinburgh
EH9 3JZ
UK
tel +44 (0)131 650 5987
email gavin.gray at ed.ac.uk

--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.