Re: NIS exhausts system resources

Dan Pelleg wrote:
> I'm not sure I understand this. First, if the server is down when the
> client boots, this will stop the client's boot sequence (or at least slow
> it significantly down).

Not really.  All it will do is cause requests for information
normally contained in NIS to fail, following some delay (for
example, for gethostbyaddr(), if the hosts file is NIS
distributed, it will cause a 3 minute delay on reverse address
resolution, before failing back to returning the IP address).

For getpwnam(), the lookup will simply fail completely, after
the NIS server is judged to no be responding, which will only
occur after a connection attempt fails after a certain amount
of time.


> sshd isn't given a chance to start.

I mistakenly understood your original posting to say that it
"was the sshd problem reported here several times"; missed the
"NOT"; sorry.

> The only sign of life from the machine at this point is ICMP replies
> and the sound of the grinding disk (probably syslogd).

You also said there was another "sign of life":

| kernel: file: table is full
| syslogd: /dev/console: Too many open files in system
| rpcbind: rpc: failed to open /etc/netconfig
| rpcbind: warning: /etc/hosts.allow, line 23: cannot open /etc/hosts.allow:
|    Too many open files in system

The "file: table is full" and the "Too many open files in system"
can be fixed by the method I describe: recompile your kernel with
a larger MAXUSERS.

As far as the "too many open files", there are two possible
causes.  The first is that so many things are piled up waiting
for NIS, that there are *really* "too many open files".  Rasing
the MAXUSERS raises the definition of "too many".  Raise it high
enough, and the problem will "go away" (e.g. if "too many" is "10",
you will have problems when you try to open 50 files, but if "too
many" is "100", you won't have that problem).


The second cause is probably that the "/etc/hosts.allow" file is
opened, the file read, the NIS checked, and then the file is
closed.  If you changed the order of operation so that the file
was not held open while NIS was being checked, then you would not
have the problem, e.g.:

	Fails			OK
	Open A			Open A
	Read A			Read A
	Open B			Close A
	<wait a long time>	Open B
	Close B			<wait a long time>
	Close A			Close B

	<2 files held open>	<1 file held open>

... in other words, if you divide the number of open files by 2,
then maybe if (2*X > "too many"), just (X < "too many").

Make sense?


> Next, this is a wimpy machine. 233Mhz processor and 64MB of RAM. I don't
> know if that matters or not, but I'm not confident of my ability to tweak
> the memory usage on it.

	cd /usr/src/sys/i386/conf
	cp GENERIC MYKERNEL
	vi MYKERNEL			# Increase MAXUSERS by 2-3 times
	config MYKERNEL
	cd ../compile/MYKERNEL
	make depend
	make
	make install

-- Terry