> 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.
I've noticed this as a problem on Linux. the -q value is 10m, but
you're quite correct. Q runner was not doing anyhting as a
grep queue mainlog
revealed (of course I spotted that seconds after mailing the list
:-)
I have put a cron job in to run a Q every hour. We do this on the
Linux boxes, but run them every 10 minutes!
Our Solaris platform fires up Q runners perfectly every 10 minutes.
Actually it fires up about 5 within seconds of each other, but
despite a Queue of around 500 messages these runners usually exit
within 10-15 seconds. Usually one or two stick around having found
messages that possibly warrant delivery.
I'm still not convinced that the retry and wait DBs are working
correctly as we frequently find messages that deliver fine by hand,
yet have been skipped over by the Q runners....
[Before sending I tried something and added this]
We also occasionally trash the DBs and restart the daemons....ahhh,
that's possibly an important piece of info. We do not run a single
daemon:
exim -bd -q10m
but rather fire them seperately
exim -bd
exim -q10m
This has historical reasons, I believe, from when the earlier
versions of exim were quite, urm, buggy :-) It allowed our guys to
kill just, say, the delivery service and restart it without
upsetting the incoming mail daemon.
Having said that, since restarting exim on the FreeBSD box as a single
daemon:
exim -bd -q5m
(5 so that #I see results quicker :-) I thnk the Q runners are now
going again properly.... Yup they are. Can this have anything to do
with the fact that a single file contains the exim PID? and that
running 2 procs results in the file containing only the PID of the
last run daemon?
The Solaris port does not seem to suffer from this.
[Back to my original reply:]
We have several sites on dialup LANs that only connect a few timees
a day....We have a special arrangement for those, we ping every 5
minutes until we reach their SMTP server, and then do an
exim -R dom.ain
to force delivery for them. However, I'm not sure if -R overrides
retry or defer times....
> 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.
well, it is possible that I picked a later delivery message and some
of the ones that had been attempted earlier had pushed it into that
state.....
Thanks for your thoughts
Kuyper
--
/ Kuyper Hoffman / Vox:+27 (0) 21.689.6242 O/H GMT+0200 /
\ mailto:Kuyper@iAfrica.Com \ Cel:+27 (0) 83.444.1024 24hr Cell \
/________________________________/ FAX:+27 (0) 21.683.4695 24hr FAX /
\ SysAdmin Manager UUnet Internet Africa PO Box 44633 \
/ http://www.baps.com/kuyper Claremont 7735 South Africa /
\__________________________________________________________________________\
