Hi.
Thanks for the hints. I ran exim in debug mode, an everything seemed to
have been directed and routed through to the special SMTP transport I
setup for this.
The problem came to light when I started playing more. When it runs the
list, and one connection gets started, exim seems to fork for each new
recipient in the list, and that child process dies with either a fork
error (it crashed the machine yesterday ;) -- or with a "too may
connections to host already" type error. This makes for a very busy
machine - trying to fork 140'000 processes in rappid succession isn't
pretty.
Anyway - setting batch_max in the smtp transport did not help. The only
way I could stop this from happening was to set the global max_parallel
option to 1 - quite a shame.
It still could be me missing something obvious (it usually is)...
Thanks.
Scot.
On Tue, 15 Dec 1998, Philip Hazel wrote:
> other messages down the same channel, but the queue runner doesn't wait
> for them as it should.
>
> The temporary workaround is to set batch_max = 1 or maybe 2 or 3 in the
> smtp transport.
>
> > I'd expect it not to try and do 5 parallel deliveries because of the
> > serialize_hosts option on this domain on the transport it uses.
>
> Hmm. That should prevent the effect too. But serialize_hosts should be
> set to the host, not the (mail) domain. Have you tried running a
> delivery with debugging turned on to see what it says?
>
> exim -d9 -M <message id>
--
*** Exim information can be found at
http://www.exim.org/ ***
