Bayes Rebuild not happening

[Julian Field]

Wonderful! At long last we can actually get an error report. That extra
eval{} was definitely worth it!

Rather than having to get a patch from the SA guys, please can you try this
patch to SA.pm

-----SNIP-----
--- SA.pm.old   2004-03-26 15:33:56.000000000 +0000
+++ SA.pm       2004-03-26 15:35:24.000000000 +0000
@@ -128,6 +128,7 @@
          # Do the actual expiry run
          MailScanner::Log::InfoLog('SpamAssassin Bayes database rebuild
starting');
          eval {
+          $MailScanner::SA::SAspamtest->init(1);
            $MailScanner::SA::SAspamtest->init_learner({
                            force_expire => 1,
                            learn_to_journal => 0,
-----SNIP-----

init() is supposed to be a non-public method, but I can't see any other way
of doing it.

Let me know if this fixes the problem. If it does, it will go in the next
release.

At 14:46 26/03/2004, you wrote:
>On Tue, 23 Mar 2004, Eric Dantan Rzewnicki wrote:
>
> > [...]
> > The logs show these 3 lines each day roughly 24-27 hours apart (it seems
> > to be happenning later each night):
> > Mar 23 02:47:00 scotty MailScanner[7751]: Bayes database rebuild is due
> > Mar 23 02:47:01 scotty MailScanner[7751]: SpamAssassin Bayes database
> rebuild preparing
> > Mar 23 02:47:01 scotty MailScanner[7751]: SpamAssassin Bayes database
> rebuild starting
> >
> >
> > But expiry doesn't appear to be happening:
> >
> > # sa-learn --dump magic -p /opt/MailScanner/etc/spam.assassin.prefs.conf
> > 0.000          0          2          0  non-token data: bayes db version
> > 0.000          0      14458          0  non-token data: nspam
> > 0.000          0      31835          0  non-token data: nham
> > 0.000          0     272940          0  non-token data: ntokens
> > 0.000          0 1075925447          0  non-token data: oldest atime
> > 0.000          0 1080071560          0  non-token data: newest atime
> > 0.000          0 1080070932          0  non-token data: last journal
> sync atime
> > 0.000          0 1079477438          0  non-token data: last expiry atime
> > 0.000          0     345600          0  non-token data: last expire
> atime delta
> > 0.000          0       1515          0  non-token data: last expire
> reduction count
> > [...]
> >
> > Any ideas? Anyone else seen this?
>
>I think I might have tracked it and fixed it.
>
>This problem had been puzzling us, too.  I had been working around it by
>periodic "sa-learn --rebuild --force-expire" done manually (others have
>worked around it with a cron job).
>
>Earlier today, I copied the "eval" change from Julian's recent beta
>(4.29.6-1) and applied it to our production version (4.26.8).  This
>revealed log entries:
>    Mar 26 09:49:01 mailrelay1 MailScanner[11548]: SpamAssassin Bayes
> database rebuild preparing
>    Mar 26 09:49:01 mailrelay1 MailScanner[11548]: SpamAssassin Bayes
> database rebuild starting
>    Mar 26 09:49:01 mailrelay1 MailScanner[11548]: SpamAssassin Bayes
> database rebuild failed with error: Can't call method "sync" on an
> undefined value at /usr/lib/perl5/site_perl/5.6.1/Mail/SpamAssassin.pm
> line 495.
>
>
>Whether this is a buglet in SpamAssassin or MailScanner's use of SA I
>don't know.
>
>But I looked into the relevant part of SA (2.63), and have tried this
>patch:
>
>========================== snip =======================
>--- SpamAssassin.pm.orig        Tue Jan 20 21:40:17 2004
>+++ SpamAssassin.pm     Fri Mar 26 14:22:24 2004
>@@ -476,6 +476,8 @@
>    if (defined $opts->{learn_to_journal}) { $self->{learn_to_journal} =
> $opts->{learn_to_journal}; }
>    if (defined $opts->{caller_will_untie}) {
> $self->{learn_caller_will_untie} = $opts->{caller_will_untie}; }
>    if (defined $opts->{wait_for_lock}) { $self->{learn_wait_for_lock} =
> $opts->{wait_for_lock}; }
>+
>+  $self->{bayes_scanner} = new Mail::SpamAssassin::Bayes ($self);
>    1;
>  }
>
>========================== snip =======================
>
>which seems to fix the problem, and lets the expiry run.
>
>You might, at own risk of course, wish to try that patch.
>
>An alternative might be to use something like "$self->init(1);" instead at
>around that place.  (I don't know the code well enough to judge that.)
>
>
>Could those who know the internals of SA comment on whether this analysis
>is correct, and whether the patch is correct?  If so, could someone on
>the list who is in routine contact with the SA folk please submit this
>patch (or variant thereof) to the SA folk?  Thanks.
>
>Hope that helps.
>
>--
>
>:  David Lee                                I.T. Service          :
>:  Systems Programmer                       Computer Centre       :
>:                                           University of Durham  :
>:  http://www.dur.ac.uk/t.d.lee/            South Road            :
>:                                           Durham                :
>:  Phone: +44 191 334 2752                  U.K.                  :

--
Julian Field
www.MailScanner.info
MailScanner thanks transtec Computers for their support

PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654