On Thu, 15 Mar 2012 17:38:03 -0500 (CDT) David B Funk wrote: > On Thu, 15 Mar 2012, Chris Hunt wrote: > > > On 3/15/2012 2:53 PM, RW wrote: > >> On Thu, 15 Mar 2012 14:27:53 -0700 > >> Chris Hunt wrote: > >> > >>> I'm trying to eliminate opportunistic bayes expirations and run > >>> them via cron. > >> bayes_auto_expire 0 > > RW, > > Thanks for the rapid reply... I have RT*M AFAIK. Sorry, I should > > have posted the relevant bits of my config: > > use_bayes 1 > > bayes_auto_learn 1 > > bayes_store_module Mail::SpamAssassin::BayesStore::MySQL > > bayes_auto_expire 0 > > > > Does the community feel confident that the "bayes_auto_expire 0" > > extends to the auto_learn function? I guess I could disable the > > cron job and watch "sa-learn --dump magic " to double-check, > > although I've no idea how to interpret that output.
auto-learn and auto-expiry are two different things. Why would you think that auto-learn would override the bayes_auto_expire setting? > > Also, do you think it's important to stop spamassassin before > > running the force-expire routine as documented in > > http://wiki.apache.org/spamassassin/BayesForceExpire? I can't > > imagine why... > > If you're using a file based (BerkeleyDB) bayes-store scanning can > come to a halt during the expire (dabase is locked) and if it takes > long enough will time-out message processing. That's not quite right. The issue with timeouts is during auto-expiry, when expiry is done as part of a normal check sharing its timeouts. With a forced expiry the only problem is that auto-learning is "unavailible" I'm not sure whether that extends to MySQL, but it's only a minor problem anyway. > However as you're using a MySQL store this shouldn't (???) be an > issue. (??? not sure as I don't use MySQL store, somebody else can > chime in).
