About the only thing we still get emailed by our monitorcyrus process now is issues with mailboxes being accessed directly after they've been renamed. This is often through a client with multiple open connections, but here's one from just a few minutes ago:
(logging lines caused variously by the fastrename patch and the auditlog patch - without them we wouldn't have the timing information - username and folder name redacted for privacy) Apr 16 08:19:03 imap2 slot211/imap[18079]: RenameCopy: user.username.Subfolder -> DELETED.user.username.Subfolder.4805EEB7 Apr 16 08:19:59 imap2 slot211/imap[18079]: Deleted mailbox user.username.Subfolder Apr 16 08:19:59 imap2 slot211/imap[18079]: auditlog: rename sessionid=<slot211-18079-1208343181-1> oldmailbox=<user.username.Subfolder> olduniqueid=<7ef27f3845a5fc37> mailbox=<DELETED.user.username.Subfolder.4805EEB7> uniqueid=<7ef27f3845a5fc37> Apr 16 08:19:59 imap2 slot211/lmtp[9066]: IOERROR: stating header for user.username.Subfolder: No such file or directory Apr 16 08:19:59 imap2 slot211/lmtp[11145]: IOERROR: stating header for user.username.Subfolder: No such file or directory Notice that the rename-copy took 56 seconds (one of the reasons we want fast rename!) Also notice that two lmtp processes were both waiting on a lock for at least part of that time but didn't find the file once the lock went away. I'm not too concerned about these, but I don't like having IOERROR in my log file when it's not a real error, because it makes parsing for errors harder! I may indeed track this down further in future, but I thought I'd throw it out to the list just incase someone else wants to fix it! Bron.
