Master_debug, nomaster_debug, slave_debug, noslave_debug Channel Options

From MsgServerDocWiki

(Link to this page as [[Master debug, nomaster debug, slave debug, noslave debug Channel Options]])
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.

Note that in the case of the l (lowercase "L") channel, master_debug enables debugging output when sending from the local channel (e.g., from VMS MAIL), and slave_debug enables debugging output as messages are delivered to the local channel (e.g., to VMS MAIL) (with output usually appearing in PMDF_LOG:l_master.log on OpenVMS or in pmdf/log/l_master.log on UNIX). On OpenVMS, these conventions also apply to the other channels that interact with VMS MAIL (d, d_, and mail_ channels). The thing to note is that this usage of the debug channel options is essentially backwards; other channels assign opposite meanings to the debug options. This usage is retained for historical and compatibility reasons.

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 slave_debug on that prior channel, rather than on the reprocess channel itself.

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

Note that the multithreaded TCP SMTP channel 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.

Personal tools