Kuyper Hoffman writes:
> Perhaps I'm missing something, but is anyone else concerned about retry
> times in Exim?
[...]
>
> So the catchall "*" entry at the end seems to compare well with the
> original comment "retry every 15 minutes for 2 hours"
>
> However, examining the log file for a particular message:
>
> [kave] /var/spool/exim/log # grep 0utwHa-0002XK-00 mainlog
> 1996-08-23 15:29:04 0utwHa-0002XK-00 <= execpers@??? H=196-7-124-198.iafrica.com [196.7.124.198] P=smtp S=41223
> 1996-08-23 15:35:18 0utwHa-0002XK-00 SMTP timeout while connected to cis.co.za [196.2.16.3] after sending data block
> 1996-08-23 15:35:18 0utwHa-0002XK-00 == executiv@??? T=smtp defer (60): Operation timed out: SMTP timeout while connected to cis.co.za [196.2.16.3] after sending data block
> [kave] /var/spool/exim/log # date
> Fri Aug 23 22:30:45 SAT 1996
>
> It hasn't been submitted even once since the initial deferment....
It sounds to me as if you have lost your daemon, or that it has an amazingly
large "-q" argument. Even if each scan had decided to bypass this message, you
should still get a mainlog entry for it, e.g.
1996-08-23 16:30:58 0utwHA-0002XK-00 == executiv@??? T=smtp defer (-20): retry time not reached for any host
every time. Check for "Start queue run" and "End queue run" messages.
That said, note that Exim may not always try to deliver a particular message
"every 15 minutes for [the first] 2 hours". If it already has an entry for
the host in the retry database as a result of previous messages to it having
been defered, it will pick up the schedule from wherever it has got to. This
isn't the case in your example though, as the receive process clearly forked
an immediate delivery process.
Chris Thompson Cambridge University Computing Service,
Email: cet1@??? New Museums Site, Cambridge CB2 3QG,
Phone: +44 1223 334715 United Kingdom.
