On Wed, 6 Sep 2000, John Sloan wrote:
> I've been spending most of today trying to understand the various ways in
> which the number of exim processes running on a system can be controlled
> in an effort to put an upper bound on it. The system I'm looking at is
> slightly underpowered and is prone to load spikes.
A good way to deal with load spikes is to set the various options that
stop Exim doing things when the load is high. In particular,
queue_only_load is helpful, but see also deliver_load_max,
deliver_queue_load_max, and smtp_accept_queue.
> As far as I can tell, I can control strictly the number of processes
> running from queue runs by using 'remote_max_parallel' and
> 'queue_run_max'.
Correct, provided the queue runs are started by the daemon.
> However each ETRN request implictly starts up another exim process, and
> since these messages may have recipients other than the domain being
> passed, those processes can persist attempting those other deliveries for
> some considerable time. [Several hours at least]
True. Exim was never designed for this.
> 1. Is there a way of persuading exim _not_ to attempt delivery of other
> recipients of those messages being scanned at this point?
Not directly. Once it's got a message in its hand, it figures it might
as well try everything. I suppose you could somehow use hold_domains to
stop a particular queue run not delivering to certain domains. This
would be messy; ETRN would have to run Exim using -D to define a macro
containing the domain not to hold, (something like -DNOGO=!some.domain
and you'd have hold_domains = NOGO).
> In an ideal world it would be possible, by some suitable
> 'smtp_etrn_command' script, to batch up ETRN requests which had arrived in
> quick succession (say within 30 seconds) and launch a single 'exim -R
> foo.com bar.com wibble.com' type process. [The same might be achieveable
> by an appropriate regexp I suppose, but this would be cleaner
> syntactacly]. Is this functionality possible?
Nope. Well, not inside Exim. Exim has no central controlling process;
this avoids a lot of bottlenecks, but doesn't allow it to play that kind
of game. Of course, you can get it to run any program you like when it
receives ETRN; you could write your own long-running process which gets
sent the requests from something that ETRN runs, and implement your own
control therein (but see below).
> This is my first serious exposure to Exim in the flesh, as it were, so
> it's possible that my trawling of the docs, faq and list archives has been
> incomplete in some way. I crave enlightenment.
The overriding point here is that, although Exim is being used in in
this way, it was never designed as a server for storing mail for
intermittently connected hosts. Such use is bending its design. The big
users in the ISP world don't use it this way. They deliver into files on
the server, and use ETRN (or some other means) to kick off an entirely
different, special-purpose program for passing the mail to a dialled-in
host.
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
