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 parentrpc.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 -e | 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 entry, you must kill all but one of them. Use svcadm disable to stop the unwanted services, then run the ps command again to make sure the unwanted daemons have died.
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.