pmx-milter - The PureMessage control program


    pmx-milter start [milter...]
    pmx-milter stop [-signal] [milter...]
    pmx-milter restart [milter...]
    pmx-milter status
    pmx-milter help


pmx-milter is a generic control program for PureMessage mail filters. It is used to start, stop and monitor the mail filter processes that communicate with the mail transfer agent (MTA).

pmx-milter loads the milter(s) specified in the pmx.conf configuration file.

Run pmx-milter as the PureMessage user (by default 'pmx6'). You can also run pmx-init as root, or from system startup and shutdown scripts.

The following sub-commands are recognized:

pmx-milter start [milter_name...]
If no milter names are specified, this command will start milters configured in pmx.conf that are not already running. If one or more milter names are specified, only those milters are started. Even milters that are disabled in the pmx.conf can be started if explicitly named.

pmx-milter stop [-signal] [milter_name...]
This command will stop the running milter(s). If one or more milter names are specified, only those milters are stopped. Otherwise all running milters are stopped.

signal should be either a signal number or a signal name.

By default, a graceful shutdown is attempted by sending the HUP (or TERM) signal to the running milter(s). This allows ongoing connections to finish processing before the milter shuts down. The signal argument can be provided with the stop command to force a more sudden death; an INT signal will attempt to do a clean shutdown after aborting current connections, and a KILL signal will shut it down immediately.

pmx-milter restart [milter_name...]
This will stop and then restart the running milter(s). Milters must be restarted after configuration changes for the changes to take effect. If one or more milter names are given, only those milters are restarted.

pmx-milter status
This will print out the current status for all running milters. The following status details will be reported for each running milter service (as applicable).
The process identification number for the service.

The port on which the service is running.

Same as the VSZ (Virtual Memory Size) value reported by 'ps' on the top-level process (the one that doesn't handle any connection requests, but simply passes them on to one of the children in the pool). It reflects the size of the top-level process before it started forking to create the child processes in the pool. All the processes in the pool will normally have a VSZ (as reported in the slot data below) at least this big.

The 'threads' field is not generally relevant and may reflect internal threads created by PureMessage or other libraries used by PureMessage. The display of the threads fields, and the value it reports, varies according to the operating system and version.

The current number of child processes under the master process.

The 'procs' field is actually computed from 'ps' output, so if 'ps' can't distinguish between processes and threads (like on many versions of Linux) this field won't be very useful. The slots data (see below) will always be accurate.

Most of the data in the status output (everything that didn't come from 'ps') is reported by whichever process happened to be available to respond to the status ping request. The 'interp' field shows how many interpreters are initialized within that process, and the maximum number of interpreters that are allowed within that process, separated by a ``/''.

The first part of this field can change depending on which process in the pool happened to service the ping request. The second part should be the same no matter which process handled the ping.

The sequence number of the most recently created interpreter in the process that serviced the ping request. The sequence number reflects how many interpreter initializations have occurred thus far.

This field is only relevant when the process pool is disabled. It shows how many connections are waiting for interpreters to become available. In process pool mode (which is the default), this will always be zero, because the master process knows how many connections each child can service, and will not send it any more connections once the capacity has been reached.

Internal flags. This will normally be 0x0 when process pooling remains enabled.

Summary information about the process pool. This is displayed as follows:
    slots=x/x (x retiring) req=x msg=xxxx

The first number after the 'slots' field reflects the maximum size that the process pool has ever been.

The second value shown in the 'slots' field (the one after the /) shows the maximum number of processes that can be instantiated by pmx-milter in its process pool. Normally, only half this number of processes can be instantiated, but the rest can be created if some of these processes are in the act of 'retiring'. A retiring process is one that is about to go away; it has stopped accepting new connections and is waiting to finish processing its pending connections before exiting.

The 'req' field shows the total number of connections that are currently being processed among all of the processes in the pool.

The 'msg' field shows the total number of messages that have been processed by the process pool.

Information about individual slots is displayed as follows:

    slot#x:   pid=xxxx   vsz=xxx.x  acc=xxxx/xxxxx/xx req=x*

The 'pid' field shows the process id of the process that currently occupies that slot. 'vsz' is the current virtual memory size of that process.

The 'acc' field shows three values: the number of connections that have been handled by the current process in the slot, the total number of connections handled by all the processes that have occupied the slot, and the number of distinct processes that have occupied the slot.

The 'req' field shows how many connections this particular slot is currently handling. This value summed across all slots should add up to the value shown in the previous 'req' field in the summary line. A '*' is added after the 'req' number if the slot is retiring.

pmx-milter help
Shows this man page.


the pmx-intro manpage, pmx-conf, PerlMx


Copyright (C) 2000-2008 Sophos Group. All rights reserved. Sophos and PureMessage are trademarks of Sophos Plc and Sophos Group.