On Thu, 4 Dec 2003, Pete Henshall wrote:

> Hi dan, list,
>
> > I think it's simply a function of load. The first system gets the bulk of
> the mail thoughput.  You can see that the > erratic loads
> > tail off over the weekend.  It's wierd.  I have tried disabling RBL, bayes
> and even removing all my third party
> > rules.  No dice.
>
> If it is still leaving spamds lying around with bayes disabled then I don't
> know.... I have just set bayes_learn_to_journal 0 (thanks David Funk) and my
> problem seems to have stopped.... maybe.

I'm sorry if I gave you the wrong impression, if you are using Bayes with
auto_learn (auto_learn 1), then you most likely -do- want
bayes_learn_to_journal set to 1. (enabled).

If you use auto_learn and disable journaling, then each spamd tries to
update the Bayes database with each new message (thus increasing the
probablilty of lock contention problems).

If you enable journaling then each spamd just appends to the end of the
journal file (no locking needed for a simple text append). Then the
database will perocially get rebuilt and incorporated in the database.
So only that occasional rebuild needs to lock the database.

>
> As far as I am concerned spamd should NEVER have rouge spamd's coming off it
> that don't have a matching spamc.  (is that right??)

I'm not so sure about this. If you have bayes_learn_to_journal enabled
then a spamd child will need to be run when ever the journal file gets
"full" (size > bayes_journal_max_size) or it's been around for more
than one day. Also, unless you've explicitly disabled it, a db expire
is done daily (which would be another spamd child).

So unless you disable all automatic Bayes maintanence operations
(learn, expire, etc), then there will be the possibility of spamd
children and potential lock contention.

Dave

-- 
Dave Funk                                  University of Iowa
<dbfunk (at) engineering.uiowa.edu>        College of Engineering
319/335-5751   FAX: 319/384-0549           1256 Seamans Center
Sys_admin/Postmaster/cell_admin            Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{



-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
Spamassassin-talk mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/spamassassin-talk

Reply via email to