Heiko Schlittermann wrote:
> W B Hacker<wbh@???> (Do 27 Jan 2011 00:06:53 CET):
>> Sergei Gerasenko wrote:
> …
>>> * * F,2h,15m; G,16h,1h,1.5; F,4d,6h
>>> Thanks!
>>
>> The retry (alone) fires a queue-runner every 15 minutes for the first 2 hours,
>> etc ..
>
> Until now I thought, that queue runners are started according the "-q…"
> option. (Or additionally triggered by external means (cron,
> some user, …) The 15m above just means, that during the first 2 hours the
> *minimum* distance between to delivery attempts has to be 15 minutes.
>
> The spec reads:
>
> | Retry times are hints rather than promises. Exim does not make any attempt to
> | run deliveries exactly at the computed times. Instead, a queue runner process
> | starts delivery processes for delayed messages periodically, and these attempt
> | new deliveries only for those addresses that have passed their next retry time.
>
> Please correct me, if I'm wrong.
>
>
Hopefully, docs and 'We' are all saying the same thing.
To clarify what *I* said -
'whatever ELSE may fire a queue runner, the retry rule is more concerned with
WHICH frozen messages are eligible for retry at a point in time than with
invocation of the queue runner itself.
Hence the log entry w/r 'retry time not reached...' and skipping over those not
yet 'aged'.
The implication is that a pass is made over the queue at NO LESS THAN <whatever
is in the retry rule>..
But is that really so?
Normally, the answer won't be in our face, 'coz queue runners are typically
triggered more often than even a fairly aggressive retry rule.
AFAIK, setting to queue_only is a minority use of Exim, so ..ordinarily, every
transit invokes a queue runner, which hopefully succeeds on the first go more
often than not, thereby leaing nothing in the queue when all is well.
But all is not always well.
Which is why I personally tend to refer to the -q<integer><measure of time>
invocation as a 'clean-up' queue runner....
Belt and braces, so to speak..
Are we clarifying or confusing?
Bill
