Re: smtp busylooping

[Eugene Crosser <crosser@online.ru>]

On 26-Jul-00 at 00:29, Roy C. Bixler (rcb@press-gopher.uchicago.edu) wrote:
> Have you had any luck in tracking this down?

Not yet.  But the source of the problem is definitely in getmxrr().
Combined with unreasonable immediate retry in case of error return
and (apparent) memory leak somewhere, this results in the behavior
the we observe.  I also took smtp binary from some earlier release
and it works for now. 

> I just installed 2.99.53 on Solaris 8 yesterday and notice I've been
> bitten by it twice.  Not only are the messages not delivered, but the
> 'smtp' process memory footprint gradually grows to exceed the memory
> capacity of the server and requires me to take immediate action to keep
> the machine running. :-/
> 
> I haven't looked at any code yet, but both times 'smtp' started
> busylooping and bloating, the delivery was for our MX client.  Meanwhile,
> I have gone back to the 2.99.53pre1 version of 'smtp' and that seems to
> work.
> 
> -- 
> Roy Bixler
> The University of Chicago Press
> rcb@press-gopher.uchicago.edu
> 
> On Fri, 21 Jul 2000, Eugene Crosser wrote:
> 
> > Here is another case of busylooping smtp transport:
> > in smtp.c:1761 smtpconn() continiously returns EX_TEMPFAIL
> > (I have yet to investigate the reason for that), and
> > the process goes into cycle between lines 1754 and 1763...
> > 
> > Oh, here is the reason for EX_TEMPFAIL:
> > in smtp.c:2086 getmxrr() returns EX_UNAVAILABLE, which, a dosen
> > lines below, resuts in return EX_TEMPFAIL.
> > 
> > Let us see how getmxrr() works...
> > seems that for some reason mx[i].ai are getting null despite
> > mx[i].host are filled with good values; and all mx[*] are
> > invalidated around line 4675; then the function returns
> > EX_UNAVAILABLE.
> > 
> > I cannot realize why this may be happening so far...  Anyway,
> > as a result of this problem, a bunch of mail cannot ever be
> > delivered.  Apparently this always happens for some domains.
> > 
> > Eugene
> >