Re: [exim] retry times

Top Page
Delete this message
Reply to this message
Author: Heiko Schlittermann
Date:  
To: exim-users
Subject: Re: [exim] retry times
Bill,

W B Hacker <wbh@???> (Do 27 Jan 2011 16:16:11 CET):
> 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.


Ok, I understood your "retry fires a queue runner…" in a different way.

And … we need to be more precise: *frozen* messages are not subject to retry
rules at all. (except probably after
ignore_bounce_errors_after/timeout_frozen_after has passed)


> The implication is that a pass is made over the queue at NO LESS THAN <whatever
> is in the retry rule>..


The queue runners are started regardless the retry rules (by the
master process via "-qXXm", cron, users…). They just skip the *messages* not sitting
for long enough in the queue.

> 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.


Here *I*'m not sure. A delivery attempt is made for every incoming
message, independend on the retry rules. But I'm not sure, if this
specific delivery process than starts walking the queue too.

> Are we clarifying or confusing?


Not sure ☺

--
Heiko :: dresden : linux : SCHLITTERMANN.de
GPG Key 48D0359B : 3061 CFBF 2D88 F034 E8D2 7E92 EE4E AC98 48D0 359B