https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6942
--- Comment #48 from Mark Martinec <[email protected]> --- > > So ... either ditch the existing database and restart redis server > > (so that SA will initialize it to "v:TOKEN_FORMAT" = 2), or hack it: > > $ redis-cli set v:TOKEN_FORMAT 2 > > I had indeed ditched the DB and restarted redis server > (also made sure Redis dumps were gone before restarting) Don't know, I just tried it here and it seems to work as intended, i.e. a database is re-initialized (but not purged) if it does not contain a key "v:DB_VERSION" when a SpamAssassin process connects it. My guess is that the redis server wasn't fully stopped while deleting its redis/dump.rdb file. As a redis process is in habit of periodically forking its copy which re-creates a dump.rdb file, it can be quite persistent in keeping an old database around. The procedure should be: stop a redis server (make sure it has stopped), delete dump.rdb, then restart it. A delete followed by a restart does not necessarily clear its database. Tried also some failure scenarios: turning off a redis server, or just restarting it. Made some changes to better cope with such situation: the current bayes check would still fail, but the next mail check would try and re-establish a connection. Also a re-starting redis server would cause "LOADING Redis is loading the dataset in memory" bayes failures during its reload, but once that is over normal processing should continue. SpamAssassin does not wait until the server is up, it's just that bayes checks contribute no results during outage. trunk: Bug 6942 - Redis bayes storage module - robustness: treat as disconnected on failure; get_storage_variables: only fetch variables which are actually needed Sending lib/Mail/SpamAssassin/BayesStore/Redis.pm Committed revision 1494371. -- You are receiving this mail because: You are the assignee for the bug.
