Master_debug, nomaster_debug, slave_debug, noslave_debug Channel Options

From Messaging Server Technical Reference Wiki
Jump to: navigation, search



Debugging channel master and slave programs (master_debug, nomaster_debug, slave_debug, noslave_debug)

Some channel programs include optional code to assist in debugging by producing additional diagnostic output. Two channel options are provided to enable generation of this debugging output on a per-channel basis. The options are master_debug, which enables debugging output in master programs, and slave_debug, which enables debugging output in slave programs. Both types of debugging output are disabled by default, corresponding to nomaster_debug and noslave_debug.

When activated, debugging output ends up in the log file associated with the channel program. The location of the log file may vary from program to program. Log files are usually kept in the MTA log directory. Master programs usually have log file names of the form x_master.log, where "x" is the name of the channel; slave programs usually have log file names of the form x_slave.log.

For the UNIX L and native channels, the "normal" debugging when the L channel is delivering is caused by slave_debug.

For the reprocess channel, since it performs some of its functions/checks as if it "were" the prior channel (the channel that enqueued to the reprocess channel), to get debugging of the reprocess channel's enqueuing operation, you will need to enable master_debug on that prior channel, rather than on the reprocess channel itself.

Note that the TCP/IP channel master program will produce multiple tcp_y_master.log files per master channel program execution when master_debug is enabled. The first such file produced shows the channel's determination of how many outgoing threads to start up; an additional log file will be created for each individual outgoing thread.

Similarly, the TCP/IP channel slave program -- the SMTP server or SMTP SUBMIT server -- will produce multiple files when slave_debug is enabled. The first such file produced is a SMTP server or SMTP SUBMIT server log file, with the base name specified via the logfilename Dispatcher option for the respective service (by default tcp_smtp_server.log and tcp_submit_server.log, respectively) with a unique identifying string appended, so typically tcp_smtp_server.log-uniqueid or tcp_submit_server.log-uniqueid. Some debugging regarding general server process initialization is written to such server log files: debugging regarding TLS initialization, the setting of TCP/IP-channel-specific options for the server, etc. However, the debugging regarding channel operation handling SMTP connections is written to channel slave log files, with names controlled by the name of the default channel for the service (see the parameter Dispatcher option for the service), so have names typically of the form tcp_local_slave.log-uniqueid or tcp_submit_slave.log-uniqueid.

The Message Store delivery channels, ims-ms and tcp_lmtpss* (LMTP back end TCP/IP channel, that is, the LMTP server), have two (or three) types of debug output: the MTA type of debug output (enabled as normal for MTA channels via the MTA channel options discussed here, and going to MTA channel debug log files as normal), plus some Message Store injection debugging (which is enabled by the loglevel option for the MTA, and which goes to the log file named, literally, imta, plus if message tracing is enabled (the activate messagetrace option is enabled) more detailed Message Store message tracing (which goes to the log file named, literally, msgtrace).

Not all MTA channel programs have debugging support code, and the amount of debugging output available also varies among those channel programs that include debug support.


See also: