Yes, I have that:
```
START {
# do not delete this entry!
recover cmd="/usr/sbin/cyrus ctl_cyrusdb -r"
# this is only necessary if idlemethod is set to "idled" in
imapd.conf
idled cmd="idled"
# this is useful on backend nodes of a Murder cluster
# it causes the backend to syncronize its mailbox list with
# the mupdate master upon startup
#mupdatepush cmd="/usr/sbin/cyrus ctl_mboxlist -m"
# this is recommended if using duplicate delivery suppression
delprune cmd="/usr/sbin/cyrus expire -E 3"
# this is recommended if caching TLS sessions
tlsprune cmd="/usr/sbin/cyrus tls_prune"
# Expire data older than 28 days.
deleteprune cmd="/usr/sbin/cyrus expire -E 4 -D 28" at=0430
expungeprune cmd="/usr/sbin/cyrus expire -E 4 -X 28" at=0445
}
```
Most of that is default, I beleive.
I don't know if I'm using skiplist dbs or not. I just know my logs are
full of those messages.
That said I don't seem to have a skipstamp file anywhere.
On 8/3/23 19:01, ellie timoney wrote:
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 <mailto: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
*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-Mf974e1b2236230891885494d>
------------------------------------------
Cyrus: Info
Permalink: https://cyrus.topicbox.com/groups/info/Tf92f39d4795cc515-Mc06cef2ae3c420362b9242f8
Delivery options: https://cyrus.topicbox.com/groups/info/subscription
