trashed databases after disk full situation

[Daniel Eckl]

Hi!

Recently I switched over to another mail host running the same software 
(cyrus 2.2.12) and there was one broken seen database, too with a 
similar error message.

I didn't find any possibility to recover this db. I had to delete it, too.

I think skiplist is one of the most reliable databases, with berkeley db 
I always has locking problems like these as you mentioned, slow service 
startup and a lot of general fuss...

But can anyone shed light on how to recover a crashed skiplist file?

@Simon
I thought about searching the mailing list archives, too, but got major 
problems:

The link below every mail http://asg.web.cmu.edu/cyrus/mailing-list.html 
just gives 404.

The web/http links on http://cyrusimap.web.cmu.edu/lists.html#archives 
gives 404 either.

So there seem to be no archives I know of.
Is there an archive mirror anywhere?

It's kinda demoralizing to get an RTFM when the manual is gone for good...

Thanks,
Daniel

Rodrigo Ventura schrieb:
> Hello all,
> 
> I'm experiencing serious problems whenever there is an accidental disk full 
> situation. I see two kinds of messages in syslog: the first one concerns the 
> seen database, for instance:
> 
> Jul 21 09:39:54 omni imap[1133]: DBERROR: skiplist 
> recovery /etc/imap/user/m/mflorencio.seen: ADD at 1FB0 exists
> Jul 21 09:39:54 omni imap[1133]: DBERROR: 
> opening /etc/imap/user/m/mflorencio.seen: cyrusdb error
> 
> what happens is that all mails become unreadable forever... I have to delete 
> rge seen database.
> 
> the second one is, for instance:
> 
> Jul 21 10:47:07 omni lmtpunix[27618]: DBERROR db3: 5 lockers
> 
> what does it mean? is it possible to be expurious lock files? Please advise.
> 
> The cyrus version is 2.2.13 configured with
> ./configure --prefix=/usr/local/cyrus --with-duplicate-db=skiplist 
> --with-sasl=/usr/local/cyrus --without-snmp
> 
> Can I switch the database backends to more realiable ones?
> 
> Cheers,
> 
> Rodrigo