Network Information Services (NIS and NIS+) Guide

Troubleshooting NIS-Related Problems

The approach to troubleshooting a Network Information Service (NIS) problem depends on whether the problem is at the NIS client (see Identifying NIS Client Problems) or the NIS server (see Identifying NIS Server Problems).

Identifying NIS Client Problems

NIS client problems most commonly occur at the following times:

Note: When attempting to solve one map problem, keep in mind that the same problem may be affecting other maps as well. See Files where NIS Appends Map Information for a more detailed explanation.

Using rsh

When a machine has two interfaces and they both are given the same name, gethostbyname lookups for rsh command will fail if NIS is being used because NIS does not return both addresses, but only the first one found. This is an implementation limitation imposed by the New Database Manager (NDBM) and performance considerations. The error message is:

0826-825: there is a host address that does not match

When Commands Hang

The most common problem occurring at an NIS client node is for a command to hang. A command can appear to hang, even though the system seems to be operating correctly. In such a case, a message similar to the following can be generated at the console:

NIS: server not responding for domain domainname. Still trying

This error message indicates that the ypbind daemon on the local machine is unable to communicate with the ypserv daemon in the given domain because systems that run the ypserv daemon have failed. It may also occur if the network or the NIS server machine is overloaded to the extant that the ypserv daemon cannot return a response to your ypbind daemon within the time-out period.

Under these circumstances, all the other NIS clients on your network show the same or similar problems. The condition is usually temporary. The messages are cleared when the NIS server machine reboots and the ypserv daemon restarts, or else when the load on the NIS server and the network decreases.

If the ypbind daemon is communicating with the ypserv daemon and the NIS server is not overloaded, one of the following problems may exist:

The domainname on the NIS client machine is not set or is set incorrectly. Clients must use a domain name that the NIS servers recognize. The domain name is case-sensitive and initially set with lowercase letters. If this is case, set the domain correctly.
Your local network may not have an NIS server machine. You can automatically bind only to a ypserv process on your local network. Binding on servers residing on other networks through a gateway requires using the ypset command. Two or more NIS servers (one master and several slave servers) can improve availability and response characteristics for NIS services.
The NIS server may not be up and running. Check other machines on your local network. If several clients have problems simultaneously, the server may be the cause.
On a client system that is working normally, run the ypwhich command. If the ypwhich command never returns an answer, stop the command. Then type the following at the NIS server machine:
```
ps -ef | grep yp
```
Look for the ypserv and ypbind processes. If the server's ypbind daemon is not running, start the daemon, using the instructions in Starting and Stopping NIS Daemons.
If a ypserv process is running, run the ypwhich command on the NIS server machine. If this command returns no answer, stop and restart the ypserv daemon by following the instructions in Starting and Stopping NIS Daemons.

When NIS Service Is Unavailable

When other machines on the network appear to have no problems, but NIS service becomes unavailable on your system, a variety of symptoms can occur:

Some commands may operate correctly while others terminate and produce an error message about the unavailability of NIS.
Some commands run slowly in a backup-strategy mode particular to the program involved.

Some commands or daemons crash with error messages or no message at all.

For example, messages such as the following might be generated:

ypcat myfile
ypcat: can't bind to NIS server for domain <wigwam>
Reason: can't communicate with ypbind.

/usr/etc/yp/yppoll myfile
RPC: timed out

When symptoms like these occur, do the following:

Run the ls -l command in a directory containing files owned by many users, including users not in the local machine's /etc/passwd file.
In the listing, determine whether file owners who are not in the local machine's /etc/passwd file are shown as numbers rather than names. If so, NIS is not working, usually because the ypbind daemon is not running.
Use the ps -ef command and look for the ypbind daemon in the list of processes. If it is not there, start it by following the instructions in Starting and Stopping NIS Daemons.

When the ypbind Daemon Becomes Inoperable

If the ypbind daemon repeatedly crashes immediately after it is started, look for a problem in some other part of the system.

