messages removed before expire

[Bron Gondwana]

On Fri, Oct 17, 2014, at 01:48 AM, Stephen Ingram wrote:

On Thu, Oct 2, 2014 at 8:48 AM, Stephen Ingram <[1]sbingram at gmail.com> wrote:

On Tue, Sep 16, 2014 at 11:15 PM, Bron Gondwana <[2]brong at fastmail.fm> wrote:

On Wed, Sep 17, 2014, at 08:24 AM, Stephen Ingram wrote:

On Tue, Sep 16, 2014 at 3:02 PM, Bron Gondwana <[3]brong at fastmail.fm> wrote:

Dumb question - but I don't suppose anything happened to your clock recently?

More non-dumb question, what version of Cyrus?


Sorry, I should have included the version. I'm using 2.4.16 rpms from Invoca Systems. Nothing has happened with the clock. This is the only mailbox that seems to have the problem too, user.ken.Trash. We are running a murder configuration with 2 backends and 2 front ends. Not may users accounts, just large mailboxes. Maybe there is some setting on the mupdate master or somewhere else that is set for 14 days?


I don't think so.  Do you have any entries in the syslog showing the deletes?  I'm pretty sure 'auditlog: 1' works in imapd.conf in 2.4.16, so you should be able to add that to see more logging.


I finally got a chance to put in auditlog and I see several entries like this everyday:

Oct  1 09:45:41 imap1 imap[7357]: auditlog: expunge sessionid=<imap1.4test.net-7357-1412174740-1> mailbox=<user.ken.Trash> uniqueid=<5f184bff4ee3c346> uid=<170665> guid=<5bbe70214bd4c7979f72977adda664afaa8ebe24>

and then:

Oct  1 09:45:41 imap1 imap[7357]: Expunged 19 messages from user.ken.Trash

at then end. The system is now removing everything down to 7 days when "info user.ken.Trash" yields:

{user.ken.Trash}:
  duplicatedeliver: false
  expire: 30
  lastpop:
  lastupdate:  2-Oct-2014 10:39:17 -0500
  partition: default
  pop3newuidl: true
  sharedseen: false
  size: 7749319

I did check the client as Alexei had suggested too as I thought the 14 days (and now 7) were a little coincidental, but there was nothing there causing the issue. Now after turning on auditlog, it does show the system removing these mails. Is this expire 30 number stored somewhere that has become corrupt or changed? This is just baffling to me as it seems to only affect this mailbox.


After another log search, I see there are messages removed every night. There are dates stretching back 14 days on the file system and 7 days in the actual Trash folder. I can't imagine that this could be a bug in Cyrus as I would have thought others to have seen it by now. I'm guessing perhaps under some unique set of circumstances, the file that contains the expiration information has become corrupt causing the mail to be removed pre-maturely. Does anyone know what file that information is contained within and if it can somehow be regenerated?



I assume it's cyr_expire that's cleaning it up?



The likely places are either the command line flags to cyr_expire, the annotations database entry for that folder, or this config item:



{ "expunge_days", 7, INT }

/* Number of days to retain expunged messages before cleaning up their

   index records.  The default is 7.  This is necessary for QRESYNC

   to work correctly.  If combined with delayed expunge (above) you

   will also be able to unexpunge messages during this time. */



Note that that is only messages which are already expunged being unlinked from the folder.



Bron.



--
Bron Gondwana
brong at fastmail.fm

References

1. mailto:sbingram at gmail.com
2. mailto:brong at fastmail.fm
3. mailto:brong at fastmail.fm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.andrew.cmu.edu/pipermail/info-cyrus/attachments/20141017/698be29b/attachment.html