Re: NIS exhausts system resources

Dan Pelleg wrote:
> This sounds plausible, thanks.
> 
> However, In the past, when configuring NIS for the first time, I did see
> the machine go unresponsive on me as soon as I did a "domainname foo". This
> was probably at a time when the server wasn't set up correctly. But why
> would that immediately cause high resource usage? There shouldn't be any
> name or user lookups taking place. This is a very quiet machine - I don't
> think it was running more than very lightly loaded postfix and sshd at the
> time, and I was the only user logging in. Name lookups, by the way, should
> not go out anyway - the machine is running its own named.

On the contrary; you have to know how "domainname foo" will affect
the system operation.

The domainanme(1) command calls the setdomainname(3) library function,
which calls that function out of /usr/src/lib/libc/gen/setdomainname.c;
This in turn sysctl's it down to the MIB entry "kern.domainname".

None of this causes ypbind to rebind to the new domain name.

As a result, all future requests return an error, because it is
asking for data which the server does not have, and which the
client, being in the wrong NIS domain, is not permitted to request.

If you are going to use domainname(1), use it as part of an rc
script, before ypbind is tarted.

Alternately, kill ypbind, use domainname(1), and then restart
ypbind.

Minimally, kick ypbind in the head with a HUP; if you have
specified a domainname on the command line when starting ypbind
(e.g. using "-S"), then you will have to kill and restart it.

>  > 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
>  >
> 
> These are lines I extracted from the log files after the machine went back
> up (I turned on the NIS server and rebooted the client). Sorry if this
> wasn't clear.

Things get logged, at least until you don't have a descriptor for
syslogd, as a result of what's wrong at the time; these are not
"OK, I'm back up!" messages: they are what was wrong while the
system was dead/down.

>  > > 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
>  >
> 
> I was going to say "I have my MAXUSERS set to 0, which is still 0 after
> multipying by 3". But checking the config file it turns out that it doesn't
> have MAXUSERS defined at all. And neither does GENERIC (from a copy of
> which I probably started my own config file) nor NOTES. What is the
> equivalent of MAXUSERS on -CURRENT?

It is not in the /usr/src/sys/i386/conf/ directory, it's in the
global one in /usr/src/sys/conf/.

Yes, the default for MAXUSERS is 0, which is supposed to mean
"autotune everything correctly".

The default ends up setting this value, a tunable int, to 32.  See
the sources in: /usr/src/sys/kern/subr_param.c.

A better number to raise might be MAXFILES; it's set based on the
number of physical pages in the system, divided by 12.

On your system, it's proably 1800 or so; to find out, type:

	 sysctl kern.maxfiles

Note that this thing pretends you can set it via a sysctl; you
*CANNOT*; there are statically sized tables that do not grow,
and your number of network, etc., connections will not be increased
by you setting this via sysctl -- SO DON'T DO THAT.

If you know how to use the boot loader rc file, then you can set
"kern.maxfiles=10000" in the loader.  If you don't, then use
"options MAXFILES=10000" and recompile your kernel, instead.

The reason I suggested MAXUSERS first is that there are other
things that it tunes, and you might bump your head on those
things, too, later (i.e. preventative maintenance).

-- Terry