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, [email protected] 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 > *Cyrus <https://cyrus.topicbox.com/latest>* / Info / see discussions > <https://cyrus.topicbox.com/groups/info> + participants > <https://cyrus.topicbox.com/groups/info/members> + delivery options > <https://cyrus.topicbox.com/groups/info/subscription> Permalink > <https://cyrus.topicbox.com/groups/info/Tf92f39d4795cc515-M53cb45e04aace1101224b514> ------------------------------------------ Cyrus: Info Permalink: https://cyrus.topicbox.com/groups/info/Tf92f39d4795cc515-Mf974e1b2236230891885494d Delivery options: https://cyrus.topicbox.com/groups/info/subscription
