Micah Anderson wrote:
* mouss <[EMAIL PROTECTED]> [071020 09:38]:
Micah Anderson wrote:
Do you think running a bayes expire via cronjob is necessary if you are
running a INNOdb based bayes DB (with this patch[1])?
The patch could make it fast enough that you'll never had child timeouts
after 600 seconds causing an expiry to abort. I read the patch but
there's not enough context in it to say anything for sure. I haven't
reviewed the code it patches.
Also, if you postpone the bayes expire to instead run it via cron aren't
you just making the expiration stack up and instead are delaying this
condition until later (when the cron job runs) and for longer (because
the expiration hasn't been run in a while)?
The problem isn't the duration it takes so long as it actually
completes. An auto expiry must complete within the child timeout limit
(default of 600 seconds) less the time that child already took to scan
the message it was passed before it decided to also do an expiry.
Moving the expiry outside of spamd gives you all the time you need to do
it. spamd will still continue to scan messages while you do it, you
just might not have access to a particular bayes DB while the expiry is
running).
doing it once a day at 3 AM is not like doing it when delivering mail.
Unless you deliver mail 24 hours a day for people all over the world.
Then 3am in one place is noon in another.
Abu Dhabi in your case. Deliver a lot of mail there? :)
Again, you can still process mail while the expiry is running, and since
you're not getting one of your spamd children to do it, you're not tying
up your spamd resources. Further the expiry isn't in danger of being
aborted due to a child timeout.
If you're concerned about a once a day expiry taking to long do it twice
a day. OR if you're not having any issues with auto expiries, keep
using them.
Daryl
