Jürgen Herz wrote: > Loren Wilton wrote: > > > warn: bayes: expire_old_tokens: child processing timeout at > > > /usr/sbin/spamd line 1086. (Spamd then takes very long to scan a > > > mail: > > > info: spamd: clean message (0.0/5.0) for Debian-exim:106 in 305.0 > > > seconds, 3781 bytes.) > > > > 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.) > > After a forced manual Bayes expire it didn't go better. And since the > --force-expire run only took 19 secs it seems unlikely the db was to > huge (the whole .spamassassin folder is 52 MB where bayes_toks is 4 > MB, the 44 bayes_toks.expire* are about 1 MB each). > On the other side, after disabling auto expire completely > (bayes_auto_expire 0), the timout problems are gone. > > So what could go on here? Any other ideas where to look, create > detailed logs a.s.o.?
If your --force-expire only took 19 seconds, I would guess that you are not talking to the same database. Make sure you are logged in as the same user that is having the problem when you run the --force-expire. -- Bowie
