Xref: utzoo comp.sys.mips:1029 comp.unix.ultrix:4578 comp.mail.sendmail:2128
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!julius.cs.uiuc.edu!ux1.cso.uiuc.edu!uicadd.csl.uiuc.edu!steven
From: steven@uicadd.csl.uiuc.edu (Steven Parkes)
Newsgroups: comp.sys.mips,comp.unix.ultrix,comp.mail.sendmail
Subject: running sendmail 5.64 + IDA on [3p]max's (and system crashes)
Message-ID: <1990Sep18.042346.8108@ux1.cso.uiuc.edu>
Date: 18 Sep 90 04:23:46 GMT
Sender: news@ux1.cso.uiuc.edu (News)
Reply-To: steven@pacific.csl.uiuc.edu
Followup-To: comp.unix.ultrix
Organization: Coordinated Science Laboratory, University of Illinois
Lines: 25

Well, we've been running 5.64+IDA (from uxc.cso.uiuc.edu + a few little changes)
under Ultrix 4.0 for a couple of weeks now ...

... and I've finally tracked down why the stupid thing grows without bound.
The way I have it compiled, it uses the generic getloadavg call, which fails,
which is no big problem -- happens the same way on our Ultrix 4.0 vaxes.
However, on the [3p]max's, the nlist call that is done in getloadavg causes
the process size to grow about ... oh heck, I don't have the data anymore, but
it was at least several KB and since it does this little number every time
someone connects to the smtp socket, it doesn't take more than a few days
before it eats all your virital memory.

So if you're going to run this, either fix getloadavg (too much work) or put
in a flag that keeps it from executing nlist over and over.  Interestingly
enough, they have a cache flag so that nlist doesn't get called over and over,
but it doesn't get used if the nlist call fails.

BTW, in the process of tracking this down, I found a great way to bring the
whole system down ... if you use dbx or gdb to debug sendmail and put break
points in, just about anything you do (run, stop, continue ...) will cause a
kernal panic.

steven parkes ---------------------------------------
University of Illinois Coordinated Science Laboratory
steven@pacific.csl.uiuc.edu -------------------------