successful create but unsuccessful subscribe

[Kerstin Espey]

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 at helinet.de
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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 464 bytes
Desc: OpenPGP digital signature
Url : http://lists.andrew.cmu.edu/pipermail/info-cyrus/attachments/20121214/da7662fa/attachment-0001.bin