Hi again,
I've dug a bit deeper...
My previous email was a little off in some of the specifics, but not enough for it to matter, and the big picture remains the same.
For skiplist specifically, if "ctl_cyrusdb -r" has not been run, and therefore the db/skipstamp file doesn't exist, then "recovery" will happen for every skiplist database every time anything opens it (thus "assuming the worst"). The housekeeping isn't missed though -- it's just maybe overdone.
The error message could be better! While I'm in here anyway, I might see about putting together a small patch to improve logging around that condition. If the problem is just that the skipstamp file is missing, an informational message about needing to run ctl_cyrusdb -r to create it seems appropriate. I think alarm bells only need to sound when the skipstamp file exists but is unreadable or corrupt.
Cheers,
ellie
On Fri, 4 Aug 2023, at 11:28 AM, ellie timoney wrote:
Hi,On Thu, 3 Aug 2023, at 8:33 AM, phil@xxxxxxxx wrote:My errors are full of logs like:2023-08-02T22:28:36.469012+00:00 virt cyrus/imaps[3012149]: DBERROR: read failed, assuming the worst: filename=</var/lib/cyrus/db/skipstamp> syserror=<No such file or directory> func=<myinit>I can't seem to find anything on this. It appears in lots of people's logs, but never seems to be the culprit for whatever they've reported. But nonetheless I'd like to either create that DB properly, or tell Cyrus not to look for it, or whatever the most appropriate remedy is.Hmm. This happens when initialising the skiplist database backend during process startup. It expects that file to contain a timestamp of the last time skiplist databases had their recovery function called. Off the top of my head, I couldn't tell you what exactly "recovery()" means, or what is being recovered. When opening a skiplist database, recovery will be run if the database was last recovered prior to the time in that timestamp. Looks like in this case, you don't have this file, so you don't have a last recovery timestamp, and it's noisily complaining about it.This file and timestamp is created when the skiplist database backend is initialised in recovery mode, which happens specifically when you invoke "ctl_cyrusdb -r". You usually have Cyrus do this on startup, with an entry like this in cyrus.conf:START {# do not delete this entry!recover cmd="ctl_cyrusdb -r"}Do you have such an entry? If not, does adding one and restarting Cyrus make the DBERROR go away?If you don't use the skiplist format for any databases, you will still see this message each time a Cyrus process starts, because it occurs when the skiplist backend is initialised, whether or not it's ever actually used. Even if you don't use skiplist databases specifically, you should still have a "ctl_cyrusdb -r" entry like this in your cyrus.conf, because the other database formats may have similar housekeeping tasks to perform at restart, and this is how that happens.Cheers,ellie
