Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!alg
From: alg@cornell.UUCP (Anne Louise Gockel)
Newsgroups: comp.sys.next
Subject: Re: Greedy lookupd(8)
Message-ID: <36083@cornell.UUCP>
Date: 16 Jan 90 22:23:12 GMT
References: <18600003@ux1.cso.uiuc.edu>
Reply-To: alg@cornell.UUCP (Anne Louise Gockel)
Organization: Cornell Univ. CS Dept, Ithaca NY
Lines: 29

In article <18600003@ux1.cso.uiuc.edu> randy@ux1.cso.uiuc.edu writes:
>
>We've had a problem with lookupd for a while now. I don't know when it
>started, but at one point lookupd just acquired an insatiable appetite
>for memory.  The virtual memory allocated for it (as indicated by ps)
>just grows (roughly linearly) until our file system fills up (660 Meg
>HD)! I would say the rate of growth is on the order of 20 Meg/day.
>Needless to say, we periodically have to reboot it when we begin
>running short of space (about once every two days or three days now).
>.....

Shortly after 1.0 came out, NeXT told us that there is a bug in the interaction
between yp and lookupd.  Apparently the only solution is:
  - niload /etc/group into NetInfo.  Do not niload the yp "magic cookie"
  - completely remove the /etc/group file
  - do not use yp to serve groups

Of course, this is extremely ackward in a distributed, predominantly YP,
environment.  NeXT did not say when they planned to fix this serious bug.  I
certainly hope it will be fixed in the next release as it is possible, but
rather ackward, to work around.

If you are not running YP, then I do not have any idea what is causing your
memory leak.  It sure sounds like the one we had that was YP related.

					-Anne Louise Gockel
					Cornell Computer Science
Internet: alg@cs.cornell.edu	UUCP: cornell!alg	Bitnet:ANNE@CRNLVAX5