Job Controller

The Job Controller is one of the two major, "control" processes of the MTA (the other major such process being the  Dispatcher).

The Job Controller has two main responsibilities: (1) maintaining an in-memory "queue cache database" containing information about  what message files are on disk awaiting delivery; and (2) scheduling  and executing channel jobs to perform message  processing (attempt  message delivery). (The Job Controller is capable also of running additional, non-channel, periodically scheduled jobs. But that  capability is not normally used in modern versions of the MTA.)

In contrast to the Dispatcher, which is responsible for accepting  incoming TCP/IP connections and creating and managing server processes,  the Job Controller is responsible for creating and managing MTA channel  jobs (in particular SMTP client outbound processes and Message Store  delivery channel processes) to attempt message delivery. Notable examples are that the Dispatcher oversees SMTP server processes for  accepting messages incoming to the MTA, whereas the Job Controller  oversees Message Store delivery channels and SMTP channel client  processes for delivering outbound messages. (Though note that there can be exceptions to the overly simplistic "inbound equals Dispatcher,  delivery equals Job Controller" separation, as in the case of  channels that "pull" messages as well as deliver messages, or  in the case of delivery channels that also enqueue new messages such as  notification messages.) The topic Job Controller operation will go  further into Job Controller operation.

As the Job Controller is so fundamental to MTA operation, in normal operation is should always be present; see the topic Checking that the Job Controller is running. Indeed, normally the Watcher and msprobe are configured to monitor and perform  automatic checks on the Job Controller, with the Watcher restarting the  Job Controller if it appears to be absent or malfunctioning.

Furthermore, as operational advice, note that other than in cases of drastic configuration changes to the MTA or to site deployment, when a  Job Controller  restart often is necessary in order for changes to take effect,  normally the Job Controller should be left running, without gratuitous  restarting, as shutting down the delivery "half" of the MTA  even briefly tends to be disruptive to optimal performance of outbound  message delivery. (In particular, message delivery problems or delivery throughput concerns are not good reasons to restart the Job Controller!  Message delivery problems should be attacked at the channel level where  the delivery problem actually occurs, not at the Job Controller level;  and overall delivery throughput generally suffers a temporary dip when  the Job Controller must be restarted.)  Certain operationally interesting Job Controller options can instead have values adjusted "on the fly" (without requiring a Job Controller restart) using the    utility.

See also:
 * Channels
 * Notification messages
 * Job Controller operation
 * Job Controller default configuration
 * Job Controller options
 * Checking that the Job Controller is running
 * System parameters on Solaris
 * restart utility
 * cache -change utility
 * The MTA