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. After logout and login again (to the same frontend), everythings works fine. > 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. > > 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: 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. -- Regards, Kerstin Network Configuration Center HeLi NET Telekommunikation GmbH & Co. KG Hafenstr. 80-82 D-59067 Hamm Tel.: +49 (0)2381 / 874-0 Fax: +49 (0)2381 / 874-4551 Email: espey@xxxxxxxxxx PGP-Fingerprint: AB02 7E7B 5B6B 983F 8FF6 8870 3CFC 79FC 0E90 DDC9 Web: http://www.helinet.de HeLi NET Telekommunikation GmbH & Co. KG Sitz der Gesellschaft: Hamm - Amtsgericht Hamm HRA 1881 Komplementärin: HeLi NET Verwaltung GmbH Sitz der Gesellschaft: Hamm - Amtsgericht Hamm HRB 2781 Geschäftsführung: Dipl.-Kfm. Ralf Schütte
Attachment:
signature.asc
Description: OpenPGP digital signature
---- Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
