Some of the error messages documented in this chapter are documented more fully in the appropriate man pages.
Some of the error messages documented in this chapter are documented more fully in the appropriate man pages.
Error messages can appear in pop-up windows, shell tool command lines, user console window, or various log files. You can raise or lower the severity threshold level for reporting error conditions in your /etc/syslog.conf file.
In the most cases, the error messages that you see are generated by the commands you issued or the container object (file, map, table or directory) your command is addressing. However, in some cases an error message might be generated by a server invoked in response to your command (these messages usually show in syslog). For example, a "permission denied" message most likely refers to you, or the machine you are using, but it could also be caused by software on a server not having the correct permissions to carry out some function passed on to it by your command or your machine.
Similarly, some commands cause a number of different objects to be searched or queried. Some of these objects might not be obvious. Any one of these objects could return an error message regarding permissions, read-only state, unavailability, and so forth. In such cases the message may or may not be able to inform you of which object the problem occurred in.
In normal operation, the naming software and servers make routine function calls. Sometimes those calls fail and in doing so generate an error message. It occasionally happens that before a client or server processes your most recent command, then some other call fails and you see the resulting error message. Such a message might appear as if it were in response to your command, when in fact it is in response to some other operation.
When working with a namespace you might encounter error messages generated by remote procedure calls. These RPC error messages are not documented here. Check your system documentation.
A single error message might have slightly different meanings depending on which part of various naming software applications generated the message. For example, when a "Not Found" type message is generated by the nisls command, it means that there are no NIS+ objects that have the specified name, but when it is generated by the nismatch command it means that no table entries were found that meet the search criteria.
The error messages in this appendix are sorted alphabetically according to the following rules:
Capitalization is ignored. Thus, messages that begin with "A" and "a" are alphabetized together.
Nonalphabetic symbols are ignored. Thus, a message that begins with _svcauth_des is listed with the other messages that begin with the letter "S."
Error messages beginning with (or containing) the word NIS+ are alphabetized after messages beginning with (or containing) the word NIS.
Some error messages might be preceded by a date or the name of the host, application, program, or routine that generated the error message, followed by a colon. In these cases, the initial name of the command is used to alphabetize the message/
Many messages contain variables such as user IDs, process numbers, domain names, host names, and so forth. In this appendix, these variables are indicated by an italic typeface. Because variables could be anything, they are not included in the sorting of the messages listed in this appendix. For example, the actual message sales: is not a table (where sales is a variable) would be listed in this appendix as: name: is not a table and would be alphabetized as: is not a table among those messages beginning with the letter "I".
Error messages that begin with asterisks, such as **ERROR: domainname does not exist, are generated by the NIS+ installation and setup scripts. They are alphabetized according to their first letter, ignoring the asterisks.
Many DNS or other messages include an IP address. IP addresses are indicated by n.n.n.n.
Some error messages include numbers such as process ID numbers, number of items, and so forth. Numbers in error messages are indicated: nnnn.
FNS messages are encapsulated in the FN_status_t object as status codes. See the FN_status_t man page for the corresponding status codes
When an error occurs, FNS commands print out the remaining part of the name on which the operation failed. The part of the name that has not been printed has been processed successfully.
For example, a user attempted to create a context for org//service/trading/bb. The name org//service/ was resolved successfully, but trading was not found in the context named by org//service/. Thus, trading/bb is displayed as the part of the name that remains when the operation failed:
Error in creating 'org//service/trading/bb': Name Not Found: 'trading/bb' |
In another example, a user attempted to destroy the context org//service/dictionary/english, but could not carry out the operation because the context named was not empty. The pair of single quotes ('') indicates that FNS was able to resolve the complete name given, but could not complete the operation as requested:
Error in destroying 'org//service/dictionary/english': Context Not Empty: '' |