On Mar 15, 2012 4:33 PM, "RW" <[email protected]
<mailto:[email protected]>> wrote:
>
> 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?
>
>
That is what I am trying to clarify. IF auto-learn runs sa-learn (which
is only implied), then it might still be doing opportunistic
expirations. I think i found my answer in the man page for sa-learn,
though:
"EXPIRY RELATED CONFIGURATION SETTINGS
"bayes_auto_expire" is used to specify whether or not
SpamAssassin ought to opportunistically attempt to expire the Bayes
database. The default is 1 (yes)."
Naturally I'd read that before, but it wasn't clear to me that sa-learn
function honored that setting regardless of how it's called (by
auto-learn or manually) but I now believe that is the case. I do hope
if that's not correct someone will jump in.
> > > 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).
>
Thanks
-Chris
