4.0 Message Transfer Agent Problems
For a list of error messages related to the Message Transfer Agent, see Message Transfer Agent Error Messages
in GroupWise 8 Troubleshooting 1: Error Messages.
This section suggests ways to fix the following problems:
Problem:
The MTA does not start.
Possible Cause:
The /home switch is missing.
Possible Cause:
The /home switch points to an unavailable location.
Action:
Make sure the location specified by the /home startup switch is currently available to the MTA. If the domain is located on a different server from where the MTA will run, preparations for the connection between the MTA and the domain are required:
-
If you are using the NetWare MTA, you must use the /dn startup switch or the /user and /password startup switches to enable the MTA to log in to the server where the domain is located.
-
If you are using the Linux MTA, mount the file system where the domain is located to the server where the MTA is running.
-
If you are using the Windows MTA, you must create the drive mapping to the domain and post offices in the domain before starting the MTA.
Possible Cause:
The server where the domain resides is down.
Action:
Check the status of the server where the domain resides.
Possible Cause:
The /work switch points to an unavailable location. Although not required, the /work startup switch is useful to specify a local working directory for the MTA when the domain it services is located on a different server. Using the /work switch to provide a local working directory on the server where it is installed is highly recommended for MTA performance. If the /work switch is not used, the working directory is placed in the directory specified by the /home switch.
Action:
Make sure the location of the MTA working directory is available to the MTA.
Possible Cause:
The MTA does not have sufficient rights to the domain directory.
Action:
Make sure the network rights in the domain are correct.
Possible Cause:
The domain database (wpdomain.db) is damaged.
Possible Cause:
The MTA server has inadequate resources.
Possible Cause:
The MTA is not installed correctly.
Possible Cause:
Language-specific files are missing.
Possible Cause:
The MTA is encountering a problem with one specific aspect of its functioning.
Action:
MTA startup switches are available to disable specific MTA functions while allowing other functions to continue normally. For example, the /noada switch disables the MTA admin thread. If a specific MTA function is causing the MTA to shut down, you might be able to disable that particular function with a startup switch. See Using MTA Startup Switches
in Message Transfer Agent
in the GroupWise 8 Administration Guide.
Possible Cause:
The MTA encounters an error condition.
MTA Shuts Down Unexpectedly
Problem:
The MTA has been running smoothly, but stops unexpectedly.
Action:
If the MTA agent console is still displayed, exit it. If the normal exit procedure does not work, use the system procedure for terminating a program.
-
If you are using the NetWare MTA, use the NetWare unload command. If you have other MTAs running on the same server, you should exit them before using the unload command. The unload command unloads all MTAs running on the same server and might not enable them to terminate gracefully.
-
If you are using the Linux MTA, kill the first MTA process. You might need to use kill -9.
-
If you are using the Windows MTA, close the MTA window.
Action:
If the MTA shuts down again, exit it again, reboot the server, then start the MTA again.
Possible Cause:
Occasionally, a badly damaged message file can cause the MTA to shut down.
Action:
Check the contents of the MTA input queues in the domain and post offices. For the locations of the MTA input queues, see Message Transfer/Storage Directories
in GroupWise 8 Troubleshooting 3: Message Flow and Directory Structure.
Move the message files out of the priority subdirectories of each input queue, start the MTA, then copy the message files back in groups, watching the MTA carefully to see if it shuts down on a particular message file. If it does, delete the problem message file so normal processing can resume.
Possible Cause:
Occasionally, a damaged domain database (wpdomain.db) can cause the MTA to shut down.
Possible Cause:
Network connections are unstable.
Action:
Make sure the connections between the server where the MTA is running and the servers where the domain database (wpdomain.db) and post office database (wphost.db) are located are stable. Repeatedly losing connections to servers can cause damage to databases.
Possible Cause:
The MTA is encountering a problem with one specific aspect of its functioning.
Action:
MTA startup switches are available to disable specific MTA functions while allowing other functions to continue normally. For example, the /noada switch disables the MTA admin thread. If a specific MTA function is causing the MTA to shut down, you might be able to disable that particular function with a startup switch. See Using MTA Startup Switches
in Message Transfer Agent
in the GroupWise 8 Administration Guide.
Possible Cause:
Another program on the server is interfering with the operation of the MTA.
Action:
If the MTA continues to be unstable, eliminate other programs running on the server. If the MTA is stable when another specific program is not running on the same server with it, a conflict might exist between the two programs.
MTA Status Box Shows a Closed Location
Problem:
At the MTA agent console, the Status box shows a closed location.
Action:
In Configuration Status Details, check the directory paths for mapped and UNC connections or the IP addresses and port numbers for TCP/IP links. Make sure the correct locations are displayed. Make sure the locations exist, and verify that the database (wpdomain.db for a domain or wphost.db for a post office) is there in the specified location. Do not use eDirectory paths.
Possible Cause:
A domain or post office has been moved incorrectly.
Action:
When you move a domain or post office to a new location or change its link type, you must make various configuration changes in ConsoleOne. If the domain or post office becomes closed as a result, the reconfiguration changes might not have replicated down to the agent in the reconfigured location before other changes prevented the replication from happening at all. Rebuild the location database (wpdomain.db or wphost.db). See Rebuilding Domain or Post Office Databases
in Databases
in the GroupWise 8 Administration Guide. This ensures that the reconfiguration changes are replicated to the location. Then restart the agent for the location.
Possible Cause:
The MTA server has insufficient memory.
MTA Statistics Box Shows Undeliverable Messages
Problem:
At the MTA agent console, the Statistics box displays a large number of undeliverable messages.
MTA Statistics Box Shows Errors
Problem:
At the MTA agent console, the Statistics box shows a large number of message errors have occurred.
MTA Configuration Status Isn’t Open
Problem:
At the MTA agent console, the Configuration Status box displays the connection status as something other than Open.
Action:
If the configuration status is Closed, the MTA cannot access the database in the domain or post office. Make sure the server where the closed location resides is not down. Make sure the MTA can access the server.
Action:
If the connection status is Open Pending, post offices in the domain are in the process of opening and the MTA is clearing its holding queues. After this is accomplished, the MTA begins processing current messages and the status changes to Open. No action is necessary.
MTA Fails to Update the Domain Database Version
Problem:
You are updating the MTA software in a secondary domain and the MTA fails to update the database version for the domain. You might see conflicting database version information depending on whether you are connected to the secondary domain or the primary domain.
Possible Cause:
You installed and started the MTA for the secondary domain before the MTA for the primary domain had finished updating the primary domain database.
Action:
Wait until the MTA for the primary domain has finished updating the primary domain database. For a large domain database, you might need to wait as much as 20 minutes or more. Verify that the primary domain database version has been updated by checking the Domain object’s Identification page in ConsoleOne. Then stop and restart the MTA for the secondary domain to update the secondary domain database.
Action:
If restarting the MTA for the secondary domain does not update the domain database version:
-
Compare the dates on the .dc files (gwdom.dc and gwpo.dc) in the secondary domain directory with the dates on the .dc files in the update source.
-
If the dates on the .dc files in the secondary domain are older than the dates on the .dc files in the update source, copy the .dc files from the update source into the domain directory.
-
At the MTA console, recover the domain database. See Recovering the Domain Database Automatically or Immediately
in Message Transfer Agent
in the GroupWise 8 Administration Guide.
When the recovery process is finished, the database version should be updated.
-
In ConsoleOne, connect to the secondary domain, then check the Domain object’s Identification page to verify that the database version has been updated.
-
Connect to the primary domain database, then check the Identification page for the primary domain to verify that the database version information matches in both domain databases.
Possible Cause:
There are one or more closed links between the secondary domain and the primary domain that are preventing the administrative messages from flowing between the domains to accomplish the database version update.
MTA Starts in the Wrong Language
Problem:
You have installed the MTA in more than one language and it is starting in a different language than you want.
Action:
Start the MTA using the /language switch to specify the language.
MTA Is Involved with Network Operating System or Hardware Problems
Problem:
The MTA is interacting with the network operating system or hardware in an undesirable way.
Possible Cause:
If you just updated the MTA software, you might not have unloaded the agent engine (gwenn5.nlm), resulting in a series of Loader cannot find public symbol: symbol errors on the server console.
Action:
Unload gwenn5.nlm, then start the MTA, so that the newly installed agent engine is loaded along with it.
Possible Cause:
The MTA server is running older software, resulting in TCP_HANDLER errors on the server console.
Action:
Make sure you are using the most current TCP/IP stack for NetWare.
Possible Cause:
The MTA server is overburdened, resulting in SYN attacks.