Understanding the MTA Log

The MTA keeps two kinds of logs. We'll refer to them as the MTA log and the Message Logging system. This section focuses on the MTA log, which keeps track of the actions performed by the MTA, including error messages, administration updates, and connections to other GroupWise agents.

Message Logging is a system whereby messages are tracked in a series of text files that are updated by the MTA. The tool for utilizing this information is the message-tracking feature of the HTTP monitoring piece on the GroupWise MTA.

You can browse the MTA logs from the MTA console using the View Logs tool under the Options menu. This tool does not allow for searching, however, and might be less convenient for you than using the HTTP interface of the MTA, which allows for detailed searches, or your favorite word processor.

MTA logs for a given domain's MTA are found at the root of the domain MSLOCAL directory. The log files have names such as 0125mta.003, which indicates the month and day on which the log file was created. The 003 in this example indicates that this was the third log file created, and of course, the filename shows that it was created on January 25.

If a log file is a 0-byte file, the MTA is probably currently working with it, and you will not be able to open it without using the Cycle Log command from the Options menu.

The Top of the Log File

At the top of each log file, the MTA writes the settings that it is running with. These settings, as discussed at the beginning of this chapter, could have been passed to the MTA through the command line, the MTA startup file, or the domain database.

Following is a look at a sample log file. Following are log entries from the MTA for the CORP domain.

General Settings

These first few blocks of text tell which domain the MTA is running against, what the Internet addressing and routing settings are, and some of the other general settings.

Following are the beginning lines of a sample MTA log:

23:00:17 0D7 CORPPO: Post office now open 23:00:17 0D7 MFG: Domain now open 23:00:17 0D7 GWIADOM: Domain now open 23:00:17 0CA LOG: Opening new log file: 0520mta.004 23:00:17 0CA General Settings: 23:00:17 0CA  Domain Directory:       wwwfs1/sys:\corp 23:00:17 0CA  Work Directory:        wwwfs1/sys:\corp\mslocal 23:00:17 0CA  Preferred GWIA:        GWIADOM.WWWGWIA 23:00:17 0CA  Default Route: 23:00:17 0CA  Known IDomains:        *wwwidgets.com 23:00:17 0CA  Allow Direct Send to Other Systems:   No 23:00:17 0CA  Force Route:              No

The last few settings deal with Internet addressing (covered in Chapter 16). Internet addressing has been enabled on this system. The preferred GWIA and default routing domain are listed, and then each of the IDOMAINs defined on this system is listed with a preceding asterisk.

Following is the last part of an MTA log, just after the MTA has started up:

23:00:17 0CA Error Mail to Administrator:        No 23:00:17 0CA Display the Active Log Window Initially: No 23:00:17 0CA eDirectory Authenticated:      Yes MTA.CORP.WWW.AMERICAS 23:00:17 0CA eDirectory User Synchronization:      Yes 23:00:17 0CA Admin Task Processing:           Yes 23:00:17 0CA Database Recovery:             Yes

The preceding are some of the operational settings for the MTA. This MTA has been authenticated to the directory, and eDirectory user synchronization is on. The admin thread is running, and if the MTA encounters domain databases damage, it will attempt to repair it.

TCP/IP Settings

An important part of your troubleshooting, should you have problems getting the MTA to "talk" to other GroupWise agents, is found here in the TCP/IP settings portion of the MTA log:

23:00:17 0CA TCP/IP Settings: 23:00:17 0CA  Maximum Inbound TCP/IP Connections:    40 23:00:17 0CA  TCP Port for Incoming Connections:     7100 23:00:17 0CA  TCP Port for HTTP Connections:       0 23:00:17 0CA  HTTP Refresh Rate:             60 secs 23:00:17 0CA TCP/IP Connection Timeout:      5 23:00:17 0CA TCP/IP Data Timeout:         20

The IP address of the MTA is not given here, because this parameter is defined at the server level. The inbound port is reported here, however. Also significant are the connection timeout and data timeout settings. These settings tell how many seconds the MTA will wait on an attempted connection or transmission. The values here are the defaults and can be changed with the /tcpwaitconnect and /tcpwaitdata switches in the MTA startup file.

Logging and Performance Settings

Here are the performance and logging settings for this MTA:

23:00:17 0CA Performance Settings: 23:00:17 0CA  Additional High Priority Routing Thread:  No 23:00:17 0CA  Additional Mail Priority Routing Thread:  No  23:00:17 0CA  Low Priority Scanning Cycle:        10 Seconds 23:00:17 0CA  High Priority Scanning Cycle:       5 Seconds 23:00:17 0CA Message Log Settings: 23:00:17 0CA  Message Log Directory:   wwwfs1/sys:\corp\mslocal\msglog 23:00:17 0CA  Track Messages:              On 23:00:17 0CA  Track Delivery Reports:          On 23:00:17 0CA  Track Status Reports:           On 23:00:17 0CA  Track Admin Traffic:            On 23:00:17 0CA  Correlate Delivery Reports:        On 23:00:17 0CA  Collect Extended Information:       On 23:00:17 0CA  Expire Records after How Many Day:     7 23:00:17 0CA  Message Log Database Size:         23552 bytes 23:00:17 0CA  Message Logging Enabled:          Yes 23:00:17 0CA Scheduled Event Settings:

In the performance settings section, it shows that there are no additional threads that have been spawned, and the scanning cycles for the MTA queues (WPCSIN\<0-7>) are every 5 seconds for the high-priority queues and 10 seconds for low-priority queues.

Finally, the log says that message logging is enabled, and indicates what the message log settings are set to.

The Body of the Log

Each line in the body of the MTA log is divided into three major sections: the timestamp, the process, and the statement. For example:

16:13:56 MTP: MFG-ipS0: Connection established. 137.65.55.211

In this example, the timestamp reads 16:13:56 (56 seconds after 4:13 p.m.), the process is MTP, and the statement is MFG-ips0: Connection established. 137.65.55.211.

The Process Column

If you are to make sense of the MTA log, you must first understand the acronyms and abbreviations in the process column. This section defines them:

• DIS: The dispatch process is responsible for dispatching other processes. You will see the DIS process when the MTA receives a restart command.

• RTR: The router process is responsible for moving files from one directory to another, as part of the whole message transfer operation. It is also the receive process when another MTA or POA transmits a file to this MTA via TCP/IP. If you have UNC links, RTR acts as both the send and the receive process, because RTR handles movement between directories.

• MTP: The message transfer process is responsible for connecting to another GroupWise MTA or POA and transmitting a message file to it via TCP/IP. This is the send process for the MTA.

• MLG: The message logging process is responsible for writing to the message log database. Even with message logging disabled, you will see the MLG process announcing the results of RTR and MTP operations.

• SCA: Th e scanner process is responsible for polling gateway directories under the domain directory, as well as any post office directories where TCP/IP connectivity has not been set up.

• ADM: The administration process is responsible for updating the domain database with any GDS (GroupWise Directory Services) information that is being propagated around the system. Add a user while connected to one domain, and you should see the ADM process on every other domain's MTA add that user there. (You'll also see the ADM process in the POA logs as the user is added to the post office database.) On occasion, you might see the Administration thread report itself as ADA or ADS.

• SNMP: The Simple Network Management Protocol process shows up when SNMP is enabled. It periodically announces that it has obtained the necessary parameters to publish MTA operational information to any SNMP-aware query agent on the system.

The MTA log files are very helpful when troubleshooting, particularly when determining whether administrative messages are being processed.