Check for the presence of the portmap daemon by typing:
```
ps -ef | grep portmap
```
If the daemon is not running, reboot the system.
If the portmap daemon is running but does not operate reliably, check the network software.
Try to communicate with the portmap daemon on your machine from a different machine that is operating normally. From such a machine, type:
```
rpcinfo -p client
```
where client is the host name of the machine.

If the portmap daemon is up and running correctly, the output appears in a format similar to the following:

program   vers proto  port
100007     2    tcp   1024  ypbind
100007     2    udp   1028  ypbind
100007     1    tcp   1024  ypbind
100007     1    udp   1028  ypbind
100021     1    tcp   1026  nlockmgr
100024     1    udp   1052  status
100020     1    udp   1058  llockmgr
100020     1    tcp   1028  llockmgr
100021     2    tcp   1029  nlockmgr
100012     1    udp   1083  sprayd
100011     1    udp   1085  rquotad
100005     1    udp   1087  mountd
100008     1    udp   1089  walld
100002     1    udp   1091  rusersd
100002     2    udp   1091  rusersd
100001     1    udp   1094  rstatd
100001     2    udp   1094  rstatd
100001     3    udp   1094  rstatd

If the daemons are not listed, the ypbind daemon is unable to register its services. Reboot the machine.
If the daemons are listed, but they change each time you try to restart the ypbind daemon, reboot the system (even though the portmap daemon is up).

When the ypwhich Command Is Inconsistent

When you use the ypwhich command several times at the same client node, the response varies because the status of the NIS server changes. The status changes are normal.

The binding of NIS client to NIS server changes over time on a busy network, when the NIS servers are busy. Whenever possible, the system stabilizes so that all clients get acceptable response time from the NIS servers. The source of an NIS service is not important, because an NIS server machine often gets its own NIS services from another NIS server on the network.

Identifying NIS Server Problems

NIS server problems can most commonly occur at the following times:

When Different Versions of an NIS Map Exist

Because NIS works by propagating maps among servers, you can sometimes find different versions of a map at the network servers. This is normal only as a temporary situation. Normal update is prevented when an NIS server or a router between NIS servers is down during a map transfer attempt. When all the NIS servers and all the routers between them are up and running, the ypxfr command should run successfully. If a particular slave server has problems updating a map, use the following procedure to detect and solve the problem:

Log in to the problem server and run the ypxfr command interactively. If this command fails, use the information in the error message to fix the problem.
If the ypxfr command succeeds, but you still suspect a problem, create a log file to enable logging of messages by typing the following:
```
cd /var/yp
touch ypxfr.log
```
This saves all output from the ypxfr command to the ypxfr.log file. The output looks much like what the ypxfr command creates when it is run interactively, but each line in the log file is time stamped. The time stamp tells when the ypxfr command began its work. It is normal to see unusual orderings in the time stamps. If copies of the ypxfr command ran simultaneously but their work took differing amounts of time, the summary status line may be written to the log files in an order that differs from the order in which they were invoked.
Examine the log for any pattern of intermittent failure. After you fix the problem, turn off logging by removing the log file; otherwise, it continues to grow without limit.
If you are still experiencing problems, inspect the system /etc/crontab entries in the log, and the ypxfr shell scripts it invokes.
Make sure that the NIS slave server is in the ypservers map. If not, the yppush command cannot notify the slave server when a new copy of a map exists.

When the ypserv Daemon Becomes Inoperable

When the ypserv process repeatedly crashes immediately after it is started, the debugging process is similar to that described for ypbind crashes. First, check for the portmap daemon:

ps -ef | grep portmap

If you do not find the portmap daemon, reboot the server. If there is a portmap daemon, type:

rpcinfo -p hostname

where hostname is the host name of the NIS server.

On your particular machine, the port numbers will be different. The four entries that represent the ypserv daemon are:

100004     2   udp   1027  ypserv
100004     2   tcp   1024  ypserv
100004     1   udp   1027  ypserv
100004     1   tcp   1024  ypserv

If these entries do not exist, the ypserv daemon is unable to register its services. Reboot the machine. If the ypserv entries exist, but they change each time you try to restart the ypserv daemon, reboot the machine again.