csua.org/u/80t -> lists.roaringpenguin.com/pipermail/mimedefang/2004-January/019591.html
A few days ago I reported a problem I was having with my bayes database to the SATalk mailing list along with the observation that I was pretty sure it was a bug in the bayes expiry software.
expire4752 A few days later I got a message from another person, David Lee, who had run into the same problem and who thought it might be due to the controlling agent, in his case a program called Mailscanner, timing out the expiry process before it could complete. It turns out that is exactly what was happening (I think). Bayes expiry can often take 3 or 4 minutes to complete, and if the system load happens to be really high when a mimedefang/spamassassin process decides its time to do an expiry, the process can easily take much longer, and if it takes longer than 5 minutes your're in trouble, since AFAIK the sendmail default timeout on a milter operation is 5 minutes. If a bayes expiry takes longer than 5 minutes it will be abruptly terminated? I'm also pretty sure this must be the case because I copied the files to another location for testing and ran an expire via sa-learn and it finished successfully in about 8 minutes, so it wasn't a matter of a corrupted database causing the problem. cf file and use sa-learn to force an expire on a regular basis via cron. As I recall someone in this forum suggested such an approach in a previous posting, but never gave a reason, so it didn't occur to me that it was mandatory and not just a matter of personal preference. I'll also be reporting this to the SATalk mailing list along with the observation that bayes expiry takes much too long, and the code could use some work to improve performance.
|