successful create but unsuccessful subscribe

[Dave McMurtrie]

On Dec 14, 2012, at 10:07 AM, Kerstin Espey wrote:

> On 13.12.2012 18:28, Dave McMurtrie wrote:
> 
>> In our case, the mupdate process on one of our frontends was not
>> receiving updates from the mupdate master.  If a webmail user created
>> a new folder and then immediately reconnected to that frontend, the
>> folder wouldn't exist.  If they connected to a different frontend, it
>> would work fine.
>> 
> In our case, the session is hold open between create and subscription of
> the mailbox.

It wouldn't matter.  The create and mupdate push both happen on the backend.  The frontend just proxies the traffic. If the mupdate process on your frontend isn't getting updates from the mupdate server, it won't know that the new mailbox has been created.

> After logout and login again (to the same frontend), everythings works fine.
> 

I don't know why this would happen.


>> To see if this is your problem, you need to determine if mailboxes.db
>> is the same across all of your frontends.  The easiest thing is to
>> compare the datestamp on the file.  You may need to ctl_mboxlist -d
>> each of them and compare.  If you find that one of the mailboxes.db
>> files on a frontend is considerably older than the rest, kill mupdate
>> on that frontend and let master re-spawn it.  It will reconnect to
>> the mupdate master and scarf a fresh database.
> 
> Half an hour after deletion of a folder, three of our four frontends are
> still behind the fourth frontend, which is the one we use with our clients.
> Killing the mupdate does work - the mailbox.db is now up2date again.

This is not normal.  You need to determine why your frontends are not updating.  


>> 
>> In our case, the problem was that the mupdate process on the frontend
>> makes one connection to the mupdate master and then remains
>> connected.  Unfortunately, it does not use tcp keepalives so if
>> there's an issue at the network layer where that connection goes away
>> without actually being closed (meaning, the cyrus frontend never
>> receives a tcp reset), the mupdate process will sit in a blocking
>> read() on the mupdate socket forever without ever getting any
>> updates.  You can use lsof and/or netstat to see if this is the case,
>> should you discover that you have a stale mailboxes.db on one of your
>> frontends.  netstat shows you the source and destination port.  If
>> that port isn't open on your mupdate server, and mupdate on your
>> frontend is stuck in a blocking read(), you'll know that's the
>> issue.
>> 
> 
> ngrep shows activity on every frontend port 3905. Nevertheless the
> mailbox.db differs:

Yes, as I mentioned, the mupdate process on our broken frontend was running and still held an open socket descriptor to our mupdate server.  The problem was that the mupdate server did not still have that connection open, so the client mupdate process was stuck in a blocking read() indefinitely, but was not getting any updates.


> 
> amanda/janis:
> ~# ctl_mboxlist -d | grep Kerstin
> user.mailteam.Kerstin   1 regina!default mailteam       lrswipkxtecda
> user.mailteam.Kerstin.info      1 regina!default mailteam
> lrswipkxtecda
> user.mailteam.Kerstin.kernel    1 regina!default mailteam
> lrswipkxtecda
> user.mailteam.Kerstin.newlog    1 regina!default mailteam
> lrswipkxtecda
> 
> tegan:
> # ctl_mboxlist -d | grep Kerstin
> user.mailteam.Kerstin   1 regina!default mailteam       lrswipkxtecda
> user.mailteam.Kerstin.info      1 regina!default mailteam
> lrswipkxtecda
> 
> sara:
> # ctl_mboxlist -d | grep Kerstin
> user.mailteam.Kerstin   1 regina!default mailteam       lrswipkxtecda
> user.mailteam.Kerstin.kernel2   1 regina!default mailteam
> lrswipkxtecda
> user.mailteam.Kerstin.newlog    1 regina!default mailteam
> lrswipkxtecda
> 
> The mailbox.db file has nearly the same timestamp on all frontends.
> Existing mailboxes under user.mailteam.Kerstin are kernel and kernel2,
> all others are deleted.


This is broken.  You need to determine why your frontends aren't all in sync.  Crank the logs up to debug level (local6) on your mupdate master and the frontends.  If you don't find anything in the logs, confirm that you actually see an open socket (using netstat) on both sides (frontend and mupdate).

Also, I didn't look at your configs, but make sure you don't have proxyservers set on your frontends like Bron mentioned.