At 04:35 PM 5/11/2004, Don Newcomer wrote:
Okay, I'll buy that.  I'm still really concerned that I'll hit another
deadlock situation like happened earlier this afternoon.  I can see it
generating a lockfile to do an expiry but why would I have had six or seven
lockfiles unless they were separate expiry runs (every 5 minutes or so it
appears based on that date changes on the Bayes files).  Why did this
deadlock happen and how can I prevent it in the future?

Typical problem for MailScanner users.. I bet if you check your logfile there are a bunch of messages telling you spamassassin timed out and was killed.


MailScanner is very impatient with SpamAssassin and will kill it if it takes more than a few seconds to run.

Add this to your spam.assassin.prefs.conf:
#don't do auto-expiry on a MailScanner system
bayes_auto_expire 0

And then run sa-learn --force-expire as a daily cronjob, as the same user that owns your bayes database.


pertinent Bayes entries from local.cf (which is a link to
MailScanner/etc/spam.assassin.prefs.conf for MailScanner):

I just noticed this.. DO NOT link local.cf to spam.assassin.prefs.conf.

MailScanner won't inhibit local.cf. MailScanner inhibits user_prefs and replaces it with spam.assassin.prefs.conf. By symlinking your local.cf onto your spam.assassin.prefs.conf, you're forcing MailScanner to reparse the exact same file twice, wasting time and resources. (and possibly causing crashes if future versions of SA do some kind of weird parallel parsing tricks)

bayes_path                 /var/spool/spamassassin/bayes
bayes_file_mode            0600

I also noticed this.. I'd strongly suggest that you NEVER force a global bayes in local.cf unless you use mode 666. NEVER. Under ANY condition.


The above line is causing your problems, and it's fundamentally not needed when using MailScanner. MailScanner always runs as one user, so do it in your spam.assassin.prefs.conf and NOT local.cf.

Symlink or copy spam.assassin.prefs.conf to root's user_prefs so you can do training but DO NOT link it to local.cf.

By doing it in local.cf you've fundamentally forced SA to only ever be invoked as one user without breaking the whole system. Not a good idea.

Note: the warnings in the SA docs about not honoring bayes_path in user_prefs only seems to apply to spamd. sa-learn, spamassassin and MailScanner are just fine with it.












Reply via email to