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
