This section covers problems related to the namespace database and tables. Common symptoms include error messages with operative clauses such as:
Abort_transaction: Internal database error
as well as when rpc.nisd fails.
See also "NIS+ Ownership and Permission Problems".
You have multiple independent rpc.nisd daemons running. In normal operation, rpc.nisd can spawn other child rpc.nisd daemons. This causes no problem. However, if two parent rpc.nisd daemons are running at the same time on the same machine, they will overwrite each other's data and corrupt logs and databases. (Normally, this could only occur if someone started running rpc.nisd by hand.)
Run ps -ef | grep rpc.nisd. Make sure that you have no more than one parent rpc.nisd process.
If you have more than one "parent" rpc.nisd entries, you must kill all but one of them. Use kill -9 process-id, then run the ps command again to make sure it has died.
If you started rpc.nisd with the -B option, you must also kill the rpc.nisd_resolv daemon.
If an NIS+ database is corrupt, you will also have to restore it from your most recent backup that contains an uncorrupted version of the database. You can then use the logs to update changes made to your namespace since the backup was recorded. However, if your logs are also corrupted, you will have to recreate by hand any namespace modifications made since the backup was taken.
If an NIS+ table is too large, rpc.nisd may fail.
Use nisls to check your NIS+ table sizes. Tables larger than 7k may cause rpc.nisd to fail.
Reduce the size of large NIS+ tables. Keep in mind that as a naming service NIS+ is designed to store references to objects, not the objects themselves.