Ahoj,
Dňa Mon, 21 Feb 2022 11:56:41 +0200 Brent Clark via Exim-users
<exim-users@???> napísal:
> Where I work, we keep getting the following message "retry time not
> reached for any host".
Exim has retry rules, which defines how often, or more precise when
next, delivery have to happen, if previous delivery failed for some
reason. These rules are configurable in retry section and in default
config (at least on debian) it uses these rules:
+ for 2 hours try every 15 min (F,2h,15m)
+ after this try every 1 hour * grow factor 1,5 for every attempt up to
16 hours (G,16h,1h,1.5)
+ after this try every 4 hours up to 4 days (F,4d,6h)
The current status of retry attempts is stored in retry DB, which is
checked on every queue processing. Thus, if there is some problem with
message delivery, it can flood log on every queue run (default is IMO
30 min) up to 4 days. Of course, one can tweak these settings to other
values, check docs.
> To resolve, we run the following:
>
> cd /var/spool/exim/db
> rm -f retry retry.lockfile
> rm -f wait-remote_smtp wait-remote_smtp.lockfile
> service exim restart
First, it is dangerous to delete any daemon's files, when it is
running. But anyway deleting retry DB files can be solution if (and
only if) files are damaged, eg. by power lost or exim's crash.
Deleting it, you lost information about current retry times, and if
particular message is still in queue, its retry times can be count from
start, thus log can be flooded for another 4 days.
You can manage retry (any) DB, by provided tool exim_tidydb, e.g. to
delete all entries from retry DB:
exim_tidydb -t 0d /var/spool/exim4 retry
exim_tidydb -t 0d /var/spool/exim4 wait-remote_smtp
You can remove particular message from queue, you can disable logging
these attempts, check docs.
You can check when next delivery have to happen by:
exinext domain # or recipient address, or messageID
> Can anyone please share any preventative tips and / tricks. Or better
> a means of auto healing.
You can prevent it only by not sending messages to hosts, which have
problems, which you will not know until try it).
> I dont want to have to write a bash / cron to manage this. It would
> be ideal to get exim to (re)solve the issue.
You do not need do it from cron, nor from other scripts, after
configured time pass (4 days in default). After max time is gone, the
message is bounced to original sender and removed from queue.
> Googling isn't proving to be helpful in this instance.
What is "Googling"?
regards
--
Slavko
https://www.slavino.sk
