bayes.mutex

[Matt Kettler]

At 03:04 PM 11/23/2004, Steve Campbell wrote:
>I seem to be having a problem with sa-learn due to a file called bayes.mutex
>in my bayes directory. Can someone explain what this file is? The archives
>has plenty of stuff listing it, but I didn't see anything saying what it is.

It's a mutex.

Ok, perhaps that's not so helpful if you're not familar with multithreaded
programing and access locking.

In short, a mutex is a MUTual EXclusion. It's used to lock access to some
piece of data so you don't run into consistency problems where two
different threads are both trying to update the same data and one winds up
stomping on the changes of the other.

(ie: if two threads decide to increment a counter at the same time, both
read a value of 1, both increment it to 2 and then write back, you get 2.
If you have locking, then the two threads operate one after the other, and
you get the right answer of 3.)

In your case, MailScanner probably timed out on a SA when it was trying to
do an opportunistic expiry and made it leave the mutex laying around.
sa-learn refuses to update the bayes database because it sees the mutex and
thinks that SA is currently working on updating the DB. Check your mail
logs for "SpamAssassin timed out and was killed" messages. They are evil,
and should be regarded as a problem and are not a healthy thing for SA's
bayes subsystem.

In the short term, jack up your spamassassin timeout in mailscanner.conf,
stop mailscanner, wack the bayes.mutex with rm, run sa-learn --force-expire
then restart mailscanner. That should clear up the need for expiry, and
make it less likely to be killed again.

For a longer discussion of more detailed tricks to stop timeouts, here's
one of my old posts:
----------------------------

In the longer term, here's some suggestions I use on my own MailScanner
server: (I use all of these together)

1) Increase the spamassassin timeout in MailScanner.conf. Bring it to 60
seconds at least, I have mine set to 120.

2) Set the "Rebuild Bayes Every" parameter in MailScanner.conf. 86400
seconds is a good start. This makes MailScanner invoke SA's bayes
housekeeping directly, rather than during a scan of a message.

3) in /etc/mail/spamassassin/local.cf set: bayes_auto_expire 0. This will
keep SA from trying to run bayes expires (long and slow) during message
handling, but relies on #2 above to allow expiry to occur.

4) I also have a sa-learn --force-expire running as a daily cronjob. I have
tested the setup without this measure, and #2 is sufficient to cause expiry
to occur. Really this is just a fail-safe to allow expiry to occur even if
MailScanner's calls fail to run it properly for some reason.

------------------------ MailScanner list ------------------------
To unsubscribe, email jiscmail at jiscmail.ac.uk with the words:
'leave mailscanner' in the body of the email.
Before posting, read the MAQ (http://www.mailscanner.biz/maq/) and
the archives (http://www.jiscmail.ac.uk/lists/mailscanner.html).

Support MailScanner development - buy the book off the website!