Rather too refreshing: bayes.lock

[Ben Wylie <sa...@benwylie.co.uk>]

I've just had an issue with SpamAssassin and Bayes. I am running
SpamAssassin 3.02 on Windows.

Basically it stopped working, and no SA checks were completeing.
I tried to see what was happening with 
Spamassassin -D --lint 
And it started ok, and decided it needed to do an expiry, which took quite a
long time. When it had completed it had the following line:
debug: refresh: 3392 refresh F:/DOCUME~1/ADMINI~1/SPAMAS~1/bayes.lock
repeated over and over again, perhaps for 20 minutes.

Fortunately the last time I tried it to get a copy of the log to post, it
did eventually complete with the following end to the log:

debug: refresh: 3392 refresh F:/DOCUME~1/ADMINI~1/SPAMAS~1/bayes.lock
debug: refresh: 3392 refresh F:/DOCUME~1/ADMINI~1/SPAMAS~1/bayes.lock
debug: refresh: 3392 refresh F:/DOCUME~1/ADMINI~1/SPAMAS~1/bayes.lock
debug: refresh: 3392 refresh F:/DOCUME~1/ADMINI~1/SPAMAS~1/bayes.lock
debug: refresh: 3392 refresh F:/DOCUME~1/ADMINI~1/SPAMAS~1/bayes.lock
debug: bayes: 3392 untie-ing
debug: bayes: 3392 untie-ing db_toks
debug: bayes: 3392 untie-ing db_seen
debug: bayes: files locked, now unlocking lock
debug: unlock: 3392 unlink F:/DOCUME~1/ADMINI~1/SPAMAS~1/bayes.lock
debug: expired old Bayes database entries in 1533 seconds: 485101 entries
kept,
18889 deleted
debug: Syncing complete.
debug: registering glue method for check_uridnsbl
(Mail::SpamAssassin::Plugin::U
RIDNSBL=HASH(0x22727b4))
debug: plugin: Mail::SpamAssassin::Plugin::URIDNSBL=HASH(0x22727b4)
implements '
check_tick'
debug: running raw-body-text per-line regexp tests; score so far=-0.287
debug: running full-text regexp tests; score so far=-0.287
debug: DCCifd is not available: no r/w dccifd socket found.
debug: Running tests for priority: 500
debug: plugin: Mail::SpamAssassin::Plugin::URIDNSBL=HASH(0x22727b4)
implements '
check_post_dnsbl'
debug: running meta tests; score so far=-0.287
debug: running header regexp tests; score so far=0.939
debug: running body-text per-line regexp tests; score so far=0.939
debug: running uri tests; score so far=0.939
debug: running raw-body-text per-line regexp tests; score so far=0.939
debug: running full-text regexp tests; score so far=0.939
debug: Running tests for priority: 1000
debug: running meta tests; score so far=0.939
debug: running header regexp tests; score so far=0.939
debug: running body-text per-line regexp tests; score so far=0.939
debug: running uri tests; score so far=0.939
debug: running raw-body-text per-line regexp tests; score so far=0.939
debug: running full-text regexp tests; score so far=0.939
debug: is spam? score=0.939 required=2.4
debug: tests=BAYES_05,MISSING_HEADERS,MISSING_SUBJECT,NO_REAL_NAME
debug:
subtests=__HAS_MSGID,__MSGID_OK_DIGITS,__MSGID_OK_HOST,__SANE_MSGID,__UNU
SABLE_MSGID

The problem which is no more a problem is why was it doing:
debug: refresh: 3392 refresh F:/DOCUME~1/ADMINI~1/SPAMAS~1/bayes.lock
over and over again?
I tried removing the bayes.lock file but it kept going and replaced the
file.

Is there anything I can do to stop this happening again?
Thanks
Ben

Re: Rather too refreshing: bayes.lock

[Bart Schaefer <ba...@gmail.com>]

On 5/19/05, Ben Wylie <sa...@benwylie.co.uk> wrote:
> 
> debug: refresh: 3392 refresh F:/DOCUME~1/ADMINI~1/SPAMAS~1/bayes.lock
[...]
> debug: expired old Bayes database entries in 1533 seconds: 485101 entries

No real help here, but another data point:

I've been seeing occasional problems on my Linux workstation with 3.0
leaving bayes.lock files behind, throughout the 3.0 series.  I suspect
it does have something to do with syncing the journals and/or token
expiry, because although it always happens after spamd has run, it
does not happen in any observably predictable way.