Re: [exim] retry times

Top Page

Reply to this message
Author: W B Hacker
To: exim users
Subject: Re: [exim] retry times
Sergei Gerasenko wrote:
> Cool! Thank you for the info!
> My exim is running with this command: /usr/local/sbin/exim4 -bd -q30m, so
> that should be 30 minutes, right?

For *that paricular* source or means of invocation of 'a' queue runner - yes.

> Adjusted the logging -- thanks!

Have a care with any of these adjustments.

It is easy to lose more log detail than you really wanted to do without, and not
realize it until trying to debug two months later..

I'd suggest you compare before/after and 'adjust'.

JFWIW, I use:

log_selector = +all -all_parents -queue_run -arguments -rejected_header

That produces a very detailed log - perhaps TOO detailed for many folks.

It WILL still show the collisions you seek to not log - but ONLY the collisions.
Basic queue-runner invocation does not show - only the delivery *results*.

Suits my needs, but YMMV,


> On Wed, Jan 26, 2011 at 6:10 PM, Phil Pennock<exim-users@???>wrote:
>> On 2011-01-26 at 16:28 -0500, Sergei Gerasenko wrote:
>>> Sorry if this has been asked before.
>>> A message has been sitting in my queue. The log file contains multiple
>>> instances of "remote_smtp defer (110): Connection timed out". I've
>> connected
>>> to the host on 25 and verified that I'm indeed unable to talk to it. So
>> far
>>> so good. My question is: why does Exim try to deliver it about every 3-4
>>> minutes (with "Spool file is locked another process is handling this
>>> message" about every 15-30 seconds)?
>> The "queue runner" is not ordered. Each queue runner takes a look at
>> handling a mail; if the spool file is locked, another runner is assumed
>> to be handling it and the runner continues on.
>> You probably have a lot of queue runners competing with each other.
>> Perhaps you should increase the time between starting queue-runners, or
>> perhaps you should look at turning on split_spool_directory and then
>> scripting a fancier queue runner strategy.
>>> So, why is it doing it so frequently? Also is there a way to not include
>>> "another process is handling this message" in the log?
>> log_selector = -skip_delivery
>> This will also avoid logging "Message is frozen".
>> For more details, see:
>> 49.15, "Reducing or increasing what is logged"
>> Note: the leading minus sign is important.
>> -Phil
>> --
>> ## List details at
>> ## Exim details at
>> ## Please use the Wiki with this list -