A manual expire run took less than 2 minutes -- closer to 1 minuteHow
impatient
is SA ??
John Hardin wrote:
On Fri, 2008-07-25 at 18:35 -0700, Linda Walsh wrote:
Jul 25 15:28:21 Ishtar spamd[2355]: bayes: expire_old_tokens: child processing
timeout at /usr/bin/spamd line 1085, line 22.
On Fri, 2008-07-25 at 18:35 -0700, Linda Walsh wrote:
> Jul 25 15:28:21 Ishtar spamd[2355]: bayes: expire_old_tokens: child
> processing
> timeout at /usr/bin/spamd line 1085, line 22.
Your autoexpire is taking longer than SA is willing to wait.
This is a fairly common question, there's lots
Matt Kettler wrote:
What version are you running? reading around the child processing
timeout seems to have been a common problem in the 3.1.x series, but
I've not seen it reported in the 3.2.x series.
---
Erp. I'll try upgrading and see what happens...still have a
3.1.7 installed.
Linda Walsh wrote:
Matt Kettler wrote:
The fact that they keep laying around is a problem. This suggests SA
keeps getting killed before the expire can complete. Do you have any
kind of limits set such as CPU time or memory that SA might be
running against and dying?
You can try kicking off
Matt Kettler wrote:
The fact that they keep laying around is a problem. This suggests SA
keeps getting killed before the expire can complete. Do you have any
kind of limits set such as CPU time or memory that SA might be running
against and dying?
You can try kicking off an expire manually
Linda Walsh wrote:
In my .spamassassin dir, I see lots of files that look like:
bayes_toks.expire1098 bayes_toks.expire1243 bayes_toks.expire13494
They are all a few hundred K or more long (just deleted the bunch).
I've also noticed spamd going off and cranking for more than an hour
-
In my .spamassassin dir, I see lots of files that look like:
bayes_toks.expire1098 bayes_toks.expire1243 bayes_toks.expire13494
bayes_toks.expire15029 bayes_toks.expire15761 bayes_toks.expire16349
bayes_toks.expire17370 bayes_toks.expire17385 bayes_toks.expire1754
bayes_toks.expire18183
