3.2. The [monami] stanza.

One one stanza entitled "monami" is allowed: subsequent monami stanzas will be silently ignored. The MonAMI section describes how MonAMI-core should run.

3.2.1. Logging Messages from MonAMI

MonAMI provides messages containing information about events that occur during runtime. The destination of these messages is controlled by a set of configuration parameters that all begin with "log".

Each message has a severity; the four severity levels are:


no further execution is possible, MonAMI will stop immediately.


something went wrong. It is possible to continue running but with (potentially) reduced functionality. Errors might be rectified by altering MonAMI configuration.


a message that, whilst not indicating that there was an error, is part of a limited commentary that might be useful in deciphering apparently bizarre behaviour.


a message that is useful in determining why some internal inconsistency has arisen. The information provided is tediously verbose and only likely of use when finding problems within the MonAMI program and plugins.

The destination of messages (and whether certain messages are ignored) can be configured on the command line, or within the [monami] section of the configuration file.

Normally, a user is only interested in "critical" and "error" messages. If MonAMI is not working correctly, then examining the messages with "info" severity might provide a clue. Supplying the -v command-line option tells MonAMI to return info messages.

If MonAMI is running as a normal process (using the -f option), then critical and error messages are sent to standard error (stderr) and other message severity levels are ignored. If MonAMI is running verbosely (using the -v option) then info messages are sent to standard output (stdout), if running more verbosely (with -vv) then the debug messages are also sent to stdout.

If MonAMI is running as a daemon (i.e. without the -f command-line option) then, by default, critical and error messages are sent to syslog (using the "daemon" facility), info is ignored (unless running with the verbose option: -v) and debug is ignored (unless running more verbosely: -vv). Any messages generated before MonAMI has detached itself are either sent to stdout, stderr or ignored.

Other destinations are defined as follows:

An absolute file location (i.e. beginning with "/")

This is treated as a file destination. The message is appended to the file, creating the file if necessary.


indicates the message should be sent to syslog daemon facility.


indicates the message should be ignored.


sends the message to standard-error output.


sends the message to standard output.

Some examples:

  # ignore all but critical errors
  log          = ignore
  log_critical = syslog
  # store critical and error messages in separate files
  log          = ignore
  log_critical = /var/log/monami/critical.log
  log_error    = /var/log/monami/error.log

3.2.2. Dropping root privileges

MonAMI needs no special privileges to run. In common with other applications, it is possible that some bug in MonAMI be exploitable and allow a local (or worse, remote) user to compromise the local system. To reduce the impact of this, it is common for an application to “drop” their elevated privileges (if running with any) soon after they start.

There are two options within the configuration file to control this: user and group. The user option tells MonAMI to switch its user-ID to that of the supplied user and to switch group-ID to the default group for that user. The group option overrides the user's default group, with MonAMI adopting the group-ID specified.

In the following example, the [monami] stanza tells MonAMI to drop root privileges and assume the identity of user monami and group monitors.

  user  = monami
  group = monitors

3.2.3. Auxiliary configuration file directories

Often, a server may have multiple services running concurrently. Maintaining a monolithic configuration file containing the different monitoring requirements may be difficult as services are added or removed.

To get around this problem, MonAMI will load all the configuration files that end .conf within a named directory (/home/paul/MonAMI-test-install/etc/monami.d). If a new service has been installed, additional monitoring can be indicated by copying a suitable file into the /home/paul/MonAMI-test-install/etc/monami.d directory. When the service has been removed the corresponding file in /home/paul/MonAMI-test-install/etc/monami.d can be deleted.

Auxiliary configuration directories are specified with the config_dir option. This option can occur multiple times in a [monami] stanza. For example:

  config_dir = /etc/monami.d

3.2.4. Attributes

Summary of possible attributes within the [monami] stanza:

log, string, optional

change the default destination for all message severity levels. This overwrites the built-in default behaviour, but is overwritten by any severity-specific options.

log_critical, string, optional

change the destination for critical messages. This overwrites any other destination option for critical messages.

log_error, string, optional

change the destination for error messages. This overwrites any other destination option for error messages.

log_info, string, optional

change the destination for info messages. This overwrites any other destination option for info messages.

log_debug, string, optional

change the destination for debugging messages. This overwrites any other destination option for debug messages.

user, string, optional

The user-name or user-id of the account MonAMI should use. By default, MonAMI will also adopt the corresponding group ID.

group, string, optional

The group-name or group-id of the group MonAMI should use. This will override the group ID corresponding to the user option.

config_dir, string, optional

A directory that contains additional configuration files. Each file ending .conf is read and processed, but any monami stanzas are ignored. Its recommended that this directory be only readable by the user account that MonAMI will run under.