This article highlights some of the common NIS problems you may face alongside the possible solutions. The approach to highlighting and addressing the potential issues will depend on whether the problem is a NIS server issue or a NIS client issue.
Identifying and Solving NIS Client Issues
You will likely face an array of NIS client issues during your interaction with the NIS protocol. Notably, commands will often hang, the service may be unavailable, and there is a failed ypbind daemon or an inconsistent ypwhich utility.
The following are some of the problems and their possible solutions:
Network Information Service Problems Affecting a Single Client
Usually, one or two problems could experience symptoms directing to binding issues while the rest of the machines are okay. Such problems are pretty specific and will be on the affected clients. But, if many client machines within your system have a similar issue, the problem will most likely be from one of your server machines.
ypbind Failure on a Client
A single client can have problems in a single client while the rest of the client machines or the same subnet are running normally. Run ls-1 on the device with the issue over a shared directory, such as /usr, which contains files owned by most clients, including some files not in the client’s /etc/passwd file.
The result should list file owners not within the /etc/passwd as names. If it displays them as numbers, the indication is that the NIS service is faulty. Of course, the diagnosis is that the ypbind process in the client is not running.
Check the ypbind by running the ps –e. If the ypbind is missing, proceed to log in as a super user and type the following command to start ypbind:
Incorrect or Missing Domain Name
Another problem that can occur to a single client in your system could result from an incorrect or a missing domain. This issue occurs even when the ypbind is operating normally.
You can sort out this by first running the domainname command, since this will provide you with the result of the set domain name.
For example:
Compare the output of the previous utility with the actual domain name saved in your NIS master server’s /var/yp directory. The actual domain should be available as a subdirectory in your master server’s /var/yp directory.
Suppose the domain name result provided after running the domainname command on the machine with the issue is different from the actual domain name in the server machine. In that case, it will be an incorrect domain.
Besides, sometimes the domainname command may bring back a missing result. In either case, log in as a super user and correct the anomaly on the client machine. Once done, reboot the machine.
Client Has No Binding to a Server
Commands can still hang even with the correct domain name and a running ypbind. Such issues arise when the client is not bound to a server. So, bind the client to a server by running the ypwhich command. If you just started ypbind but still find reports of nonexistent binding between your domain and the client, try running ypwhich several times.
ypbind Crashes
If your ypbind hangs or crashes as soon as you start it, the problem exists in a different part of your system. You can begin your assessment by checking the availability of the rpcbind daemon using the following command:
Proceed to consult the RPC documentation if the rpcbind daemon is unavailable, hangs too soon, or behaving strangely. Establish communication with the rpcbind daemon on the faulty client from a non-problematic machine. So, you can type the following command from a functioning client:
The rpcinfo will produce the following display if the rpcbind on the problematic client machine is operating well:
Your machine should have a list of different addresses. But, if the display does not have a list of addresses, it shows that ypbind cannot register the requested services. Go ahead and reboot your machine before rerunning the rpcinfo. But, if the available ypbind processes change every time you restart the /usr/lib/netsvc/yp/ypbind/, reboot your machine irrespective of whether ypbind is running or not.
Unavailable NIS Service
One client machine can have this problem as the rest run normally. The following symptoms will show up when NIS service seizes to be available in your system:
- Some commands will bring back a NIS unavailable error message, while others will run correctly
- Crashing commands or daemons with or without an error message
- Commands limping in a backup-strategy mode
You can see either of the following display in case of unavailable NIS service:
Or the display as shown below:
The solution to problems similar to the ones above is to run ls-1 on the machine with the problem over a shared directory, such as /usr, which contains files owned by most clients, including some files not in the client’s /etc/passwd file.
Problems Affecting All Client Machines in Your Network
Problems that can affect all client machines in your system include:
Hanging Commands
Commands will often hang. This is arguably one of the most prevalent problems on NIS client devices. A command can always hang even when the system works well and other utilities run successfully. The console will generate a message similar to the following figure in case this happens:
The previous display indicates that the client ypbind daemon does not communicate with the ypserv daemon on the linhint domain. Such a problem happens due to the failure of systems that run on the ypserv daemon. It can also occur due to an overloaded network or server that makes the ypserv daemon unable to send responses back to your client ypbind before the time-out period elapses.
While this problem will show on all client machines, it is often temporary. It automatically solves itself when the server machine reboots and your ypserv daemon restarts. Alternatively, it will go when the load on the server or network goes down.
NIS Server Problems
The following are the most common NIS server problems:
Existence of Different NIS Map Versions
NIS propagates maps among servers. But sometimes, different map versions can exist on your network servers. You can correct this by running the ypxfr command, particularly if all servers and routers are running correctly.
You can also run the previous command on a slave server if the server has issues updating a map. But, if this command fails, you will receive an error message with the failure details and how you can correct the issue. You can still go ahead and check the problem using the following command:
Inoperable ypserv daemon
The ypserv daemon can repeatedly crash immediately after restarting. If this happens, begin by looking up the portmap daemon using the command below:
Reboot the server if you fail to get the portmap daemon. Once you get the daemon, use the following command:
Linhint in the previous command is our server hostname. You will notice that port numbers are different on your faulty machine:
The ypserv utility cannot register services under it if you do not find entries such as those shown in the previous illustration. In that case, reboot your machine. You also need to reboot the machine if the server entries are available but change whenever you restart the /usr/lib/netsvc/yp/ypserv utility.
Conclusion
This article discussed how to troubleshoot the NIS problems that users face and provide the solutions through addressing potential NIS server or NIS client issues. In addition, problems affecting all client machines in your network, such as existence of different NIS map versions and inoperable ypserv daemon were highlighted.
