Bayes Rebuild not happening
Eric Dantan Rzewnicki
rzewnickie at RFA.ORG
Fri Mar 26 15:53:07 GMT 2004
Where does the matching } for that eval go?
-Eric Rz.
On Fri, Mar 26, 2004 at 03:34:32PM +0000, Julian Field wrote:
> 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
More information about the MailScanner
mailing list