Re: skipstamp db missing errors

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Cyrus SASL]     [Squirrel Mail]     [Asterisk PBX]     [Video For Linux]     [Photo]     [Yosemite News]     [gtk]     [KDE]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux