Fails to add/modify entry
- The connection to the directory server might be down. The Admin Server might need to be restarted.
Cannot add the following entry ...
- The connection to the directory server might be down. The Admin Server might need to be restarted.
Cannot access Content Manager
- Admin server might be down. Restart Admin Server.
Failed to delete entry:
- The connection to the directory server might be down. The Admin Server might need to be restarted.
... does not exists in the directory
- Directory structure might be inconsistent. Check the DN to make sure the node exists in the directory.
Contains invalid input value.
- Check the indicated field to make sure it contains the valid information.
Search failed
- The connection to the directory server might be down. The Admin Server might need to be restarted.
Cannot find Administrative Server
- Admin server might be down. Restart Admin Server.
Cannot find main Admin Console
- Admin Console is not connected. Try go back to the main login page and go through the login process.
Create group failed
- The connection to the directory server might be down. The Admin Server might need to be restarted.
Cannot find owner DN
- Inconsistent directory information. Manual inspection of the directory is required.
Cannot access session
- Admin Console is not connected. Try go back to the main login page and go through the login process.
Create group failed due to RMI error
- Transport error. Try restart the HotJava browser.
Cannot find moderator DN
- Inconsistent directory information. Manual inspection of the directory is required.
Parent node does not exist: ...
- Inconsistent directory information. Manual inspection of the directory is required.
Cannot authenticate to LDAP server: ...
- The directory server might be down. Restart the directory server
Failed to initialize LDAP library: ...
- The LDAP client library is not found in the library search path. Check installation components.
Cannot connect to LDAP server: ...
- The directory server might be down. Restart the directory server
Cannot delete entry because SMCS is using this context
- The delete operation is stopped because the entry is under SMCS control. Please verify the operation.
Cannot delete root dn
- User tried to delete the root folder from the Admin Console. Attempt to do this will result in attempt to remove "all" of the entries in the directory.
You need to search logs before saving them.
- You are attempting to save the current display before completing the search of log entries. Perform a search of desired log entries by selecting the desired search criteria then click the Search button. Log entries that match your specified criteria will display. Click on the Log Manager menu and select Save the current display.
These messages may occur while using the IMTA and IMTA channel property books.
IMTA Channel Property Book Error Messages
IMTA is already running.
- You are attempting to start the IMTA when it is already running. If desired, you can restart the IMTA from the IMTA property book by clicking on the IMTA menu and selecting Restart IMTA, or Stop IMTA then Start IMTA.
[Add channel] Channel name already exists.
- You are attempting to create a channel with a name that already exists. Specify a unique name for the channel you are attempting to create.
Please select a channel
- From the Selected menu in the IMTA property book, you chose an option other than Monitor Queue but did not select a channel from the Channels section. Select a channel from the Channels section by clicking on it. Click on the Selected menu and choose the desired option.
This channel is not configurable.
- You are attempting to configure an internal channel (reprocessing, conversion, and defragmentation channels). Internal channels cannot be configured using the Admin Console.
Invalid entry in field: Pattern: <> Please change the value
before continuing.
- In the Rewrite Rules section of the IMTA channels property book, you have entered an invalid entry for the pattern or a blank pattern and clicked the Add button. Refer to "To Add, Delete, or Modify a Rewrite Rule" on page 110 for more information on the correct syntax for entering a pattern. Try to add the rewrite rule again.
Invalid entry in field: Template: <ddsdsd hhh> Please change
the value before continuing.
- In the Rewrite Rules section of the IMTA channels property book, you have entered an invalid entry for the template and clicked the Add button. Refer to "To Add, Delete, or Modify a Rewrite Rule" on page 110 for more information on the correct syntax for entering a template. Try to add the rewrite rule again.
IMTA Start-up Failure Error Messages
These messages appear at the command line when the IMTA fails to start up. There are a number of general sorts of issues that can interfere with the running of a variety of IMTA components; such issues include general syntax errors in an IMTA configuration, or license problems, or disk/quota problems leading to trouble writing files. The following are some of the more common general error messages.
Note that the imta test -rewrite utility will give warnings of many such common issues and with more detailed error messages than some other components of the IMTA may display. So imta test -rewrite can be a useful diagnostic tool to see the type of error generated.
Specific IMTA components may also issue other error messages, specific to that component. So when you an encounter an error not described below, see also the documentation on the IMTA component in question.
Compiled configuration version mismatch
- One of the functions of the imta cnbuild utility is to compile IMTA configuration information into an image that can be loaded quickly. The compiled format is quite rigidly defined and often changes substantially between different versions of the IMTA. Minor changes may also occur as part of mid-version releases.
- When such changes occur an internal version field is also changed so that incompatible formats can be detected. When an incompatible format is detected the IMTA components will halt with the above error. The solution to this problem is simply to generate a new compiled configuration with the UNIX command,
- # imta cnbuild -option
- It is also a good idea to use the imta restart command to restart any resident IMTA server processes so they can obtain updated configuration information.
File open or create errors
- In order to send a message, the IMTA needs to read configuration files and create message files in the IMTA message queue directories. Configuration files must be readable to the user, which generally implies world read access on the files in the IMTA table directory. During installation, proper protections are assigned to these files. The IMTA utilities and procedures which create configuration files also assign proper protections. If the files are protected by the system manager or other privileged user or through some site-specific procedure, the IMTA may not be able to read configuration information. This will result in "File open" errors or unpredictable behavior. The imta test -rewrite utility will report additional information when it encounters problems reading configuration files. See the imta-test-rewrite man page for information on using this utility.
- If the IMTA appears to function from privileged accounts but not from unprivileged accounts, then file protections in the IMTA table directory are likely to blame. Check the protections on configuration files and their directories. The only files that should be protected against world read access in the table directory are the queue cache database or other channel option files which may contain password information.
- "File create" errors usually indicate a problem while creating a message file in an IMTA message queue directory. See "Check Message Queue Directories" on page 279 for procedures to aid in diagnosing file creation problems.
Errors in mm_init
An Error in mm_init error generally indicates an IMTA configuration problem. Thus the imta-test-rewrite utility, which is often used to test the health of an IMTA configuration, may return such an error, as may other utilities such as
imta cnbuild, or a channel, or server, or user agent trying to run may return such an error.
In particular, one of the more commonly encountered sorts of mm_init errors is a "No room in table" error or similar "No room in ..." sort of error. Generally, "no room in" errors are an indication that your current IMTA configuration has not set internal table sizes sufficient for the size of your IMTA configuration, and that it is time to have the IMTA resize its internal tables. (Note that the IMTA stores configuration information in internal tables in memory. To prevent unnecessary use of excessive amounts of virtual memory, these tables are allocated with fixed sizes. The sizes of the tables are controlled by values in the IMTA option file.)
However, some particular such "no room in ..." error messages may have alternate causes, and such cases are called out below. Any other "no room in" errors not explicitly mentioned are most likely simply an indication of a need to resize internal tables.
Rather than manually calculating and setting table sizes, you should use the
imta cnbuild utility to automatically resize the tables for you. See the
imta-cnbuild man page and SIMS Reference Manual for more information.
Following are some of the more commonly encountered mm_init errors.
bad equivalence for alias ...
- The right hand side of an alias file entry is improperly formatted.
cannot open alias include file...
- A file included into the alias file cannot be opened. This typically indicates a protection problem with a file referenced by the file include operator, <. Note that such included files (like the alias file itself) must be world readable.
duplicate alias(es) found ...
- Two alias file entries have the same left hand side; you will need to find and eliminate the duplication.
duplicate host in channel table ...
- In its literal meaning, this error says that you have two channel definitions in the IMTA configuration that both have the same official host name.
- But note that an extraneous blank line in the rewrite rules (upper portion) of your IMTA configuration file causes the IMTA to interpret the remainder of the configuration file as channel definitions, and as there are often multiple rewrite rules with the same pattern (left hand side), this then causes the IMTA to think it is seeing channel definitions with non-unique official host names. So check your IMTA configuration both for any channel definitions with duplicate official host names, and for any improper blank lines in the upper (rewrite rules) portion of the file.
duplicate mapping name found ...
- This error literally means that two mapping tables have the same name, and one of the "duplicates" needs to be removed. However, note that formatting errors in the mapping file may cause the IMTA to interpret something not intended as a mapping table name as a mapping table name; for instance, failure to properly indent a mapping table entry will cause the IMTA to think that the left hand side of the entry is actually a mapping table name. So check your mapping file for general format, as well as checking the mapping table names.
error initializing ch_ facility: compiled character set version
mismatch
- Such an error generally means that you need to recompile and reinstall your compiled character set tables via the command:
- # imta chbuild
- See the documentation for imta chbuild for additional details.
error initializing ch_ facility: no room in ...
- Such an error likely means that you need to resize your IMTA character set internal tables and then rebuild the compiled character set tables via the commands
- # imta chbuild -noimage -maximum -option
# imta chbuild
- See the man page for imta-chbuild for additional details.
local host alias or proper name too long for system ...
- This error literally means that a local host alias or proper name (the optional right hand side in the second or subsequent names in a channel block) is too long. However, note that certain syntax errors earlier in the IMTA configuration file (an extraneous blank line in the rewrite rules, for instance) may cause the IMTA to interpret something not intended as a channel definition as a channel definition. So besides checking the indicated line of the configuration file, also check above that line for other syntax errors and in particular, if the line on which the IMTA issues this error is intended as a rewrite rule, then be sure to check for extraneous blank lines above it.
mapping name is too long ...
- This error literally means that a mapping table name is too long and needs to be shortened. However, note that formatting errors in the mapping file may cause the IMTA to interpret something not intended as a mapping table name as a mapping table name; for instance, failure to properly indent a mapping table entry will cause the IMTA to think that the left hand side of the entry is actually a mapping table name. So check your mapping file for general format, as well as checking the mapping table names.
no equivalence addresses for alias ...
- An entry in the alias file is missing a right hand side (translation value).
no official host name for channel ...
- This error indicates that a channel definition block is missing the required second line (the official host name line). See the Channel Definition Chapter in the SIMS Reference Manual for a discussion of the format of channel definition blocks. In particular, note that a blank line is required before and after each channel definition block, but a blank line must not be present between the channel name and official host name lines of the channel definition; also note that blank lines are not permitted in the rewrite rules portion of the IMTA configuration file.
no room in ...
- Generally, "no room in" errors are an indication that your current IMTA configuration has not set internal table sizes sufficient for the size of your IMTA configuration, and that it is time to have the IMTA resize its internal tables. See the imta-cnbuild man page and SIMS Reference Manual. However, some particular such "no room in..." error messages may have alternate causes, and such cases are called out below. Any other "no room in..." errors not explicitly mentioned are most likely simply an indication of a need to resize internal tables.
no room in channel host table for ...
- This error indicates that your configuration's current IMTA internal table sizes are not large enough for the number of host names listed in your channel definitions. However, note that an extraneous blank line in the rewrite rules (upper portion) of your IMTA configuration file causes the IMTA to interpret the remainder of the configuration file as channel definitions; with just one such extraneous blank line, the IMTA sees just one extra channel but with a lot (all the rest of the rewrite rules) as host names on that channel. So check the line of the file that the error is complaining about---if it is not truly intended as a host name on a channel definition but rather is a line in the rewrite rules section of your configuration file, then check for an extraneous blank line above it.
no room in channel table for ...
- This error indicates that your configuration's current IMTA internal table sizes are not large enough for the number of channels defined in your IMTA configuration. See cnbuild man page and SIMS Reference Manual.
no room in table for alias ...
- This error says that the current IMTA internal table sizes are too small for the number of aliases in the aliases file. This can be resolved either by resizing IMTA's internal table sizes--see the cnbuild man page and SIMS Reference Manual.
no room in table for mapping named ...
- In its literal meaning, this error says that your configuration's current IMTA internal table sizes are not large enough for your current number of mapping tables. Internal IMTA table sizes can be increased to match your current configuration side--see the cnbuild man page and SIMS Reference Manual. However, also note that formatting errors in the IMTA mapping file can cause the IMTA to think that you have more mapping tables than you really have; for instance, check that mapping table entries are all properly indented.
official host is too long
- The official host name for a channel (second line of the channel definition block) is limited to forty characters in length. So if you were trying to use a longer official host name on a channel, shorten it to a "placeholder" name and then use a rewrite rule to match the longer name to the short official host name. Note, however, that certain syntax errors earlier in the IMTA configuration file (an extraneous blank line in the rewrite rules, for instance) may cause the IMTA to interpret something not intended as a channel definition as a channel definition; that could result in an intended rewrite rule being interpreted as an official host name. So besides checking the indicated line of the configuration file, also check above that line for other syntax errors and in particular, if the line on which the IMTA issues this error is intended as a rewrite rule, then be sure to check for extraneous blank lines above it.
Log File Error Messages
The following error messages would be found in a log file.
Illegal host/domain errors
- Such an error may be returned immediately in response to an address provided to the IMTA through a user agent, or the error may be deferred and returned as part of an error return mail message. In all cases, such an error message indicates that the IMTA is not able to deliver mail to the specified host. Before diagnosing such problems any further, verify that the address in question is indeed correct and is not misspelled, transcribed incorrectly, or using the name of a host or domain which no longer exists.
- Try running the address in question through the imta test -rewrite utility. If this utility also returns an "illegal host/domain" error on the address, then the IMTA has no rules in its configuration file, imta.cnf and related files, to handle the address. Verify that you have configured the IMTA correctly, that you answered all configuration questions appropriately, and that you have kept your configuration information up to date.
- Otherwise, if imta test -rewrite does not encounter an error on the address, then the IMTA was able to determine how to handle the address, but the network transport would not accept it. You can examine the appropriate log files from the delivery attempt for additional details. Transient network routing or name service errors should not result in returned error messages, though it is possible for badly misconfigured domain name servers to cause such problems.
- If you are on the Internet, then check that MX record lookups work.
Errors in SMTP channels: os_smtp_* errors
- os_smtp_* errors, for example, os_smtp_open, os_smtp_read, or os_smtp_write errors, are not IMTA errors per se: they correspond to the IMTA reporting back about a problem encountered at the network layer. For instance, an os_smtp_open error means that the network connection to the remote side could not be opened, which may be due to addressing errors or channel configuration errors (the IMTA configured to attempt to connect to the "wrong" system), but is more commonly due to DNS problems or network connectivity problems (particularly if this is a channel or address that was previously working). os_smtp_read or os_smtp_write errors are usually an indication that the connection was aborted (either by the other side or due to network problems).
- Note that network and DNS problems are often transient in nature. It is normal to occasionally see such problems. Indeed, for connections to troublesome systems, it may even be common. So the occasional such error is usually nothing to be concerned about. However, if you are consistently seeing such errors on most messages on a channel, or seeing such errors on most messages to or from a particular remote system, then the errors may be an indication of an underlying network problem.
- If you need more information about an os_smtp_* error, enable debugging on the channel in question and get a debug channel log file showing details of the attempted SMTP dialogue. In particular, the timing of exactly when a network problem occurred during the SMTP dialogue tends to be suggestive as to what sort of network or remote side issue might be involved. In some cases, you may also want to do network level debugging (e.g., TCP/IP packet tracing) to see what was sent or received over the wire.
Queue Monitor Error Messages
This section contains error messages that you may receive while using the Queue Monitor, an explanation of the problem, and instructions on how to resolve the problem, if applicable.
qmonitorSvr.SelectMtaChannel(qChannel) of QMonitorPanel():
Channel created but yet to be configured.
- The object classes involved may not yet be assigned memory. Close extra windows or applications on your desktop and re-try again.
getQueMonitorRemoteObj() in QMonitorPanel: QUEUE MONITOR: Could
not communicate with the server due to a network problem.
- The IMTA may be down. Check the System Status section on the Admin Console home page to determine the status of the IMTA. If the IMTA is down, start it from the IMTA property book by clicking on the IMTA menu and selecting Start IMTA. If taking this action does not resolve this problem, contact your authorized service provider.
channelList.addElement in QMonitorPanel: Could not add channels
to channel list.
- There may be a network problem or the server may be down. Check your admin server, if it is down, restart the server, and then restart console.
Init() in QMonitorPanel: Could not allocate memory for resource
creation.
- The object classes involved may not yet be assigned memory. Close extra windows or applications on your desktop and re-try again.
Error getting imageURL of QMonitorPanel:LoadImageURLException
- Any or all pieces of the Uniform Resource Locator (URL) are not in the proper format. Contact your authorized service provider.
setChoiceBar() of QMonitorPanel: Could not allocate memory for
resource creation.
- The object classes involved may not yet be assigned memory. Close extra windows or applications on your desktop and re-try again.
scaleCounters() of QMonitorPanel: Could not allocate memory for
resource creation.
- The object classes involved may not yet be assigned memory. Close extra windows or applications on your desktop and re-try again.
updateCounterDisplay() of QMonitorPanel: Could not allocate
memory for resource creation.
- The object classes involved may not yet be assigned memory. Close extra windows or applications on your desktop and re-try again.
constructMsgCount() of QMonitorPanel: Could not allocate memory
for resource creation.
- The object classes involved may not yet be assigned memory. Close extra windows or applications on your desktop and re-try again.
constructMsgVolume() of QMonitorPanel: Could not allocate
memory for resource creation.
- The object classes involved may not yet be assigned memory. Close extra windows or applications on your desktop and re-try again.
constructDualGauge() of QMonitorPanel: Could not allocate
memory for resource creation.
- The object classes involved may not yet be assigned memory. Close extra windows or applications on your desktop and re-try again.
Notation() of QMonitorPanel: Could not allocate memory for
resource creation.
- The object classes involved may not yet be assigned memory. Close extra windows or applications on your desktop and re-try again.
getStoredMessages() of handleevent() in QMonitorPanel: QUEUE
MONITOR: Could not communicate with the server due to a network
problem.
- The IMTA may be down or the Admin server may be down. If the IMTA is down, start it from the IMTA property book by clicking on the IMTA menu and selecting Start IMTA. If the Admin Server is down, restart the server, and then restart console.
Channel <channel name: No Messages>
- There are no stored messages in the selected channel. Select a channel which has stored messages and try again.
ResetCounters() of handleevent() in QMonitorPanel: QUEUE
MONITOR: Could not communicate with the server due to a network
problem.
- The IMTA may be down. Check the System Status section.
ResetCounters() of handleevent() in QMonitorPanel: Could not
allocate memory for resource creation.
- The object classes involved may not yet be assigned memory. Contact your...
Error in run() of QmonitorPanel Could not allocate memory for
resource creation.
- The thread that should be running may have been interrupted by another thread. Contact your authorized service provider.
Server Polling in run() of QMonitorPanel QUEUE MONITOR: Could
not communicate with the server due to a network problem.
- The IMTA may be down. Check the System Status section...
Failed to start IMAP4/POP3.
- The IMAP4/POP3 server cannot start. Contact your authorized service provider.
Failed to stop IMAP4/POP3.
- The IMAP4/POP3 server cannot stop. Contact your authorized service provider.
IMAP4/POP3 are already started.
- You are attempting to start the IMAP4/POP3 server when it is already up.
IMAP4/POP3 are already stopped.
- You are attempting to stop the IMAP4/POP3 server when it has already down.
You should start IMAP4/POP3 in advance.
- You requested connection information when the IMAP4/POP3 server is not running. Start the IMAP4/POP3 server from the Internet Message Access Protocols property book by clicking on the Internet Message Access Protocols menu and selecting start message access protocols IMAP4/POP3.
Error messages and warnings concerning the message store and the programs which maintain it, such as the mail server and mail delivery, often will report to the system log, /var/log/syslog.
Besides normally checking syslog periodically, if any unexpected effects are noticed, the admin should check the syslog for messages concerning the message store.
For example, if you can not connect to the mail server through IMAP after a system crash, check the syslog to see if the mail server (imaccessd) has exited and left a message as to why. It is possible the mail server may explain that the store is in a questionable state, and imcheck must be run for crash recovery before the store will be allowed back up.
Even if the store comes up, it is possible that warning or error messages may be sent during delivery or access to syslog in unexpected situations. Usually these messages specify a user or day that has some kind of problem which may or may not need to be addressed. Often with the user or day information, an admin can run imcheck on that user or day in order to get more information and to see if there is a problem.
Copyright© 1999 Sun Microsystems, Inc. All Rights Reserved.