Stripping of attachments using Horde 4/IMP 5.

[Adam Tauno Williams]

On Mon, 2012-12-31 at 10:33 +0100, Simon Matter wrote:
> > The databases used are:
> > -rw------- 1 cyrus mail 144 Dec  9 09:29 ./annotations.db
> > ./annotations.db: Cyrus skiplist DB
> > -rw------- 1 cyrus mail 144 Dec 30 11:30 ./db.backup1/annotations.db
> > ./db.backup1/annotations.db: Cyrus skiplist DB
> > -rw------- 1 cyrus mail 1882668 Dec 30 11:30 ./db.backup1/mailboxes.db
> > ./db.backup1/mailboxes.db: Cyrus skiplist DB
> > -rw------- 1 cyrus mail 144 Dec 30 11:00 ./db.backup2/annotations.db
> > ./db.backup2/annotations.db: Cyrus skiplist DB
> > -rw------- 1 cyrus mail 1882668 Dec 30 11:00 ./db.backup2/mailboxes.db
> > ./db.backup2/mailboxes.db: Cyrus skiplist DB
> > -rw------- 1 cyrus mail 18038784 Dec 30 11:30 ./deliver.db
> > ./deliver.db: Berkeley DB (Btree, version 9, native byte-order)

I can't image how the delivery database would create the problem you
describe; so I'd doubt it is that.

Irregardless of where the data is physically stored, does the filesystem
pass an fsck?

> > I don't have backtrace?  I am using RHEL rpms.

That doesn't in any way prevent you from generating a backtrace.  You
have a core file, just use gdb to generate the backtracr.

> Unfortunately we can also not see what has been changed in the patched
> RPMs you got from RH.
> > But, is it OK to use NetApp Storage for /var/lib/imap file system?
> NetApp often sounds like NFS but you told us you are not using NFS but FC
> attached disks? If so I don't know why it shouldn't work exactly as local
> disks would.

+1 An FC or iSCSI attached volume *is* as a local disk.

> But when I hear Horde/IMP I remember a problem that some people hit after
> upgrading Horde/IMP. I don't remember what it was but you should find it
> in the archives. IIRC it has been fixed in the latest version of
> cyrus-imapd.


-- 
Adam Tauno Williams  GPG D95ED383
Systems Administrator, Python Developer, LPI / NCLA