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 worker server has problems updating a map, use the following procedure to detect and solve the problem:

1. 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.
2. 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.

3. 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.
4. If you are still experiencing problems, inspect the system /etc/crontab entries in the log, and the ypxfr shell scripts it invokes.
5. Make sure that the NIS worker server is in the ypservers map. If not, the yppush command cannot notify the worker server when a new copy of a map exists.