% configutil -o option-name

% configutil -o option-name -v option-value

% stop-msg snmp
% start-msg snmp

Option (Default) 

Description 

local.snmp.enable (0)

The Messaging Server SNMP subagent will only run when this option is given a value of 1 or true in which case Messaging Server will automatically stop and start the subagent as part of its normal startup and shutdown procedures. By default this option is set to zero which disables operation of the subagent. Before enabling the subagent, ensure that the platform's master agent has been properly configured as described in A.3.3 Running as a Standalone SNMP Agent.

local.snmp.standalone (0)

Messaging Server's SNMP support normally runs as a SNMP subagent, receiving SNMP requests via the platform's SNMP master agent, snmpd. This operational mode is the default and is selected by giving this option a value of 0 or false. However, as described in A.3.3 Running as a Standalone SNMP Agent, the subagent may run in a "standalone" mode whereby it operates as a SNMP agent independent of snmpd. When run in standalone mode, the subagent--now a SNMP agent--listens directly for SNMP requests on the Ethernet interface and UDP port specified by, respectively, the local.snmp.listenaddr and local.snmp.port options. To run in this standalone mode, specify a value of 1 or TRUE for this option.

Running in standalone mode does not interfere with other SNMP master or subagents running on the system. 

local.snmp.listenaddr (INADDR_ANY)

Hostname or IP address of the Ethernet interface to listen for SNMP requests on when running in standalone mode. By default, all available interfaces are listened on. This corresponds to specifying the value INADDR_ANY. A specific interface may be selected by specifying either the IP address or hostname associated with that interface. The interface may be either a physical interface or a virtual interface.

This option is ignored when local.snmp.standalone is set to 0 or FALSE.

local.snmp.cachettl (30)

Time to live (TTL) in seconds for cached monitoring data. This option controls how long the subagent will report the same monitoring data before refreshing that data with new information obtained from Messaging Server. With the exception of message loop information, data is cached for no longer than 30 seconds by default. Loop information, as determined by scanning for .HELD files, is updated only once every 10 minutes. That because of the resource cost of scanning all the on-disk message queues.

Note that the subagent does not continually update its monitoring data: it is only updated upon receipt of an SNMP request and the cached data has expired (that is, outlived its TTL). If the TTL is set to 30 seconds and SNMP requests are made only every five minutes, then each SNMP request will cause the subagent to obtain fresh data from Messaging Server. That is, data from Messaging Server will be obtained only once every five minutes. If, on the other hand, SNMP requests are made every 10 seconds, then the subagent will respond to some of those requests with cached data as old as 29 seconds; Messaging Server will be polled only once every 30 seconds. 

local.snmp.servertimeout (5)

The subagent determines the operational status of each monitored service by actually opening TCP connections to each service and undergoing a protocol exchange. This timeout value, measured in seconds, controls how long the subagent will wait for a response to each step in the protocol exchange. By default, a timeout value of five seconds is used. 

local.snmp.directoryscan (1)

Use this option to control whether or not the subagent performs scans of the on-disk message queues for .HELD message files and the oldest message files. That information corresponds to the mtaGroupLoopsDetected, mtaGroupOldestMessageStored and mtaGroupOldestMessageId MIB variables. When this option has the value 1 or true, then a cache of this information is maintained and updated as needed. Sites with thousands of queued messages, that are not interested in these particular MIB variables should consider setting this option's value to 0 or false.

local.snmp.enablecontextname (0)

The subagent has the ability to register its MIBs under an SNMP v3 context name. When this is done, the MIBs may only be requested by a SNMP v3 client which specifies the context name in its SNMP request. Use of context names allows multiple, independent subagents to register Network Services and MTA MIBs under the same OID tree (that is, under the same SNMP master agent). See A.3.4 Monitoring Multiple Instances of Messaging Server for further information.

To enable the use of SNMP v3 context names, specify a value of 1 or true for this option. When that is done, the subagent will default to using the value of the service.defaultdomain option for its context name. To use a different value for the context name, use the local.snmp.contextname option.

local.snmp.contextname (service.defaultdomain)

When the use of SNMP v3 context names has been enabled with local.snmp.enablecontextname, this option may be used to explicitly set the context name used by the subagent for its MIBs. The values supplied for this option are string values and must be appropriate for use as a SNMP v3 context name. This option is ignored when local.snmp.enablecontextname has the value 0 or false.