Re: exim performance hint
On Wed, Oct 01, 2008 at 07:07:36AM +0200, Ingo Juergensmann wrote:
> On Tue, Sep 30, 2008 at 05:19:05PM -0500, Lance Tagliapietra wrote:
>
> > Looking closer, exim is run by a cron task periodically, to try to
> > re-send email that could not be sent, or was queued for some reason. If
> > the message could not be delivered, it sits in the queue. Due to a
> > mis-configuration of exim, I had system messages to root sitting in
> > there, all the mail to support popularity-contest, and others, for about
> > 6 years! There were about 1000 files there to be processed, each time,
> > which simply took time.
> > [...]
> > Note that all this time I was able to send email/ receive email and
> > didn't really know about much system generated email.
>
> You could run exim -d -qff <msgid> to see why those mails in the queue are
> failing.
>
> I suffered from a similar problem once and wrote a little Python script to
> deal with this problem. It tries to flush the queue and depending on the
> error code it gets back, it either tries to deliver the mail again, spool it
> again or simply delete it. If it can't send mails for a certain amount of
> time in the queue, it deletes the mail as well.
Actually, exim can do that itself. Just set 'timeout_frozen_after' to a
sane value (say, '1 month' or some such), and exim will remove all
frozen mails that it can't deal with after a while.
--
<Lo-lan-do> Home is where you have to wash the dishes.
-- #debian-devel, Freenode, 2004-09-22
Reply to: