Date: Tue, 08 Apr 2003 16:38:11 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Dan Nelson <dnelson@allantgroup.com> Cc: current@freebsd.org Subject: Re: NIS exhausts system resources Message-ID: <3E935D63.DAC8BBF8@mindspring.com> References: <u2sznn19jvw.fsf@gs166.sp.cs.cmu.edu> <3E92E509.A7A43986@mindspring.com> <20030408174218.GE86482@dan.emsphone.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Dan Nelson wrote: > In the last episode (Apr 08), Terry Lambert said: > > Dan Pelleg wrote: > > > When does this happen, you ask? I triggered it this morning by > > > booting the machine when the NIS server was down. I had also seen > > > it in the past when configuring NIS, and it happened as soon as I > > > set the domainname. Any ideas? I can provide packet captures on > > > request, however note the failure where the server is down. > > > > Historical behaviour when the NIS server is down has been for the > > client machines to hang until the NIS server is back up. > > I've never seen that here. I used to run a SPARC SunOS 4.1.3_U1 client machine off an SunOS 4.1.3_U2 NIS server as my primary engineering workstation. Trust me, the FreeBSD code is different. > I have three NIS servers though, so there > has never been a case when all NIS resources were unavailable. Usually > what I see in the logs are: > > Mar 12 13:52:13 ypbind[113]: NIS server [10.0.0.11] for domain not responding > Mar 12 13:52:13 ypbind[113]: NIS server [10.0.0.89] for domain OK > > Was it ypbind that was hogging all the file descriptors, or what, I > wonder? No. Likely, it was something that held an unrelated descriptor open over a call to the NIS as a result of some map lookup, rather than closing the unrelated descriptor before making the map request. The big hint here is that it was complaining about /etc/hosts.access while a broken NIS request was still outstanding. -- Terry
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E935D63.DAC8BBF8>