Commands hang on clients (server not responding)

The most common problem of NIS clients is for a command to hang and generate console messages such as:

   yp: server not responding for domain domainname. Still trying

The message above indicates that ypbind on the local machine is unable to communicate with ypserv in the domain domainname. This happens when a machine running ypserv has crashed and ypbind is unable to find another NIS server. It may also occur if the network or NIS server is so overloaded that ypserv cannot get a response back to the client's ypbind within the timeout period.

Under these circumstances, every client on the network will experience the same or similar problems. The condition is temporary in most cases. The messages will usually go away when the NIS server reboots and restarts ypserv or when the load on the NIS server or network itself decreases.

However, commands may hang and require direct action to clear them. The following list describes the causes of such problems and gives suggestions for fixing them:

• The NIS client has not set, or has incorrectly set, the domainname on the machine. Clients must use a domain name that the NIS servers know.

  On the client, enter domainname to see which domain name is set. Compare that with the actual domain name in /var/yp on the NIS master server. If a machine's domain name is not the same as the server's, the machine's domain name entry in its installation scripts is incorrect. Log in as NIS administrator, edit the client's installation scripts, and correct the domainname entry. This ensures the domain name is correct every time the machine boots. Then set domainname manually by entering:
  
  domainname good_domain_name

• If your domain name is correct and commands still hang, make sure that at least one of the servers in /var/yp/binding/domainname/ypservers is reachable. Alternatively, if broadcasting is enabled, make sure there is at least one server on the same subnet as the client. Clients that use broadcasting can only bind to servers on their local subnet; if no servers are available on the subnet, the name of a server that is accessible on another network or subnet must be present in the ypservers file. In this case, the IP address for the server on the other network or subnet must be in the /etc/inet/hosts file.

  The ypset command may also be used to allow binding to a specific server. However, if ypbind has not been started with either of the -ypset or -ypsetme options, this kind of binding is not possible. For security reasons, limit the use of -ypset to debugging purposes under controlled circumstances. Using -ypsetme can also result in serious security breaches. If you must start ypbind with the -ypset or -ypsetme option, once you have fixed the problem kill ypbind and restart it again without the option.

• If your local network has an NIS server and commands still hang, make sure the server is up and running. Check other machines on your local network. If several clients also have problems, suspect a server problem. Try to find a client machine behaving normally, and enter the ypwhich command on it. If ypwhich does not respond, kill it and go to a terminal on the NIS server. Enter:
  
  ps -eaf | grep yp

  Look for ypserv and ypbind processes. If the server's ypbind daemon is not running, start it by entering:
  
  /usr/lib/netsvc/yp/ypbind

  If a ypserv process is running, enter:
  
  ypwhich

  on the NIS server. If ypwhich does not respond, ypserv has probably hung. Restart it by entering the following while logged in as NIS administrator:
  
  ps -eaf | grep ypserv
  kill pid
  /usr/lib/netsvc/yp/ypserv

  where pid is the process ID for ypserv. If ps shows no ypserv process running, start one up.

• If the server's ypbind daemon is not running, start it up by entering:
  
  /usr/lib/netsvc/yp/ypbind

  Notice that if you run ypbind and you enter ypwhich immediately, ypwhich will return the error message ``not found'' in all cases. Run ypwhich again; it should now return the name of a server.

• If commands still hang, try the following:

  1. Kill the existing ypbind:
     
     ps -eaf | grep ypbind
     kill pid

     where pid is the process-ID for ypbind.

  2. Restart ypbind with the ypset option that permits root to change the server:
     
     /usr/lib/netsvc/yp/ypbind -ypsetme

  3. Reset the server to one you know is reliable:
     
     ypset servername