db5 / PANIC errors under 2.5.12?

[Karl Pielorz]

--On 16 November 2018 13:52 +1100 ellie timoney <ellie at fastmail.com> wrote:

> Since you've recently upgraded from 2.3 to 2.5, it might be a good
> opportunity to migrate your Cyrus databases to one of the other database
> backends such as twoskip or skiplist?  It looks like the problems you are
> having are specifically in the berkeley backend so I think they should be
> resolved just by switching to other backends.  The 'cvt_cyrusdb' tool is
> able to convert database formats, and you'll also want to update your
> various foo_db settings in imapd.conf to specify your new database format.

Hi,

Thanks for the reply - we recently moved from 2.5.3 I think it was to 
2.5.12 - i.e. within 2.5.x.

As far as I'm aware - all our DB's are already twoskip - certainly running 
"files" against anything ending in '.db' returns "Cyrus twoskip DB" - the 
only ones that don't, are the files in the 'db' directory - these return as 
a mix of 'binary' or 'Applesoft BASIC' and other weirdness - as 'file' 
doesn't know what they are - I don't either, all I know is after the 'db5' 
PANIC messages - shutting down, then clearing out __db.001, __db.002, 
__db.003 and 'skipstamp' and restarting appears to fix the problem for a 
while.

> If you need to stick with Berkeley DB for some reason, the info-cyrus
> list might have active subscribers that use this database and might be
> able to provide guidance (though I'm not directly aware of any)

Hehe, no we don't need to stick with Berkeley DB - and, as I said - as far 
as I'm aware, we're entirely twoskip based.

Using Google I was able to find one other reference to 'DBERROR db5: 
pthread suspend failed: Invalid argument' - again, DB compatibility was 
mentioned (and apparently ruled out) - leaving a question over, maybe it's 
a bug?

I could really do with someone confirming the files in 'db/' - are 'fine as 
they are' (i.e. should not return a file type of 'twoskip' etc.) - and any 
other suggestions for what might be causing this - or any way of getting 
some more debug info.

We have two IMAP servers on identical hardware - only the one that's 
heavily loaded encounters this issue (so far).

Regards,

-Karl