Eric "Shubes" wrote:
> Ok, so here's my situation.
>
> I have two apparently identical low-volume servers. One shows the corruption
> symptoms, the other doesn't (yet).
>
> Here is the local.cf (same on both):
> ok_locales all
> skip_rbl_checks 0
> required_hits 5
> report_safe 0
> rewrite_header Subject [SPAM]
> use_pyzor 1
> use_auto_whitelist 1
> bayes_path /home/vpopmail/.spamassassin/bayes
> use_bayes 1
> use_bayes_rules 1
> bayes_auto_learn 1
> bayes_auto_learn_threshold_spam 7.0
> bayes_auto_learn_threshold_nonspam 0.1
> bayes_auto_expire 1
>
> The problem seems to manifest itself when tokens begin to become due to
> expire.
>
> # spamassassin -D bayes --lint
> shows that the problem server has never sync'd, while the one which hasn't
> failed (yet) shows a sync'd value.
>
> Does anyone know when, under normal operation, the bayes db is supposed to
> be sync'd? I would think that after an autolearn=ham or autolearn=spam that
> this would happen. On one server it appears to do so (and things are fine),
> but on one where it doesn't (for a long period of time), the expiration
> process appears to exhibit problems.
>
> Some of this observation may be coincidental, but I'm thinking that not
> syncing might be the root cause of this problem.
>
> I've gotta go for now, but will try to follow up on this thread as soon as I
> can.
Ok, I found out what's happening from the SA list:
> The child is trying to run a Bayes expire, apparently on a large Bayes
> database
> that hasn't had a successful expiry run in some time. This attempt to
process
> the Bayes database is probably taking over 300 seconds, and the child is
being
> timed out and killed by something. As a result of being killed, it never
> finished the Bayes expire processing. So the next child tries to do the same
> thing, gets timed out and killed, the nex child tries to do the same thing...
>
> Run a manual Bayes expire run and it will probably clean up your problems.
> If this sort of problem starts to reoccur you might consider turning off bayes
> auto expire and setting up a cron run to do it once a day or so.
> (Or more often, depending on your mail volume.)
Note (to myself), I changed timeoutsmtpd from 1200 (default 20 minutes) to
60 (1 minute) to keep sluggish connections from backing up. Perhaps that
wasn't such a good idea. I think this problem happened before I did that
though, but I can't be positive.
I think that the toaster should have a permanent fix for this. I'm thinking
that auto expire should be turned off, and a daily cron job created to
handle expirations.
The only other way to fix it I can think of would be to increase the timeout
window with auto expire on, but I don't like that idea. 20 minutes seems too
long of a period of inactivity for an smtp connection. There's also a risk
that the sending server will terminate the connection before the expiration
process completes.
Suggestions?
Gotta go away for a while - will check back when I can.
--
-Eric 'shubes'
---------------------------------------------------------------------
QmailToaster hosted by: VR Hosted <http://www.vr.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
