> Ole Nomann Thomsen wrote:
>
> > Hi All.
> >
> > I was scanning my SA log-files, when i noticed that about 30% of the
> > "result:" -lines do not contain any "BAYES_*" score.
> >
> > Version info:
> > SpamAssassin version 3.1.0
> > running on Perl version 5.8.4
> > on Debian and Redhat Linux
>
> The explanation was two-fold:
>
> 1. Whenever two spamd-demons ran opportunistic journal
> syncing approximately
> *at the same time*, one of them would lose the bayes-check.
> 2. The "last journal sync atime" was *stuck* at sometimes
> march 2005. So any
> run of spamd would sync the journal.
>
> Ad 1: This will never happen in normal circumstances, as
> syncing is only run
> once a day (by one spamd, i surmise).
>
> Ad 2: This is probably because of the upgrade to SA 3.1.0
> where i dumped the
> old-format bayes and inserted it in the new format. I must have goofed
> somewhere.
> To solve, i only had to:
>
> stop SA
> sa-learn --backup > /tmp/backup.txt'
> sa-learn --restore /tmp/backup.txt
> start SA
>
> So now I get "1" when I
> perl -ne 'if (/result:/) {$n++; $b++ if (/BAYES/);} } print
> $b/$n,"\n"; {' <
> current
>
> Thanks for all your inputs,
>
> Ole.
>
Thanks for posting your solution. I think I am experiencing a similar
problem... Although bayes seems to be working fine most of the time, Bayes
tags do not appear on many false negatives. Before I try anything, though,
I have a more general related question - can someone give me some context
about the numbers in the 'sa-learn --dump magic' output? Here's mine:
[mail] /home/_vilter/.spamassassin > sa-learn --dump magic
0.000 0 3 0 non-token data: bayes db version
0.000 0 62789 0 non-token data: nspam
0.000 0 725 0 non-token data: nham
0.000 0 144079 0 non-token data: ntokens
0.000 0 946707021 0 non-token data: oldest atime
0.000 0 1139412959 0 non-token data: newest atime
0.000 0 1139331748 0 non-token data: last journal sync
atime
0.000 0 1139328045 0 non-token data: last expiry atime
0.000 0 111811 0 non-token data: last expire atime
delta
0.000 0 9624 0 non-token data: last expire
reduction count
What is the number for 'last journal sync atime'? Is that seconds since the
last sync? If so does that indicate my last sync time is 'stuck' like
Ole's? If so what would cause that? I am running 3.0.4, it is a fresh
database install not an upgrade.
Here's my database:
[mail] /home/_vilter/.spamassassin > ls -al
total 8730
drwx------ 2 _vilter wheel 512 Feb 7 12:37 .
drwxr-xr-x 4 _vilter wheel 512 Jan 10 13:41 ..
-rw------- 1 root wheel 78 Jan 26 11:55
bayes.lock.mail.stcservices.com.3788
-rw-rw-rw- 1 _vilter wheel 84456 Feb 7 12:37 bayes_journal
-rw-rw-rw- 1 _vilter wheel 5111808 Feb 7 12:37 bayes_seen
-rw-rw-rw- 1 _vilter wheel 5423104 Feb 7 12:37 bayes_toks
bayes_seen and bayes_toks are modified pretty much constantly. Is this the
expected behavior, or should the sync only occur once a day?
Sorry for all the questions, I'm obviously new at this. Thanks for any
input.
