Re: [exim] exim 4.50 turns into a cpu hog

Top Page
Delete this message
Reply to this message
Author: Hirling Endre
Date:  
To: exim-users
CC: Philip Hazel
Subject: Re: [exim] exim 4.50 turns into a cpu hog
On Tue, 2005-04-05 at 14:52 +0100, Philip Hazel wrote:
> On Tue, 5 Apr 2005, Hirling Endre wrote:
> > In the meantime I found out that reverting the fix for debian bug#296492
> > cures this problem.
>
> Please remind me what that fix was. I don't tend to keep debian bug
> numbers.


The patch below moves setting nexthost after the check for the usability
of the current host, so if the current host is not usable, exim will
recheck it in an endless loop instead of skipping to the next.

endre


*** exim-4.50/src/transports/smtp.c Thu Feb 17 14:49:11 2005
--- transports/smtp.c   Tue Mar 22 15:45:35 2005
***************
*** 2133,2143 ****
      uschar *retry_message_key = NULL;
      uschar *serialize_key = NULL;


-     /* Default next host is next host. :-) But this can vary if the
-     hosts_max_try limit is hit (see below). */
- 
-     nexthost = host->next;
- 
      /* Set the flag requesting that this host be added to the waiting
      database if the delivery fails temporarily or if we are running with
      queue_smtp or a 2-stage queue run. This gets unset for certain
--- 2172,2177 ----
***************
*** 2244,2249 ****
--- 2278,2290 ----
        continue;      /* With next host */
        }


+     /* The default next host is the next host. :-) But this can vary if the
+     hosts_max_try limit is hit (see below). NOTE: we cannot put this setting
+     earlier than this, because a multihomed host whose addresses are not looked
+     up till just above will add to the host list. */
+ 
+     nexthost = host->next;
+ 
      /* If queue_smtp is set (-odqs or the first part of a 2-stage run), or the
      domain is in queue_smtp_domains, we don't actually want to attempt any
      deliveries. When doing a queue run, queue_smtp_domains is always unset. If