On Fri, Oct 17, 2014, at 01:48 AM, Stephen Ingram wrote:
On Thu, Oct 2, 2014 at 8:48 AM, Stephen Ingram <[1]sbing...@gmail.com> wrote:
On Tue, Sep 16, 2014 at 11:15 PM, Bron Gondwana <[2]br...@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]br...@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
br...@fastmail.fm
References
1. mailto:sbing...@gmail.com
2. mailto:br...@fastmail.fm
3. mailto:br...@fastmail.fm
----
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
