Shutdown utility

Shut down MTA components.

Syntax
imsimta shutdown &#x5b;component&#x5d;

Restrictions
Must have superuser privileges or use the Solaris RBAC feature in order to use this utility.

The optional   parameter specifies a specific MTA component to be shut  down. The components that may be specified are ,  , and any  services  defined in the Dispatcher configuration, which  typically might include   ,  , and.

Description
The  utility shuts down the  MTA Job Controller and the MTA  Dispatcher.

Note that shutting down the MTA Dispatcher causes a graceful shutdown  of all services (e.g., ,   ,   ) being  managed by the MTA Dispatcher. That is, existing such server processes "finish up" whatever connections they currently have open,  but do not accept new connections. As of MS 6.2p8, such server processes "finish up" processing of whatever message  submissions were already in progress, but reject any attempts (even in  the same, already opened connections) to submit further messages, with  an effect as if   /   had been  reached. That is, prior to MS 6.2p8 while new connections would not be accepted, old connections might continue to work, accepting further  message submissions; however, as of MS 6.2p8 even already existing  connections are "poisoned" so that they may not receive  additional new message submissions. (See the   channel option if you wish to have the  server processes force a disconnect of connections once they will no  longer accept further messages.)

Whenever the Job Controller is shutdown, before it shuts down it sends  a "no more messages" notice to all its child processes  (channel processes), which such processes will read from their  communication buffer once they finish up whatever current message they  are working on and wish to ask the Job Controller whether there are any  more messages. That is, the Job Controller itself shuts down, but leaves a "poison" message in a buffer that the channel jobs  will see as they each finish up their own work. So generally (but with a couple of exceptions, to be discussed just below) any old channel  processes that the Job Controller had previously started finish up  whatever message they had already been working on. Once a channel process has finished its already started work and then asks for another  message to process, it will see that there are no more messages for it  to process, and exit. However, exceptions are the   channel, and less  commonly, outbound TCP/IP channels. When the Job Controller has been shutdown, then   channels will interrupt  processing even of currently being processed messages after a brief  amount of time (an additional 55 seconds) spent attempting to complete  processing of the current message; but the remaining recipients of a message  for which processing had begun will be deferred for later processing;  (when logging is enabled,  " " records with a  reason of  " " will be generated for those recipients). TCP/IP channels will abort processing after their configurable    TCP/IP-channel-specific option time period has expired. (Note that the default value for    is relatively "large" due to the potential  for undesirable remote SMTP server handling of aborted message  transfers, and the potential expense of resending a "large"  message.)

In typical Messaging Server configurations,   may be  configured to check periodically on the Job Controller, the SMTP  server, and SMTP SUBMIT, and LMTP server; see the  ,   ,  ,   , and     options in Unified Configuration. In particular, if with such configuration   determines that the Job Controller, or a service managed by the  Dispatcher, is not responding to its probe, and if autorestart has been  enabled (   in Unified Configuration),  then   will ask the  Watcher to restart the  non-responsive process (such as the Job Controller or Dispatcher). So performing a   of an MTA management process, or  specific service (e.g.,  ) causes a temporary  shutdown, but  that shutdown is likely to be only temporary (unless such Messaging  Server monitoring-and-automatic-restarting has not been enabled). (To shut down a service more permanently, the configuration should be more  fundamentally modified: for instance, remove the Dispatcher&#x27;s  definition of the service in question, or to  disable the Dispatcher or  Job Controller, respectively, in Unified Configuration, set    or    to   .) Thus the use/purpose of the    command in modern usage tends to be to perform a temporary  shutdown, perhaps while a configuration change is being made, with    often used shortly thereafter, to start  the component back up once a desired configuration change has been  implemented.

Examples
Stopping dispatcher server 29020 ......... done Stopping job_controller server 29637. done The above UNIX command shuts down the MS MTA, showing the sort of output shown in  MS 6.3. (Earlier versions would not have as much/the same sort of output.) dispatcher server is not running job_controller server is not running The above shows an example of the sort of output shown as of  MS 6.3,  if a   command is issued  when the MTA Dispatcher and Job Controller had not in fact been running.
 * 1) imsimta shutdown
 * 1) imsimta shutdown

Error messages
Trouble communicating with the Dispatcher, shutting it down, will be reported back to  : dispatcher server is not running or Cannot stop dispatcher server (pid=pid) with SIGTERM Retrying with SIGKILL Trouble shutting down the Job Controller will be reported back to : job_controller server is not running

See also:
 * Dispatcher
 * Job Controller
 * Service group
 * Typical TCPIP channels and servers
 * ALLOW_TRANSACTIONS_PER_SESSION
 * transactionlimit Option
 * disconnecttransactionlimit Option
 * Job Controller operation
 * ims-ms channels
 * logging Option
 * MTA transaction log entry format
 * log_reason MTA Option
 * TCPIP channels
 * WINDDOWN_TIMEOUT
 * msprobe options
 * Probe options
 * msprobe task options
 * Base autorestart options
 * Watcher options
 * enable Option
 * MTA command line utilities