Home /  MMonit /  FAQ

Table of Contents

Host does not show up in M/Monit

Keywords: mmonit settings configuration host top

Each Monit instance is identified by a unique ID, stored in the file, $HOME/.monit.id on the host running Monit. $HOME is the home directory of the user running Monit. This file is automatically created at startup by Monit if it does not exist. Care should be taken not to delete or change this file as the ID is used to pair messages from Monit with a host entry in M/Monit.

If the ID file is duplicated on multiple machines (this can happen if you clone the system including the Monit ID file) then several Monit instances will update the same host entry in M/Monit.

If this is the case, you will need to change or generate a new Monit ID file for those machines that does not show up in M/Monit:

  1. Stop monit on the host with the duplicate ID
  2. Change the Monit ID: use monit -r to reset the ID.
  3. Start monit (it will automatically update M/Monit with the new ID)

Jabber "Authentication failed"

Keywords: jabber auth login top

M/Monit use the SASL PLAIN authentication mechanism to login to a jabber server. If M/Monit reports an "Authentication failed" error, please make sure that you have this authentication mechanism enabled in your server. Also make sure that your jabber server software is updated. Several jabber servers (jabberd, prosody, ejabber) have a bug in their SASL PLAIN implementation which only recently has been fixed. For instance, ejabberd before version 2.1.2 had this bug.

Systems settings and scaling

Keywords: mmonit settings configuration scaling top

The sketch below describe the basic architecture of the M/Monit Connector. The Connector is the main processing component in M/Monit and is responsible for reading requests and creating responses. Many more sub-components are in use, but here we focus on the parts of the Connector which are configurable from server.xml via the <Connector> element; in practice, the number of processor threads (processors) and processorTimeout. Of these, the processors attribute is the most important.

Contrary to what one may think, increasing the number of processor threads may not help with scaling nor speed up M/Monit. In fact the effect is often the opposite. The reason is that M/Monit uses locking internally and adding more threads may lead to lock contention, that is, threads may fight over the same lock which can slow down the server. In addition, and to a lesser extent, the OS kernel has to do context-switching between threads, that is, pause a running thread, wake up and start the next thread in the queue etc. This context switching can also lead to a slowdown if there are many threads.

As a rule of thumb we recommend using the following settings in server.xml:

  • Set the processor attribute of <Connector> to 10 or to the number of CPU cores on the machine M/Monit is running if this number is higher.
  • The Database connection pool defined in <Realm>. Set maxConnections to 25. Adding more connections might only slow down the system.

Short description: 1. When a new request is received it is put in a first-in-first-out (FIFO) request queue. 2. The first available processor thread will dequeue the request, process it and create the response. If no threads are available, a new thread is created if the pool contains less than processor number of threads. Otherwise, the request waits in the queue and as soon as a processor thread becomes available it will dequeue and process the first request in the queue. If there are no more incoming requests, a processor thread will hang around for processorTimeout seconds, waiting for more work before it exit. This means that during peak hours, the pool will have max processor threads available to handle requests. and during slow periods, threads will be closed down and thereby reduce the resources used by M/Monit. 3. and 4. Once a response is created it is put on an outbound i/o queue. One I/O thread is used to flush the queue and write output non-blocking. This means that a processor thread works fast because there normally is no read or write i/o done by the thread.


The system's per process file descriptor limit defines a hard limit on how many concurrent connections M/Monit is allowed to handle as each connection to the M/Monit server requires at least one file descriptor.

In the old days, many Unix systems had the number of file descriptors allowed per process set to a low number. Today the opposite can be a problem. A too high limit can make M/Monit use unnecessary resources. M/Monit allocates a file descriptor table at startup based on available descriptors. At run-time, M/Monit polls the same table. We recommend setting the limit to "#Monit Agents + 1024". This is best done by using ulimit -n on the same command line before starting M/Monit. For example; ulimit -n 4096; /opt/mmonit/bin/mmonit

