Re: skipstamp db missing errors

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, [email protected] <mailto:[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-Mf974e1b2236230891885494d>

------------------------------------------
Cyrus: Info
Permalink: https://cyrus.topicbox.com/groups/info/Tf92f39d4795cc515-Mc06cef2ae3c420362b9242f8
Delivery options: https://cyrus.topicbox.com/groups/info/subscription