On Thu, 22 Apr 2004, Michael Haardt wrote:
> trying to understand what exactly queue runners do, I noticed that
> they appear to fork a process per message, even if the next retry
> point has not been reached.
Yes. Delivery decisions are always taken in delivery processes. The
queue runner does not know whether the next retry point (for any one
particular recipient - there may be several) has been reached. The
delivery process has to route the addresses before it can discover what
the retry times are.
> The forked process will try to deliver it, check the appropiate retry
> database for the transport and exit. Is that correct?
For each undelivered address, yes. Some may get delivered, some may not.
> It would explain why queue runners have such an impact.
Exim is not designed to operate with long queues. It's a point I try to
make again and again. However, a queue runner forks only one process at
a time. Are you sure it is the processes that have the impact? I thought
a cheap fork() was supposed to be one of the good things about
Unix/Linux systems. I would have thought it much more likely to be the
disk accesses. A queue runner has to read every -H file in the queue.
> But how could the queue runner be modified not to fork a process if
> the forked process would not try a real delivery anyway?
With very great difficulty. It doesn't fit the underlying paradigm for
all sorts of reasons. (And as I said above, I'm not convinced it would
actually help.)
As for the -J files, not creating them when not needed isn't too easy, I
suspect. Remember that Exim does deliveries in subprocesses that run
under different uids. The -J file is created at the outer level.
Philip
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
Get the Exim 4 book: http://www.uit.co.uk/exim-book