M/Monit Software Version Scheme

Keywords: mmonit version numbers top

The version number scheme used by M/Monit and Monit is, major.minor.revision, for example M/Monit version 3.2.1 . Where Major is a major update to the software, Minor is a small update to the software and Revision is any change made (bug fixes, small updates). Minor and Revision releases are free while Major releases typically requires a License upgrade. M/Monit releases can seen here

How to fix License Quota Exception

Keywords: mmonit license exception top

If your M/Monit license has a Host quota and an extra Host was inadvertently added, M/Monit might fail to restart with a License exception. To correct the problem, you can delete the last host from the database this way:


 cd <mmonit's directory>
 ./bin/sqlite3 ./db/mmonit.db
 PRAGMA foreign_keys = ON;





You should now be able to start M/Monit again.

How to redirect M/Monit http to https

Keywords: mmonit redirect http to https top

M/Monit can be setup to always use https and automatically redirect incoming http connections to https. The first step is to setup M/Monit to use SSL. See the manual to learn how to do this. To setup the redirect from http to https, open the file, mmonit/conf/server.xml and add a second connector on port 80 (the http port) with the redirectPort attribute set to your https connector's port. That is, your service element should consist of two connectors:

    <Connector address="*" port=“80" processors="10" redirectPort="443"/>
    <Connector scheme="https" address="*" port="443" processors="10" secure="true" />     

Then open mmonit/docroot/WEB-INF/web.xml and replace all (two places)




You are done. Restart mmonit and observe how connections over http is automatically redirected to https.

How to login to M/Monit with Basic Authentication

Keywords: mmonit login basic auth top

You can switch authentication in the M/Monit app from Form Based Authentication to Basic Authentication. To switch, change <login-config> in docroot/WEB-INF/web.xml and restart mmonit.

     <realm-name>M/Monit Login</realm-name>

Note that basic authentication does not have a concept of logout and you must restart your browser to logout. The logout button in the UI will only recreate the session and have no effect. Form Based authentication is therefor recommended.

How to reset the M/Monit admin user

Keywords: admin auth login top

  1. Follow these steps to reset the admin user's password back to swordfish:
  • Stop M/Monit
  • Connect to the M/Monit database (if you're using the default sqlite backend: sqlite3 db/mmonit.db)
  • Execute the following SQL statement:
 UPDATE users SET password = "15B29FFDCE66E10527A65BC6D71AD94D" WHERE uname = "admin";
  • Start M/Monit
  1. If you inadvertently have deleted the admin user and need to insert it again with the password ’'swordfish'', follow these steps
  • Stop M/Monit
  • Connect to the M/Monit database (if you're using the default sqlite backend: sqlite3 db/mmonit.db)
  • Execute the following SQL statements. Only do the first statement if the admin role was also deleted
 INSERT INTO roles VALUES ("admin", "The administrator role”); 
 INSERT INTO users (uname, password, fullname, title) VALUES ("admin", "15B29FFDCE66E10527A65BC6D71AD94D", "Administrator", "M/Monit Administrator");
 INSERT INTO userroles VALUES ("admin", "admin");
 INSERT INTO userroles VALUES ("admin", "monit");
  • Start M/Monit

How to use Gmail to send alerts from M/Monit

Keywords: alerts gmail smtp auth top

You can use Gmail's SMTP server to send email alerts from M/Monit. To do this, you will need to create an App Passwords in your Google Account which you then use with M/Monit. This approach can only be used with Google accounts that have 2-Step Verification turned on.

  • First login to your Google Account and select Security and click App passwords
  • In the Select app dropdown, select "Other" and use e.g. mmonit as the name:

  • Click Generate. The password generated can then be used in M/Monit where you setup the mail-server for alerts.

This will enable M/Monit to use Google's SMTP server to send email alerts. Later M/Monit versions will support the more secure alternative, Sign in with Google.