Pinging and Checkpointing in NIS+

When a change is made to the NIS+ data set, that change is made in the memory of the master server for the NIS+ domain (or subdomain). A record of the change is also logged in the master server's transaction log (/var/nis/data/trans.log).

Normally, the master server transfers a change in the NIS+ data set to the domain's replica servers 120 seconds (2 minutes) after the change was made. This transfer process is called pinging. When the master server pings a replica, it updates the replica's data set with the change. The changed NIS+ data now resides in memory of the master and replica servers.

If the automatic ping process fails to update one or more replica servers, you need to manually force a ping as described in Forcing a Ping in NIS+. If you suspect that a replica has not been correctly updated with the most current NIS+ data, you can check when the replica was last updated as described in Displaying When NIS+ Replicas Were Last Updated.

Changes to the NIS+ data set stored in server memory and recorded in the transaction log need to be written into the NIS+ tables stored on disk. The process of updating the NIS+ tables is called checkpointing.

Checkpointing is not an automatic process. You must issue the checkpoint command as described in Checkpointing an NIS+ Directory.

`nisping` Command

The nisping command is used to:

Display when a replica was last pinged as described in Displaying When NIS+ Replicas Were Last Updated.
Force the master server to ping a replica if the automatic ping cycle has not been successful as described in Forcing a Ping in NIS+.
Checkpoint servers as described in Checkpointing an NIS+ Directory.

Displaying When NIS+ Replicas Were Last Updated

When used with the -u option, the nisping command displays the update times for the master and replicas of the local domain.

/usr/lib/nis/nisping -u [domain]

To display the last updates in some other domain, specify the domain name in the command line. Note that when used with the -u option, the nisping command does not actually ping any replicas.

For example, to display the most recent replica update times for the local doc.com. domain, you would enter:

rootmaster# /usr/lib/nisping -u
Last updates for directory doc.com.:
Master server is rootmaster.doc.com.
 Last update occurred at Wed Nov 25 10:53:37 1992
Replica server is rootreplica1.doc.com.
 Last update seen was Wed Nov 25 10:53:37 1992

Forcing a Ping in NIS+

If the nisping -u command reveals that a replica has not been properly updated, you can use the nisping command to force the master server to ping all the replicas in a domain, or one replica in particular.

To ping all the replicas, use the nisping command without options:

/usr/lib/nis/nisping

This forces the master server to ping all the replicas in the domain. Here is an example that pings all the replicas of the local doc.com. domain:

rootmaster# /usr/lib/nis/nisping
Pinging replicas serving directory doc.com.:
Master server is rootmaster.doc.com.
 Last update occurred at Wed Nov 25 10:53:37 1992
Replica server is rootreplica1.doc.com.
 Last update seen was Wed Nov 18 11:24:32 1992
 Pinging ... rootreplica1.doc.com.

To ping all the replicas in a domain other than the local domain, append a domain name:

/usr/lib/nis/nisping domainname

You can also ping all the tables in all the directories on a single specified host. To ping all the tables in all the directories of a particular host, use the -a option:

/usr/lib/nis/nisping -a hostname

Checkpointing an NIS+ Directory

Each domain and subdomain should be checkpointed at least once every 24 hour, or more often if the transaction log grows too large in relationship to swap space or total disk space.

Note - Checkpointing large domains, or any domain with a large transaction log, is a time-consuming process which ties up NIS+ servers and slows NIS+ service. While a server is checkpointing, it will still answer requests for service, but it will be unavailable for updates. If possible, checkpoint operations should be scheduled for times when system use is low. You can use the cron file to schedule checkpoint operations.

To perform a checkpoint operation, run nisping -C on the domain's master server. It is good practice to first ping all replicas before checkpointing. This ensures that the replicas are checkpointing data that is current and up to date.

To checkpoint a particular directory, run the nisping command with the -C directoryname option. For example,
```
rootmaster# /usr/lib/nis/nisping
rootmaster# /usr/lib/nis/nisping -C org_dir
```
To checkpoint all the directories in the local domain, run the nisping command with the -C -a options. For example,
```
rootmaster# /usr/lib/nis/nisping
rootmaster# /usr/lib/nis/nisping -C -a
```

Once a server has transferred information from the server's transaction log to the appropriate NIS+ tables, the transactions in the log file are erased to conserve disk space.

For example, to checkpoint all of the directories in the doc.com. domain, you would enter:

rootmaster# /usr/lib/nis/nisping -C -a
Checkpointing replicas serving directory doc.com. :
Master server is rootmaster.doc.com.
 Last update occurred at Wed May 25 10:53:37 1995
Master server is rootmaster.doc.com.
checkpoint has been scheduled with rootmaster.doc.com.
Replica server is rootreplica1.doc.com.
 Last update seen was Wed May 25 10:53:37 1995
Replica server is rootreplica1.doc.com.
checkpoint has been scheduled with rootmaster.doc.com.

Skip Navigation Links
Exit Print View
	System Administration Guide: Naming and Directory Services (NIS+)